9 вопросов к разработке продукта, которые помогут добиться ваших целей в следующем году

Руководитель Digital Sail, разработчика ИТ-продуктов и ERP, Екатерина Безденежных поделилась чек-листом вопросов, которые помогают понять, почему за год могло не получиться дойти до результатов, которые хотелось бы видеть в командной разработке внутреннего IT решения для бизнеса.

«У нас есть продукт, мы куда то движемся, но не совсем понятно, «куда» и можно ли лучше». С этим запросом к нам часто приходят руководители IT направления среднего и крупного бизнеса, где IT-продукт — инструмент предоставления основной услуги.

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

Предлагаю вам ответить на 9 вопросов о разработке вашего IT-продукта, которые мы обычно задаем при знакомстве, чтобы найти слабые места. Так вы узнаете, как лучше структурировать работу и закрыть максимум целей в будущем году.

Разговоры о базовых принципах создания IT-продуктов, Agile и SCRUM часто остаются теоретическим ориентиром. В реальности к любым решениям и процессам примешивается естественный «шум» — разросшиеся списки задач, переход разработчика из одной команды в другую, срочный релиз и починка багов.

Рутина стаскивает с запланированного маршрута, мешая найти то, что по-настоящему уводит в сторону от поставленных целей. По собственному опыту руководителя IT-продакшена и кейсам наших клиентов, я выделила 9 моментов, которые хоть и кажутся очевидными, на практике часто мешают проекту работать в полную силу.

Работа над большим проектом часто разрастается так, что в какой-то момент продукт начинает разделяться на 2, 3, а то и 4 самостоятельные части. Если вовремя этого не заметить, весь продукт начинает сбоить — не все проекты получают достаточно ресурсов, более активные норовят перетянуть внимание на себя и не дают другим развиваться в полную силу.

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

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

Когда контроль разработки не разделяется между руководителем IT направления и лидером (руководителем) каждого из проектов, фокус внимания неизбежно размывается. Чтобы проект двигался в нужном направлении, важно верно оценить объем внимания, который ему требуется.

Даже разделив продукт на несколько проектов, вы можете не замечать, как они продолжают мешать друг другу развиваться. Проверьте:
- есть ли взаимоисключающие цели у двух проектов внутри одного продукта?

- конкурируют ли проекты за одни и те же ресурсы?

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

В бизнесах, где IT-проект — инструмент для работы, а не конечный продукт или услуга, заказчиком продукта часто являются и внутренние сотрудники, и внешние пользователи. И между руководителем разработки и остальными отделами компании, которые как раз пользуются продуктом, могут возникать «трудности перевода».

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

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

Если задачи «в моменте» перестают совпадать с направлением, в которое вы стремитесь и куда хотите добежать, стоит либо пересмотреть актуальность целей, либо еще раз перебрать бэклог проекта. Фокусировка на выбранном приоритетном направлении творит чудеса.

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

Если все задачи нужны были ещё вчера, а планы невозможно удержать без изменений даже 1-2 недели, вы уже в затянувшейся гонке. Чтобы выдохнуть, вернитесь на пару шагов назад к разделению продукта на проекты и выбору точки, в которую вы хотите прийти за конкретный период.

Не бывает команд, в которых плохо настроены все процессы. Чаще всего проседают отдельные этапы, на которые не хватает времени, ресурсов или экспертизы. Эти узкие места регулярно обваливают весь цикл работы по задачам или спринтам. Их сложно заметить сразу, потому что возникают они постепенно с ростом команды.

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

Вспомните, на каком этапе работы над задачей постоянно возникают сложности? Если вы уже пытались это исправить, но проблемы всё равно появляются снова — пересоберите процесс с нуля или обратитесь к опыту похожих кейсов у других компаний. Скорее всего кто-то уже решал такую задачу и сможет поделиться шорткатом.

Стендапы, растягивающиеся на час, молчаливые ретроспективы — в какой-то момент теряются желание и мотивация их проводить. В идеальном мире разработка продукта выстроена в рамках ежедневной/еженедельной/ежемесячной рутины или рабочего спринта… Но в реальности эта система начинает сбоить, если не все до конца понимают, как и зачем её использовать.

Чтобы встречи были живыми и продуктивными, важно объяснить каждому участнику, как они помогут лично его работе. Встреча может стать местом, где команда упрощает и структурирует работу, куда можно принести проблему и действительно её решить. Команде важно поработать с опытным ведущим, который умеет соблюдать фреймворк и возвращать всех в продуктивное русло.

Есть ли у вас инструменты, которые номинально должны использоваться, но в реальности все стараются их избегать? Как часто вы и вправду обращаетесь к знаниям, которые хранятся в Wiki, Notion или Miro?

Чтобы всё это работало на результат, а не превращалось в бесполезную обязанность, нужно сделать процесс естественным. Если у вас есть Wiki, но её никто не заполняет, хотя она кажется простой, стоит упростить ее использование ещё. И упрощать и/или изменять процесс до тех пор, пока её заполнение из бюрократической обязанности не превратится в логичную часть рабочего процесса.

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