Когда над проектом одновременно работает 5-10 человек, организовать процесс бывает непросто. Множатся цепочки в электронной почте, а информация все равно доходит с опозданием, сроки горят, на обсуждения и согласования уходит много времени. Рано или поздно каждая команда начинает искать выход из этой ситуации. Самый простой и надежный - менеджер задач - программа, которая автоматизирует львиную долю организационных моментов. Но как выбрать подходящую, ту, которая идеально впишется в рабочую схему и действительно будет экономить время, а не отнимать его? Подобных облачных сервисов сейчас очень много. В этом обзоре я решила остановиться на тех, которые сэкономят и время, и деньги.

Trello

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

Достоинства

• Многофункциональность. Trello - это таск-менеджер, ежедневник, форум для обсуждения идей и органайзер для хранения полезных ссылок, статей, изображений и видео.
• Наглядность. Все задачи по проекту отображаются на одной доске.
• Простота. С интуитивным интерфейсом легко разобраться самостоятельно.
• Возможность интеграции с другими сервисами - Dropbox, Google Диск, Gmail, Evernote, Google Calendar, всего около 30.
• Гибкость. Каждая карточка Trello и сам сервис настраивается под конкретные задачи.
• Десктопные и мобильные приложения.
• Количество проектов и участников не ограничено.

Недостатки

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

Краткая инструкция

Для работы с сервисом нужно зарегистрироваться (или подключиться с помощью аккаунта Google) и подтвердить регистрацию в письме. Доски, списки и карточки создаются одним кликом - вбиваем название, нажимаем Enter. Самый гибкий элемент системы - карточка, у нее же больше всего настроек. Доски и списки служат в основном для структурирования задач.

Каждая карточка - это одна задача, к которой добавляется описание (1), участники (2), разноцветные метки (3), чек-лист или to-do-список (4), затем устанавливается дедлайн (5) и прикладываются файлы (6). Закончив работу с карточкой или листом, их нужно заархивировать, а доску - закрыть. Почти все действия в Trello можно совершать несколькими способами, проще всего с помощью drug&drop.

Бесплатно

В базовой версии можно добавлять неограниченное количество досок, списков, карточек и участников. Доступны интеграции с Google Диск и Dropbox, а также 10 МБ для хранения файлов.

Платно

На двух тарифных планах - Business Class (9,99 долл. За пользователя в месяц) и Enterprise (цена договорная) - доступны 250 МБ для хранения файлов, коллекции досок, пользовательские фоны и стикеры, интеграция с Evernote, Github, Mailchimp, Salesforce и некоторыми другими сервисами, а также повышенные меры безопасности и приоритетная техническая поддержка.

«Битрикс24»

По определению авторов продукта, это социальная сеть для работы. На деле функционал сервиса выходит далеко за рамки менеджера задач, охватывая взаимодействие с клиентами, учет рабочего времени и еще с десяток бизнес-процессов. Но в рамках этого обзора мы не будем их касаться и рассмотрим только те, что помогают эффективно управлять проектами. Для этих целей в «Битрикс24 » есть возможность добавлять задачи, назначать ответственных, устанавливать дедлайны, вести обсуждения и отслеживать прогресс. А функционал социальных сетей позволяет быстро обмениваться информацией и выражать свое мнение.

Достоинства

• Много возможностей. «Битрикс24» - полноценный корпоративный портал.
• Облачное хранилище файлов с контролем версий. Редактировать их можно прямо в системе.
• Встроенный мессенджер и возможность обмениваться сообщениями, не покидая системы.
• Интеграция с другими продуктами Битрикс, включая CRM и CMS.
• Мобильная и десктопная версии.
• Диаграмма Ганта.

Недостатки

• Сложный и перегруженный интерфейс. Чтобы использовать возможности сервиса на полную мощность, придется долго его изучать.
• Не слишком расторопная техподдержка.
• Нужно потратить много времени, чтобы полностью настроить систему под потребности своей команды.
• «Живая лента» занимает большую часть рабочего пространства, которое можно было бы использовать эффективнее.

Краткая инструкция

По «Битрикс24» можно написать полноценное руководство пользователя страниц на 100, поэтому сейчас кратко пройдемся по основным функциям. Регистрация в сервисе занимает буквально пару минут. Главная страница портала - это «Живая лента» с вертикальным меню слева и несколькими информационными блоками справа - «Ближайшие события», «Мои задачи» и другие. Создать новую группу, задачу, событие или пригласить сотрудника можно с помощью кнопки «Добавить» в левом верхнем углу. Внутри разных групп удобно работать над отдельными проектами, собрав там сотрудников, файлы и информацию.

В открывшейся форме нужно ввести заголовок (1) и описание. Можно прикрепить чек-лист (3), чтобы отслеживать прогресс. Файлы (2) загружаются несколькими способами: с компьютера с помощью Drag’n’drop (4), из облачного хранилища «Битрикс24» (5), с виртуальных дисков Google Drive и Dropbox (6) или создаются в приложениях пакета MS Office (7). Чтобы сотрудник получил уведомление о новой задаче, его нужно добавить к ней, назначив ответственным (8), наблюдателем или соисполнителем. Если дело срочное, лучше установить дедлайн (9). Поставить задачу можно кнопкой (10) или комбинацией клавиш ctrl+enter. Для обсуждения проектов используется функционал соцсетей - комментарии и лайки.

Бесплатно

Тариф «Проект» включает 12 бизнес-пользователей и 5 ГБ места на виртуальном диске. Доступны большинство возможностей платных версий (телефония, чат и видеозвонки между сотрудниками, CRM и другие), но они немного урезаны.

Платно

Платных тарифа 3 - «Проект+» (990 руб./мес.), «Команда» (5490 руб./мес.) и «Компания» (10 990 руб./мес.). Их владельцам доступны функции «бизнес-процессы», «учет рабочего времени», «собрания и планерки», расширенные опции из базового тарифа и некоторые дополнительные настройки.

Я не буду рассказывать основы трелло, сразу прыгну к интересной части.

Мы проводим множество проектов одновременно, поэтому настроили огромную структуру досок и переплели их между собой. В целом наша компания выглядит так:

Зеленые карточки – активные проекты. Фиолетовые и с картинками – департаменты (об этом будем говорить во второй статье). Красные – подготовленные пресеты для новых досок.

Ключевой доской для с проектами является Projects Pipeline:

В ней можно найти и посмотреть статус любого проекта. Глянуть быструю информацию о проекте и перейти в саму доску с проектом.

Сам жизненный цикл проекта состоит из таких шагов:

1. Projects queue

В этом листе находятся все заиницированные проекты. По ним узнается бриф и происходит вся подготовительная работа перед подписанием контракта.

2. Pending signing of the contract

Ожидает подписания контракта.

3. In development (design)

Проекты, которые находятся на стадии разработки дизайна.

4. In development (animation)

А здесь на этапе разработки анимации.

5. In development (code)

Ну а здесь кода. При чем сами мы не пишем код, этим занимаются наши партнеры, или фрилансеры.

6. Preparation for release

Все проекты, которые готовятся к релизу/запуску.

7. On review

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

8. Waiting for the bill

Проекты, которые ожидают оплаты за проделанные услуги.

9. Finish won

Завершено с успехом. Те проекты, которые завершились с успехом и получили полную оплату.

10. Finish lost

А здесь находятся проваленные проекты. Здесь обязательно пишется причина провала, чтобы больше такого не повторилось.

Как видно на скриншоте выше, карточка содержит в себе небольшую информацию о статусе проекта и ссылку на доску. И да, на ней стоит due date. Это первый ключевой дедлайн по проекту. Чтобы можно было сразу увидеть когда сдача проекта.

Давайте нырнем в какой-то проект и посмотрим как он устроен изнутри:

Опять же опишу списки по порядку:

Здесь собрана вся основная информация о проекте: как пользоваться этой доской, общее описание проекта, ссылка на проект на Google Drive и какие-то вводные важные комментарии от клиента.

2. Notes

В этом листе обычно собирается вся информация после Research’a, или какие-то другие интересные заметки.

