Инвестирование

Трелло: фишки и основы успешной работы над проектом в японском стиле. Руководство по продуктивной работе в Trello

Всем привет! Сегодня у меня в гостях — моя подруга и коллега Анна Выдыш с полезным опытом — как повысить продуктивность.

Анна Выдыш

Анна — автор программ и методик по упрощению домашнего быта, большой любитель составления списков, своим хобби считает организацию жизни во всех ее проявлениях, начиная с окружающего пространства и заканчивая личным временем. Основатель ресурса “Уютный дом” , на котором совмещает творческую и техническую работу с воспитанием двоих детей и созданием онлайн-курсов.

Передаю слово Анне.

Здравствуйте, меня зовут Анна и я Trello-зависима. Но это, пожалуй, лучшее, что случилось в моей жизни за последний год. Раньше мне приходилось хранить списки рабочих и домашних дел в разных местах: в бумажном виде, сервисах Evernote и Google Keep. Много лет я безрезультатно пыталась навести в этом порядок и однажды наткнулась на Trello.

Зарегистрировалась, не питая каких-то особых иллюзий на то, что этот инструмент надолго задержится в моей жизни и совершенно неожиданно попала в точку. За три дня все мои списки переехали жить в новый домик и я с радостью продолжила эксперименты с оптимизацией повседневных дел на суперудобных досках, что впоследствии вылилось в мини-курс “Живи продуктивней с Trello” .

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

Система №1. Всё на своих местах

Благодаря удобной автоматизации и классификации задач, вы можете не беспокоиться о том, что что-то пропустите. Вам удастся удерживать под контролем даже самые длинные списки дел:

● распределяйте дела по спискам каждое утро, чтобы получить заряд вдохновения и настроиться на продуктивную работу;
● настройте автоматизацию, чтобы синхронизировать вашу почту со списком “Входящие”;
● включите улучшения “Card Snooze” и “Card Repeater”, чтобы сосредоточиться на самом важном и не утонуть в мелочах.

Улучшения, которые вы можете использовать на этой доске:

Automation by Zapier : экономьте время на организации задач, автоматически отправляя электронную почту, события из календаря и сообщения из чата на доску.

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

Card Repeater : автоматически создает определенные карточки через заданный промежуток времени. К примеру, задача “оплатить аренду жилья” может появляться в списке сама в заданную вами дату.

Card Snooze : если кажется, что некоторые задачи не будут решены на этой неделе, отложите их в архив до следующей.

Dropbox и/или Google Drive : добавляйте важные файлы, связанные с задачами и встречами.

Система №2. Приоритизация по матрице Эйзенхауэра

Система, которую использовал президент Соединенных Штатов Дуайт Эйзенхауэр помогает легко распределить дела по степени важности, прибегнув к помощи всего 4 колонок. Подробнее об этой системе вы можете почитать в статье .

● помогает расставить задачи по приоритету выполнения;
● помогает сосредоточиться на долгосрочных целях и не отвлекаться на то что не имеет значения;
● работайте вместе с коллегами и делегируйте неприоритетные задачи, добавляя их на доску вашей команды или копируя доски других команд.

Система №3. Мечтай по-крупному

Продуктивность — это не просто вычеркивание дел из списка, но ещё стремление к росту, поиск возможностей и постановка целей. Доска “Мечтай по-крупному” позволяет объединить крупные сферы вашей жизни (профессиональное развитие, путешествия, хобби) с шагами, которые нужно сделать, чтобы вырасти в этих сферах. Доска предназначена для постановки целей, на ней наглядно представлены все планы, интересы и стимулы:

● разделение по сферам помогает творчески осмыслить самые разные цели и идеи, а также дает возможность увидеть картину целиком;
● добавляйте в свои карточки изображения, ссылки, видео, метки и вложения с помощью улучшений Evernote и Google Drive. Так вы можете дополнить цели заметками и стимулами;
● списки задач помогут составить пошаговый маршрут к цели, а дата выполнения — уложиться в поставленные сроки. Вы также можете делиться досками с коллегами и работать над задачами вместе.

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

P.S. Не знаете, как одним кликом скопировать доску в свой профиль? Я подготовила подробную видео-инструкцию о том, как настроить свою учетную запись и успешно стартовать с Trello.

