Как стать автором
Обновить

Кейс SMM-приложения KUKU.io: путь от спринта в 4 месяца до разумного планирования

Время на прочтение 6 мин
Количество просмотров 2.1K
Ребята из стартапа KUKU.io, популярного сервиса для SMM, прошли долгий путь от хаотичного планирования и спринтов, растянутых почти на полгода, до логичного управления задачами, автономной команды и, наконец, закрываемых в срок спринтов. Молодым проектам на заметку.

Менеджер проекта Павел поделился историей о том, как удалось безболезненно решить большиство проблем:




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

Когда мы начинали, KUKU.io умел публиковать контент в 4 социальные сети: Facebook, Вконтакте, Twitter и Linkedin. Однозначно, полноценным управлением социальными сетями это никак не назовешь, и приложение постепенно начало обрастать другими особенностями: пользователи хотели видеть разделение аккаунтов соцсетей в каналы или проекты, анализ социальных сетей стал ключевым фактором выбора (или не выбора) сервиса, UTM-метки, сокращение ссылок, много картинок в одном посте, новые соцсети (сейчас KUKU.io поддерживает 10) и др. — все это предстояло реализовать.

В первые дни, когда я пришел в проект, была ситуация, когда вроде все понятно, а на деле ничего не понятно. Что за проект я понял очень быстро, без деталей, так как продукт уже на продакшене, и можно потыкать посмотреть, что к чему. К тому же, команда сразу позаботилась о крутом UX/UI, разобраться за несколько минут сможет даже человек, далекий от социальных сетей.

Команда… Команда есть, отличные все ребята, профессионалы в своем деле: от нереальных разработчиков до маркетолога и сммщика. Кто что делает, не понятно. :) Есть какое-то управление проектами и системы: Jira и GanttPRO, в них что-то есть, но что это — тоже ни малейшего представления (сторей тасков, описаний к ним минимальных, логики, ничего нет).

Лезу в документы — есть в драйве море папок, в которых вроде по названиям что-то адекватное намечается: альфа версия, анализ конкурентов, бета версия, демо, спека версии 1.0 и тд. Открываешь — заголовок, какие-то наброски и все.

В результате имеем: рабочий продукт, без понимания, как и что в нем работает, кто над чем работает, кто product owner, кто за что отвечает, куда проект идет, какие цели в дальнейшем, какие рабочие правила. Планирование не определить какое было, так как видно, пытались прийти к какому-то фреймворку гибкому, но все забрасывали. В результате имелась куча релизов, спринтов незакрытых, гигантский спринт в 4 месяца. По рабочему процессу была такая схема: практически любой участник команды создавал себе issues в Jira, естественно без описаний.

Т.е. залазим в спринт или бэклог, а там какая-нибудь борода «Изменить существующий блок» или баг «Не работает login — консольная ошибка #».

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

Поэтому начали с простого:

  • Взяли за основу канбан (свой проект, поэтому нет привязки по срокам).
  • Определили, кто за что отвечает, кто принимает решения.
  • Выбрали актуальные задачи.
  • Расставили приоритеты.
  • Договорились с QA насчет метода описания багов в виде use cases с описанием среды.
  • Наконец, прогрумили бэклог (заняло очень много времени).
  • Начали описывать все через истории, чтобы уменьшить количество багов.

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

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

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

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

Из XP взяли большую часть CI (Continuous Integration), что ускорило обновления и, опять же, позволило выпускать более качественные релизы, обратную связь с клиентом (users' feedback) взяли за основу при расставлении приоритетов; все решения принимали сами, на свой страх и риск.

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

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

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

Позже из Scrum взяли story и epics — идем к детальному планированию. Можно сказать, что мы приходим к более детальному планированию и коротким итерациям. Сейчас мы знаем, что у нас будет почти на месяц вперед на процентов 80-90. И легко можем вносить правки.

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

Что в нашем случае привело к автономности:

1) постоянно меняющийся и растущий продукт и отпуска — все понюхали пороху в роли других участников и имеют представление, что и как устроено в продукте.
2) ежедневные митинги — мы на них не только рассказываем, что кто делает, но и стараемся решить оперативно задачу, таким образом вся команда, хоть краем уха, но знает про изменения либо про проблему (если мы понимаем, что затянется обсуждение, то остальных участников отпускаем).
3) планирование — мы знаем, что у нас сейчас и к чему мы идем.
4) сплоченость команды — походы в бар, корпоративы, живое общение, отсутствие давления.
5) коммуникации — еще надо расти в этом направлении, но сейчас уже, если у кого-то есть проблема, ее не держат в загашнике долго, а сразу говорят свое фе или бьют в колокол, нет боязни высказаться.

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

Итак, что же по итогу? Прежде всего, у нас уменьшилось количество багов: сказать насколько, точно не возьмусь (честно говоря, не вел учета, интересно будет проанализировать), но на выходе у нас очень добротный продукт, а те баги, которые появляются, не являются критичными — мелкие недочеты в основном из-за невнимательности (хотя все еще бывают косяки с мержем и деплоем). Но нашему QA (а он у нас 1) стало жить проще, да и радовать пользователей релизами мы стали намного чаще.

Мы планируем примерно на месяц, потом фикс, регресс, деплой. Итого примерно раз в 5-6 недель релизим обновление с крупными особенностями, а обновления с багфиксом — по мере поступления сообщений от пользователей. Раньше вообще наши планы были космосом. Спринт на 3 недели мог затянуться на пару месяцев.

Яркие последние примеры: это Контент План для социальных сетей и Командный План для SMM и маркетинговых агенств и компаний, в которых не один человек занимается продвижением в социальных сетях. Последний мы думали сделать за месяц по первой прикидке вообще без понимания как это должно быть. После анализа, декомпозиции, написания небольшой «спеки» оценили скоуп задач в 2 месяца. По факту команда выкитила командный план, кучу обвесов к нему, smm и маркетинговых плюшек, годовые подписки, улучшили аналитику социальных сетей, оттестировали все это, сделали регресс и релизнули на продакшен за 3 месяца. Это с учетом того, что у нас — 3 разработчика, у двоих была сессия и выселение из общежития, параллельно создавался Контент План, они связаны между собой и должны мержится без конфликтов. И оно все работало, как было описано. Это реально успех!

Еще одно достижение огромное достижение — меньше конфликтов в команде.

Дальше хотелось бы прийти к более частым релизам и уведомлять пользователей о наших ближайших обновлениях. Весь road map, мне кажется, не так круто показывать — нет интереса, все на ладони, а так ждать будут. :)
Теги:
Хабы:
+2
Комментарии 0
Комментарии Комментировать

Публикации

Истории

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн