«Скрытые» затраты стартапа: из чего состоит разработка ИТ-продукта

Разработка любого ИТ-продукта — это процесс, который включает его создание, развертывание, эксплуатацию и развитие. Ни один ИТ-продукт, даже великий, не создается «раз и навсегда». Согласно исследованию Blossom Street Ventures, SaaS-компании тратят в среднем 24% выручки на разработку, а есть те, кто тратит больше 50%.

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

Нашей компании уже 7 лет. И каждый год мы сталкиваемся с 2 типами заблуждений:

• Нужна какая-то конкретная сумма денег, чтобы запустить продукт и потом заниматься только продажами.
• Деньги понадобятся только на разработку новых функций.

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

Финансовое планирование стартапов часто затруднено градусом неопределенности дальнейшей жизни проекта. Обычно составление бюджета на разработку ограничивается пониманием того, сколько в месяц заказчик готов на нее тратить. Дальше уже подрядчик или внутренняя команда строит план работ. И если вы фаундер IT-стартапа, вам важно знать все статьи бюджета разработки и понимать, на что ушли деньги:

Разработка новых функций. Если IT продукту нужно новое свойство, сценарий, роль, разработка займется этим. Сценариев появления новых функций может быть несколько. Например, часто стартап начинает с разработки MVP (минимального жизнеспособного продукта) с ограниченным количеством функций. После выпуска и сбора обратной связи, к MVP добавляются новые, нужные пользователям функции.

Работа с багами. Баг означает ошибку в программе или в системе, из-за которой программа выдает неожиданное поведение и результат. Баги появляются по многим причинам: ошибка в коде, неожиданное пользовательское поведение, ошибки в готовых библиотеках и компонентах и пр. Очевидно, что баг — это плохо. Каждый желает, чтобы IT-продукт работал идеально, без сбоев и странного поведения. Но реальность такова, что если продукт больше одного поля с одной кнопкой, баги неизбежны. Ни один IT продукт не застрахован от их появления. Они есть у всех. Зная это, команда разработки должна иметь:

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

- систему выявления багов в продуктивной среде;

- отлаженный процесс работы с обратной связью от конечных пользователей, чтобы быстро реагировать на массовые и критические ошибки;

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

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

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

Работа с запросами маркетинга и продаж. Маркетологи, продавцы и продакт менеджеры часто дают команде разработки задачи, не связанные с добавлением функционала продукта. Эти задачи связаны с анализом поведения пользователей, онбордингом, А-Б тестами и т. п. Один из примеров — изменение тарифной сетки. Речь не о том, когда меняется только цена тарифа (это несложно поменять) , а когда тарифы отличаются входящим в него функционалом. В этом случае продукт должен действовать по определенной новой логике, и команда разработки тратит на это свое время.

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

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

Инфраструктура. Статья, которая может занимать значительное место в бюджете стартапа — это покупка или аренда вычислительных мощностей, на базе которых работают приложения и сервисы. Это могут быть серверы и виртуальные машины, дисковое пространство для хранения данных, а также специальные сервисы, например — защита от DDoS-атак, отправка SMS или электронной почты, CDN для ускорения загрузки фото- и видеоконтента и пр.

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

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

• бизнес-задачи – задачи по разработке дополнительного функционала продукта, отвечающего бизнес-требованиям заказчика;
• работа с багами, технической долг, исследования и прочие категории, описанные выше.
• прочие задачи – задачи, которые не могут быть однозначно классифицированы в одну из категорий (стендапы, коммуникации между членами команды, онбординг новых сотрудников на проекте и т.п.).

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

Каждая бизнес-задача формулируется в виде эпика. Эпик в начале содержит в себе только задачи на подготовку спецификаций аналитиками и макетов дизайнерами. Далее на основании подготовленных спецификаций происходит разбиение эпика на одну или несколько пользовательских историй. Каждая пользовательская история содержит задачи на разработчиков и дефекты, обнаруженные впоследствии командой QA при тестировании истории. Таким образом, каждая бизнес-задача распадается на множество подзадач, каждая из которых назначается на одного исполнителя и одного ответственного за QA.

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

Всё это позволяет давать клиентам следующие виды аналитики:

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

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

Напишите нам, если у вас остались вопросы. Мы проконсультируем по аутсорс разработке или поговорим, как эффективно управлять вашей внутренней командой.