Presale: от сбора требований до подготовки оффера

Статья написана в соавторстве с Мэри Ротарь, CEO IAMPM.

Всем привет! Меня зовут Владимир Яцевский, я основатель проекта LiveArt и консультант стартапов по Solution Design. Имею более 20 лет опыта в IT, 15 из которых руководил проектами и компаниями. Также я преподаю и провожу стажировки в НаУКМА. В своей компании занимаюсь всеми процессами включая Presale сложных проектов и их передачей в разработку.

Даже если в компании официально не употребляют слово «Presale», всегда есть стадия, на которой оценивается и планируется будущий проект.

Команда часто забывает о существовании пресейла, а клиент не понимает, зачем тратить деньги и время на этот этап. Отсюда и проблемы: несоответствие проекта видению клиента, неправильно просчитанный бюджет, упущенные из виду риски, потраченные силы на то, чтобы выиграть тендер любой ценой, и т.д. Именно поэтому важно помнить, что Presale — это не какой-то «быстренький» этап перед продажей, а целый предпроект, и относиться к нему нужно как к проекту: со всей серьезностью, следуя плану, а не просто надеясь на интуицию.

Проработав в сфере IT 20 лет, понимаю: многих проблем можно было бы избежать в прошлом, если бы я и мои коллеги знали о пресейле больше. Немного завидую современным специалистам, которые могут развиваться благодаря информации, которая сейчас в открытом доступе: курсам, лекциям, а еще — учитывать ошибки, которые допускали их коллеги, в том числе и я.

Исходя из своего опыта работы в пресейле я определил для себя план, следуя которому, можно подготовиться к проекту относительно безболезненно. Он может помочь всем, кто участвует в пресейле: PM-ам, Presale Manager-ам, BA, техническим специалистам и т.д.

Сбор требований

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

Хорошо описанные требования не только сделают работу легче, но и могут стать фреймворком в будущем.

Откуда берутся требования

Конечно, основной источник требований — это непосредственное общение с клиентами. Помимо этого, есть и другие, в частности, в моей работе. Возможно, вам доводилось слышать: «Вот готовое решение», «Сделайте так же, как в компании Х» и другие подобные формулировки. Нередко клиенты пытаются рассказать все требования на единственной встрече, затем аргументируя, что это и была спецификация их требований. Реже вам все же пришлют документ, кратко описывающий желаемое решение (заметьте, не проблему, а именно решение, которое, вероятно, ее решит!), но и он будет содержать неточные формулировки.

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

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

  1. Бриф — документ, своеобразная анкета, где прописываются основные проблемы (pain), цели и условия работы над проектом.
  2. Комментирование user stories — эта практика позволяет письменно зафиксировать изменения и решения, на которые можно будет ссылаться в более поздних фазах и на этапе работы с возражениями.
  3. Интервью с клиентом — если вопросов много, Presale Manager узнает у клиента требования на созвоне или во время личной встречи. Решения и детали обязательно нужно задокументировать, а в идеале — иметь записи всех интервью.
  4. Воркшоп — более развернутое интервью, в рамках которого целая команда брейнштормит и определяет требования. Эта практика позволяет проверить степень готовности вовлечения клиента и его продуктивности. К тому же все участники воркшопа должны быть готовыми брать на себя ответственность за дальнейший исход событий.
  5. Наблюдения за клиентом в процессе работы — иногда клиент сам не до конца понимает, что в приоритете. Он может прийти с требованием использования хештегов для маркировки статусов заказов, но в ходе общения и работы менеджер выяснит, что исходя из остальных задач хештеги либо абсолютно бесполезны, либо физически не воплотимы в данном контексте.
  6. Опросники — request for proposal — классический способ получить ответы массово от всех стейкхолдеров.
  7. Фокус-группы — аудитория, максимально схожая с ЦА готового проекта, к которой можно идти за фидбеком на этапе разработки проекта.
  8. Анализ существующей системы — API, пользовательский интерфейс, data and assets — проанализировав все это, тоже можно сделать выводы, в частности, касательно нефункциональных требований и ограничений. Например, какие картинки тянет система? Каким должен быть их максимальный размер? Это кажется не столь существенным, но мы и сами недавно столкнулись с сервисом, в котором пользователь пытался загрузить картинку на 500+ МБ, а ПО «легло», пытаясь обработать ее более двух часов.
  9. Пользователи — конечные потребители проекта, мнение которых очень важно, ведь если 99% обращают внимание на какой-то баг и говорят, что работать невозможно, значит, что-то нужно менять. Здесь также помогает аналитика новой или уже существующей системы, в частности, с помощью Hotjar.