3. Tensions

Это очень важный список. В нем находится все напряженности проекта. Напряженности – это то, что нужно сделать к определенному сроку.

4. Ideas

Любые идеи, которые могут возникнуть у участников проекта.

5. To Do (queue)

Огромный список вещей, которые необходимо сделать для завершения данного проекта.

6. To Do (within 2 weeks)

Список того, что нужно закончить за (3 дня, неделю, 2 недели, месяц). Срок выставляется на первом совещании по поводу этого проекта.

7. Started & In progress…

Список задач, которые были начаты, но не закончены, и в данный момент находятся в процессе. Обычно эти задачи уже за кем-то закреплены.

8. Doing Now (AT THIS MOMENT)

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

9. For Review

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

10. Done

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

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

Поэтому в нашей методологии ведения проектов можно найти элементы Kanban, Scrum и других.

На этом я закончу первую статью из цикла. В следующих статьях планирую рассказать, как происходит непосредственный процесс работы над проектом от а до я.

Всем спасибо, всем удачи.

Design teams, whether in-house or agency, aren’t defined as “creative teams” as mere lip service. The work your design team does has vision, meaning, and the purpose to create memorable experiences that connect people to concepts, brands, and beyond.

Building a team culture that upholds this creative mission while keeping team to-dos and communication organized requires a little out-of-the-box thinking, too. Effective design teams know that a balance between artistic freedom and structured process gives them artistic freedom to work without the worry of if, how, when, and by whom the work is getting done.

That’s why your design team tools should include Trello, a hub for all the project work, team management, incoming requests, sprints, and brainstorming that’s shared across your organization:

• Support asynchronous teamwork with accessible-anywhere Trello boards that help creativity thrive whenever and wherever inspiration strikes.
• Keep all your notes, versions, feedback, and files in one place by connecting tools in your design stack like InVision, Dropbox, and Figma to Google Docs and more.
• Amp up visual perspective with image previews as card covers, custom backgrounds, and teammate avatars assigned to each task.

And because design team roles and responsibilities change almost as fast as seasonal color trends, Trello is there to evolve and grow with whatever new creative challenges come your way.

Our own design team at Trello uses these boards to manage requests, build out new creative ideas, and work on cross-functional projects. Get inspired, copy the boards, and make them your own!

Product Design

For design teams with lots of members, it’s easy to lose track of what everyone is doing. Use this board as a command center for all ongoing projects:

• Create a leftmost list with a card for each member of the team. Attach 3 checklists to the card: “Currently Doing,” “Up Next,” and “Done” checklists. Drag items from one checklist to another as they are being worked on.
• In the comments section of this card, update the team on what you got done every Friday.
• Use the rest of the board to create lists and cards for “Active Projects,” “On Hold Projects,” and “Shipped Projects.”
• Create some static lists with general information for the team about regular meetings and other opportunities the team uses for sharing, like Lunch and Learn presentation sessions.

Design Huddles

Use this board for meetings where one designer would like the others to give feedback on their concept or design. The board provides structure, keeps record, and is democratic.

• Create a helpful instructional list for different roles in a Huddle that includes cards for “If you’re facilitating,” “If you’re presenting,” and “If you’re an attendee.”
• Provide a list for each individual Huddle session with the agenda for that meeting. Each card is a different person that is presenting a project. The presenter can attach all relevant specs, and provide a detailed description of the scope right on the card.
• Attach Mural links to cards to allow the meeting attendees to take notes that are visible to the whole group. They are then reviewed by the presenter after they show their demo.
• You can also attach template cards in the leftmost list for attendees to easily copy when they need them.

Подробный пост о разных фишках Trello , которые помогут сделать работу с этим сервисом еще удобнее.
Как добавлять карточки в Trello по email и из Evernote , синхронизация с Google Calendar , учет времени, система поинтов , как установить WIP-лимит и многое другое.
Приблизительный размер поста ≈ 4 страницы.

Интеграция с Evernote и Email через Zapier.com

