«Это пока не для нас»
Так звучит расхожее мнение среди основателей маленьких стартапов, которые считают, что моделирование процесса разработки лучше отложить на потом, когда компания вырастет. Но откладывать настройку процессов «на вырост» – большая ошибка, поскольку это может оказаться именно тем препятствием, которое в итоге не позволит стартапу развиваться.
Стартап – это небольшая и, что очень важно, молодая компания с теми же самыми проблемами и задачами, что и у большой, но помноженными на два: привлечь деньги без продаж – очень сложно, но делать продажи без продукта – еще сложнее. В связи с этим любой стартап даже самый маленький, не слишком отличается по процессам от любой другой компании.
К сожалению, большинство стартапов вообще не прописывают свои бизнес-процессы, потому что их основатели считают, что маленькая команда в этом не нуждается – и так понятно, кто и за что отвечает. Например, человек работает разработчиком в Ozon и параллельно с двумя-тремя единомышленниками делает свою компанию. Собственно, у него отсутствуют какие-либо процессы, они и не нужны, потому что у него пока небольшая команда, и в ней на самом деле четко распределены все роли.
Второй вариант: владелец — продавец, и он ходит по рынку и предлагает идеи. На своем энтузиазме он нашел довольно большую команду разработчиков, дизайнеров, всего около десяти человек. Но и эта команда все равно является стартапом, потому что у проекта на этом этапе нет денег, их надо откуда-то привлекать. В этом случае стартап уже нуждается в разработке бизнес-процессов, чтобы получить четкое понимание того, как будет развиваться компания.
Сначала что, а потом как
Процесс разработки обычно выглядит довольно просто: сначала определяется, что делать, а потом определяется как именно делать.
Первая часть, «что делать» — это чистой воды продакт-менеджмент. В это время происходит сверка функциональных требований и сбор бизнес-требований, а уже потом определяется как именно все это будет реализовано в будущем. В этот момент, как правило, должна появиться команда разработки и проектный менеджмент, который является на данном этапе ключевой персоной.
В понятие «как делать» входит, во-первых, дизайн, а, во-вторых, непосредственно сама разработка и грамотное управление ею. Что мы понимаем под управлением? Это умение правильно ставить задачи, своевременно их проверять, учитывать архитектуру всей системы, учитывать стратегию компании для того, чтобы масштабировать инфраструктуру.
Как выстроить процесс?
1. Найти IT-ментора
Как правило, это разработчики, тим-лиды и архитекторы, которые хотят расширить свой опыт, посмотреть на разработку под другим углом, или изучить новую нишу. Найти такого человека бесплатно не составит труда. Сейчас достаточно платформ, тематических чатов, групп, где можно поискать технических кураторов и менторов.
2. Настроить процесс менеджмента разработки
Сейчас популярен agile – гибкая методология разработки, которая предполагает активное взаимодействие между участниками многофункциональных команд. В ней есть четыре артефакта:
- Планирование, где мы рассматриваем, что будем делать на этой неделе, в этом спринте. Спринт – короткий временной интервал, в течение которого команда выполняет заданный объем работы.
- Дейли — ежедневные летучки.
- Демо – показ результатов, достигнутых командой, и их оценка в конце каждого спринта.
- Ретроспектива, где мы обсуждаем что получилось, что нет и почему.
На летучках ставится три вопроса:
- Что мы сделали?
- Что мы делаем?
- Какие проблемы возникают?
Желательно, чтобы все визуализировалось с помощью скрам или канбан-доски. На ней вывешиваются задачки, на каждую из которых выделяется не более чем 16 рабочих часов, то есть за неделю по доске должны проходить несколько задачек. Это позволяет предпринимателю, владельцу видеть трекшн, то, насколько успешно реализуется бизнес-модель стартапа, и своевременно реагировать на изменения разработки и бизнес-требований.
3. Отрисовать IT-архитектуру будущего продукта
Для этого программисту либо куратору дается задача на отрисовку. Он изучает, какие компоненты будут в системе, какие из них мы будем брать от сторонних подрядчиков и так далее. Таким образом получается некая схема, с которой мы будем в дальнейшем работать. Она поможет сориентироваться, когда проект будет выходить за рамки первоначальных требований. Для создания этой схемы надо показать путь пользователя: отрисовать ситуации, с которыми он будет сталкиваться, что нужно сохранить в функционале.
4. Вести разработку на доске + иметь Вики-систему
Например, Notion для того, чтобы собирать базу знаний, и чтобы сохранять данные, с которыми работает команда. Кроме этого, требуется создать репозиторий, чтобы было место для хранения кода, и куратор мог постоянно заходить и отслеживать изменения. Чем больше пунктов из этого будут соблюдаться, тем лучше будет вестись разработка. Через подобную прозрачность достигается понимание того, успеваем мы или нет, насколько разработка соответствует поставленным задачам, правильно мы формируем бизнес требования или где-то ошиблись.
Ключевыми в этом процессе являются планирование и дейли, потому что на них сразу становится понятно, насколько глубоко мы понимаем задачу и результат, ожидаемый от нее.
5. Построить диаграмму Ганта или продакт-карту для того, чтобы понимать сроки
Сроки обязательно должны быть определены еще в начале процесса разработки, потому что, если их нет, работа рискует растянутся на неопределенный промежуток времени. Диаграмма Ганта помогает планировать и оперативно реагировать на изменения.
В итоге все работает так: есть архитектура, по которой мы определяем задачи. Начинается планирование, открываем диаграмму Ганта и смотрим, что должно быть сделано в первую очередь. Затем начинаем работау и после этого каждую дейли собираемся и отслеживаем ведение выбранных задач на спринт. Спринт может быть как недельный, так и двухнедельный.
Параллельно с архитектурой прорисовываются макеты дизайна для того, чтобы разработчик смог оценить задачи более детально. Чем больше данных будет на входе, тем лучше мы понимаем насколько своевременно будет сдана задача, и насколько точно она будет соответствовать заявленным ожиданиям.
Подведем итоги
Нет очевидно правильного варианта развития стартапа – это всегда поиск компромиссов и срезание углов в зависимости от ситуации. Одно можно сказать наверняка – для начинающей компании очень важна правильная организация процессов, а техническая экспертиза должна закладываться еще на старте.
Читайте также: