Дисклеймер: эта специализированная статья предназначена для продуктовых менеджеров и энтузиастов product / project management tooling и продуктовых методологий.
Перевод статьи подготовлен редакцией итеративно-функционального метода, новейшей альтернативы Agile и Kanban.
Джейсон Фрайд (Jason Fried), CEO компании 37signals — создателей Basecamp и HEY — недавно опубликовал в своих запрещенных в России соцсетях два демо видео нового продукта Fizzy, который представляет собой новый взгляд на трекер идей, задач и багов. Представление задач реализовано в виде коллекции (аналог доски в Канбане) с двумя колонками — «В рассмотрении» (“Considering”) и «В работе» (“Doing”). Карточки в обеих колонках содержат заголовок, имя автора карточки и исполнителя, а также информацию о дате создания и последнего обновления. В колонке «В работе» есть переключатель стадий («Изучение», «В процессе», «Блокировано»). Последовательность стадий определяется одним из выбранных рабочих процессов (workflow), который настраивается в параметрах коллекции. В зависимости от выбранной стадии меняется цветовая схема карточки. Завершённые карточки отправляются в подвал страницы, где каждая карточка проштампована большой печатью с причиной закрытия.
Прежде всего хочу подчеркнуть, что с большим уважением отношусь к Джейсону Фрайду и СТО 37signals Дэвиду Хайнемайеру Ханссону (DHH) и к их работе. В эпоху бездушных аджилистских монстров вроде Jira, ClickUp, Asana и десятков их безликих клонов, Джейсон и Давид создали оригинальный подход под названием Shape Up, который во многих аспектах лучше адаптирован под современную разработку для мобильных и веб-платформ, чем Agile, Scrum, SAFe и иже с ними.
Тем не менее, создание софта со встроенной жесткой методологией одновременно сужает потенциальную аудиторию и формирует более восприимчивую к экспериментам пользовательскую базу. Fizzy — смелый эксперимент, и его последствия могут оказаться гораздо масштабнее, чем кажется. Причина в том, что Fizzy — первая попытка крупной компании оторваться от принципов Канбана. В современном мире каждый инструмент управления проектами и продуктами построен вокруг Канбан-доски. Да, можно встретить всевозможные списки, диаграммы Ганта, таймлайны, чаты — но главный инструмент, с которым работают 100% разработчиков ежедневно, — это Канбан-доска. Именно она, со своими колонками и карточками, формирует наше восприятие работы, модели коммуникации, принципы декомпозиции, понимание завершённости задач и психологию рабочего процесса в целом.
Если эксперимент с Fizzy провалится, другие игроки могут сделать вывод, что Канбан — непобедим, и его нечем заменить. Это может надолго затормозить эволюцию инструментов управления продуктами. Как автор итеративно-функционального метода, который предназначен для полной замены Канбан-досок, я лично заинтересован в успехе Fizzy, поскольку он может легитимизировать альтернативные подходы в глазах сообщества.
Манифест Agile был написан в 2001 году. Первая книга, в которой принципы Toyota Production System (т.е. Канбана) были перенесены в разработку ПО, вышла в 2002. Канбан-доски (тогда их называли Agile-досками) появились в Jira около 2012 года. Отказ от Канбана не произойдёт за одну ночь — это займёт годы. Но первые шаги — самые важные.
Вот почему нам, сообществу разработчиков, важно проанализировать сильные и слабые стороны Fizzy до того, как продукт будет в публичном доступе. Я начну с самых очевидных моментов, но не обойду вниманием и технические детали.
В своём демо Джейсон справедливо отметил, что длинные бэклоги вредны: они собирают пыль и устаревшую информацию. Внутри команды их так и называют — «badlogs». В Fizzy встроено решение: если карточка не обновляется определённое число дней, она автоматически закрывается. Но это принудительная чистка не решает настоящую причину, по которой людям нужен бэклог. Этих причин две.
Первая – продактам нужно место, где можно подготовить спецификации. Они понимают, что потом эти спеки превратятся в задачи, и не хотят писать сначала документ, а затем дробить его на тикеты — двойная работа, если только это не абсолютно необходимо по правилам компании. В корпоративной среде ситуация, когда фича «зависает» по внешним причинам, — норма. Это не зависит от людей, которые будут двигать карточки в Fizzy. Через два месяца всё может «разморозиться», и никто не хочет терять уже подготовленные карточки, в которые вложено время и усилия. Это приведёт к тому, что каждые 30 дней придётся бампать карточку бессмысленным комментарием, чтобы она не исчезла. Так главная фича Fizzy превращается не просто в бесполезную, а в вызывающую стресс — из-за обратного отсчёта дней возле карточки. А если вас раздражает ключевая фича продукта — как вы будете относиться к продукту в целом?
Вторая причина, по которой люди хотят бэклог — это мелкие задачи и баги, формирующие технический долг. Команда может не иметь ресурсов, чтобы справиться с этим сейчас, но это не отменяет важности таких задач. Они реальны, и их решение улучшит качество и стабильность продукта. Автоматическое удаление карточек в Fizzy предполагает, что если баг важен, его всё равно пересоздадут. В этом есть логика, но она разрушительна в двух аспектах: 1) обесценивается работа по логированию бага, описанию шагов воспроизведения и контекста проблемы; 2) создаётся атмосфера, культура работы, в которой люди знают, что мелкие баги игнорируются. В результате — снова бамп карточек каждые 30 дней, чтобы они не исчезли. Так и формируется тот самый длинный список, от которого Fizzy пытается избавиться.
Полный отказ от Канбана может быть слишком большой просьбой к пользователям, если Канбан это всё, что знали эти пользователи. Fizzy в этом плане не уходит от Канбана, а лишь выворачивает наизнанку, делая эволюционный шаг, но в итоге борется с энтропией Канбана своей собственной, новой энтропией.
Кроме колонок и drag-and-drop, Fizzy унаследовал теги и комментарии. Да, вы правы — все конкурентные платформы их имеют. Но если мы всерьёз хотим уйти от Канбана, стоит задать себе вопрос: зачем они вообще нужны?
Теги появились по тем же причинам, что и поиск. Бэклог, сама доска и «афтерлог» — то есть место, куда попадают завершённые карточки, — это три по определению неструктурированные кучи (heap) информации. Чтобы найти что-то в этих кучах, нужен длинный, как игла, и точный поисковый запрос. Теги — это заранее подготовленные иглы. Но в итоге они — ещё один источник энтропии. Посмотрите на список тегов в демо Fizzy — он уже длинный. А разве мы не хотели избавиться от длинных списков? Пусть это техническая деталь, но она влияет на восприятие рабочего процесса.
Третий всадник энтропии Канбана после собственно доски и тегов — это комментарии. У комментария обычно есть две главные цели: 1) детализированный апдейт статуса тикета; 2) обсуждение деталей имплементации и блокеров. Но эта информация не обязательно должна быть в виде текстового потока, который нужно читать от начала до конца, иначе вы рискуете упустить потенциально важный контекст. Так уж повелось исторически — и всех устраивает статус кво. Комментарии — это «сырой» процесс в виде белого шума. А людям, работающим с тикетами, нужен результат: статус и принятое решение, а не вся история принятия этого решения. Признание этой логики позволит переосмыслить интерфейс экрана карточки.
Современная жизнь и работа перегружены информацией. Нам нужны жёсткие границы, которые помогут людям сосредоточиться на важном. В этом плане Fizzy делает большой шаг вперёд — и несколько шагов назад. Пример: две независимые очереди поп-ап уведомлений вместо одной. Уведомления — третий, инвертированный способ получить важную информацию из дезорганизованной кучи.
Последняя деталь в Fizzy, унаследованная от Канбана — это блок с метаданными, который занимает примерно 25% карточки в списке: кто создал, когда, кому назначено и когда обновлялось. На мой взгляд, всё кроме исполнителя — белый шум, актуальный только для функции принудительного закрытия карточки. Кого волнует, кто и когда создал баг или фичу? Её надо сделать или пофиксить — и всё. Что меняет то, что карточку обновили шесть или три дня назад? Это только занимает место и заставляет пользователя дольше скроллить лист карточек.
Если промотать экран Fizzy вниз до конца, можно увидеть колонку «Недавно закрытые» — это хорошая попытка заполнить пустоту функционала обычной канбан-доски, потому что в канбане тикеты просто уходят в небытие. Однако новая колонка – всё ещё дезорганизованная куча информации. Причина закрытия в виде большого штампа — разновидность тега — не несёт никакой пользы. В реальности у людей нет повода искать: «все завершённые» или «все дубликаты». Это снова белый шум.
Несомненно, Fizzy — шаг вперёд в управлении продуктами. Но в текущем виде она унаследовала многие наследственные болезни Канбана. Главный риск, который допускают 37signals — это пересекающееся позиционирование Fizzy относительно их флагманского продукта Basecamp. Когда Джейсон выложил первое демо, многие люди спрашивали, как эти продукты будут сосуществовать, ведь оба нужны для учёта задач и багов, и в целом делают одно и то же, но по разному. Джейсон ответил, что Fizzy — для тех, кто по каким-то причинам не может использовать Basecamp. Но такой ответ не удовлетворителен. Basecamp — универсальный инструмент. Нет ничего, чего не может Basecamp, но может Fizzy. Сейчас Fizzy — это иной, оригинальный способ делать Канбан. А значит, схожесть двух продуктов будет либо: 1) тормозить распространение Fizzy среди новых пользователей и клиентов Basecamp, либо 2) каннибализировать рынок Basecamp без очевидной финансовой выгоды, особенно учитывая, что по словам Джейсона Fizzy будет дешевле.
С другой стороны, если бы 37signals и захотели внедрить метод, полностью отрицающий Канбан, это тоже вызвало бы путаницу у клиентов. Нельзя внедрить две взаимоисключающие методологии — и Канбан, и что-то ещё. Придётся сделать выбор. Путь к прогрессу тернист. Нам всем нужно работать вместе, чтобы приблизить будущее управления продуктами.
Комментарий редакции ИФ Метода:
В ответе на эту статью Джейсон Фрайд отметил следующее (далее вольный сокращенный перевод ответа редакции с сохранением смысла).
Джейсон Фрайд
CEO 37signals, создатель Basecamp
Функционал автоматического закрытия карточек может быть отрегулирован и на 7, и на 90 дней, и отключен вовсе, чего мы не рекомендуем делать.
Относительно личности автора карточки – что если баг зафиксировал кто-то важный в корпоративной иерархии? У этой карточки будет больше внимания. Или баг зафиксирован кем-то с хорошей репутацией (solid reputation)? Это скорее сигнал, чем белый шум.
Что касается соотношения Fizzy и Basecamp… Существует множество причин, по которым вы можете использовать Basecamp или Fizzy, либо использовать оба. Я не говорил об этом на демо, потому что слишком рано это делать без демонстрации всего функционала продукта. Я расскажу об этом, когда мы будем ближе к запуску. Действительно Basecamp может быть использован для любых вещей, и Fizzy может заменить ряд кейсов Basecamp, и мы считаем, что это хорошо.
