Свяжитесь с нами
Почему мы в 65apps сделали ставку на дискавери-фазу и не проиграли
Потерянная функциональность, неправильный выбор архитектуры, увеличение стоимости, переносы сроков релиза — типичные ситуации на проектах заказной разработки, в которых клиент и подрядчик имеют разное представление о том, как, что и с какой целью нужно делать.
Как подрядчикам успешно выполнять проекты на заказ, а клиентам не разочаровываться в аутсорс-разработке? Ответ прост — на старте определять цель, синхронизировать ожидания, фиксировать ожидаемый результат, бюджет и сроки. Для этих задач мы в 65apps используем один из самых надежных инструментов — фазу дискавери.
В этой статье развеем мифы о том, что дискавери-фаза — это кусок работы, который понапрасну сжирает бюджет и затягивает старт разработки
Как подрядчикам успешно выполнять проекты на заказ, а клиентам не разочаровываться в аутсорс-разработке? Ответ прост — на старте определять цель, синхронизировать ожидания, фиксировать ожидаемый результат, бюджет и сроки. Для этих задач мы в 65apps используем один из самых надежных инструментов — фазу дискавери.
В этой статье развеем мифы о том, что дискавери-фаза — это кусок работы, который понапрасну сжирает бюджет и затягивает старт разработки
Дискавери-фаза — это начальный аналитический этап, который определяет основные цели, задачи и требования к продукту. На этом этапе проводится сбор информации, определяются ключевые риски и проблемы, которые предстоит решить в процессе разработки. Результатом становится снятие неопределенности и установление границ проекта, что в дальнейшем позволяет уточнить стоимость и срок разработки.
Дискавери-фаза — это начальный аналитический этап, который определяет основные цели, задачи и требования к продукту. На этом этапе проводится сбор информации, определяются ключевые риски и проблемы, которые предстоит решить в процессе разработки. Результатом становится снятие неопределенности и установление границ проекта, что в дальнейшем позволяет уточнить стоимость и срок разработки.
Миф №1. Дискавери — это долго
«Стартуем сейчас, разберемся потом» — частая позиция в ситуациях, когда продукт надо получить как можно быстрее (например, через год), а фаза дискавери может занять целых 2 драгоценных месяца.
И тут есть два важных момента.
Во-первых, при желании дискавери можно сделать и за меньшее время. На скорость этой работы влияет не только профессионализм подрядчиков, но и желание и готовность клиента. Чем быстрее предоставляется информация, согласовываются документы, назначаются встречи, тем быстрее проектная команда проходит все этапы и выдает результат. Впоследствии благодаря такой сыгранности на старте общая скорость разработки проекта увеличивается в разы.
Во-вторых, тезис «быстрее начнем — быстрее закончим» не всегда срабатывает так, как хотелось бы.
Когда команда идет в разработку без подготовленного плана действий (проведенного дискавери), она начинает самостоятельно определять: с чего начинать, откуда брать информацию, кто предоставляет API, какие задачи и функциональность в приоритете, кто и за что отвечает. В лучшем случае реальный старт разработки может отложиться на те же пару месяцев.
Печальнее сценарий, когда команда принимает решения, основываясь только на собственном видении проекта, и закладывает архитектуру, начинает разрабатывать функциональность, готовит дизайн-концепты, а на первом демо оказывается, что прототип не отвечает задачам проекта и не закрывает боль клиента. Действительно критичные фичи не сделаны, а второстепенные уже готовы. И еще потерян кусок работ, потому что о нем не подумали на старте. В общем, не предусмотрели то, чего не знали.
В итоге хотели сэкономить пару месяцев, а придется откладывать срок запуска на год.
И тут есть два важных момента.
Во-первых, при желании дискавери можно сделать и за меньшее время. На скорость этой работы влияет не только профессионализм подрядчиков, но и желание и готовность клиента. Чем быстрее предоставляется информация, согласовываются документы, назначаются встречи, тем быстрее проектная команда проходит все этапы и выдает результат. Впоследствии благодаря такой сыгранности на старте общая скорость разработки проекта увеличивается в разы.
Во-вторых, тезис «быстрее начнем — быстрее закончим» не всегда срабатывает так, как хотелось бы.
Когда команда идет в разработку без подготовленного плана действий (проведенного дискавери), она начинает самостоятельно определять: с чего начинать, откуда брать информацию, кто предоставляет API, какие задачи и функциональность в приоритете, кто и за что отвечает. В лучшем случае реальный старт разработки может отложиться на те же пару месяцев.
Печальнее сценарий, когда команда принимает решения, основываясь только на собственном видении проекта, и закладывает архитектуру, начинает разрабатывать функциональность, готовит дизайн-концепты, а на первом демо оказывается, что прототип не отвечает задачам проекта и не закрывает боль клиента. Действительно критичные фичи не сделаны, а второстепенные уже готовы. И еще потерян кусок работ, потому что о нем не подумали на старте. В общем, не предусмотрели то, чего не знали.
В итоге хотели сэкономить пару месяцев, а придется откладывать срок запуска на год.
Это как идти в поход без разработки маршрутного листа. Думали, что сэкономим пару дней на изучении местности и планировании, а в итоге заблудились, остались без еды и переломали ноги.
Это как идти в поход без разработки маршрутного листа. Думали, что сэкономим пару дней на изучении местности и планировании, а в итоге заблудились, остались без еды и переломали ноги.
Миф №2. Дискавери — это дорого
Давайте считать.
В зависимости от сложности и масштаба проекта дискавери-фаза обычно занимает от 2 недель до 2 месяцев работы бизнес-архитекторов, аналитиков и лидов разработки. Беря в расчет рыночные зарплаты с hh.ru, наш опыт и мировую практику, получаем стоимость работ: от 500 тыс. до 5 млн рублей. Меньше — вряд ли, больше — возможно, но редко.
В итоге: дорогие специалисты поработали, код не написан, посмотреть на красивый макет в Figma нельзя, и кроме пакета документов потрогать нечего.
Но ценность познается только в сравнении.
Представим, что сработали риски, описанные в предыдущем пункте: команда вслепую пилит фичи для новой программы лояльности и упускает из вида важный кусок работ — например, интеграцию с сервисом отчетности. Может оказаться, что структура хранения данных не позволяет строить отчеты с нужной скоростью, система перегружается, виснет и вылетает. Чтобы все работало как нужно, придется либо перерабатывать структуру хранения данных, либо разрабатывать отдельный сервис/базу для их хранения в нужном формате. Конечно, это потребует дополнительных ресурсов: и времени, и бюджетов.
Вариантов таких ситуаций может быть бесконечное множество.
Приблизительно их можно оценить так:
Плюсуйте к этому расходы на собственный менеджмент — всем этим «пожаром» нужно будет управлять, и скорее всего в антикризисном режиме на овертаймах.
Не промолчим и о том, что в некоторых случаях придется поступаться принципами и соглашаться на неприятные костыльные решения, а часть фичей — хоронить.
В зависимости от сложности и масштаба проекта дискавери-фаза обычно занимает от 2 недель до 2 месяцев работы бизнес-архитекторов, аналитиков и лидов разработки. Беря в расчет рыночные зарплаты с hh.ru, наш опыт и мировую практику, получаем стоимость работ: от 500 тыс. до 5 млн рублей. Меньше — вряд ли, больше — возможно, но редко.
В итоге: дорогие специалисты поработали, код не написан, посмотреть на красивый макет в Figma нельзя, и кроме пакета документов потрогать нечего.
Но ценность познается только в сравнении.
Представим, что сработали риски, описанные в предыдущем пункте: команда вслепую пилит фичи для новой программы лояльности и упускает из вида важный кусок работ — например, интеграцию с сервисом отчетности. Может оказаться, что структура хранения данных не позволяет строить отчеты с нужной скоростью, система перегружается, виснет и вылетает. Чтобы все работало как нужно, придется либо перерабатывать структуру хранения данных, либо разрабатывать отдельный сервис/базу для их хранения в нужном формате. Конечно, это потребует дополнительных ресурсов: и времени, и бюджетов.
Вариантов таких ситуаций может быть бесконечное множество.
Приблизительно их можно оценить так:
- Допиливание фичей — от 5 до 20 млн руб. (2-6 месяцев работы средней команды разработки).
- Переделка архитектуры — от 10 млн рублей (3 месяца работы сеньор лида разработки) и остановка работы команды на квартал.
- Аналитика и доработка для интеграции с сервисом — от 6 млн рублей (2 месяца работы аналитика и команды разработки).
Плюсуйте к этому расходы на собственный менеджмент — всем этим «пожаром» нужно будет управлять, и скорее всего в антикризисном режиме на овертаймах.
Не промолчим и о том, что в некоторых случаях придется поступаться принципами и соглашаться на неприятные костыльные решения, а часть фичей — хоронить.
Миф №3. Дискавери не несет пользы для бизнеса
Бытует мнение, что на этапе дискавери-фазы клиент платит только за то, чтобы команда разработки могла комфортнее стартовать проект и снизила свои риски.
Но это не так.
Дискавери-фаза — это не только изучение инфраструктуры и подготовка к старту разработки. Большая доля в этой работе отводится исследованию болей и задач клиента. Для бизнеса это ключевая точка внутренней синхронизации по целям проекта: какие подразделения или лица в нем участвуют, и как будут использоваться его результаты.
Мы видели истории, когда проект сдан, KPI менеджмента выполнен, бюджет потрачен, а пользы — ноль. Всему виной потеря информации по цепочке от бизнеса до менеджера, с которым непосредственно коммуницирует подрядчик. Неполные, обрывочные знания о сути проекта напрямую негативно влияют на его полезность и применимость в реальной жизни.
Представим кейс. Школа для молодых мам захотела продавать свои курсы для беременных. Была выбрана стратегия — разработать собственное мобильное приложение для притока аудитории и дальнейшие продажи курса через него. Приложение разработали, бюджет потратили, но при релизе оказалось, что на рынке уже существуют подобные приложения. Чтобы достичь бизнес-целей, необходимо вложить в рекламу х5 от стоимости разработки самого приложения, а также нести постоянные расходы на его содержание и развитие. Ровно такого же результата по продажам курса можно было добиться меньшими ресурсами: лендингом и рекламой, например, в уже существующих на рынке мобильных продуктах.
Но это не так.
Дискавери-фаза — это не только изучение инфраструктуры и подготовка к старту разработки. Большая доля в этой работе отводится исследованию болей и задач клиента. Для бизнеса это ключевая точка внутренней синхронизации по целям проекта: какие подразделения или лица в нем участвуют, и как будут использоваться его результаты.
Мы видели истории, когда проект сдан, KPI менеджмента выполнен, бюджет потрачен, а пользы — ноль. Всему виной потеря информации по цепочке от бизнеса до менеджера, с которым непосредственно коммуницирует подрядчик. Неполные, обрывочные знания о сути проекта напрямую негативно влияют на его полезность и применимость в реальной жизни.
Представим кейс. Школа для молодых мам захотела продавать свои курсы для беременных. Была выбрана стратегия — разработать собственное мобильное приложение для притока аудитории и дальнейшие продажи курса через него. Приложение разработали, бюджет потратили, но при релизе оказалось, что на рынке уже существуют подобные приложения. Чтобы достичь бизнес-целей, необходимо вложить в рекламу х5 от стоимости разработки самого приложения, а также нести постоянные расходы на его содержание и развитие. Ровно такого же результата по продажам курса можно было добиться меньшими ресурсами: лендингом и рекламой, например, в уже существующих на рынке мобильных продуктах.
В каких проектах нужна дискавери-фаза?
С первого взгляда кажется, что дискавери нужно проводить только в случаях, когда на проекте нет ТЗ (технического задания) — именно в нем должны быть обозначены границы проекта, прописаны требования к функциональности и производительности, логика работы. Но такие по-настоящему проработанные, подробные документы стоят дорого и пишутся крайне редко. И еще реже валидируются доверенным техническим специалистом со стороны клиента, который готов подписаться под результатом.
Намного чаще мы встречаем поверхностно описанные требования к функциональности продукта без вдумчивой, осознанной проработки бизнесовой части. Такие документы тоже полезны — они помогают на старте получить представление о задаче клиента. Помогают ли они быстрее стартовать разработку? Увы, нет.
Еще одна история — стартап-проекты, когда на старте в принципе не может быть четкого определения, что из себя должен представлять продукт.
Требования к нему появляются параллельно разработке, вместе с погружением в нишу и целевую аудиторию. Но даже в этом случае дискавери-фаза будет полезна для проведения продуктового планирования, определения бенчмарков и ключевой функциональности MVP, что позволит на старте не распыляться на разработку второстепенных фичей и как можно быстрее вывести продукт на рынок.
Дискавери можно (и нужно) проводить, когда:
В этих случаях ключевая задача фазы дискавери — помочь зайти в этап разработки не в состоянии «весело и страшно», а в режиме управляемости и уверенности, что все происходящее имеет смысл и ценность.
Ровно так было в нашем кейсе с «РУЛОГ», когда нам нужно было за год импортозаместить b2b-портал. Несмотря на сжатые сроки и большой объем работ, мы выделили два месяца на дискавери, во время которого полностью разобрались в бизнес-процессах клиента, сформировали видение MVP продукта и зафиксировали план действий. За оставшееся время прошли этапы разработки, интеграции и внедрения согласно намеченному плану. Клиент получил продукт, который ожидал, и который полностью выполняет его бизнес-задачи. Бизнес понес нулевые затраты на переобучение сотрудников и сохранил всю операционную деятельность. Мы с удовольствием продолжаем развивать проект.
Намного чаще мы встречаем поверхностно описанные требования к функциональности продукта без вдумчивой, осознанной проработки бизнесовой части. Такие документы тоже полезны — они помогают на старте получить представление о задаче клиента. Помогают ли они быстрее стартовать разработку? Увы, нет.
Еще одна история — стартап-проекты, когда на старте в принципе не может быть четкого определения, что из себя должен представлять продукт.
Требования к нему появляются параллельно разработке, вместе с погружением в нишу и целевую аудиторию. Но даже в этом случае дискавери-фаза будет полезна для проведения продуктового планирования, определения бенчмарков и ключевой функциональности MVP, что позволит на старте не распыляться на разработку второстепенных фичей и как можно быстрее вывести продукт на рынок.
Дискавери можно (и нужно) проводить, когда:
- вы хотите быть уверены, что ничего не забыли в скоупе;
- до конца не понимаете, как работает ваша система;
- нужно проверить соответствие состава работ целям бизнеса;
- надо запустить новый продукт, но нет ни роадмэпа, ни четкого понимания функциональности;
- важно строго соблюдать бюджет, уложиться в сроки;
- надо рассчитать эффект, который может принести планируемый проект;
- надо оценить объем работ и сроки.
В этих случаях ключевая задача фазы дискавери — помочь зайти в этап разработки не в состоянии «весело и страшно», а в режиме управляемости и уверенности, что все происходящее имеет смысл и ценность.
Ровно так было в нашем кейсе с «РУЛОГ», когда нам нужно было за год импортозаместить b2b-портал. Несмотря на сжатые сроки и большой объем работ, мы выделили два месяца на дискавери, во время которого полностью разобрались в бизнес-процессах клиента, сформировали видение MVP продукта и зафиксировали план действий. За оставшееся время прошли этапы разработки, интеграции и внедрения согласно намеченному плану. Клиент получил продукт, который ожидал, и который полностью выполняет его бизнес-задачи. Бизнес понес нулевые затраты на переобучение сотрудников и сохранил всю операционную деятельность. Мы с удовольствием продолжаем развивать проект.
