Как настроить «Планфикс» с нуля и почему именно он

Статья будет интересна бизнес-аналитикам, project-менеджерам, тимлидам, CEO начинающих студий по разработке и всем причастным и интересующимся.

Hola, Amigos!

Меня зовут Артем, и я TeamLead компании Amiga.

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

Amiga — молодая, и мы начинали с чистого листа. Налаженных процессов не было, как и настроенных CRM-систем или любых других инструментов. Перед нами стоял ряд важных задач:

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

В начале пути оптимизация расходов нужна как воздух, поэтому вариант с использованием Jira не подошел.

Поэтому решили «пощупать», что такое Яндекс.Трекер. «Щупали» мы его 2 месяца, но не срослось. Яндекс.Трекер не позволял указывать область видимости комментариев в задачах. Мы не могли свободно общаться и обсуждать внутренние процессы, ведь каждое сообщение доступно всем участникам, заказчику тоже. Попробовали разбивать задачи на «для клиента» и «для разработки» — да простят меня менеджеры. Отказались, конечно.

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

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

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

Буду рад послушать про ваши схемы, поэтому пишите в комменты, не стесняйтесь.

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

Менеджер собирает требования по задачам и закидывает их тимлиду.

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

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

После согласования оценки задача движется по такой схеме:

Задача отправляется разработчику. После завершения разработчик переводит ее на тимлида для проведения code review. Если замечаний по качеству кода нет — задача идет в отдел тестирования, результаты которого принимает менеджер.

В работе мы используем следующие статусы по задачам:

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

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

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

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

Еще одна фишка, которая упрощает нашу работу, — автоматизация процессов. Например, уведомления по событиям или смена исполнителей в задаче при изменении статуса.

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

Вот пример отчета по времени, которые ребята тратят на задачи за неделю.

Давайте все вместе напомним Маргарите и Кириллу, что переработки ведут к выгоранию ;)

Так в Amiga используют аналитику в отчетах. Сравниваем предполагаемую оценку с реальной и анализируем, что стоит скорректировать в будущем.

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

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

Мы часто оцениваем крупные проекты на пресейлах. Для этого у нас есть довольно четкая табличка с формулами. В ней мы фиксируем фичи, которые предполагаются в проекте, но есть одно но… Переносить их в «Планфикс» для планирования ресурсов становится трудоемкой и скучной задачей. Мы разработали макросы, с помощью которых все задачи из сметы переезжают в виде готовых задач в «Планфикс» по нажатию пары кнопок, — невероятная магия :)

Наша команда общается в Telegram, поэтому мы настроили уведомления из «Планфикс» в мессенджер — очень удобно и помогает вовремя реагировать на срочные вопросы. Как правило, это изменения по задачам или комментарии, которые адресовали тебе.

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

Еще одной полезной фишкой, которой мы не могли не воспользоваться, — входящие вебхуки. Они позволяют обработать практически любой произвольный запрос из внешней системы. Один из настроенных у нас связан с системой контроля версий Gitlab. При слиянии ветки, которая содержит в себе правки по задаче, автоматически меняется соответствующее свойство у задачи в «Планфикс» — тимлиды могут контролировать, на каком контуре находится задача.

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

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

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

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

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

Другими словами — мы продолжаем работу над совершенствованием наших процессов.

Спасибо, что дочитали статью до конца. Буду рад, если вы поделитесь своим опытом, а также ответить на ваши вопросы, поэтому не прощаюсь!