Мы обозрели: выбираем систему управления задачами для web-студий. Личный опыт: работа над проектами с помощью Trello

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

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

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.

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

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

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

Ключевой доской для с проектами является 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 и других.

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

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

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

Анна Выдыш

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

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

Здравствуйте, меня зовут Анна и я 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%!

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

Прежде, чем погрузиться в лонгрид о системах, коротко определим, какие потребности мы учитывали. Что такое web-студия? Это компания, внутри которой происходит очень быстрая работа одновременно над несколькими проектами, каждый из которых может находиться на разном этапе. Таким образом, сотрудники вынуждены жёстко приоритизировать задачи и помнить о самых незначительных деталях, которых при создании и управлении сайтами не счесть.

Исходя из этого, мы будем искать:

• вложенные иерархии проект-задача-подзадача
• удобные формы создания задачи
• чек-листы с возможностью отображения закрытых подзадач
• быстрый доступ к полям задачи для изменения параметров
• быстрое развёртывание системы
• возможность назначения и изменения исполнителей и фолловеров
• возможность создания обособленных групп для фрилансеров
• возможность создания дополнительных кастомных полей и изменения названия сущностей.

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

Для тех, кто любит погорячее

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

TrackStudio

Пожалуй, это самая необычная система из всех, что мне пришлось изучить. Магия IT-ретро начинается с самого процесса установки, когда приходится разворачивать сервер-менеджер на десктопе, вручную создавать чистую базу данных и затем уже заходить в web-интерфейс системы, попутно поглядывая за состоянием базы. Столь же необычен и интерфейс, пришедший к нам из середины 2000-х. Впрочем, это не лишает TrackStudio неплохих возможностей управления проектами. Если кто-то надумает разбираться, сильно рекомендую вооружиться документацией: там много полезного и для пользователей и для разработчиков. Лично меня успокоило название раздела «Как управлять миром с помощью TrackStudio». Собственно, этим я и занялся. Сразу скажу, что TrackStudio - история совсем не для web-студий, потому что таким, как мы, это просто не нужно. Такой функционал и мощные инструменты доработки больше подойдут крупным компаниям, зажимающим деньги на дорогие системы или же компаниям-девелоперам: на мой взгляд, TrackStudio можно заточить и под систему управления разработкой, и под багтрекер, и под систему управления тикетами и инцидентами. Несмотря на такое заявление, я всё же остановлюсь на управлении проектами подробнее.

Задачи собираются на рабочем столе системы и одновременно имеют представление в виде дерева. Главной сущностью является проект, в котором можно создавать другие проекты и задачи. С помощью TrackStudio можно создавать различные категории задач (баги, требования, информация и проч.), они будут отображаться в привязке к проекту. Категория задач требует настроить связи между категориями (где может создаваться задача) и позволяет настраивать триггеры (тогда при создании и редактировании задачи может исполняться созданный пользователем скрипт). По всем проектам можно построить отчёты в виде списка, детализации, отчёт о распределении, о затраченном времени, о структуре задач, тренд, табель и диаграмму Ганта. Некоторые отчёты выгружаются в XML и формате MS Project, это кому-то может быть нужным для подгрузки во внешние системы. Диаграмма Ганта не далеко ушла от интерфейса системы, выглядит довольно олдскульно и работает только как отчёт - перетаскивать и редактировать линейки не получится.

TrackStudio - сильное и интересное решение для тех, у кого есть навыки программирования и время на длинный старт. Убеждён, при долгой настройке и подготовке система может принимать любое обличие и надёжно решать различные задачи, тем более, что её можно настроить для любой СУБД. Однако для скромной (да и не скромной тоже) web-студии решение слишком сложное, к тому же в TrackStudio нет готового удобного механизма завершения задач, чек-листов, быстрых моделей управления задачами (назначения, делегирования, контроля и проч.).

Redmine

