Что будет:

• Опишу свой подход к разработке ПО и выстраиванию бизнес процессов.

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

• Покажу, как шаг за шагом создавался отдел разработки.

• Расскажу, как распараллелил работу над продуктом между 10 бэкенд-разработчиками.

• Поделюсь некоторыми шаблонами артефактов.

Чего не будет:

• Новых инструментов. Я убежден, что дело не в инструментах, а в том, как их "готовить".

• Название компании, бренда, технических деталей — в силу NDA.

• Полноты описания. Если хочется чтобы я раскрыл конкретную тему - напишите свой вопрос в комментарии или в личные сообщения.

Мой подход и инструментарий этого проекта

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

В данном случае была уже работающая система (MES), которую нужно было заменить, были конкретные даты остановки фабрик. Это сделало особенно актуальными практики классического менеджмента: управление рисками, тщательная проработка требований. Итеративный подход, актуальный практически всегда, столкнулся с ограничениями из-за невозможности тестирования системы в окружении, идентичном production. А вот разработки клиента(CustDev) и фокуса на поиске UX-решений не требовалось. За два года удалось сформировать высокопродуктивную кросс-функциональную команду, которая использует большинство инструментов самостоятельно, без моего участия.

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

1. Правило: не переписываться по рабочим вопросам в личных сообщениях. Вся коммуникация ведётся в тематических групповых чатах.

2. Подход: на встречах я задаю вопросы, но большую часть времени говорит команда. Причём обсуждаются актуальные вопросы и блокеры, а статус фиксируется текстом в чате. Если нет вопросов, встреча заканчивается. Таким образом, у нас были суперпродуктивные ежедневные встречи продолжительностью 10–30 минут, даже при максимальном размере команды в 18 человек. Единственное важное правило — следить за тем, чтобы диалоги выносились на отдельные встречи.

3. Подход: я передавал фасилитацию встреч разным людям. Уже через полгода работы все привыкли к формату, и фасилитация не представляла сложности.

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

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

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

Ниже перечисленны инструменты

Управление проектом

• Lean: короткие итерации, визуализация процесса на канбан-доске и другие методы.

• Scrum: ежедневные короткие встречи, статусы, ретроспективы, еженедельное планирование, оценка задач в story points.

• Экспертная оценка на старте и прогноз сроков завершения по историческим данным (Reliable Scrum). Основой послужила книга Software Estimation: Demystifying the Black Art Стива МакКоннелла.

• Risk-Driven Development: реестр рисков, основанный на книге Waltzing with Bears Тома ДеМарко.

• OpenProject на собственном хостинге + кастомные отчёты в Google Sheets.

Архитектура и сбор требований

• Event Storming: встречи экспертов домена и инженеров для описания системы через события и модели данных.

• ADR: записи архитектурных решений.

• C4: диаграммы на разных уровнях в Miro.

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

Развитие отдела

• ИПР, матрица компетенций.

• Менторинг.

• Диаграммы описания бизнес-процессов и правила работы.

Практики разработки

• CI/CD: в ограниченном виде, без доступа к закрытому окружению клиента.

• Code Review, Gitflow.

• Тестирование: Unit-тесты, нагрузочное тестирование (JMeter, Grafana), UI-тесты (Playwright).

Технологический стек

• Backend: Python, Django, Dramatiq, Joeflow, RabbitMQ, PostgreSQL, Virtual IP, HAProxy.

• Frontend: Angular.

Хронология

Добрый день, Данил.

Меня зовут #### и я владелец небольшой ИТ фирмы. Нашел Вас на хабре. Нам необходима консультация для создания ИТ архитектуры для Веб Проекта где необходимо использовать либо опенсурс либо российские технологии для создания реалтайм проложения, соединения с ERP системой и ПЛК( производственные логические контроллеры),

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

Если у Вам было бы интересно, то прошу обратным сообщением указать стоимость консультации за 1час.

Началось всё с консультации и моей оценки проекта. Поскольку я долгое время занимался pre-sale в работе со стартапами, где не только выполнял приблизительные оценки масштаба задач, но и выступал в роли Solution Architect, разрабатывая технические решения, это помогло мне быстро разобраться в предметной области, понять масштаб проекта и выстроить конструктивный диалог.

Как мне позже сообщили, другие компании предлагали кастомизировать CRM-систему. Однако я оказался единственным, кто решил глубже изучить существующую систему, соединяющую ERP и ПЛК. Я наткнулся на аббревиатуру MES, узнал, что даже у 1С есть похожая разработка, и задал ключевой вопрос:

«Почему вы не хотите использовать готовые решения, например 1С?»

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

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

Этап 1. Запуск проекта, решения по технологическому стеку

