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

---

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

• Как скоро придет оборудование для тестов? Нужно оповестить отдел закупок и согласовать сроки подачи заявки. Решение: согласуем с ними дату подачи заявки и ожидаемую дату поставки.

• Нужна ли конструкторская документация и сборка? Если да — кто этим занимается и в какие сроки будет готов опытный образец? Решение: согласовываем сроки по MVP-образцу и документации.

• Как устанавливать плеер на большое количество панелей? Очевидно — через единый образ и автоматическое обновление по CI/CD-пайплайну.

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

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

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

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

• КТ 1 — Разработка административной панели

• КТ 2 — Интеграция файлового хранилища (MinIO, S3)

• И так далее

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

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

---

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

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

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

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

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

---

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

Блокер

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

Что это дало

---

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

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

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

Что дальше

---

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