Как оценить проект и не попасть впросак?

Самое высокое, недостроенное здание в мире. Где ошибся менеджер?

Корпорация из штатов открыла тендер на миграцию продуктового решения с джавы на “современную” платформу. Компания, в которой я тогда работал, с удовольствием приняла вызов и выделила pre-sale команду из менеджера (меня собственно), сейлза для общения с клиентом, разработчиков и разработчиков, тестеров, дизайнеров по требованию. Сроки – адские. Мы запрыгнули в этот поезд последними и оказались в чудной компании маленьких индусских компаний всего по 5-10 тысяч человек. На входе – RFP в 10 страниц и один кикоф звонок с клиентом. По итогу недели надо выслать видение миграции проекта. В общем, предстоял марафон, где главным риском было не убить сердце килограммом-другим кофеина.

Других проектов с меня не сняли, и работать нужно было над присейлом или в свободное время или по вечерам. В такой ситуации я умудрился и успел сделать нормальную версию эстимейта за 4 дня (потом еще месяц поил пивом разработчиков за эту скорость). Но, даже не смотря на то что я свою работу сделал, другие члены команды подошли к вопросу спустя рукава и на 4 день оказалось, что рискуем просто не отправить клиенту предолжение от которого нельзя отказаться. А значит 3 дня моей работы и все счета в барах пойдут прахом.

В итоге, я остался в офисе и провел очень длинную последнюю ночь за тремя мониторами, параллельно верстая пропоузал, забивая в MS Project всю WBS, чтобы получить внушительные gantt-графики и выверяю формулировки технического решения.

Было ли это “геройство” оправданным? Стоил ли забег результата? Стоило ли вообще браться за такой эстимейт? Отвечу на эти вопросы дальше в посте.

***

Дисклеймер. Пост написан для руководителей проектов работающих в аутсорсинговых компаниях малого и среднего размера. В посте не будут рассмотрены продуктовые компании или как делать эстимейт для энтерпрайза. У меня такого опыта нет.

Не буду рассказывать что такое estimate, quote, RFP, в чем отличие Preliminary от Accurate. Кмон, если вы нашли эту статью, значит знаете базу, если не знаете – оставьте комментарий под статьей, могу собрать другую статью, про самые-самые основы.

***

Требований может быть самый минимум или они будут противоречить друг другу. Времени всегда в обрез, а экспертность оценщиков хромает. Знакомо?Давайте обсудим основные отмазки и блокеры с которыми менеджеры, особенно молодые, сталкиваются в работе над эстимейтами. Хочу выделить 5 вещей:

  • Оторванность от процесса
  • Сомнительная экспертность команды
  • Агрессивные сроки
  • Мало требований на входе
  • Оценивают одни, а делают другие

Отмазка: Оторванность от процесса pre-sale

Менеджеры занимаются эстимейтами, но не видят всей картины и оторваны от процесса pre-sale. ПМ получает задачу на оценку и старается ее как можно быстрей запроцессить, выполнив основные формальные требования. Что будет дальше с эстимейтом для него не очень важно, потому что у него есть текущие проекты и головной боли хватает с лишком. В итоге мы получаем “суррогат” работы. Есть некий эксель, потрачено время, но такой эстимейт не продается, потому что завышен или хуже того, продается и компания попадает впросак, ведь бюджет вышел очень маленьким.
Ведь ПМ-у наплевать на это, давайте будем честными. Он(а) получает зп в долларах, за то что текущие проекты заканчиваются. А то что сейлз не может продать “честный” эстимейт – проблема сейлза и бренда компании, верно?

Совет: Нет, не верно. Каждый сотрудник компании должен думать про бизнес. Если ПМ будет говорить: “Это не мое дело”, то почему вы удивляетесь, что так говорят и разработчики, когда в релизе вываливаются критические ошибки? “Это не моё дело тестировать\думать про дизайн\заранее предупреждать”, – говорят они и не понимают, почему менеджеры дуются. Ведь менеджеры (вы) сами ведут себя аналогичным, наплевательским образом.

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

Думайте про цель и бизнес в первую очередь. А затем про форму.

Отмазка: Низкий уровень экспертности

На результат оценки влияет конечно же сомнительная экспертиза команды оценщиков. Маленькие и среднии компании физически не могут позволить себе выделить стабильную команду оценщиков, которые занимаются только оценками. И потому на оценку берут свободные “руки” с бенча. Экспертиза в оценке не аккумулируется, да и не каждому это дано, оценивать. Тут 2 грани.

  • “Эксперты” недооценивают сложность и по итогу, бюджет может быть занижен на 20%-30% (в лучшем случае).
  • “Эксперты” переоценивают сложность проектов, особенно заметно такое в нише CMS решений. Даже доступные из коробки возможности цмс-ок оцениваются в трёхкратном или даже больше объеме. В итоге, менеджер разочаровывается в разработчика, перестает верить в людей и пропагандирует правило trustn01. Сам был таким.

