Процессы в стартапах чаще всего находятся в хаосе. Это сродни рождению Вселенной. Все возникает с нуля, какие-то структуры в последствии сталкиваются с другими, получаются идеи, гипотезы, проекты, некоторые из которых потом рассеиваются в пространстве. Как управлять этим хаосом и выстроить первую систему, редакции РШУ рассказала CEO и сооснователь HR-Tech стартапа Re-Action Екатерина Днепровская.
Бизнес-модель Канвас — первый шаг к структурированию процессов
Когда в 2023 году зародилась идея создания сервиса автоматических рассылок резюме по вакансиям, никто не думал о том, чтобы выстраивать процессы. Важно было как можно быстрее выходить на тестирование гипотезы на рынок. Но даже в этом случае мы уже начали применять первичную для многих стартапов систему — бизнес-модель Канвас. Ее суть заключается в структурировании информации в едином фрейме по основным направлениям: от клиентов, партнеров до ценностей и структуры доходов и расходов. Именно она впоследствии может стать основой для выстраивания первичных процессов в молодой организации.
Когда-то мне посчастливилось быть на очной лекции в Москве у одного из евангелистов этой бизнес модели — Боба Дорфа. А один из лучших курсов на эту тему ведет еще один небезызвестный предприниматель Стив Бланк, автор книги «Стартап: Настольная книга основателя» на Udacity. Кстати, он еще и бесплатный, но на английском. Я крайне его рекомендую и добавляю ссылку на него на YouTube (да, он уже опубликован там).
Зрелость процессов определяется зрелостью проекта и команды
Пока команда была совсем небольшая (6-8 человек из разных специальностей), выстраивание процессов не требовалось, все делалось быстро, а договоренности составлялись прямо на встречах. Но при росте команды до 20 человек и увеличении количества внутренних проектов от автоматизации до перехода на другой технологический стек, мы начали шаг за шагом внедрять синтез из разных подходов и методологий в зависимости от проектов и отделов.
Очень важно отметить, что зрелость процессов напрямую зависит от уровня развития и, опять же, зрелости организации. У нас был сложный кейс, когда тимлид одной из команд из самых лучших побуждений пыталась насадить правильные, на ее взгляд, процессы взаимодействия между группами, тратя на это и время, и нервы. С одной стороны, заложить это сразу в основание будущей компании — идея здравая, но до всего необходимо дорасти. Углубляясь в выстраивание зрелых процессов на начальном уровне MVP, можно потерять и весь стартап.
Lean-разработка как основа бережливого стартапа
Итак, первый подход, который мы активно применяем в стартапе — это Lean-разработка. В первую очередь она необходима для параллельного тестирования нескольких идей, которых в голове у основателей крайне много. Ведь известно, что стартапы погибают не от недостатка идей, а от их огромного количества. Но что очень важно, тестирование и исследование происходит до этапа разработки: туда должны попадать только отобранные проекты.
Например, у нас родилась интересная идея — сделать скан резюме, который будет собирать ключевые навыки. Проект улетает на исследование к data scientist, который изучает, а возможно ли это в принципе сделать. Уже через неделю мы получаем предварительный ответ. Дальше проект остается в группе до момента вывода его на первые тесты в фокус-группах. И даже после этого проект не передается в разработку. Первоначально мы отправляем его на бизнес-тестирование и только после получения первых тестовых продаж и сбора обратной связи проект встает в очередь к аналитикам, которые тщательно соберут все данные, сделают описание и передадут в разработку.
Agile-подходы для стартапа
Другой подход, который также оберегает нашу разработку от работы «в стол» — это элементы из гибких методик управления Agile. Еще на старте мы четко понимали, что фреймворк Scrum к нам неприменим: у нас распределенная команда, которая работает в асинхронном режиме из разных часовых поясов. Но некоторые подходы мы взяли оттуда. И первый — работа по спринтам. У нас они составляют 3 месяца. Да, в Scrum обычно это 1-2 недели, но для нас так оказалось намного удобнее.
Все идеи, какими бы безумными, клевыми, нужными, скучными, прорывными ни были, попадают в бэклог идей. У нас это отдельная статья для основателей в вики в GitLab и проект в Miro. За 2-3 недели до нового спринта мы начинаем перебирать их и сравнивать с приоритетами на текущий момент. Для этого у нас порядка 7 критериев: от сложности реализации, наличия ресурсов до хайповости. Но главные — это снижение рисков (создание более антихрупкой системы, конкурентоспобность, отказоустойчивость) и инновационность (конкурентные преимущества завтрашнего дня). Выбираем примерно 3-4 проекта для реализации и тестирования. Остальные идут на следующие спринты, примерный план реализации которых висит в том же Миро.
Для каждого проекта предусмотрен этап аналитики, несмотря на то, что это может значительно задерживать скорость реализации, а конкуренты держат нервную систему в постоянном тонусе. Зато часть идей отсеется, а разработка получит понятную и четкую задачу, реализация которой не будет тормозиться и спотыкаться. Честно говоря, в продуктовой разработке и без этого есть много бутылочных горлышек.
Контролируя процессы в проектах, мы стараемся отслеживать возникновение «заторов». Например, на моменте передачи разработанного макета в Figma от дизайнеров у фронт-разработки по ходу возникало много вопросов, что сильно тормозило процессы. Мы поняли, что «костылить» тут больше не получается — пересобрали процесс по-новому и поставили на него тестовый период. В апреле посмотрим, что сработало, а что надо будет выстроить по-другому. В общем, применение базовых элементов Теории ограничения систем возможно даже в стартапе при невысокой зрелости процессов.
Возвращаясь к Agile, мы заменили ежедневные 5-минутки на краткие отчеты в Telegram в формате «Что сделано / Что будет сделано / Проблемы» 3 раза в неделю. Для нашей распределенной асинхронной команды это оказалось намного удобнее для быстрой синхронизации. Но без встреч обойтись невозможно, поэтому 1 раз в неделю митинг для обсуждения проблем и распределения новых задач.
Пока команды разработки делают синтез между разными подходами в управлении проектами, другие группы («продуктовый дизайн» и «группа развития» используют принципы регулярного менеджмента, а проекты планируют по Waterfall. Мы не считаем правильным заставлять всю команду работать только в одном подходе. Возможно, именно в этом и проявляется гибкость, но эту гипотезу тоже стоит проверить.