«Я управляю оркестром»

В прошлой статье я говорил о том (Методология Projex), что суть Projex - не в создании процесса ради процесса, а в адаптации этого процесса под людей. Но для начала давайте разберемся: что вообще такое процесс?

Вот как его описывает Википедия (Wiki): повторяемая последовательность действий, направленная на достижение поставленной цели. Определений много, но я бы добавил к этому свое:

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

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

Самое интересное начинается тогда, когда сотрудник понимает: он не просто “ценный кадр”, а человек которому доверяют принимать решения. После этого процесс начинает ветвиться - появляются новые продукты, проекты, иногда новые люди в команде.

Как сказал герой фильма “Стив Джобс” (2015): “Музыканты играют на инструментах. А я управляю оркестром”. Я воспринимаю это так: не нужно говорить людям как работать - нужно дать им пространство для творчества и указать правильное направление.

Пример применения Projex на проекте в транспортной отрасли

Сразу оговорюсь: я показываю модель “AS-IS” - то, как методология работает прямо сейчас. Она продолжает развиваться и дорабатываться.

Сложность этого проекта была не только в разработке ПО. Нужно было состыковать сразу несколько процессов: закупку, сборку, пусконаладку на реальном транспорте - и уложиться в срок. Вот как мы с этим справились.

1. Планирование

Покажу Карту проекта для задачи по разработке плеера - инструмента отображения рекламы в транспорте.

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

Из этого мы понимаем проблему и цель проекта. Из опыта: если сразу описать заказчику как ты видишь решение - это здорово повышает уровень доверия. Главное чтобы предлагаемое решение было реалистичным и реализуемым силами вашей команды.

Карта проекта

Поле	Содержание
Проблема	Существует множество разных плееров, но нет централизации контента и его обновления в реальном времени
Цель проекта	Реализовать инструмент централизованного получения и передачи контента до конечных пользователей
Предлагаемое решение	Веб-приложение с административной панелью для заказчика с выводом на экран
Срок	2 месяца

После этого важно определить всех участников проекта. Это позволяет понять кто заказчик, кто исполнитель, кто подрядчик - и главное: какой интерес у каждой из сторон. Это не формальность. Если у стороны нет явного интереса в проекте - она не будет активно в нем участвовать. Иногда это повод задуматься: а нужна ли эта сторона вообще? Если без нее не обойтись, но интереса нет - ищите что предложить взамен. Не бойтесь договариваться: там такие же люди, которые тоже хотят получить что-то полезное.

Заинтересованные стороны

Сторона	Роль	Интерес
Компания - заказчик	Заказчик	Получить решение “под ключ”, интегрированное в транспортное средство
Компания - исполнитель	Исполнитель	Получить прибыль с продажи продукта и создать конкурентное предложение на рынке
Разработчик	Исполнитель	Пополнить портфель проектов, получить опыт работы с хранением и демонстрацией видео
Отдел пусконаладки	Исполнитель	(нет явного интереса - но можно предложить договориться с заказчиком о дополнительных работах, например ремонт транспорта на договорной основе)

В качестве сторон можно указывать кого угодно - от генерального директора до студента, только что вышедшего на работу.

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

Предварительные метрики

Область	Метрика
Отображение рекламы	Без задержек, автообновление и цикличность воспроизведения
Включение устройства	Автозапуск, подгрузка информации
Питание для панели	+24 Вольта

Все это аккумулируется в Карту проекта и дает возможность перейти к приоритизации.

2. Приоритизация

Важно понять в каких сроках живет заказчик - это опорная точка для расстановки приоритетов. Здесь начинают формироваться контрольные точки.

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

Например, при работе с плеером я сразу понял: нам нужно физическое устройство. А значит возникают вопросы которые надо проработать до старта, иначе потом они станут блокерами:

Как скоро придет оборудование для тестов? Нужно оповестить отдел закупок и согласовать сроки подачи заявки. Решение: согласуем с ними дату подачи заявки и ожидаемую дату поставки.
Нужна ли конструкторская документация и сборка? Если да - кто этим занимается и в какие сроки будет готов опытный образец? Решение: согласовываем сроки по MVP-образцу и документации.
Как устанавливать плеер на большое количество панелей? Очевидно - через единый образ и автоматическое обновление по CI/CD-пайплайну.

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

Из личного опыта: был у нас проект по автоматическому подсчету объектов на конвейере с минимальным бюджетом и полной передачей прав заказчику. Когда я спросил у руководства какую выгоду получим мы как компания - через пару дней взаимодействие с заказчиком свернули. Правильный вопрос в нужный момент сэкономил кучу времени и ресурсов.

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

Контрольные точки на этом проекте формировались из потребностей заказчика:

КТ 1 - Разработка административной панели
КТ 2 - Интеграция файлового хранилища (MinIO, S3)
И так далее

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

3. Распределение ролей

Мы знаем задачу и сроки. Теперь нужно определить команду. Для этого я формирую таблицу Роли проекта.

