banner banner banner
Искусство управления IT-проектами
Искусство управления IT-проектами
Оценить:
 Рейтинг: 0

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


• Ведомственная информационная страница будет загружаться, по крайней мере, так же быстро, как и домашняя страница.

• Интерфейс запросов к базе данных будет по надежности сопоставим с остальными компонентами системы.

• Пользователи получат возможность видеть состояние сервера электронной почты в простом и удобном формате.

• У пользователей будет удобный способ сохранять свои предпочтения при настройке системы.

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

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

Объединение деловых и технологических требований

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

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

Выводы

• Разные проекты требуют различных подходов к планированию.

• Результаты планирования часто определяются тем, кто и какими полномочиями обладал. На планирование оказывают влияние три вида полномочий, связанные с определением перечня требований, конструированием и финансированием.

• Существует ряд общих разработок для планирования проекта: документы, отражающие анализ потребностей рынка (MRD), документы, определяющие концепцию и рамки проекта, технические условия и документы структурной декомпозиции работ (WBS).

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

• Постановка вопросов наводит на правильные размышления и эффективно направляет энергию планировщиков в нужное русло.

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

• Формулировка проблем и выработка сценариев представляют собой простейший способ определения перечня требований и доведения его до участников проекта. Эти документы легко превращаются в конструкторские идеи, сохраняя видение главных и второстепенных составляющих проекта.

Упражнения

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

2. Из трех взглядов на проект – с точки зрения бизнесмена, разработчика и потребителя – какой был представлен меньше других в последнем, реализованном вами проекте? Как это повлияло на качество конечного изделия?

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

4. Предположим, вы были руководителем проекта, при работе над которым инженеры и бизнесмены недолюбливали друг друга, и вели войну вокруг основных решений. Какие действия можно было предпринять с вашей стороны для улучшения взаимоотношений? (Подсказка: Какие вопросы не были подняты? Какие точки зрения не были представлены?)

5. Представим, что вы решили саботировать проект на этапе планирования. Составьте список наиболее действенных мер, с помощью которых можно было бы завалить все дело. (Если затрудняетесь, то представьте, что возмездие вас не волнует.)

6. Составьте список мер, которые вы в качестве руководителя, а не саботажника могли бы предпринять для предотвращения действий или в ответ на меры, перечисленные в предыдущем списке.

7. Какие в проекте были признаки осложнений, потребовавшие слишком большого внимания при планировании? Что можно было бы сделать, если вы как руководитель проекта заметили бы все эти признаки?

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

9. Должен ли специалист, составляющий требования, быть тем же самым человеком, который будет конструировать удовлетворяющее им изделие? В чем заключаются проблемы, когда один и тот же человек делает оба дела? В чем заключаются проблемы, когда этим занимаются разные люди?

Глава 4. Разработка качественных концептуальных документов

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

В главе 3 был дан краткий обзор документов планирования, где были упомянуты документы, отражающие анализ потребностей рынка (MRD), концептуальные документы и технические условия. В данной главе основное внимание уделено концептуальным документам как наиболее важной составляющей всех материалов планирования. Я объясню, почему на разработку концептуальных документов стоит потратить определенные усилия, какими качествами должны обладать лучшие образцы этих документов, как извлечь из них пользу на протяжении всего процесса реализации проекта. При правильном подходе к делу разработкой концептуальных документов завершается исходная фаза планирования (рис. 4.1).

Рис. 4.1. Готовый концептуальный документ знаменует окончание фазы планирования, так же как готовность технических условий означает окончание фазы проектирования

Прежде чем приступить к изложению темы, следует сделать одно замечание: для деления всей области, охватываемой этим документом, существует множество различных способов. В некоторых организациях вообще не используются MRD-документы или бизнес-планы, а относящиеся к ним вопросы попадают сразу в концептуальный документ. Несколько раз я принимал участие в весьма скромных проектах, где вся концептуальная информация помещалась в технические условия. Поэтому не стоит волноваться насчет количества необходимых документов и их названий: я думаю, что главное не в этом. Мои рекомендации подойдут любому используемому вами процессу планирования.