Чтобы получить доступ к остальным 9 урокам мини-курса «Живи продуктивней с Trello», оформите заказ по этой ссылке .

Кстати, маленький бонус! При заказе курса введите промокод OPTIMIZIRUEM — и получите скидку 10%!

С наилучшими пожеланиями, Анна Выдыш

Моя первоначальная реакция на такие перемены была отнюдь не положительной. Проблема заключалась не в самом Trello, а в том, как мы им пользовались. Trello – это ОЧЕНЬ открытый проект. Не существует единственного “правильного” способа работы в Trello, поэтому, чтобы чувствовать себя в нем как дома, вам потребуется время для настройки «под себя».

Наш процесс

Наш процесс разработки объединяет в себе 6 различных досок Trello. Центральным звеном является доска Current Development («Текущая разработка»). Основной целью других досок является снабжение карточками, которые представляют собой улучшения или баги (см. ниже), доски Current Development, а конкретно ее колонки Next Up («Следующее»). Список Next Up - это наш единственный список, задачи в котором рассортированы по приоритету. Разработчики и проектировщики заглядывают в него, когда они готовы приступить к работе над новой карточкой.

Однако прежде чем мы детально рассмотрим функции всех наших досок, давайте поговорим о «кровяных тельцах» в нашей «кровеносной системе» разработки: о карточках Trello.

Карточки


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

Карточки с улучшениями возникают как простая идея, длиной в 1-2 предложения. Однако перед тем как их можно будет отправить в разработку, они увеличиваются в объеме и теперь включают ссылку на Google Doc с детально расписанной спецификацией, набором схем интерфейса (wireframe) или грубых макетов.

Мы используем понятие «спецификация» (spec) в достаточно широком смысле. Это не те спецификации, которые приходят вам на ум, когда вы вспоминаете работу над курсовой в универе или работу в той дрянной консалтинговой компании сразу после его окончания. В нашем случае спецификации подробно раскрывают пользовательскую историю: почему (с точки зрения бизнеса) мы за неё берёмся, чего мы надеемся добиться, и, по возможности, включают некоторые заметки на тему её предполагаемой реализации (хотя этот пункт остаётся на усмотрение разработчиков; он может помочь, но не является обязательным). Хорошие спецификации также содержат ссылку на первоисточник и на связанную идею на нашем форуме UserVoice.

Если карточка описывает баг, то в ней содержатся шаги, помогающие его воспроизвести (хорошо, если добавлен ещё и скринкаст), и ссылка на тикет в UserVoice Helpdesk , где данный баг был изначально описан.

Наша кухня

Доска Current Development – это доска, на которой «творится история». На ней расположены следующие колонки:

Next Up («Следующее»)
  • Список всех карточек по приоритетам, проверенных и готовых к проектированию и разработке.
  • Стоить заметить, что разработчику или проектировщику не обязательно брать для работы самую первую в списке карточку. Лучше взять верхнюю карточку из тех, с выполнением которых вы точно сможете справиться.
In Progress («В процессе»)
  • Это те карточки, которые находятся в стадии активного проектирования или разработки.
  • Если вы берете карточку, вы прикрепляете к ней свою аватарку, тем самым закрепляя её за собой. У разработчиков есть правило, следуя которому нельзя закреплять за собой одновременно больше двух карточек: один основной проект и один дополнительный.
  • Когда разработчик берёт карточку, он присваивает ей дату выполнения, чтобы остальные были в курсе предполагаемой даты отправки этой карточки в QA. Беглый просмотр нашей доски в Trello показал, что исполнение данного правила оставляет желать лучшего.
QA
  • Когда инженер считает задачу выполненной, карточку проверяют на работоспособность и перемещают её в QA. С этого момента за оценку полученного результата и решение, имеет ли он право на жизнь, отвечают наш QA менеджер и руководитель по UX.
  • Как упоминалось ранее, если карточка представляет собой проект какого-либо крупного улучшения, мы выделяем отдельную доску Trello, посвящённую проблемам, возникающим в процессе тестирования этого проекта. Карточка проекта останется в QA до тех пор, пока все карточки, находящиеся на отдельной доске этого проекта и содержащие в себе его проблемы, не будут решены и удалены.
