Привет, меня зовут Андрей Фомин, я создатель онлайн-школы для подготовки к ЕГЭ NeoFamily. Платформу я создал в 2019 году. В штате компании 80 человек, не считая кураторов. Возникла задача организовать командную работу — поэтому мы и начали искать трекер.
До WEEEK
До знакомства с WEEEK мы использовали Trello. Он у нас был чисто как Канбан-доска. Там не было единого пространства для задач, досок по разным направлениям и отделам — каждый юзал Trello для себя. Коммуникация там не шла, командной работы не строилось. К тому же тогда Trello уже иссякал на российском рынке.
Мы стали искать российские аналоги и остановились на Яндекс.Трекере — там тоже не пошло. Перешли в другой — название я даже не помню, но он популярен у разработчиков.
А потом наш руководитель маркетинга посоветовала мне WEEEK. Я посмотрел и решил — да, нужно попробовать.
Как NeoFamily построил работу в WEEEK
Я разрабатываю крупную платформу и хорошо понимаю, как сложно сделать продукт, который будет не только красивым, но и юзабельным. Я увидел это в WEEEK и вдохновился, потому что это круто.
В WEEEK началась наша командная работа. Мы впервые начали пользоваться спринтами — в разработке они у нас двухнедельные. Вместе со спринтами стали декомпозировать стратегические таски на разные задачи и связывать их. Для этого мы активно используем Канбан-доски — это база для буста производительности отделов.
К примеру, у разработки есть доска с колонками: бэклог, процесс, ревью, тестируем, готово в прод, на проде. Базовый набор для контроля процессов.
Ещё мы используем связи задач, чтобы понимать зависимости — порядок выполнения и блокирующие задачи. Используем их только на задачах по фронтенду и бэкенду. Скажем, у нас родительская — это фронтенд, потом идёт дочерняя — это бэкенд. Потом от фронтенда или бэкенда идут дополнительные подзадачи.
У каждой задачки есть теги, которые отличают задачи по фронтенду, бэкенду, продукту — «product» и «tech». Систему тегов придумал наш проджект.
- Первый тег «product» нужен для меня — я могу фильтровать и смотреть, на каком этапе находится функция. С помощью фильтров я вижу все задачи, которые касаются именно продуктовых историй, и не влезаю в технические дебри.
- Второй тег «tech» — для программистов. Им удобнее разбивать функции на мелкие фичи, каждая из которых может находиться на разных этапах разработки.
В WEEEK вообще хорошо сделаны теги и фильтрация — можно создавать бесконечное количество цветных тегов и фильтровать по ним задачи. Даже в пределах одной доски каждый может ориентироваться по нужным тегам.
Для долгосрочного планирования у нас есть общее расписание и планы отделов. Их вывели в отдельный проект — в формате календаря на месяц, где по дням расписаны всякие анонсы, рассылки. Тут тоже используем теги, чтобы фильтровать и ориентироваться по отделам. К примеру, вводим «маркетинг» и получаем планы отдела маркетинга на ближайший месяц.
Классно, что в комментариях к задаче можно тегать других пользователей и вести полноценную коммуникацию — это тоже бустит командную работу. К задаче можно прикреплять ссылки, файлы, фотки — что угодно. Можно ввести трекинг времени на задачи, чтобы рассчитывать объективную «производительность» команды и ориентироваться на это при планировании.
Ещё два преимущества для нас — прекрасные уведомления в Telegram и База знаний. Нравится, что уведомления приходят вместе со сменой статуса задачи, и подписант никогда не останется в неведении. А Базу знаний активно используем её для маркетинга и продаж и для регламентов.
Набор методологий, собственная методичка и проджект-менеджер
С использованием WEEEK я стал увлекаться разными методологиями работы. Мы впервые начали декомпозировать задачи и использовать связи — и это натолкнуло на мысль: «А что ещё есть, помимо этого?»
К тому же наличие в WEEEK таймера Помодоро и медитаций заставило подумать: «Круто, значит, это реально используют — значит, это работает». И я стал погружаться в тему методологий и Agile.
Так WEEEK стал проводником к изучению и внедрению дополнительных методологий работы. А ещё я вдохновился поощрением Agile-подходов.
В итоге я собрал актуальные методологии работы, адаптировал их специально под нашу компанию — и описал это всё в методичке, такой небольшой внутренней книге. С помощью методички мы хотели улучшить онбординг новых сотрудников и распространить идею, что эффективные процессы — основа роста и экономии сил.
Мы используем вот такие методологии:
- Брейншторм. Регулярные, по всем правилам, в основном для создания сценариев рилсов. Никто не может генерировать десятки креативных идей каждый день — а после коллективного брейншторма у нас минимум 50 идей в работу.
- Шесть шляп мышления. Стали использовать эту технику благодаря WEEEK — после подарочного Канбан-набора, где была эта игра. Проводим удалённо в Miro.
- Спринты. Это база. Сначала определяем стратегические цели у проекта, а потом декомпозируем их и определяем временные промежутки. Благодаря спринтам чудесным образом исчезают горящие задачи, улучшается атмосфера в коллективе — и главное, растёт КПД отдела.
- Матрица Эйзенхауэра. Таблица из четырёх квадрантов, которая распределяет задачи по важности и срочности. Позволяет грамотно расставить приоритеты и действовать согласно стратегии.
- Покер планирования. Игра, в которой команда должна одновременно оценить задачу по сложности. Регулярный покер планирования со временем научит команду точнее оценивать силы и общие риски. Особенно это пригодится при спринтах.
- Ретроспектива. Всегда полезно оглянуться, посидеть и подумать, что было сделано хорошо, а что — не очень. У нас ретро состоит из трёх этапов обсуждения: чем мы гордимся, что можно было сделать лучше и что изменим в следующий раз.
- Планёрки. Классический способ коммуникации в команде. Как их проводить — история индивидуальная, главное не перебарщивать ни по частоте, ни по времени.
- Канбан. Про него я уже рассказал — это наш метод управления работой. Чтобы видеть, что нужно делать, что сейчас делается и что уже сделано.
А ещё у нас появился проджект-менеджер.
Когда в команде сменился фронт-тимлид, доска немного поплыла в плане актуальности. Я стал искать проджекта. Целью было найти не супер-дорогого спеца, не спасителя ситуации, а того, кто с умом наведёт порядок.
В итоге нашёл парня, который кодил на Python и хотел попробовать себя в проджект-менеджменте. Оказалось, это классный вариант — программист как никто другой знает, как работает система изнутри, и у него всё хорошо с логикой. Это очень важно для проджекта.
До появления проджекта программисты работали просто по Канбану, а проджект ввёл спринты. Выросла прозрачность планирования, стало легче синхронизировать изменения. У продуктовых задач появились очерченные сроки, освободилось время на точечный груминг — теперь можно разбирать не весь бэклог, а только его приоритетную часть. Это порадовало разработчиков и ускорило выход функций.
Чтобы всё это работало, мы используем флоу работы — описание того, как должна выглядеть задачка, что у неё есть за поля, какие атрибуты мы применяем.
Например, приоритет задач у нас необязателен. Мы используем только низкий и высокий маркеры — ведь приоритетность забора тасок в работу определяет вертикальное положение этой задачи, как и описано в флоу.
После внедрения методологий сотрудники стали замечать, что работать стало проще, а они начали выдавать тот же результат с меньшими трудозатратами. Появляется больше работающих идей и гипотез. Теперь есть время на аналитику — к примеру, раньше мы не оценивали, как проходят наши трансляции, а сейчас есть силы на полный анализ.
Планы и ожидания от WEEEK
WEEEK закрывает любые потребности — можно создавать доски под отдельные спринты, удобные уведомлениями в Телеграм, хорошие теги и фильтрация по ним.
Но из больших минусов — нам не хватает интеграции с GitLab, очень ждём появления. И хотелось бы усилить хранение файлов. Нам пока неудобно хранить в WEEEK готовые файлы, и у нас нет большого хранилища документов, и мы базово используем Телеграм-чаты или Яндекс Диск.
Ещё отмечу, что если в разделе «Образование» будет какая-то база знаний или текст в таком же формате, как наша методичка — это облегчит жизнь многим пользователям.
Мы же планируем развивать нашу методичку. Следующим этапом будем создавать внутренние метрики, чтобы отслеживать эффективность наших методологий.
Подписаться