Почему «Додо Пицца» стала использовать Kaiten вместо связки Trello и Jira
Сочетание Jira и Trello внутри одной компании создавало больше проблем, чем преимуществ. Мы выбрали третий вариант — Kaiten
Команды у нас всегда имели большую степень свободы в использовании инструментов для работы. Менеджеры продуктов использовали Trello для работы над бэклогом и его обсуждения с бизнесом. Разработчики декомпозировали крупные проекты из Trello в пользовательские истории и вели работу в Jira. Инженеры и QA в своё время выбрали Trello и так на нём и остались.
Используя Trello и Jira одновременно, мы столкнулись с двумя проблемами
Во-первых, приходилось синхронизировать два бэклога для одного продукта. В Trello жил бэклог крупных проектов, а в Jira неизбежно возникала своя жизнь — мелкие баги, недоделки, технически задачи.
Во-вторых, никто кроме менеджеров продуктов не понимал, как по-настоящему работает весь процесс «от идеи до продакшна» здесь и сейчас. Переходы задач из бизнес-анализа в разработку, а из разработки в QA приходилось дирижировать на специальных синхронизациях, иначе информация просто терялась.
Мы смотрели на эти проблемы как на неизбежное зло в течение многих лет. Они неприятные, но вполне себе управляемые. В апреле 2018 года у нас заканчивается контракт с компанией Atlassian (владеет Jira и Trello), и мы решили осмотреться — есть ли на рынке один продукт, достаточно удобный для всех команд, который бы решал в том числе и эти проблемы.
Ключевым фактором отбора для нас стала способность инструмента визуализировать все особенности нашего рабочего процесса as is, без сложных настроек и подгонки своего рабочего процесса под сам инструмент.
Для начала мы попытались перетащить друг друга в Jira и Trello.
Готовы ли менеджеры продуктов полностью переехать в Jira
Работа разработчика гораздо проще укладывается в workflow из Jira, она действительно похожа на конвейер — задача путешествует по окружениям разработки, пока не доходит до продакшна.
Задачи в бэклоге, над которым работает менеджер продукта, всегда очень разные. Некоторые очевидны и требуют просто описать требования. Другие требуют предварительного дизайна. Третьи предполагают предварительные глубокие исследования пользователей.
Работа над четвёртым типом задач не заканчивается в момент, когда она доведена до продакшна — в этот момент начинается её анализ. Наконец, большинство задач сочетает в себе некоторые из этих качеств в произвольном порядке.
Это заставляет менеджера продукта постоянно перестраивать свой рабочий конвейер в поисках оптимального способа управлять задачами так, чтобы все участники понимали, что происходит, просто глядя на доску. И это занимает немало времени.
Jira может дать какую угодно гибкость, но эта гибкость достигается с помощью конфигурирования настроек workflow. Любой, кто настраивал себе workflow в Jira, знает, что это реально, но долго и сложно. В Trello это делается на лету, а любые правила работы с доской проговариваются, а не автоматизируются. Это буквально вынуждает команду чаще обсуждать доску и оперативно менять её правила. И это круто.
Менеджеры продуктов оказались не готовы к переезду в Jira и мы начали искать российский бесплатный аналог.
Готовы ли команды девелоперов переехать полностью в Trello
Trello и доступные к нему интеграции с лихвой покрывают все потребности одной достаточно изолированной девелоперской команды. Он интуитивный, быстрый и понятный. Именно поэтому его у нас выбрали более автономные команды инженеров и QA.
Однако сложности начинаются, когда несколько девелоперских команд работают над одним продуктом, при этом каждая развивает своё измерение бэклога (одни работают над любыми проектами, другие поддерживают внутренний сервис, третьи развивают конкретный блок функциональности).
Именно проблемы комплексных связей решает Jira, где можно собрать любое представление задач в виде доски, используя ярлыки (labels). В Trello по ярлыкам можно делать только фильтрацию. Сделать удобную визуализацию больших проектов не получилось.
Команды девелоперов оказались не готовы к переезду в Trello. Решили искать бесплатный аналог от российских разработчиков.
Хотите построить управляемый
процесс в своей команде?
Решением для нас стал российской продукт Kaiten, в центре которого находится канбан-метод
Во-первых, Kaiten позволяет видеть сразу несколько досок, которые работают по разным принципам в одном пространстве. Это даёт возможность визуализировать процесс практически любой сложности в одном месте — без необходимости переходить куда-то, чтобы увидеть всю картину.
Подобная визуальная гибкость есть у обычной офлайновой пробковой доски, но Kaiten обладает и классическими трекинговыми функциями (статусы, дочерние задачи, оценки, сроки, описания), без которых работать над большим проектом очень трудно.
Все видят однозначную и понятную картину того, как устроен процесс. При этом, если мы захотим изменить его, нам достаточно создать ещё одну доску в этом же пространстве и перетащить туда, куда нужно.
Во-вторых, Kaiten позволяет вкладывать пространства друг в друга. Именно эта функциональность позволила визуально представить весь рабочий процесс от customer development идеи, через продакшн и до пост-продакшн-аналитики.
В-третьих, Kaiten позволяет иметь в своём пространстве чужие доски в актуальном состоянии (считай — рабочие процессы). Если вам нужно быть в курсе того, как идёт работа над связанным проектом, вам не нужно никуда переходить — вы просто добавляете чужую доску себе в пространство и можете работать с ней так же, как если бы она была вашей.
В-четвёртых, Kaiten позволяет на полную катушку использовать приёмы канбан-метода. Выставлять лимиты work in progress, подсвечивать заблокированные карточки, выставлять политики для колонок и дорожек, анализировать время доведения карточек до статуса «Готово». При этом Kaiten не вынуждает вас подстраивать свой процесс под свою модель — вы адаптируете Kaiten под свой процесс.
Отдельно скажу, что в моём опыте не было более безболезненного перехода команды из семидесяти человек на новый инструмент для управления проектами. Мы выбрали по канбан-евангелисту из каждой команды и перетащили задачи, а в день Х просто увидели привычные сущности в привычном процессе в новом инструменте.
Есть и минусы — быстродействие приложения при большом количестве досок и карточек в пространстве. Здесь разработчикам ещё есть над чем поработать. Не вызывает восторга и дизайн — он далёк от высоких потребительских свойств того жe Trello.
В прошлом не было смысла хорошо оформлять карточки, ведь приходилось делать тройную работу, переводя их из одной системы в другую, информация постоянно терялась. Сейчас мы видим, что люди инвестируют время в поддержание хорошего качества описаний и проставление связей между карточками, потому что это начало приносить участникам процесса ценность.
А это приводит к тому, что мы можем наконец начинать доверять нашим доскам и полагаться на них, принимая решения без необходимости уточнять друг у друга: «А эта задача точно сейчас на регрессионном тестировании?»
Мы в «Додо Пицце» работаем на Kaiten уже больше двух месяцев. Инструмент, на наш взгляд, представляет очень эффективную альтернативу связки Trello и Jira.
Если хотите рассказать о своем кейсе, управленческом опыте или стать соавтором статьи, напишите нашему редактору d.lebedeva@kaiten.io
Интересные статьи
Viacheslav Tsyrulnik
Viacheslav Tsyrulnik
Прогрессивные компании уже управляют своими проектами в Kaiten. Присоединяйтесь к лучшим.