Launchpad («Стартовая площадка»)
  • Эти карточки прошли проверку в QA и готовы к запуску (однако это не обязательно происходит, об этом позже), и чаще всего включают GitHub Pull Requests, связанные с ними (курировать запрос будет человек, создавший его. Хотя никаких строгих правил нет: курировать запрос может каждый).
  • Если карточка содержит исправление бага или доработку, её запускают в работу немедленно, но не позже 3-ёх часов ночи по тихоокеанскому времени. Если только вы, как разработчик, не хотите провести ближайшие полтора часа за монитором и следить, не возникнет ли каких-нибудь проблем.
  • Если карточка содержит улучшение, оно также будет запущено в работу, но его спрячут от конечных пользователей с помощью “feature flag” (“Feature flag” позволяет включить новую функцию для избранных аккаунтов). Улучшение будет немедленно доступно для нашего собственного аккаунта UserVoice и для всех пользователей с ранним доступом к новым фичам. В иных случаях карточка попадёт в отдел Маркетинга и будет открыта для всех аккаунтов после официального релиза.
Live («Запуск» (Неделя №))
  • Эти карточки уже запущены и больше не скрыты от пользователей под «feature flag».
  • Единственными людьми, которые могут отправить карточку в «Запуск» (по существу это наш список выполненных задач), являются Product Manager (если это улучшение) и Bug Reporter (если это исправление бага). Это помогает убедиться в том, что петля обратной связи завершена, прежде чем мы перестанем следить за карточкой.
  • Каждую неделю в Trello создаётся новая колонка Live, чтобы мы могли отследить, что и когда было запущено.
Кроме всего прочего мы используем три ярлыка, которые можно прикрепить к карточкам:
  • Bug - Баг
  • Staging - Проверка работоспособности
  • Production - Запуск в работу
Довольно просто, правда? Такой подход к разработке очень похож на систему Канбан. Теперь давайте разберемся, как карточки попадают на эту доску.

Мама, а откуда берутся карточки?

Новые карточки могут появляться из 4-ёх различных досок:
Product Roadmap
  • Здесь содержатся все основные проекты на каждый квартал, притом имеется приблизительный план на 3 квартала вперёд. Эти большие проекты перемещаются на доску Planning с началом соответствующего квартала.
Inbox («Поступающие идеи»)
  • Здесь есть две колонки: одна с идеями от членов компании, а другая – с идеями наших пользователей (с привязкой к соответствующим тикетам поддержки на UserVoice Helpdesk и идеям, приходящим на наш форум обратной связи с пользователями UserVoice).
  • Мы просматриваем идеи на этой доске во время нашего еженедельного совещания по обзору входящих идей (см. ниже).
Bugs («Баги»)
На этой доске 3 списка:
  • «Входящие» – это непроверенные сообщения о багах.
  • «Требует дополнения» – здесь находятся баги, с воспроизведением которых у нас возникли проблемы и которые требуют дополнительной информации от человека, сообщившего о баге.
  • «Принято» – да, это, с большой долей вероятности, действительно баг.
  • Если баг попадает в «Принято» и команда по работе с клиентами решает, что этот баг «критический» (вы можете узнать, как мы решаем данный вопрос, прочитав наш пост «Our critical issue escalation process »), то его сразу же перемещают на доску Current Development и срочно связываются с нашим «дежурным разработчиком».
  • Если баг не критический, он остаётся в колонке «Принято» до тех пор, пока глава Отдела по работе с клиентами не переместит его в колонку «Следующая неделя», в которой находятся баги, которые должны быть исправлены на следующей неделе (кэп). Одно условие – он имеет право выбирать не больше 7 багов в неделю. Вы спросите, почему 7? Потому что багов всегда предостаточно, и команда по работе с клиентами всегда хочет исправить все из них, но если мы чему-то и научились, так это необходимости ограничить количество времени, которое можно посвящать устранению (не критических) багов.
Engineering («Разработка»)
  • У нас есть список областей, в которых может потребоваться реструктуризация кода. Каждый список – это отдельная категория (например: Бэкенд, Фронтенд, Тесты, Инфраструктура), а каждая карточка – это отдельный проект по рефакторингу или другой, не относящийся к пользователям напрямую, проект.
  • Разработчики по желанию могут брать карточки с мелкими вопросами и помещать их в In Progress; более крупные карточки следует поместить в колонку Next Up для предварительного планирования.

