На старте любого проекта бывает пилот, а также серия показов, встреч, переговоров и обсуждений. Но почти всегда получается, что клиенту ваш продукт либо посоветовали, либо потенциальный заказчик попал под рекламу, либо увидел случайно и заинтересовался, либо ваши сейлы сделали марафон лести и убедили посмотреть продукт. Дальше ваша команда показывает продукт менеджерам клиента, ещё зачастую бизнес-пользователям и айтишникам. Но у всех более-менее крупных компаний еще до подключения бизнеса и ИТ-специалистов есть обязательный этап - отправка вендорам опросника о функциональных возможностях продукта и определение стоимости внедрения/пилота. Вот тут начинается веселье.
В этой статье я попробовал собрать советы, которые помогут вам оценить стоимость и продолжительность проекта по не слишком детальному техническому заданию или по поверхностным характеристикам систем клиента. Я занимаюсь проектами внедрения BI-решений на стороне вендора продукта Insight, поэтому примеры будут по этой теме.

Компании, которые хотят заменить или внедрить у себя BI-решение, обычно сперва прощупывают почву и рассылают опросники вендорам, интеграторам или размещают такие опросники на своих сайтах/платформах для конкурсов. Опросники представляют собой огромный набор функциональных требований к системе, чаще всего с разбивкой на группы критериев, например, работа с данными, безопасность, визуализация.
Почти все опросники заказчиков, которые получаем я и мои коллеги, заточены под платформу Power BI и ее функциональность. Даже был один опросник, где все функции DAX стояли отдельными строками и везде можно было выбрать да или нет. Также в опросниках бывает много пунктов, где очень скудное описание задач заказчика, и их можно трактовать разными способами. Конечно, все вендоры пытаются использовать эту информацию в свою пользу.
Какие ТЗ и требования я встречал
Клиенты любят присылать табличку с указанием своих источников данных. Это могут быть как различные типы файлов, так и API или базы данных и т. д. (одно название системы или файла и не более), примерное количество таблиц/представлений в источнике. Обычно дают информацию об объеме данных и, если повезет, о частоте обновлений. Для визуала присылают скрины своих старых систем без подробного описания, что и как происходит. Иногда прикладывают свои расчётные метрики (зачастую на DAX). Ещё бывают случаи, когда клиент присылает скрины своей модели данных, что практически бесполезно при оценке переезда на наше решение. Если повезёт, то клиент даст информацию о количестве пользователей и на кого ориентирован дашборд. Но это уже удача.
Совет. Как правило, для клиента главное - получить вашу оценку проекта быстро. Ему нужно в принципе определиться. Поэтому не тратьте месяцы на обратную связь заказчику.
Был случай, когда заказчик не очень ориентировался в том, что хотел заменять, но стремился заменить вообще все одним решением. Так как наша компания не является поставщиком облачных серверов (одним из важных условий клиента было, чтобы при закупке сразу покупались и серверы), то пришлось скреативить и сделать расчёт цен на мощности у партнёров, которые поставляют облачные серверы.
Совет. Если можете помочь заказчику в смежных областях, которые ему интересны, помогите.
Однажды один из клиентов прямо спросил, а почему два партнёра дали разные оценки сроков и стоимости внедрения, если будут делать одинаковую работу (разница по трудозатратам была более чем в квартал). Пришлось погрузиться в ТЗ, но так как до дедлайна оставалось всего несколько часов и у меня не было времени на уточняющие вопросы, глубокую проработку, то я решил, что стоит оценить верхнеуровнево, на основе опыта, а не подробностей проекта, и добавить процент на перестраховку по трудозатратам. Истина оказалась где-то по середине, и моя оценка была чуть ближе к менее громоздкой и продолжительной по времени.
Совет. При оценке не стоит перезакладывать ресурсы от всех возможных проблем, так как клиент вас просто не выберет из-за очень высокой цены и долгого срока выполнения проекта. Лучше дайте оценку в рамках ожиданий и далее обсуждайте дополнительные работы (если такие потребуются в ходе проекта).
Часто бывает, что ваша система не покрывает все хотелки клиента. Что делать, если вы можете покрыть только 90 процентов от потребностей или 70, или вообще меньше 50? Может быть, стоит сразу отказаться и отдать потенциального клиента конкурентам? Но это может быть не просто миллионный контракт, а крупная корпорация с тысячами пользователей, а такой отказывать не очень хорошо (если вы сами - не такая корпорация).
Совет. Сперва стоит оценить то, что ваша система может закрыть, как говориться, “из коробки” и затем добавить в оценку набор человекочасов тех специалистов (например, аналитиков или даже дизайнеров), которые будут “переосмыслять” задачу клиента и предлагать ему классные решения, которые могут быть даже привлекательнее изначальных запросов и уже закрываются вашей системой. Иногда можно и доработки системы включить в оценку, но здесь надо быть на короткой ноге с продуктовой командой, ибо не все хотелки клиента реально могут улучшить систему для конкуренции на рынке и для массового пользователя. Таким образом, у вас будет оценка с перезакладыванием рисков и переосмыслением задачи клиента в пользу подсвечивания плюсов вашей системы, так как не все используемые клиентом решения в реальности ему нужны или удобны. Их применение может быть обусловлено техническими возможностями “прошлой” системы, и вам стоит смело предлагать что-то иное. Это работает, если ваша команда аккаунтов смогла найти контакт с клиентом и вы не враги уже на этапе оценки. Такой подход даст дополнительный плюсик в ваши отношения с заказчиком, так как он будет видеть, что вы ради него готовы продумывать и другие направления его работы.
Что нужно иметь для оценки
Это источники, объёмы данных, частота обновлений, сколько требуется дашбордов/отчётов, какова целевая аудитория, сколько пользователей будет использовать систему и в каких ролях, есть ли методология расчётов показателей и др. Эти параметры помогают понять базовые вещи и дать приблизительную оценку проекта. Например, если у клиента 5+ источников, то это не очень простая интеграция, а если в качестве источника один Postgres, то задача сразу становится сильно легче.
Аналогично по всем другим пунктам. Например, если пользователи - топы, то мы делаем более статичные дашборды с малым количеством метрик, но очень красиво. Если пользователи - аналитики, то здесь главное, чтобы было много метрик, фильтров и в идеале self-service, что заметно отражается на перфомансе системы: много метрик, следовательно - много расчётов и много запросов в базу данных, из-за чего дашборд может тормозить в момент открытия или фильтрации.
Также всегда стоит запрашивать у клиента шапки таблиц от данных или подобное описание. Но мало кто делится сэмплами данных в принципе. Кроме того, у большинства очень много таблиц, что усложняет получение примеров таблиц заказчика. Конечно же, также стоит просить скрины дашбордов и описание переходов/фильтров на них, но многие не могут их прислать или присылают вам почти полностью замазанные скрины, что даёт возможность только понять, это боль или есть шанс реализовать функцию минимально.
Как работает калькулятор проекта

