«Стоит идее завладеть мозгом…»

Когда я только начинал выстраивать процессы внутри команды, я экспериментировал с различными подходами: Agile (в основном Kanban), доски в Jira, ретроспективы по понедельникам и пятницам. Работа двигалась, но достаточно тяжело: большинство этих методологии сконцентрированы на процессе, а не на людях, которые в нём работают. Другие руководители в компании говорили, что я слишком мягок со своими сотрудниками и многое им позволяю. Но так или иначе именно это дало импульс в разработке — у нашей команды уже более 6 реализованных продуктов.

В процессе управления командой я выбрал то, чего некоторые руководители боятся выбирать. Я выстроил с сотрудниками доверительные отношения (дошло до того, что создали общий сервер в Minecraft и играли на нем) и старался поддерживать их как в рабочих, так и в личных делах. Параллельно я формировал идеологию переиспользования отдельных частей систем в других разработках. Например, собственный граббер для онлайн-видео не только снизил потери кадров и ошибок во всех системах, но и позволил оперативно интегрировать его в другие разработки — так появились инструменты для записи видеофайлов, фильтрации видео и ряд других.

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

Так появилась идея Projex, в основе которой лежит простая мысль:

_Процесс подстраивается под человека, а не человек под процесс.

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

Немного о себе

Меня зовут Ричард, и я руковожу командой CV-разработчиков и DevOps-инженеров. Построил команду с 3 до 10 человек и увеличил количество продуктов направления с 2 до 8 - все они уже проходят опытную эксплуатацию на городском транспорте. Часть продуктов мы уже продали, и они активно используются заказчиками.

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

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

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

Почему существующие подходы меня не устроили

Agile. Да, гибко и итерационно. Но если копнуть глубже — команда живёт в состоянии постоянной неопределённости. Разработка систем компьютерного зрения достаточно трудоемкая задача: любое изменение чаще всего затрагивает большую часть ПО, а обучение одной модели может занимать до 2 — 3 дней в зависимости от объёма данных. В таких условиях постоянно меняющиеся приоритеты только усугубляют ситуацию: бэклог пухнет, ощущения движения к конкретной цели нет. У каждого из моей команды висело в среднем по 6+ задач в высоком приоритете и ещё 3 — 4 в бэклоге. Планирование в классическом Agile можно сказать отсутствует. В долгосрочной перспективе это выматывает людей — отсюда выгорание и текучка. Мы применяли Kanban, но суть от этого не менялась: задач было огромное количество, сроки постоянно сдвигались вправо, а часть из них и вовсе закрывалась без результата из-за потери актуальности.

Waterfall. Полная противоположность. Всё расписано, все роли закреплены, каждый знает своё место. Звучит хорошо, но на практике человек годами делает одно и то же, не имея возможности вырасти в направлении (так было у моего друга, он просто ушел в Сбер, так как не видел роста), которое ему реально интересно. А именно из интереса рождаются лучшие решения — это я знаю точно по своей команде. Этот подход мы даже не рассматривали всерьёз: он ограничивает творчество, а практика показывает — дай людям пространство, и они будут творить.

PRINCE2. Пожалуй, самый зрелый из трёх. Чёткие процессы, артефакты, зоны ответственности — всё на месте. Но роли снова формируются под проект, а не под человека. Чем интересуются люди в команде, что им хочется развивать — PRINCE2 этому не учит. Это сам решает руководитель. Система хорошая, но человека в ней нет. Коллеги из соседних отделов пробовали интегрировать этот подход - в итоге продукт фактически ушёл в legacy, и от его доработки отказались. Нам такой сценарий тоже не подходит.

Что такое Projex и из чего он состоит

Projex строится на четырёх элементах, которые работают в двух парных связях — как буква X:

• Планирование — Приоритизация — сначала строим дорожную карту, потом правильно расставляем задачи внутри неё;

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

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

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

На старте проекта я формирую Карту проекта — один документ, в котором зафиксированы проблема, цель, решение, первичный вариант метрик и заинтересованные стороны.

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