Типичные ошибки при работе с требованиями

Самая глобальная проблема — не спросишь клиента, он сам и не скажет. А если и скажет, то только тогда, когда проект будет уже на завершающей стадии. Для того и существует этап пресейла — чтобы максимально проработать все требования, выявить скрытые и довести их до уровня good enough — минимального объема, с которым можно работать и минимизировать риски неоправданных ожиданий.

Было бы неплохо, если бы это была единственная проблема. Я выделил другие основные ошибки в работе с требованиями, и этот список можно продолжать.

  1. Использование брифа as is. В разных брифах совершенно разная степень детализации. Ошибкой будет взять этот документ, «нарезать» его на задачи как есть и отдать на выполнение. Presale Manager обязан его обработать, ведь с большей долей вероятности появятся неясности и уточнения, которые всплывут при передаче задач в разработку.
  2. Недостаточное выявление и проработка требований. Даже те, что не касаются проекта напрямую (организационные, нефункциональные), могут крайне его застопорить. Например, запустили проект, и все идет очень неплохо. Вдруг выясняется, что важный стейкхолдер, который будет принимать проект, увольняется через две недели, но вам об этом не сказали. Нехорошо, конечно, но только в том случае, если этот риск не проработали заранее.
  3. Использование сложных инструментов в работе. В начале 2000-х очень популярно было использовать RUP и в частности прорисовывать детальные UML Use Case диаграммы даже для простых сайтов. Это отнимало много времени, и проекты закрывались «в ноль» или значительно ниже. Усложнять инструменты и техники сбора требований нужно по мере усложнения проекта и если это действительно необходимо, особенно если проводится discovery-фаза.
  4. Слишком сильное погружение Presale Manager-а в анализ. Настолько сильное, что в какой-то момент приходит Sales Manager, хватается за голову и спрашивает: «Зачем ты все это делаешь?». Эта проблема также известна как Analysis paralysis. Главное — создать каркас основных эпиков и историй, с которым можно работать и впоследствии равномерно дополнять деталями. Да, грань между «слишком» и «недостаточно» тонка, но в этом и заключается мастерство Presale Manager-а — балансировать между крайностями.

Инструменты

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

  • Trello — позволяет структурно разбивать эпики и истории, но при этом без лишней сложности. Весьма понятный клиентам инструмент, в котором можно задавать проясняющие вопросы прямо в карточках user stories, делать перелинковки и декомпозировать.
  • Miro — всеми любимая интерактивная доска, которой чаще всего пользуются клиенты.
  • Figma — программа для быстрого UX/UI прототипирования; можно создать набросок и показать клиенту, чтобы понять, то ли он имел в виду и сходится ли видение, а в дальнейшем усложнять вплоть до подготовки high-fidelity прототипа и макета интерфейса.
  • PlantUML — удобен быстрым созданием наброска диаграммы для прояснения отдельных требований. Я, например, не люблю визуально расставлять компоненты диаграммы и всякий раз терять стрелки, здесь же я могу это делать быстро и продуктивно.
  • StoriesOnBoard — инструмент для сбора user stories, в котором можно логично группировать и декомпозировать объемные задачи на мелкие и воплотимые, разбивать по релизам и быстро проводить bottom-up оценку, о которой и поговорим дальше.

