Искусство управления IT-проектами

Ежедневное поклонение концептуальным положениям

Один из оригинальных экземпляров Конституции США помещен в музейное хранилище в Вашингтоне, округ Колумбия, за толстыми листами из сверхпрочного стекла. Хотя этот экземпляр хранится в безопасном и надежном месте, я уверен, что в таком формате его читали немногие. Когда идеи недоступны или остаются в тени, они постепенно уходят в небытие (если только из-за особой ценности их не делают музейными экспонатами). Даже в краткосрочных проектах легко утратить ту общую для проекта канву, в которую должны вписываться ежедневные решения, и недостаток видения основных идей способствует возникновению этой разновидности энтропии. Люди могут быть загружены до предела и успешно работать над решением частных задач, но без частой сверки курса с общими ориентирами им будет довольно трудно понять, что все они движутся в правильном направлении. Концепция, или сборник основных идей и целей проекта, является частью общего процесса, и поэтому она должна постоянно присутствовать в коридорах и офисах людей, выполняющих свою работу.

Чтобы концепция всегда была на видном месте, несколько ключевых целей проекта должны быть оформлены в виде плакатов, расположенных в наиболее людных местах. Их открытое обсуждение должно вестись на еженедельных или ежемесячных совещаниях после предварительной публичной зачитки. Если командой используется демонстрационный экран или другие вспомогательные средства визуализации, то ключевые моменты должны быть отображены на первом слайде или первой странице. Большинство сотрудников в любое время должны быть в состоянии назвать основные цели проекта, по крайней мере, те из них, к которым они имеют непосредственное отношение или за реализацию которых несут личную ответственность.

Но этих мер явно не достаточно для поддержания концепции в актуальном состоянии. Лишь то, что люди ее запомнили, еще не означает, что они ее используют в своей работе. Сохранение актуальности концепции требует усилий со стороны руководства команды. Оно должно постоянно обращаться к тем самым мотивам, которые и привели к созданию самой концепции.

В процессе работы над реализацией проекта на каждом совещании по подведению итогов или постановке задач обращайтесь к следующим вопросам:

1. Насколько точно концепция отражает наши цели, определенные для этого проекта?

2. Помогает ли концепция ведущим и рядовым сотрудникам принимать решения, а также отклонять запросы, не имеющие к ней отношения?

3. Есть ли достойные обсуждения изменения концептуальных положений, позволяющие положительно ответить на два первых вопроса?

Если руководство организации в состоянии сохранять актуальность концептуального документа, то предоставляет такую же возможность и всем остальным. Концепция и цели проекта сохраняют жизненные силы и могут служить постоянным источником мотивации и ясности действий всей команды.

Но это вовсе не означает, что концепция должна подвергаться частым корректировкам. Наоборот, существенные изменения, после того как проект наберет полные обороты, должны быть событием исключительным. Но, как и в случае с поправками к Конституции, вполне вероятно, что при определенных обстоятельствах вносимые изменения будут вполне оправданы. И такая возможность позволяет сохранять у всех четкость представлений и осмысленность основных концептуальных замыслов.

Выводы

• Концептуальные документы являются квинтэссенцией всех остальных материалов планирования и находят свое выражение в едином обобщенном плане.

• Документирование приносит пользу и создателю концепции, и всей команде. Тем самым закладываются основы для проведения дискуссий и рабочие ориентиры, не зависящие от нашей «дырявой» памяти.

• Степень детализации вашего концептуального документа зависит от особенностей команды и самого проекта.

• Цели команды должны быть производными от целей, определенных в концепции, а индивидуальные цели, в свою очередь, от целей, поставленных перед командой.

• Хорошая концепция отличается простотой, запоминаемостью, целенаправленностью, способностью консолидировать усилия участников проекта и вдохновлять их на его реализацию.

• Объем не является эквивалентом качества. А краткость требует больших усилий.

• Концепция должна сохранять актуальность за счет ее повседневной сверки с решениями, принимаемыми в ходе реализации проекта.

Упражнения

1. Выберите какой-нибудь фильм или книгу, которые, по вашему мнению, вызывают вдохновение. Благодаря каким качествам фильма возможен этот эффект воздействия? Представьте себя режиссером фильма. Составьте краткие концептуальные положения фильма, перечислите те качества фильма, которые вы хотели бы иметь в его окончательной версии. Если вы выбрали такой фильм, посмотрите DVD-комментарии, чтобы услышать, как создателям фильма удалось добиться такого воздействия на зрителей.