Кто сказал, что центральное планирование не работает? (доска «Planning»)

Доска «Планирование» – это доска, на которой я вместе с нашими PM’ом и руководителем по UX проводим большую часть времени. Она включает следующие колонки:

Next Up («Следующее»)
  • Список следующих проектов, которые мы хотим запустить в разработку, размещённых по примерному приоритету.
Spec («Спецификации)»
  • Карточка в этом списке означает, что необходимо, чтобы кто-то написал для нее спецификацию. До того как это произойдет, карточка обычно представляет собой просто общую идею.
  • Для написания спецификаций мы используем Google Docs и в значительной мере полагаемся на контекстные комментарии, чтобы обсудить (не организованно, а каждый по отдельности) любые спорные моменты с другими членами команды. Любой достаточно сложный спорный концепт будет детально рассмотрен на импровизированном проектном собрании (подробнее об этом в следующем разделе).
Design («Проектирование»)
  • Карточка в этом списке означает, что необходимо, чтобы на неё взглянул проектировщик. Это не обязательно предполагает создание схемы интерфейса или макета, так как этап проектирования предполагает решение не только вопроса внешнего вида, но и рассмотрение требований приемочных критериев и разрешение вопросов, касающихся принципов проектирования, юзабилити, производственных процессов, а также влияния на существующую функциональность – её фактическая проверка и исправление любых неисправностей до того, как карточка отправится на этап разработки. (Также, если оказывается, что над приемочными критериями карточки необходимо еще поработать, то она снова отправляется в список «Spec»).
Ready («Готово»)
  • Здесь находятся карточки, проверенные инициатором идеи и командой по проектированию. Иногда к ним прилагаются схемы интерфейса или другие необходимые артефакты. Теперь все готово к перемещению в список Next Up на доске Current Development (после обсуждения и проверки на совещании по планированию).
На любой другой доске, кроме Planning, карточки всегда перемещаются исключительно слева направо. Но на этой доске карточки нередко переходят из Design или Ready назад в колонку Spec (иногда неоднократно), прежде чем они, наконец, попадут на доску Current Development.

Наши совещания (или как мы перемещаем карточки из одной доски в другую)

У нас всего несколько еженедельных совещаний:

Утро понедельника – совещание по продукту (30 минут)

  • Присутствующие: все работники компании
  • Всеобщее собрание, которое проводится, чтобы каждый был в курсе того, что происходит, а также для того, чтобы отметить недавние успехи в работе нашей группы разработчиков. Руководит совещанием наш PM, и это единственное из совещаний, для которого обязательно создаётся презентация.
  • Один слайд мы выделяем на обзор исправленных за прошедшую неделю багов, используя при этом аватарки, чтобы показать, кто именно их пофиксил. Всегда испытываешь гордость, когда видишь своё фото рядом с длинным списком исправленных багов.
  • Каждая новая фича помещается на отдельный слайд вместе с аватарками всех людей, вовлечённых в работу над проектом, количеством поинтов а также скриншотом или (чаще) видео. Каждому участвующему в проекте даётся 20-30 секунд на то, чтобы объяснить остальным, что конкретно было сделано.
  • PM или CEO рассказывают обо всех новых проектах, переехавшие в колонку Next Up, и предоставляют более детальную информацию о том, что представляют собой эти новые карточки и почему они являются приоритетными.
Утро пятницы – совещание по обзору входящих идей (30 минут)
  • Присутствующие: PM и Руководитель по UX – обязательно, все остальные – по желанию
  • Если вы добавили карточку на доску Inbox (неважно, в колонку идей пользователей или членов компании), ожидается, что вы посетите это совещание и лично представите историю данной карточки (вы можете прочитать подробности о том, как, с нашей точки зрения, должна работать обратная связь с пользователями). Основная цель – помочь другим членам команды понять ваш кейс. Чтобы убедиться в том, что мы занимаемся рассмотрением наиболее актуальных проблем, мы ограничили число карточек на одного человека до 3-ёх.
  • Секрет того, как на данном совещании придерживаться заданной темы – это обсуждение только самих проблем, а не способов их решения.
