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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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