Из моей практики. На текущем проекте — ПО для вычислительного комплекса транспортного средства — нам изначально ставили срок пять месяцев. Мы реализовали первую версию с 1 апреля по 20 мая, то есть меньше чем за два месяца. Справедливости ради, первый месяц ушёл на планирование: ТЗ со стороны руководства изначально было размытым, и мне пришлось самостоятельно выстраивать понимание того, что требуется реализовать. После этого я вместе с двумя ведущими разработчиками расписал план, донёс его до команды - и мы уложились в срок. Именно это планирование дало результат: каждый разработчик с первого дня понимал не только свою задачу, но и её место во всей архитектуре продукта.

Приоритизация по срочности

Каждая контрольная точка живёт в одном из трёх статусов:

Пороговый остаток — показывает то срок, в который требуется подключаться руководителю, если не было решено ранее. Значение задаётся в начале каждой задачи в зависимости от её сложности и опыта исполнителя. Ориентир: 15–30% от общего времени, но чаще всего это будет 20%.

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

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

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

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

Здесь ещё одно ключевое отличие Projex от всего, что я видел раньше.

Роли не закрепляются жёстко за людьми — они назначаются каждому сотруднику в зависимости от проекта. Для удобства на уровне отдела формируется Карта ролей — документ, в котором описаны все возможные роли. У каждого сотрудника есть профиль с тремя блоками:

• Могу — то, что уже умею и делаю хорошо;

• Хочу развивать — направления, которые мне интересны;

• Не моё — где я работаю неэффективно.

При назначении на задачу я смотрю на пересечение «Могу» и «Хочу развивать». Это зона, где человек будет работать быстро и с удовольствием.

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

Живой пример — как бывает хорошо. В моей команде есть разработчик, который около десяти месяцев занимался компьютерным зрением. Когда мы запустили проект вычислительного комплекса, он сам проявил интерес к оптимизации запросов и производительности — области, в которой раньше не работал, но очень хотел разобраться. Я дал ему эту зону. В итоге он оптимизировал скорость всех запросов с 100 мс до 5 - 15 мс - в десять раз. Это случилось не потому, что я поставил его туда по штатному расписанию, а потому, что он сам этого хотел, и я это увидел.

Живой пример — как бывает плохо. Был и обратный случай: я поручил коллеге интегрировать телеметрию в его часть разработки, не учтя, что он не только не знал как это делается, но и был загружен другими задачами, от этого совершенно не хотел браться за эту. В итоге мы потратили около трёх недель, чтобы получить хотя бы минимальный результат — который в итоге так и не был использован у заказчика. Это классический пример назначения «по удобству», а не по способностям.

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

Модульность

Последний элемент, который замыкает систему — модульность.

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

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

Схема работы руководителя

Ниже — последовательность действий руководителя от старта проекта до его закрытия.

Разберем каждый шаг.

Шаг 1 — Анализ задачи. Большинство руководителей хотят быстрее перейти к делу и пропускают его или делают формально. Но именно здесь закладывается фундамент: если ты не можешь сформулировать проблему одним абзацем и метрику успеха одной строкой — тогда стоит ли вообще делать эту задачу? И точно не сможешь объяснить её команде.

