Решаем проблемы оверинжинеринга и готовности ДЕМО с PS+

Эта статья будет полезна если:  
- Вам нужно срочно заимплементить что-то для ДЕМО (Например вы стартап готовящий прототип или вам нужно срочно дойти до какого-то конкретного этапа для получения следующего раунда инвестиций);  
- Вы замечаете множество задач в бэклоге связанных с рефакторингом кода, но при этом релизы ваших бизнес фич запаздывают;  
- Вы хотите улучшить кооперацию с заказчиком для которого разрабатываете ПО;  
- Вы хотите помочь вашей команде инженеров с расстановкой приоритетов на уровне технического планирования задач;  
- Вы чувствуете, что ваша команда инженеров работает над чем-то лишним, но у вас нет возможности проверить это;  
- Вы любознательны.

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

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

Корни оверинжинеринга имеют разные формы. Так, это может быть желание инженера получить признание своих знаний, либо просто желание “сделать что-то интересное”. У инженера может не хватать компетенции на оценку сложности задачи, либо он может не верно оценить уместность сложного решения задачи, предложенного коллегой.

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

Из десяти проектов разработки ПО мы с трудом можем найти одну или две команды, которые проводят технический ретроспективный анализ с целью выявления “лишней разработки”. Само осознание того, что ты мог потратить на что-то вдвое меньше времени, с той же пользой для бизнеса - больно, если не сказать больше.  
 

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

В современных курсах и книгах по проект менеджменту обсуждается тайм менеджмент, создание правильных Канбан досок, имплементация WIP (лимитирование макс. кол-ва задач в колонке In Progress) и решение вопросов координации команды.

Что не обсуждается в этих материалах, так это возможность проект менеджера вовлекаться в техническое обсуждение решений по продукту. Это, конечно, логично. Далеко не каждый менеджер может обладать компетенцией для обсуждения реляционных баз данных и документирования API в Swagger-е.

Роль менеджера обычно сводится к простому “работай с тем, что есть”. PRD (SRS, Тех.Задача) декомпозируется на множество Пользовательских Историй. Те в свою очередь перетекают в множество глубоко-технических задач. Теперь менеджер должен помочь команде имплементировать это в рамках X времени и Y бюджета.

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

В соответствии с дисклеймером в начале статьи, здесь мы говорим об аутсорсинговых компаниях - тех, которые разрабатывают ПО по заказу для клиента. Подобные отношения между заказчиком и исполнителем подразумевают простое “Сделай мне X за Y часов и Z денег”. Стороны заранее договариваются о проведении ДЕМО встреч (обычно, от 4 до 12 в год), с целью валидации что все идет по плану. Каждое успешное ДЕМО - это победа для компании-исполнителя.

Успешное ДЕМО позволяет компании выглядеть очень хорошо в глазах заказчика. Оно позволяет завоевать доверие, укрепить дружеские и рабочие отношения и, что не менее важно, дать понять заказчику что его выбор работать с компанией-исполнителем - был верен. Каждое ДЕМО - это высокочувствительный ритуал, на котором заказчик хочет чтобы все прошло гладко. Иногда заказчик хочет этого даже больше чем компания-исполнитель.

Иными словами, ДЕМО - это идеальная  возможность для исполнителя показать что вы находитесь на одном уровне понимания бизнес целей, и очень бережно относитесь к задачам и интересам заказчика.

Теперь, давайте вернемся к оверинжинерингу, и посмотрим как это явление пересекается с ДЕМО.

Проблема с ДЕМО в том, что команда разработчиков и заказчик видят их по-разному.  
Разработчики могут потратить пару спринтов (обычно, 4 календарные недели) на имплементацию множества глубокотехнических вещей. Заказчика же будет волновать только то, что он “Кликнул на эту кнопку, и ничего не произошло”. Заказчик смотрит на систему с точки зрения бизнес процессов. В современной терминологии мы можем назвать их “user workflow”, “user journey” и др.

