Как извлечь пользу из проваленного проекта

Привет! Сегодня мы поговорим о фейлах.

Однажды я решил заняться развитием собственной компании, и вот уже 8 лет, как двигаюсь в этом направлении. И чем чаще спотыкаюсь и больше шишек набиваю, тем сильнее мне хочется делиться этим опытом с теми, кто столь же отчаянно строит собственную компанию. Я не претендую на истину в последней инстанции, но буду очень рад, если другим менеджерам и руководителям статья поможет преодолеть сложные этапы развития.

Иллюстрация Уляны Патоки

Что такое «фейл»

Google переводит английское fail как «провал», и это нам подходит, поэтому в дальнейшем будем использовать его именно в этом значении.

Фейлят все — и большие компании с опытом, и маленькие «зеленые» фирмы. Не фейлить невозможно. Вы не можете спрогнозировать все риски и проработать их, но даже если можете, то на это не всегда хватает времени и ресурсов; в итоге вина за провал возлагается на компанию, подписавшуюся на проект.

Можно, конечно, приводить много возражений и отмазок: клиент постоянно меняет скоуп, он не понимает, как осуществляется разработка, клиент неадекватен, таким заказчикам место на фрилансе, у клиента не тот часовой пояс или характер :)

Но все равно виновата компания!

Кто не проработал риски? Кто неправильно их оценил? Кто хотел завести проект быстрее, чтобы избавиться от бенча? Кто экономил на ролях в проекте? И так далее...

Не берите проект, если вы не уверены, что доведете его до конца.

Чтобы это понять, реально оцените свои силы: много ли в вашем окружении людей или компаний, которые смогут помочь вам, если у вас не хватит ресурсов или экспертизы. Здесь важно опереться на собственный успешный опыт, и, если вы уже преодолевали подобные челленджи, тогда все окей, ведь вы уже знаете, как это бывает.

Возможно, за вашей спиной команда, на которую вы можете опереться железобетонно.

В моем случае есть понимание своего внутреннего ресурса, и, конечно же, я могу опираться на свою команду: она уже неоднократно оправдывала доверие, ввязываясь в бой вместе со мной. Хочу сказать, что эти челленджи вынесли ребят на новый уровень и сделали только круче.

Например, иногда бывают ситуации, когда нужно брать проект на новой технологии. Тогда вы должны быть на 300% уверены, что, даже если ваши менеджеры и разработчики покинут вас, вы зарелизите проект в срок. Впрочем, это уже тема для другой статьи :)

Итак, самое правильное, что вы можете сделать, это избежать фейла.

Как не зафейлиться

Большая часть фейлов зарождается на первых фазах проекта, таких как исследование (Discovery) и/или инициализация, поэтому важно ничего не упустить. Эти фазы связаны с планированием, подготовкой и проработкой рисков, но очень часто (в спешке или из-за отсутствия оплаты) их просто опускают, полагаясь на адекватность клиента по ту сторону монитора.

Часто бывает, что, для того чтобы перекрыть бенч, приходится завести проект. Или прилетает заявка, по которой срочно нужно принять решение, брать ее в работу или нет. В таких случаях даже опытный Project Manager не всегда может все предусмотреть.

Отличный вариант, когда такое решение принимается командой как осознанная необходимость (подчеркну, именно командой, потому что в случае чего крайним потом будет один Sales Manager, искренне спасавший бюджет компании).

И совсем не отличный вариант, когда такое решение принимается на авось по принципу «лучше так, чем никак» либо когда Sales Manager невзирая ни на что хочет получить свой процент, то есть когда компания даже не делает попыток проработать риски.

Самое главное — избежать фейла. Ниже рассмотрим методы, которые помогут это сделать.

Коммуникация — слышать клиента, быть на связи, интересоваться его бизнесом и делами. Составлять в начале проекта план действий, на случай, если что-то пойдет не так. Если вы не знаете, что обсудить, скажите, что вы всегда готовы к открытым переговорам и признанию своих ошибок.

