Если вы напишете на бумаге свое желание – ничего не изменится. Если вы напишете на бумаге план своего проекта – вы сделаете первый шаг к тому, чтобы все изменилось.

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

Для начала немного теории. Внутри любого проекта находятся две взаимосвязанные категории содержания: продукт (product) и проект (project). Содержание продукта — это общность всех требований к конечному результату нашей деятельности, будь то приложение или услуга. Содержание проекта – это состав проектных работ, которые проводятся внутри стартапа. Иногда в команде есть и product-менеджер, и project-менеджер. В их взаимодействии рождается лучшая версия продукта, потому что за внешним и внутренним развитием следят уже два специалиста, которые способны правильно делегировать задания между разработчиками и дизайнерами, не теряя из виду главную концепцию будущего товара.

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

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

Этап 1. Содержание продукта.

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

Метод тройного ограничения.

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

Если речь идет о стартапе, то временной период инкубации будет от 3 месяцев до полугода, а объем инвестиций в среднем от 500 тысяч до полутора миллионов. Таким образом, ориентируясь на два заданных ограничения – время и инвестиции, команде проекта следует обсудить

- свои технические возможности в реализации продукта,

- какой функционал должен быть представлен в продукте и на каких стадиях,

- какие компетенции потребуются и сколько человек нужно для работы,

- сколько времени в неделю команда готова работать.

Этап 2. Содержание проекта.

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

В уставе проекта команда определяет основные формальные параметры. Кто, когда, на какой должности и сколько сил планирует тратить на проект. Назначьте руководителя, определите цели, содержание по ТЗ и подпишите устав. Этот момент – официальное начало проекта.

Анализ окружения – это скорее ментальное упражнение, в результате которого команда определяет все факторы, которые влияют на проект. Это могут быть не только инвесторы и конкуренты, но и социальная атмосфера, зарубежные аналоги, климатические и финансовые прогнозы в стране релиза, настоящее и будущее. Что касается непосредственных участников, то при анализе окружения команде нужно правдиво оценить кто «в лодке» и поддержит проект, а кто будет против. Мы рекомендуем использовать анализ силового поля Курта Левина.

Обоснование проекта документирует проблемы, к которым адресуется проект, по сути дела, отвечая на классический для стартапа вопрос – зачем выполнять этот проект? Резюме описывает, как именно проект адресуется к описанной проблеме, то есть отвечает на вопрос – какую проблему решает проект? Польза этого описания в том, что именно его мы будем презентовать инвестору и под него привлекать первоначальные средства.

Ключевые компоненты продукта описывает общий бэклог. При его составлении обязательно нужно учитывать всех заинтересованных участников проекта и их интересы. Иначе мы рискуем упустить те задачи, которые нужно решить для получения наилучших результатов, и, соответственно, потеряем и время, и деньги. Фичи (features, или элементы функционала) в бэклоге сортируются по приоритету, оцениваются по трудозатратам и раздаются исполнителям. Бэклог можно составить самостоятельно в любой таблице. Это гибкий инструмент для управления проектами и планирования.

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

Если вместо того, чтобы делать функционал, ваша команда неделями обсуждает цвет нового супер-лэндинга, вспомните этот пункт.

Этап 3. Детализация.

Необходимо определить, какие конкретные работы должны быть выполнены для подтверждения проекта и перехода к следующей стадии стартапа.

Для этого используется метод декомпозиции работ: большие задачи разбиваются на несколько элементарных задач, которые можно выполнить меньше, чем за пару дней. Декомпозиция помогает определить календарный план, а также длительность и количество спринтов. Спринт –это декомпозиция масштабных целей всего проекта.

Если вы захотите сделать поисковик, вы не напишете в бэклоге «сделать поисковик, исполнитель Вася», а начнете с изучения алгоритмов Гугла, написания различных модулей, в конце-концов, с дизайн-концепции. Впоследствии все эти задачи тоже нужно будет декомпозировать.

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

При детальном планировании работ, инвестиции, выделенные на проект, будут затрачены разумно и вовремя, а в случае провала спринта, мы сможем найти ошибку и двигаться дальше, улучшая результаты.

Этап 4. Оценка стоимости.

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

Существует несколько общепринятых методов расчета стоимостных оценок. Мы для оценки стоимости используем метод оценки «по аналогу» и метод «снизу вверх».

Суть метода оценки «по аналогу» заключается в том, что для предсказания стоимости оцениваемого проекта используются фактические данные о стоимости прежде выполненных проектов. Мы располагаем достаточной базой для выполнения такой оценки. Все проекты в чем-то схожи между собой. Если сходство между проектом-аналогом и оцениваемым проектом велико, то результаты оценки могут быть очень точными.

Метод оценки «снизу вверх» нужен для выработки согласованной базовой цены стадии проекта. Точность зависит от уровня детализации при оценке затрат на нижних уровнях рассмотрения. Недостатком же этого метода является то, что вам придется потратить время на точную декомпозицию и оценку стоимости трудозатрат команды. Для использования метода «снизу вверх» в гибких системах управления проектами нужно иметь сноровку, а желательно и инструмент контроля «работочасов» сотрудников.

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

Пока проекты небольшие, над планированием не хочется и думать. Вас ведет вдохновение, какие формальности? Обычно так и происходит с первыми стартапами. Но не стоит превращать это в привычку.

Стартаперам иногда выпадает шанс реализовать возможности, которые они даже не способны оценить. Команда неверно оценивает объёмы работ или соглашается на условия, которые разом вгоняют бизнес в неволю и убытки, откуда они уже не выберутся. Учитесь планировать свою работу и отслеживать точность прогнозов трудозатрат с самых первых проектов. Тогда, когда вам посчастливится отыскать инвестора и привлечь его, вы будете готовы планировать свое будущее правильно. Ну, а если что – вы знаете, где нас найти.

Салтыков Алексей, директор бизнес-инкубатора Инкубис