Neoflex — компания‑интегратор (некоторые «хаброэксперты» с оттенком пренебрежения называют такие компании «галерами»), которая решает конкретные проблемы заказчиков, занимается прикладной разработкой «под ключ». У нас в работе находится одновременно много проектов на разном стеке и постоянно появляются новые, так что сотрудники обычно не скучают, разгребая годами тонны легаси или разрабатывая очередное широко известное в узких кругах мобильное приложение.
Эта статья, надеюсь, будет интересна тем, кто работает на проектах, но не знает, с чего всё начинается и что предшествует старту проекта. А может быть, вы грустите над своими задачами и хотите присоединиться к команде с более прогрессивными идеями? :)
Чтобы проект успешно завершить, нужно его начать :‑). А чтобы начать, нужно его продать. Я вхожу в пресейл‑команду внутри центра компетенций Big Data Solutions в качестве технического консультанта (архитектор, разработчик, иногда и системный аналитик) и уже накопил интересный опыт наших «болей» на этом пути пред‑продаж и даже разработал с коллегами общий алгоритм действий для подобных команд.
С чего вообще начинается наша работа? Сейлз‑менеджеры общаются с действующему и потенциальными заказчиками, если находят что‑то по профилю нашего центра компетенций (построение/миграция DataLake/хранилищ или витрин данных и/или BI‑отчётности), приходят к нам с более или менее (чаще «менее», чем «более») чётко сформированными требованиями. Центр кометенций назначает одного ответственного за пресейл (пресейл‑консультанта), тот запрашивает себе в помощь экспертов от DevOps, аналитики, разработки и тестирования (как правило, пресейл‑консультант сам является экспертом в одной из этих областей), возможно, кого‑то ещё. Желательно, чтобы эксперты обладали большим проектным опытом и могли посвятить пресейлу несколько следующих дней: сроки на подготовку ответного предложения, как правило, очень сжатые.
Дальше мы (команда пресейла) приступаем к своей части работы:
анализируем требования от заказчиков;
устраиваем внутрикомандный брейншторм, чтобы услышать всех, подискутировать – кто и как трактует поступившие требования. Этот пункт необязательный, но в ходе дикуссии мы делимся знаниями и экспертизой с новичками;
собираем требования (задаём заказчику ряд уточняющих вопросов, получаем ответы и так возможно несколько итераций);
готовим PoC и проводим презентацию.
Здесь, в зависимости от уровня доверительности отношений компании или конкретного менеджера с заказчиком, возможные варианты общения такие: по электронной почте; во время открытого телемоста со всеми заинтересованными подрядчиками; или в ходе сессии, созданной исключительно для нас. Последний вариант, безусловно, самый интересный, потому что можно:
почувствовать степень вовлеченности заказчика в проект;
вступить в продуктивную дискуссию; выявить иногда проблемные зоны заказчика, о которых он, возможно, и не догадывается на старте;
уточнить его предпочтения по архитектуре и техническому стеку;
понять уровень технической экспертизы, чтобы не предлагать решения, которые он не сможет поддерживать;
и, как следствие, подготовить наиболее корректную оценку наших трудозатрат и коммерческое предложение.
Иногда подобных сессий может быть даже не одна.
Первичные требования от заказчиков — это зачастую большая боль, ведь они могут быть сформулированы самым общим образом буквально в нескольких абзацах. Вот пара реальных примеров:
Пример 1:
Идентификация возможностей использования методов анализа данных и визуализации для повышения операционной эффективности и принятия решений в компании.
Оценка существующей инфраструктуры данных и рекомендации по улучшению для обеспечения оптимального управления данными, их хранения и доступности.
Переход существующих BI‑дэшбордов с <инструмент 1> на <инструмент 2> для использования передовых возможностей визуализации и аналитики в <инструменте 2>.
Создание BI‑дэшбордов на основе данных: обеспечение быстрого развития BI‑дэшбордов и отчетов для оперативного получения информации с целью принятия обоснованных решений.
Унификация данных: интеграция данных из различных систем, включая Oracle и Salesforce, в единый фреймворк, например, Microsoft Fabric.
Предоставление экспертного сопровождения по проектированию архитектуры данных и рекомендации наиболее подходящей структуры для среды данных университета.
Встраивание BI‑дэшбордов и отчетов в веб‑порталы компании для удобного доступа и использования заинтересованными сторонами.
Создание DataLake/DataMart с упрощенной структурой данных из таблиц Oracle, Salesforce и других приложений, чтобы бизнес‑пользователи могли легко создавать отчеты на основе упрощенного DataLake/DataMart.
Пример 2:
Тут всё несколько лучше, но тоже без особой конкретики («Делайте то, что нужно делать, а что не нужно делать — не делайте»).
Основные функциональные требования к корпоративному хранилищу данных (КХД):
КХД должно содержать данные из ключевых информационных систем компании (перечень в приложении — малоинформативные внутренние наименования систем);
Хранение информации за много лет, возможно, в будущем нужно будет включить архивирования определённых периодов — реальная формулировка была настолько косноязычна, что её пришлось переделать, чтобы сохранить анонимность заказчика.
Основные нефункциональные требования к КХД Доступность 24/7, требования к простою и количеству одоновременно активных пользователей, возможность масштабирования, реализация на российском ПО либо open‑source решениях — занимали куда больше места, чем требования функциональные.
Требования ИБ к КХД:
Аутентификация и авторизация;
Доступ к системе <верхнеуровнево описаны ограничения ролевой модели, выставлено требование о размещении КХД внутри сети компании, физически – в помещениях с ограниченным доступом>;
Данные: <срок хранения, архивирование, шифрование – без указания алгоритма>;
Физический доступ. Инфраструктура находится в помещениях с ограниченным доступом;
Требования к журналированию событий безопасности: <Далее перечислены пункты, касающиеся журналирования: создание / изменения пользователя, попытки логина, протоколирование изменений в данных>.
Примечание 1:
Эта информация была опубликована на общедоступных площадках для запросов предложений. Я лишь скрыл некоторые подробности, которые могут деанонимизировать клиентов.
Примечание 2:
Исходя из требований, сформулированных подобным образом, мы часто предлагаем провести предпроектное обследование с целью понять, какие именно данные требуется хранить, в каких разрезах и за какие периоды, потому что иначе точность всех оценок равна плюс‑минус трамвайной остановке.
К счастью, большинство заказчиков присылает довольно развёрнутые стартовые требования. Тем не менее, это не означает, что они всегда конкретные и недвусмысленные. Чем запутаннее требования, тем интереснее их анализировать. При этом бывает, что разные пункты требований по‑разному интерпретируются участниками пресейл‑команды. В таком случае мы либо сводим наши точки зрения к единой, либо готовим соответствующий вопрос, чтобы снизить неопределенность.
А вот это — примеры наших типовых вопросов к бизнесу:
С какими проблемами сталкиваетесь при формировании отчетов? (например, есть неактуальные сведения (нет единой версии правды), дубли информации, часть данных не попадает в отчеты, есть временная задержка (отчет долго формируется или длительная загрузка актуальных данных)?
Данные в отчетах должны быть по состоянию на текущую дату или за предыдущий день (T-1)?
Как часто необходимо вносить изменения в формы отчетов? Какие это изменения?
Какие категории пользователей ипользуют отчеты: руководство, менеджеры, аналитики данных... Какое количество пользователей? Какие подразделения? Какой уровень владения инструментами?
Есть ли ролевая модель для доступа к отчетам, витринам?
Что хотят видеть пользователи: графики, витрины данных, отчеты в формате doc, excel...
Какие BI‑инструменты используются сейчас? Какие требования к BI‑инструменту?
Вопросы к IT:
Объем данных, которые имеются в настоящий момент, годовой прирост.
Примерное количество источников и потребителей, которые нужно включить в разрабатываемое DWH либо переключить на новое.
Типы источников — структурированные/реляционные/медиа/стриминг/кубы. На каких технологиях построена текущая инфраструктура?
Требования к загрузке — batch/near real time /гибрид
Есть ли внешние интеграции (например, с сайтами регуляторов для загрузки/выгрузки), которые будут в составе проекта)?
Для ETL — допустимо ли применение хранимых процедур, или лучше всю логику реализовывать отдельно, вне БД?
Требуется ли реализовывать деперсонализацию, маскирование данных для стендов разработки/тестирования?
Могут ли в источниках вноситься изменения в данные прошедших периодов? Если да, то на какую максимальную глубину?
Горизонт хранения данных — за какой период требуется хранить данные, какое обслуживание необходимо (удаление/перенос в архив)
Планируется ли развертывание стендов разработки, тестирования, uat (или разработка на стендах исполнителя)?
Какое серверное оборудование имеется или надо предложить рекомендации к его закупке?
Что можно предлагать в качестве ПО (open source, российские решения)?
Рассматривается ли стек Hadoop / выход в облака?
Какие предпочтения по выбору оркестратора запуска ETL/ELT?
Нужен ли BI/какой‑либо веб‑интерфейс для построения отчетности?
В случае миграции с одного хранилища на другое: Как долго допустима параллельная работа двух DWH?
Вопросы по качеству данных:
Каковы ваши текущие проблемы с качеством данных?
К примеру, отсутствующие значения, повторяющиеся записи, несогласованные данные, неправильные типы данных и т. д.
Или более высокоуровневые проблемы: необходимость отчетов или сумм и т. д.
Как проблемы с качеством данных влияют на ваши бизнес‑операции и принятие решений?
Как вы в настоящее время измеряете и контролируете качество данных?
Какие средства контроля качества данных у вас есть?
Каким правилам качества данных должен следовать инструмент?
Например, существуют ли какие‑либо конкретные стандарты, которым должны соответствовать данные (например, отраслевые правила, политика компании)?
Каковы ваши долгосрочные цели в области качества данных?
Хотели бы вы видеть только технические проверки, которые покажут что миграция прошла успешно и данные совпадают с исходными,
или же следует проверить качество данных на соответствие определенным стандартам, форматам, улучшить текущее качество данных?
Каким бы вы хотели видеть процесс обработки выявленных проблем в данных?
Нужно ли исправлять данные? Что делать в случае, если данные явно некорректны, но нет понимания, как их исправить (к примеру, в поле номера телефона 71111111111)
Каково ожидаемое время выполнения работ по выявлению и устранению проблем с качеством данных?
В случае срабатывания контролей качества данных на сыром слое, нужно ли строить дальнейший lineage, витрины?
Если витрины построены на данных, в которых обнаружены инциденты, нужно ли автоматически перезапустить процесс построения витрин данных после исправления ошибок?
Какие ресурсы сервера вы готовы выделить под работу инструмента Data Quality?
Если вы считаете, что это прямо нечто базовое, то вы не ошибаетесь. Полный перечень вопросов, которые мы накопили за всю историю, безусловно, гораздо обширнее, но конкретному заказчику мы отправляем только часть из них, потому что какая-то информация всё же содержится в изначальном запросе предложений.
Получив в том или ином виде ответы на наши вопросы, мы уходим готовить оценку трудозатрат в разбивке по этапам и подэтапам работ, определяя на каждой стадии перечень артефактов, которые должны стать её результатом. Например, архитектурное решение, BRD, стратегия тестирования, разработанные потоки заполнения витрин или дэшборды в BI. Иногда (в первую очередь, для себя) мы прикидываем количество специалистов и их грейды, которые нам потребуются на том или ином этапе. Таким образом сразу подготавливается предварительная версия календарного плана-графика проекта, который мы сможем предложить заказчику (или сравнить наши оценки с его ожиданиями). В обязанности пресейл-консультанта входит окончательно верифицировать оценку и, если экспертная команда не может прийти к единому мнению, выступить арбитром в обсуждении и даже настоять на своём варианте.
Все неопределенности на стадии оценки либо прописываются в ограничения (допустим, интеграция с не более чем X источниками, из которых мы будем забирать Y таблиц; обезличивание данных производится силами заказчика), либо закладываются в риски проекта с помощью повышающего коэффициента. Второй вариант, конечно, не лучший, ведь тогда мы можем получить оценку реализации проекта в 40 млн рублей там, где заказчик хотел потратить 20. А не сболтнул ли я в этом абзаце чего лишнего?
Что может снизить наши трудозатраты и, как следствие, общую стоимость проекта?
Во‑первых, это люди. Большинство экспертов в нашей компании имеет за плечами ряд успешных проектов в той или иной сфере, что позволяет избавить заказчика от роли подопытного кролика и стартовать проект с пониманием того, что и зачем мы делаем. При этом хорошее упражнение — периодически вспоминать глобальные цели проекта и бизнес‑боли заказчика.
Во-вторых, конечно, чётко прописанное техническое задание, из которого будет ясно, что нам нужно будет в итоге реализовать, скажем, 15 BI-дэшбордов на основе 200 атрибутов, обновляемых ежедневно, а глубина просмотра данных не будет превышать 12 месяцев. Однако, в зависимости от задачи, мы эффективно её решаем использованием самых передовых методологий и практик, таких как agile (scrum, kanban, SAFe), waterfall и т.п.
В-третьих, готовность использовать наши акселераторы. Это ещё не конечные продукты, которые уже можно продавать отдельно, но некие наработки, например, генератор scala-кода или проверок качества данных, которые создадут первичный код, и дальше мы его сможем быстро «доработать напильником». За счёт этого заказчик получает возможность сократить сроки проекта и его стоимость.
В-четвёртых, наш проектный опыт, который позволяет быстро предложить архитектуру и обосновать её целесообразность, а в некоторых случаях может избежать изобретения велосипедов и принятия принципиально неверных решений.
Для сложных или значимых пресейлов иногда мы создаем демо-стенды или прототипы, на которых можно наглядно показать особенности и эффективность предлагаемого нами решения на конкретных бизнес-кейсах (например, лямбда-архитектуру для DataLake). Эти кейсы мы либо адаптируем сами, выбирая их из типовых задач из нашей проектной практики, либо реализуем в том или ином виде просьбу заказчика. Готовые демо-стенды мы можем использовать повторно для схожих проектов.
Пару раз лично мне как пресейл-консультанту приходилось доставать из пыльного угла шкафа пиджак и выступать с защитой нашего предложения на очном мастер-классе в офисе заказчика (не могу удержаться от цитаты: «желательно – в июле, и желательно – в Крыму»). Один из рецензентов черновика этой статьи с обидой прокомментировал предыдущее предложение, дескать, можно ошибочно подумать, будто мы – типичные «красноглазики», сидим в подвале и не выходим к людям на переговоры – нет, просто я красноглазик не люблю пиджаки.
Тут уж могут задать самые каверзные вопросы: например, одного из заказчиков очень интересовало количество проверок качества данных, которые мы реализуем на проектах, и это была прямо‑таки его idée fixe — реально, он хотел несколько тысяч (!). Несмотря на довольно скромный поток данных, такое количество проверок (включая межтабличные) серьёзно снизило бы скорость загрзуки данных в хранилище.
Другой же, отчаянно не доверяя внешним консультантам, хотел самостоятельно развернуть кластер Spark — а также HDFS, Jupyter, Hue и Hive — в Kubernetes, вопреки рекомендациям наших DevOps‑инженеров (в итоге наступил на ряд грабель и зауважал нас).
Заканчивается наша работа подготовкой итогового коммерческого предложения — за это ответственен сейлз‑менеджер совместно с пресейл‑консультантом, — в котором помимо коммерческих условий, обязательно фиксируются цели и задачи проекта, результаты, формат выполнения работ, основные этапы, их продолжительность в календарных днях, трудозатраты в человекоднях в разбивке по грейдам, а также перечислены категории специалистов со стороны заказчика, которые на каждом этапе будут предоставлять нам информацию, согласовывать проектные решения и участвовать в приёмо‑сдаточных испытаниях.
В обязательном порядке прикладывается портфолио релевантного проектного опыта, референсы или презентация команды ( со звёздочками на погонах с сертификатами от ведущих разработчиков ПО), которую можно привлечь к выполнению проекта.
Все артефакты, созданные на этапе пресейла, складываются и хранятся в единой системе нашей компании, что в дальнейшем упрощает нам подготовку оценок, архитектур, презентаций и т. п. для схожих проектов.
Что в итоге.
Деятельность пресейл‑консультанта противоречива.
С одной стороны, ‑новый проект — новые вводные и вызовы, которые позволяют расти. Вокруг столько экспертов, новичков с горящими глазами, а каждый пресейл — это соревнование, в котором ты либо выиграешь, либо проиграешь. Нам нравится это делать и мы всегда рады это делать!
С другой — надо сказать, что это похоже на венчурные инвестиции: доля пресейлов, которые в итоге станут проектами, весьма невелика и едва ли дотягивает до 10%.
На этой работе (впрочем, как и на любой другой) можно выгореть, видя, как твои усилия раз за разом не приносят значимого результата, но это лишь на первый взгляд. В бизнесе конверсия 10% считается достаточно приличной, однако мы как индивиды хотим всегда «всё и сразу». Чтобы было не очень обидно за впустую потраченные усилия, время от времени состав экспертной команды ротируется. Таким образом, мы ещё и наращиваем круг сотрудников, которые могут подхватить эту активность, если внезапно все ведущие эксперты окажутся заняты. Ведь зачастую в случае подписания контракта ответственный за пресейл становится тимлидом или архитектором в проектной команде.
И в этом тоже есть свой резон: этот человек уже, во‑первых, погружен в контекст задачи, во‑вторых, успел познакомиться с кем‑то из команды заказчика, что повышает шансы на общий успех проекта.