Читать онлайн «Искусство управления IT-проектами». Страница 51

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

Вот мой перечень вопросов, пересмотр и дополнение которого только приветствуется.

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

• Где самые узкие места проекта? Каковы самые слабые компоненты или элементы интерфейса? Почему они не могут быть улучшены?

• В чем самые сильные стороны проекта? В чем самые слабые? В чем мы более-менее уверены? Проецируются ли сильные стороны и уверенность в успехе на наиболее важные компоненты?

• Приемлем ли уровень качества? Будет ли конечный продукт столь же надежен, производителен и полезен, как того требует концепция проекта? Являются ли реалистичными тестовые оценки?

• Не лучше ли упростить замысел? Неужели нам на самом деле нужна такая сложность и функциональность? Какие у нас основания или веские аргументы против упрощения конструкции?

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

• Какие элементы замысла, скорее всего, могут подвергнуться изменениям? Почему?

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

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

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

• Удалось ли нам добиться соответствия требованиям относительно доступности и локализации пользовательского интерфейса?

• Каковы угрозы безопасности данного проекта? Почему бы их не устранить? Задокументированы ли эти угрозы в технических условиях, включая потенциальные средства восстановления (например, есть ли модели угроз)?

• Располагаем ли мы достоверными доказательствами, свидетельствующими о том, что конкретные пользователи могут успешно работать с данным интерфейсом?

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

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

• Удачно составленные технические условия отличаются простотой. Прежде всего они являются формой организации взаимодействия.

• Составление технических условий в корне отличается от проектирования как такового.

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

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

• Проведение обсуждения – простейший способ определения уровня технических условий и контроля их качества.

1. Возьмите большой набор элементов LEGO-конструктора и пригласите другого руководителя проектов. Разделите элементы на две кучки с одинаковым количеством и типом элементов. Сядьте друг к другу спиной, а затем кто-нибудь из вас пусть соорудит какую-нибудь конструкцию (неважно, какую именно). Как только она будет готова, ее создатель, пользуясь только словами, должен проинструктировать своего коллегу, как создать точно такой же объект. Сравните результаты. Затем повторите все сначала, поменявшись ролями.

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

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

4. Изобразите что-нибудь из привычных и заученных действий, вроде завязывания шнурков, установки будильника или запуска DVD. Запишите, как вы это делаете, чтобы кто-нибудь мог последовать вашим инструкциям. Сделайте набросок, иллюстрирующий ваши действия. Попробуйте в точности последовать тому, что вы написали, или попросите об этом кого-нибудь другого. Обратите внимание на результаты, пересмотрите инструкции и повторите попытку.

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

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

7. Вам знаком какой-нибудь человек, увлеченный Visio, UML или другими инструментальными средствами? Есть ли у вас доказательства, что эта увлеченность приводит к созданию плохих технических условий? Сделайте для команды полезное дело: организуйте протест против применения Visio. Пригласите всех, кто пользуется его техническими условиями, соберите их подписи под петицией об ограничении использования документов, созданных с помощью Visio, и передайте эту петицию руководителю проекта. Приобщите к ней список, какие технические условия могут и не могут быть выполнены с помощью инструментальных средств.

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

9. Представьте себе следующий сценарий: вы создали великолепные технические условия, с замечательными иллюстрациями, ясным изложением и полной документацией. Но вашим лучшим разработчикам они не понравились. Им не понравилось не только, как они написаны, но и идеи, которые в них представлены. До сдачи технических условий осталось только два дня. Что нужно сделать? Что можно сделать в следующий раз, чтобы предотвратить подобную ситуацию?

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

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