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