В предыдущей статье мы рассказали историю нашего стартапа, рассмотрев три ключевых составляющих: “Идею”, “Реализацию” и “Продажи”. Из-за большого объема статьи вопрос реализации формально описать не хватило места. Исправлять это будем в данной публикации.

Управление командой начинается с планирования и проектирования. Существуют десятки, если не сотни, методологий управления проектами: от “Разработки по ReadMe” до громоздкого, зато на все случаи жизни PMBOK. Как программисты, бывает, изобретают велосипеды, так и проект-менеджеры могут этим грешить. Если с методологией мы могли позволить себе некоторые вольности, то инструмент подбирался уже без “велосипедостроения”…

Что такое “pivot” стартапа

Pivot (от англ. — вертеться, поворачиваться вокруг своей оси) в контексте стартапа — это отказ от текущей бизнес-модели, программного продукта и перезапуск всех работ по новой концепции. Объяснение, почему так происходит, почему так произошло у нас, выходит за рамки статьи. Поясню лишь то, что в нашем случае обозначал “pivot”:

• ограниченные ресурсы — 4 человека на все работы;
• жестко определенные сроки — 30 календарных дней;
• необходимость выполнить поставленную задачу: “получить первый доход с продукта”.

Подробнее об исходной точке

• Проект начинается не с “0” — программный продукт-предок был версии 2.3, имел хорошую архитектуру после рефакторинга, с отловленными и исправленными багами;
• Задача по разработке: из продукта-предка v2.3 сделать продукт-потомок v0.1 alpha-1. Основные изменения касаются переработки архитектуры под многопроектность, добавления новых типов конечных документов, удаления ненужных функций, редизайна в соответствии со вкусами новой ЦА, создания “демо-режима” работы;
• Финансово-маркетинговая задача: в кратчайшие сроки выпустить продукт и привлечь к нему аудиторию, проанализировав реакцию на него. По анализу составить план дальнейшего развития. С полученных дополнительных финансов ускорить разработку нового функционала;
• Проектирование началось с создания маркетингового концепт-документа, в котором были сформулированы основные идеи и тезисы: какие работы нужно провести, чтобы реализовать поставленные задачи;
• Состав команды и обязанности, которые они выполняют:
  “Программист” — фронтендбэкенд разработка, системное администрирование;
  “Тестер” — тестирование ПО, написание баг-репортов, SMM- и контент- менеджмент, анализ и обработка фидбэка;
  “Дизайнер” — разработка внешнего вида и механики GUI, создание и подготовка медиа-контента;
  “Проект менеджер” — аналитика, проектирование, планирование, управление (проектное, маркетинговое, финансовое и т.д.), разработка технической документации, текстового контента, SEO.
• Ограничение-требование от наших менторов-инвесторов: за 30 дней переделать продукт, подготовить материалы и работы по продвижению.

Инструменты управления проектами

У нашей команды есть опыт работы с тремя “связками” инструментов по управлению проектами:

“Связка первая”
Google Docs — электронный документооборот и облачный редактор документов;
Мегаплан — трекинг задач, не связанных с разработкой кода;
Readmine + GIT — баги и задачи, связанные с разработкой кода + контроль версий;
Kayako — сервис для сбора фидбэка, баг-репортинга;

Такая связка хороша, когда в разработке несколько проектов, несколько заказчиков и т.д. (Readmine), много сотрудников и задач, не связанных с работой над кодом (Мегаплан), много пользователей, а соответственно много: саппорта, фидбэка, баг-репортов (Kayako).

“Связка вторая”
Google Docs — электронный документооборот и облачный редактор документов;
Мегаплан — трекинг задач, не связанных с разработкой кода + CRM-система;
BitBucket вместо Readmine + GIT;
Яндекс.Почта для домена — для сбора фидбэка, баг-репортинга.

“Вторая связка” подходит, когда проект один, и он относительно простой (BitBucket); при этом работы, не связанной с кодом (Мегаплан), много, а фидбэка-саппорта пока мало, так что хватает настроенного веб-интерфейса от почты (Yandex.pdd).

