«Я управляю оркестром»
В прошлой статье я говорил о том (Методология 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-пайплайн. Данные для разработки я собирал больше недели - а сама разработка заняла меньше. Две правки от заказчика - тоже хороший показатель: это значит что на этапе планирования мы правильно поняли задачу.
Все это стало возможным потому что на старте каждый разработчик понимал что от него требуется и зачем.
Что дальше
В следующей части я расскажу об инструменте, который я разработал самостоятельно - он позволяет учитывать все описанные выше элементы в одном месте. Покажу как он выглядит и как применяется на практике.