Например, обсуждая с клиентом этапы работы, сообщите ему, как будете действовать, если что-то пойдет не так, и как вы будете его об этом информировать. Скажите ему, что это нормально и профессионально, что вы считаете правильным быть в курсе того, как обстоят дела у клиента.

На одном из наших проектов у клиента заболел родственник. Менеджер, увы, не предпринял никаких шагов, чтобы уточнить, что происходит, полагая, что заказчик знает, что делает. Клиент стал реже отвечать, но и это не смутило менеджера. В итоге заказчик пропал и отказался оплачивать остаток работ, сославшись на подавленное состояние. Все закончилось хорошо, но мы потеряли время.

Управляйте ожиданиями — если что-то идет не так, говорите клиенту сразу и корректируйте его ожидания. Обсуждайте, что и как он получит. У молодых менеджеров часто бывают с этим проблемы, поскольку они боятся сообщать о неприятностях клиенту. Так вот знайте, что, если вы можете говорить подобное клиенту сразу, ничего не стесняясь, — это опыт!

Планирование и риски. Однажды на ивенте я невольно подслушал, как звукорежиссер, настраивавший оборудование для большой сцены, ругает своего молодого помощника, не следовавшего правилу «5П»: Правильное Предварительное Планирование Предупреждает Происшествия.

Если вы изучите каждое слово в контексте проектного менеджмента, с вероятностью 99% ваш проект будет спасен. Конечно, как ни прорабатывай правила, рано или поздно столкнешься с риском, который не был предусмотрен. Но вы достаточно легко с ним справитесь, если будете знать, что делать в смежных ситуациях. Собираетесь ли вы в лес на пикник или разворачиваете проект ВigData, это правило универсально. Если вы играли когда-нибудь в шахматы, это оно. Вы должны увидеть доску и просчитать все варианты ходов каждой фигуры противника.

Однажды при организации ивента в Испании возникли непредвиденные ситуации, в которых один спикер потерял чемодан, а другой — задержался на 2 дня. Хорошо, что у нас не только был проработан трансфер, но и имелась пара личных авто в запасе; они должны были отвечать за кухню, на них и забрали спикера из аэропорта. Так что проверено на себе :)

Виды фейлов

Здесь ничего нового: приходим к старому доброму тройственному ограничению из проектного менеджмента.

Сроки. Вы срываете клиенту сроки, и у него слетает заранее проплаченная рекламная компания, затягивается демо для инвесторов стартапа, или ему нужно приложение под ивент, который передвинуть невозможно

Например, бывало так, что неопытный PM сам, без согласования с клиентом, принимал решение о том, когда провести демо, а клиент, в свою очередь, сам принимал решение о приглашении на демо инвестора.

Случалось, что PM погружался в разработку на 3 дня, а на 4-й оказывалось, что клиент уже нашел сейлза и директора и пришел с претензией к PM. И тут выяснялось, что PM в это время работал не покладая рук, но не информировал об этом клиента, поэтому тот в ужасе начал менять свои планы и т. д.

На мой взгляд, управление ожиданиями на 80% закрывает вопрос сроков.

Бюджет. У клиента совсем нет денег, а проект не доделан. Так может случиться, когда у вас не просчитаны риски и не пройдена фаза Discovery проекта, а в ходе разработки вы узнаете, например, что платежная система функционирует совершенно по другому принципу. Часто случается, когда разработчик откладывает непонятные задачи на потом, а когда наступает это самое «потом» и задача становится понятной, выясняется, что API службы доставки, которую нужно интегрировать в интернет-магазин, вообще не заточена под такую интеграцию. Менеджер не отвечает за это непосредственно, потому что эта проблема технического характера, но он обязан на соответствующем митинге проработать этот риск с командой заранее.

Скоуп. Экспертиза может закончиться, и тогда решение вопроса становится непредсказуемым — и по деньгам, и по срокам. Бывает, что в ходе разработки выясняется, что клиенту, например, нужно не просто добавлять данные в таблицу, но и осуществлять их разбор, и генерировать по ним отчеты. В ходе работы вы понимаете, что это OLAP, к которому вы не знаете, с какой стороны подступиться.

