Проблема не в разработке, проблема в управлении: если виноватых нет, виноватый назначается

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

«Тут проблема не в разработке. Тут проблема в управлении».

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

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

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

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

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

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

Управление и координация — не одно и то же

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

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

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

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

Со временем мне стало ясно, что во многих организациях управление подменяется координацией.

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

Координация

Person A → Task 1
Person B → Task 2
Person C → Task 3

→ кто чем сейчас занят

Управление

System state
     ↓
Decision: can we move forward?
     ↓
Next state

→ может ли система двигаться дальше — и почему

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

Где на самом деле проявляется «проблема управления»

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

Такие точки легко наблюдаемы:

• в том, как принимаются решения и кто имеет право их принимать;

• в том, как идея превращается в формализованную задачу;

• в том, где процесс допускает движение дальше без проверки смысла;

• в том, кто несёт ответственность за переход между этапами, а не за выполнение отдельных действий;

• в том, что считается завершённым, а что — «почти готовым».

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

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

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

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

Почему без формальной модели разговор невозможен

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

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

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

Однако эти элементы описывают действия внутри системы, но не саму систему. Они отвечают на вопрос «как выполняются действия», но не на вопрос «при каких условиях система может перейти к следующему состоянию».

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

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

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

Жизненный цикл ≠ workflow

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

При этом workflow и жизненный цикл отвечают на принципиально разные вопросы.
Workflow описывает, какие действия и в какой последовательности выполняют люди.
Жизненный цикл описывает, в каком состоянии находится продукт в каждый момент времени.

Workflow

Task → Task → Task → Task
  ↓      ↓      ↓
 Done   Done   Done

Жизненный цикл продукта

State: Idea
     ↓
State: Analysis
     ↓
State: Design
     ↓
State: Development
     ↓
State: Release

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

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

В таком случае workflow не устраняет управленческую проблему, а лишь ускоряет масштабирование ошибки.

Если workflow описывает действия, а жизненный цикл — состояние продукта, то управляемость определяется именно жизненным циклом. Следовательно, он должен быть зафиксирован явно — независимо от конкретной реализации процесса.

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

Минимальный жизненный цикл продуктовой разработки

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

Минимально необходимый жизненный цикл включает следующие этапы:

1. Идея — возникает ожидание ценности или необходимость изменения.

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

3. Проектирование — формируется решение: что именно и каким образом будет реализовано.

4. Разработка — решение превращается в код и конфигурации.

5. Тестирование — проверяется соответствие результата зафиксированному проектному решению.

6. Релиз — изменение становится частью продукта и доступно в продакшене.

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

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

Почему ключевое — не этапы, а переходы

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

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

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

Idea
  ↓
[Decision: есть ли зафиксированное ожидание ценности?]
  ↓
Analysis
  ↓
[Decision: приняты ли ограничения и риски?]
  ↓
Design
  ↓
[Decision: зафиксировано ли решение?]
  ↓
Development
  ↓
[Decision: соответствует ли результат решению?]
  ↓
Release

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

Если переходы между состояниями не формализованы, система теряет способность к управлению:

• процесс не умеет останавливаться при отсутствии зафиксированного смысла;

• ошибки проталкиваются на последующие стадии;

• ответственность размывается между ролями и действиями;

• разработка начинает компенсировать управленческие пробелы за счёт переработок, героизма и ручных договорённостей.

Инварианты жизненного цикла

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

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

К таким инвариантам относятся:

• переход к разработке невозможен без зафиксированного результата анализа;

• переход к тестированию невозможен без зафиксированного проектного решения;

• переход к релизу невозможен без формального принятия результата;

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

Analysis ──X──> Development
Design   ──X──> Release
Testing  ──✓──> Release

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

Область применимости модели

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

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

Поэтому модель не рассматривает роли, инструменты и методологии как первичные объекты управления.

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

• роли понимаются не как должности или организационные единицы, а как носители ответственности за состояния и переходы;

• инструменты и таск-трекеры рассматриваются как способы реализации и визуализации правил, а не как источник этих правил;

• методологии трактуются как наборы практик, работающие внутри уже зафиксированной системы, но не определяющие её границы;

• скорость и производительность не являются целями управления, а выступают производными эффектами корректно работающей модели.

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

Именно поэтому модель отвечает на один принципиальный вопрос: :

может ли система двигаться дальше — и на каких основаниях.

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

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

Применение модели на практике

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

Сервис анализирует резюме, сопоставляет их с требованиями вакансии и формирует структурированную оценку релевантности, позволяя HR работать не с сырым потоком откликов, а с приоритизированным списком кандидатов.

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

Разработка ведётся в соответствии с зафиксированным жизненным циклом:

• идея фиксируется как ожидание ценности, а не как список функций;

• анализ завершается управленческим решением о границах ответственности системы;

• проектирование определяет модель состояний и правила переходов;

• переход к реализации допускается только после формальной фиксации условий.

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

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

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

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

Критерии существования жизненного цикла

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

Состояния жизненного цикла:

• определены явно;

• одинаково понимаются всеми участниками процесса;

• имеют зафиксированную цель и формально определённые границы ответственности.

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

Переходы между состояниями:

• требуют явного управленческого решения;

• не подменяются сменой статуса или закрытием задач;

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

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

Ответственность в управляемом жизненном цикле:

• закреплена за состояниями и переходами, а не за отдельными действиями;

• закреплена явно и не допускает неоднозначности в принятии решений;

• не подменяется операционной занятостью.

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

Процесс разработки:

• способен останавливаться при отсутствии формально зафиксированного смысла;

• не проталкивает изменения дальше автоматически;

• не требует героизма для корректной работы.

Если система не умеет останавливаться, она неизбежно начинает масштабировать ошибки.

Релиз в управляемой модели:

• рассматривается как управленческое событие;

• имеет формальные условия принятия;

• не сводится к технической операции.

Релиз фиксирует принятие последствий решений, а не просто доставку кода в продакшен.

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

Заключение 

Жизненный цикл продуктовой разработки — это не про скорость и не про инструменты. Это про управляемость.

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

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

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