У нас в компании есть калькулятор проекта. Его можно собрать на любом ПО, в том числе и на Insight, на основе которого я делаю расчёты/оценки. Как это выглядит? Есть список специалистов и их ставки (себестоимость и коммерческая). Далее есть календарь по месяцам. В итоге получается матрица, где у каждого месяца можно поставить число дней специалиста. Да, специалистов проставляем в днях. Если нам нужны на проект Devops, тестировщик, дизайнер, бизнес-аналитик, технический писатель, low-code/BI-разработчик и дата-инженер, то проставляем предполагаемое число дней в нужные месяцы.
Лучше сразу продумать каскад, кто за кем стартует, т.к. не всегда все специалисты могут одновременно работать. Это важно в тех случаях, когда кому-то требуется 20 и более дней, что выпадает из рабочих дней одного месяца.
Также есть хитрость по поводу срока - всегда можно взять не одного специалиста (low-code-разработчика, например), а двух, и часть работ получится делать одновременно, что сократит срок реализации при одинаковой стоимости.
Cовет. Используйте дополнительные средства, где будет записана информация (калькуляторы, опросники, база знаний и др.). Так всегда всё будет под рукой, ничего не потеряется и не забудется.
В сухом остатке от прочитанной статьи у вас должно быть что-то приятное на душе. Надеюсь, что этот материал занял не слишком много вашего времени и не убил мозг терминами, сложными схемами/формулами. Возможно, те случаи из практики, которые я описал, вызвали у вас реакции типа: “А этот клиент не приходил ли и к нам?”, “А такое и правда бывает? Бред!” (если вам повезло сильнее). Приведенные мною советы действительно очень простые (что-то очевидно, что-то менее очевидно), но теперь они сформулированы в одном месте. А какие советы вы можете дать из своего опыта? Оставляйте комментарии.
*Статья написана в рамках ХабраЧелленджа 3.0, который прошел в ЛАНИТ осенью 2024 года. О том, что такое ХабраЧеллендж, читайте здесь.
aimfirst
Плюс за раздел <Какие ТЗ и требования я встречал>, ноль за остальную часть статьи.