Я провёл оценку проекта. Это была экспертная оценка в соответствии с канонами книги МакКоннелла Software Estimation: Demystifying the Black Art, подходящими для данного кейса: PERT, разделение плана и оценки, декомпозиция, анализ рисков.

Причём я изначально планировал сделать проект “под ключ”. И хорошо, что мы выбрали другую форму взаимодействия! На старте я не до конца понимал масштаб системы и глубину автоматизации. Клиент хотел вести разработку своей штатной командой.

Конфигурация получилась интересной: я и мой партнёр Сергей работали как подрядчики, руководя командой, находившейся в штате клиента. Первый этап мы отработали вдвоём. В качестве технического стека выбрали Python и Django.

Я настоял на том, чтобы у нас сразу был workflow engine. Анализ доступных решений показал, что большинство из них рассчитано на простые операции с минимумом ветвлений, либо это были проприетарные, громоздкие BPM-движки от IBM и других компаний. В итоге я нашёл подходящее решение — Joeflow. Этот выбор оказался удачным, хотя для стабильной работы в продакшене его пришлось дорабатывать.

Ещё возникла сложность с донесением подхода до остальных разработчиков. На старте я проводил парное программирование, выделяя бизнес-логику в отдельный слой. Через Joeflow это можно сделать очень красиво:

Плюс Joeflow сам генерирует такую схему на основе edges:

Таким образом, можно собрать все бизнес-требования на диаграмме в Miro, а затем написать изящный код, который отражает эту диаграмму один к одному. После этого можно сравнить диаграмму в Miro с диаграммой, сгенерированной Joeflow.

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

Так вот, идея оказалась слишком сложной для начинающих разработчиков и несколько затерялась в ходе реализации. Основная сложность заключалась в том, как её адаптировать для синхронных операций, ведь в Joeflow на каждый шаг создаётся задача в Celery/Dramatiq, что влияет на производительность системы.

Следующим принципиальным вопросом стала интеграция с устаревшей технологией OPC DA. OPC DA — это платформозависимая технология, которая использует библиотеки Windows. Существуют решения для подключения к OPC DA-серверу с Linux, но их применение было крайне рискованным из-за требований к производительности и отказоустойчивости.

Для сбора требований я решил начать с Event Storming. Нашёл человека с опытом на Getmentor. Следующую сессию, где мы уточняли весь бизнес-процесс, проводил уже сам. Использование новых фасилитационных практик было вызовом, но практика оказалась успешной, а видеозапись Event Storming стала важной частью онбординга для новых инженеров.

За две сессии мы собрали общую картину работы системы: от приёма Process Order из SAP до конкретных сообщений на PLC. В середине проекта провели ещё одну сессию, где уделили отдельное внимание терминологии и причинам возникновения разночтений.

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

Мы начали проект вдвоём, и через два месяца к нам присоединился ещё один начинающий разработчик. На начальном этапе работали без фронтенда — все демонстрации проводили через Django Admin. Для наглядности собрали там несколько дашбордов.

Этап 2: Найм и отладка процессов командной работы

Немного лирики. На ранней стадии проекта нам с моим партнёром удалось встретиться вживую и проработать вместе целый месяц. Мы сняли квартиру в Приэльбрусье. Утром у нас были тренировки на скалах, днём — работа, а на выходных мы ходили с палаткой на высоту для акклиматизации. На третьей неделе взяли выходной в пятницу, поднялись на Эльбрус, вернулись и уже в понедельник продолжили работать над проектом.

На мой взгляд, такой опыт очень важен и делает работу по-настоящему командной. Ярко ощущается принцип: 1 + 1 > 2.

Особенно запомнилась ретроспектива у озера. Это был август, тёплые вечера. Я завариваю китайский чай на берегу, а мы неспешно обсуждаем, что нам понравилось и что можно улучшить, рассматривая всё в двух разрезах: с точки зрения нашей поездки и с точки зрения проекта. Пожалуй, это был один из самых счастливых и продуктивных месяцев в моей жизни.

Возвращаемся непосредственно к проекту. Покажу свой подход к его оценке.

Экспертная оценка делится на две части. В первой я совместно с разработчиками оцениваю трудозатраты. Во второй — определяю, какая композиция команды необходима, и сопоставляю её с календарным планом.

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

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

Мы нанимали джунов, и поначалу я был настроен скептически. На старте у нас просто не было достаточного количества простых задач, которые они могли бы выполнять относительно автономно. Однако я решил отложить свой прошлый опыт и попробовать другой подход. Оказалось, что junior-разработчики могут быть даже продуктивнее, чем middle-разработчики. Да, им может не хватать знаний, но они компенсируют это вовлечённостью и интересом.

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

«Как понять, что человек работает мало?»

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

