Thread by @ppravdin

Тред про процессы в распределённой компании
25 человек, 12 команд, 5 стран, 10 городов
Создаём @welltory - это разработка, data science, контент, devops, маркетинг, саппорт.
Работаем по единому адаптивному agile, процессы не меняются год, команда не просит изменений, все довольны

В компании нет менеджеров или скрам мастеров, только тим лиды, CTO, CPO и CEO.
Все "менеджерские" функции по шевелению задач автоматизированы.
Обо всех инструментах расскажу ниже, стек используемых технологий stackshare.io/welltory

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

[1] Утренние стендапы
Вне единого офиса команде нужна синхронизация.
За 15 минут до звонка в слаке бот @standuply задаёт вопросы команде, затем ремайндер поднимает ссылку комнату в @zoom_us. Короткий звонок с лимитом 1-2 минуты на человека, проблемы озвучиваются и решаются после

[1.1] Практика полезна. Составленный план на день повышает шанс сделаешь то, что надо. Все всегда примерно в курсе, кто-что делает, какой прогресс, где-что могли сломать и к кому по какому вопросу обращаться. Потраченное время "15 минут*людей на звонке" будет меньше, чем польза.

[1.2] Практика работает, если в ней участвуют все и прежде всего фаундеры. Да, тестировщик рассказывает, что верифицировал, девелопер про свою задачу, а фаундер про привлечение инвестиций. Все равны, это улучшает эмпатический климат и формирует результатоориентированную культуру

[2] Недельные спринты

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

[2.1] Короткие спринты это не прихоть и блажь, 2 и более недели сразу снижают результативность и увеличивают шанс ухода в дебри там, где не требуется. Сначала недельные это очень трудно, вся работа на виду, кажется, что на работу времени очень мало.

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

[2.3] На каждый спринт в @asana автоматически создаётся отдельная Kanban style доска как на скрине. Колонки по классике: Todo, Bugs, Doing, Ready for test, Done, Not Done.
Команда сфокусировано работает только с одной доской и не вовлекается в другие проекты таск трекера.

[2.4] По завершению спринта задачи могут быть только в Done или Not Done, к демо-планированию доску приводят в актуальный вид. Всё что в Not Done либо переносится в следующий, либо возвращается в бэклог команды. В карточке-задаче всегда видно, сколько спринтов её пинают.

[2.5] Мы написали микросервис под API @asana, чтобы: создавать новые доски командам, уведомлять в слаке QA о попадании карточки в Ready for test и разработку о появлении задач в Bugs, архивировать доски завершённых спринтов, уносить не сделанное в бэклог, формировать ченджлог.

[2.6] Повторюсь, у членов команды нет никаких других задач, кроме тех, что на доске его команды. Любой точно знает, что если задачи нет на доске, то задачу можно не делать. Никаких My Tasks, всё что назначено на человека вне доски не считается.

[2.7] В течении спринта новые задачи ставятся на доску следующего. Это простое правило позволяет всем, кто хочет, чтобы команда поскорее сделала его задачу, заводит карточку на доске следующего спринта. Если задача не срочная - в бэклог команды.

[2.8] В слаке в канале команды всегда есть ремайндеры: "кодфриз" - работа над задачами спринта останавливается, переключаемся на обработку обратной связи, так же о новых сборках, о найденных дефектах.

[2.9] Когда вокруг много аджайлизма (Греф, привет!), мы без боли внедрили единый процесс в т.ч. для не технических команд. Так же работают и маркетологи, и контентщики, и дизайн, и саппорт, и учёные науку прорабатывают.

[3] Демо-планирование

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

[3.1] В слаке в канале #demo_planning с помощью аппы google calendar постятся специальные ссылки на комнату в @zoom_us, члены команды уведомляются и заходят на встречу. Календарь вместо ремайндера удобен тем, что удобно менять время\ссылку\состав уведомлений.

[3.2] Демонстрация - это шэринг экрана с доской и рассказ про свои задачи. Всё что можно показать, любой артефакт, лучше показать и рассказать. Так повышается шанс полезных уточняющих вопросов. Обычно демо укладывается в 10-25 минут в зависимости от размера команды.

[3.3] Когда все задачи показаны, с Not done разобрались, переходим к планированию. Здесь тимлид (продакт, техдир, CEO или лидер команды) забирают экран и объясняют каждую задачу словами, отвечают на все вопросы. Исполнитель эстимирует задачу в часах и если надо - декомпозирует.

