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

Стоит ли следовать инновациям?

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

Мой босс – любитель покрасоваться

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

Соблюдение краткости совещаний

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

Смерть в результате несчастного случая

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

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

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

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

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

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

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

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

Самодельный или готовый продукт

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