Шаг 2 — Согласование с заказчиком. Карта проекта — это твой персональный договор с проектом. Ты должен четко понимать все тонкости проекта и как он будет устроен. Когда заказчик подписывает или явно подтверждает Карту — у тебя появляется точка отсчёта ([[#Планирование]]). Все последующие изменения требований фиксируются относительно неё. Кто-то назовёт это техническим заданием (ТЗ) — по сути так и есть. Можно использовать что угодно в данном шаге, но главное чтобы исполнители понимали, что от них хотят.

Шаг 3 — Назначение ролей. Здесь важно не перепутать удобство с эффективностью. Удобно поставить на задачу того, кто уже делал это раньше — он справится быстро и без вопросов. Но если человеку это неинтересно, через несколько таких задач подряд он начнёт выгорать. Принцип «Могу + Хочу развивать» ([[#Распределение ролей]]) немного медленнее на старте, но даёт значительно больший импульс в перспективе.

Шаг 4 — Формирование контрольных точек. КТ — это не просто вехи в календаре. Каждая КТ должна давать осязаемый результат и с конкретным сроком ([[#Приоритизация по срочности]]). Размытая КТ — это гарантия споров при закрытии. Поэтому пороговый остаток и метрики фиксируются сразу, до старта работ.

Шаг 5 — Декомпозиция. Декомпозицию должен делать исполнитель, а не руководитель. Руководитель создает КТ и указывает срок к ней - а исполнитель сам разбивает это на задачи и оценивает их. Во-первых, он лучше знает как это делается. Во-вторых, он берёт на себя ответственность за оценку — это принципиально меняет отношение к срокам. Задача руководителя здесь — проверить что декомпозиция реалистична и не противоречит целям КТ. В данном шаге руководитель, только может подсказать исполнителю, какую базу он может брать за основу при реализации КТ — это он может указать в описании к КТ ([[#Модульность]])

Шаг 6 — Исполнение и мониторинг. Если КТ в зелёном статус — не трогаем. Желание руководителя постоянно проверять как дела в зелёном статусе — это не контроль, это недоверие. Оно разрушает автоматизм и снижает мотивацию быстрее, чем любые внешние факторы.

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

Красный статус — срок нарушен (и это уже влияет на результат перед заказчиком). Формируем локальный план-график: что конкретно нужно сделать, в какой срок и кто подключается дополнительно если нужно. Этот план согласовывается с заказчиком — он должен знать о переносе и понимать новые сроки. Красный статус сам по себе не трагедия. Трагедия — это красный статус, о котором заказчик узнаёт последним.

Шаг 7 — Закрытие. Закрытие КТ или проекта — наиболее важный этап. Это сверка с Реестром метрик: каждый показатель либо достигнут, либо нет. Если не достигнут — КТ не закрыта и тогда действуем аналогично красному статус в Шаге 6.

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

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

Примеры артефактов

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

Вот как выглядит Карта проекта для нашего вычислительного комплекса в упрощённом виде:

Реестр метрик (пример для одной КТ)

КТ-2 — Интеграция модуля телеметрии

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

Разбор реального блокера

У коллеги была задача: подключить светодиодную панель (готовый продукт) и вывести на неё информацию через наш комплекс. Изначально задача казалась простой — на руках была вся документация, продавец панели был на связи. Тем не менее, несмотря на все усилия, коллега потратил практически неделю и так и не пришёл к результату. Срок ещё не был просрочен, но вплотную к этому приближался.

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

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

До/после: что изменилось с Projex

Разумеется не все так было плохо до появления Projexy - команда работала, продукты выходили. Но было несколько системных проблем, которые я замечал снова и снова.

До Projex - как было:

У каждого разработчика в Jira висело в среднем 6–8 задач в статусе «высокий приоритет». Плюс 3–4 в бэклоге, которые формально существовали, но никто не знал когда до них дойдут. Сроки сдвигались вправо регулярно — не потому что люди работали медленно, а потому что не было чёткого понимания что важно прямо сейчас, а что подождёт. Часть задач закрывалась вообще без результата — просто теряла актуальность пока лежала в бэклоге.

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

После Projex — как стало:

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

Конкретные цифры по проекту вычислительного комплекса:

Сравнительная таблица

Что дальше

Я продолжаю применять Projexy на своих проектах и дорабатываю по ходу. Параллельно разрабатываю инструмент Projexy — ПО, в котором вся эта логика будет реализована нативно: карты проектов, светофор статусов, журнал блокеров, профили команды. По мере разработки буду рассказывать о реальных плюсах и минусах системы на практике.

Главное, что хотел донести — это не критика существующих подходов, а попытка найти то, чего в них не хватает. Человека.