Почему проекты все еще срываются, хотя у всех Agile, Jira и куча митапов

Представь обычную картину. Компания говорит, что работает по «Agile».

У всех есть «Jira».

Каждый день стендапы, раз в неделю планирование, созвоны.

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

И ты сидишь на очередном созвоне и думаешь

«Как так вообще?».

Давай разберемся почему такое может быть?

Представь, что ты купил дорогой ежедневник и крутую ручку, но при этом толком НЕ ПОНИМАЕШЬ, что именно хочешь сделать в своей жизни в этом году.

Ежедневник красивый, ручка приятная, а жизнь все равно хаотичная.

С проектами то же самое.

Можно завести идеальную доску в «Jira», писать правильные статусы, проводить ретро, но если команда не понимает, ЗАЧЕМ вообще все это, результат будет не тот.

Есть ощущение движения, но нет движения вперед.

Очень часто команда неплохо понимает задачи, но слабо понимает настоящую цель.

Пример.

Бизнес говорит «Нужно новое приложение, чтобы быть современными» или «Нужно обновить личный кабинет».

С виду это похоже на цель, но на самом деле это просто ЖЕЛАНИЕ что то сделать.

Настоящая цель звучит по другому.

... Снизить нагрузку на кол центр.

... Увеличить число повторных покупок.

... Сократить время обработки заявки.

Когда такой цели нет, рождаются странные решения.

Функции делаются потому, что кто то сверху так решил, а не потому, что они ведут к понятному результату.

Это как поехать в такси и сказать «Вези куда нибудь на юг».

Формально движение есть, поездка оплачена, но приехать можно вообще не туда.

Частая история.

Процесс вроде есть по всем правилам, но ДУХА «Agile» нет вообще.

Ситуация примерно такая.

Официально команда работает спринтами. Но в середине спринта прилетает пять новых срочных задач.

Формально мы планируем, но... на деле....

Проводим ретро, но выводы никто не фиксирует и тем более не меняет процесс.

В итоге получается не гибкая разработка, а странный гибрид.

Часть старого управления, припудренная модными словами.

Команда живет в вечном аврале, но НА БУМАГЕ все красиво (есть спринты, стендапы, ретро).

Еще одна причина срывов - это когда разговоров много, а понятных решений и договоренностей мало.

Созвон прошел.

Люди поговорили, поспорили, разошлись по следующим встречам.

Но не зафиксировано ЧТО ИМЕННО решили, кто что делает, к какому результату идем в конце недели.

Без этого митап превращается в разговор на кухне.

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

Иногда в проекте просто нет человека, который видит всё целиком.

.. У разработчиков свой взгляд.

.. У тестировщиков свой.

.. У бизнеса свой.

А того, кто СКЛЕИВАЕТ все эти миры, не хватает.

Бизнес говорит на языке ожиданий и денег.

Разработчики говорят на языке архитектуры и кода.

Пользователи говорят на языке «мне удобно» или «мне непонятно».

Если нет аналитика или продукта, который умеет перевести все эти языки друг в друга, возникает каша.

Вроде все старались, но пазл не складывается.

А то, что сделали, бизнес воспринимает как «это не то, что мы хотели изначально».

Еще одна типичная история.

Сегодня главное одно, завтра уже другое.

Вчера все бросили ради важного отчета для руководства. Сегодня все бросили ради срочного запроса от большого клиента.

Завтра появится еще что нибудь не менее важное.

При этом срок релиза никто не сдвигает.

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

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

В итоге ты постоянно опаздываешь везде.

С документацией обычно две крайности.

Первая - ее почти нет. Кроме кратких задач вроде «Сделать удобней страницу корзины».

Во второй документации очень много. Огромный документ, который живет отдельно от проекта.

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

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

Золотая середина выглядит ПРОСТО.

Есть несколько живых артефактов.

... Короткое описание цели проекта в одном абзаце.

... Карта основных пользовательских сценариев.

... Пара понятных схем по системе.

И их периодически обновляют, а не пишут один раз ради галочки.

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

Разработчик отвечает за свою задачу. Тестировщик за свои проверки. Бизнес за свой запрос.

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

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

Несмотря на то, что звучит всё грустно - это не приговор.

Есть несколько шагов, которые уже сильно помогают.

Во первых.Честно сформулировать цель проекта в одном абзаце, так чтобы ее понимали и бизнес, и команда.

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

Во вторых. После каждого важного митапа оставлять понятный саммари.

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

В третьих. Выделить в проекте человека, который держит общую картину.

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

Важно, чтобы кто то сознательно связывал точки и не боялся задавать неудобные вопросы.

В четвертых Фильтровать срочность.

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

Друзья, проект срывается не потому, что в нем нет модных практик.

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

Когда начинаешь смотреть на это так, становится немного легче.

Проблема не в том, что команда мало созванивается.

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

Только в этом случае «Agile» и «Jira» наконец начинают работать как задумано. Не прикрывать хаос красивыми досками и статусами, а помогать людям шаг за шагом доводить проекты до конца.