“Связка третья”
Google Docs — как облачный редактор;
TrackStudio + GIT — трекер задач, как по коду, так и прочих + электронный документооборот;
Яндекс.Почта для домена — для сбора фидбэка, баг-репортинга.

Эта связка — самая правильная, она позволяет в одной системе вести работу над задачами как по коду, так и по всему остальному. К сожалению, основной инструмент в этой связке требует много ресурсов на настройку-допиливание (TrackStudio); по фидбэку-сапорту, как и во “второй связке”, хватает Yandex.pdd,

Эти связки были подобраны под разные условия работы. Google Docs используется всегда: мы просто его любим — это приятный, быстрый и удобный облачный редактор документов.

Под наши условия: один проект, работать надо как над кодом, так и над продвижением, пользователей пока вообще нет, много саппорта-фидбэка не предвидится, предполагали выбор второй или третьей “связки”. “Третья связка” (основанная на TrackStudio) после коротких размышлений отпала — не было ни времени, ни ресурсов, чтобы настроить-довести этот инструмент под новый проект. Решили использовать “Вторую связку” с инструментами, которые работали из коробки (BitBucket, Мегаплан).

Вариант попробовать что-то новое не рассматривался по той же причине, по какой отказались от использования “Третьей связки”. Не было времени на эксперименты, нужно было начинать работать. Учитывая отсутствие возможности попробовать новое, положились на опыт проект-менеджера по общению с парой десятков прочих систем управления проектами (СУП) как специализированных для разработки ПО, так и широкой области применения: от Teamer’а до BugZill’ы.

Планирование

Почему мы начали с выбора инструментов, а не с планирования?

Потому что “вторая связка” состоит из двух негибких сервисов: BitBacket’а и Мегаплана. Они не имеют возможности настраивать их под любые процессы, поэтому приходится выстраивать методологию управления проектом в терминах и ограничениях этих инструментов. Выбрав инструменты, и зная их ограничения, можно приступать к следующему этапу — планированию.

Кому-то покажется, что ситуация, когда инструмент диктует методологию, а не на оборот — очень плохо. По нашему мнению, если ограничения пагубно не влияют на производительность (например, излишней бюрократией), то можно с ними смириться.

Общие задачи ставятся в Мегаплане, будем использовать его терминологию. Отправная точка в иерархии таск-менеджера Мегаплана — “Вехи”. Веха — срез проекта на определенном сроке, её еще можно описать, как набор целей, которые нужно достичь к конкретному времени. Планирование сводится к созданию вех. Рассмотрим их на примере нашей ситуации (переделываем один проект в другой, подготавливаем его продвижение, на всё 30 дней, с 5 сентября по 5 октября).

Веха #1. “Подготовительный этап”, закончено к 10 сентября:
— Выбраны и настроены инструменты, локальные сервера;
— Спланирован ход работ;
— Поставлены и распределены задачи;
— Составлены ТЗ по всем задачам.

Веха #2. “Базовые работы”, закончено к 15 сентября:
— Произведен рефакторинг кода проекта (ускорит реализацию будущих задач);
— Подготовлены серверы и учетные записи, домены для продакшна;
— Разработан и собран ключевой контент для продвижения (по правилу «Бритвы Оккама»: 20% “ключевого” контента дадут 80% трафика);

Веха #3. “Первый наглядный результат”, закончено к 20 сентября:
— Рефакторинг редактора (перенесен в iframe, что позволит быстро реализовать “демо-режим”);
— Произведен редизайн GUI;
— “Запущены” блог проекта, сообщества в социальных сетях.

Веха #4. “Первый публичный результат”, закончено к 25 сентября:
— Добавлена форма приема платежей;
— Реализован демо-режим;
— На демо-режиме запущен промо-сайт с 90-100% запланированного контента;
— Версия 0.0.11 задеплойдена в продакшн;
— Сообщества в соц. сетях и блог на сайте наполнены первыми постами.

Веха #5. “Подготовлено продвижение проекта”, закончено к 30 сентября:
— Заведен блог на Хабрахабре;
— Реализованы мелкие фичи и доработки;
— Пройдена модерация и подключена система биллинга;
— Версия 0.0.17 задеплойдена в продакшн;
— Согласно плану публикаций продолжается постинг в соц. сети и в блог на сайте.