Оценка проекта

Всякий опытный разработчик скажет вам, что точная оценка проекта может занять столько же, сколько и его реализация. Как же тогда закрыть сделку в оговоренные сроки, не потратив слишком много времени и ресурсов? Использовать принцип good enough! В одних ситуациях быстрая оценка, составленная из одного интервью с заказчиком, может поспособствовать выявлению невыгодной сделки. А в других (например, если это интересный тендер, долгоиграющий проект и клиент никуда не спешит) стоит проделать большой объем работы: ответить на множество вопросов, подготовить качественную презентацию для воркшопа и т.д.

Перед тем как начинать подсчитывать стоимость проекта, нужно понять его значимость. Что мы хотим получить? Клиента, с которым планируем долгосрочное сотрудничество и который может сыграть ключевую роль в бизнесе, несмотря на минимальную прибыль с первого проекта? Новый продукт, который в дальнейшем поможет в решении проблем в других проектах? Большую прибыль? Наработку reusable-компонентов? Или все вышеперечисленное?

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

На самом деле этап оценки может длиться столько же, сколько и сам проект. Все зависит от целей проекта. В идеале, этап оценки вместе со сбором требований не должен занимать больше 20% времени от разработки. Бывает, что после тщательного сбора требований и оценки клиент отказывается, соответственно, пресейл не оплачивается. Такие случаи могут заставить задуматься над тем, а нужен ли он вообще. Еще как нужен!

Во-первых, пресейл — это опыт. Компании, которых не устраивает такой исход событий, как отказ клиента, — могут изменить подход к работе. Тем более, что качественную экспертизу в пресейле можно продавать как Discovery Phase! Причем как полностью весь предпроектный этап, так и каждую его составляющую: сбор требований, оценка и т.д. Работа сотрудников будет оплачена, а клиенту не придется проходить каждый раз один и тот же процесс в новой компании, в случае если текущее сотрудничество не сложится. С уже готовым предпроектным анализом заказчик может обращаться в другие компании и узнавать условия работы. Во-вторых, если клиент согласится продолжать сотрудничество, то проект с качественно проведенным пресейлом принесет в разы больше прибыли, и это факт.

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

  1. По аналогии с другими подобными проектами. Например, ваша компания собаку съела на создании различных соцсетей. На счету команды просчет примерно 100+ подобных проектов, а принцип их создания не очень-то отличается. В таком случае назвать примерную стоимость создания еще одной соцсети не составит труда.
  2. По принципу декомпозиции. Хорошо работает, когда клиент приходит с непонятным проектом (читать «с типом проекта, с которым раньше не работали»), и вам просто не с чем сравнивать. Что делать и куда бежать? Бежать не нужно, а вот что делать, подскажу. Декомпозировать! Разбейте проект на составляющие части исходя из того, как вы его собираетесь реализовывать, и оцените каждую часть отдельно. Затем суммируйте все полученные оценки. Предварительная сумма готова. Не переживайте, если в этом процессе вы не будете знать чего-то, ведь вы не одни в этой лодке, с вами как минимум BA и Solution Architect. Совет: для каждой из составляющих частей прописывайте предпосылки, из которых вы исходили, ставя оценку. Например, «этот сценарий можно воплотить с помощью микросервисной архитектуры ввиду требований к нагрузке». Таким образом, мы сможем объяснить клиенту наличие большего количества нулей в бюджете, чем предполагалось изначально.
  3. По принципу просчета risks and assumptions. Суть подхода заключается в том, чтобы прописать стоимость возможных вариантов решений и рисков для проекта от обратного. Зная минимально необходимый бюджет для проекта, можно дать клиенту выбор исходя из его ограничений. Например, многие API имеют особенности, которые предполагают минимальный порог входа в реализацию приложения.
  4. Поиск зависимостей и ограничений. Любая зависимость между функциональными частями проекта довольно часто означает не сумму оценок их независимой реализации, а произведение. Клиент должен понимать, что количество зависимых историй экспоненциально увеличивает стоимость как разработки, так и поддержки. Один мой клиент так увлекся добавлением различных бизнес-правил в систему, что реализация каждого последующего правила начала занимать в разы больше времени. Решением, к которому мы пришли, было пересмотреть весь накопившийся технический долг и создать новую версию системы.
  5. Bottom-up — оцениваем индивидуальные части проекта, а после собираем из них общую оценку. Если декомпозированные требования можно оценивать в равной степени сверху вниз, то метод «снизу вверх» позволяет проверить предыдущие оценки на прочность. Бывает так, что bottom-up оценка в несколько раз превышает обычную. Тогда эксперты признают, что в общей оценке не учли ряд деталей.

