Я расскажу об опыте аутсорсинговой компании. Как мы прокачали предварительную оценку проектов и как пришли к тому, что стали продавать этап аналитики отдельно от разработки.
Для начала уточню, что под аутсорсом я подразумеваю разработку на заказчика, который находится за пределами компании. Это добавляет свои особенности — заказчик не всегда является оунером, а оунер — не обязательно эксперт в разработке. Из-за этого особая чувствительность к срокам и изменениям стоимости.
Что сделали
Сейчас у нашей компании два полноценных офиса в Новосибирске и Питере и небольшое представительство в Лондоне. Всего же у нас работает 120 человек.
Вопрос оценки стал колючим, когда мы доросли до 30 сотрудников. Тогда задачи по оценке размазывались между project-менеджерами и разработчиками, а подпинывал процесс самый заинтересованный — sales-менеджер.
Логично, что такое отношение приводило к ситуациям, когда никто не понимал, что мы продали и почему это столько стоит.
Решили, что что-то пора менять, когда надоело факапить «со старта» из-за неправильных оценок. Да и хаотичность самого процесса оценки стала отнимать слишком много сил.
Для начала ввели отдельную боевую единицу «аналитик». Постепенно от проекта к проекту аналитик разросся до целого отдела бизнес-аналитики и забрал на себя всю предварительную оценку.
Улучшения итеративные и очень похожи на ремонт — только закончим старый, пора начинать новый. Поэтому даже к моменту публикации этой статьи, скорее всего, что-то поменяется. В любом случае, глупо не поделиться нашими наработками. Вот, что мы сделали.
Завели базу знаний
Мы переработали и структурировали данные по всем проектам, которые делали или хотя бы оценивали.
Для каждого выполненного или поступившего на оценку проекта заполняется анкета:
- дата поступления проекта и из какой страны;
- кто sales-менеджер и бизнес-аналитик;
- технологии;
- объём часов на разработку;
- «рисковые» часы;
- тип работы;
- описание.
Анкета проектов чуть больше:
База знаний помогает и sales-менеджерам, и аналитикам. Первым — самостоятельно очень грубо прикинуть стоимость проекта ещё на стадии знакомства с клиентом, вторым — учесть нюансы при составлении сметы.
Сама смета, достаточно стандартная для нашей сферы и очень похожая на ту, что уже опубликовали на vc.
Разработали чек-лист
Чек-лист заполняет sales-менеджер перед отправкой запроса на оценку. Без этого процесс даже не стартует. Так мы снизили количество запросов, которые аналитик не может пустить в работу из-за нехватки первичных данных.
Состав чек-листа
Ожидаемое время получения оценки от аналитика, ожидаемый бюджет клиента (количество часов), тип оценки:
- full estimation: фичи + часы;
- только feature map: только фичи;
- оценка фазы проектирования: аналитика, прототипирование, часы на PM и коммуникации;
- range estimation. Например, 1000–1500 часов.
Запросы на привлечение специалистов для дополнительных работ:
- чья инициатива: SM-а или клиента? видение архитектуры от аналитика;
- видение архитектуры от разработчика;
- дизайн-концепт;
- анализ конкурентов;
- code review;
- аудит дизайна;
- аналитическая записка;
- календарный план работ;
- созвон с заказчиком. Дополнительно указать агенду, список участников и роль каждого участника на созвоне;
- митинг внутри компании: дополнительно указать агенду, список участников и роль каждого на митинге;
- деловое предложение: указать цель;
- протоптип ПО.
И обязательно для каждого запроса заполняется информация:
- чья инициатива: SM-а или клиента?
- какая цель: познакомиться, подтвердить нашу экспертизу, согласовать условия работы, выявить требования заказчика;
и ожидаемый результат:
- бизнес-цель приложения или сайта
- проблема, которую решает приложение или система;
- целевая аудитория
- предполагаемые роли в системы;
- какие части системы нужно оценить, например, бэк+мобилка+админка;
- что уже есть у заказчика: front, back, design, analytics?
- входная информация от заказчика;
- аналоги;
- предполагаемое количество пользователей
Стали анализировать пресейл
Мы стали анализировать анкеты ранее поступивших запросов. Это помогает прогнозировать, чем закончится новый, кому его отдать на оценку и стоит ли выделять дополнительные ресурсы и инвестировать дополнительное время.
Ограничили время на оценку
Сегодня мы обрабатываем в месяц примерно 50 запросов на оценку. Это уже те, которые прошли сито адекватности — без «сделайте нам Фейсбук за $1000». И это те оценки, которые совершенно бесплатные для потенциальных заказчиков. Я специально уточнил, что они бесплатные именно для заказчика, ведь для нас они платные — мы тратим на них время, а значит и деньги. Чтобы не расходовать дорогое время, выставили максимальный срок оценки — 4 часа. К этому показателю, конечно, пришли не сразу. Но теперь это стандарт.
Если мы считаем, что заявка перспективная, то можем инвестировать дополнительное время — в среднем, до двух рабочих дней. Когда не укладываемся во время, то даём только грубую оценку и поясняем, что проект сложный и даже на оценку требуется оплаченное _кем-то_ время.
Бывают и исключения. Когда к нам приходят очень большие проекты, например, заказ от компаний из топ-3 аудиторов, авиакомпаний или крупных российских ритейлеров — мы подходим к пресейлу по-другому, выделяя на него дополнительное время и ресурсы. По сути, мы инвестируем в эти проекты.
Ввели новые роли
Presale account
Теперь все запросы на оценку проходят через опытного аналитика, который хорошо знает и процессы разработки, и бизнес-процессы компании. Он распределяет запросы по направлениям, подсвечивает белые пятна входящих запросов и управляет ресурсами — свободными аналитиками.
Пул задач Discovery PM
— изучить запрос и либо взять в работу, либо отправить обратно;
— выделить фичи;
— понять, «что сделать, чтобы его взять»: созвониться, показать экспертизу, провести демонстрацию кейсов или даже нарисовать варфреймы;
— дать конечную оценку. Провести оценку по фичам или же указав range «от и до»;
— выявить цель оценки и для чего её заказывают;
— заполнить анкету по оценке;
PM
Запросы по Российским проектам выделили отдельно, так как во-первых, их меньше, чем запросов со всех остальных стран, а во-вторых, они немного отличаются по принципу работы. Но в целом РФ PM выполняет почти те же самые задачи, что и Discovery PM.
Tech PM
На Tech PM-а уходят те запросы, которые он сам может оценить, без верификации с разработчиками.
Что получили
Такие действия привели к тому, что мы …не добились той точности, на которую рассчитывали. Оценка по-прежнему могла сильно отличаться от конечной стоимости. Многие проекты невозможно оценить быстро, а сама оценка — большой блок работ, который кто-то должен оплатить.
Слова «быстро», «точно» и «бесплатно» в одном предложении — по-прежнему, утопия.
Но мы пришли к тому, что всем большим проектам обязательно должен предшествовать этап Discovery phase — платной оценки проекта. Результат Discovery phase — набор артефактов, который меняется от целей заказчика и позволяет предложить либо дальнейшие шаги, либо конкретное решение. И конечно же, стоимость работ, если всё это будем делать мы.
Не будем приукрашивать, sales-менеджеры такое решение оценили не сразу. Пришлось дождаться осознания, что больше не приходится продавать проект со словами: «Вы же понимаете, это примерная оценка и она может измениться на 100500%». Да и положительная реакция заказчиков на подробную документацию, которая заточена под их задачи и позволяет перейти к разработке хоть у нас, хоть в любой другой компании, дала понять, что мы на правильном пути.