Финальная Веха #6. “Первое продвижение проекта”, закончено к 10 октября:
— Реализован весь задуманный на альфа-версию функционал;
— Релиз версии R0.1 Alpha-1 задеплойден в продакшн;
— Первая статья опубликована в блоге на Хабрахабре;

Запланированные Вехи #7-Х. “Создание комьюнити проекта”, закончено к 30 октября:
— Опубликованы 3-5 статей в блог на Хабрахабре;
— Подготавливаются и публикуются посты в блог на сайте, в сообщества соц. сетей;
— Идет сбор и анализ фидбэка, общая переписка с заинтересовавшимися в проекте пользователями;
— Планируются и проводятся работы по прочему продвижению согласно маркетинговому концепту;
— Производятся хот-фиксы;
— Анализируются суммы собранных средств, соотносятся с возможностями по дальнейшему развитию проектов.

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

Напомню: первые Вехи планировались, опираясь на “маркетинговый концепт”. Наша команда состоит из 4-х человек, несколько лет работающих вместе над разными проектами. Схожие с теми, что поставлены в Вехах для Alpha-версии Ahoba (; задачи, мы уже реализовывали в других проектах. Поэтому, составляя Вехи, проект-менеджер уже представлял кто и как будет решать поставленные задачи. Этот процесс происходил неформально, опираясь на прошлый опыт, эмпирическую оценку и аналитическое прогнозирование.

Можно написать книгу о этих неформальных мыслительных процессах, о истории их возникновения, проб вариантов, обучение на ошибках и т.д. Получится этакий “PMBOK Lite for Brain”. Однако, на данный момент нет не то что книги, но и оформленной на бумаге концепции: все на 70% — в голове ПМ’а, и лишь оставшиеся 30% — в его личных шпаргалках-тезисах. Возможно когда-нибудь и из этих наработок получится, пускай и не книга, но достойная статья для Хабрахабра точно. Сейчас же мы просто отметим, что было сделано, не вдаваясь в вопрос “Как?”.

Проработка структуры проекта

Итак, имеем Вехи, есть команда из 4-х человек, которая будет их реализовывать. Можно было бы сразу перейти к следующему этапу — постановка формальных задач — но для упрощения последующего контроля над исполнением стоит использовать ещё один инструмент — иерархическую структуру проекта.

Иерархия нужна, чтобы скомпоновать/сгруппировать задачи. Задачи имеют две основные отличительные характеристики: функциональное содержание и исполнителя. Проектировать иерархию задач можно либо по их функциональному группированию, либо с привязкой к конкретному исполнителю. Это формальные подходы. Они упрощают менеджмент, делают его более прозрачным, но вносят множество излишней бюрократии, что, в свою очередь, уменьшает общую производительность. Во многих ситуациях можно пожертвовать производительностью в угоду менеджменту, и это оправдано, т.к. дает свои плоды в виде предсказуемости и высокого качества. Нам же был нужен результат как можно скорее, поэтому можно было отойти от формальной структуры, чтобы упростить и ускорить проведение работ. Тем не менее, в любой другой ситуации я был бы против подобной структуры.

Таким образом, наши задачи сгруппированы где-то с привязкой к исполнителю, где-то с привязкой к функциональному содержанию:

0. Проектирование
1. Разработка проекта
2. Продвижение проекта
2.1. Сайт и блог Ahoba (;
2.2. Продвижение в соц. сетях
2.3. Продвижение на Хабрахабре
3. Разработка дизайна и медиа-контента

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

Постановка задач

При работе над составлением и постановкой формальных задач всплывают все недостатки выбранной связки инструментов…

Общий принцип-последовательность, через который проходит большинство задач в наших проектах, можно описать так:

Краткая концепция задачи → Разработка подробного ТЗ → Создание тестовогодемо контента → Создание макетов GUI по ТЗ → Постановка формальной задачи на реализацию в таск-трекер (ТЗ + Макет) → Реализация → Тестирование → Багфикс (если нужно) → Закрытие задачи.

Над задачей на разных этапах работают разные люди с разными ролями: ПМ разрабатывает концепцию задачи; бизнес-аналитик, технический писатель составляют ТЗ; дизайнер рисует макет; ПМ передает ТЗ и Макет программисту; программист реализует задачу, передает её на тестирование; тестер проверяет реализацию и, если всё в порядке, соответствует ТЗ и Макету, то уже как QA-специалист закрывает задачу.

И это самый простой вариант… Бывают ситуации, когда нельзя определить, как именно реализовать задачу. Тогда программист может подключаться к задаче уже на этапе проектирования (например: могут быть реализованы несколько прототипов интерфейсов, чтобы юзабилити-эксперт оценил каждый вариант и внес конечный в цепочку реализации).

В итоге имеем около 5-ти типовых моделей жизненных циклов задач и еще пару десятков “атипичных”.

Гибкие инструменты для трекинга задач, такие, как TrackStudio, хороши тем, что позволяют формально настроить менеджмент по любой модели жизненного цикла задачи. Это и их достоинство, и их недостаток. Как уже говорилось выше, когда нет ресурсов на первоначальную настройку, использовать эту систему не получится. Взяв коробочные Мегаплан и BitBucket, мы понимали, что формально настроить их для наших жизненных циклов реализации задач не выйдет. Поэтому, дальнейший рассказ а-ля “много-много костылей” о неформальном использование этих сервисов.

Как в связке “Мегаплан + BitBucket” реализовать нашу модель жизненного цикла задачи? Во-первых, конкретные фичи, связанные с кодом (п.1. “Разработка” из иерархической структуры, определенной ранее), заносятся в BitBucket, а задачи по подготовке материалов для реализации фич (ТЗ + Макет + ТестовыеДемо данные) — в трекер Мегаплана.

Алгоритм примерно такой:
Ставим в Мегаплан задачу для бизнес-аналитика: “Разработать ТЗ” — со ссылкой-примечанием “Готовое ТЗ выложить в задачу Х для дизайнера”. Дизайнеру, также в Мегаплан, ставим задачу “Разработать Макет по ТЗ” с теми же ссылками-примечаниями: “Позже ТЗ в задачу выложит бизнес-аналитик, готовый Макет выложить в задачу Y в BitBucket”. Программист и тестер работают только в BitBucket’e, оперируя сменой статусов у задач.

В интерфейсе этих СУП’ов объединения этапов работы над задачами нет. При неумелом проект-менеджменте это может привести к негативным последствиям. Из личного опыта: если вручную не согласовывать распределение работ (а автоматизировано инструменты этого не делают), может возникнуть ситуация, когда, например, программист простаивает неделями в ожидании формальных описаний для фич. Такое я наблюдал на прошлом месте работы. В итоге ведущий разработчик уволился, аргументируя своё увольнение монологом в духе: “Мне скучно, так как нет работы, а я код писать хочу”. Это показательный пример того, как неподходящие инструменты или их неформальное использование, могут деморализовать членов команды. Всем, решившим, как и мы, использовать “Вторую связку”, нужно понимать и учитывать эти риски при работе в таких системах управления проектами.

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

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

Таблица: “Работы по реализации и продвижению проекта Ahoba (; ver. Alpha-1”

И т.д., всего около 50 задач.

По целям из Вех получилось сформулировать конкретные задачи. Некоторые цели описаны одной задачей, другие разделены на несколько. Сроки из Вех позволили расставить дедлайны, ориентируясь на логическую последовательность выполнения работ. По заранее установленным проектным ролям, были назначены исполнители, ответственные за те или иные задачи. Сами задачи, естественно, не состоят из одних лишь заголовков, указанных в таблице. Большинство из них были дополнены описаниями, пояснениями, ссылками на проектную документацию в Google Docs, чек-листами с этапами или алгоритмами выполнения…

Отдельно стоит отметить распараллеливание на раннем этапе. Пока ПМ прорабатывает задачи, команде нечем заняться. Чтобы избежать простоя, работа ПМ’а начинается с постановки задач, не требующих детального ТЗ или аналитики: Программист начинает с удаления ненужного функционала; Дизайнер рисует лого проекта; SMM-менеджер подбирает контент для постов по тематике, определенной еще в концепте. Все при деле, а проект-менеджер спокойно работает над полусотней задач, распланировав деятельность команды на следующие 30 дней.

На этом проект-менеджмент заканчивается, и лишь изредка приходится возвращаться к нему: отслеживать статусы задач, корректировать дедлайны и Вехи, если нужно.

Формальные правила постановки и выполнения задач

Задачи сформулированы и поставлены, сроки и исполнители определены, но, чтобы достичь поставленных целей без сучка и задоринки, необходимо соблюдать ряд формальных правил:

• Любая идея, предложение, пожелание и т.д. проходят через ПМ’а, т.к. он отвечает за общую работу и жизненные циклы отдельных задач, определяя и внося всё новое согласно текущей ситуации;
• Все задачи фиксируются в системах управления проектом. Связанные с кодом — в BitBecket’е, все прочие — в Мегаплане;
• Для каждой задачи должен быть назначен ответственный и определен дедлайн;
• Задача должна иметь полное, формальное, однозначное описание. Если исполнитель не уверен в смысле задачи, он обязан перед её выполнением уточнить его у постановщика задачи. Постановщик, если необходимо, дополняет описание;
• Порядок выполнения задач — согласно их дедлайнам. Если задачи имеют одинаковый дедлайн, исполнитель сам выбирает, в какой последовательности их реализовывать;
• Статусы при работе над задачами (выставляются автоматически и вручную) и реакция на них в Мегаплане:
  1. “Новая задача” — необходимо ознакомится с сутью и условиями задачи, согласовать порядок выполнения прочих своих задач и новой.
  2. “Принята к исполнению” — ответственный за задачу знает о ней, если свободен, работает над её реализацией.
  3. “Условно завершена” — статус устанавливается вручную, после того, как исполнитель закончил работу над задачей, выполнил все условия описанные в ней. (Например, по условию: выложил готовый Макет в связанную задачу по разработке GUI).
  4. “Завершена” — устанавливается вручную, после того как поставщик задачи проверил качество её исполнения;

• Статусы при работе над задачами, служебная информация в заголовках (задаются только вручную) и реакция на них при работе в BitBucket’e:
  1. Задаче должен быть указан тип. Тип “task” — задается для задач, связанных с добавлением нового или изменением текущего функционала; тип “bug” — для задач по исправлению ошибок, недочетов.
  2. Т.к. в BitBucket’е нет сущности “версия” или “релиз”, для каждой задачи, в начале её заголовка добавляется служебная информация типа “RX”, где “R” — метка обозначающая релиз, а “X” — номер релиза. Пример метки — “R0.1”. Перенос задач из релиза в релиз осуществляется изменением служебной метки в заголовке задачи.
  3. Задача добавляется без статуса, если в ней отсутствуют какие-то данные (например, макет нового GUI), при этом в описании должно быть примечание (например: “Позже дизайнер выложит макет, подробности в задаче — ссылка_на_задачу_по_разработке_макета”).
  4. Задаче ставится статус “new”, что означает, что все описания по ней готовы, и программист может приступать к работе над ней;
  5. Задаче ставится статус “resolved”, когда программист заканчивает работу над задачей и деплойдит изменения на тестовый сервер. Данный статус означает, что тестер может приступить к тестированию задачи.
  6. Если в выполненной задаче найдены ошибки, и их можно исправить в рамках текущей задачи, тестер ставит статус “invalid”. Это означает, что программисту необходимо исправить найденные недочеты. После правки программист опять ставит статус “resolved”.
  7. После того как текущая задача реализована без ошибок, или ошибки вынесены в отдельную задачу с типом “bug”, задаче присваивается статус “closed”.
  8. Каждой задаче автоматически присваивается уникальный ID. Он необходим для двух вещей: а) для привязки коммитов в git-репозиторий к определенной задаче; б) для получения номера версии текущего релиза.

На этих правилах, инструментах и методологии было реализовано управление проектом при создании и продвижении стартапа Ahoba (; на этапе “Alpha-1”. Цели и условия, которые у нас были, диктовали именно их.

Кирилл,
руководитель проекта Ahoba (;
Временно с аккаунта нашего программиста Антона (skrutty)

Автор:

Источник