Игорь Матрофайло

Delivery Director в SoftServe и спикер курсов IAMPM

Как определить ожидания заказчика и сопоставить их со своими? По каким критериям можно определить уровень своей экспертности перед началом проекта?
Как распределить роли внутри команды и кто понадобится со стороны клиента?

По каким критериям и методам можно оценивать пресейл-проект?

Своим опытом делится Игорь Матрофайло — Delivery Director в SoftServe и спикер курсов IAMPM. Мы собрали ключевые тезисы и идеи, которые были озвучены экспертом.

За плечами Игоря 15 лет опыта в IT. Он прошел путь от разработчика до технического лида. Потом занимался проектным менеджментом и два года работал в США в роли Agile-консультанта.

Последние 5 лет Игорь Матрофайло занимает должность Delivery Director в SoftServe. Он управляет бизнес-подразделением численностью 100+ человек и отвечает за развитие бизнеса.

Рекомендуем и другие материалы Kraftblick/Media по теме:

Как IT компаниям повысить Win Rate: работаем с пресейл в продажах.
Как построить работу над Proposal на этапе Presale, чтобы заполучить контракт. Кейс с Toyota.
Discovery Phase в IT: пример плана для проектов аутсорсинговых компаний.
Как с помощью команды Delivery подготовить Proposal, чтобы с большей вероятностью закрыть сделку.

В этой статье вы прочитаете:

• От пресейла до реализации
• Чего ожидает компания, которая пришла с запросом?
• Основные фазы пресейл-проекта (оценка квалификации, подбор команды/распределение ролей, сбор требований, оценка)
• Основные критерии и методы оценки проекта
• Основные ошибки на этапе оценки

От пресейла до реализации

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

Разложив на большие кубики деливери, увидим, что есть процесс инициации и пресейла.

Мы получили первый запрос от заказчика и двигаемся к этапу анализа и дизайна, чтобы спланировать, как-то обозначить это его ожидание (Pain или Gain) в рамках изначального запроса.

Дальше приступаем к реализации, которая тоже состоит из нескольких фаз:

1. Разработка и тестирование (зачастую идет итеративно)
2. Регрессия и стабилизация
3. Приемка
4. Go-Live

Вот такая схема поможет нам понять процесс:

Рассмотрим более подробно, что мы делаем на этапе пресейла.

Чего ожидает компания, которая пришла с запросом?

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

Прежде всего нам нужно понять, каковы ожидания компании, которая пришла к нам с запросом.

Чаще всего под этими ожиданиями имеется в виду следующее:

1. Когда мы сможем получить готовое решение или продукт для выхода на рынок — ожидание “когда”, Time To Market (TTM).
2. По какой цене мы получим этот продукт — ожидание “сколько”.
3. Что мы получим от этого решения, какие цели и боли оно сможет решить — заказчик ожидает от вас профессионализма и полного вовлечения в процесс.

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

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

Основные фазы пресейл-проекта

Далее рассмотрим подробнее основные фазы пресейл-проекта, а именно:

1. Оценка квалификации: достаточно ли у нас знаний и умений, чтобы реализовать проект заказчика.
2. Подбор команды и распределение ролей: какие специалисты понадобятся и кто за что будет отвечать.
3. Сбор требований для оценки: откуда брать и что это вообще может быть.
4. Оценка: основные критерии и методы (на этом особо остановлюсь).

А хватит ли нам квалификации?

Каким образом вы можете оценить уровень своей экспертности для решения проблемы компании, которая к вам обратилась?

Позитивный ответ можно дать, исходя из наличия следующего:

1. Экспертизы и понимания горизонта технологий/доменных областей.
2. Завершенных проектов в этой области.
3. Специалистов, которые делали проекты.
4. Сертификатов и опыта партнерства.

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

Остальные три критерия — факторы ширины, они показывают, насколько хорошо организован у вас процесс, а также глубину вашей экспертизы в той или иной технологии.

Это в совокупности и позволит понять, сможем ли мы выполнить проект.

Вообще важно постоянно оставаться в тренде, поскольку компании стремительно внедряют новые технологии. [Об этом у нас есть отдельный материал — прим. ред.]

Если мы перестанем фокусироваться на новых технологиях, мы не сможем адресовать потребности, которые приходят к нам от клиентов, окажемся аутсайдерами.

Например, Gartner Hype Cycle поможет понять, через сколько лет та или иная технология станет мейнстримом.

Собираем команду и распределяем роли для оценки задачи

Теперь необходимо собрать команду, распределить роли, чтобы можно было сделать оценку задачи, с которой к нам обратился заказчик.

У нас есть 2 стороны: заказчики и пресейл-команда.

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

1. Бизнес — лицо, написавшее изначальный запрос с описанием ожиданий.
2. Procurement — лицо, которое отвечает за деньги, за выбор вендора по определенным критериям.
3. Юротдел.

Кто нам нужен со стороны команды:

