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

Недавно моя команда, занимающаяся разработкой веб-приложений, упражнялась в планировании преодоления нештатных ситуаций. Мы собрались всей группой за столом, составили краткий перечень всевозможных неурядиц, а затем попытались провести мозговую атаку, чтобы понять, как на них реагировать. (Это было настолько забавно, что всем вам нужно как-нибудь попробовать заняться тем же самым.) Одна из придуманных нами ситуаций вызвала наибольшее количество споров: «За три недели до наступления очередного контрольного срока вашего лучшего программиста сбил автобус, и он впал в кому. По дороге из больницы в офис вы пытаетесь понять, что же делать дальше. Чтобы вы сделали и как бы преподнесли свои решения своей команде?»

Наш поезд идет под откос

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

Борьба с излишней функциональностью

Мы имеем дело с программным продуктом для ведения бухгалтерского учета версии 3.0. Продукт уже обладает многими общепринятыми и важными функциями, и его конструкция приобретает вполне зрелые очертания. Но возникает ситуация, при которой вся команда (специалисты по бизнесу, маркетингу, а заодно с ними и разработчики) поддается общему настроению по продвижению эффектных по виду, но второстепенных по назначению функций, которыми люди, возможно, если и воспользуются, то не более одного-двух раз. Мне уже приходилось наблюдать подобное «раздувание» функций в других проектах, и в данном случае на лицо все те же признаки. Мы превращаемся из организации по разработке программных продуктов в некую «ферму» по разведению новых функций. И всем видится в перспективе история, как в фильме «Ганг Хо». Как мне добиться того, чтобы в версиях 3.0 и 4.0 вся хорошая работа, сделанная в предыдущих версиях, не были похоронена под грудой функций и прочего хлама, родившегося в силу чьих-то предпочтений или продиктованного какими-то маркетинговыми ходами? Как проектирование может и дальше содействовать основному бизнесу, не превращая кодирование продукта и разработку его потребительских свойств в некую зону бедствия?

Стиль совещания, напоминающий чемпионат по борьбе

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

Итак, вопрос заключается в следующем: какую роль должен играть руководитель проекта при выборе основных проектных направлений? Что должны делать руководители проектов, отслеживать ход реализации проекта и всячески содействовать этому процессу или возглавить весь процесс? А если они его возглавят, то в какой степени они должны быть причастны к проектированию программного продукта или веб-сайта?