Пятница после полудня – совещание по планированию (1 час)
  • Присутствующие: CEO, PM, Руководитель по UX, Ведущий разработчик
  • Цель этого собрания – обзор всех карточек, находящихся на досках Planning и Engineering и готовых к тому, чтобы их переместили в колонку “Next Up” на доске Current Development. Перед перемещением карточки мы должны убедиться, что по ней нет нерешённых вопросов или задач и что мы можем обсудить следующий шаг (к примеру, необходимо ли нам вначале спроектировать прототип?). Как только все карточки из Ready будут перемещены в Next Up, мы заново сортируем все карточки в этой колонке по приоритету (да, даже если карточка была в начале списка на прошлой неделе, на этой она может переместиться в самый его конец).
  • Также мы определяем уровень сложности каждой карточки. Мы оцениваем их как простые (1 звёздочка), средней сложности (2 звёздочки) и сложные (3 звёздочки). Эта оценка основывается на предыдущем опыте (опыте компании, а не отдельных лиц): делали ли мы что-то похожее раньше, насколько мы знакомы с данной сферой деятельности, есть ли у нас свои эксперты в данном вопросе и т.д. Мы используем карточки, чтобы разработчикам было легче понять, насколько они сложны и трудоёмки, а также, чтобы показать важность карточек остальным членам команды во время совещания в понедельник.
  • И, наконец, мы рассматриваем все карточки с багами, которым команда по работе с клиентами выставила статус «Устранить на следующей неделе». Если карточка содержит недостаточно информации или если предположительно она займёт много времени на разработку (больше, чем пару часов), мы не отправляем её в колонку “Next Up”. Все карточки, которые перемещаются в “Next Up”, автоматически попадают в начало очереди. Мы хотим быть уверены в том, что в первую очередь всегда ремонтируем то, что сломано.
Каждое утро – Стендап (10 минут)
  • Присутствующие: все члены рабочей группы (проектировщики, разработчики и QA)
  • В Skype (у нас два офиса) по понедельникам, средам и пятницам, и с помощью HipChat по вторникам и четвергам (наши «спокойные» дни без внутренних совещаний).
  • Мы стараемся, чтобы на стендапе члены команды обсуждали то, что необходимо для выполнения их задач, а не скукотищу типа «Я сделал это, а я делаю то».
Вот и все наши «официальные» регулярные совещания, однако стоит упомянуть, что нередко мы вместе с Руководителем по UX и PM’ом проводим импровизированные трёхчасовые совещания, на которых подробно обсуждаем вопросы проектирования и дизайна, разбирая несколько карточек с доски «Planning».

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

Полученные уроки

Всегда @обращайтесь к кому-нибудь в комментариях к карточке, если вы действительно хотите получить ответ
Если вы пишете комментарий к карточке, не обращаясь ни к кому конкретно, это значит, что вы написали его как примечание для самого себя на будущее. Если вы хотите, чтобы на ваш комментарий кто-то обратил внимание, укажите, кто это должен быть с помощью символа @ в Trello.

Единый список задач по приоритетам для рабочей группы
Первоначально у нас были колонки карточек, расположенных по приоритету, для каждой отдельной области применения продукта (admin-консоль, виджеты , iOS , веб-портал, электронная почта). Это могло бы сработать, если бы у нас были отдельные рабочие группы для каждой подсистемы, но их у нас нет. Привело это лишь к путанице по поводу того, какая же задача действительно должна быть следующей. Также было крайне неудобно определять и следить за тем, над чем именно команда работает в данный момент. (Совет: если вы замечаете, что часто используете горизонтальный скроллбар Trello, значит, вы что-то делаете неправильно).

Не используйте отдельную систему для багов
Первоначально мы оставили в работе наш предыдущий баг-трекер, а Trello стали использовать для разработки новых функций. Это вызвало проблемы по тем же причинам, по которым не сработало большое количество колонок: как только мы начинали использовать больше одого списка, любое распределение по приоритетам переставало работать.

