«Это пока не для нас»
Так звучит расхожее мнение среди основателей маленьких стартапов, которые считают, что моделирование процесса разработки лучше отложить на потом, когда компания вырастет. Но откладывать настройку процессов «на вырост» – большая ошибка, поскольку это может оказаться именно тем препятствием, которое в итоге не позволит стартапу развиваться.
Стартап – это небольшая и, что очень важно, молодая компания с теми же самыми проблемами и задачами, что и у большой, но помноженными на два: привлечь деньги без продаж – очень сложно, но делать продажи без продукта – еще сложнее. В связи с этим любой стартап даже самый маленький, не слишком отличается по процессам от любой другой компании.
К сожалению, большинство стартапов вообще не прописывают свои бизнес-процессы, потому что их основатели считают, что маленькая команда в этом не нуждается – и так понятно, кто и за что отвечает. Например, человек работает разработчиком в Ozon и параллельно с двумя-тремя единомышленниками делает свою компанию. Собственно, у него отсутствуют какие-либо процессы, они и не нужны, потому что у него пока небольшая команда, и в ней на самом деле четко распределены все роли.
Второй вариант: владелец — продавец, и он ходит по рынку и предлагает идеи. На своем энтузиазме он нашел довольно большую команду разработчиков, дизайнеров, всего около десяти человек. Но и эта команда все равно является стартапом, потому что у проекта на этом этапе нет денег, их надо откуда-то привлекать. В этом случае стартап уже нуждается в разработке бизнес-процессов, чтобы получить четкое понимание того, как будет развиваться компания.
Сначала что, а потом как
Процесс разработки обычно выглядит довольно просто: сначала определяется, что делать, а потом определяется как именно делать.
Первая часть, «что делать» — это чистой воды продакт-менеджмент. В это время происходит сверка функциональных требований и сбор бизнес-требований, а уже потом определяется как именно все это будет реализовано в будущем. В этот момент, как правило, должна появиться команда разработки и проектный менеджмент, который является на данном этапе ключевой персоной.
В понятие «как делать» входит, во-первых, дизайн, а, во-вторых, непосредственно сама разработка и грамотное управление ею. Что мы понимаем под управлением? Это умение правильно ставить задачи, своевременно их проверять, учитывать архитектуру всей системы, учитывать стратегию компании для того, чтобы масштабировать инфраструктуру.
Как выстроить процесс?
1. Найти IT-ментора
Как правило, это разработчики, тим-лиды и архитекторы, которые хотят расширить свой опыт, посмотреть на разработку под другим углом, или изучить новую нишу. Найти такого человека бесплатно не составит труда. Сейчас достаточно платформ, тематических чатов, групп, где можно поискать технических кураторов и менторов.
2. Настроить процесс менеджмента разработки
Сейчас популярен agile – гибкая методология разработки, которая предполагает активное взаимодействие между участниками многофункциональных команд. В ней есть четыре артефакта:
- Планирование, где мы рассматриваем, что будем делать на этой неделе, в этом спринте. Спринт – короткий временной интервал, в течение которого команда выполняет заданный объем работы.
- Дейли — ежедневные летучки.
- Демо – показ результатов, достигнутых командой, и их оценка в конце каждого спринта.
- Ретроспектива, где мы обсуждаем что получилось, что нет и почему.
На летучках ставится три вопроса:
- Что мы сделали?
- Что мы делаем?
- Какие проблемы возникают?
Желательно, чтобы все визуализировалось с помощью скрам или канбан-доски. На ней вывешиваются задачки, на каждую из которых выделяется не более чем 16 рабочих часов, то есть за неделю по доске должны проходить несколько задачек. Это позволяет предпринимателю, владельцу видеть трекшн, то, насколько успешно реализуется бизнес-модель стартапа, и своевременно реагировать на изменения разработки и бизнес-требований.
3. Отрисовать IT-архитектуру будущего продукта
Для этого программисту либо куратору дается задача на отрисовку. Он изучает, какие компоненты будут в системе, какие из них мы будем брать от сторонних подрядчиков и так далее. Таким образом получается некая схема, с которой мы будем в дальнейшем работать. Она поможет сориентироваться, когда проект будет выходить за рамки первоначальных требований. Для создания этой схемы надо показать путь пользователя: отрисовать ситуации, с которыми он будет сталкиваться, что нужно сохранить в функционале.
4. Вести разработку на доске + иметь Вики-систему
Например, Notion для того, чтобы собирать базу знаний, и чтобы сохранять данные, с которыми работает команда. Кроме этого, требуется создать репозиторий, чтобы было место для хранения кода, и куратор мог постоянно заходить и отслеживать изменения. Чем больше пунктов из этого будут соблюдаться, тем лучше будет вестись разработка. Через подобную прозрачность достигается понимание того, успеваем мы или нет, насколько разработка соответствует поставленным задачам, правильно мы формируем бизнес требования или где-то ошиблись.
Ключевыми в этом процессе являются планирование и дейли, потому что на них сразу становится понятно, насколько глубоко мы понимаем задачу и результат, ожидаемый от нее.
5. Построить диаграмму Ганта или продакт-карту для того, чтобы понимать сроки
Сроки обязательно должны быть определены еще в начале процесса разработки, потому что, если их нет, работа рискует растянутся на неопределенный промежуток времени. Диаграмма Ганта помогает планировать и оперативно реагировать на изменения.
В итоге все работает так: есть архитектура, по которой мы определяем задачи. Начинается планирование, открываем диаграмму Ганта и смотрим, что должно быть сделано в первую очередь. Затем начинаем работау и после этого каждую дейли собираемся и отслеживаем ведение выбранных задач на спринт. Спринт может быть как недельный, так и двухнедельный.
Параллельно с архитектурой прорисовываются макеты дизайна для того, чтобы разработчик смог оценить задачи более детально. Чем больше данных будет на входе, тем лучше мы понимаем насколько своевременно будет сдана задача, и насколько точно она будет соответствовать заявленным ожиданиям.
Подведем итоги
Нет очевидно правильного варианта развития стартапа – это всегда поиск компромиссов и срезание углов в зависимости от ситуации. Одно можно сказать наверняка – для начинающей компании очень важна правильная организация процессов, а техническая экспертиза должна закладываться еще на старте.
Читайте также:
В ИТ очень сложно отойти от массовых заблуждений и трендов. Автор совершенно прав - необходимо сразу выстраивать структуру. Можно даже с какой-то гордостью говорить о том, что у нас, у программистов, очень сложно передавать результат своей работы по акту приёма-передачи, "опись, прОтокол, отпечатки пальцев". Команды многочисленны, разнообразны, участники со своим опытом. Я бы и командой это не стал называть - команда действует по приказам капитана, командира, лидера. А группа разработки больше напоминает бригаду - собрались плотник, печник, штукатур и подмастерье и стали пытаться заработать деньги. Синхронизация очень важна - конвейер из живых людей.
Автор верно пишет, что всё это разнообразие стягивает, синхронизирует, организует воркфлоу более-менее известных продуктов. Часто функционал этих продуктов заменяет и методики и стандарты. Скажу даже не самую популярную вещь - знание таких организующих приложений бывает важнее самой разработки. Набрать любих образцов кода сейчас может любой школьник, только хоть малость отличай питона от джавы-скрипта..
Тем не менее хочу чуток и поправить Виталия. В статье упомянуты практически все новомодные инструменты. эджайл, канбан, продакт-план, дейли, спринты, диаграммы ганта и пр и др. В этом наборе слов, продуктов и особом мире коллективной разработки нужно уметь плавать, разбираться и не выглядеть белой вороной, это верно. Тем не менее, руководитель разработки, организатор разработки должен уметь оторваться от ежедневного мониторинга, постоянного контроля и подняться чуть выше понимания конечного продукта другими участниками команды. Сколько раз наблюдалось красивейшая работа команды со всеми положенными причиндалами и наворотами, но через полгода-года работы всё разваливалось.
Выжить в этом деле без опережающего программирования, без опережающего видения невозможно. А руководителю нужен определённый талант избегания стандартов, умения быть оригинальным. К чертям эджайл, канбан и прочее! Давайте сделаем ежедневное демо и будем хвастаться квалификацией! Моржет так? Ну нет так нет! Завтра что-нибудь ещё придумаю. Всё - придумал! В нашей бригаде на неделю запрещено слово "спринт".
Подход автора не вполне традиционный.
Почему бы не начать с маркетинга и архитектуры? Для кого, собственно, всё это разрабатывается? Кто и как будет этим пользоваться? Кто поддерживать?
Нужны ли именно диаграммы Ганта или что-то другое - вопрос второстепенный. Инструменты планирования определяет менеджер проекта. Он же отвечает за документирование, коммуникации, этапность и бюджет, помимо прочего.
Следующий вопрос - можно ли привлечь менеджера продукта, который тесно работает над требованиями вместе с архитектором и, в зависимости от готовности продукта, общается с потенциальными заказчиками.
Вы совершенно правы!
Может быть Вы согласитесь со мной, что конкретное кодирование, программирование уже давно ушло на второй плна в разработке. Гораздо важнее продвижение продукта, общение с заказчиком, поиск заказчика, клдиента, партнёра.
Выскажу совсем крминальную мысль - программист давно стал штукатуром, но, увы, не строителем. От его способностей мало что зависит, он мало что решает. Он не делает выбора языка программирования, не понимает в оптимизации, не занимается неразрешимыми проблемами. И именно из-за этого его инструментарий мало кого волнует и интересует.
Если Вы об индустриальном подходе, то кодирование, оптимизация, тестирование - очевидно не первый шаг (или даже не несколько первых шагов) в разработке. Но так, по сути, было и раньше, хотя, возможно, называлось другими словами.
Именно поэтому я и предлагаю начинать с обычных упражнений маркетинга, определения своего сегмента, сбору и анализу требований к макету / первой версии (MVP, если угодно) и разработке соответствующей архитектуры.
Мне сложно сказать, где еще можно набрать основную массу требований к функционалу, интерфейсам пользователя, API (если нужно), безопасности и пр., если с самого начала не общаться в максимально плотном режиме с потенциальными и реальными заказчиками, начиная с фокус-групп (формальных и неформальных). Из этого вытекают и подходы к продвижению, версионности, развитию продукта и, естественно, ценообразованию.
Никакого криминала. А штукатур, водопроводчик он или кровельщик - не берусь судить.
У строителей много специальностей, и никто из разумных строителей не строит (и не построит) что-то существенное без проекта - не будут даже начинать. Есть архитекторы, прорабы, производители стройматериалов, бетонные и кирпичные заводы, бетонщики, крановщики, монтажники, штукатуры, электрики, паркетчики, специалисты по лифтам ... - список длинный. Это не считая геологических изысканий на конкретном участке. Но кто-то должен точно знать, какое именно здание строится, для кого, как долго и за какие деньги. Как тут не вспомнить BIM, не зря его полюбили финансисты.
В отрасли IT свои жесткие законы, которые, как и в строительстве, нет смысла нарушать или переписывать для себя. Программист, к примеру, делает то, что он делал всегда - пишет код, желательно максимального качества, в соответствии с техническими и прочими требованиями и в указанные сроки. И в этих требованиях черным по белому написано, пишет ли он некий новый драйвер, часть системы управления уникальным телескопом, многоканальный контакт-центр на несколько тысяч операторов или интернет-магазин. Там же еще более подробно написано, с кем и как из коллег он общается в процессе разработки, от кого что в каком виде получает и кому, что и как отдаёт. От этого зависят и требования к уровню исполнителей, их опыту и прочим компетенциям.
Заказчика (пользователя), как водится, интересует конечный продукт, в том числе сроки его готовности и качество, а не обсуждение, на чем его писать, как проводить совещания (если он в них не принимает участие), какие инструменты кем используются и всё остальное, что решается на уровне проекта. Как Вы совершенно справедливо отметили - а кого это вообще волнует, если не указано в требованиях.
Сомневаюсь, что во всём вышеперечисленном есть хотя бы что-то, с чем Вы много раз не сталкивались и не пропускали через себя. Поправьте меня там, где я ошибся или преувеличил.
Нет, не буду поправлять, практически со всеми Вашими выводами согласен.
Простите, коллеги, но пробежав статью по диагонали, я так и не понял основной идеи - "А нафига козе баян?"
"строит свой бизнес" - что это за бизнес? Экспресс-доставка неучтенки со склада Озон? Пилит лэндинги по ночам? Открыл свою кофейню/лесопилку? Откуда ложный вывод, что у него нет бизнес-процессов? Что означает фраза "они ему не нужны"?
Стартап поэтому и называется "стартап", потому, что это новый бизнес и, сколько человек в нем задействовано - не важно. Хотя 1000 - главное, чтобы они не разбежались раньше времени. И посыл, что разработка бизнес-процессов связана с необходимостью привлечения инвестиций - ложна.
Мало того, развитие компании определяется стратегией (миссией, прости Боже), но никак не бизнес-процессами.
И тут мой когнитивный диссонанс увидел ЭТО и возопил:
Вы серьёзно? Не говоря уже о том, что это (по большей части) относится к IT-структурам, ЭТО вызывает серьезное беспокойство за психологическое здоровье ... этого... как его.... а! Безнестмена! Вот!
п.1 говорит о том, что "владелец идеи" не имеет понятия о продукте - ему нужен бородатый дядя, который разжуёт ему суть проекта и как с этим жить и бороться.
п.2. говорит о том, что у "бизднесмена" нет понимания, что же он хочет получить в конце пути - нет четкого ТЕХНИЧЕСКОГО ЗАДАНИЯ. Отсюдa и тяга к Agile.
п.3 говорит о том, что "идеолог бизднеса" опять-таки, не понимает, что он хочет. Нет, я знаю достаточно много стартапов, когда в процессе развития менялся не только технологический уклад, но и радикально менялся сам продукт.
п.4 - чистая вкусовщина.
п.5. это дань "моде"? Дык "Гант" уже считается прошлым веком (хотя, ЕМНИП, это даже позапрошлый век, но могу ошибаться). Сколько же времени нужно, чтобы построить корректную ДГ силами начинающего стартапера? Неделю? Две? А потом, после каждого "спринта" (мы же топим за Agile???) - перестраивать ее. Или наймем специально обученного мальчика/девочку для работы с ДГ?
В результате проект умирает, едва начавшись... Потому, что лошадь вперед паровоза, а телега не хочет везти вагоны...
Не претендуя на авторство (я же не только сейчас это выдумал, вероятно, прочитал где-то), процесс разработки организуется так:
1. Разрабатывается стратегия.
2. Ставятся цели.
3. Формулируются задачи - текущие и перспективные.
4. Оценивается:
- взаимосвязи/взаимозависимость задач, при необходимости, формируется кроссировка.
- определяются потребные ресурсы для выполнения задач
5. С заказчиком согласуется первая итерация дизайна.
6. Задачи детализируются, декомпозируются и составляется план работ (неважно какой именно, хоть простой чек-лист - у нас же не стартап по созданию космического аппарата?)
7. Оценивается время и, при необходимости, корректируется состав ресурсов, чтобы обеспечить своевременное исполнение нашего проекта (в данном случае - разработки, хотя так можно организовать работу по любой тематике).
И когда все звЕзды сойдутся (время, деньги и счастье заказчика) - начинается работа над проектом. В процессе работы, неминуемо, вылезут подводные камни, что гарантированно сдвинет сроки - но это уже ляжет на "главного стартапера" - и как он это разрулит - так и будет.
Я не претендую на истину в конечной инстанции, если коллеги уточнят - буду тольк рад.