[3.4] Весь звонок автоматически записывается в облако zoom. Чтобы не платить за место в облаке и хранить записи вечно, мы написали тул github.com/Welltory/Zoom2…, он автоматически перекладывает запись на youtube с доступом по ссылке и уведомляет всех в канале #video

[3.5] Запись реально помогает. Во-первых, это асинхронный просмотр демо другими членами команды, во-вторых это сильно помогает вспомнить договоренности и детали планирования. В-третьих удобно ссылаться на обсуждение с таймстемпом, спасибо ютубу.

[3.6] 21 час работы в спринте. После десятка экспериментов мы нашли эталон объёма планируемой работы. Если планировать меньше, то остаётся свободное время, если больше хотя бы 1-2 часа, никогда не успевается. Для наших команд работает, нас устраивает.

[3.7] Итого, если вы девелопер, для работы вам нужно: по уведомлению зайти на звонок, показать, что сделал, уточнить и запланировать свои задачи, приступить к работе на новой доске, перекинуть задачи в колонку Ready for test, вспомнить про кодфриз, пофиксить из Bugs. Всё.

[3.8] Мы никак не используем scrum практики: burndown charts, planning poker, sprint retrospective. Первые два это какой-то прикол, который я никогда не понимал. Burndown charts - оверменеджмент, planning poker - дичь, sprint retrospective - не требуется, если процессы здоровые

[3.9] У нас открытая и горизонтальная оргструктура, пока не было этого процесса, половину коммуникаций занимали разговоры как всё не удобно и не понятно, фаундеры занимались межкомандной дипломатией, а не проработкой задач. Если вы обсуждаете процессы, то значит они хуёвые.

[4.0] Управление задачами

Постановкой задач на создание\изменение продукта и развития бизнеса занимаются только фаундеры. Опытные тимлиды в своих зонах ответственности работают в спец проектах и таких направлениях, как devops или support.

[4.1] Я не верю ни в какие самоорганизующиеся команды, которые получив стратегическую задачу сами сделают продукт. В стартапе, где 90% продукта неведомая хрень, это невозможно. Поэтому максимум внимания уделяется внятности, краткости и конкретности формулировок задач.

[4.2] Конечно мы пробовали делегировать common фичи, вроде "регистрация" или "биллинг" наёмным продактам, из этого ничего не вышло. Любая такая фича будет проектироваться на столько преступно долго, что проще отказаться от такого человека и сделать самому.

[4.3] 8 из 10 продактов любого уровня, в т.ч. с запросами по 300k RUR\mo и с опытом из гигантов индустрии, на собеседовании и по памяти не смогут спроектировать фичу восстановления пароля, обязательно забудут что-то важное. Проверялось многократно, сам не понимаю, как же так.

[4.4] Поэтому мы сделали процессы так, чтобы и простые и сложные фичи прорабатывались через фаундеров и делались максимально быстро. Наёмных продакт менеджеров в команде нет до сих пор, хотя с ростом компании и зрелостью продукта такая роль становится возможной.

[4.5] Все задачи содержат дефолтные блоки "Что происходит" (зачем, как будет использоваться), "Что сделать" (конкретика), "Ожидаемый результат" (форма). И опциональные "Дедлайн" (редкость), "FAQ" (ответы на предполагаемые вопросы). ТЗ пишутся отдельно в confluence.

[4.6] У каждой команды есть свой бэклог - списочный проект в @asana, куда складываются важные, но не срочные задачи. При подготовке спринта к планированию тимлид его грумит и достаёт самое актуальное.

[4.7] Дефекты найденные юзерами, а так же не блокирующие косяки найденные QA укладываются в проект с багами. Продакт достает их оттуда каждую неделю и отправляет на исправление в спринт. Тимлид саппорта ходит на плэнинги разработки и "продаёт" важность тех или иных дефектов.

[4.8] Асана позволяет легко держать задачи-карточки в разных проектах, поэтому сложные фичи декомпозируются и одновременно находятся в нескольких спринтах и метапроекте продакта, где отслеживается общий прогресс.

[4.9] Команда всегда в курсе крупных проектов в компании. Фаундеры отчитываются о развитии компании на ежемесячном звонке, показывают все метрики, рассказывают о новых проектах и их таймлайне, объясняют роадмэп всего продукта. Вся информация в компании доступна всем.

[5] Инструменты