Ограничьте количество времени на решение проблем с багами
Мы добились этого, установив лимит на количество багов, которые еженедельно можно добавлять в колонку Next Up. Вначале такое решение приняли немного неоднозначно, однако в дальнейшем оно помогло предотвратить кучу споров на тему, стоит ли рассматривать тот или иной баг. Теперь команда по работе с клиентами наделена правом (а может, обременена) выбора стоящих карточек. Это своеобразная версия «Голодных игр» в сфере разработки.

Добавляйте и сортируйте карточки в колонке Next Up только 1 раз в неделю
Это поможет не превратить список Next Up в постоянно растущую песчаную дюну. После того как в понедельник утром представлены новые проекты, вы точно знаете, на каком месте в очереди они будут находиться всю оставшуюся неделю. Вам не нужно беспокоиться о том, что проект, которым вы хотели заняться, окажется в конце очереди (и вы не сможете осуществить задуманное) посередине недели.

Хорошие спецификации скорее рассказывают историю, чем являются пошаговым рецептом
Чтобы все работали над проектом с полной отдачей, они должны чётко понимать, зачем это делают. Поэтому так важно разъяснить проблемы пользователей (или бизнеса) разработчику, которому предстоит их решать.

Не пытайтесь делать предварительную оценку сроков проекта
Раньше, когда мы работали спринтами, мы тратили ОЧЕНЬ много времени (почти целый день на 2-хнедельный спринт) на предварительную оценку и планирование в тщетных попытках провести черту и сказать: «Мы разберёмся вот с этими карточками в течение двух ближайших недель». Мы проделывали большую работу и все равно почти всегда ошибались, поэтому мы перестали бороться с неопределённостью.

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

Обожаю Трелло. Уже на протяжении пары лет, я использую его каждый день. Это сервис организации коллективной работы. Причем необязательно коллективной. И не обязательной работы.

Чтобы вы сразу все поняли, вот для чего предлагают использовать Трелло его разработчики:

  • Разработка продуктов
  • Управление клиентами
  • Подбор персонала
  • Исследования
  • Планирование свадьбы(или других мероприятий)
  • Встречи
  • Блоггинг
  • Фитнес и тренировки
  • Рецепты

В основе Трелло лежит система Канбан , которая в реальном мире выглядит вот так:

До того как я начну о ней рассказывать, хочу успокоить вас, что у этого сервиса есть как и вебверсия, так и отдельная программа для Windows 8, приложения под iOS и Android и расширение для Хрома (которое позволяет выводить уведомление прямо на вашем рабочем столе): https://trello.com/platforms

Есть не официальные для других браузеров, поищите сами если нужно(набрав trello и название браузера).

Первое, что вам нужно знать о Трелло, это из чего он состоит:

  • Доски (boards)
  • Списки (lists)
  • Карточки (cards)

Пример, как мы организуем работу

У нас есть 2 доски:

  • Текущая: задачи которые можно или нужно выполнять на данный момент, или, например, раз в месяц или неделю)Для каждого сотрудника у нас тут свой список + 1 общий, где отмечены основные приоритеты, чтобы все понимали на что сейчас фокус.
  • Будущее: тут для каждого из продуктов у нас отдельный список на доработки, и не критичные баги. Также есть отдельные списки тем и идей для постинга в соц сети, рассылку и идеи по продажам. Часть из карточек в списках снабжается ответственным исполнителем и датой к которой задача в карточке должна быть сделана

Все новые задания, если они не срочные, добавляются в “Будущую” доску. А потом, когда приходит время, или кончаются задачи, переносятся в “Текущую” доску.

Это не совсем тот способ организации, для которого придумывался Трелло, но мне нравится. Поэтому не важно как вы будете использовать этот инструмент, главное чтобы нравилось вам:)

