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

Пост от 23 года.

«Как я повышал прозрачность продуктовой разработки и постановки задач технарям с помощью JTBD. [ЧАСТЬ 1]»

Прошло два месяца с момента начала внедрения мною фреймворка JTBD в компании, где, в принципе, культура айтишного производства была на достаточно высоком уровне. Делюсь впечатлениями.

По отзывам коллег со стороны "гуманитарного" крыла компании, способность к прогнозированию результатов разработки всегда была ограничена в силу непонятности того, что собсна разрабатывает отдел разработки. В нашем случае - это даже несколько отделов: хард, софт, нейросети. Есть не только жесткое разделение этих направлений, но и, фактически, 2 СТО.

Ну а "техническое" крыло постоянно жалуется на то, что планирование и соблюдение сроков невозможно в условиях постоянного поступления change requests и размытого фокуса при постановке задач без четкой аргументации, что и зачем нам нужно, а также какого результата ждет бизнес от конкретных фич в разработке. Нужно отметить, что понимание простыми работягами ключевых задач бизнеса, проставленных для каждой функциональной единицы, поступающей в разработку, - это, наверное, самое важное условие успеха. В этом деле уже сделаны некоторые шаги, но путь и методы решения проблем здесь выглядят супер фундаментальными и занимающими длительное время.

Так вот, в начале была документация: набор технических заданий на разработку, спеки, самописный трекер для постановки задач, где, к сожалению, нет функционала досок задач. Сначала я очень хотел переехать на что-то, помогающее соблюдать SLA и тречить просрочки, но из-за супер сжатых сроков релизов пришлось отказаться от этой затеи до лучших времен. С продуктовой командой, с другой стороны, удалось достаточно быстро внедрить трекер с досками, что значительно повысило качество планирования загрузки и помогло хотя бы визуально держать топ-менеджмент в курсе - работы много и она постоянно выполняется. Раньше продуктовые задачи не тречились в принципе.

Относительно документации: у нас были очень подробные технические задания (в компании их кличут PRD - Product Requirements Document), в которых, как и ожидалось, практически полностью отсутствует бизнесовая составляющая, объясняющая, почему такая то задача была поставлена именно так, и каков предполагаемый результат её выполнения.

Написание опусов о бизнес-целесообразности в каждом ТЗ не выглядело оптимальным сценарием, да и подход JTBD давно хотелось проверить на вшивость в боевых условиях несущейся на всех парах разработки, а не при очередном планировании на предпроекте в стартапах.

Продолжение следует.