В сети можно прочитать тысячи хвалебных отзывов, посвящённых Redmine . Причём хвалят его и как багтрекер, и как таск-менеджер, а значит, мы не имеем права пройти мимо. Признаюсь честно, мне не часто приходилось работать с командной строкой в Windows, но Redmine решил забрать мою душу приучить меня к ней. Я обложился мануалами и за долгую ночь научился прямо из командной строки ставить Ruby, DevKit к нему, разворачивать СУБД MySQL и запускать Redmine как службу в Windows. Но речь идёт всё ещё о web-студиях, зачем им столько мороки, неужели нет какого-нибудь готового установочного пакета для людей, не обременённых знанием разработки или системного администрирования? Ответ я нашёл в комментариях к посту на Хабре.

Там же я нашёл самое точное название того, чему посвятил часть ночи.

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

Redmine очень прост: минималистичный дизайн, простое меню и хороший набор понятных настроек. Перед тем, как приступить к работе в таск-менеджере, стоит зайти в настройки в разделе «Администрирование»: там можно создать кастомные наборы трекеров, категорий задач, задать наборы колонок, которые будут отображаться в списках задач. Такая подготовительная работа позволит управлять задачами изначально упорядоченно.

Задачи в проекте создаются просто: название, поле описания, степень готовности, трудозатраты, дедлайн, статус. Менять статус выполнения (в том числе закрывать) можно только посредством редактирования задачи. Чек-листы не предусмотрены. Все задачи отображаются в виде календаря и на диаграмме Ганта: при наведении курсора на отрезок задачи можно видеть её карточку, перетаскивание элементов мышью не предусмотрено. В отдельном окне можно видеть документы проекта, вести обсуждение на форуме, создавать и наполнять полезной информацией Wiki.

На мой взгляд, Redmine хорош именно благодаря многочисленным настройкам (ну и бесплатности, конечно). Хорош он и как багтрекер, и как таск-менеджер, особенно для компаний, в которых задачи не требуют детального дробления, но активно обсуждаются и важно сохранить накопленный опыт обсуждения.

Jira

Раз уж речь зашла о Redmine, то остановимся и на Jira - ещё одной системы, популярной у разработчиков. При запуске Jira предлагает пользователю выбрать необходимые модули: разработчикам - Scrum, Kanban, Basic software development; бизнесу - process management, project management, task management. Интерфейс системы на английском языке, в базовой поставке можно выбрать русский язык заведения задач. Однако есть и русскоязычная локализация, её можно добавить в плагины системы и использовать Jira на родном языке. Кстати, раз уж речь зашла о плагинах, Jira предлагает множество полезных add-ons, среди них есть, что выбрать.

Итак, при создании Jira мы выбрали Project management, а это значит, что основная сущность этого раздела - проект. Внутри проекта регистрируются задачи с помощью формы, в которой определены поля для даты дедлайна, ответственного, вложений, форматируемого описания, фолловеров, приоритета, меток и комментариев. При необходимости ненужные поля можно исключить, сохранив пользовательский набор полей заведения задачи. Внутри задачи создаются подзадачи в виде списка, в котором отображается статус выполнения. Все задачи и подзадачи отображаются в левой панели списком, рядом открывается описание выбранного элемента. Выполненные таски можно отображать в общем списке, выбрав соответствующую опцию. По итогам работы можно построить отчёты на основе готовых шаблонов. Итоги по активностям и структуре задач доступны в разделе Summary.

В целом Jira вполне удобна для работы с проектами, работу с фрилансерами можно вынести в отдельный раздел. Если компания больше ориентирована на разработку, то Jira будет отличным выбором: каждое подразделение будет работать в своём проекте и в то же время в единой функциональной системе.
Собственно, на Jira настала пора закончить с извращениями и рассмотреть системы, более подходящие для поставленных задач.

Системы, где таск-менеджер - модуль