Фишки

  • Используйте комбинации клавиш .
    Это поначалу сложно, нужно привыкать, но сохраняет кучу времени возякания мышкой!
    • Орлиный взгляд: открываем доску, жмем Q, и видим только карточки, назначенные вам;
    • Задание готово и хотите заархивировать карточку? Жмите C;
    • Хотите добавить карточку чуть ниже активной? Вместо того, чтобы создавать новую и перетаскивать наверх списка, жмите N;
    • Добавили карточку для самого себя? Нажмите пробел, чтобы ее себе и назначить.
  • Если на одной доске работает несколько человек, после создания задания с дедлайном, обязательно назначайте его кому-то , иначе уведомления о дедлайне будут приходить всем участникам доски;
  • Не добавляйте в задание тех, кто не отвечает за результат . Например, если выполняет один человек, а тестирует 2ой - пусть сначала карточка будет назначена первому, а потом второму, чтобы был ясен ответственный человек на каждом из этапов;

  • В качестве логина в начале пишете свое имя. Иначе будет сложно будет угадать с какой буквы начать ввод @логинсотрудника чтобы вылезла подсказка;
  • Карточки можно перемещать между досками и доставать из архива обратно;
  • Перед приглашением сотрудников, раздайте им персональную ссылку , которую можно найти нажав сверху на профиль и выбрав “Share Trello”. Ссылку можно найти в самом низу(под надписью “Copy and share this link”). Так, за каждого человека, вы получите месяц тарифа Gold бесплатно;
  • Если вы делаете доски под типовые проекты(например, создания вебсайта для определенного клиента), то имейте ввиду, что вы можете создать шаблон доски , а потом его просто копировать и использовать каждый раз;
  • Можно использовать списки в качестве стадий какого-то процесса . Например, это может выглядеть так: Звонок → Встреча → Обсуждение → Сделка или В планах → Делается → Выполнено

Тарифы:

  1. . Не триал версия. Бесплатный навсегда;
  2. Gold . Добавляет стикеры к карточкам, фон для досок из любых изображений, вложения в карточки до 250мб. и можете добавлять свои смайлы. И самое важное. К вашей аватарке добавляет корона.
  3. Business Class . То, что в Голде + администраторы видят доски всей организации, более гибкие настройки доступа к доскам, запрет регистрации с почтой не на вашем домене. Вроде все.

На данном этапе развития Трелло, мягко говоря, платить там не за что, нет ничего особо интересного и помогающего работе. Увы.

Если вы получите бесплатный Голд аккаунты через приглашения друзей или сотрудников, то потом зайдите на главную страницу(trello.com) и там сверху будет вот такой блок:

Жмите там зеленую кнопку и вы перейдете на тариф Gold. После нажатия вы увидите еще более здоровый блок с описание того, что вам добавилось. Внизу него будет ссылка для закрытия:

Если будет еще что-то говорить, просто ищите ссылку со словом “close” и жмите. Отключить его можно будет на вкладке “Billing” в настройках вашего профиля.

Ссылки

Как мы используем Trello и Google Docs, чтобы постоянно улучшать работу UserVoice:
http://habrahabr.ru/post/171503/

Возможно вас заинтересует раздел “Автоматизация работы” вот в этой статье:

Александр Крутько, CEO в io media , поделился полезным опытом своей работы с Trello. Вот как вы можете облегчить и структурировать свою жизнь, когда задачи сыпятся одна за другой.

Стандарты работы с планировщиком задач

Trello - это онлайн-доска, которая используется для ведения задач в производственной воронке.

Наша воронка содержит следующие статусы:

  • New / Update / Fix - это разные виды задач, подробности будут ниже,
  • In progress - задача, над которой идет работа в данный момент,
  • Need to test - задача на этапе тестирования,
  • Done - задача готова,
  • Live - задача выкачена на продакшн и отправлена клиенту.

Каждая карточка - это проект со своими задачами, и у каждой карточки есть свои атрибуты. Это:

  • Цвет - маркер самой задачи:
  1. Зеленый - это новый проект, который установил наш код, и его нужно настроить и отдать клиенту на триальный период,
  2. Желтый - пожелание клиента по кабинету, то есть любое запрошенное обновление,
  3. Красный - баг или жалоба клиента, которые требуют оперативного исправления (хотим жить без них, но не всегда получается)
  • Участники - пара людей, которые работают над задачей в лице менеджера (постановщика задачи) и разработчика (исполнителя).
  • Срок - когда задача должна быть сделана,

    Количество задач по проекту - да, внутри каждой карточки может быть адский список из пунктов,

    Приоритет - есть задачи, которые нужно сделать в течение 1 часа.

