Переход из сферы IT-услуг в продуктовую разработку

Нередко ИТ‑компании, заметив нерешенную проблему, стремятся пойти в развитие собственного продукта и выделяют отдельную команду с целью занять свободную нишу.

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

С каких ошибок начать

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

У нас в самом начале пути было лишь непреодолимое желание разработать систему управления проектами для IT команд. И благодаря этому желанию мы понеслись собирать ошибки одну за одной:

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

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

Новости

Основные этапы продуктовой разработки

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

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

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

Пример Wireframes — Пример схематичной карты экранов — wireframes

Оценка. Для оценки проекта необходимо произвести декомпозицию задач и разбить их на более мелкие. Для наглядности и достоверности оценки и контроля сроков при реализации рекомендую составить диаграмму Ганта.

Диаграмма Ганта в системе управления проектами eTIME

Этап реализации. Процесс разработки в соответствии с выбранной методологией и фреймворком. А для удобства управления и отслеживания прогресса на всех этапах, рекомендую использовать специализированные сервисы управления проектами — как раз для этого мы и разработали систему управления проектами eTIME.

Тестирование и ввод в эксплуатацию. Проверка и тестирование работоспособности продукта очень важны. Этап тестирования обычно идет параллельно с этапом реализации, но бывают и исключения — зависит от выбранного методологии.

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

Актуальные статьи и свежие тренды