Наименование	Основные задачи
Руководитель проекта	Формирует документацию, анализирует конкурентов, формирует КТ и анализирует риски
Ведущий DevOps-инженер	Строит инфраструктуру системы, настраивает WatchDog и организует хранение данных
DevOps-инженер	Строит CI/CD-пайплайны, настраивает периферию, подключает устройства и готовит образы
Ведущий AI-разработчик	Готовит prod-версию ПО, проводит code review, разрабатывает архитектуру, формирует правила логирования и тестов
UI-разработчик	Разрабатывает клиентскую часть с возможностью выбора и демонстрации медиаконтента в онлайн
Закупщик	Анализирует, подбирает и закупает оборудование для монтажа у заказчика
Конструктор	Разрабатывает конструкторскую документацию на систему и физическую панель

Зачем переносить это на бумагу? В этой таблице есть скрытая логика.

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

Кто-то спросит: ты же говорил что каждый должен заниматься тем, что ему нравится - зачем тогда создавать границы? Резонный вопрос. Но я отвечу вопросом: зачем ставить двух людей с одинаковыми компетенциями на одну задачу? Эти “невидимые” границы нужны не для ограничения, а для защиты состояния сотрудника. Уставший человек не сможет работать с тем же интересом и темпом, что и отдохнувший.

4. Модульность

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

Ваша команда наверняка прошла немалый путь и накопила результаты, которые можно переиспользовать - возможно с небольшой доработкой. Чаще всего это чувствуется сразу: берешь задачу и думаешь “я же это уже делал”. Вот эти моменты и нужно замечать и использовать.

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

Как КТ устроены в проекте

Следующий этап - делим работу на контрольные точки. Об этом инструменте я впервые узнал из книги Павла Алферова “Проектное управление: как правильно делать правильные вещи” - и сразу понял насколько это сильный инструмент, которым многие пренебрегают.

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

КТ	Ответственный	Срок	Статус	Метрики	Критерии приемки
Что должно быть сделано и получено. Пример: Выпущен релиз MVP 1.0	ФИО исполнителя, отвечающего за статус выполнения	Срок, согласованный с заказчиком	Текущий статус - светофор (подробнее в первой части)	Показатели из реестра метрик	Словесное описание того, что требует заказчик

Важный момент: статус КТ может менять не только ответственный или руководитель, но и любой исполнитель задачи внутри КТ. Контрольная точка - это не одна задача, а блок задач, где ответственный выступает в роли “мини-руководителя”.

Декомпозиция

Ответственный за КТ - это не просто исполнитель. Он помогает распределять задачи между собой и командой. Я чаще всего назначал ответственным того, кто дольше всего работал в команде и знал все тонкости. Он брал к себе от одного до нескольких разработчиков, наставлял их, учился управлять - и при этом сам оставался полноценным исполнителем. Важно чтобы ответственный не превращался в “раздатчика задач” и не перекладывал всё на других - он такой же член команды, просто с небольшим инструментом управления.

Отдельно стоят задачи связанные с закупкой оборудования - за них отвечал я лично. Потому что временной лаг между подачей заявки и получением оборудования может вырасти в непредсказуемое количество времени, и это нужно держать под контролем. Требования были простые: доставлять по мере поступления, вычислительные компьютеры - в первую очередь. Подбор компьютеров начинался еще на этапе планирования - потому что то, что работает на ноутбуке или рабочем ПК, в prod-окружении ведет себя совсем иначе. Это классика.

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

Ход выполнения

Начинается выполнение задач. Здесь должно быть в меру ритмично: совещания, контроль выполнения и соответствия реестру метрик. Руководитель максимально включается в момент когда КТ переходит в желтый статус - его задача выправить ситуацию до того как она станет красной.

Желтый статус возникает когда разработчик столкнулся с чем-то, что явно отодвигает выполнение КТ за срок - сложной задачей, неожиданным багом. Переключение статуса может произойти на совещании или самостоятельно. И да, есть защита от синдрома “я все успею, осталось чуть-чуть” - это пороговый остаток времени. Как писал в первой части: ориентир 15-30%, на практике чаще всего это 20%.

Если все метрики в рамках КТ достигнуты - она закрыта. Если в процессе возникли проблемы - фиксируем в журнале блокеров.

Блокер

Поле	Содержание
Дата выявления	Дата обнаружения проблемы
КТ	Название контрольной точки
Выявил	Кто зафиксировал проблему
Описание блокера	Что происходит и почему возникает
Статус	Текущий статус по проблеме
Ответственный за устранение	Кто берется за исправление - исполнитель или руководитель

Заполнили, учли, исправили.

Что это дало

Все любят конкретику - вот результаты.

Показатель	План	Факт
Срок выполнения	2 месяца	1 месяц
Количество исполнителей	4	3
Количество правок от заказчика	-	2 раза
Время активной разработки ПО	2 месяца	1 неделя

Последняя строка требует пояснения: основное время ушло не на разработку, а на закупку и сборку. Разработчики сделали ПО за пару дней и выкатили в prod через CI/CD-пайплайн. Данные для разработки я собирал больше недели - а сама разработка заняла меньше. Две правки от заказчика - тоже хороший показатель: это значит что на этапе планирования мы правильно поняли задачу.

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

Что дальше

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

Projex на практике: как мы делали проект для транспорта и не сошли с ума