5 способов провалиться при ведении IT проекта
Ничто так быстро не приближает проект к провалу, как слабая команда и нереалистичные планы. Джоэл Спольски рассмотрел причины, приближающих команду разработчиков программного обеспечения к провалу. Будет полезно познакомить всех читателей нашего журнала с основными моментами этой статьи – с 5 шагами, которые загубят команду разработчиков.
Пожалуй, одним из крупнейших софтверных провалов с точки зрения менеджмента, за последнее время, стала операционная система компании Microsoft Windows Vista. И вовсе не потому, что она была прохладно встречена прессой и пользователями. Проблема крылась в том, что данная ОС была лишена чуть ли не основной своей функции, о которой говорили за несколько лет до ее выхода – революционной файловой системы WinFS, которая должна была позволить по-новому взглянуть на файловые системы, как таковые. О данной системе говорили еще в 2003 году. Увы, в Windows Vista она не вошла. При этом многие полагают, что WinFS была не последней причиной того, что Microsoft серьезно подвинула сроки выхода Vista. Ну а итог всем известен – софтверный гигант отказался от новой файловой системы. Итак, вот 5 основных моментов, приводящих софтверные команды к провалу:
Ошибка № 1: Начать с посредственной командой разработчиков
Проектирование программного обеспечения – трудная задача, и, к сожалению, многие люди, которые называют себя программистами, не могут это делать. Увы, начать проект с неправильными людьми – это катастрофа для софтверного проекта (кстати, это актуально почти для любого проекта). При этом далеко не всегда удается понять, что это действительно команда виновата в неудаче. А еще сложнее исправить положение, ведь здесь придется увольнять людей, что, во-первых, не так просто (и очень дорого), а во-вторых, это далеко не всегда спасет проект. Как избежать данной проблемы? Отбирайте правильных людей. Тех, кто действительно сможет поднять проект. Тщательно отбирайте каждого сотрудника в команду. Только при таком подходе вы сможете добиться успеха в этом деле (межу прочим, знаменитый (но весьма спорный) менеджер Джек Уэлч всегда полагал, что именно команда определяет успех проекта).
Ошибка № 2: Недельные контрольные точки
Представьте, что вы решили перестроить свою кухню. Вы нанимаете парня, который уже создал множество кухонь перед этим, и вы можете познакомиться с результатами его работы (обычно в таких ситуациях человека нанимают через знакомых, зная, что тот уже сделал кухню им). Но с разработкой программного обеспечения совсем иная ситуация. Программисты создают любой продукт впервые. Если бы у них была бы возможность создать его ранее, то они бы принесли его вам на CD-диске. Поэтому приблизительные оценки здесь невозможны.
Команда нуждается в детальном плане перед началом работы. Если вы являетесь менеджером проекта, то должны предоставить им такой план. И вы должны быть уверены в том, что они будут работать именно по этому плану. Если вы обратитесь к разработчикам, то они разобьют план на недели. Это может показаться отличными решением, но оно таковым не является. План должен быть расписан по дням (и это актуально не только для софтверного проекта, но и для многих других).
Ошибка № 3: Согласование сроков
Программисты по природе своей являются оптимистами. Вы можете легко договориться с ними о сокращении сроков. Но есть одна важная проблема – договориться, конечно, можно, но эти сроки никогда не будут выполнены. Увы. Представьте себе ситуацию с беременной женщиной. Она должна родить через 9 месяцев. Вы можете упрашивать ее сделать это через 5, но это невозможно. Она все равно родит через 9. Такая же ситуация и в мире разработки программного обеспечения. Программисты могут договориться с вами о сроке на разработку продукта не за 10 месяцев, а за 5, но тогда они просто сорвут сроки на 5 месяцев.
Излишняя оптимистичность относительно сроков выполнения проекта характерна не только для программных проектов, но и для многих других. К сожалению, бороться с этим очень сложно. Нужен действительно квалифицированный менеджер, способный справиться с этой ситуацией и выдать реалистичные сроки.
Ошибка № 4: Справедливое разделение задач
Такая ситуация может серьезно ударить по срокам проекта. Представим, что у Марии огромное количество задач, и она не выполнила некоторые из них. В это же время программист по имени Джон получил заметно меньше работы и теперь у него есть свободное время. Разве не разумно, передать ему часть работы Марии, чтобы освободить ее? Ответ прост: это не просто не разумно, но и губительно. Все дело в том, что Мария разбирается в своем коде. В отличие от Джона, которому потребуется много времени на то, чтобы понять, что сделала Мария. К тому же девушка знает обо всех проблемах и ловушках данного кода, так что гораздо быстрее сможет редактировать его и добавлять к нему какую-либо функциональность, чем Джон.
На самом деле подобная проблема может возникнуть не только в мире программного обеспечения. Да, делегирование полномочий – важная штука, но далеко не всегда удачная для конкретной ситуации. Иногда может получиться, что вы гораздо быстрее выполните задачу сами, нежели отдадите ее другому человеку, которому придется вникать во все аспекты деятельности.
Ошибка № 5: Работать до полуночи
Эдвард Йордон (автор нескольких книг по ИТ-менеджменту) назвал это марафоном смерти. Суть достаточно проста. Представьте себе ситуацию, когда команде необходимо работать по 40 часов в неделю в течение 6 месяцев для завершения проекта. Определенно может возникнуть соблазн закончить проект в более короткие сроки – например, за 4 месяца, работая при этом по 60 часов в неделю (если рабочая неделя пятидневная, то это означает, что люди будут работать по 12 часов в день). Если смотреть на бумаге, то идея отличная! Главное придумать, как уговорить людей столько работать. Но на самом деле это путь в никуда. Программирование – это интеллектуальная деятельность. Практика показывает, что даже самые лучшие программисты не могут интенсивно работать более нескольких часов в день. Это правда жизни. И тот факт, что они будут сидеть на работе до полуночи, просто приведет к тому, что в проекте будет гораздо больше ошибок и неточностей, которые и придется исправлять следующие два месяца.
Возможно, данная ситуация может проецироваться и на другие профессии и команды. Вывод достаточно прост и банален – много работать не всегда хорошо. Иногда это только вредит проекту.