Совет: Поверьте, всех уволить – не вариант. Экспертов нужно прокачивать и нужно прокачивать собственную экспертность. Да, это занимает время, личное время. А вы как думали? Разработчики, между прочим, постоянно кодят в личное время и учатся новому. Чем вы лучше? Учитесь делать разбивки проекта, учитесь брифовать клиентов, разбирайте старые оценки и сравнивайте их с фактическими результатами. Разбирайте частые ошибки, как свои так и чужие. Подружитесь с теми разработчиками, которые мыслят с вами в одном русле и вытягивайте на оценки именно их.

Отмазка: Сроки всегда агрессивные

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

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

Отмазка: Требования на салфетках

С того же апворка запросы приходят в размере 500 знаков, или как фотографии с салфеток или вайтбордов. Как на этой основе давать оценки на фиксед-косты – непонятно. Но апворк полнится ими, а бизнес ставит менеджеру задачи и надо как-то крутиться уже сегодня.
Ок, требования приходят и в нормальном виде и даже снабжаются утвержденным дизайном. Но все равно, разработчики не видят всей картины, упускают важные сценарии и вообще, почему этим не занимается бизнес-аналитик?!

Совет: положим, аналитика в компании нет, потому что пм, которого уволили в прошлом месяце, увалил проект для клиента на почасовке и проблема съела бюджет на аналитика. Или бизнес-оунер просто жлоб и купил себе порше, вместо реинвестиций. Какая разница? Вы пришли работать или языки чесать? Нет аналитика и что, Scope Management секцию в PMBOK никто еще не отменял, так что вперед: интервью, прототипы, воркшопы. Тяжело в первые десять раз. Сори гайз, я не открыл Америку, но серебрянной пули нет, серьезно.

Работать, работать и еще раз работать с требованиями.

Кстати, я писал о том как обрабатывать недостаточные требования в статье про оценку в 5 шагов.

Отмазка: Оценщики дали эстимейт, но проект будут делать другие

Теряется ответственность за цифры и решения. Нет ответственности – плохой результат. Я работал в компании где оценщиков выделили в отдельный юнит, но это не избавляло оценки от проблем.

Совет: менеджер сам мало что может с таким сделать, потому что это operations уровень. Если бы у компании была возможность всегда выделять тех людей на эстимейт, которые и будут делать проект, они бы так и делали. Но ресурсы на аутсорс проектах даже более волатильные, чем курс биткоина.
Что можно сделать, так это стандартизировать подход к разбивке, всегда описывать задачи в эстимейте и документировать каждый шаг, чтобы не терять знания. Тупо не пропускайте эстимейты где у задач только название, обязательно пинайте экспертов, чтобы давали подробное описание, как они собирались за 4 часа прикрутить PayPal.

***

Гуру менеджмента, PMP, скрам мастера и сертифицированные аджайл коучи скажут что надо в топку слать таких клиентов и компании, в которых от тебя требуют хороший результат, но крутых специалистов не дают и не дают клиентов с бездонным бюджетом. А, ну и еще они скажут, что в топку эстимейты, нужен скрам и оценка в сторипоинтах.
Мысль, в своей основе правильная, но практически я не представляю, как менеджеру с годом опыта посылать в лес своего работодателя, который точно так же видел последний зарплатный опрос с доу и понимает, что незаменимых менеджеров нет. Мы сами разогрели этот рынок и сами оказались в ловушке. Так что давайте сами же с нее и выбираться.
Но, действительно, вы не дерево, чтобы работать с компанией без процессов и фокусом на клиентов, которые вам не по душе.

Рынок большой. Ходи торгуйся. Или просто начни работать.

***

Я благополучно проснулся от того что меня ласково хлопала по лицу уборщица. Кофе я пить не мог потом еще с неделю и потому вместо кофемашины включил почту, чтобы увидеть ответ от клиента на пропоузал.
Отказ, хоть и вежливый. Они отдали предпочтение другой компании, которая предложила прислать человека онсайт, выделить аналитиков и что-то там еще. Не цена, не объем проекта, а именно operations value стало кикером для клиента.

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

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

Перестаньте жаловаться. Улучшайте процесс.

Окей, скажете вы и добавите: “Саша, заканчивай с мотивейшн булшит и скажи что делать то?”

Обязательно расскажу в части 2.

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