Всем привет! Меня зовут Владимир Яцевский, я основатель проекта LiveArt и консультант стартапов по Solution Design. Имею более 20 лет опыта в IT, 15 из которых руководил проектами и компаниями. Также я преподаю и провожу стажировки в НаУКМА. В своей компании занимаюсь всеми процессами включая Presale сложных проектов и их передачей в разработку.
Даже если в компании официально не употребляют слово «Presale», всегда есть стадия, на которой оценивается и планируется будущий проект.
Команда часто забывает о существовании пресейла, а клиент не понимает, зачем тратить деньги и время на этот этап. Отсюда и проблемы: несоответствие проекта видению клиента, неправильно просчитанный бюджет, упущенные из виду риски, потраченные силы на то, чтобы выиграть тендер любой ценой, и т.д. Именно поэтому важно помнить, что Presale — это не какой-то «быстренький» этап перед продажей, а целый предпроект, и относиться к нему нужно как к проекту: со всей серьезностью, следуя плану, а не просто надеясь на интуицию.
Проработав в сфере IT 20 лет, понимаю: многих проблем можно было бы избежать в прошлом, если бы я и мои коллеги знали о пресейле больше. Немного завидую современным специалистам, которые могут развиваться благодаря информации, которая сейчас в открытом доступе: курсам, лекциям, а еще — учитывать ошибки, которые допускали их коллеги, в том числе и я.
Исходя из своего опыта работы в пресейле я определил для себя план, следуя которому, можно подготовиться к проекту относительно безболезненно. Он может помочь всем, кто участвует в пресейле: PM-ам, Presale Manager-ам, BA, техническим специалистам и т.д.
Хорошо описанные требования не только сделают работу легче, но и могут стать фреймворком в будущем.
Именно здесь начинается настоящая работа с требованиями — превратить неструктурированные обрывочные сведения в систему, достаточно понятную для дальнейшей оценки. Для этого есть ряд практик, с которыми можно вступать в бой с неизвестностью.
Это не значит, что нужно внедрять абсолютно все в свои проекты, но я бы посоветовал хотя бы с ними ознакомиться. Так вы будете понимать, к кому, чему и за чем еще можно обратиться, чтобы собрать максимально полные требования.
Было бы неплохо, если бы это была единственная проблема. Я выделил другие основные ошибки в работе с требованиями, и этот список можно продолжать.
Перед тем как начинать подсчитывать стоимость проекта, нужно понять его значимость. Что мы хотим получить? Клиента, с которым планируем долгосрочное сотрудничество и который может сыграть ключевую роль в бизнесе, несмотря на минимальную прибыль с первого проекта? Новый продукт, который в дальнейшем поможет в решении проблем в других проектах? Большую прибыль? Наработку reusable-компонентов? Или все вышеперечисленное?
В зависимости от выбранной цели, в работу добавятся разные акценты. Если в приоритете сотрудничество, то фокус нужно сместить на качество коммуникации, так как часто именно это является ключевым фактором в выборе. При одинаковых условиях разных компаний клиент выберет ту, где на все его вопросы ответили вежливо и вовремя.
На самом деле этап оценки может длиться столько же, сколько и сам проект. Все зависит от целей проекта. В идеале, этап оценки вместе со сбором требований не должен занимать больше 20% времени от разработки. Бывает, что после тщательного сбора требований и оценки клиент отказывается, соответственно, пресейл не оплачивается. Такие случаи могут заставить задуматься над тем, а нужен ли он вообще. Еще как нужен!
Во-первых, пресейл — это опыт. Компании, которых не устраивает такой исход событий, как отказ клиента, — могут изменить подход к работе. Тем более, что качественную экспертизу в пресейле можно продавать как Discovery Phase! Причем как полностью весь предпроектный этап, так и каждую его составляющую: сбор требований, оценка и т.д. Работа сотрудников будет оплачена, а клиенту не придется проходить каждый раз один и тот же процесс в новой компании, в случае если текущее сотрудничество не сложится. С уже готовым предпроектным анализом заказчик может обращаться в другие компании и узнавать условия работы. Во-вторых, если клиент согласится продолжать сотрудничество, то проект с качественно проведенным пресейлом принесет в разы больше прибыли, и это факт.
Так как же оценить проект? Способов существует много, в своей работе я выделил несколько базовых техник оценки:
Вот пара лайфхаков для работы с возражениями:
Presale — это инвестиция, которая может быть рисковой, но доход от проекта, перед которым был проведен Presale, чаще всего в разы превышает потраченные усилия.
dou.ua
Даже если в компании официально не употребляют слово «Presale», всегда есть стадия, на которой оценивается и планируется будущий проект.
Команда часто забывает о существовании пресейла, а клиент не понимает, зачем тратить деньги и время на этот этап. Отсюда и проблемы: несоответствие проекта видению клиента, неправильно просчитанный бюджет, упущенные из виду риски, потраченные силы на то, чтобы выиграть тендер любой ценой, и т.д. Именно поэтому важно помнить, что Presale — это не какой-то «быстренький» этап перед продажей, а целый предпроект, и относиться к нему нужно как к проекту: со всей серьезностью, следуя плану, а не просто надеясь на интуицию.
Проработав в сфере IT 20 лет, понимаю: многих проблем можно было бы избежать в прошлом, если бы я и мои коллеги знали о пресейле больше. Немного завидую современным специалистам, которые могут развиваться благодаря информации, которая сейчас в открытом доступе: курсам, лекциям, а еще — учитывать ошибки, которые допускали их коллеги, в том числе и я.
Исходя из своего опыта работы в пресейле я определил для себя план, следуя которому, можно подготовиться к проекту относительно безболезненно. Он может помочь всем, кто участвует в пресейле: PM-ам, Presale Manager-ам, BA, техническим специалистам и т.д.
Сбор требований
В идеальном мире выявление требований происходит быстро, клиент вовлечен и заинтересован в процессе, а ответственный за этап пресейла делает все с учетом нужд заказчика и с одними только выгодами для компании. Но мы живем в другом мире — с клиентами, которые пропадают на неопределенное время, оставляя пресейл-специалиста в неведении и с собранными наполовину требованиями, с горящими дедлайнами и озвученными сейлзом клиенту цифрами за проект, которые в разы ниже реальных.Хорошо описанные требования не только сделают работу легче, но и могут стать фреймворком в будущем.
Откуда берутся требования
Конечно, основной источник требований — это непосредственное общение с клиентами. Помимо этого, есть и другие, в частности, в моей работе. Возможно, вам доводилось слышать: «Вот готовое решение», «Сделайте так же, как в компании Х» и другие подобные формулировки. Нередко клиенты пытаются рассказать все требования на единственной встрече, затем аргументируя, что это и была спецификация их требований. Реже вам все же пришлют документ, кратко описывающий желаемое решение (заметьте, не проблему, а именно решение, которое, вероятно, ее решит!), но и он будет содержать неточные формулировки.Именно здесь начинается настоящая работа с требованиями — превратить неструктурированные обрывочные сведения в систему, достаточно понятную для дальнейшей оценки. Для этого есть ряд практик, с которыми можно вступать в бой с неизвестностью.
Это не значит, что нужно внедрять абсолютно все в свои проекты, но я бы посоветовал хотя бы с ними ознакомиться. Так вы будете понимать, к кому, чему и за чем еще можно обратиться, чтобы собрать максимально полные требования.
- Бриф — документ, своеобразная анкета, где прописываются основные проблемы (pain), цели и условия работы над проектом.
- Комментирование user stories — эта практика позволяет письменно зафиксировать изменения и решения, на которые можно будет ссылаться в более поздних фазах и на этапе работы с возражениями.
- Интервью с клиентом — если вопросов много, Presale Manager узнает у клиента требования на созвоне или во время личной встречи. Решения и детали обязательно нужно задокументировать, а в идеале — иметь записи всех интервью.
- Воркшоп — более развернутое интервью, в рамках которого целая команда брейнштормит и определяет требования. Эта практика позволяет проверить степень готовности вовлечения клиента и его продуктивности. К тому же все участники воркшопа должны быть готовыми брать на себя ответственность за дальнейший исход событий.
- Наблюдения за клиентом в процессе работы — иногда клиент сам не до конца понимает, что в приоритете. Он может прийти с требованием использования хештегов для маркировки статусов заказов, но в ходе общения и работы менеджер выяснит, что исходя из остальных задач хештеги либо абсолютно бесполезны, либо физически не воплотимы в данном контексте.
- Опросники — request for proposal — классический способ получить ответы массово от всех стейкхолдеров.
- Фокус-группы — аудитория, максимально схожая с ЦА готового проекта, к которой можно идти за фидбеком на этапе разработки проекта.
- Анализ существующей системы — API, пользовательский интерфейс, data and assets — проанализировав все это, тоже можно сделать выводы, в частности, касательно нефункциональных требований и ограничений. Например, какие картинки тянет система? Каким должен быть их максимальный размер? Это кажется не столь существенным, но мы и сами недавно столкнулись с сервисом, в котором пользователь пытался загрузить картинку на 500+ МБ, а ПО «легло», пытаясь обработать ее более двух часов.
- Пользователи — конечные потребители проекта, мнение которых очень важно, ведь если 99% обращают внимание на какой-то баг и говорят, что работать невозможно, значит, что-то нужно менять. Здесь также помогает аналитика новой или уже существующей системы, в частности, с помощью Hotjar.
Типичные ошибки при работе с требованиями
Самая глобальная проблема — не спросишь клиента, он сам и не скажет. А если и скажет, то только тогда, когда проект будет уже на завершающей стадии. Для того и существует этап пресейла — чтобы максимально проработать все требования, выявить скрытые и довести их до уровня good enough — минимального объема, с которым можно работать и минимизировать риски неоправданных ожиданий.Было бы неплохо, если бы это была единственная проблема. Я выделил другие основные ошибки в работе с требованиями, и этот список можно продолжать.
- Использование брифа as is. В разных брифах совершенно разная степень детализации. Ошибкой будет взять этот документ, «нарезать» его на задачи как есть и отдать на выполнение. Presale Manager обязан его обработать, ведь с большей долей вероятности появятся неясности и уточнения, которые всплывут при передаче задач в разработку.
- Недостаточное выявление и проработка требований. Даже те, что не касаются проекта напрямую (организационные, нефункциональные), могут крайне его застопорить. Например, запустили проект, и все идет очень неплохо. Вдруг выясняется, что важный стейкхолдер, который будет принимать проект, увольняется через две недели, но вам об этом не сказали. Нехорошо, конечно, но только в том случае, если этот риск не проработали заранее.
- Использование сложных инструментов в работе. В начале 2000-х очень популярно было использовать RUP и в частности прорисовывать детальные UML Use Case диаграммы даже для простых сайтов. Это отнимало много времени, и проекты закрывались «в ноль» или значительно ниже. Усложнять инструменты и техники сбора требований нужно по мере усложнения проекта и если это действительно необходимо, особенно если проводится discovery-фаза.
- Слишком сильное погружение 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! Причем как полностью весь предпроектный этап, так и каждую его составляющую: сбор требований, оценка и т.д. Работа сотрудников будет оплачена, а клиенту не придется проходить каждый раз один и тот же процесс в новой компании, в случае если текущее сотрудничество не сложится. С уже готовым предпроектным анализом заказчик может обращаться в другие компании и узнавать условия работы. Во-вторых, если клиент согласится продолжать сотрудничество, то проект с качественно проведенным пресейлом принесет в разы больше прибыли, и это факт.
Так как же оценить проект? Способов существует много, в своей работе я выделил несколько базовых техник оценки:
- По аналогии с другими подобными проектами. Например, ваша компания собаку съела на создании различных соцсетей. На счету команды просчет примерно 100+ подобных проектов, а принцип их создания не очень-то отличается. В таком случае назвать примерную стоимость создания еще одной соцсети не составит труда.
- По принципу декомпозиции. Хорошо работает, когда клиент приходит с непонятным проектом (читать «с типом проекта, с которым раньше не работали»), и вам просто не с чем сравнивать. Что делать и куда бежать? Бежать не нужно, а вот что делать, подскажу. Декомпозировать! Разбейте проект на составляющие части исходя из того, как вы его собираетесь реализовывать, и оцените каждую часть отдельно. Затем суммируйте все полученные оценки. Предварительная сумма готова. Не переживайте, если в этом процессе вы не будете знать чего-то, ведь вы не одни в этой лодке, с вами как минимум BA и Solution Architect. Совет: для каждой из составляющих частей прописывайте предпосылки, из которых вы исходили, ставя оценку. Например, «этот сценарий можно воплотить с помощью микросервисной архитектуры ввиду требований к нагрузке». Таким образом, мы сможем объяснить клиенту наличие большего количества нулей в бюджете, чем предполагалось изначально.
- По принципу просчета risks and assumptions. Суть подхода заключается в том, чтобы прописать стоимость возможных вариантов решений и рисков для проекта от обратного. Зная минимально необходимый бюджет для проекта, можно дать клиенту выбор исходя из его ограничений. Например, многие API имеют особенности, которые предполагают минимальный порог входа в реализацию приложения.
- Поиск зависимостей и ограничений. Любая зависимость между функциональными частями проекта довольно часто означает не сумму оценок их независимой реализации, а произведение. Клиент должен понимать, что количество зависимых историй экспоненциально увеличивает стоимость как разработки, так и поддержки. Один мой клиент так увлекся добавлением различных бизнес-правил в систему, что реализация каждого последующего правила начала занимать в разы больше времени. Решением, к которому мы пришли, было пересмотреть весь накопившийся технический долг и создать новую версию системы.
- Bottom-up — оцениваем индивидуальные части проекта, а после собираем из них общую оценку. Если декомпозированные требования можно оценивать в равной степени сверху вниз, то метод «снизу вверх» позволяет проверить предыдущие оценки на прочность. Бывает так, что bottom-up оценка в несколько раз превышает обычную. Тогда эксперты признают, что в общей оценке не учли ряд деталей.
Готовим предложение для клиента: лайфхаки и техники
В какой бы форме клиент не получил оффер — на питчинг-сессии или в письме, — существуют универсальные лайфхаки и техники, которые помогут убедить заказчика и перевести его в категорию лояльных.- Метод контраста. Предлагайте клиенту несколько вариантов (оптимально — три): от простого, который будет стоить дешевле всего, до самого сложного (читать «дорогого»). Частая ошибка — отметать самый дорогой вариант с мыслью «Да ну, клиент все равно не согласится». Не нужно решать за клиента. Он делает выбор, а не вы. Неуверенность в самом дорогом варианте оправданна тем, что на психологическом уровне самое дорогое обычно прельщает меньше всего. Это можно обыграть в переговорах! Вместо того чтобы отметать этот вариант, сделайте так, чтобы самый оптимальный вариант — тот, на который вы делаете ставки — шел перед самым дорогим. На контрасте с самым недосягаемым предпоследний вариант будет казаться очень даже привлекательным.
- Совет. Клиенты не любят много думать и решать. Они хотят, чтобы за них все просчитали и решили, опираясь на заранее оговоренные требования. Вам же, как специалисту, будет не трудно порекомендовать один из вариантов и аргументировать свой выбор. На этом можно сыграть, ведь всегда есть как минимум одна альтернатива, которая устроила бы и вас, и клиента.
- Anchoring. Известный принцип, строящийся на «зацикливании» клиента на ранее названных цифровых значениях, что влечет за собой неадекватную оценку последующих значений. Как это проявляется в контексте переговоров с клиентом? Когда ему озвучивают вилку, например, 20 000-40 000, он запоминает первое число, затем ориентируется только на него и очень возмущается, если в итоге сумма получится больше, чем 20 000. Решение: всегда отталкиваться от большего числа (40 000) и строить вилку от него, оговаривая, что в результате при определенных условиях (быстрое согласование требований, прием проекта и т.д.) может получиться и меньшая стоимость. Если получится сделать за 20 000, вряд ли клиент расстроится. Для него это будет, скорее, приятная неожиданность.
- Принцип неопределенности. Градацию вилки всегда можно увеличивать, если вы не уверены в оценке. Согласитесь, оценка 28-32 (не важно, в какой мере исчисления) воспринимается более точной, чем 30-60. На последнюю клиент сразу же среагирует, что позволить вовлечь его в дальнейшую работу, прояснить требования или же отказаться от реализации рисковых сценариев.
Вот пара лайфхаков для работы с возражениями:
- Докопаться до причины. Максимально «раскрутить» «нет» клиента до первопричины при помощи «Почему?», «Как вы это видите?», «Что мы бы могли сделать?».
- Вывести на конструктив. После слов: «А вот в компании N мне предлагали сделать все в два раза дешевле» — важно вовлечь клиента в конструктивный диалог. «Мы не против сделать это дешевле для вас, но тогда давайте вместе подумаем, как это можно сделать». Проработайте варианты по ситуации: от «...чтобы было дешевле, нужно из скоупа убрать...» до аргументов, что дешевле лучше не делать. Важно показать клиенту, что вы с ним на одной стороне, а проблема — на противоположной. Отказывайтесь, если клиент не проявляет готовность сотрудничать или банально пытается манипулировать.
- Есть ли что-то вне коробки? Помимо очевидных возражений по поводу цены, всегда нужно прорабатывать менее явные: возможно, решение требуется несрочное, от части функционала можно отказаться, а клиент готов оставить видеоотзыв и поучаствовать в других SMM-активностях. Ищите скрытые возможности в каждой сделке. То, что кажется мелочью для вас, может оказаться бесценным для клиента.
Личный рекомендасьон: что почитать по теме
Тема Presale слишком обширная, чтобы ее можно было изложить в одной статье. На ДОУ существует много материала, который поможет лучше погрузиться в тему. Я же хочу поделиться must-have литературой, которая будет полезна для любого специалиста, вовлеченного в presale-процесс.- Карл Вигерс, «Разработка требований к программному обеспечению»
- Нил Рекхэм, «СПИН-продажи»
- Крис Восс, «Никогда не идите на компромисс. Техника эффективных переговоров»
- Гэвин Кеннеди, «Договориться можно обо всем! Как добиваться максимума в любых переговорах»
Итог
Presale-этап нельзя недооценивать, ведь это вложение в успешность вашего проекта и компании в целом. Даже если этот этап можно назвать скорее предпроектом, от его качественного планирования будет зависеть прибыльность основного проекта разработки. Усложнять все — подход и инструменты — нужно по мере необходимости, а оценивать — исходя из желаемого результата. Нужно также не забывать о том, что даже если сроки и бюджет ограничены, провести пресейл следует правильно, несмотря ни на что. Вовремя проведенный хороший пресейл лучше идеального, но проведенного с опозданием.Presale — это инвестиция, которая может быть рисковой, но доход от проекта, перед которым был проведен Presale, чаще всего в разы превышает потраченные усилия.
DOU
DOU – Найбільша спільнота розробників України. Все про IT: цікаві статті, інтервʼю, розслідування, дослідження ринку, свіжі новини та події. Спілкування на форумі з айтівцями на найгарячіші теми та технічні матеріали від експертів. Вакансії, рейтинг IT-компаній, відгуки співробітників, аналітика...
dou.ua