Та же история: задачи, не проанализированные на ранней стадии, позже могут выйти боком. У нас был случай, когда зашел в работу большой проект и ребята оценили его как обычную CRM на Laravel. Уже после прохождения отбора в конкурсе, за день до подписания контракта, разработчики получили уточняющий комментарий клиента, что для нас означало работу с BigData + OLAP, о чём мы на тот момент знали не больше, чем о дальнем космосе и полетах спутников. Все закончилось хорошо: немного танцев с бубном — и HR + CEO + DevOps пересобрали команду, проект успешно взлетел, но понервничать нам пришлось серьезно.

Основные факторы, повышающие вероятность фейла (стейкхолдеры)

Сотрудники

Болезни. Да, люди болеют, и болеют чаще всего внезапно. Поэтому в идеале всегда должен быть второй человек, обладающий такими же навыками. Это позволит поддерживать баланс в случае чьей-нибудь болезни.

Отпуска. Менеджеры не всегда помнят об отпусках разработчиков. Некоторые люди вовсе не возвращаются из отпусков. Вот почему важно, чтобы менеджеры заглядывали в планы отпусков.

Усталость. Разработчик, давно не бывший в отпуске, будет выдавать очень низкий КПД. Важно, чтобы HR выявлял это при первых же звоночках: апатии, непунктуальности, изменении обычного поведения, грустном настроении или прохладном отношении к работе. Усталость — подлая штука, часто она приходит совершенно неожиданно, в одно прекрасное утро.

Увольнения. У сотрудников меняются жизни, на них влияют родственники, климат, законодательство — с этим ничего не поделаешь.

Фрилансеры. Это категория людей, среди которых очень маленький процент хороших подрядчиков, но они есть. И если у вас нет классного контракта, работать с фрилансером — это все равно что иметь дело с котом в мешке. Да простят меня боги фриланса!

Требования

Нет требований. О каком обещании и сроках может идти речь?

О неполных. Вы сами управляете рисками и разбираетесь в том, что для разработчиков и тестировщиков важно, а что нет. Для каждого проекта полнота требований своя, где-то достаточно хорошего мокапа, а где-то нужны функциональные требования и диаграммы use case. Главное, чтобы менеджеру и команде было на 100% понятно, что делать для достижения результата, обозначенного заказчиком.

Здесь трудно дать конкретные рекомендации. Все зависит не от проекта, а от глубины понимания задач разработчиками и остальных членов команды, но это уже определяется их опытом.

Менеджмент

«И снова здрасьте» — это менеджмент, от которого на 98% зависит возникновение фейла.

Нет backlog’a — нет оценки и приоритетности задач. Как следствие, нет плана движения и сроков по проекту. Всегда прикидывайте объем задач, сопоставляйте, насколько вы в него вписываетесь, и информируйте клиента о малейших возможных рисках.

Нет трекинга — менеджер не следит за состоянием задач, не проводит ежедневные 15-минутные митинги. Если менеджер теряет понимание происходящего, компания начинает терять время и деньги.

Нет управления ожиданиями — клиента не вводят в курс происходящего (как позитивного, так и негативного), в итоге заказчик вообще ничего не понимает. Даже если вы решите не посвящать клиента в трудности проекта из благих побуждений, позже он будет удивляться каждой заминке и считать вас непрофессионалами.

Когда фейл настал

Четыре пункта, описанных ниже, очень хорошо работают в моей практике. Из них можно сделать roadmap и смело использовать.

1. Признать и взять ответственность. Поверьте, не нужно спорить, это не приведет ни к чему хорошему. Может, на 10%, на 50%, 80%, но ответственность перед клиентом нужно принять, стиснув не только зубы, но и все места, которые можно стиснуть.
2. Написать отчет, почему это произошло. Написать недлинный отчет клиенту о том, что привело к этому фейлу. Желательно так, чтобы отчет содержал понятные клиенту процессы. Это убедит клиента в том, что вы понимаете ситуацию, его беспокойство и можете контролировать происходящее.
3. Обозначить конкретные шаги и сроки. Обсудите шаги, которые нужно предпринять, и сроки их выполнения. Даже если вы еще не знаете, что делать, добавьте риски и заложите время на ресерч, но выдайте клиенту конкретику. Хорошо работает демонстрация позитивного и негативного сценариев, с ориентацией клиента на негативный. Он скажет, что понимает вас, но все равно будет думать о позитивном: так ему легче. В результате клиент убедится в том, что вы эксперт и знаете, что делать. Это успокоит его.
4. Стать более внимательным. Теперь, пока вы не разберетесь с фейлом, следует быть максимально внимательным. Разумеется, не нужно звонить клиенту утром и спрашивать, как он себя чувствует и не остыл ли его кофе, но всю информацию по проекту важно доводить до ведома заказчика максимально быстро.
   Бояться также не стоит: терять вам уже нечего — можно только приобрести.

Рассказывайте клиенту о каждом маленьком прогрессе. Чем чаще вы будете его информировать, тем скорее у него появится ощущение, что ситуация под контролем, и он успокоится.

Глазами клиента

Клиенту важно знать, что он получает. В тот момент, когда вы сорвали проект, реализовав который клиент хотел спасти мир, он утрачивает понимание того, что происходит, а заодно и доверие к вам, и начинает ощущать себя обманутым. Поэтому важно всегда сообщить ему, что он получит, без общих фраз. Клиента пугает отсутствие конкретики, потому что он бизнесмен, а значит, у него есть план развития. И когда вы фейлите проект, то вы тем самым подрываете его план спасения мира.

Где искать чудо и бюджет

Теперь нужно разобраться с ситуацией, когда вам страшно, неясно, что делать, а в голове все время вспыхивают вопросы: кто это будет фиксить? за какие деньги? в какие сроки?

Ответ прост: чудо наступает после того, как вы возьмете на себя ответственность за происходящее и проявите вовлеченность в проект. Вы начинаете видеть, что клиент тоже человек, и даже если он и не идет вам навстречу, то подстраивается и помогает.

Клиент компенсирует бюджет, если он увидит, что вы вложились в его проект по полной. Когда работа будет закончена, отправьте ему письмо, в котором в цифрах будут указаны ваши затраты на устранение этого фейла. Это вызовет уважение к вам, клиент увидит, сколько ресурсов вы вложили. Предложите ему покрыть часть этих расходов настолько, насколько он считает справедливым.

В нашей практике клиенты покрывают от 50% этих работ.

Давайте подытожим, как обернуть ситуацию себе на пользу

1. Принять в ней максимум участия и ответственности. Это поддержит клиента.
2. Продолжать демонстрировать результат. Это придаст клиенту уверенности.
3. Закончить проект. Это создаст клиенту ценность, а вам вернет репутацию.
4. Отправить смету. Это увеличит вероятность, что клиент оплатит часть расходов.
5. Ретроспектива и выводы — вишенка на торте — покажут вашу системность. Отправьте результаты ретроспективы клиенту.

Совсем немного нашей собственной 7-летней статистики:

• 70% клиентов возвращается после выруливания ситуации;
• более чем 50% бюджета, ушедшего на устранения фейлов, покрывается в благодарность за вашу ответственность.

На личном примере

Напоследок рассмотрим кейс, имевший место в работе нашей компании.

О проекте

Достаточно большой проект, агрегатор национального масштаба. Стек технологий: Laravel + SPA + SSR.

Что произошло

После смены нескольких команд разработчиков в течение полугода возник коллапс с багами. PM не вытянул, не смог найти общий язык с клиентом, начал хитрить и перегружать разработчиков команды бестолковыми заданиями.

Как отреагировал клиент

Клиент выдвинул ультиматум — окончить работу. Затем подключил сторонних разработчиков, да еще и фрилансеров, в итоге количество багов только возросло.

Как разрулили

Заново собрали команду, усилив ее техлидами и более опытными сотрудниками. Создали план выхода из кризиса и согласовали его с клиентом понедельно. Обсудили объем работ и назначили клиенту дату, когда будет устранено 80% ошибок.

В общем, спасибо, что дочитали. Помогайте клиентам, не бросайте их у разбитого корыта или проекта. Ведь им страшнее и сложнее, чем вам. Любите свою работу и служите людям!