Эти системы в свою очередь делятся на две части: где управление проектами - модуль и где управление проектами и задачами - практически единственная цель существования программы. Поясню, почему иногда целесообразно покупать CRM/ERP/xRM с модулем таск-менеджмента. Если компания стартует как небольшая студия, но имеет в планах расширение портфеля услуг и омниканальное продвижение, то стоит сразу присматриваться к комплексным решениям, чтобы потом мучительно не интегрировать весь необходимый для работы софт. Поверьте, нет ничего плохого, если ваши продажники изначально начнут вести клиентов в CRM - вы от этого только выиграете, получив управляемую клиентскую базу. С другой стороны, если вы решили развиваться только в одном направлении (например, быть web-студией и стать самыми крутыми именно в этом), то стоит ограничиться инструментом, наиболее подходящим именно основным задачам. Итак…

amoCRM

amoCRM в левом тулбаре предлагает вкладку «Задачи», в которой непосредственно можно добавлять задачи и управлять ими. Также допускается назначение задачи из карточки сделки и карточки контакта. Изначально amoCRM предусматривает два типа задач: follow-up и встреча. Этого, конечно, недостаточно, поэтому буквально в пару кликов можно создать множество кастомных типов задач: например, звонки, разработка, дизайн и всё, чего требует ваша деятельность. Форма добавления задачи довольно скудная: выбор даты и точного времени, указание контакта или сделки, связанного с задачей (на самом деле, в поле можно внести любые данные), для кого задача (выбор из списка сотрудников в системе), тип задачи и комментарий (удивительно, но является обязательным полем, пока не заполните, задачу сохранить не удастся). Возможность создания вех и подзадач так и не удалось найти, а для любой web-студии это важный момент: кто работал с сайтами, текстами, рекламой прекрасно знают, что каждая задача может разделяться на внушительный список подзадач, каждая из которых имеет свои сроки, ответственных и т.д.

Задачи в amoCRM могут отображаться в виде списка, однодневного календаря с делениями времени, календаря на месяц, а также to-do line, на которой видны задачи на сегодня и задачи на завтра. Чтобы закрыть задачу из to-do line, следует мышью перетянуть её вниз и тогда появится ещё одна line с отрезками: удалить, послезавтра, сл.неделя, сл.месяц, завершить. Честно говоря, очень неочевидное интерфейсное решение - мне его помогло найти только понимание стандартных интерфейсов. Думаю, начинающий менеджер надолго бы завис. В списочном представлении задачи закрывать проще, для этого достаточно поставить хинт (галочку) у названия задачи и откроется меню: открыть задачи, закрыть задачи, удалить. При попытке закрыть задачу всплывёт окно с предложением указать результат. Закрытые таски не отображаются в панели задач, но их можно найти на рабочем столе amoCRM в «Последних событиях» и в соответствующей сделке. Из приятного - отображение количества поставленных, выполненных и просроченных задач на дашборде рабочего стола amoCRM. Этот дашборд, конечно, не вот нужная штука, но красиво. Поскольку речь идёт о CRM, возможно проставлять сумму сделки, отслеживать этапы взаимодействия с клиентами (воронка).

В общем, amoCRM не совсем вписывается в потребности управления задачами web-студии. Прежде всего потому, что это CRM, нацеленная в первую очередь на решение проблем отдела продаж. Сам по себе модуль управления задачами не имеет необходимого для студии функционала.

Битрикс24

Задачи фактически лежат в основе Битрикс24 . При их создании устанавливается название, инициатор, соисполнители, приоритет, планируются сроки начала и окончания работ по задаче. Внутри задачи можно создать чек-лист с подзадачами - это очень удобно для контроля этапов выполнения работы или списка дел сотрудника. Задачу можно отнести к проекту, который может быть создан по нужному пользователю критерию (отделу, работе, направлению, офису и проч.). Для задачи можно выбрать фолловеров или сотрудников, которым она делегируется. Однородные задачи можно сделать цикличными или создавать в дальнейшем с помощью сохранённых шаблонов. Все задачи подразделяются по статусам и могут отображаться как в табличной форме, так и на диаграмме Ганта. В случае Битрикс24 управлять задачами можно прямо на линейках диаграммы: по клику правой кнопкой мыши открывается меню управления задачей, левой - открывается карточка задачи. Кстати, в Битрикс24 возможно создавать рабочие группы для внешних пользователей.

