Утро было хмурым и промозглым, подстать настроению . После только что закончившегося совещания единственными словами Ивана были: "Как же я от этого устал".
PO (Product Owner, Владелец продукта) снова устроил ему разнос, в этот раз за очередной, еще даже не начатый проект.
Иван работал в крупной компании, где руководил командой разработки программного обеспечения складской логистики. Бизнес, дающий ему задачи, постоянно фонтанировал идеями. И всё надо было сделать срочно.
Не успевали закончить один проект как пора уже было заканчивать другой. И это не кончалось никогда.
Разработчики не справлялись, задачи делались месяцами. Даже предновогодний напряг, когда все постарались закрыть висящие задачи, не помог. Не помогло даже увеличение количества разработчиков.
Очередная срочная задача. 8 разработчиков бэка уже неделю сидят и ждут пока аналитики не закончат проработку проекта. Заказчик бьется в истерике - задача не делается, да еще и все разработчики простаивают.
Хмурый как туча после только что прошедшей головомойки, Иван сидел перед компьютером и руки его опускались. Хотелось всё бросить и уехать в деревню, подальше от всей этой нервотрепки. Но проблему надо было как-то решать. Избегание могло привести к еще более худшим последствиям.
В этот раз Иван решил не тушить пожары, а попытаться сдвинуть ситуацию с мёртвой точки. Недавно прочтенная книга Э.Голдрата "Цель" дала ему несколько полезных идей.
Голдрат говорил:
- Найди узкое горлышко. Обычно оно там, где больше всего скопившихся запасов
- Расширь его, используй на 100%
- Подчини всё производство узкому горлышку
- Обеспечь горлышко работой создав небольшой буфер
Было очевидно, что узким горлышком в команде разработки были аналитики. На 8 бэков было всего 2 аналитика, и именно на них зависла работа - они до сих пор никак не могли закончить спецификацию методов API, которых так ждала разработка.
Иван начал действовать. Выпив для бодрости кофе он собрал аналитиков и рассказал им о проблеме. Все вместе они попытались выписать проблемы, являющиеся причиной задержек. Вот, что у них получилось:
- Перескакиваем с одной задачи на другую
- Аналитика делается когда разработка уже началась
- Нет понимания, что делать завтра и приоритетов
- Плавающие и непрозрачные сроки
- Возникают постоянные изменения от смежников и бизнеса, вынуждающие делать правки и у нас
- Приходится делать двойную работу, например, пришлось делать три параллельных аналитики на одну и ту же задачу печати документов
- Есть моменты, которые неизвестны и которые меняются в процессе
- Не хватает аналитиков
- У аналитиков нет задач в Jira, а те, что есть - очень большие и не закрываются
- Не хватает компетенций в спецификации методов API
Все эти проблемы сильно смахивали на "НЖЯ" - НеЖелательные Явления из книги Голдрата и прямо-таки вопили о необходимости построения Дерева Текущей Реальности. Но Иван решил отложить это на более позднее время, т.к. перед этим захотел посмотреть на внутренности процесса аналитики.
Просматривая результаты работы одного из аналитиков он обратил внимание, что у того было полностью готово описание процесса в целом, созданы и утверждены макеты экранов, прописаны все сценарии. И даже спецификации методов API тоже были наполовину сделаны.
Нельзя было сказать, что человек не работал. Но при этом прошла неделя, а разработчики курили бамбук и до сих пор ждали окончания этапа аналитики, а заказчик при этом орал, что всё пропало. Что-то тут было не так.
Иван понял: разработчики ожидали спецификацию методов API, а как раз её-то до сих пор и не было сделано. Т.е. всё, что сделал аналитик было совсем не тем, что давало разработчикам ценность! Они ждали другого.
Карта потока создания ценности расставила всё по своим местам:
Карта со всей очевидностью показывала, что изменить процесс не получится, ведь перед тем как приступить к спецификации методов API аналитику необходимо было сначала проштудировать весь процесс, нарисовать макеты экранов и прописать сценарии работы в приложении.
Осознание этого факта привело Ивана в тупик. Несколько лет назад он и сам работал ит-аналитиком и поэтому прекрасно знал, что не понимая процесса в целом и не видя перед собой макетов экранов приложения аналитик не сможет нормально составить список методов API и сделать на них спецификацию, ведь набор параметров методов сильно зависел от того, в какой момент и на каком экране они вызывались.
Решения не было, а часы показывали уже 20:30. Утро вечера мудренее, решил Иван, и ушёл из офиса домой.
Следующий день действительно оказался мудрым.
Вспоминая наставления Голдрата Иван вспомнил про диаграмму конфликтов "Грозовая туча". А ведь в его голове действительно зрел конфликт: с одной стороны было очевидно, что разработчикам бэка нужна только спецификация методов и не нужно больше ничего другого, а с другой - весь процесс в целом тоже надо было анализировать, так же как и макеты экранов нужны были мобильным разработчикам. Т.е. и без полного анализа тоже обойтись было нельзя.
Иван собрал аналитиков и сказал: "А что, если мы будем делать спецификацию методов API не прорабатывая процесса и экранов? Т.е. представьте, что вы делаете методы полностью с нуля. Сможете вы это сделать?".
Аналитики сначала опешили, а потом начали активно сопротивляться - идея казалась слишком бредовой.
Не теряя времени Иван начал рисовать"Грозовую тучу". Пальцы застучали по клавиатуре занося тонны возражений, выливаемых на него аналитиками. Список растянулся:
Когда поток возражений закончился Иван предложил: "Один умный дядечка в книге сказал, что причиной конфликтов часто являются ложные убеждения, пусть даже и сделанные ради хороших намерений. Давайте попробуем понять, действительно ли всё, что мы написали является абсолютной истиной. По каждому пункту попробуем просто спросить: Правда?!!!!"
Первое же возражение из списка не выдержало этой простейшей проверки и аналитики сами предложили вычеркнуть его как ложное. Все остальные пункты сдались один за другим. Ивану даже не понадобилось ничего говорить - он просто молча наблюдал как аналитики сами беспощадно уничтожают свои же заблуждения.
Тут ко встрече присоединился тех лид от команды бэка и сказал: "Ребят, а давайте вы сразу будете делать спецификацию методов в yaml-е в формате OpenAPI, а мы потом из неё будем автоматом генерить наши методы?" Возражений ни у кого не было. Решение явно было прорывным.
И уже на следующий день работа закипела.
Продолжение следует...