Сочетание подходов гибкого и регулярного менеджмента

Для контроля сроков завершения проекта я использую Reliable Scrum — инструмент, позволяющий статистически оценивать сроки завершения задач на основе исторических данных о скорости работы команды (или подкоманды). У нас выстроен процесс оценки задач с использованием единой шкалы, независимой от индивидуальной скорости разработчиков. Это даёт возможность учитывать различия в их продуктивности.

Поскольку объём работ на бэкенде был значительно больше, чем на фронтенде, прогнозирование сроков завершения осуществлялось именно по бэкенду.

Ещё одна из ключевых практик — Risk-Driven Development.

• Выписываем риски и в первую очередь прорабатываем то, что может нанести наибольший ущерб проекту.

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

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

Самое сложное в крупном производстве — наладить выпуск функционала в окружение клиента.

• Во-первых, это закрытые сети, так что про CI через GitHub можно забыть.

• Во-вторых, отсутствует стейджинг, идентичный продакшену. Производственная линия одна, и она работает без остановок.

• В-третьих, договориться о запуске MVP можно, но даже этот MVP окажется громоздким.

Тем не менее, сдаваться нельзя. Нужно шаг за шагом разбираться, какое окружение у клиента: что можно воспроизвести один в один, как симулировать работу систем с которыми происходит интеграция, как мониторить изменения в окружении и копировать их. Именно здесь скрыто 80% возможностей для увеличения скорости поставки ценности. Причём на всех этапах:

• Во время разработки — разработчики могут проверять работоспособность нового функционала с минимальными временными затратами.

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

• Во время поддержки системы — уменьшается время, необходимое для воспроизведения и устранения проблем.

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

На следующем этапе мы планируем договориться с клиентом о создании сервера внутри его сети, с которого можно будет запускать UI-тесты.

Этап 3. Расширение команды

Отдельный вопрос — как я организовал параллельную работу 10 бэкенд-разработчиков.

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

Были ежедневные сессии, где можно было увидеть друг друга, задать вопросы, назначить встречи в малых группах или один на один. Встреча длилась 15–30 минут, без воды.

Также была отдельная еженедельная встреча для планирования. Затем мы разделили её на четыре отдельных сессии (три для бэкенда и одну для фронтенда).

На планировании происходит оценка задач, и разработчики берут в работу столько, сколько могут успеть сделать за неделю. Классика Scrum.

Процесс оценки задач

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

Сложности декомпозиции задач

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

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

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

Итоговая команда

В итоге мы вышли на состав из 17 человек:

• 10 бэкенд-разработчиков

• 2 фронтенд-разработчика

• Владелец продукта

• 2 аналитика

• Архитектор

• DevOps

• Менеджер проекта

Результаты расширения

На графике скорости видно, что среднее значение выросло с 34 до 53 пойнтов. Прирост на 35%. Для увеличения числа разработчиков с 4 до 9 человек — это очень хороший результат.

Процесс разработки

Весь процесс разработки отразили на канбан-доске. Он состоит из трёх частей:

1. Аналитика.

2. Разработка

3. Демонстрация, тестирование, развертывание

Ролевая модель

Среди разработчиков также есть дополнительные роли — ментор и ревьюер кода. Эти роли появились естественным образом через год активной разработки, когда junior-разработчики, писавшие проект с самого начала, окрепли, насмотрелись на разный код и стали готовы давать обратную связь другим.

Я запустил процесс оценки компетенций разработчиков и выработки ИПР. За основу взяли систему уровней Avito и добавили вопросы про опыт в конкретных технологиях.

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

Ниже представлена ролевая модель, которая описывает текущее положение вещей. Один человек может занимать несколько ролей.

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

Тогда можно создавать кросс-функциональные команды, ориентированные на разные ценности, и делегировать им ответственность за весь цикл создания и поддержки ценности.

Это то, что ещё предстоит сделать.

На картинке ниже — текущий расклад.

Этап 5. Нагрузочное тестирование и запуск

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

Мы начали с ручного тестирования, чтобы тестировщики могли погрузиться в предметную область и функционал. Уже через пару недель они начали автоматизировать свою работу разными способами: создавали коллекции в Postman, писали UI-тесты.

Перед запуском мы столкнулись с проблемами нагрузки. В это время я прилетел в Ставрополь к партнёру, и вместе с ним нам удалось собрать окружение для нагрузочного тестирования. Мы нагрузили систему уже имеющимися сценариями запросов и смогли воспроизвести проблему.

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

Я был очень рад поработать с каждым в этой команде. Мы вместе создали по-настоящему крутой продукт. Благодарю каждого!

Спасибо, что дочитали до конца! Пишите вопросы в комментариях или личные сообщения.