«Понимаем куда и сколько тратится времени»: как веб-студия Pyrobyte использует тайм-трекинг в Kaiten

Барнаульская компания Pyrobyte уже 6 лет занимается разработкой веб-сайтов, мобильных приложений, CRM и ERP-систем. В основном компания работает над проектами внешних заказчиков, но также выпускает и собственные B2C продукты, самый популярный из них — онлайн-сервис «СпросиВрача», который насчитывает более 200 000 уникальных посетителей в день.

Последние два года компания развивалась наиболее активно — получила много новых проектов от российских и зарубежных заказчиков и увеличила команду разработчиков с 15 до 50 человек.

Исполнительный директор Pyrobyte Александр Комбаров рассказал, почему компания переехала из Trello в Kaiten, как с помощью разных пространств организовали удобную работу с заказчиками и как разработали собственный плагин для визуализации отчетов на открытом API Kaiten.

Искали замену Trello с функцией тайм-трекинга

С самого основания студии и до 2022 года мы работали в Trello. Этот трекер всем нравился, потому что он простой и удобный, а единственным его минусом для нас было отсутствие тайм-трекинга.

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

Еще работая в Trello, мы договорились с сотрудниками, что будем хотя бы вручную фиксировать время, которое уходит на работу с задачами по каждому проекту в формате excel-таблицы. Конечно, это был не самый удобный способ, потому что такой подход отнимал много времени и не давал точных данных. А с ростом числа проектов и сотрудников поняли, что есть два пути — автоматизируй или умри в муках подсчетов)

В общем, задача перевести команду на сервис со встроенным тайм-трекером стояла у меня уже давно, а проблемы с доступом и оплатой Trello в 2022 году послужили последним «пинком» в эту сторону.

Основными критериями при выборе тайм-трекера были:

• канбан-доски, схожие с Trello;
• добавление файлов и чек-листов в задачи;
• автоматический подсчет планируемых и затраченных часов за отчетный период;
• список выполненных задач и отчет по эффективности их выполнения;
• отчеты о затраченном времени по исполнителям, проектам, задачам;
• разделение прав доступа исполнителей и менеджеров.

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

Я выбирал между Kaiten и еще двумя продуктами. Один из них отпугнул слишком агрессивными продажами, а другой показался слишком навороченным. Kaiten был достаточно прост и максимально похож на Trello. Дополнительными плюсами были автоматический перенос задач и открытый API, благодаря которому мы могли сами докрутить то, чего не хватало. Сначала в тестовом формате перенесли в него работу одной команды, а потом подтянули все остальные.

Как организовали работу над разными проектами в Kaiten

Над каждым проектом у нас работает отдельная проектная группа, а менеджеры ведут одновременно 4-5 проектов. Для каждого проекта мы создали в Kaiten отдельное пространство.

Все они организованы по одному шаблону:

• Есть доска «Инфо», где содержится вся информация по проекту.
• Далее рабочая доска проектной команды — «Задачи». Здесь применяется стандартный канбан и задачи двигаются по этапам: «Очередь», «Выполняется», «На проверке», «Проверено». Для каждой новой итерации работы мы создаем отдельную дорожку, чтобы удобнее отслеживать эффективность.
• И еще есть доска «Архив». На ней хранятся выполненные задачи, которые мы уже закрыли, но пока не отправляем в архив Kaiten, чтобы удобнее взаимодействовать с ними на пространстве.

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

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

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

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

Учет времени – самая важная функция

Как я уже говорил, нам нужно было вести учет рабочего времени сотрудников, чтобы понимать рентабельность проектов и эффективность работы сотрудников.

Для этого в каждой проектной задаче мы выставляем размер (в специальном поле) — указываем количество часов, которое запланировано на решение этой задачи.

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

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

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

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

Тут есть еще один тонкий момент — договориться с исполнителями, чтобы они отмечали свое реальное время работы с задачами. Объяснить, что мы это делаем не для тотального контроля или каких-то наказаний, а чтобы выстраивать прозрачный бизнес-процесс и в итоге зарабатывать больше.

Создали свой плагин на открытом API Kaiten – Reporter

Несмотря на то, что в Kaiten удобно устроен сам таймер и все данные собираются в разные типы отчетов, нам не хватало удобной визуализации. Приходилось скачивать отчеты в формате excel и дальше вручную доставать нужные данные. Но ведь «мы-ж-разработчики», поэтому решили адаптировать систему отчетов для себя, создав специальный плагин — Reporter. Благо у Kaiten есть открытый и довольно удобный API.

Вот что умеет Reporter:

• Формировать отчет за день по конкретному сотруднику. На основе данных из Kaiten Reporter в один клик показывает все затраченные часы сотрудника и комментарии по ним.

• Показывать эффективность работы сотрудников по задачам в процентах. Он автоматически сравнивает, сколько часов было запланировано и потрачено на задачу, а также, сколько часов сотрудник был активен в сервисе.

• Показывать статистику по всем сотрудникам. Сколько часов они отработали за конкретный день.

• Показывать общую статистику по проекту. Reporter достает данные по всем задачам на пространстве проекта и сравнивает план и факт по запланированному и потраченному времени на проект. Также показывает прогресс по проекту — сколько задач в очереди, в работе и готово.

Немного выводов

К вопросу перехода на Kaiten мы подошли обстоятельно, поэтому подготовили почву для команды: написали регламент, расписали основные фишки, сделали небольшой собственный FAQ. Конечно, были какие-то шероховатости, но больше от того, что привыкали к чему-то новому. А когда сделали свою надстройку, то Kaiten с тайм-трекером нам стал как родной :)

Иногда читаю истории, что какая-то команда устроила бунт, когда начали трекать время. Но считаю, что дело не только в инструменте, но и в правильном его использовании.

Спустя год могу сказать, что переход в Kaiten был правильным решением. Возможно, так совпало, но с переходом в сервис мы выросли ~ на 30%. Качество постановки и контроля задач стало выше. Мы понимаем, куда и сколько тратится времени на проект.

Впервые кейс был опубликован на GlobalCIO: https://globalcio.ru/discussion/33333/