За время работы руководителем в разработке у меня сформировалась определённая позиция про планирование и реализуемость наших планов.

Звучит так:

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

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

И в моей парадигме мира это тот самый Agile с его 4 каноничными принципами:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

В работе я очень часто вижу, что принципы Agile отождествляются парадигме «У меня есть идея, погнали кодить! — Погнали». Без понимания, что и зачем мы делаем у всех причастных и без каких-либо даже базовых договорённостей о результате.

Тем самым, оправдывая весь создаваемый «хаос» благородным словом «гибкость» 🤫

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

И вот здесь крайне важна часть про «подумать, прежде чем начинать что-то делать» 🤔

А после того как подумали — сформировать артефакт с верхнеуровневыми деталями решения для проблемы/фичи, который: 1. Выравнивает ожидания и понимание по фиче у всей команды (разработка, продукт и бизнес) - помним про сложность наших продуктов и систем 2. Формирует дискуссию внутри команды, что позволяет находить более оптимальные решения благодаря коллективному разуму 3. Даёт фактуру для срезания скоупа, где в одном доке выложены все детали фичи и они вместе лежат перед глазами 4. Если есть грамотные DoD, то заранее подумать про важные штуки типа плана раскатки фичи, новых метрик для аналитики, вопросов наблюдаемости и пр.

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

Но оно не будет работать, если ваши фичи размером с месяца и кварталы 🤷‍♂️ Слишком большой скоуп работы. И это также про Agile и гибкость. Точно ли мы гибки и делаем реально что-то полезное, когда делаем 1 фичу квартал без понимания, а как она пользователям?

#agile #продукт #гибкость #фичи