Запуск Berlin Brandenburg Airport изначально запланированный на 2012 снова перенесен. Теперь на 2020. Где ошибся менеджер?
Для себя собрал маленький estimate фреймворк. Совсем просто, но идея эстимейта состоит в том, чтобы пройти следующую цепочку шагов:
Собрать требования > Разбить на задачи > Оценить задачи
Предыдущий пост состоял из отмазок и мотивации, но я практик и хочу рассказать о конкретных инструментах и шагах, как улучшить эстимейты. Но без мотивации и эмпирики практика работать не будет.
1. RFP
Как работать с требованиями уже разбирались, хотя тема бездонная. На Входе нужно получить RFP (request for proposal) от клиента или саммари от сейлзов по брифу.
В компании может быть не принято брифовать клиента или клиенты заходят без собранных в одну кучу требований. Это не ОК. Нужно чтобы стартер эстимейта собирал все в одном месте.
Бриф – набор типичных вопросов, которые вы задаете клиентам, чтобы понять их запрос. Сюда входят не только вопросы про бюджет и сроки, но и цель проекта (с нуля, внедрение изменений, поддержка, инновационный продукт), аудитория, кто будет пользоваться и ограничения. Поймите стейкхолдеров, их боль.
Клиент прислал запрос создать сайт для публикации отчета о работе за год. Единоразовый сайт для презентации инвесторам и понтов. Через месяц-другой жизни он совершенно потеряет актуальность. Компания-подрядчик предложила создать все на CMS с возможностью управлять каждым ньюансом отображением и управления содержимым.
Клиент отказался. Его “боль” – не управление контентом. Его боль – быстрее выкатить в мир “витрину”. Не поняли боли, не взяли проект.
2. Брифование
Если есть возможность, то проведите встречу(и) с клиентом по требованиям и ещё глубже детализируйте бриф. С upwork-клиентами это нереально, знаю, по крайней мере, с большинством из них. Но с другими клиентами это вполне возможно.
Вопросы – главный инструмент на этапе сбора требований. Но не единственный. Не стоит ожидать, что клиент 100% понимает всю задачу. Он обратился к специалистам, чтобы ему помогли. К своим вопросам добавляйте предложения и предположения о работе системы\сайта\приложения. Предлагайте лучшие практики и подходы, подтвержденные опытом решения.
Важный момент, если боитесь или стесняетесь задавать вопросы клиенту или не знаете какие вопросы задавать (т.е. не понимаете технологии и бизнес клиента), то лучше за оценки не браться. Сначала прокачайте себя в анализе.
Собираем ответы на вопросы и подтверждения предположений в отдельный документ. Информацию получили и зафиксировали в задаче, чтобы все участники процесса имели одинаковое понимание. Не храните документы в почте и мессенджерах. Заносите в систему управления документами или хотя бы таск-трекеры.
По итогу, в конце первой группы процессов ПМ должен детализировать RFP и обновить бриф.
Estimate scoring
Для скоринга эстимейтов пользуюсь подходом Probability/Impact, чтобы понять, насколько сильно нужно углубляться в оценку. Если клиент пришел из ниоткуда, требования туманны, клиент выходить на связь не хочет и при этом есть маленький бюджет, то это Low Probability и Low Impact. Для такого запроса сделайте high-level оценку и предложить созвониться для выяснения требований. Не представляю себе вселенную, где можно выжимать из таких запросов толк и потому много тратить сил не стоит.
Если у клиента есть кредабилити, как минимум успешная история на UpWork или подтвержденный background check, и это тендер с ограниченным кол-вом участников, то оценивается в Probability High / Impact High. И за такие запросы беритесь закатав рукава.
Фокусируйтесь на самом главном и выстраивайте ожидания сейлзов и клиентов. Из 500 знаков написанных на салфетке тяжело сделать оценку с точностью выше 50%. Тем самым вы начнете уделять больше внимания правильным клиентам и меньше внимания трешу.
Сейлз или руководитель просит браться за каждый запрос и уделять каждому запросу одинаковое время (сомнительно, но все же)? Соберите историю оценок и посмотрите, какие из них зашли за последний квартал. Головой ручаюсь, что заходили только High / High.
3. Техническое решение
Окей, разобрались, что конкретный запрос пускаем в работу и подключаем команду. На основе ответов и наших предположений начинаем собирать техническое решение. Делаем это вместе с экспертом со стороны разработчиков. Давайте на примере:
Вводная 1: Клиент хочет просто выйти в онлайн и дать знать миру о своей компании. Хочет рассказать про себя, команду и услуги. Не хочет ничего продавать (пока что).
Анализ: типичный запрос на сайт визитку, которые о чудо еще случаются в 2017 году. Лучшим решением для клиента будет предложить дизайн и создание сайта на базе CMS (желательно той, с которой вы знакомы).
Да, можно поддаться веянию моды и предложить сделать SPA на React или Angular. Но смысл забивать гвозди микроскопом?
Вводная 2: Клиент хочет автоматизировать прием и обработка табелей рабочего времени и выплаты зарплат сотрудников на своем производстве. Сейчас все делается в гугл доках и ему стало неудобно держать информацию просто в таблицах.
Анализ: вот тут надо разобраться с основными пользовательскими сценариями и ролями. Конкретное решение может быть сделано как на реакте, так и на cms, но формализация требований должна идти на первом месте. Если у клиента нет списка сценариев, их нужно продумать вместе с ним.
В первом и втором случае важно брифовать клиента и задавать ему открытые вопросы, чтобы понять больше про бизнес и про боль. Интересно, что времени на этот процесс нужно примерно одинаково, хотя второй проект потенциально гораздо сложней.
4. Декомпозиция
Есть формализованные требования в любом удобном для команды виде. Может быть формат SRS, может быть плоский список пользовательских историй. Теперь на их основе делаем Work breakdown structure.
Есть компании, которые работают с конечными клиентами. Они не понимают кухню аутсорса и в гробу видали концепцию человека-часа и часового рейта. Есть компании посредники, которые кухню понимают отлично и не упускают шанса срезать косты на рейте или часах. Два разных клиентских портрета, которым нужны совершенно разные эстимейты.
В первом случае, конечный клиент будет смотреть какие фичи вы сделаете и какую ценность от каждой фичи он получит. Вот есть корзина и чекаут, вот есть PDP.
Для посредника важно видеть итоговую разбивку по часам, чтобы была возможность сравнить с другими подрядчиками или инхаус командой. Нужны конкретные активности в рамках проекта. Вот бекенд часть для корзины и чекаута, верстка, тестирование и менеджмент.
Если вы вышлите эстимейт с разбивкой по активностям, как во втором примере, конечному клиенту, он может быть и “купит”, но мало поймет, ожидания не будут четкими. И наоборот.
Для облегчения жизни, поделюсь простеньким шаблоном оценки. Собрал структуру подходящую для разработчиков, с разбивкой по группам и направлениям работы.
5. Оценка
Оцениваем вместе с экспертами (разработчиками, тестерами, другими специалистами). ПМ может сам проставлять цифры если это крошечный, типичный проект, которых он уже сделал штук 10 и знает все подводные камни. Может, но не должен. Нужно привлекать экспертов и фассилитировать их работу. Просто начните использовать 2 подхода:
Оценка по 2-м точкам: не так хороша, как оценка по 3-м точкам, но для начала подойдет. Если осилите, углубитесь в красоту среднего распределения, почитайте о PERT и добавьте пару колонок в эксель. Но даже 2 точки (min-max) обеспечат минимальную “вилку” при оценках. Исходя из концепции “конуса неопределенности”, на этапе присейла есть высокий шанс неадекватно оценить проект. И потому лучше страховаться и всегда давать рейндж, а не 1 цифру.
T-Shirts: если и вам и вашим разработчиком тяжело оценивать в абсолютных часах, попробуйте подход T-Shirts и оценивайте в относительном измерении.
Сколько часов займет подключить платежную систему? Ведь тяжелый вопрос и есть риск ошибиться. Разработчик боится брать на себя обязательство и оценит в пару недель, ведь в случае чего доделает на выходных. Или недооценит, и проект сольет бюджет. Знаком такая проблема?
Человек принимает решения на основе эмоций. Человек мыслит категориями и образами. И разработчик тоже человек, а значит несовершенен и подвержен ошибкам. Более того, у разработчика может быть мало опыта. Так зачем ломать ему и себе голову и пытаться оценивать в часах, если не выходит делать хорошо? Попробуйте оценивать в отностительных величинах.
Это большая задача или маленькая? Задачи можно сравнивать между собой, а можно с эталоном. Нормализуйте размеры и договоритесь с командой оценки об эталонах. Соберите для себя размеры где будут:
- S(mall) – маленькие задачи, не требует описания выполнения. Для одних команд может быть добавить кнопку, для других – создать десяток api endpoints.
- M(edium) – средние задачи, требует описания выполнения.
- L(arge) – большие задачи, требует дальнейшей декомпозиции.
6. Финализация
Вычитываем и форматируем. Помните, документы – лицо менеджера. Если документ минимально не отформатирован, есть ошибки в формулах и опечатки, то какая гарантия, что менеджер точно так же и проект не сделает?
Помните что:
- Libre Office Calc умеет проверять орфографию в таблицах;
- Google Sheets имеет отличный плагин Spelling;
- Дайте вычитать коллеге.
Выходы оценки
На выходе нужно получить минимальный набор артефактов состоящий из:
- Документ со списком вопросов и предположений на которые клиент дал ответ или подтвердил\опроверг их;
- Предложение по техническому решению, выбор платформы или фреймворка, под который этот эстимейт и создавался;
- Экселя, в котором есть WBS, оценка в цифрах по задачам\фичам, описания задач;
С этими документами сейлз уже сможет сделать хорошее предложение клиенту и понимать, что мы делаем, сайт визитку или маленькую ERP систему.
После 10 эстимейтов, вы заметите паттерны и сможете собирать типичные вопросы в брифы. Научитесь быстрей проводить скорринг, а шаблоны оценки и процесс дадут скорость. Рим тоже не сразу строился.
На правах рекламы. 17-18 февраля буду проводить 2-х дневный курс-интенсив по управлению проектами в P&M Hub. Рассмотрим вопрос работы с требованиями, оценок, управления сроками и бюджетом. Специально для читателей блога есть промо-код OUTSOURCED – даст 20% скидки. Узнать про мероприятие.
