Как ИТ‑компании из сферы оказания услуг перейти в продуктовую разработку
Нередко ИТ‑компании, заметив нерешенную проблему, стремятся пойти в развитие собственного продукта и выделяют отдельную команду с целью занять свободную нишу.
Но удержать продукт на плаву на старте — это настоящее искусство! Искусство, которое требует хорошего знания потребностей и болей клиентов. Искусство критического мышления и постоянной проверки гипотез с целью создания и поддержки в актуальном состоянии ценностей продукта.
С каких ошибок начать
Даже с учетом накопленного опыта в аналогичной сфере по оказанию услуг, в начале пути все ошибаются, это неизбежно. Проводя ретроспективу после неоднократного общения с коллегами, могу сказать, что на старте ошибки типовые и очень схожи.
У нас в самом начале пути было лишь непреодолимое желание разработать систему управления проектами для IT команд. И благодаря этому желанию мы понеслись собирать ошибки одну за одной:
- Нащупав несколько нерешенных проблем в этой сфере, сразу бросились реализовывать их решение.
- Разработчики часто менялись и выпадали из контекста, т.к. разработка над проектом велась во время простоев команды между заказами (как часто это бывает в аутсорс кампаниях).
- Отсутствие проработанной документации усугубило ситуацию в п.2.
- Недооценка и просчеты в начальной архитектуре проекта стоили больших усилий при масштабировании.
- Неверно подобранная методология в управлении проектом и грубые ошибки в распределении ролей и зон ответственности привели к тому, что решения многих вопросов сильно затягивались.
- Отсутствие риск‑менеджмента привело к непоправимым последствиям.
Спустя год работы в подобном темпе, пришлось признать несостоятельность такого похода, да еще и архитектурные изменения привели к необходимости переписывать большую часть сервисов.
Рассылка: как вести бизнес в России
Пять полезных писем пришлем сразу после подписки. В них — бизнес‑идеи, готовые промпты для нейросетей, советы, как выбрать налоговый режим и получать пассивный доход
Основные этапы продуктовой разработки
Чего не хватило в выбранном подходе, какие основные этапы разработки обязательно должны присутствовать, и что было пропущено.
Формулировка идей, исследование и проверка гипотез. Перед тем как бросаться в омут реализации той или иной идеи, необходимо сформулировать гипотезы, расставить приоритеты и провести ряд исследований и кастдевов. Проблемные интервью, опросы, анализ конкурентов — это тот минимум который просто необходим. И важно это сделать как можно раньше на жизненном пути продукта, т.к. результаты проведенных исследований могут сильно изменить его очертания.
Проектирование и планирование. Необходимо определить и описать функциональные возможности продукта на основе установленных ценностей. Рекомендую это делать в формате схематичной карты экранов — wireframes без детальной прорисовки и дизайна элементов — и дополнить это описание классическим текстовым описанием функциональных модулей. Кроме того, на данном этапе необходимо определиться с методологией будущей модели управления проектом и определиться со стеком технологий и архитектурой.
Оценка. Для оценки проекта необходимо произвести декомпозицию задач и разбить их на более мелкие. Для наглядности и достоверности оценки и контроля сроков при реализации рекомендую составить диаграмму Ганта.
Этап реализации. Процесс разработки в соответствии с выбранной методологией и фреймворком. А для удобства управления и отслеживания прогресса на всех этапах, рекомендую использовать специализированные сервисы управления проектами — как раз для этого мы и разработали систему управления проектами eTIME.
Тестирование и ввод в эксплуатацию. Проверка и тестирование работоспособности продукта очень важны. Этап тестирования обычно идет параллельно с этапом реализации, но бывают и исключения — зависит от выбранного методологии.
Чтобы ваш продукт стал менее хрупким, успел набраться сил и стать устойчивым к внешним воздействиям, ошибки нужно уметь принимать и извлекать из них пользу.
