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

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

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

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

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

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

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

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

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

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

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

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

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

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

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