Мы перестали искать идеальный рабочий сервис и выбрали тот, который раздражал всех

Краткая аннотация

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

Вступление

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

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

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

Почему удобные сервисы не решали нашу проблему

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

За один месяц в предыдущем сервисе появилось 386 карточек. Около трети из них не имели срока. У 112 задач отсутствовал конкретный исполнитель. В 74 карточках описание состояло из одной строки. Были и совсем прекрасные экземпляры вроде проверить лендинг, подумать над письмом и обсудить аналитику. Через две недели уже никто не помнил, что именно предполагалось проверить и с кем нужно было что-то обсудить.

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

Перед добавлением задачи приходилось определить:

1. кто отвечает за результат, а не просто участвует в обсуждении;
2. к какой цели относится работа;
3. что произойдёт, если задача не будет выполнена;
4. по какому признаку её можно считать завершённой;
5. действительно ли это задача, а не заметка, идея или пожелание.

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

Мы неожиданно увидели стоимость хаоса

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

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

Мы начали смотреть не на количество закрытых карточек, а на четыре показателя:

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

Картина оказалась неприятной. Почти половина времени уходила не на выполнение, а на ожидание. Некоторые задачи лежали без движения по пять или шесть рабочих дней, хотя сама работа занимала два часа. Ещё 28 процентов карточек хотя бы один раз возвращались с проверки. Причём чаще всего проблема была не в качестве исполнения, а в неясном описании результата.

Особенно показательной оказалась задача по изменению формы регистрации. В старой системе она выглядела бы как небольшая карточка на пару строк. В новой пришлось указать сценарии, ограничения, критерии приёмки и связанные события аналитики. На подготовку ушло около двадцати минут. Зато разработчик выполнил задачу без дополнительных вопросов, а тестировщик не возвращал её на доработку. Раньше аналогичные изменения проходили два или три круга уточнений.

Инструмент оказался неудобным не там, где мы думали

Через месяц я попросила команду снова оценить систему. Почти никто не сказал, что она стала приятнее. Интерфейс всё ещё был тяжёлым. Некоторые действия по-прежнему занимали больше времени, чем хотелось. Мобильная версия раздражала особенно сильно.

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

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

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

Вывод

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

Мы пытались найти инструмент, который приспособится к любому процессу. В итоге получили процессы, которые никто не мог нормально описать. Жёсткая система сделала слабые места заметными. Она не позволяла скрыть неопределённость за карточками, цветами и бесконечными статусами.

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