В плане работы с задачами Битрикс24 точно не подведёт. Однако сама по себе система - целый корпоративный портал с модулем управления продажами и CRM. Для web-студии система явно перегружена. Впрочем, эти слова можно отнести абсолютно ко всем изученным нами CRM. В большинстве систем задачи и планировщики удовлетворяют практически всем требованиям, но нужно ли это компании? Дело тут даже не в стоимости софта, а в том, что у каждого сотрудника перед глазами будет множество ненужного функционала, который будет только запутывать и отвлекать - так просто неудобно работать. Однако, как я уже говорил, если вам нужно расширенное управление продажами и клиентами, контроль исполнения KPI и учёт, присмотритесь к комплексным системам.

Мегаплан

Мегаплан изначально позиционировал себя как система управления проектами. Постепенно он в угоду рынку стал маскироваться под CRM, что, впрочем, не противоречит определению системы управления взаимоотношениями с клиентами. Однако именно модуль управления проектами и постановки задач в Мегаплане реализован довольно сильно, с учётом мельчайших деталей. Первое преимущество - это иерархия и вложенность задач: внутри проекта создаются задачи, подзадачи, вехи, дела, подпроекты. Такая иерархия позволяет организовать работу и фактически построить карту проекта, доступ к каждому элементу можно получить, кликнув на ссылку названия задачи, подзадачи и т.п.

Форма создания задачи предусматривает большой набор полей, из которых минимум относится к обязательным. Внутри задачи устанавливается ответственный, возможный бонус за исполнение, дедлайн, права доступа к полям. В дополнительных полях можно проставить продолжительность, дату старта и финиша задачи, установить плановые трудозатраты. Среди участников задачи опционально можно указать соисполнителей, аудиторов, заказчика. При необходимости можно настроить правила повторения задачи каждый день, неделю, месяц или год. Подзадачи создаются в схожих формах. Задачи и подзадачи можно завершать, редактировать, снимать, удалять, ставить на паузу, делегировать и даже проваливать (по сути, завершать без результата и работы по задаче). Проваленные и завершённые задачи отображаются в списке серым цветом, по желанию пользователя их можно скрыть. В Мегаплане задачи можно отображать как в виде списка, иерархии, так и на диаграмме Ганта. Однако диаграмма Ганта в Мегаплане довольно номинальна - на ней можно видеть поставленные задачи, но передвигать и редактировать их прямо на диаграмме невозможно.

В целом Мегаплан подходит практически для любой компании, нуждающейся в системе управления проектами (кроме, разве, разработческих и промышленных компаний, предъявляющих специфические требования к системе). Из минусов я отмечу несколько перегруженный интерфейс и диаграмму Ганта, которая, увы, уже три года остаётся неизменной. Лично мне опять же не хватило классического простейшего чек-листа с галочками и вычёркиванием выполненных задач.

На десерт - наиболее подходящие таск-менеджеры

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

Pyrus

Следующей я рассмотрю систему управления проектами Pyrus . Сам Pyrus позиционирует себя как систему, отличающуюся от системы управления проектами, документооборотом и бизнес-процессами. Нельзя не отметить возможности интеграции с множеством сервисов и наличие API, однако мы договорились, что нас интересует управление проектами, поэтому к нему и обратимся.

Форма создания задачи простая: большое текстовое поле ввода текста задачи, привязка задачи к проекту, ответственный, срок, метка контроля, возможность загрузить файл (Google Drive, Box, DropBox, OneDrive). Опционально прямо из карточки можно добавить задачу в Google Календарь, назначить несколько этапов согласования и определить папку для задачи. Если до создания задачи не было заведено ни одного проекта, проект можно создать прямо из карточки задачи в отдельном окне - удобно. Также можно создавать пользовательские шаблоны формы создания бизнес-процесса (например, маршрутизация и согласование документов), указать бюджет каждого этапа. Возможно создавать повторяющиеся задачи, это нужный функционал для рутинных задач, которых в web-студиях неизменно много. Все задачи распределяются по папкам: входящие, последние, на контроле. Входящие, в свою очередь, разложены по «долгим ящикам»: сегодня, запланированные, следующие, когда-нибудь. Не знаю, как вам, а мне такая классификация показалась загадочной и недостаточно чёткой.