2. Закройте глаза и представьте, на что по завершении будет похож проект, над которым вы работаете. Если завершенный проект преобразовать в художественный фильм, на что будет похож его саундтрек? Будет ли это фоновая музыка (приглушенная музыка, которую можно услышать в лифтах и комнатах ожидания)? Танцевальная музыка? Панк-рок? Подберите для проекта музыку из кинофильма, воспользовавшись помощью специалистов команды, и раздайте им компакт-диск или список воспроизведения.

3. Исследуйте историю прорицателей. Выберите любых двух из следующего списка: Ганди, Малкольм Х, Торо, Будда, Сократ, Иисус Христос или Конфуций. Какими были их мировоззренческие концепции? Как они развивали свои идеи? Что они делали для выражения этих идей? Для их продвижения и популяризации?

4. Выберите какой-нибудь день и подсчитайте, какой процент вашего времени ушел на чтение составленных кем-то письменных документов. Обязательно включите сюда текстовые сообщения, электронную почту, моментальные сообщения, веб-сайты, доски объявлений, письма из дома, а также документы, имеющие непосредственное отношение к проекту. Не забудьте подсчитать время, затраченное на записи этих подсчетов. Это упражнение поможет вам понять, почему с учетом всего времени, потраченного на чтение, так важно уделять внимание составлению концептуальных документов.

5. Что может произойти, если чьи-то индивидуальные цели вступают в конфликт с целями команды или проекта? Кто должен разрешить подобную ситуацию? Какие действия нужно предпринять?

6. Когда настанет время для команды написать концептуальный документ или технические условия, распечатайте несколько копий Конституции США и оставьте все это на стуле любого из авторов технических условий с запиской: «Они составили технические условия для целого правительства всего на шести страницах. А сколько понадобится тебе для описания отдельной характеристики?» Как на это отреагирует команда?

7. В начале каждого проекта составьте общий для всех список жаргонных слов, нерекомендуемых к употреблению. Выберите слова, которые, по вашим сведениям, имеются в лексиконе ваших людей, но у которых есть более приемлемые и понятные синонимы (которые нужно предложить). Поместите список на публичном wiki-сайте и позвольте людям по мере работы над проектом вносить в него дополнения.

Конец ознакомительного фрагмента.

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

1

Сознание начинающего является начальным понятием дзен-буддизма. В канонической притче фигурирует пустая чаша: если сконцентрироваться на том, чем заполнена ваша чаша, в ней никогда не будет места для новых знаний. См. книгу Сюнрю Судзуки (Shunryu Suzuki) «Zen Mind, Beginner’s Mind» (Weatherhill, 1972).

2

Об этом свидетельствует отчет «CHAOS Report» (The Standish Group) – документ о бюджете, календарном плане и общих провалах проектов разработки программного обеспечения. Публикуется по адресу http://standishgroup.com/sample_research/.

3

