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

Список вопросов

Список вопросов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оглавление книги