Задачи можно переназначать, привязывать к другому проекту и завершать с различными результатами. Как и в нескольких других системах, мне не хватило чек-листа, полей для добавления кратких примечаний для каждого участника процесса и не понравилось, что задачи после завершения принудительно попадают во «Все задачи» и не отображаются в других папках. В целом, система не совсем подходит под поставленные задачи, хотя, уверен, за её возможности интеграции те, кому они нужны, ей всё простят.

iQ300

iQ300 - доступная, понятная система управления проектами, отвечающая почти всем требованиям, которые может предъявлять к подобным системам небольшая компания. Облачная система с лаконичным интерфейсом и очевидными сущностями даёт возможность создавать проекты, задачи, чек-листы (наконец-то!), писать комментарии, прикреплять документы и логировать все действия пользователей. Основной сущностью является проект, внутри которого создаются задачи и подзадачи. При создании проекта формируется довольно полная карточка, с учётом целей, рисков, критериев успеха, результата. Из очевидно приятного - возможность создания рабочих групп (сообществ): например, можно создать группы «Фрилансеры», «Удалёнка», «Филиал в Чебоксарах» и отдельно по ним отслеживать активность, скорость работы с задачами и прогресс по деятельности в целом. Это тот функционал, который действительно важен для креативных агентств и студий.

Однако не всё так просто - первое приятное впечатление несколько стирается в процессе создания задач. Судите сами: изначально создаётся черновик задачи и подзадач, затем необходимо вручную менять статус задачи на «В работе». Кстати, это можно сделать через меню «Преобразовать в задачу»: здесь поневоле задумываешься, что произойдёт, если использовать такое преобразование для подзадачи? Спойлер: ничего не произойдёт, подзадача станет активной. При создании задачи поле ответственного за исполнение не является обязательным, однако в случае, если вы захотите активировать задачу, а исполнителя нет, у вас ничего не получится и никакие подсказки не всплывут - сами догадывайтесь по ходу работы. Однако после нескольких столкновений с ограничениями начинаешь понимать логику работы системы и она становится вполне дружелюбной: чек-листы легко закрываются, можно включать и отключать отображение различных типов задач, в том числе завершённых, управление осуществляется через простое меню, возможны групповые операции. Внутри проекта можно вести обсуждение, есть календарный план (по сути своей - базовая диаграмма Ганта с возможность просматривать задачу при наведении курсора на отрезок и перетаскивать линейки и оси времени), в отдельной вкладке находятся документы и мультимедиа по проекту, можно строить отчёты по задачам, исполнителям, ходу исполнения поручений, затраченному времени. Задачи в зависимости от статуса подсвечиваются разными цветами - всё очень наглядно.

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

WorkFlow Soft

WorkFlow Soft - ещё одна система из тех, что мне попалась в ходе моего глобально исследования. В принципе, ничем не отличается от многих систем-напоминалок: нет чек-листов, меток категории задач и т.д., задачи создаются в минимальной стандартной форме.

Но система не может существовать без фишечек: в WorkFlow Soft это конструктор шаблонов и маршрутов выполнения задачи. Маршруты строятся в понятном и приятном глазу интерфейсе, привязываются к задаче и могут быть запущены на исполнение - фактически, это один из вариантов моделирования бизнес-процессов. Очевидно, что ставка сделана именно на логическую связанность задач и возможность построения цепочек работы: от согласования документа до разработки сайта и выпуска нового продукта.

Кому интересна простая настройка несложных бизнес-процессов без использования нотации BPMN - присмотритесь.

