Программа планфикс инструкция по применению

Материал из Planfix

Перейти к: навигация, поиск

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

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

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

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

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

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

Hola, Amigos!

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

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

Какая стояла задача

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

• построить понятный процесс разработки, поддержки и развития проектов;

• создать площадку для взаимодействия с клиентами;

• наладить контроль сроков разработки, планирование ресурсов, ведение внутренних задач компании.

Что мы попробовали и какие сложности возникли

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

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

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

Почему выбрали «Планфикс»

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

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

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

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

Флоу по задачам, которые настроили

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

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

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

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

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

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

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

• Оценка

• Требуется информация

• В работе

• CodeReview

• Можно тестировать

• Тестирование

• Выполненная

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

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

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

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

Ништяки автоматизации

Автоматические сценарии для разных событий

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

Отчеты

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

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

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

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

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

Автоматические задачи

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

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

Уведомления в Телегу

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

Уведомления по ДР

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

Интеграция с Gitlab через вебхуки

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

Перспективы развития

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

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

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

Больше автоматизации

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

Больше различных отчетов и метрик

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

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

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

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

Hola, Amigos!

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

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

Какая стояла задача

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

Что мы попробовали и какие сложности возникли

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

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

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

Почему выбрали «Планфикс»

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

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

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

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

Флоу по задачам, которые настроили

Разные флоу для задач

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

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

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

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

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

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

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

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

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

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

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

Ништяки автоматизации

Автоматические сценарии для разных событий

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

Отчеты

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

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

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

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

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

Автоматические задачи

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

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

Уведомления в Телегу

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

Уведомления по ДР

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

Интеграция с Gitlab через вебхуки

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

Перспективы развития

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

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

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

Больше автоматизации

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

Больше различных отчетов и метрик

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

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

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