Проработав длительный срок в IT-сфере, начинаешь понимать, что как бы ты ни хотел, часть проектов проваливается. По оценкам некоторых экспертов, количество таких проектов доходит до 60%. Перефразируя классика, можно сказать, что все успешные проекты успешны одинаково, а каждый провальный - провален по-своему. В каждом случае можно найти свою ключевую причину провала. Вот некоторые из них:
1. Нереальные проектные сроки и бюджет
«…менеджера по маркетингу вряд ли особенно волнует реалистичность предлагаемого им плана и бюджета, поскольку его основная цель - получить комиссионное вознаграждение или доставить удовольствие своему боссу». Эдвард Йордан, «Смертельный марш».
2. Непрофессионализм участников проектов
«Все компании, предоставляющие услуги в ИТ, становятся жадными и пытаются расти быстрее, чем могут находить талантливых людей…». Джоэл Спольски, «Джоэл о программировании».
3. Политические интриги вокруг проектов
«…отличительной чертой безнадежных проектов является настолько сильное влияние политики, что она может свести на нет все усилия выполнить хотя бы какую-нибудь работу». Эдвард Йордан, «Смертельный марш».
4. Изменчивость требований к системам в ходе выполнения проектов
«Одной из самых распространенных причин неуправляемости проектов являются изменчивые требования». Роберт Гласс, «Факты и заблуждения профессионального программирования».
Причины разные, итог один – провал. Но он не приходит сразу. Провал терпеливо ждет своего часа, отмечая промахи, проблемы, конфликты, срывы сроков и другие свидетельства своего неизбежного торжества. Причины провала присутствуют, как правило, с самого начала проекта, но вряд ли кто-то готов закрыть проект на старте. Ведь главное - ввязаться в драку. Но чем больше усилий и (денег!) уходит на проект, тем меньше шансов его закрыть. Возникают все новые и новые проблемы, в которые вовлекается все больше средств и людей. Каждый член проектной команды самоотверженно включается в борьбу. Преодоление уже становится самоцелью: дорога – все, цель – ничто. Думаю, что и вам не раз приходилось наблюдать типичные этапы развития провального проекта.
Этапы развития провального проекта
- Сроки предоставления технического задания начинают затягиваться. Беспокойства нет – это бывает.
- Техническое задание представлено на согласование. У Заказчика возникает легкое недоумение - в документах слишком много «воды», часть требований не соответствует тому, что обсуждалось с проектной командой. Начинается процесс согласования. Все полны решимости быстро устранить недочеты.
- Процесс согласования технического задания затягивается. Появляются первые признаки беспокойства в связи с нарушением сроков. К этому относятся с пониманием, ведь важны не документы, а сама система.
- Подошел срок поставки первого релиза системы, который Исполнитель должен установить на оборудование Заказчика. Исполнитель сообщает, что все готово, но нужно подождать еще пару дней.
- Установка системы идет полным ходом, но пока безрезультатно. Систему должны были установить еще две недели назад.
- Сроки согласования ТЗ давно прошли, но это уже не очень волнует. Озабоченность связана с тем, что никак не удается наладить систему.
- Система установлена, но работает плохо. Часть функционала не реализована совсем, часть реализована не так, как ожидалось, и все равно не работает из-за большого количества ошибок. Недовольство Заказчика нарастает.
- Устанавливаются новые релизы системы, но каждый следующий релиз работает не лучше предыдущего. Протоколы встреч уже не ведутся. Встречи превратились во взаимные претензии. О том, что техническое задание до сих пор не согласовано, уже никто не вспоминает.
- Составляются длинные списки ошибок системы, которые нужно устранить. Новые релизы системы содержат исправления новых ошибок, но обнаруживаются старые ошибки, которые были исправлены ранее в предыдущих релизах.
- Исполнитель требует начала опытной эксплуатации системы и подписания актов приемки, но пользователи отказываются работать в системе, так как она им не нравится и часто падает.
- Акты приемки этапа разработки технического задания подписываются с обещанием Исполнителя исправить все позднее.
- Запаздывание проекта уже составляет 30% - 50%. ТЗ согласовывается задним числом.
- Установлены, наконец, все компоненты системы. Основные критические ошибки исправлены, но работать в системе невозможно из-за неудобства функционала.
- Заказчик просит переделать функционал. Исполнитель не соглашается без дополнительной оплаты, так как функционал разработан согласно ТЗ. Заказчик отказывается принимать систему. Идет долгий период непонимания, что делать с системой.
- Происходят изменения на стороне Заказчика (меняются люди/процедуры/процессы и тому подобное). В связи с произошедшими изменениями становится понятно: чтобы хоть как-то начать работать в системе, ее нужно переделать в соответствии с произошедшими изменениями. Заключается дополнительное соглашение на доработку системы. Чтобы не потерять лицо, руководство договорилось объявить о новом этапе проекта.
- Идет длительный этап доработки. Сроки превышены уже в два раза. Сотрудники Исполнителя и Заказчика устали от проекта, но не знают, как его прекратить. На проекте меняется руководитель проекта Исполнителя и часть проектной команды. Новая проектная команда заново собирает требования.
- Заказчик понимает, что существующая система работать не будет. Старая технология работы кажется уже не такой плохой, по сравнению с новой системой. Заказчик максимально тормозит внедрение системы, не зная как выйти из этого внедрения.
- Идет долгий процесс переговоров. В результате стороны договариваются о приемке системы. Размер денежного вознаграждения Исполнителю существенно снижен. Акты закрываются. Провал не нужен ни одной из сторон, поэтому по молчаливому согласию проект считается успешным.
- Выходит пресс-релиз об успешном внедрении системы.
Вот он, наконец, долгожданный финал. То есть вроде бы не провал. Но мы-то знаем…
К чему были все эти бессонные ночи, мешки под глазами, ссоры с коллегами, убийство нервных клеток, если система все равно не работает, премий нет, а ожидаемая профессиональная удовлетворенность так и не наступила? Потрачен огромный бюджет, а что мы получили в итоге?
«Как сказал мне старый раб перед таверной:
'Мы, оглядываясь, видим лишь руины'.
Взгляд, конечно, очень варварский, но верный».
И.Бродский
А ведь было бы гораздо эффективнее направить усилия на благородное дело - сохранение средств родной компании при сохранении собственного здоровья и душевного равновесия. Иными словами – не пытаться спасти проект, а, наоборот, утопить его как можно раньше. Уверен, что вы уже знаете или догадываетесь, как это сделать.
Что необходимо сделать, чтобы провалить проект наиболее результативно.
- Изучите перед проектом резюме специалистов проектной команды Исполнителя. Отвергайте кандидатуры сотрудников до тех пор, пока вы не убедитесь в следующем:
- Вам представлены наиболее молодые сотрудники компании Исполнителя, пришедшие в команду недавно и не имеющие проектного опыта.
- Сотрудники проектной команды никогда прежде совместно не работали.
- Профиль специалистов проектной команды максимально далек от вашей предметной области, а архитектура предложенного решения не соответствует инфраструктуре компании.
- Руководитель проекта Исполнителя запуган и ведет себя неуверенно.
- Проекты, которые выполняли сотрудники проектной команды, не были завершены или завершены неудачно.
- Поставьте нереально сжатые сроки проекта.
- Определите максимальное количество проектных документов, требующих согласования.
- Составьте предельно длинный список сотрудников, согласующих проектную документацию с вашей стороны.
- Затягивайте согласование технического задания. Отказывайтесь подписывать проектные документы, ссылаясь на несоответствие ГОСТам, внутренним стандартам вашей компании, слабую детализацию или несоответствие бизнес-процессам.
- Постоянно изменяйте требования к системе.
- Чаще проводите ротацию сотрудников вашей проектной команды и предметных специалистов.
- Если почувствуете, что проектная работа, тем не менее, начала стабилизироваться, попросите заменить проектную команду Исполнителя по причине срыва сроков этапов проекта. Начните вновь, с пункта 1.
Согласитесь, все это сделать гораздо проще, чем погибать за проект. При этом вы ничего не теряете. Провал проекта – это уже не провал, а ваш успех. А если проект все же завершен успешно, система внедрена, значит это действительно хорошая система, которая закалилась в борьбе благодаря вам. Вы в любом случае остаетесь в выигрыше. И может быть даже с премией. За успешно выполненный проект или как результат экономии средств вашей компании.
Удачи на проектах!
статья, безусловно, хороша! и юмор и сарказм присутствуют. Сам автор, видимо, пережил не один проект. К советам можно добавить:
- никогда не смотрите как делают то же самое конкуренты
- платите всегда, а за что не спрашивайте
- мнение Исполнителя всегда важнее мнения будущих пользователей, поэтому лучше вообще не спрашивать мнения пользователей
- Исполнитель еще на этапе предпроектного исследования знает, что в итоге получится у Заказчика, и лучше с этим смириться за названную цену, а то выйдет дороже
- не берите в команду пессимистов - слишком часто сбываются их мрачные предсказания
Статья мне категорически НЕ ПОНРАВИЛАСЬ!
Я бы назвал ее (статью) – «дурацкой». А как иначе…
Описывается взаимодействие ЗАКАЗЧИКА неизвестно зачем устанавливающего у себя систему и не в состоянии определить цель и требования к системе, для краткости назовём ЗАКАЗЧИК-дурак.
С другой стороны ИСПОЛНИТЕЛЬ, который не знает цели, требования заказчика, не понимает проблемы заказчика, и при этом, БЕРЁТСЯ делать ЧТО-ТО :!: не зная что. Для краткости назовём ИСПОЛНИТЕЛЬ-дурак.
Так вот, автор описывает взаимодействие одного «дурака» с другим «дураком» и смакует их «дурацкие» проблемы.
Заканчивает автор статью «дурацкими» (в смысле для дураков) советами.
Ну как НЕ НАЗВАТЬ эту статью «дурацкой» и вредной как для НОРМАЛЬНЫХ исполнителей, так и для НОРМАЛЬНЫХ заказчиков???
Почему считаю статью ВРЕДНОЙ?
1. Она не дает советы НОРМАЛЬНЫМ участникам процесса.
2. Она не указывает НОРМАЛЬНЫМ исполнителям и заказчикам на «подводные камни» и не показывает, как избежать неприятности.
3. Она ничему не учит!
Но если кто и прочел статью до конца, то мой (личный) совет – не будьте дураками!!
Могу порекомендовать к чтению (есть в интернете):
Автор : Эдвард Йордон
Название книги : Путь камикадзе [Смертельный марш]
Аннотация :
Книга Эдварда Йордона «Путь камикадзе» представляет собой полное руководство по выживанию в безнадёжных проектах, предназначенное для разработчиков программного обеспечения. Практически каждому разработчику ПО и менеджеру приходится сталкиваться с проектами, характеризующимися никуда не годными персоналом, планом и бюджетом, т.е. проектами, обречёнными на неудачу. В условиях реинжиниринга корпораций безнадёжные проекты становятся «стилем жизни» многих организаций. Книга Эдварда Йордона является руководством по решению следующих проблем: выживание в проектах, обречённых на неудачу; достижение оптимальных соглашений во время переговоров; управление персоналом и расстановка приоритетов; выбор средств и технологий; определение момента, когда уже пора выйти изпроекта. Эдвард Йордон применяет свою уникальную технологию и интуицию менеджера к наихудшим вариантам софтверных проектов, показывая, как максимально повысить шансы на успех, или, по крайней мере, вывести вашу карьеру из-под удара. Шаг за шагом Йордон проходит все стадии жизненного цикла проекта, учит менеджеров и разработчиков правильно вести себя с заказчиками и оптимально использовать доступные ресурсы, включая людей, средства, процессы и технологию. Учитесь проявлять необходимую гибкость при проведении переговоров, расставлять осмысленные приоритеты и… вовремя выходить из проекта. Если вам когда-либо требовалось совершить невозможное, «Путь камикадзе» – ваша книга.
Дата : 1997