Я встречался с этой проблемой много раз. И каждый раз после такого ДЕМО, где у заказчика было не самое радужное представление о прогрессе, я возвращался к команде чтобы сказать им что заказчик не доволен. Иногда ситуация осложнялась тем, что команда ждала меня в приподнятом настроении, ведь они “Успели имплементировать X, и разработать Y за пару недель!” А мне приходилось объяснять ребятам что “Да, то что мы сделали это здорово, но…”

Любой опытный менеджер знает как неприятны эти диалоги и все это балансирование между желаниями клиента и ожиданием признания своей работы командой.  
Часто, подобные диалоги заканчиваются фразой одного из инженеров “В документе было написано имплементировать это и сделать вот это. Мы все сделали. Что не так?” И действительно, все так. Ошибка здесь исходит от разных перспектив того, как опции и страницы продукта видит клиент, и как их видит команда инженеров.

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

В начале 2022 года в одной из наших компаний появились проблемы на одном из проектов. У нас был штат исключительно опытных инженеров-разработчиков. Каждый из них успел поработать над очень интересными и сложными решениями до того как перейти на этот проект. Тем не менее, некоторые наши ДЕМО на этом проекте выглядели очень слабо, и заказчик был недоволен.  
В соответствии с нашим стремлением все оптимизировать и докапываться до сути проблем, мы решили понять откуда растут корни недовольства у заказчика.

Поговорили с инженерами - у них все “почти готово”. Посмотрели на чарты в JIRA - “почти все готово”. Почему же наша оценка проекта с заказчиком до такой степени контрастна?

Не вдаваясь в наши исследования скажу, что проблема была в понимании термина “готово”. Так, заказчику было безразлично сколько кода мы написали и сколько тикетов в JIRA мы зарезолвили. Они хотели “Клик, дабл-клик, ввели данные, нажали на плюс и успех!”

Конечно, для нас это не новость. И мы вернулись к нашей команде разработчиков с заметками составленными по результатам встречи с клиентом. В заметках были простые предложения типа “Пользователь с правами Администратора должен иметь возможность редактировать страницы А, Б и В.” “Пользователь с правами Администратора должен иметь возможность создавать и рассылать оповещения группам X, Y и Z.”

Просмотрев заметки, один из инженеров раздосадованно и с легким презрением как-бы про себя, но вслух выговорил “Если вам буквально нужно это, я могу сделать это за один день!”  
- “А что вы делали остальные 89 дней?” спросил я.  
- “Мы решали вопросы масштабируемости на уровне базы данных и сетей, а затем мы…” и так далее.  
В какой-то момент, после череды моих вопросов мы вышли на понимание, что около 10-15% вещей, которые были сделаны командой были излишни. Поговорив еще немного, процент поднялся до 30%.  
Тридцать процентов времени потраченного на написание кода было потраченно без особой нужды. Боль.

Конечно, у нас есть грамотно составленный PRD (ТЗ, Тех. Задача), в котором детально описана вся логика работы ПО. У нас есть детально проработанный и прототипированный дизайн. И да, в конечном итоге, к моменту завершения проекта мы доставим клиенту то, что обещали. Отличием будет лишь то, что в глазах клиента это будет выглядеть маленьким чудом (Они не могли показать что-то дельное 11 месяцев, а тут все заработало!).

Очевидно, что подобный подход в большинстве своем не будет способствовать хорошей атмосфере в команде. А о дружественных отношениях с заказчиком вообще можно забыть после 2-го сырого ДЕМО.

Так получилось, что очень скоро после этой встречи с инженерами, я участвовал в одном внутреннем ДЕМО, где инженеры показывали прогресс по проекту, а продакт менеджер выступал принимающей стороной. В какой-то момент, одна из наших талантливых QA инженеров, Луиза, расшарила экран и прошлась по списку фич, которые должны были быть готовы “с точки зрения заказчика”. Фичи были написаны в Google sheets, в формате коротких предложений типа тех, которые я написал в одном из абзацей выше. В документе было около десяти предложений. Некоторые были полностью помечены желтым (как объяснила Луиза - это то, что действительно готово). Другие предложения были черными. Некотороые предложения были составленны так, чтобы можно было помечать желтым только часть предложения. Это позволяло не повторяться в написании, придерживаясь минимального кол-ва слов в документе.

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