1. Account Executive, наш Sales Manager, который отвечает за раннюю коммуникацию с заказчиком и общение с ним на протяжении пресейл-проекта.
2. Бизнес-аналитики или Subject Matter Expert.
3. Архитектор, который имеет опыт работы с данными технологиями и направлениями.
4. Delivery-команда, которая состоит из Project Managers, Delivery Manager. Также может быть привлечен Engagement Manager.
5. Команда экспертов: Quality Control, DevOps, Data Science (дата-инженеры) или это могут быть какие-то нишевые профайлы, платформы.
6. Юротдел.
7. Финансовый отдел.

Определяем требования, на основе которых будем проводить оценку проекта

Источниками первичных требований могут быть:

• Бриф, в котором описаны ожидания заказчика относительно решения его проблемы. Он может быть дополнен спецификацией, содержать описание архитектуры, пользовательского интерфейса или другие детали, дополнительные материалы, информацию от третьих сторон и т.д.
• Интервью, которое помогает уточнить детали после изучения брифа от заказчика.
• Прототипы, консалтинг-репорты или существующая система.
• Доступ к конечным пользователям.

Фактор успеха работы над пресейл-проектом — это понимание первичного брифа, который в дальнейшем нужно будет адаптировать к поставленным задачам с помощью дополнительных вопросов, заданных заказчику.

От предварительной подготовки и результатов обсуждения с клиентом будет зависит успех нашей оценки.

Какие инструменты автоматизации можно использовать при работе с пресейл-проектом

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

Это поможет зафиксировать ожидания, сократив неопределенность.

Можно использовать Trello, Jira, Confluence, Excel либо вордовский документ — что удобнее для вас и для клиента.

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

Преимущество Miro, например, в том, что он позволяет в интерактивном режиме вести коллаборацию не один на один, а целыми командами.

Также пригодятся визуализаторы: Figma, Invision и ряд аналогичных тулов. Они помогают подготовить пользовательский интерфейс в формате кликабельного прототипа или ряда монохромных скринов.

Этот инструментарий очень важен для получения single source of truth, в котором мы, как команда исполнителей, зафиксировали, что именно будем оценивать.

Основные критерии и методы оценки проекта

Здесь важны несколько факторов, которые я свел в таблицу:

Начинать нужно со спецификации. Описывайте фичи, формируйте юзкейсы, делайте интерактивный прототип, рисуйте референс-архитектуру.

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

Помним о принципе good enough: имея ограничения по времени, мы не используем методику, которую нужно детально прорабатывать и специфицировать все требования. На этапе пресейла в этом нет нужды.

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

Нужно, чтобы кто-то ему подсказал, какой подход должен использоваться, как сделать лучше.

Методы оценки

1. Аналогия и экспертиза.

Первый и самый простой метод оценки. К примеру, мы запустили 1,000 платформ на WordPress, сделали много сайтов, знаем, как это все работает. У нас выработалась собственная методика оценки.

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

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

2. Оценка по трем точкам.

Наш мозг, пытаясь решить какую-то задачу, всегда мыслит в формате optimistic — pessimistic, оптимальное решение при этом находится где-то посредине между этими двумя крайностями.

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

Точность этого метода оценки зависит от декомпозиции и того, насколько грубо или детально мы разложили перечень задач (scope items).

3. Метод оценки Feature/Story Points.

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

Тогда в рамках каждого сегмента определяем вес: задачи из самого простого сегмента — это 1 или 2 story points, попавшие во второй сегмент — 5 или 8 story points, и третий сегмент — 13 story points.

Здесь используется тот же механизм, что и в planning poker.

В этом методе очень важно найти эталонную задачу, от которой можно отталкиваться. Он хорош тем, что мы можем оценить фичи не только в эквиваленте усилий, но еще и в эквиваленте денежных единиц: доллара или евро.

4. Прототип.

Объем задач сужается до какого-то результата/прототипа или до чего-то, что можно легко и быстро оценить, что даст некое value заказчику.

5. Пакетное предложение.

Мы делаем оценку большого пирога, разделяя его на куски: самый простой, базовый набор, продвинутый или VIP.

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

6. Exploration Phase.

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

Основные ошибки на этапе оценки

На этапе оценки мы иногда забываем про такие важные вещи, как:

• Quality control процедура, юнит-тесты, code review, исправление дефектов, которые тоже съедают время. Все это является неотъемлемой частью процесса деливери.
• Нечеткое понимание baseline. Если он плавает, тогда и оценка плавает — мы не понимаем, что именно нужно оценивать.
• Давление со стороны заказчика, особенно на этапе пресейла, когда вы должны предложить реальное решение. Дорого? Давайте рассмотрим пакеты. Долго? Давайте разобьем реализацию проекта на шаги.
• Излишний буфер и оценка навскидку.
• Деливери цикл. Не забывайте об этапе приемочного тестирования (UAT), тестирования приложения группой конечных пользователей, выход в продакшен. Это тоже важная часть процесса.

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

Все равно будут происходить какие-то изменения, ведь современный мир динамичен, рынок постоянно меняется.

И мы двигаем наш baseline и делаем переоценку. В этом отлично помогает треугольник управления проектами.

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

Мы находимся в IT бизнесе, но в то же время работаем с людьми: с нашей командой, с заказчиком.

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