Для удобства работы мы используем: slack, asana, confluence, zoom, figma, zappier, standuply, ifttt, grafana, metabase, amplitude, appfollow, intercom, support hero, siftery, docsend. Другие узкоспециализированные сервисы - тема отдельного треда.

[5.1] Мы вообще не используем емейл и вся компания и аутсорсеры работают у нас в слаке, асане и конфлюенсе. Я был бы очень рад навсегда забыть емейл, но внешние коммуникации обязывают. Так же емейл иногда использует саппорт, люди привыкли писать на почту.

[5.2] C slack я уже рассказал про asana, zoom, standuply, расскажу ещё про zappier и ifttt. Все работают в слаке, поэтому с ним проинтегрировано всё, что можно и полезно. Zappier и IFTTT доставляют в слак несколько десятков уведомлений из почты и других мест.

[5.3] Нотификации в нужный канал: тестовые сборки в iTunes и Google Play, уведомления о всех релизах, входящие в поддержку, комментарий в соц сетях, новый твит с упоминанием, фидэк от пользователя, новое резюме, новый пост в блоге, новый меншн в прессе, заявка с сайта и т.д.

[5.4] Figma. Мы долго сидели на zeplin+sketch и для дизайна-разработки он удобнее, однако все остальные сильно страдают. Речь и про продакта, и локализаторов и маркетологов. Дизайн нужен всем и поэтому браузерная Figma идеальное решение. Зашёл, поправил, экспортнул.

[5.5] Дэшборды и метрики используются в трёх панельках grafana, metabase, amplitude.
Grafana - реалтайм мониторинг здоровья продакшена и метрик роста. Metabase - работает напрямую базой, используется всеми для контроля KPIs. Amplitude - лучший инструмент продуктовой аналитики.

[5.6] Всего в компании более 100 дашбордов, это много и погодите крутить пальцем у виска. 1\3 это продуктовые дашборды на каждую фичу, другая треть это технические devops дашборды, и оставшиеся это всё про бизнес метрики и главные KPIs. Каждый работает только со своими.

[5.7] Для саппорта мы используем 3 основных тула: @appfollowru - для ответа на reviews прямо в slack, intercom для общения в юзерами в чате внутри нашего приложения и support hero для ведения мультилэнг хэлпа. Мы много пробовали и это 100% самое удобное, что есть на рынке.

[5.8] Фаундерские тулзы: docsend для инвестиционного питчдека, идеальный инструмент, даёт полную аналитику по просмотру слайдов и трасирует куда и кто ваш питчдек рассылает. Siftery очень помогает контролировать расходы, если у вас банк в US или юзаете Xero для бухгалтерии.

[5.9] Под узкоспециализированными сервисами я имел ввиду тулы для разработки и маркетинга, их ещё несколько десятков, девелоперские можно глянуть тут stackshare.io/welltory , маркетинговые обычно никому не интересны :)

[6] Результаты подхода и его минусы

C начала 2018 года прошло 34 недели, что успели сделать: 33 back-end и front-end релиза, 47 релизов мобильных приложений, 4 фичеринга в App Store, выросли с 300k до 650k юзеров

[6.1] На 144% выросла ключевая метрика - "замеры пользователей" и подобралась к 5М, но кратно быстрее всех других метрик росла выручка.

[6.2] Очевидным минусом наших процессов является то, что иногда новоприбывшие члены команды не готовы работать с таким уровнем прозрачности. Если ты не умеешь или не привык давать результат, то команда сразу это видит. Было 2-3 кейса, когда люди сами уходили через несколько дней

[6.3] Учитывая, что неумение и нежелание давать результат не лечится, это хороший фильтр от долгосрочных проблем с наймом людей, которые привыкли больше занимать чем-то другим, а не работой

[6.4] Если человек проработал месяц, то шанс, что он уволится сам практически нулевой.

[6.5] Часть команды любит путешествовать и меняют несколько стран за год. Это практически никогда не мешает работе. Если часовой пояс сильно меняется, то время звонков подстраивается.

[6.6] Минусом для всех остальных вопросов стартапа будет нагрузка фаундеров по митингам. Продакт @jsmorodnikova делает 14 регулярных звонков в неделю, я 5. В остальное время фандеры готовят задачи и решают вопросы, которые некому поручить.

Думаю написать ещё тред-пост, о чём бы вы хотели почитать?

Ретвиты приветствуются.