Готовим предложение для клиента: лайфхаки и техники

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

  1. Метод контраста. Предлагайте клиенту несколько вариантов (оптимально — три): от простого, который будет стоить дешевле всего, до самого сложного (читать «дорогого»). Частая ошибка — отметать самый дорогой вариант с мыслью «Да ну, клиент все равно не согласится». Не нужно решать за клиента. Он делает выбор, а не вы. Неуверенность в самом дорогом варианте оправданна тем, что на психологическом уровне самое дорогое обычно прельщает меньше всего. Это можно обыграть в переговорах! Вместо того чтобы отметать этот вариант, сделайте так, чтобы самый оптимальный вариант — тот, на который вы делаете ставки — шел перед самым дорогим. На контрасте с самым недосягаемым предпоследний вариант будет казаться очень даже привлекательным.
  2. Совет. Клиенты не любят много думать и решать. Они хотят, чтобы за них все просчитали и решили, опираясь на заранее оговоренные требования. Вам же, как специалисту, будет не трудно порекомендовать один из вариантов и аргументировать свой выбор. На этом можно сыграть, ведь всегда есть как минимум одна альтернатива, которая устроила бы и вас, и клиента.
  3. Anchoring. Известный принцип, строящийся на «зацикливании» клиента на ранее названных цифровых значениях, что влечет за собой неадекватную оценку последующих значений. Как это проявляется в контексте переговоров с клиентом? Когда ему озвучивают вилку, например, 20 000-40 000, он запоминает первое число, затем ориентируется только на него и очень возмущается, если в итоге сумма получится больше, чем 20 000. Решение: всегда отталкиваться от большего числа (40 000) и строить вилку от него, оговаривая, что в результате при определенных условиях (быстрое согласование требований, прием проекта и т.д.) может получиться и меньшая стоимость. Если получится сделать за 20 000, вряд ли клиент расстроится. Для него это будет, скорее, приятная неожиданность.
  4. Принцип неопределенности. Градацию вилки всегда можно увеличивать, если вы не уверены в оценке. Согласитесь, оценка 28-32 (не важно, в какой мере исчисления) воспринимается более точной, чем 30-60. На последнюю клиент сразу же среагирует, что позволить вовлечь его в дальнейшую работу, прояснить требования или же отказаться от реализации рисковых сценариев.

«Нет» можно воспринять по-разному — как окончательный отказ или как поле для работы, в ходе которой можно склонить клиента от «нет» к «да». Услышать отказ — очень даже хорошо. Хуже, когда клиенты пропадают и не выходят на связь (что не раз случалось в моей практике; и только однажды клиент вернулся, аргументировав свое «исчезновение» личными проблемами, и мы продолжили работать).