Вместе с другими менеджерами (проект менеджеры, продакт менеджеры, старшие инженеры и глава QA команды) мы договорились создать документ в Google spreadsheet для каждого из текущих проектов и назвать их “DEMO Readiness”.

В этом документе, ответственный продакт менеджер должен был скомпоновать около дюжины предложений, которые бы охватывали 95%+ продука, описанного в PRD.  
Сама по себе эта задача не тривиальна, так как мы говорим о сжатии документов, которые в некоторых случаях достигают размеров 50+ страниц A-4 (только текст).  
Было разрешено использовать двусложные предложения.  
Было запрещено использовать лирику. Так, было важно минимизировать лишние слова, т.к. это не диктант, и никто речевые обороты оценивать не будет.  
Мы должны были написать предложения так, чтобы они полностью отражали ожидания клиента.

Если в PRD было несколько страниц описывающих одну страницу продукта со множеством фич, мы могли все это скомпоновать в одно предложение типа “Администратор должен иметь возможность создавать и редактировать страницы А, Б, В, с последующей возможностью отправлять оповещения связанные с обновлением этих страниц группам пользователей X, Y, Z” и так далее.

Затем, мы договорились, что QA команда, вместе с задачами и багами в JIRA будет проверять эти документы, и выделять те части текста, которые завершенны (готовы к показу клиенту!) жирным шрифтом (bold).

Затем мы написали скрипт  (скрипт писал менеджер без знаний кода, простите инженеры) используя гугловский App Script. Суть скрипта была в том, что он пробегался по странице с текстом, вычитал пробелы и всякие лишние обозначения не несущие когнитивной нагрузки, и считал кол-во букв выделенных жирным по отношению к кол-ву общего кол-ва букв в тексте:

А затем мы сгенерировали чарт на основе этих данных (встроенная функция Google sheet) и интегрировали его в наши PRD, рядом с чартом JIRA:

 

После этого, мы презентовали это нашим инжинеринг командам, в том числе техническим руководителям проектов. Во время презентации мы попросили их провести идеологическое изменение в их подходе к разработки. Так, вместо акцентирования внимания на том, чтобы задачи слева (Jira Tickets) решались первыми, мы попросили их решать все задачи способствующие увеличения процента “Done” справа (DEMO Readiness).

Таким образом, каждый раз, когда инженер начинает раздумывать над тем, “а стоит ли делать X сейчас?”, или у него появляется более общий вопрос “чем заняться далее?”, он может открыть Demo Readiness документ, посмотреть на не жирный текст, и попробовать понять какие задачи в JIRA помогут увеличить процент жирного текста.

Картинка чуть выше иллюстрирует проблему которую мы у себя нашли. В нашей реальности мы были уверенны что все идет хорошо т.к. с точки зрения технической имплементации продукт был готов на 81.8% процентов (Jira Tickets). Тем не менее, клиент не чуствовал этих изменений, и думал что мы очень сильно отстаем от графика (65.1%).

После имплементации концепции DEMO Readiness-а на этот же проект, уже совсем скоро наши результаты выглядели так:

То что выглядело инженерам как что-то “скучное” и “не интересное”, было быстро имплементировано и сделало нашего заказчика невероятно счастливым.

С момента использования этой методики прошло больше года.PoC (Proof of Concept) концепция себя зарекомендовала хорошо. Я использовал ее не только для помощи команде инженеров с приоритетами, но также для быстрых организаций ДЕМО workflow-ов. Мы даже интегрировали это в Админ Панель нашей фирмы:

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

По поводу названия статьи, и PS+. Изначально мы хотели придумать название для этой методики оценки, т.к. она состоит из нескольких композитов. Так, Demo Readiness Chart - это компонент. Его документ - тоже. Тренинги команды - тоже. Поэтому мы решили собирательно назвать эту методику “PS+” от Project Status Plus.