Закон Притяжения в ИТ-разработке:
на чём фокусируемся — то и проявляется
Замечали ли вы, что в ходе проекта или разработки продукта как будто нет реального прогресса?
Стресса — много. Совещаний — бесконечное количество. А разговоры всё крутятся вокруг сроков, планов, бэклогов, дорожных карт и диаграмм Ганта.
Для инженера DevOps или облачного архитектора всё это выглядит чем-то чуждым. Мы смотрим на эти артефакты и видим мало ценности. В то же время проектные менеджеры и владельцы продуктов недоумевают: сколько бы усилий они ни вкладывали в дорожные карты и расписания, сроки всё равно срываются, зависимости не выдерживаются, а проектный план требует эскалаций, изменений и новых согласований.
Получается, чем глубже погружаешься в «сорняки» проекта, тем меньше реальных результатов видно. Ценность снижается день ото дня.
Если это вам знакомо, возможно, стоит выйти за рамки привычных методологий разработки и управления проектами. Может быть, нам есть чему поучиться у древней мудрости.
Возьмём, к примеру, Закон Притяжения. Когда-то его считали маргинальной идеей, а сегодня он часть мейнстрима, популяризован в книгах и фильмах. Суть проста: то, на чём ты концентрируешь внимание, то и притягиваешь. Внимание — это энергия, которая материализует результат.
А что если этот принцип применим и к ИТ-разработке? Может быть, именно наш фокус — на сроках, планах или продукте — и определяет, что в итоге проявляется?
Сроки ≠ Доставка
Может показаться, что концентрация на сроках и планах — единственный способ обеспечить предсказуемость и согласованность ожиданий бизнеса. Ведь руководителям нужны даты.
Но сами по себе сроки не имеют ценности. Это лишь вехи, которые часто не связаны напрямую с реальными возможностями команды и готовностью продукта. Сказать: «Через три месяца всё будет готово» — ещё не значит, что так и случится. Такая «предсказуемость» основана на иллюзии.
Настоящая предсказуемость строится иначе — через рамки фокуса. Например: «В этом квартале мы делаем X, в следующем — Y». Это помогает планированию, но исходит от продукта и результата, а не от календаря.
Примечание: По данным CHAOS Report от Standish Group, проекты с жёстко фиксированными сроками и объёмом работ проваливаются значительно чаще, чем те, что строятся на инкрементальной поставке. В масштабных Agile-фреймворках (SAFe) кварталы используются как «контейнеры намерений», а не как жёсткие обязательства. В Amazon практикуют подход Working Backwards: начинают с описания готового продукта (пресс-релиза), а сроки проявляются уже из этого видения.
Source: https://www.csus.edu/indiv/v/velianitis/161/chaosreport.pdf
Бесконечная итерация и «ползучий» рост требований
Можно возразить: без жёстких рамок Agile превращается в бесконечные итерации и «scope creep» (разрастание требований).
На деле Agile решает эту проблему. «Scope creep» — это бесконечная работа без завершения. Но в Agile конечность обеспечивается продуктовым видением. Если цель — миграция из дата-центра в облако, то конечный результат ясен: всё должно быть перенесено. Путь может меняться, но финальная точка фиксирована.
Agile использует строгие практики: спринты с ограничением по времени, Definition of Done, регулярное уточнение бэклога, поставка инкрементов. Итерации действительно бесконечны в теории, но на практике они обрамлены дисциплиной.
Примечание: Исследование McKinsey показывает, что цифровые трансформации, основанные на итеративной поставке ценности, вдвое чаще завершаются успешно, чем проекты с жёсткими сроками. Итерация без цели — хаос. Итерация, закреплённая на видении, — прогресс.
Source: https://www.mckinsey.com/capabilities/transformation/our-insights/the-numbers-behind-successful-transformations
Бэклог — это инвентарь, а не ценность
На первый взгляд бэклог — это и есть проявление фокуса. Ведь именно там хранится «дорожная карта» продукта.
Но это не сам продукт — это всего лишь механизм. Подобно деньгам: деньги — не цель, а средство. Настоящая цель — покупка дома, поездка или новый опыт. Бэклог тоже лишь средство фиксации идей.
Если всё внимание уходит на его бесконечное уточнение, команда рискует «материализовать» лишь идеальный список задач, но не рабочий софт. Фокус должен оставаться на поставке результата.
Примечание: В Agile даже есть термин — перераздувшийся бэклог (backlog bloat). Lean-подходы подчёркивают: бэклог — это инвентарь, а не ценность. В Spotify команды (squads) используют бэклог как инструмент, но миссии измеряются только результатами.
Планы, бюджеты и комплаенс — это побочные продукты
Можно подумать, что умалять значение проектных планов, бюджетов и требований комплаенса опасно. Именно они держат предприятия на плаву.
Но истина в том, что всё это вторично. План нужен потому, что есть продукт. Бюджет существует потому, что есть что финансировать. Комплаенс появляется потому, что есть система, которая должна соответствовать требованиям. Всё это важно, но это побочные продукты, а не цель.
Примечание: В Agile говорится прямо: «Рабочий продукт — главный показатель прогресса». SAFe рассматривает планы как прогнозы, а не контракты. Метрики DevOps (DORA metrics: частота релизов, lead time, MTTR, доля неудачных изменений) куда лучше предсказывают успех компании, чем формальное следование плану. Даже в банках и медицине требования комплаенса всё чаще реализуются как by-design через пайплайны (аудит-логи, тесты, policy-as-code).
Опасность «золотых унитазов» (gold-plating)
Ещё одно возражение: если фокусироваться только на продукте, разработчики будут делать то, что им интересно, а не то, что нужно бизнесу. Разве сроки и планы не нужны как предохранитель от «золотых унитазов»?
Agile и здесь даёт решение. Для исследовательских задач есть спайки (spikes) — ограниченные по времени эксперименты. Для контроля ценности есть user stories, acceptance criteria и приоритизация владельцем продукта. Всё это удерживает внимание на бизнес-ценности.
Примечание: У Google была практика «20% времени». Её критиковали как источник потерь. Но поскольку она была ограничена и встроена в бизнес-цели, результатом стали Gmail и AdSense — продукты с гигантской ценностью.
Source: https://builtin.com/software-engineering-perspectives/20-percent-time
Финальная мысль
И в жизни, и в ИТ-разработке мы проявляем то, на чём фокусируемся.
Фокусируешься на сроках — получаешь сроки.
Фокусируешься на планах — получаешь планы.
Фокусируешься на бэклоге — получаешь бэклог.
Но если фокусироваться на поставке — получаешь поставку.
Если на продукте — получаешь продукт.
Agile, Lean и DevOps на самом деле давно об этом говорят: концентрируй внимание там, где рождается ценность. Всё остальное — сроки, планы, дорожные карты, комплаенс — появится как побочный продукт.
Важно: Исследования подтверждают — планы и сроки нужны для синхронизации. Но когда их принимают за результат, проекты терпят крах. Настоящая ценность всегда проявляется только в продукте.
Source: https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/how-high-performers-optimize-it-productivity-for-revenue-growth-a-leaders-guide