Мои вишенки на торте

Asana

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

Внутри проекта (можно создавать несколько проектов с различными группами сотрудников) создаётся задача с описанием, комментарием и подзадачами в виде чек-листа. Допускается создание подзадач у подзадач любой глубины вложенности. При создании задачи назначаются исполнители и фолловеры, которые будут извещаться о ходе работы. Для завершения задачи достаточно поставить галочку - при этом закрытые попадут в раздел «All items» и отображаться в задаче не будут. Внутри Asana также можно создавать групповой календарь и командный чат для обсуждения задач. В случае, если среди множества задач нужно что-то найти, возможен поиск по отдельному полю или по вхождению слова. Asana позволяет создавать несколько рабочих разделов (workspace), которые можно использовать как для разных проектов, так и для разных команд (фрилансеров, удалённых работников, заказчиков и т.д.). Кроме того, одна задача может быть привязана к нескольким проектам. Отдельно мне понравилась возможность управления горячими клавишами - это значительно ускоряет работу. Из субъективных недостатков - невозможность просматривать все задачи и подзадачи одним деревом. А ещё там живут единороги.

Wrike

Wrike - столь же популярная система, как и Asana, но с бОльшими возможностями. Во Wrike можно создавать группы пользователей в разделе «Администрирование» - опять же удобно для ведения нескольких проектов разной тематики и групп фрилансеров. Внутри группы уже создаются проекты, а внутри проектов - задачи. Кстати, кроме проектов, можно создавать приватные и расшаренные папки с задачами. Задачи включают подзадачи, организованные как чек-лист. Опять же, возможно несколько уровней вложенности. В отличие от Asana можно настроить отображение всего дерева задач и включить/отключить задачи со статусами «Решена» и «Закрыта». Для каждой задачи устанавливается ответственный и фолловеры, задаётся дата старта и зависимости; можно прикреплять файлы и создавать комментарии.

Задачи во Wrike можно просматривать в виде таблицы (очень удобная) и на диаграмме Ганта. Это, пожалуй, одна из лучших диаграмм, с которыми я встречался в ходе тестирования перечисленных программ: прямо на диаграмме можно перетаскивать отрезки задач, менять сроки исполнения задач и проекта в целом, устанавливать и разрывать связи между задачами. Плюс ко всему, диаграмма легко масштабируется при помощи специального бегунка. Также пользователь может настраивать отчёты и дашборды по отдельному проекту или по всем проектам команды.

Basecamp

Basecamp - если бы меня попросили охарактеризовать эту систему, я бы назвал её самой наглядной и неформальной. Всё благодаря рабочему столу с закреплёнными панелями чата, заметок, дел, опросов и проч. Basecamp немного выходит за рамки простого таск-менеджера, это ещё и корпоративный портал, внутри которого можно формально и неформально общаться с командой или командами, которые могут быть созданы отдельно. Задачи в Basecamp представляют собой простенький to-do list, состоящий из задачи и множества подзадач, в которых пользователь может задать сроки, исполнителей и фолловеров.

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

На мой взгляд, Basecamp - история для небольшой команды, которой важно следить за порядком в работе, но при этом сохранять непринуждённую атмосферу.

PTYSH

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

В PTYSH задача создаётся внутри проекта. Форма задачи учитывает особенности работы именно web-студий и кроме полей названия, дедлайна, исполнителя, стоимости проекта и фолловеров включает несколько сценариев задач: без сценария, чек-лист, копирайтинг, SEO-продвижение, создание сайта. Сценарии постоянно обновляются - так, уже добавлен сценарий «Контекстная реклама». В зависимости от выбранного сценария формируются дополнительные поля, специфические для типа работ по задаче. Подробно о полях каждого сценария мы уже писали в своём блоге на Мегамозге. Кстати, о чек-листе. В PTYSH мы постарались сделать его таким, о каком мечтали: пользователь просто вводит все нужные пункты через Enter в одном поле, а при создании задачи чек-лист генерируется автоматически. При выполнении подзадачи достаточно поставить галочку - и в вашем чек-листе появятся зачёркнутые пункты с указание точного времени и даты закрытия, а также с указанием закрывшего сотрудника, если над чек-листом работает несколько ответственных.Всё наглядно. Бонусом для клиентов служит встроенный в любую версию PTYSH (в том числе бесплатную) чек-лист для проведения комплексного SEO. Он подгружается в случае выбора сценария «SEO продвижение» и содержит 70 пунктов, разделённых на несколько блоков работ. О них мы тоже уже писали.

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