Начну с сервиса, о котором стоит знать, даже если вы не пользуетесь Trello. Zapier.com вполне достоин отдельного поста. Он помогает “подружить” между собой различные приложения с открытым API, создавая всевозможные связи между ними. Если вы знакомы с , то без труда поймете о чем идет речь. Основных отличия от IFTTT два:
1) Zapier платный (есть бесплатная ограниченная версия)
2) Zapier фокусируется на бизнес приложениях.

Сегодня Zapier поддерживает более 200 приложений, цифра растет. С полным списком можете ознакомиться . Вот небольшая их часть, впечатляет, не правда ли?

Теперь конкретные кейсы, как я использую Zapier для улучшения работы Trello:

Points for Trello добавляет систему “очков” к карточкам Trello. “Вес” одного очка можно настроить, ровно как и величину измерения: дни, часы, доллары. Сумма очков всех карточек в списке выводится в заголовке каждого списка.
Существует очень похожее (и более известное) расширение Scrum for Trello . Я пользуюсь Points, т.к. в нем немного больше возможностей.

Work-in-progress limit (WIP) - важный элемент любой канбан-системы, подробнее об этом я расскажу в следующем посте. Расширение WIP позволяет установить “ограничение” на количество карточек в определенном списке Trello. Для этого нужно указать это значение в заголовке списка в квадратных скобках. Когда количество задач в списке будет равно заданному значению, список подсветится желтым, а если количество задач превысит максимум, то список покраснеет, видимо от стыда.

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

Удобные оповещения об активности в Trello. Добавляет возможность помечать отдельные\все оповещения как прочитанные\непрочитанные.

Time-tracking в Trello

Как справедливо в Trello сильно не достает функции учета времени. За эту фичу на доске разработки Trello пользователи голосуют чаще всего, надеюсь это даст результат. А пока… Запущено сразу несколько сторонних проектов, призванных решить эту проблему. Вот их краткий обзор:

Еще с Trello умеют взаимодействовать тайм-трекеры PayDirt и TimeCamp , но эти решения лично мне понравились меньше.

Trello random tips and tricks

- Если в адресной строке Chrome набрать trello.com и нажать Tab , то можно выполнить поиск по всем своим доскам и карточкам.

Если перейти по ссылке trello.com/my/cards , можно увидеть все карточки из всех досок, которые закреплены за вами. Карточки на этой странице можно фильтровать по доскам либо по дате.

В Chrome изображения к карточкам можно добавлять из буфера обмена. Просто скопируйте любую картинку и нажмите control/command + v.

С помощью символа @ в комментарии можно упомянуть любого члена команды, и он получит уведомление об этом. Для символа @ работает автозаполнение, так что полностью набирать имя коллеги не придется.

Если во время просмотра доски нажать Q , то Трелло отфильтрует и покажет только ваши карточки.

Широкие доски удобнее всего скроллить горизонтально , потянув за фоновое изображение доски (зажмите левую кнопку мыши и потяните влево).

Нужную карточку можно найти с помощью поиска по заголовкам. Просто нажмите F во время просмотра доски.

Нажмите C , чтобы заархивировать активную карточку. Главный time-saver.

Любую общедоступную доску можно закрепить в своем меню , если в Options нажать Pin to header menu.

Чтобы быстро добавить лейбл, нажмите L .

Нажатие N приведет к тому, что новая карточка будет создана ниже той, которая активна в данный момент.

Нажмите пробел , чтобы назначить любую карточку себе.

Trello запоминает фильтры . Т.е. можно включить фильтр, который будет показывать только ваши карточки, и только с красным лейблом, например. И работать с этим включенным фильтом, пока все эти дела не будут выполнены.

Чтобы очистить фильтры, нажмите X .

Знаете, чем можно дополнить этот список? Поделитесь в комментариях!

Моя первоначальная реакция на такие перемены была отнюдь не положительной. Проблема заключалась не в самом 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-хнедельный спринт) на предварительную оценку и планирование в тщетных попытках провести черту и сказать: «Мы разберёмся вот с этими карточками в течение двух ближайших недель». Мы проделывали большую работу и все равно почти всегда ошибались, поэтому мы перестали бороться с неопределённостью.

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