Стоп, хватит, немедленно удаляйте! Для того, чтобы закрыть провальный проект, нужны две вещи: нужно понять, что проект провалился, и его нужно закрыть.
Но это не так просто.
Данная статья написана на основе отчета Мария Белкина от SEMrush, с OKR-митап в Санкт-Петербурге : «Опыт перехода с OKR на Spotify Rhythm».
Хотя название доклада претендует на демонстрацию недостатков OKR, преимуществ Ритма и способов замены одного другим, основной темой стал вопрос: «Что делать с провалившимися проектамиЭ» Это острая и болезненная тема, в которой интересно разобраться.
Культура стартапов ориентирована на успех.
Если вам удастся достичь своей цели, нужно продолжать в том же духе.
Но не все проекты успешны; в большинстве случаев достигаются лишь посредственные результаты или даже хуже.
Что происходит с такими проектами? - Они продолжают. Всем: и руководству, и исполнителям гораздо проще продолжать вкладывать усилия в неудачный проект, чем признать его провал.
Эскалация проблемы может привести к конфликту в коллективе, что может испортить отношения с коллегами.
Это никому не нужно.
Но если ничего не делать, разработка увязнет в бесперспективных проектах, а продукт превратится в неподдерживаемый набор бесполезных функций.
Это тоже нехорошо.
Деньги всегда важны, но ключевой ресурс развития – это люди.
За месяц работы группа из ста человек сожжет одинаковое количество денег независимо от результата.
Конечно, организация наилучшего результата – главное в управлении развитием.
Но когда приходит новая идея: «Вот что нам нужно сделать!», зачастую оказывается, что взяться за нее некому.
Все разработчики заняты текущими задачами, причем не самыми важными, но бросать их нельзя.
Это типично для зрелого продукта.
Чем старше программный продукт, тем большая доля ресурсов тратится на его поддержку и тем медленнее идет новая разработка.
Даже если двести из ста тысяч пользователей воспользуются функцией, ошибку в ней все равно придется исправлять.
Внедрение новых технологий потребует исправления всего кода, независимо от того, вызывается ли метод каждую миллисекунду или раз в месяц.
Лучше завершить начатый проект, чем оставить его незавершенным.
Любые глобальные изменения потребуют полного тестирования и так далее.
Все это немного отрезвляет и заставляет критически задуматься о перспективах.
Не все проекты будут успешными, это реальность.
С этим можно жить, но в какой-то момент руководство должно понять, что оно не может просто продолжать бросать игрушки на пол.
Периодически их нужно убирать обратно в коробку, иначе будет бардак.
Да, наводить порядок – это скучно.
Да, это требует времени.
Да, кто-то может расстроиться, что любимую игрушку положили обратно в коробку.
Но мы взрослые.
Что значит закрыть неудавшийся проект? Речь идет не только о списании десяти человеко-лет работы как убыток.
Весь разработанный функционал также необходимо удалить из продукта, а это дополнительная работа и дополнительные затраты.
Будут и недовольные пользователи, которым по каким-то причинам понравился функционал проекта.
Не забывайте об упущенных возможностях.
Время и силы, затраченные на закрытие проекта, кажется, можно использовать с большей пользой.
Закрытие проекта обходится дорого.
Для такого шага требуется воля, решимость и понимание того, что долгосрочное здоровье продукта важнее тактической экономии.
Но даже если есть готовность применить столь радикальные меры, все равно нужен спусковой крючок, нужен способ понять, что проект провалился.
Критерии провала проекта.
Обычно принято определять критерий успеха.
Казалось бы, если критерии успеха определены, а проект их не достигает, то он провалился.
Точно нет. Между успехом и неудачей существует большая серая зона.
Не дотягивая до показателей, определяющих успех, всегда возникает ощущение, что «мы просто еще недостаточно сделали», «еще немного, и тогда все получится».
Возможно, это правда.
Но оценка проекта по критериям успешности ставит лишь вопрос «продолжать или нетЭ», а такой вопрос не предполагает ответа «закрыть и уничтожить!» Критерием провала проекта является нижняя граница показателей, ниже которой проект должен быть уничтожен.
Точно так же, как корабль, получивший пробоину ниже ватерлинии, должен пойти на дно.
Со всей возможной гордостью, величием и профессионализмом.
Как успех не должен вызывать зависть, так и неудача не должна разжигать ненависть в коллективе.
В долгосрочной перспективе это все рутинная работа.
Чтобы гарантировать, что провал проекта не приведет к конфликту, критерии провала должны быть определены и согласованы заранее, а также критерии успеха.
Также план завершения проекта необходимо подготовить заранее, даже раньше, чем план самого проекта.
Тогда, определив, что проект провалился, не останется сомнений, что и как делать в этой ситуации.
Можно будет сразу перейти к решительным действиям.
Все по-взрослому.
Разумно утверждать, что наш мозг устроен таким образом, что, заранее думая о неудаче, мы настраиваем себя на неудачу.
Может быть.
Но способность думать о последствиях – признак зрелости мышления.
И трудности, связанные с этим, похоже, преодолимы.
Дмитрий Мамонов, Райк P.S. Продолжая тему как, зачем и когда удалять фичи из продукта, могу порекомендовать отчет от моего коллеги Юрия Андрейковича.
Теги: #Управление разработкой #Управление проектами #agile
-
Как Увеличить Продажи В Интернете?
19 Oct, 24 -
На Сколько Rss-Каналов Вы Подписаны?
19 Oct, 24 -
Итого — Мы Верим В Бога!
19 Oct, 24 -
У Обамы Будет Новый Смартфон: Модель Анб?
19 Oct, 24