Поверьте, иногда нюансы очень важны

Ну а чтобы вам было ещё проще выбирать, вот табличка с ценами на перечисленные решения. На момент составления таблицы (а это было 13 января 2016 года), курс доллара был 1 $ = 75.97 р. Кстати, не забывайте о колебании курса, приобретая систему, стоимость которой привязана к валюте - это может привести как к приятным, так и к неприятным (к ним чаще) сюрпризам. Бывает, что компания фиксирует курс, но это казуистика.

Система	Стоимость, заявленная на сайте	Стоимость владения в течение 1 года на команду 10 человек	Примечание
Битрикс24	12 польз. - 0 р. Проект - 990 р./мес., 24 польз. Команда - 4 990 р./мес.	12 польз. - 0 р. 24 польз. - 11 880 р. Команда - 59 880 р.	Тариф «Команда» необходим, чтобы использовать экстранет для внешних пользователей системы (клиентов, фрилансеров)
amoCRM	Базовый - 499 р./мес./польз. Расширенный - 799 р./мес./польз.	95 880 р.	Создание задач возможно, начиная с пакета «Расширенный», выбираем его.
Мегаплан	Совместная работа: облако - от 290 р./мес./польз. сервер на 10 польз. - 47 400 единовременно	34 800 р.	В тариф входят задачи, общение, документы, без финансов. По моде, берём облако.
Pyrus	Бизнес: 9 р./польз./день	32 850 р.	Старшие тарифы предполагают расширенные интеграционные возможности
PTYSH	до 3-х чел. - 0 р. остальные - 990р./мес. без ограничений за всё	11 880 р.	Нет стоимости за пользователя
IQ 300	Старт (2 проекта, 5 польз.) - 0 р. Стартап (10 проектов, 20 польз.) - 1 500 р./мес.	18 000 р.	Тарифы имеют дополнительные ограничения
WorkFlow Soft	Облако и сервер: 15 польз. - 48 000 р./год 25 польз. - 60 000 р./год	48 000 р.	В старших версиях серверная версия дороже облачной версии
Basecamp	29 $/мес. без огр.польз. 79 $/мес. с ведением клиентов 3000 $/год - Enterprise	26 438 р.	Ведение клиентов - набор функций для совместной работы с клиентами. Берём минимум.
Asana	до 15 польз. - 0 р. 8,33 $ в мес. и меньше	0 р., 75 939р. бизнес	Прогрессивные скидки
Wrike	до 5 польз. - 0 р. 5 польз. - 49 $/мес.* 15 польз. - 99 $/мес.	90 252 р.	*на тарифе недоступны подзадачи, дашборды и групповая обработка задач. По нашим условиям выбираем с подзадачами.
Track Studio	5 польз. - 0 р. 10 польз. - 13 950р.	13 950р.	Несколько тарифов, зависящих от серверных возможностей и доступа к репозиторbю с исходниками системы на GitHub
Jira Core **	Облако: 10 польз. - 10 $/мес. 15 польз. - 50 $/мес. 25 польз. - 100 $/мес.	9 116р.	**версия для управления проектами. Сервер дорогой, только для 10 польз. - 10 $
Redmine	бесплатно	бесплатно	Распространяется по лицензии GNU GPL v.2

Примечание: некоторые компании устанавливают скидки при покупке на год, до 10%. Поскольку условия получения скидки постоянно меняются, в таблице они не учтены. Добавить метки