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