Моя первоначальная реакция на такие перемены была отнюдь не положительной. Проблема заключалась не в самом Trello, а в том, как мы им пользовались. Trello – это ОЧЕНЬ открытый проект. Не существует единственного “правильного” способа работы в Trello, поэтому, чтобы чувствовать себя в нем как дома, вам потребуется время для настройки «под себя».
Однако прежде чем мы детально рассмотрим функции всех наших досок, давайте поговорим о «кровяных тельцах» в нашей «кровеносной системе» разработки: о карточках Trello.
Каждая карточка представляет собой одну из пользовательских историй. Это может быть улучшение, задача для переработки либо баг.
Карточки с улучшениями возникают как простая идея, длиной в 1-2 предложения. Однако перед тем как их можно будет отправить в разработку, они увеличиваются в объеме и теперь включают ссылку на Google Doc с детально расписанной спецификацией, набором схем интерфейса (wireframe) или грубых макетов.
Мы используем понятие «спецификация» (spec) в достаточно широком смысле. Это не те спецификации, которые приходят вам на ум, когда вы вспоминаете работу над курсовой в универе или работу в той дрянной консалтинговой компании сразу после его окончания. В нашем случае спецификации подробно раскрывают пользовательскую историю: почему (с точки зрения бизнеса) мы за неё берёмся, чего мы надеемся добиться, и, по возможности, включают некоторые заметки на тему её предполагаемой реализации (хотя этот пункт остаётся на усмотрение разработчиков; он может помочь, но не является обязательным). Хорошие спецификации также содержат ссылку на первоисточник и на связанную идею на нашем форуме UserVoice.
Если карточка описывает баг, то в ней содержатся шаги, помогающие его воспроизвести (хорошо, если добавлен ещё и скринкаст), и ссылка на тикет в UserVoice Helpdesk , где данный баг был изначально описан.
Доска Current Development – это доска, на которой «творится история». На ней расположены следующие колонки:
Доска «Планирование» – это доска, на которой я вместе с нашими PM’ом и руководителем по UX проводим большую часть времени. Она включает следующие колонки:
Утро понедельника – совещание по продукту (30 минут)
Эти импровизированные обсуждения вопросов дизайна обычно проводятся ближе к концу недели (четверг/пятница), когда становится ясно, что существуют разные мнения касательно карточек, над которыми мы работали всю неделю. Для меня это одни из наиболее продуктивных и интересных совещаний из тех, что мы проводим. Внешне они могут показаться малопродуктивными, так как часто после обсуждения мы возвращаемся к тому, с чего начали. Но на самом деле это признак того, что мы действительно хорошо осознаём все плюсы и минусы выбранного нами пути: мы принимаем решение осознанно, а не вслепую и второпях.
Единый список задач по приоритетам для рабочей группы
Первоначально у нас были колонки карточек, расположенных по приоритету, для каждой отдельной области применения продукта (admin-консоль, виджеты , iOS , веб-портал, электронная почта). Это могло бы сработать, если бы у нас были отдельные рабочие группы для каждой подсистемы, но их у нас нет. Привело это лишь к путанице по поводу того, какая же задача действительно должна быть следующей. Также было крайне неудобно определять и следить за тем, над чем именно команда работает в данный момент. (Совет: если вы замечаете, что часто используете горизонтальный скроллбар Trello, значит, вы что-то делаете неправильно).
Не используйте отдельную систему для багов
Первоначально мы оставили в работе наш предыдущий баг-трекер, а Trello стали использовать для разработки новых функций. Это вызвало проблемы по тем же причинам, по которым не сработало большое количество колонок: как только мы начинали использовать больше одого списка, любое распределение по приоритетам переставало работать.
Ограничьте количество времени на решение проблем с багами
Мы добились этого, установив лимит на количество багов, которые еженедельно можно добавлять в колонку Next Up. Вначале такое решение приняли немного неоднозначно, однако в дальнейшем оно помогло предотвратить кучу споров на тему, стоит ли рассматривать тот или иной баг. Теперь команда по работе с клиентами наделена правом (а может, обременена) выбора стоящих карточек. Это своеобразная версия «Голодных игр» в сфере разработки.
Добавляйте и сортируйте карточки в колонке Next Up только 1 раз в неделю
Это поможет не превратить список Next Up в постоянно растущую песчаную дюну. После того как в понедельник утром представлены новые проекты, вы точно знаете, на каком месте в очереди они будут находиться всю оставшуюся неделю. Вам не нужно беспокоиться о том, что проект, которым вы хотели заняться, окажется в конце очереди (и вы не сможете осуществить задуманное) посередине недели.
Хорошие спецификации скорее рассказывают историю, чем являются пошаговым рецептом
Чтобы все работали над проектом с полной отдачей, они должны чётко понимать, зачем это делают. Поэтому так важно разъяснить проблемы пользователей (или бизнеса) разработчику, которому предстоит их решать.
Не пытайтесь делать предварительную оценку сроков проекта
Раньше, когда мы работали спринтами, мы тратили ОЧЕНЬ много времени (почти целый день на 2-хнедельный спринт) на предварительную оценку и планирование в тщетных попытках провести черту и сказать: «Мы разберёмся вот с этими карточками в течение двух ближайших недель». Мы проделывали большую работу и все равно почти всегда ошибались, поэтому мы перестали бороться с неопределённостью.
Старайтесь отмечать свои успехи
Важно понимать, что несделанная работа есть всегда. Каждую неделю мы создаем отдельную колонку для карточек, которые запускаются в эксплуатацию, чтобы было понятно, чего мы достигли на этой неделе. Также мы используем фотографии всех, кто успешно завершил выполнение задачи, на наших совещаниях по понедельникам.
Добавить метки
Обожаю Трелло. Уже на протяжении пары лет, я использую его каждый день. Это сервис организации коллективной работы. Причем необязательно коллективной. И не обязательной работы.
Чтобы вы сразу все поняли, вот для чего предлагают использовать Трелло его разработчики:
В основе Трелло лежит система Канбан , которая в реальном мире выглядит вот так:
До того как я начну о ней рассказывать, хочу успокоить вас, что у этого сервиса есть как и вебверсия, так и отдельная программа для Windows 8, приложения под iOS и Android и расширение для Хрома (которое позволяет выводить уведомление прямо на вашем рабочем столе): https://trello.com/platforms
Есть не официальные для других браузеров, поищите сами если нужно(набрав trello и название браузера).
Первое, что вам нужно знать о Трелло, это из чего он состоит:
У нас есть 2 доски:
Все новые задания, если они не срочные, добавляются в “Будущую” доску. А потом, когда приходит время, или кончаются задачи, переносятся в “Текущую” доску.
Это не совсем тот способ организации, для которого придумывался Трелло, но мне нравится. Поэтому не важно как вы будете использовать этот инструмент, главное чтобы нравилось вам:)
На данном этапе развития Трелло, мягко говоря, платить там не за что, нет ничего особо интересного и помогающего работе. Увы.
Если вы получите бесплатный Голд аккаунты через приглашения друзей или сотрудников, то потом зайдите на главную страницу(trello.com) и там сверху будет вот такой блок:
Жмите там зеленую кнопку и вы перейдете на тариф Gold. После нажатия вы увидите еще более здоровый блок с описание того, что вам добавилось. Внизу него будет ссылка для закрытия:
Если будет еще что-то говорить, просто ищите ссылку со словом “close” и жмите. Отключить его можно будет на вкладке “Billing” в настройках вашего профиля.
Как мы используем Trello и Google Docs, чтобы постоянно улучшать работу UserVoice:
http://habrahabr.ru/post/171503/
Возможно вас заинтересует раздел “Автоматизация работы” вот в этой статье:
Управление проектами в веб-студии должно быть централизованным, но хорошо сказать, а сложно сделать. Особенно если компания имеет удаленных сотрудников, которые должны быть на связи так же, как и их коллеги в штате - на протяжении всего рабочего дня.
На данный момент на рынке TaskManager/CRM очень много разных предложений, но не все они подходят для управления проектами в веб-студии.
Веб-студия «Магвай» работает с 2009 года. За это время мы пробовали много разных систем для ведения проектов и только недавно нашли для себя идеальную программную связку. Но, вернемся к началу.
В начале 2009 года мы вели проекты с помощью форума на PhpBB. Сейчас это звучит смешно и нелепо, но тогда казалось, что ничего удобнее и быть не может. Туда же заносились данные по документообороту и потенциальным сделкам.
Этого «разнообразия» нам хватило на пару лет, а затем в 2011 году мы нашли TaskManager, заточенный под бизнес веб-студии и это был «Мегаплан». В тот момент нашей радости не было предела – клевый интерфейс, с продуманным юзабилити, и весьма удобная начинка. Но скоро наш энтузиазм быстро прошел. Система на тот момент была еще довольно «сырой», функциональность хромала. Было неудобно заносить потенциальные сделки, хранить файлы, ставить задачи. Раздражали слишком отвлекающие элементы, ненужные кнопки, фишки; например, при постановке задачи кнопки окружали форму создания аж с 4-х сторон. Бизнес-процессы было сложно настроить, возможно, для некоторых и вовсе не было подобного функционала. Сейчас, судя по отзывам, «Мегаплан» уже продуманная, функциональная и удобная штука. В 2011-2013 годах это было не совсем так, но за неимением лучшего, мы продолжали работать с «Мегапланом».
В то время также рассматривали и зарубежные аналоги – Basecampи Jira, но англоязычный интерфейс отталкивал, а на освоение многих функций требовалось больше времени, чем мы могли и хотели выделять.
А затем в 2013 году мы открыли для себя Битрикс 24, на котором работаем и по сей день. Это неидеальный продукт, но для начала он был функциональнее и удобнее «Мегаплана». Мы перешли на него почти безболезненно, с переносом и сохранением данных. Данные переносили не сразу, а только когда 1С-Битрикс купили долю в Мегаплане – появилась удобная интеграция данных из Мегаплан в Б24, чем мы успешно и воспользовались.
На сегодняшний момент мы пользуемся Б24, как системой управления проектами, уже 5 лет. Но при этом, это не единственная система, которая помогает нам в работе.
Мы в студии «Магвай» непрерывно ищем наиболее удобные программные связки для того, чтобы сделать бизнес-процессы максимально удобными и логичными для нас.
На сегодняшний момент связка Битрикс24 + Trello + AmоCRM для нас удобна и закрывает все процессы, начиная с продаж, продолжая планированием задач, и заканчивая самой разработкой.
Битрикс24 имеет достаточно обширный функционал, но есть некоторые нюансы, которые являются для нас не совсем удобными, и есть функционал, которого нам порой не хватает в работе.
Например, очень не хватает приоритетов, которые можно присваивать задачам, выстраивая очередность. Да и сама очередность задач в Битрикс24 не так удобна для нас: каждый раз нужно задавать сортировку. Общая картина – кто и что делает, сколько задач в дизайне, сколько задач у технической поддержки – прослеживается в Битрикс24 с трудом. Последнее – особенно важно, ведь необходимо, чтобы руководители всех звеньев видели занятость специалистов на данный момент, очередь из будущих задач, приоритеты. Только так можно понимать загруженность студии, возможность взять новый проект или выделить время на разработку собственного продукта студии.
Со стороны Исполнителей также есть определенные трудности. Исполнитель видит 100500 различных задач, и, хоть они и объединены по группам, «портянка» от этого меньше не становится. С другой стороны, функционал постановки задач, контроль их выполнения, общение в чате Б24 нас полностью устраивают. Как с этим быть? - Мы нашли решение в виде Trello.
Trello, по сути, обычная канбан-доска, которых существует великое множество, в том же Б24 есть некая встроенная функция доски задач, есть неплохое платное решение от Сибирикс. Но Trello, по нашему мнению, имеет ряд преимуществ:
1. Не нужно платить деньги. Точнее, вы можете приобрести подписку на расширенный функционал, но и того, что предлагают бесплатно, вполне хватает;
2. Простота и интуитивность интерфейса.
3. Кастомизация под нужды команды. Мы создаем только те доски, которые нужны, настраиваем свои списки задач в каждой доске, управляем уровнями доступа к каждой доске, сами настраиваем и присваиваем маркеры к каждой карточке.
Таким образом, все задачи обязательно ставятся в Б24 и дублируются в Trelloв виде карточек с кратким описанием и ссылкой на задачу. Мы видим, сколько задач и на каком исполнителе сейчас, какая очередность у задач и какие статусы (например «сделать срочно» или «баг после тестирования»).
Перед тем, как мы начали использовать Trello, у нас было несколько магнитных досок, на которых мы планировали работы и следили за приоритетом задач. Многие наши коллеги пользуются стикерами, в общем, каждый выкручивается как может. Но сейчас мы совсем отказались от физических носителей для планирования задач.
С течением времени мы разработали удобную систему, при которой на доске было отражено все, что нужно для комфортного ведения проектов, но оставалась проблема – как это сделать более мобильным, как эту доску показать всем сотрудникам (в том числе и тем, кто находится вне офиса на данный момент).
Мы пробовали множество разных вариантов, но именно сервис Trello позволил нам перенести всю наработанную систему магнитных досок в электронный вид, при этом только улучшив коммуникации в процессах.
Еще важный момент, которого нам недостает в Б24 – это база потенциальных сделок, контроль работ по ним для отдела продаж. И снова, этот функционал есть в Б24, но нас он категорически не устраивает. Есть ощущение, что его делали технари, без поправки на нужды маркетологов и продажников – настолько, на наш взгляд, там неудобный интерфейс. Поэтому мы не используем встроенный в Б24 механизм CRM, заменяя его еще одним сторонним сервисом AmoCRM.
Если говорить об AmoCRM, то открытие этого сервиса быстро и четко расставило все точки над «И» в секторе продаж студии.
В Amo мы работаем с 2016 года и это настолько приятно и удобно, что прямо проецируется на довольных лицах специалистов отдела продаж.
Система выстроена настолько просто, что освоение ее функций происходит интуитивно. AmoCRM позволяет вести учет всех потенциальных клиентов, просматривать их на общей «доске», прикреплять различные стикеры-этапы (которые, кстати, можно создавать самому) и ставить задачи внутри сделки.
Отдельно можно рассказать о том, что Amo – это удобный справочник всех контактов, которые взаимодействовали с нашей студией во время продажи проектов. Это позволяет хранить всю информацию о Заказчике в одном месте, а не создавать для этого горы архивов. К тому же с данной системой легко осуществлять вторичные сделки, когда клиент возвращается в студию, или когда мы снова «напоминаем» о себе по прошествии времени.
Все компании стремятся улучшить свою бизнес-логику и в целом оптимизировать подход к работе, чтобы увеличить эффективность.
Мы, исследовав многие сервисы за долгое время работы студии, нашли и используем максимально удобную для нас программную связку Битрикс24 + Trello + AmоCRM.
Но нет предела совершенству, мы с интересом смотрим на рынок TASKManager/CRM и с удовольствием тестируем что-то новое. Например, для почасовой технической поддержки и для постоянной работы с зарубежными заказчиками уже применяем Slack. Потому что мы всегда стараемся гибко адаптироваться к новым обстоятельствам на рынке веб-разработки или к изменениям внутри студии.
Но на данном этапе мы говорим о том, что действительно работает, о своем непростом опыте, и надеемся, что наш подход будет полезен и интересен кому-то, кто так же как и мы ищет советы по улучшению комфортного ведения своего бизнеса в сфере digital.
Александр Крутько, CEO в io media , поделился полезным опытом своей работы с Trello. Вот как вы можете облегчить и структурировать свою жизнь, когда задачи сыпятся одна за другой.
Trello - это онлайн-доска, которая используется для ведения задач в производственной воронке.
Наша воронка содержит следующие статусы:
Срок - когда задача должна быть сделана,
Количество задач по проекту - да, внутри каждой карточки может быть адский список из пунктов,
Приоритет - есть задачи, которые нужно сделать в течение 1 часа.
В общем, представьте себе систему, которую вы используете. И неожиданно вам в голову приходит идея или пожелание (хуже, если вы находите баг). Вы открываете онлайн-чат, пишите менеджеру свой запрос, вам отписывают стандартный ответ в стиле «спасибо, разберемся». И вы думаете про то, что отправили свои мысли в никуда, хотя продолжаете мечтать про новое обновление (или про исправленный баг). Но, внезапно для вас, через 1-2 дня вам отвечают: «Готово, заходите - смотрите». Да, идеальный мир существует!
Короче, наш экран задач не бывает пустым, сегодня мы разобрали почти всю очередь. Но бывало в нашей жизни и так:
Как видите, мы используем классическую в проектном менеджменте схему. Но дальше - больше.
Trello известен своей простотой, и любой необходимый для работы хак нужно искать на стороне - в плагинах или интеграциях с их API . Мы же столкнулись с пулом задач, решения для которых создавались нами самостоятельно:
Когда на сайте нашего клиента появляется код для трекинга, карточка в Trello появляется автоматически - для этого мы используем API Trello и собственного бота - он проверяет появление данных с сайта клиента, которому был отправлен код для установки и который ранее нами не отслеживался.
Новая задача - это зеленая карточка, к которой автоматически крепится менеджер и разработчик, добавляется дата (+1 день к текущей дате) и приоритет (важнее остальных).
На выходе: у разработчика в пуле появляется заказ на проект, который нужно приготовить максимально оперативно. И разработчик, при фильтрации по себе, будет видеть именно свой стол заказов:
Эх, не успел заскринить задачу в плане Джона, так как она уже в работе:
Да, наши боты справляются не всегда, и мы всегда готовы им помочь.
Когда задача реализована и разработчик хотел бы ее протестировать, карточку с проектом переносят в список «Need to test». В этом списке за нее отвечает менеджер и принимает задачу с точки зрения клиента:
Если все действительно сделано правильно, то он переносит задачу в Done, как бы оставляя просьбу на выкатку решения. На данном этапе ответственность человека заканчивается.
В этот момент просыпается еще один бот, разбуженный появлением новой карточки в своем логове. Он использует наше API и по названию проекта находит настройки этого проекта в коде и выкатывает свежие обновления на живой сайт. И да, еще один бот собирает письмо для клиента о том, что в его проекте были сделанные ранее согласованные изменения.
Информацию про клиента он находит в нашей админке, где по названию проекта можно найти пользователей этого проекта и кто из них является администратором. Кстати, теперь, кажется, стало понятно, почему в названии задачи мы используем имя сайта, а не тайтл самой задачи.
На последнем этапе бот архивирует карточку, и она пропадает с доски.
Да, у Trello просто нет аналитики. Даже больше - он под это не заточен, так как не рассматривает задачу, отправленную в архив, как сделанную.
А поскольку мы работаем с цифрами, и нам важно любой процесс измерять, нам было критично увидеть такие цифры:
Какое количество проектов попадает в план, и сколько из них мы реализуем,
Сколько времени мы тратим на выполнение задач, особенно по типам - зеленые, желтые или красные,
Кто из разработчиков сколько делает задач и как быстро.
В общем, все перечисленные вопросы - мелочи по сравнению с главным для нас вызовом: наш клиент должен получать решение в течение 1 дня. И любые препятствия на пути - менеджеры или разработчики, размер очереди задач или снижение скорости реакции - должны быть обнаружены раньше, чем они начнут влиять на конечный результат.
Для измерения Trello мы использовали следующие инструменты:
Google Spreadsheet
Как видите, Trello нашел отличное применение для решения поставленных целей. Да, бывали моменты, когда хотелось уйти, попрощаться, взять платные инструменты для ведения workflow и утонуть в их функционале, благо на рынке их уйма.
Но оказалось, что для решений, которые в Trello отсутствуют, можно найти собственные. А простая канбан-доска, придуманная для использования на заводах, может быть применима для ведения современных b2b проектов. Особенно когда постановщиками задач являются тысячи клиентов.
Я не буду рассказывать основы трелло, сразу прыгну к интересной части.
Мы проводим множество проектов одновременно, поэтому настроили огромную структуру досок и переплели их между собой. В целом наша компания выглядит так:
Зеленые карточки – активные проекты. Фиолетовые и с картинками – департаменты (об этом будем говорить во второй статье). Красные – подготовленные пресеты для новых досок.
Ключевой доской для с проектами является Projects Pipeline:
В ней можно найти и посмотреть статус любого проекта. Глянуть быструю информацию о проекте и перейти в саму доску с проектом.
Сам жизненный цикл проекта состоит из таких шагов:
В этом листе находятся все заиницированные проекты. По ним узнается бриф и происходит вся подготовительная работа перед подписанием контракта.
Ожидает подписания контракта.
Проекты, которые находятся на стадии разработки дизайна.
А здесь на этапе разработки анимации.
Ну а здесь кода. При чем сами мы не пишем код, этим занимаются наши партнеры, или фрилансеры.
Все проекты, которые готовятся к релизу/запуску.
На рассмотрении заказчика. Обычно после этого момента проекты возвращаются в предыдущие листы с комментариями заказчика.
Проекты, которые ожидают оплаты за проделанные услуги.
Завершено с успехом. Те проекты, которые завершились с успехом и получили полную оплату.
А здесь находятся проваленные проекты. Здесь обязательно пишется причина провала, чтобы больше такого не повторилось.
Как видно на скриншоте выше, карточка содержит в себе небольшую информацию о статусе проекта и ссылку на доску. И да, на ней стоит due date. Это первый ключевой дедлайн по проекту. Чтобы можно было сразу увидеть когда сдача проекта.
Давайте нырнем в какой-то проект и посмотрим как он устроен изнутри:
Опять же опишу списки по порядку:
Здесь собрана вся основная информация о проекте: как пользоваться этой доской, общее описание проекта, ссылка на проект на Google Drive и какие-то вводные важные комментарии от клиента.
В этом листе обычно собирается вся информация после Research’a, или какие-то другие интересные заметки.
Это очень важный список. В нем находится все напряженности проекта. Напряженности – это то, что нужно сделать к определенному сроку.
Любые идеи, которые могут возникнуть у участников проекта.
Огромный список вещей, которые необходимо сделать для завершения данного проекта.
Список того, что нужно закончить за (3 дня, неделю, 2 недели, месяц). Срок выставляется на первом совещании по поводу этого проекта.
Список задач, которые были начаты, но не закончены, и в данный момент находятся в процессе. Обычно эти задачи уже за кем-то закреплены.
Список задач, которые выполняются конкретно в данный момент. Это нужно для того, чтобы не было конфликтов между участниками. Этот лист позволяет урезать “убытки” времени на производстве. К примеру, зайдя в какой-то проект, я сразу вижу его статус и мне нет необходимости связываться с кем-то и отвлекать кого-то.
Список того, что должно быть рассмотрено лидером проекта.
Список завершенных задач.
В своей работе мы используем все самое лучшее, что только смогли собрать из разных методологий ведения проектов. И мы постоянно улучшаем это знание и механизмы работы.
Поэтому в нашей методологии ведения проектов можно найти элементы Kanban, Scrum и других.
На этом я закончу первую статью из цикла. В следующих статьях планирую рассказать, как происходит непосредственный процесс работы над проектом от а до я.
Всем спасибо, всем удачи.