Когда вы решаете запустить технологический стартап, то рано или поздно становитесь перед выбором: каким образом создавать продукт. Стоит ли жестко распланировать все этапы и делать все шаг за шагом? Или лучше работать короткими итерациями, чтобы была возможность отследить свою результативность и вовремя внести правки в будущий прототип? Или разбить работу на несколько не зависящих друг от друга частей, и для каждой из них выделить отдельную команду? Все это определяют модели и методологии разработки продукта, которых десятки, и каждая из них имеет свои преимущества и недостатки. В этой статье рассмотрим наиболее популярные из них.
Startup Jedi
Мы общаемся со стартапами и инвесторами, а вы перенимаете опыт.
Модель разработки продукта — это то, через какие стадии он проходит во время создания и что происходит на каждой из них. Если речь идет о разработке программного обеспечения, то, как правило, проект проходит через шесть основных фаз. Это:
Планирование. Определяем, что делаем и какие проблемы решаем. Ставим цели, выясняем, какие ресурсы нам нужны для реализации проекта. Изучаем рынок и конкурентов, прорабатываем альтернативные варианты разработки продукта.
Анализ системы. Определяем и документируем требования конечного пользователя системы. Какие ожидания есть у нашего потребителя и как мы можем их осуществить? Можем ли мы это сделать вообще?
Дизайн. Определяем элементы системы, ее компоненты, уровень безопасности, архитектуру, интерфейсы, типы данных. Рисуем дизайн, обсуждаем, проектируем.
Разработка и внедрение. К началу этой стадии дизайн уже завершен, наступает очередь разработки. Пишем код, настраиваем систему под определенные требования и функции. К концу фазы система готова к установке и запуску.
Тестирование. Проверяем, получили мы в итоге то, что хотели, или же результаты работы оказались другими. Тестируем продукт автоматизированными тестами, командой, предлагаем поработать с системой потенциальным пользователям. Определяем дефекты и недостатки в работе системы и устраняем их.
Поддержка системы. Подготовка и выпуск обновлений, оценка производительности системы, замена/деактивация устаревших компонентов.
Это классическая схема, которая изменяется в зависимости от того, каким образом идет разработка, а также от специфики работы команды, размера бюджета и особенностей продукта. Именно здесь и наступает момент выбора модели разработки. Они подразделяются на классические и гибкие.
Вот список классических моделей:
Code and Fix (написание кода, проверка и устранение ошибок),
Waterfall (проект последовательно проходит все стадии),
V-Model (проведение тестирования одновременно с разработкой),
Инкрементная модель (проект делится на составные компоненты, команда по очереди готовит каждый из них, затем происходит финальная сборка),
Спиральная модель (предусматривает тщательную проработку рисков),
Итеративная модель (сначала делается базовая модель продукта, затем следуют итерации по ее усовершенствованию),
RAD-Model (скоростная разработка продукта).
Классические модели предполагают акцент на последовательности, сроках, конечных требованиях к продукту.
Что касается гибких моделей, то это всем известный Agile. Когда мы работаем над продуктом по гибкой модели, наш проект и требования к нему могут меняться в течение каждой итерации (гибкая модель, когда проект может изменяться с каждой итерацией), а что касается сроков, то работа может вестись бесконечно — вы будете совершенствовать продукт и добавлять в него новый функционал.
Наконец, методологии разработки — это применение той или иной модели на практике. Так, Agile-модель имеет целый ряд довольно популярных методологий — от мягкого Kanban, когда команда работает с доской с задачами, до жестких Scrum и XP.
Теперь рассмотрим особенности каждой из упомянутых моделей.
...
Это одна из самых старых моделей разработки: она очень проста и подойдет стартапам, где команда невелика, нет особых конфликтов, вы знаете, что хотите сделать и имеете представление, как это сделать.
Как работает Code-and-Fix: у нас есть понимание, что мы хотим сделать. Начинаем программировать, затем смотрим, что получилось. Выявляем баги, правим их и снова смотрим — и так, пока наш продукт не начнет работать.
Плюсы методологии: не нужно тратить время на планы, документацию, митинги.
Минусы: иногда исправление одной ошибки приводит к тому, что у вас ломается вся система. В итоге приходится переделывать — снова и снова. Поэтому когда-то давно программисты, которые мучились с этой моделью разработки, решили уйти от ее мнимой простоты и изобрести другую.
...
Одним из первых выходов стал Waterfall, или водопадная (каскадная) модель разработки. Это классическая жесткая модель: у вас есть план, бюджет и вы строго выполняете этап за этапом.
Разработка продукта идет по ступенькам: вы изучаете требования, проектируете продукт, разрабатываете его, тестируете и затем поддерживаете его работу. Новый этап не начинается, пока не завершится предыдущий. Ошибки, допущенные на этапах изучения требований и проектирования, очень сложно исправить — как в финансовом плане, так и в техническом — и это самая большая проблема этой модели.
Водопадная модель хороша при разработке продукта, очень похожего на какой-либо другой: у вас есть модель, и вы просто работаете по образцу. Поскольку стартап — это не всегда разработка абсолютно нового продукта, иногда это создание усовершенствованной версии существующего решения, то каскадная модель может оказаться подходящим вариантом при выборе модели разработки. Главное, не наделать ошибок в расчетах.
Эта модель используется при разработке программ для строительства, медицины, работы с государственными контрактами. Если говорить о непрограммных продуктах, то каскадная модель применяется для строительства крупных объектов.
Емко этот метод описал Чак Кобб, автор книг по проектному менеджменту:
Если бы вы строили мост через реку, было бы смешно сказать: «Мы построим первый пролет, посмотрим, как это выходит, а затем решим, как закончить оставшиеся пролеты!”
Действительно, в таких объектах должен быть заранее утвержденный план, макет, прототип, и изменения, как правило, не предусматриваются.
Каскадную модель применяли: компания Cisco для разработки систем безопасности, IBM, Microsoft IT и даже Toyota.
...
V-Model — улучшенная версия водопадной модели. В отличие от последней V-model предполагает тщательную проверку и тестирование продукта уже на ранних стадиях разработки — оба процесса идут параллельно. При переходе на следующий этап разработки предусмотрен контроль всего, что было сделано до этого. Все найденные ошибки устраняются, и только затем наступает новая фаза работы над продуктом.
Тестирование начинается еще на стадии написания требований, для каждой фазы разработки предусмотрен свой тест-план. Кроме того, уже во время проверки текущего уровня идет разработка стратегии тестирования для следующего. При создании тестов определяются ожидаемые результаты тестирования, указываются критерии входа и выхода для каждого этапа работы над продуктом.
Здесь тоже нужно планирование и четко определенные требования к продукту, кроме того, у вас в команде должны быть тестировщики — без них модель окажется нерабочей.
...
Эта модель разработки дает возможность делать продукт по частям — инкрементам. Каждая часть представляет собой готовый фрагмент итогового продукта, который в идеале не переделывается.
Мы получаем несколько циклов разработки — своеобразный “мультиводопад”. Каждый цикл делится на модули, каждый модуль — на фазы: определение требований, проектирование, написание кода, внедрение, тестирование.
Такая модель позволяет проработать риски и вывести базовую версию продукта на рынок, когда весь запланированный функционал может быть еще в стадии проектирования. Стартапы могут ее использовать, если у них есть общее понимание, каким должен быть их продукт в итоге.
...
Эта модель схожа с инкрементной, однако имеет существенную отличительную особенность — детальную проработку рисков. Спиральная модель применяется для ведения критически важных проектов, где неудача приведет к закрытию компании. Таким образом, стартапы вполне могут ее применять, ведь существование проекта напрямую связано с тем, понравится ли его продукт рынку.
Для разработки продукта по спиральной модели часто проводятся специальные научные исследования и аппробации.
Разработка идет по спиралям, каждая из которых состоит из четырех основных этапов: планирования, анализа рисков, конструирования, оценки результатов.
Спиральная модель довольно затратна в применении, поэтому не подходит для небольших проектов. А вот для средних и больших ее можно применять, особенно, если вы боитесь прогореть.
Эту модель хорошо использовать для работы над продуктом стартапа в том случае, если вы еще не определились с конечными требованиями к нему, но знаете, что в любом случае они достаточно сложные. В там случае, работая итерациями и планируя риски, вы сможете благополучно выпустить свой продукт на рынок и затем постепенно его дорабатывать — опять же, с оглядкой на риски.
Кейс GanttPRO. Приложение для управления проектами и задачами GanttPRO разрабатывалось по принципам спиральной модели, а также фреймворка Agile — Scrum, о котором расскажу чуть ниже. Разработчики выбрали довольно короткие двухнедельные периоды релизов для того, чтобы иметь возможность часто получать отзывы. Также был создан детальный план того, что должно было быть реализовано на первой итерации и как проработать различные риски. Например, перед первой итерацией каждый разработчик высказался по поводу того, что из запланированного может не быть реализовано и почему. Кроме того, команда уделила особое внимание снижению рисков, вызванных необходимостью быстрой адаптации к нуждам пользователей и рынка.
...
Для того, чтобы начать работать с этой моделью, не нужно иметь все требования и спецификации. Продукт создается таким образом, что в первую очередь вы создаете базовый работающий функционал. Затем с каждой итерацией вы совершенствуете его, добавляя новые функции.
Итеративную модель можно сравнить с картиной, когда сначала мы рисуем некий набросок, исходя из которого можно увидеть, что будет изображено. С каждым шагом мы добавляем новые цвета и переходы. В итоге получаем готовую картину. А в случае стартапа — готовый продукт.
Модель подходит для стартапа, который хочет как можно быстрее выйти на рынок и привлечь клиентов.
Кейс “Самокат”. Метафорически итеративную модель можно проиллюстрировать на примере разработки транспортного средства. Результатом первой итерации может стать самокат. Это пример транспорта, хоть и максимально простого. Результатом второй итерации может стать самокат с электродвигателем, третьей — электровелосипед, четвертой — мотоцикл. Таким образом, с каждой итерацией повышаются функциональные возможности продукта, созданного еще во время первой итерации. Сравним разработку этого же транспортного средства по водопадной модели: траспорт мы получим в самом конце, после того, как будут завершены все стадии проекта.
...
Разновидность инкрементной модели. Появилась в конце 80-х годов и стала одной из попыток создания гибкого процесса разработки.
Заказчик привлекается к процессу на самых ранних стадиях — он участвует в разработке и оценке состояния продукта. Обязательное требование этой модели — проект должен легко разбиваться на небольшие части, которые при необходимости могут создаваться параллельно друг другу несколькими командами.
Плюсы такой модели разработки — скорость. Минусы — финансирование.
...
Гибкая модель разработки, по которой сегодня работает большинство ИТ-проектов. Вы получаете определенный результат после каждой итерации, можете вносить изменения в первоначальное видение продукта практически в любой момент работы — исходя из того, какой функционал больше нравится пользователям вашего продукта.
Минусы такой модели — готовый продукт может на рынок так никогда и не выйти, вы постоянно будете заниматься его усовершенствованиями, дополнениями, тем временем бюджет может закончиться. Плюсы — чтобы начать работать над продуктом не нужно иметь детальное представление о том, что вы хотите получить в конце. Не нужно иметь весь бюджет и просчитывать все риски.
Agile имеет множество вариаций и фреймворков. Среди самых известных: Scrum, Kanban, экстремальное программирование (XP), Lean.
...
Является одной из методологий Agile. Метод базируется на концепции бережливого производства, основанной на стремлении к устранению всех потерь — временных, производственных, логистических, качественных.
Особенность Kanban — задачи должны выполняться точно в срок, нагрузка между командой распределяется равномерно.
На практике это выглядит следующим образом. Каждая задача по проекту описывается в отдельной карточке и добавляется на доску — виртуальную или настоящую. Карточка и доска — неотъемлемые элементы Kanban. Все задачи, которые необходимо сделать, собраны в специальной колонке, условно, она может называться “сделать”/ “to do”. Исполнитель выбирает задачу и перемещает в колонку “в процессе” / “in progress”. Когда задача сделана, она попадает в соответствующую колонку “готово” / “done”. На практике колонок может быть гораздо больше, чем три. К примеру, колонки на доске могут выглядеть так: “обсуждается” (backlog), “согласовано” (ready), “кодируется” (coding), “тестируется” (testing), “подтверждается” (approval) и “сделано” (done).
Есть множество инструментов для того, чтобы выстроить работу команды по Kanban. О некоторых из них можно почитать в статье “Инструменты для командной работы над стартапом”.
Кейс “Тойота”. Методология Kanban родилась на производстве в компании Toyota. Мастера участков перечисляли выполняемые работы на бумаге и вывешивали их на видном месте — так и родилась доска канбан, один из элементов методологии. В основе производства Toyota — годовой план производства и сбыта авто, на базе которого составляются месячные и оперативные планы среднесуточного выпуска на каждом участке, основывающиеся на прогнозировании покупательского спроса. Методология базируется на принципе “точно в срок”, что, помимо четкого следования таймингу по каждой задаче, позволяет раскрывать дефекты производства вовремя. Например, ежедневные контроль запасов продукции и деталей выявляет неисправности или простои.
...
Одна их самых популярных методологий Agile. В отличие от канбан, у скрама гораздо больше элементов — различные митинги (от ежедневных пятиминутных, до планирований спринтов, демо), четкое разделение по ролям. Кроме того, разработка подразделяется на спринты — которые длятся от недели до четырех недель и заканчиваются выпуском части продукта.
В переводе с английского scrum — это драка либо схватка вокруг мяча. Термин пришел из регби и означает специфическую игровую ситуацию, в которой участники команд смыкаются в три линии с каждой стороны, когда в игру вводится мяч после нарушения правил; задача игроков — выиграть за счет совместных усилий команды.
Почти так же применяется методология Scrum при разработке ПО: команда кросс-функциональных специалистов совместно реализует проект. Важно, чтобы это были профессионалы с высокой мотивацией, инициативные и готовые вносить изменения как в ход реализации проекта, так и в продукт.
Рассмотрим пример применения Scrum.
1. На этапе формирования продукта вы с командой решаете, кто из вас будет исполнять роль product owner — человека, который отвечает за связь команды с потребителем и инвесторами (если ваши инвесторы будут интересоваться ходом разработки продукта).
2. Product owner формирует список пожеланий к продукту, собирает первичную информацию от возможных пользователей и затем формирует бэклог продукта — список задач, выполнение которых в конце концов приведет вас к выходу на рынок.
3. Ваша команда определяет размер спринта — периода, в конце которого вы должны сделать какой-то рабочий кусок продукта, и выбирает задачи для первого спринта из бэклога.
4. В течение первого спринта вы отслеживаете качественные и количественные характеристики своей работы. Неотъемлемая часть скрама — ежедневные короткие (5–10) минут митинги, в течение которых каждый из участников команды рассказывает, что он планирует сделать за день, делится возникающими сложностями или, наоборот, успехами.
5. Ход выполнения задач отслеживается по скрам-доске, на которой все задачи двигаются от условной позиции “сделать” до “выполнено”.
6. По завершении спринта вы демонстрируете выполненную часть работы и собираете обратную связь — от членов команды, клиентов, в т.ч. потенциальных.
7. Цикл спринтов повторяется до того момента, пока продукт не будет полностью завершен.
...
eXtreme Programming, экстремальное программирование, XP — гибкая методология разработки, которая появилась в конце 90-х годов прошлого столетия. Авторы взяли лучшие, на их взгляд, практики гибкой разработки и усилили их до максимума — отсюда и слово “экстремальный” в названии.
В отличие от канбана, скрама, которые можно применять в самых разных стартапах и бизнесах, да и в организации личных дел, XP применяется исключительно в разработке программных продуктов. В рамках экстремального программирования выделяются четыре процесса: кодирование, тестирование, дизайн, слушание. Если описать эту методологию несколькими словами, то ее характеризуют оперативность, высокое качество, командная работа.
Особенностью XP являются некоторые практики, самая известная из которых — парное программирование. Суть его заключается в том, что два разработчика одновременно работают над кодом для одной функции продукта: сначала один пишет, а второй наблюдает и исправляет ошибки, затем они меняются местами. Таким образом, в процессе создания кода есть два альтернативных решения, на каждом этапе выбирается лучшее. Парное программирование работает по принципу: одна голова — хорошо, а две лучшею
Другая особенность экстремального программирования заключается в том, что сначала готовятся тесты, и только потом — код. При этом тесты пишут сами программисты. Тестирование позволяет исправить большинство ошибок на стадии создания кода.
Третья особенность — коллективное владение кодом: каждый программист в команде имеет доступ к коду продукта и может вносить в него изменения. В том случае, если изменения привели к некорректной работе системы, исправить все должен тот программист, который внес эти изменения.
Экстремальное программирование предполагает также работу в рамках небольших релизов — от одного дня до месяца. При этом чем короче релизы, тем лучше качество продукта.
Наконец, интеграция новых частей в систему происходит так быстро как это возможно. Как только тесты показали, что функция работает корректно, она интегрируется в систему.
...
Как видим, даже если вам кажется, что вы работаете “без заморочек” — без всяких там методологий и прочего — на самом деле даже это прописано в теории:) Скорее всего, вы работаете по модели Code-and-Fix и, возможно, уже совсем скоро столкнетесь со всеми ее недостатками. Чтобы их избежать, важно перед началом работы над продуктом проанализировать его и вместе с командой, решить, по каким фазам будет идти разработка. Оптимальный вариант выбирается, исходя их того, сформировали вы уже конкретные требования к своему продукту или планируете “совершенствовать” его во время работы; какой у вас бюджет и насколько кросс-функциональна команда; насколько длителен проект по времени выполнения и как обстоят дела с финансированием.
Нет идеальной модели и нет идеальной методологии, однако в ваших силах подобрать такую, которая позволит вам максимально эффективно выстроить свою работу и в конце концов вывести продукт на рынок.
Facebook: facebook.com/Startup.Jedi.ru/
Telegram: t.me/Startup_Jedi_RU
Twitter: twitter.com/startup_jedi
Комментарии