В чем ценность ведения записей

Дэниел Бурстин (Daniel Boorstin), автор великолепных работ «The Creators» (Vintage, 1993) и «The Discoverers» (Vintage, 1985), как-то сказал, что письменное слово было величайшей из всех технологий, когда-либо изобретенных человеком. Без него нам пришлось бы всецело зависеть от нашей печально известной своей дырявостью памяти,[24 - Прочтите книгу Дэниела Шактера (Daniel Schacter) «The Seven Sins of Memory» (Mariner Books, 2002) или посмотрите замечательный фильм «Помни» («Memento»). Это поможет вам осознать, сколь ограничена и ненадежна человеческая память.] занимаясь такими сложными вещами, как создание динамита (гм, в каком весовом соотношении должны быть нитроглицерин и древесный уголь?) или ядерного реактора (а куда исчезает уран?). Применительно к работе над проектом записи дают возможность однократно определить характер технической работы или зафиксировать общие для всей команды цели, а затем многократно использовать эти сведения. Документирование деталей принятых решений перекладывает с нашей памяти на бумагу все заботы о точности их формулировок и сохранности, после чего их можно восстановить в памяти, всего лишь взглянув на записи. Такая разгрузка памяти позволяет нам решать поставленную задачу полным ходом, имея под рукой ее описание, и пребывать в полной уверенности, что мы всегда, если понадобится (собьемся с курса, столкнемся с разногласиями или запутаемся), сможем вернуться к написанному. Из этого следует, что чем больше в работе сложностей и чем больше прилагаемых к ней усилий, тем выше вероятность того, что запись некоторых деталей решения повысит шансы на ее успешное выполнение.

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

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

Какой по объему концептуальный документ вам нужен?

Мне попадались концептуальные документы объемом в 50 страниц, состоящие из тщательно отформатированных результатов исследований, диаграмм и стратегических замыслов. Приходилось сталкиваться и с документами всего в пару страниц с маркированными пунктами, сопровождаемыми пояснениями, объемом в несколько предложений. Необходимая степень детализации структуры и вида документов плана зависит от характера проекта. Нужно избавиться от догмы, что документы плана – это нечто жестко заданное. В конце концов, это всего лишь документы. Степень их детализации или своеобразия зависит от сущности проекта и культуры проработки документов плана, присущей той или иной команде. Тем не менее качественно разработанные концептуальные документы, хотя и охватывают по сути одни и те же вопросы, отличаются глубиной и серьезностью подхода.

Рассмотрение следующих вопросов поможет вам определить структурную сложность и трудоемкость вашего концептуального документа:

• Много ли обоснованных вопросов имеется у самой команды относительно будущей работы? Насколько люди осведомлены о предстоящей работе и о важности ее результатов?

• Сколько разных людей будет вовлечено в реализацию проекта? Сколько различных организаций представляют эти люди? Каким образом вы сможете правильно оценить ожидаемый вклад каждой организации?

• Насколько подробно вам лично хотелось бы обосновать заложенные в концепцию решения. (Удачно составленная концепция способна сама по себе дать многим вполне достаточное представление о сути проекта.)

• В какой мере вы допускаете влияние сторонних организаций на основную направленность проекта?

• Сколько проницательности, компетентности и рассудительности потребуется от руководителя проекта при принятии ключевых проектных решений? (Очевидно, именно эти свойства будут востребованы при выработке концепции.)

• Насколько глубоко команда сможет вмешиваться в стратегию проекта в процессе работы над его реализацией?

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

• Возникнет ли в последующем необходимость напоминать команде о целях проекта? Склонны ли сотрудники возвращаться к спорам по отдельным положениям, с которыми они совсем недавно согласились?

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

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

Общекомандные и индивидуальные цели