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

Вступление

Есть фраза из Agile Manifesto, которую часто цитируют:

Люди и взаимодействие важнее процессов и инструментов.

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

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

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

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

Регламент — это не замена компетентности

Когда в команде что‑то идёт не так, первое, что приходит на ум - это найти управленчески понятное решение:

• Много багов? Расширяем Definition of Done.

• Низкое качество требований? Держите шаблон постановки!

• Срываются сроки? Фиксируем правила коммуникации между отделами.

• Команда плохо синхронизируется? Вводим ещё один регулярный митинг (а лучше два!)

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

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

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

Разработка — это цепочка решений, а не конвейер документов

Часто слышу, что разработку и ИТ-процессы в целом сравнивают с производственной линией: бизнес сформулировал идею, затем бизнес аналитик описал требования, системный аналитик с архитектором написали постановку... Разработчик реализовал... QA проверил... Релиз‑менеджер выпустил. Всё как на конвейере, ну почти. Но реальность несколько отличается от описанной схемы.

На каждом этапе люди не просто «передают артефакт дальше». Они принимают решения. Бизнес‑аналитик решает, правильно ли он понял потребность бизнеса / клиентов. Системный аналитик решает, какие есть противоречия в требованиях и как это ляжет на существующие процессы. Архитектор решает, какой компромисс допустим, а какой - нет. Разработчик определяет, как именно встроить изменение в существующую систему. QA пытается предугадать, где вероятнее всего сломается сценарий. Тимлид анализирует, где решение можно принять, а где нужно остановиться и продумать всё заново.

И если на любом из этих участков принимаются слабые решения, проблема почти неизбежно доедет до конца цепочки:

• плохая аналитика превращается в переделки и срывы сроков;

• слабая архитектура — в технический долг;

• поверхностная разработка — в дефекты;

• формальное тестирование — в инциденты;

Думаю, что логическую цепочку вы уловили. А потом команда садится на ретро и говорит:

Кажется, нам не хватает процесса.

Иногда действительно не хватает. Но часто (а, откровенно говоря, ещё чаще 🙂) не хватает не процесса, а качества решений внутри уже существующего процесса.

Процессы полезны. Но не всегда так, как мы от них ждём

Я не против процессов. Скорее наоборот. Хороший процесс - это полезная вещь. Он помогает команде:

• не забывать повторяющиеся действия;

• быстрее договариваться;

• одинаково понимать ожидания;

• онбордить новых людей;

• фиксировать удачные практики;

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

Есть хорошая идея, которую я впервые услышал у одного широко известного в узких кругах спикера: если масштабировать бизнес до того, как у него сошлась юнит‑экономика, ты начинаешь не масштабировать успех, а масштабировать убытки.

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

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

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

Плохая постановка, оформленная по правилам — всё ещё плохая постановка

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

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

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

Внешне документ стал выглядеть лучше. Внутри появились правильные разделы. Формально всё стало аккуратнее. Но ключевая проблема никуда не делась.

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

В какой‑то момент стало очевидно: проблема была не в отсутствии структуры. Проблема была в недостаточном понимании системы и недостаточной профессиональной зрелости.

Большой DoD не превращает слабого разработчика в сильного

Другой пример — Definition of Done.

У нас был разработчик, за которым требовалось много контроля. Ошибки возникали в разных местах: где‑то не учёл состояние, где‑то - не проверил сценарий, иногда — не подумал о влиянии на соседний функционал или не обновил связанный код.

Команда решила помочь: собрали большой документ DoD. По сути, чек‑лист того, что может потребоваться сделать по ходу задачи или перед её завершением.

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

Почему? Потому что человек всё равно находил места, где ошибиться.

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

Кодить документом не получится! Кодирование — это не только знание синтаксиса и следование чек‑листу. Это навык принятия технических решений. Это образ мышления. Это понимание последствий. Это привычка задавать себе инженерные вопросы:

• а что будет в соседнем сценарии или на старой версии приложения?

• не сломаю ли я обратную совместимость?

• что произойдёт при ошибке сети или если данные придут в другом порядке?

• не создаю ли я здесь технический долг, который потом ударит по команде?

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

Чем слабее компетенции, тем сильнее хочется всё зарегулировать

Наверное, все хоть раз сталкивались с таким организационным паттерном: команда сталкивается с проблемой → cоздаётся регламент → проблема повторяется в соседнем месте → создаётся ещё один регламент → затем ещё один... чек‑лист... матрица... согласование...

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

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

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

Agile не про отсутствие процессов

Конечно, важно не уйти в другую крайность. Фраза «люди важнее процессов» не означает:

Давайте вообще ничего не описывать, не планировать, не фиксировать и не договариваться.

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

Поэтому вопрос должен звучать не в духе «какой ещё регламент нам нужен?», а так:

Какую проблему мы пытаемся решить? Это проблема процесса или проблема компетенций? Что именно должно измениться в поведении команды? Поможет ли документ изменить это поведение? Или мы просто создаём артефакт, чтобы почувствовать контроль?

В финтехе инженерная культура — не опция

Я работаю в финтех‑контексте, и мне кажется, что здесь эта тема особенно важна.

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

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

Поэтому мне близка идея компании, ведомой инженерной культурой. Не в смысле, что все руководители должны быть бывшими разработчиками. И не в смысле, что «технари всегда правы, а бизнес ничего не понимает». Фишка тут в другом.

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

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

Процесс должен рождаться из практики, а не заменять её

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

1. Команда сталкивается с повторяющейся проблемой.

2. Сильные специалисты разбираются, где именно возникает сбой.

3. Команда пробует новый способ работы.

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

5. После этого его можно формализовать.

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

Хороший процесс — это зафиксированный опыт, плохой процесс — это попытка нарисовать зрелость там, где её ещё нет.

Что делать лиду

Для себя я формулирую несколько практических выводов.

1) Определи, с чем пришлось столкнуться - с проблемой процесса или компетенций?

Если аналитик системно делает слабые постановки, то проблема скорее всего не в шаблоне. Если разработчик регулярно ошибается в простых задачах — то не факт, что дело в DoD. QA пропускает важные сценарии — ну, вы поняли...

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

2) Опиши только то, что действительно повторяется

Не нужно пытаться зарегулировать всю разработку. Что имеет смысл описывать:

• повторяющиеся ритуалы;

• критичные проверки;

• релизные процедуры;

• правила работы с инцидентами;

• Definition of Ready / Definition of Done на разумном уровне;

• договорённости по коммуникации;

• типовые сценарии взаимодействия между ролями.

Но не нужно пытаться превратить инженерное мышление в инструкцию.

3) Опиши регламент по KISS (keep it simple, stupid) принципу

Бумага всё стерпит, а люди — нет. Если чек‑листом невозможно пользоваться без внутреннего сопротивления, им не будут пользоваться в ежедневной работе. Если документ слишком большой, он становится не инструментом, а оправданием:

Ну у нас же всё описано.

Хороший процесс должен быть достаточно коротким, чтобы реально влиять на поведение.

4) Попробуй регламент в деле, помогает ли он на практике?

Процесс не должен оцениваться по факту своего существования, а вопросы — должны быть практическими:

• стало ли меньше переделок и дефектов?

• стали ли задачи понятнее и проще для реализации?

• сократилось ли время согласований?

• стало ли меньше ручного контроля? ...

Если нет — возможно, процесс ничего не улучшает.

5) Не бойся признать, что документ не решает проблему

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

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

Короче

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

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

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

Мы правда описываем удачную практику? Или пытаемся документом заменить компетентность?

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