Карл Поппер был одним из видных философов ХХ века. (См. http://en.wikipedia.org/wiki/Karl_Popper).

4

Из книги Джеймса Чайлза (James R. Chiles) «Inviting Disaster: Lessons from the Edge of Technology» (HarperBusiness, 2002).

5

Хорошее описание как матричного, так и других типов организации можно найти в книге Стивена Силбигера (Steven A. Silbiger) «The Ten-Day MBA» (William Morrow and Company, 1993) на с. 139–145. Впрочем, эту информацию можно найти практически в любой книге, посвященной теории управления.

6

Опубликована по адресу http://www.tompeters.com/col_entries.php?note=005297&year=1991.

7

Как-то в Питтсбурге мы с приятелями зашли пообедать в пиццерию и получили заверение, что столик будет готов через десять минут. Ровно через десять минут мой друг Чад МакДаниел поинтересовался готовностью столика и получил ответ распорядителя, что все будет готово через десять минут. Тогда он спросил: «Это те же десять минут или другие десять минут?» – но его шутку должным образом так и не оценили.

8

В оригинале «Feature-driven development». – Примеч. ред.

9

Сравнительное обсуждение традиционных и гибких методов разработки программных средств вы сможете найти в книге Барри Боэма (Barry Boehm) и Ричарда Тернера (Richard Turner) «Balancing Agility and Discipline: A Guide for the Perplexed» (Addison Wesley, 2003).

10

Информацию об определениях и понятиях изменений процесса разработки программного обеспечения, а также об управлении этими изменениями можно найти в книге Уоттса С. Хамфри (Watts S. Humphrey) «Managing the Software Process» (Addison Wesley Professional, January 1989).

11

«Understanding and Controlling Software Costs», IEEE Transactions on Software Engineering, т. 14, № 10, октябрь 1988, стр. 1462–77; а также книга «Software Engineering Economics» (Prentice Hall, 1991).

12

Календарные планы, основанные на имеющихся работах, называются восходящими, потому что они создаются командой, а календарные планы, основанные на потребностях управления, – нисходящими. Обычно разногласия между ними согласовываются.

13

В зависимости от характера непредвиденных обстоятельств (просчеты проектантов, политические революции, нашествия пришельцев и т. д.), заложенных в календарный план, рабочий график может быть разным. Если возможные провалы не рассматривались, календарный план не может вызывать доверия. Его создатель не проявил должного творческого подхода или скепсиса.

14

Процесс проведения структурной декомпозиции работ описан во многих книгах. К этой теме я вернусь в главе 14, но если вы хотите изучить ее более обстоятельно, начните с материалов, размещенных по адресу http://en.wikipedia.org/wiki/Work_breakdown_structure, или с книги Стефана Дево (Stephen Devaux) «Total Project Control» (Wiley, 1999).

15

В книге Кента Бека (Kent Beck) «Extreme Programming Explained» (Addison Wesley, 1999) предлагается программно-ориентированная модель распределения работ, при которой программисты сами выбирают себе работы. В идеале должен быть выдержан компромисс между тем, что лучше для проекта, и тем, что лучше для отдельных специалистов команды.

16

См. книгу Кента Бека (Kent Beck) и Мартина Фоулера (Martin Fowler) «Planning Extreme Programming» (Addison Wesley, 2002), стр. 60–62.

17

Стандартная формула для метода PERT: лучший расчет + (4 × наиболее вероятный расчет) + худший расчет/6. Имейте в виду, что существует огромное количество разновидностей и теорий наилучших взвешенных расчетов.

18

Сравнить другие типы проектов вы сможете, обратившись по адресу http://www.joelonsoftware.com/articles/FiveWorlds.html.

19

Эндрю Стеллман (Andrew Stellman), один из научных редакторов данной книги, несколько раз угрожал мне физической расправой, если я не расскажу о качестве программного продукта, но эта глубокая тема так и не вписалась в рамки моей книги. Для начала порекомендую вам две другие книги: «Out of the Crisis» (MIT Press, 2000) У. Эдвардса Дэминга (W. Edwards Deming) и «Quality Is Free» (Signet Books, 1992) Филиппа Кросби (Philip Crosby).

20

Файзал Джафдат (Faisal Jawdat), один из научных редакторов данной книги, угрожал мне изощренными пытками, если я не отмечу всю иронию ситуации, в которой после всего сказанного я продолжал работать на Microsoft.

21

Эта сноска дана специально, чтобы заставить читателя обращать на сноски хоть какое-то внимание. А если серьезно: когда проектировщики работают на себя, они имеют склонность многократно переделывать сделанное, возможно, расслабляясь в отсутствие образа потребителя, на которого надо работать.

22

Обратите внимание на замечательную книгу Дональда Гауса (Donald Gause) и Джералда Вейнберга (Gerald Weinberg) «Exploring Requirements: Quality Before Design» (Dorset House, 1989).

23

Этот метод описан в книге Алистера Кокборна (Alistair Cockburn) «Writing Eff ective Use Cases» (Addison Wesley, 2000).

24

Прочтите книгу Дэниела Шактера (Daniel Schacter) «The Seven Sins of Memory» (Mariner Books, 2002) или посмотрите замечательный фильм «Помни» («Memento»). Это поможет вам осознать, сколь ограничена и ненадежна человеческая память.

25

Из книги «Piloting Palm: The Inside Story of Palm, Handspring and the Birth of the Billion-Dollar-Handheld Industry» авторов Андреа Баттера (Andrea Butter) и Дэвида Поги (David Pogue) (Wiley, 2002), стр. 72.