Маленькой команде — большие цели. Как развивать SaaS, если вас пятеро
Привет! Я Алина, руководитель разработки конструктора ботов Smartbot. В этой статье я хочу поделиться опытом развития цифрового продукта силами маленькой команды.
Если у вас уже есть MVP и вы даже смогли привлечь первых юзеров, перед вами встает целый ряд интересных задач: нужно разрабатывать новую функциональность, исправлять баги, обрабатывать запросы пользователей и искать способы привлечения новой аудитории. Крупным корпорациям в этом плане неплохо живется — обычно под каждую из таких задач формируется целый отдел. А что делать, если над вашим продуктом работает всего 5-6 человек?
Простого ответа здесь нет, и сама я тоже не нашла большой красивой кнопки, по нажатию которой все процессы налаживались сами собой, а релизы вставали на поток. Поверьте, даже когда вы работаете с крутыми и целеустремленными людьми, при неправильном распределении задач они едва будут успевать разбираться с багами. Оказалось, что для грамотного управления командой недостаточно два раза в день принимать простой советский скрам.
И все же за последний год наша маленькая команда сумела встать на верный путь. Шаг за шагом мы пришли к стабильному результату: сейчас нам удается запускать по релизу-двум в неделю, хотя раньше такая скорость казалась фантастикой.
Сегодня я расскажу о том, как мы этого добились. Не буду грузить вас объемными теориями и абстрактными понятиями (почти), а просто поделюсь практическими действиями, которые помогли именно нам. Вполне вероятно, что и вашей команде они смогут принести пользу.
Оглавление
Кто мы и чем занимаемся
Мы разрабатываем Smartbot — конструктор чат-ботов на все случаи жизни. С его помощью можно автоматизировать рутину во внутренних процессах и во взаимодействии с клиентами. Проект довольно быстро обрел популярность, и со временем нашими услугами стали пользоваться не только частные, но и крупные корпоративные клиенты. А с большим спросом, как известно, приходит и большая ответственность.
Правда, в команде нас было всего четверо: техлид-бэкендер, бэкендер, фронтендер и я. Вот только число запросов на поддержку росло, заказчики хотели видеть дополнительную функциональность под свои задачи, и наш паровозик оказался не готов так быстро встать на новые рельсы. Мы еще не умели работать в подобном режиме.
Как мы работали раньше
Поначалу команда продолжала пользоваться общей канбан-доской, и все задачи лежали в едином пространстве. Вообще все. На одной вкладке могли соседствовать тикеты на разработку нового шаблона и на отладку мелкого бага. Мы одновременно пытались кастомизировать продукт под запросы одного крупного заказчика и допиливать SaaS под потребности наших пользователей.
Конечно, мы расставляли приоритеты — по крайней мере, старались это делать. Здравый смысл и четкие договоренности позволяли оценить, какую задачу нужно решить здесь и сейчас, а какую можно с чистой совестью отправить в бэклог. Но когда ты не ставишь перед собой конкретную цель, на здравом смысле далеко не уедешь. Бэклог рос, наша производительность падала, и вся операционка со временем превращалась в хаос.
Нам казалось, что чем меньше мы допускаем простоев, тем эффективнее мы работаем. Знали бы вы, сколько лишних задач мы сами себе насоздавали с таким подходом!
К примеру, если продуктовая задача по фронту была заблокирована и ожидала реализации бэка, мы отдавали фронтендеру запрос на саппорт. Само собой, в этот момент на бэкендеров заводился отдельный тикет по первой задаче.
Затем фронтендер осознавал, что для решения саппорт-запроса ему тоже нужна помощь бэкендеров, и новые тикеты продолжали почковаться. Там, где нужно было работать над одной задачей, мы сами себе заводили четыре. Между ними приходилось постоянно переключаться, каждая порождала новые вопросы и требовала новых обсуждений, и в итоге этот вал обрушался на техлида, который должен был все отревьюить в свободное от разработки и аналитики время.
Сама я тем временем анализировала аудиторию, паттерны использования нашего продукта, старалась определить потребности наших юзеров и найти новые фичи, которые помогли бы нам захватить рынок. А еще тестировала весь код после ревью от техлида. В плане менеджмента меня хватало только на распределение верхнеуровневых задач, а вот до процессов руки не доходили очень долго.
Мы работали много и усердно, но наш труд не приносил ожидаемых результатов. Эстимейты не сбывались, продукт обогащался крайне медленно, техдолг копился, а вслед за ним росла и общая неудовлетворенность самой команды. Становилось очевидно, что подход пора менять.
Что мы решили внедрять
Из оглавления вам могло показаться, что названия следующих разделов больше похожи на набор тостов для корпоратива, чем на список практических рекомендаций. К тому же, мои советы вряд ли станут откровением для уверенных гуру Agile. Признаю, многие из этих методов действительно описаны в любом фреймворке, и как раз поэтому я не буду погружаться в теорию — вместо этого расскажу, как мы внедряли ее на практике.
Выстраиваем иерархию приоритетов
Определяем основные направления
В первую очередь мы решили оценить, какие направления работы являются для нас ключевыми.
-
Мы работаем над конкретным цифровым продуктом, совершенствуем и оптимизируем его. Разработка новых фич и способов интеграции составляет львиную долю наших задач. Следовательно, для начала мы выделяем продуктовое направление (или, говоря проще, продукт).
-
Наш продукт пользуется спросом, и клиенты часто обращаются за технической помощью, сообщают о неисправностях и запрашивают дополнительную функциональность. В свою очередь, скорость обработки таких запросов напрямую влияет на клиентский опыт и удовлетворенность заказчиков нашими услугами. А это значит, что необходимо выделить направление поддержки, a.k.a. саппорт.
-
Наконец, месяцы разработки в производственном кошмаре не пошли на пользу нашему коду, и в нем накопилось немалое количество костылей и кривоты. Такой техдолг нужно разруливать, чтобы он не дал о себе знать в самый неподходящий момент. А еще нужно писать мониторинг, собирать аналитику, оттачивать быстродействие и в целом решать инфраструктурные вопросы. Под эти задачи мы выделяем техническое направление (техника).
Список можно сделать и длиннее. Кто-то считает отдельным направлением непрерывное совершенствование, кто-то выделяет обязательное управление базой знаний, и так далее. Итоговый перечень будет напрямую зависеть от ваших планов и основных задач. Главное — это само наличие такой верхнеуровневой классификации, поскольку с нее начинается иерархия ваших приоритетов.
Затем мы назначили ответственных за направления. Ввиду специфики нашего продукта нам нужна значительная концентрация ресурсов на бэкенде, поэтому отвечать за треки тоже должны бэкендеры. Здесь мы уперлись в очередное ограничение, на этот раз арифметическое: трека три, а бэкендеров в команде двое.
Три и два надо было приравнять. И мы приравняли!
Точнее, выстроили процесс обработки пользовательских обращений таким образом, чтобы до разработчиков доходила только информация о багах, а остальные проблемы решались на уровне сотрудников, выполняющих роли первой и второй линии. А раз от саппорта разработчикам осталась только обработка багов, которая вполне совпадает с назначением технического трека, мы смогли их неформально объединить.
Чудовище Франкенштейна из саппорта и техники мы доверили техлиду, а второй бэкендер сосредоточился на продукте. Само собой, это не значит, что остальной команде стало нечем заниматься — ответственные за треки не разруливали все в одиночку, а расставляли задачам приоритеты и привлекали коллег для их выполнения.
Итак, глобально перед нами остались два направления. Возникает вопрос: на чем же сосредоточиться? Опять на всем сразу? В прошлый раз такой подход оказался не самым эффективным — как мы помним, небольшая команда с трудом концентрируется на потоке задач по разным направлениям. Нужно было думать дальше.
Ставим цели и сортируем задачи
Вот здесь мы и переходим к целеполаганию. Чтобы усилия команды были всегда направлены в одно русло, мы начали ставить квартальные цели, которые соответствовали одному из треков: к примеру, в течение квартала мы должны или обогатить сервис определенными фичами, или решить конкретную проблему путем оптимизации компонентов инфраструктуры, и так далее.
Когда к нам поступает новая задача, при определении ее приоритета мы задаем себе вопрос: насколько ее решение позволит нам приблизиться к текущей цели? Этот простой фильтр позволяет легко делить таски на актуальные и неактуальные — если вклад от их решения будет заметным, мы берем их в работу здесь и сейчас, а если они не соответствуют квартальной цели, то сразу летят в бэклог.
Разумеется, сам по себе такой подход тоже не избавляет от производственного хаоса. Входящий поток актуальных задач может оказаться слишком мощным, каждая небольшая доработка может блокировать соседнюю и плодить все новые и новые тикеты. Поэтому перед началом работ над задачей мы стали анализировать, возможно ли объединить ее с другими в более масштабную.
Далеко не всегда таски соединяются легко и изящно — порой этот процесс отнимает не меньше времени, чем решение одной из задач. Но результат дает о себе знать: если вместо точечных изменений заниматься проблемой глобально, это часто позволяет не только разом закрыть целый ворох небольших дел, но заодно и застраховаться от дополнительной работы над этой проблемой в дальнейшем.
Важно: этот метод предполагает, что здравый смысл не покидает чат. Если в «продуктовый» квартал обнаруживается критический баг, а в «технический» квартал приходит крупный корпоративный клиент и просит срочно реализовать новую функциональность, мы корректируем текущие цели под новые обстоятельства. К счастью, судьба не так часто подкидывает подобные испытания.
Такой подход позволил нам меньше распыляться и работать более слаженно. Но проблему непрерывного потока новых задач он все еще не решал. Чтобы качественно анализировать и решать имеющиеся таски, ребятам нужна была некоторая автономия и гарантия, что на них не свалится разом целый ворох новых дел.
И здесь нам пришел на помощь старый добрый Agile с его спринтами.
Вводим спринты
Вряд ли вам незнакомо это понятие, но вкратце поясню: спринт — это определенный период (как правило, неделя или две), на который команда планирует конкретный список задач. Все новые таски, которые прилетают на команду в течение спринта, временно располагаются в бэклоге.
Перед началом этого периода мы трубим общий сбор, залезаем в бэклог, достаем оттуда наиболее приоритетные тикеты и раздаем их — каждому по потребностям, от каждого по возможностям. В конце спринта вновь собираемся у костра и проводим ретроспективу для подведения итогов (о ней подробнее чуть позже).
Приоритет тикетов для нового спринта не возникает из воздуха. Вспомним оговорку про сортировку из предыдущего раздела: цели помогают нам определить, какая задача сейчас актуальна, а какая нет. Соответственно, при каждой ревизии бэклога мы оцениваем, насколько та или иная задача позволит нам приблизиться к намеченной цели. Если влияние задачи будет значительным, то мы смело берем ее в работу.
Поскольку во время спринта все новые таски смиренно лежат в бэклоге, разработчики могут более эффективно работать над старыми. Гарантия, что в рандомный четверг дел не станет вдвое больше, очень помогает не выгореть. К тому же, когда вы четко понимаете, какой объем задач стоит перед вами, вы можете самостоятельно управлять своим временем.
Собственно, так и выглядит наша иерархия приоритетов:
Благодаря ей мы решили большинство наших проблем, но, к сожалению, не все. Зато нам стало намного проще разобраться в оставшихся.
Балансируем команду
Приоритизация задач позволила нам выявить тенденцию: задач по бэкенду копилось больше, чем команда успевала переварить. Чтобы соблюсти пропорцию между фронтом и бэком, мы взяли бэкендера-стажера и доверили его обучение разработчику, ответственному за продуктовый трек. Через несколько спринтов в нашей работе больше не было явного перекоса в сторону бэкенда.
Потом мы выявили еще одно «бутылочное горлышко», в котором застревали многие задачи. Я отвечала за описание задач, верхнеуровневую аналитику и менеджмент, при этом я же была тестировщиком и второй линией техподдержки. Следовательно, на этапе тестирования работа постоянно подвисала. Чтобы разделить зоны ответственности, мы наняли в команду QA, которому передали тестирование и задачи второй линии, и вот тогда все шестеренки пришли в движение.
Заметьте, мы начали не с бездумной попытки заткнуть все дыры новыми рабочими руками. Если бы мы сперва не определились с приоритетами, не проанализировали, на каких направлениях реально нужны дополнительные ресурсы, нам вряд ли удалось бы расширить команду адекватно. Вероятнее всего, мы бы просто разрослись втрое, а задач в работе так и не стало бы меньше.
Делаем акценты на сильных сторонах
Или, опять же, «каждому по возможностям, от каждого по способностям». Если вам удалось собрать команду крутых специалистов, это не значит, что все они с одинаковым энтузиазмом будут браться за любую задачу. Побеседуйте с ними о предпочтениях, и вам станет ясно, на чем хотели бы сосредоточиться ваши сотрудники и как грамотнее распределить между ними нагрузку.
Вернемся к нашему техлиду. Почему именно ему, а не другому бэкендеру, мы доверили технический трек? Неужели его компетенции не пригодились бы в разработке продукта?
Потому что его заряжает работа над системой в глобальном смысле. Он не станет лепить пластырь там, где требуется хирургическое вмешательство — таков его принцип. Он старается масштабировать мелкие проблемы до тех пор, пока не доберется до их корня. В руках именно такого человека техника будет в безопасности.
А другие что, раскиданы по остаточному принципу? Нет, конечно. За продукт отвечают те разработчики, которым комфортнее работать обсуждать и реализовывать новую функциональность. А еще лучше, когда эти разработчики способны поставить себя на место клиента, разобраться в его потребностях и предложить самое изящное решение.
Но как же быть, если кто-то и сам не знает, в чем конкретно его сильная сторона? Таким сотрудникам мы даем задачи из разных треков, если это не противоречит текущим целям. Чем больший скоуп деятельности разработчик сможет охватить и «пощупать», тем проще ему будет определиться с предпочтениями.
Старайтесь учитывать, в чем члены вашей команды смогут по-настоящему проявить себя. И не забывайте время от времени интересоваться, устраивают ли их текущие задачи и зоны ответственности. Специфика продукта может меняться, а вместе с ней меняется и рутина ваших коллег, поэтому их обязанности нужно регулярно калибровать.
Как проходило внедрение
Менеджеру ни в коем случае нельзя забывать о том, что он работает с людьми. А мозг человека, даже самого талантливого и трудолюбивого, имеет одно неприятное свойство — ему тяжело выходить из зоны комфорта и принимать перемены. Вы не найдете ни один коллектив, который встретил бы пачку управленческих инициатив единогласным одобрением. Никто не скажет вам «Ого! И как мы раньше жили без фреймворков, треков, спринтов и остальных абстрактных англицизмов?»
К тому же, подобный коллективный скептицизм имеет под собой вполне осязаемые основания. Далеко не все общие рекомендации пойдут на пользу любой команде. На то они и рекомендации, а не правила.
Еще важно помнить, что обкатка новых практик всегда занимает какое-то время, и вы не сможете внедрить все, везде и сразу. Поэтому изменения должны быть поступательными, их ценность должна быть понятна каждому сотруднику, а сотрудники, в свою очередь, должны иметь возможность дать обратную связь и поделиться мнением о нововведениях.
Проще говоря, каждую идею нужно сначала обсудить. В том числе для этого мы стали собираться на регулярные ретро-встречи в конце спринтов. На них мы не только делились достижениями и рефлексировали проделанную работу, но и давали друг другу фидбэк по новым практикам.
Кто-то из ребят предлагал свои идеи, общими силами мы их докручивали и воплощали. Какие-то идеи не приживались, какие-то оставались с нами надолго, а самые полезные попали в шорт-лист, которым я с вами поделилась. И даже сейчас, когда мы уверенно стоим на ногах и не путаемся в процессах, мы продолжаем собираться на ретро.
Чего мы добились
Благодаря тому, что мы перестали распыляться на все подряд, нам удалось закрыть базовый техдолг. Но насколько это оказалось полезно? Чтобы перейти от абстрактных оценок «нам помогло» и «у нас улучшилось» к реальным результатам, я предлагаю рассмотреть два простых показателя: количество зарегистрированных обращений и количество зарегистрированных багов.
Сравнивать будем цифры за первый и третий квартал 2024 года (во второй квартал мы как раз сосредоточились на технике).
-
За первый квартал мы зарегистрировали 85 обращений, из них 38 были связаны с багами.
-
За третий квартал мы зарегистрировали 48 обращений, из них 18 были связаны с багами.
Итого, благодаря разделению треков нам удалось сократить количество зарегистрированных обращений и багов практически вдвое (на 43,53% и 62,5% соответственно). С учетом того, что количество пользователей SaaS за этот период только возросло, можно утверждать, что наш продукт действительно стал менее багучим.
Что хотим посоветовать
В первую очередь, не забывайте, для чего работает ваш конвейер. Ставьте четкие цели, обсуждайте их с коллегами, ориентируйтесь на пользовательские запросы. Ведь ваша конечная цель — создать ценность для пользователя, верно? А значит, весь коллектив должен понимать, каким образом этой цели достичь.
Выстраивайте цели от глобальных к локальным. Не факт, что конфигурация «треки-кварталы-спринты-задачи» подойдет именно вам; подобную иерархию можно сделать и шире, и уже. Главное, чтобы она была. Иначе усилия вашей команды не будут направлены в одно русло, и вскоре разработчики перестанут понимать, что они делают и зачем.
Во-вторых, не ждите, когда производственный ад свалится на вас. Смотрите на свой конвейер максимально широко: анализируйте, где клинит шестеренка, где не хватает мощностей, а где работа порой простаивает. Когда вы игнорируете подобные симптомы, вы рискуете погрузиться в беспросветный хаос даже с командой самых опытных профессионалов.
Когда вы сможете выявить слабые места, думайте о том, как их укрепить. Не бойтесь экспериментов, пробуйте перенять опыт других команд. Нашим опытом я поделилась — возможно, часть моих советов поможет наладить процессы и вам.
Читайте книги про фреймворки и практики — их пишут неглупые люди с большой экспертизой в управлении. Но не увлекайтесь верхнеуровневыми абстракциями, не пытайтесь сделать «все по Agile». Экстраполируйте их теорию на свою реальность, и всегда спрашивайте себя, какое непоправимое счастье именно вам причинит соблюдение очередной рекомендации.
А еще читайте другие статьи в нашем блоге, где мы также делимся экспертизой в управлении командой и развитии продукта:
Автор: wheat_al