В общем, представьте себе систему, которую вы используете. И неожиданно вам в голову приходит идея или пожелание (хуже, если вы находите баг). Вы открываете онлайн-чат, пишите менеджеру свой запрос, вам отписывают стандартный ответ в стиле «спасибо, разберемся». И вы думаете про то, что отправили свои мысли в никуда, хотя продолжаете мечтать про новое обновление (или про исправленный баг). Но, внезапно для вас, через 1-2 дня вам отвечают: «Готово, заходите - смотрите». Да, идеальный мир существует!

Короче, наш экран задач не бывает пустым, сегодня мы разобрали почти всю очередь. Но бывало в нашей жизни и так:

Как видите, мы используем классическую в проектном менеджменте схему. Но дальше - больше.

Как мы прокачали Trello

Trello известен своей простотой, и любой необходимый для работы хак нужно искать на стороне - в плагинах или интеграциях с их API . Мы же столкнулись с пулом задач, решения для которых создавались нами самостоятельно:

1. Создание новых задач с новыми проектами

Когда на сайте нашего клиента появляется код для трекинга, карточка в Trello появляется автоматически - для этого мы используем API Trello и собственного бота - он проверяет появление данных с сайта клиента, которому был отправлен код для установки и который ранее нами не отслеживался.

Новая задача - это зеленая карточка, к которой автоматически крепится менеджер и разработчик, добавляется дата (+1 день к текущей дате) и приоритет (важнее остальных).

На выходе: у разработчика в пуле появляется заказ на проект, который нужно приготовить максимально оперативно. И разработчик, при фильтрации по себе, будет видеть именно свой стол заказов:

Эх, не успел заскринить задачу в плане Джона, так как она уже в работе:

Да, наши боты справляются не всегда, и мы всегда готовы им помочь.

4. Сдача кабинета клиенту

Когда задача реализована и разработчик хотел бы ее протестировать, карточку с проектом переносят в список «Need to test». В этом списке за нее отвечает менеджер и принимает задачу с точки зрения клиента:

  1. сделано ли все корректно,
  2. не сломано ли все остальное.

Если все действительно сделано правильно, то он переносит задачу в Done, как бы оставляя просьбу на выкатку решения. На данном этапе ответственность человека заканчивается.

В этот момент просыпается еще один бот, разбуженный появлением новой карточки в своем логове. Он использует наше API и по названию проекта находит настройки этого проекта в коде и выкатывает свежие обновления на живой сайт. И да, еще один бот собирает письмо для клиента о том, что в его проекте были сделанные ранее согласованные изменения.

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

На последнем этапе бот архивирует карточку, и она пропадает с доски.

5. Аналитика

Да, у Trello просто нет аналитики. Даже больше - он под это не заточен, так как не рассматривает задачу, отправленную в архив, как сделанную.

А поскольку мы работаем с цифрами, и нам важно любой процесс измерять, нам было критично увидеть такие цифры:

    Какое количество проектов попадает в план, и сколько из них мы реализуем,

    Сколько времени мы тратим на выполнение задач, особенно по типам - зеленые, желтые или красные,

    Кто из разработчиков сколько делает задач и как быстро.

В общем, все перечисленные вопросы - мелочи по сравнению с главным для нас вызовом: наш клиент должен получать решение в течение 1 дня. И любые препятствия на пути - менеджеры или разработчики, размер очереди задач или снижение скорости реакции - должны быть обнаружены раньше, чем они начнут влиять на конечный результат.

Для измерения Trello мы использовали следующие инструменты:

    Google Spreadsheet

  1. Послесловие

    Как видите, Trello нашел отличное применение для решения поставленных целей. Да, бывали моменты, когда хотелось уйти, попрощаться, взять платные инструменты для ведения workflow и утонуть в их функционале, благо на рынке их уйма.

    Но оказалось, что для решений, которые в Trello отсутствуют, можно найти собственные. А простая канбан-доска, придуманная для использования на заводах, может быть применима для ведения современных b2b проектов. Особенно когда постановщиками задач являются тысячи клиентов.

    Управление проектами в веб-студии должно быть централизованным, но хорошо сказать, а сложно сделать. Особенно если компания имеет удаленных сотрудников, которые должны быть на связи так же, как и их коллеги в штате - на протяжении всего рабочего дня.

    На данный момент на рынке 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.