Когда за одну ночь в службу поддержки стали поступать сотни заявок, мы поняли, что подошли к критической точке. Инженеры запустили новую функцию без ведома службы поддержки, и всю оставшуюся ночь мы судорожно пытались ответить на вопросы клиентов.
Но дело было не только в этом. В течение нескольких недель, предшествовавших этому запуску, отдел маркетинга продукта каждую неделю заставлял дюжину инженеров заполнять примечания к релизу. Разные команды проводили свои собственные совещания по статусу, чтобы следить за одним и тем же запуском. В общем, мы теряли много времени, пытаясь наладить коммуникацию.
Компания Ноушен росла — у нас было пять инженерных групп, и несколько проектов шли параллельно. Но мало кто мог понять, что и почему отгружается. Если мы не найдем лучшего способа координации между командами, мы не сможем масштабировать наш бизнес.
Каждый стартап сталкивается с такими «болями роста». Я видел, как такая же ситуация происходила в продуктовых командах Twitter, Oculus, Robinhood, а теперь и Ноушен (мы тоже не застрахованы!). Поэтому я решил поделиться с вами тем, как мы разработали решение для нашей собственной команды.
В этом материале мы расскажем о системах и процессах, которые мы внедрили для того, чтобы все члены команды были в курсе нашей инженерной и продуктовой работы. Мы также включили шаблоны, чтобы вы могли сразу же применить лучшие элементы в своей команде.
Дублирование шаблона нашей системы управления продуктами →
Стандартизация лучших методов работы
Когда я пришел в компанию Ноушен, одним из первых моих занятий было общение с инженерами и дизайнерами на тему того, как они обычно создают и поставляют продукты. Некоторые команды использовали формальные системы заданий и спринтов, в то время как другие хранили обновления в одном большом совместном документе.
Я уже сталкивался с подобным: По мере роста компании разные команды вырабатывают разные привычки, что затрудняет координацию работы. Это нормально! Команды должны работать так, как им удобно, особенно в условиях удаленной работы. Но нам необходимо было стандартизировать способы информирования о работе наших команд.
Но как понять, что именно нужно стандартизировать, если каждый делает это по-своему? Выясните, что все используют в основном одинаково, и стандартизируйте это.
В компании Ноушен наши инженерные, продуктовые и дизайнерские группы в основном были сосредоточены вокруг трех концепций: команды, проекты и задачи (определения каждой из них вы найдете ниже). Мы потратили время на определение каждого компонента, а затем кодифицировали их в общекорпоративном документе, чтобы все создавали проекты одинаково.
Важно также договориться о том, что не следует стандартизировать. Например, мы не диктуем командам, как проводить совещания или какие инструменты для макетирования использовать. Определите несколько основных правил, а затем позвольте людям работать свободно.
Построить систему управления продуктом, подходящую для каждой команды
Выявление и стандартизация этих компонентов помогли нам организовать всю нашу работу в рамках каждого продукта и инженерной команды. Но затем нам нужно было последовательно доносить информацию об этой работе до остальных сотрудников компании на понятном им языке.
Чтобы сделать это эффективно, мы построили систему коммуникаций, состоящую из четырех частей:
- Команды — группа людей, содержащая проекты.
- Проекты — дискретный, независимо отгружаемый набор работ, который можно разбить на задачи.
- Задачи — рабочие элементы, назначенные отдельному лицу.
- Обновления — краткая, доступная для чтения информация о каждом проекте, представляемая каждые 2 недели.
Некоторые части помогают инженерным командам координировать работу друг с другом, а некоторые, например, обновления, говорят с остальной частью компании. Каждая из этих частей представляет собой базу данных Ноушен, и все они связаны между собой, создавая систему. Мы считаем, что эта система состоит из четырех слоев, каждый из которых обеспечивает различный уровень контекста для разных команд.
Ваша система, скорее всего, будет выглядеть по-другому — она может жить в электронных таблицах или папке с документами. Возможно, вы организуете свою работу по спринтам или этапам. Но если вам нужна отправная точка, мы привели ниже в качестве шаблона именно нашу систему.
Дублирование шаблона нашей системы управления продуктами →
Давайте рассмотрим каждую часть системы, как мы ее структурировали и для какой аудитории она предназначена.
Команды
Четкое определение владельцев способствует организованности проектов. Но составить точный список команд сложнее, чем кажется. То, как вы создаете программное обеспечение, не похоже на оргсхему. Вы ищете виртуальные группы, в которых люди реально работают над созданием продукта. Это может включать в себя множество функций, которые вы обычно не считаете одной и той же «командой», например, инженера, дизайнера, маркетолога, юриста и, вероятно, некоторых других.
Хорошим способом поиска таких команд является просмотр каналов Slack, которые люди создают для координации работы над проектом. В этих каналах обычно можно найти неофициальные команды, которые функционируют в настоящее время.
После того как вы нашли эти команды, вы можете создать простой или сложный реестр по своему усмотрению. В нашем реестре мы указываем название команды, ее состав, краткое описание деятельности, а также несколько других полезных сведений, таких как Slack-канал и устав команды.
Дублируем шаблон реестра команд →
Проекты
После того как вы определились с командами, можно определить проекты для каждой из них. Для нас проекты — это «вещи», которые могут быть отправлены, и чаще всего это те вещи, которые больше всего волнуют людей в компании.
Сюда же относятся такие команды, как отдел продаж, юридический отдел и другие инженерные подгруппы — они могут не участвовать в активном создании проекта, но часто хотят понимать ход его реализации, чтобы работать лучше. И всем им нужен одинаковый уровень контекста:
- Что решает проект
- Каков статус
- Когда будет отгрузка
- Где можно глубже изучить дизайн и решения
Наша база данных «Проекты» оптимизирована для ответов на эти вопросы: она содержит название проекта, его краткое описание, статус, дату запуска и указатели на более подробную документацию по проекту. Мы представляем их в виде таблицы, чтобы любой желающий мог просмотреть список активных проектов и сразу же получить ответы на интересующие его вопросы.
Название проекта — не более 75 символов, с понятным для других описательным названием. Не должно быть никаких уточнений, например, «H1 2022». Хороший пример — «Team gallery v3». Плохой пример — «Углубление работы над небольшими проектами продуктов p0».
Описание — Конкретное краткое изложение в виде твита того, что должен сделать проект. Хороший пример: «Создать дополнительные наборы данных в почтовых инструментах для автоматического формирования почтовых аудиторий». Плохой пример — «Захват любых дополнительных элементов, необходимых для надежной работы мобильного приложения».
Команда — Мы берем эти данные из базы данных команд.
Статус — Чтобы убедиться, что все используют единый набор тегов, мы определили набор стадий, которые мы все используем в Ноушен, например «Backlog», «Scoping», «In beta», и что каждая из них означает.
Обновления на этой неделе — краткое, основанное на фактах резюме того, что было сделано и что будет дальше в этом проекте. Включите все, что поможет команде быстрее продвигаться вперед на следующей неделе. Хорошим примером может быть «Решены последние задачи в спринте; продукт отправляется на разработку в понедельник». Плохой пример: «Продолжаем продвигаться в создании боковой панели».
Предполагаемая дата поставки — конкретная дата, которая является нашей наилучшей текущей оценкой того, когда данный проект будет запущен для первых внешних клиентов. Эта дата помогает таким командам, как маркетинговая и юридическая, понять, когда им необходимо начать работу над планом выхода на рынок.
Дата внешнего запуска — конкретная дата, которая является нашей наилучшей текущей оценкой того, когда данный проект будет доступен всем желающим клиентам. Мы отличаем эту дату от предполагаемой даты поставки, поскольку она определяется совместно с маркетингом для обеспечения плавного внедрения.
Указатели на остальную часть работы — Здесь мы возвращаемся к нашей рекомендации предоставлять людям как можно больше свободы после того, как вы установили основные правила. Поскольку мы используем Ноушен для создания проектной документации и можем встраивать в эти страницы файлы Figma и репозитории Github, для нас это немного проще. Но если ваш инструмент не может этого сделать, просто включите ссылки.
Дублирование шаблона трекера наших проектов →
Задачи
После того как проекты определены, инженеры, дизайнеры и менеджеры по продуктам могут разбить их на управляемые задачи. Они должны представлять собой повседневную работу проектной группы и быть достаточно конкретными и подробными для людей, выполняющих эту работу. Если пытаться сделать задачи понятными для всех, они станут расплывчатыми и бесполезными.
Чтобы сделать задачи понятными для исполнителей, мы используем специальные свойства для отслеживания приоритета, статуса QA, назначенного инженера, связанного проекта и всего остального, что необходимо инженерам для выполнения работы.
Дублирование шаблона базы данных наших задач →
Еженедельные обновления
Последний слой предназначен для тех, кто не знает, какие проекты их интересуют. Если множество задач составляют проект, то множество проектов составляют обновление. Люди не будут просматривать список из пятидесяти проектов. Они хотят, чтобы им показали, на что следует обратить внимание.
Поскольку еженедельные обновления предназначены для всей организации, я сам пишу их на простом, доступном для чтения английском языке. Я беру содержание из отдельных обновлений продукта, которые пишет каждая инженерная команда, а затем пишу их на страницах Ноушен, чтобы было легко находить и искать старые обновления. Но их можно оформить и в виде электронных писем или документов.
В настоящее время я распределяю еженедельные обновления по трем группам:
- Что отгружено — Просто список всего, что было отгружено внешним клиентам на этой неделе.
- Анонсы — Информация о прогрессе, хорошем или плохом. Сюда можно поместить, например, новый PRD или значительные задержки в проекте.
- FYIs — информация о последних проектах или общих изменениях в продуктовом и инженерном подразделении.
Но следует ожидать, что эта структура будет меняться по мере изменения приоритетов вашей компании. В настоящий момент в компании Ноушен мы заинтересованы в том, чтобы все команды были в курсе этих планов. Если ваша команда объединяется вокруг трех больших камней, то обновление может быть посвящено тому, как продвигается работа над ними.
Дублирование шаблона еженедельного обновления продукта →
Успешной является самоподдерживающаяся система
Все, что мы только что сказали? Все это теряет смысл, если никто не пользуется вашей системой. Чтобы обеспечить успех нашей системы, нам нужно было показать людям ее ценность.
Наша цель заключалась в том, чтобы все были на одной волне и при этом требовали как можно меньше дополнительной работы. Это непростой баланс. Для этого мы нашли как можно больше способов связать части системы друг с другом. Таким образом, добавление информации в одну часть делает другие части более ценными, стимулируя людей продолжать вносить свой вклад в общую систему.
Например, я встраиваю трекер проекта в нижнюю часть каждого еженедельного обновления. Любой, кто хочет узнать больше о конкретном проекте, знает, куда идти, чтобы получить более подробную информацию. Тем самым я стимулирую команду инженеров поддерживать список проектов в актуальном состоянии.
Отдельные инженерные команды также встраивают фильтрованное представление базы данных задач в каждый проектный документ, где видны только связанные задачи. Любой, кто открывает страницу проекта, может сразу увидеть, как разбита работа и насколько она продвинулась.
Связь с системами других отделов также повышает ценность. Возьмем, к примеру, отдел маркетинга продуктов — для составления календаря запуска они обращаются к внешним датам запуска в трекере проектов.
Для создания продукта нужна деревня
К концу этого процесса мы создали систему, позволяющую отслеживать всю нашу работу над продуктами и инженерными решениями в одном месте и доводить ее до сведения остальных сотрудников компании с минимальными затратами. Мы надеемся, что эта система будет полезна для вашей команды.
Но в стартапах все быстро меняется! По мере нашего роста будет меняться и используемая нами система. Ваша система тоже будет меняться.
Поэтому по мере развития ваших систем мы пришли к выводу, что важнее всего понять, что нужно знать различным командам. Чтобы создать продукт, нужна вся компания. И именно благодаря тому, что мы учитываем потребности каждого, нам удается сохранять прозрачность в процессе масштабирования.