Вот пара лайфхаков для работы с возражениями:

  1. Докопаться до причины. Максимально «раскрутить» «нет» клиента до первопричины при помощи «Почему?», «Как вы это видите?», «Что мы бы могли сделать?».
  2. Вывести на конструктив. После слов: «А вот в компании N мне предлагали сделать все в два раза дешевле» — важно вовлечь клиента в конструктивный диалог. «Мы не против сделать это дешевле для вас, но тогда давайте вместе подумаем, как это можно сделать». Проработайте варианты по ситуации: от «...чтобы было дешевле, нужно из скоупа убрать...» до аргументов, что дешевле лучше не делать. Важно показать клиенту, что вы с ним на одной стороне, а проблема — на противоположной. Отказывайтесь, если клиент не проявляет готовность сотрудничать или банально пытается манипулировать.
  3. Есть ли что-то вне коробки? Помимо очевидных возражений по поводу цены, всегда нужно прорабатывать менее явные: возможно, решение требуется несрочное, от части функционала можно отказаться, а клиент готов оставить видеоотзыв и поучаствовать в других SMM-активностях. Ищите скрытые возможности в каждой сделке. То, что кажется мелочью для вас, может оказаться бесценным для клиента.

Личный рекомендасьон: что почитать по теме

Тема Presale слишком обширная, чтобы ее можно было изложить в одной статье. На ДОУ существует много материала, который поможет лучше погрузиться в тему. Я же хочу поделиться must-have литературой, которая будет полезна для любого специалиста, вовлеченного в presale-процесс.

  1. Карл Вигерс, «Разработка требований к программному обеспечению»
  2. Нил Рекхэм, «СПИН-продажи»
  3. Крис Восс, «Никогда не идите на компромисс. Техника эффективных переговоров»
  4. Гэвин Кеннеди, «Договориться можно обо всем! Как добиваться максимума в любых переговорах»

Итог

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

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

👍НравитсяПонравилось22
В избранноеВ избранном13
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Спасибо за подробную статью!

спасибо за подробную статью
Возник вопрос о смысле применения PlantUML
Обычно мы используем UML, чтобы визуализировать абстракции, которые хуже воспринимаются в другой форме. Однако, чтобы получить диаграмму в PlantUML необходим еще один уровень абстракции — внутренний язык описания диаграмм. Очевидно, что это усложняет и замедляет работу. В чем же тогда смысл этого инструмента?

Мне, как бывшему программисту, так гораздо быстрее и удобнее чем визуально создавать диаграмму в drag-n-drop режиме. Особенно в sequence или activity, где я могу долго попадать стрелочками в нужное мне место или тратить время на прихорашивание. Часто я открываю plantuml на встече чтобы вместе с тех командой или клиентом набросать диаграмму описывающую какой-то сценарий. Сама диаграмма затем уходит в документацию или команде на доработку, в этом случае удобно когда исходник диаграммы находится под git например и можно отслеживать изменения.

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

Отличная статья, благодарю!

Метод контраста

Это, кстати, научно доказано. В частности упоминается в «Психологии влияния» Чалдини Р.

Спасибо большое! Кстати да, и саму книгу можно добавить в список выше 👍.

Дякую за статтю, дуже пізнавально.

Хуже, когда клиенты пропадают и не выходят на связь (что не раз случалось в моей практике; и только однажды клиент вернулся, аргументировав свое «исчезновение» личными проблемами, и мы продолжили работать).

Так, а що ж сталося в інших випадках? Клієнт пропав і не повернувся? Цікаво, чи є у Вас лайфхаки на такі ситуації.

Дякую за відгук!
Найчастіше це означає, що клієнт шукає інші альтернативи або йому і справді потрібен час для владнання інших бізнес справ або ж узгодження з керівництвом чи інвесторами. Поради у мене дві: запастись терпінням і продовжувати працювати з іншими лідами та підтримувати контакт з клієнтом на рівні радника. Останнє класно спрацьовує якщо вам вдалось отримати довіру, у такому випадку клієнт розповість хід своїх думок та concerns і вам це дасть інформацію для покращення пропозиції.

Это даже не статья, а скорее инструкция к применению! Мои комплименты — легко, доступно и очень информативно!

Благодарю, очень приятно!

С вашего разрешения, добавлюсь в LinkedIn)

Дякую за інформацію! Дуже мало топіків на цю тему, а це чи не найголовніший етап в нашій роботі...

Подписаться на комментарии