Планирование IT-проектов в ПланФиксе

Алёна Талмазан: Долгое время мы изучаем предпринимателей и компании, которые приходят в ПланФикс. Особенно интересно наблюдать за тем, как предприниматели, стартовав своё дело, постепенно погружаются в рутину и хаос. Всё это со временем нарастает, как снежный ком. В итоге мы часто видим, как предприниматели пытаются из этого хаоса выбраться и навести в делах порядок. Именно в этот момент они узнают про CRM и в целом про системы управления компанией. Здесь обычно начинается долгий путь проб и ошибок, а также тяжелого выбора подходящей системы управления. Когда система найдена — её постепенно начинают внедрять в рабочие процессы компании.

Сегодня история как раз об этом: IT-компания Alto находится в процессе «переезда» в ПланФикс. Им предстоит долгий путь, но ребята уже сделали первые шаги. Что уже удалось реализовать, от каких рабочих инструментов ещё не получилось отказаться, какие планы предстоит реализовать — расскажет директор компании Alto Иван Ярославцев. Передаю ему слово.

Иван Ярославцев: Мы веб-интеграторы. Это означает, что у нас есть постоянный поток проектов объемом от 20 часов до нескольких тысяч. Для себя мы выделяем такую структуру: контрагент, веха, проект.

Веха — это группа проектов, объединенная единой целью.

Например, в разработке сайта у нас могут быть проекты:
— Разработка дизайна,
— Вёрстка,
— Программирование,
— Финальное тестирование.

Все они будут объединены единой вехой «Разработка сайта».

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

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

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

В нашем случае минусы такие:

  1. Мы не можем пользоваться стандартным набором функционала проектов. Например, создание проекта по шаблону.
  2. Не подходят стандартные конфигурации, которые используют проекты.
  3. Сложности при формировании отчетов.

Плюсы:

  1. Мы видим подробную карточку проекта.
  2. Можем создавать триггерные события при смене статуса проекта.
  3. Визуализируем все проекты в виде канбана.

Как выглядит наш проект

Реализация проекта в виде канбана.
Карточка проекта в задаче.
По клику картинка откроется в новом окне и большем размере.
  1. Исполнитель. Всегда в единственном числе. Ответственный за весь проект. 
  2. Продавец проектов. Носитель информации о проекте.
  3. Бюджет проекта. Числовое поле.
  4. Предоплата. Это аналитики, так как оплат может быть несколько, нам важно отслеживать все поступления.
  5. Факт. расходник. Так как бонус исполнителю проекта и продавцу вычисляет за вычетом всех расходов, мы отдельно отслеживаем. 
  6. Тип проекта. Нужен для расчета нагрузки по типам проектов.
  7. Осталось часов. Вручную заполняется для расчета часов
  8. Ссылка на акт и отзыв клиента. Текстовые поля, куда менеджеры вставляют ссылку на учетную систему. Для актов у нас используется Контур.Эльба.

Как выглядит процесс

Описание процесса работы.
Этапы проекта.
По клику картинка откроется в новом окне и большем размере.

Все проекты у нас двигаются по 7 этапам:

  1. Принять проект и познакомиться с клиентом;
  2. Поставил все задачи;
  3. Оповещать клиента о ходе работ;
  4. Получить правки от клиента;
  5. Получить оплату;
  6. Получить акт;
  7. Выполнено.

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

Если говорить про автоматизации, то у нас их пока немного:

  1. Проверка на наличие акта при перемещении в «Выполнено».
  2. Проверка на заполненное поле отзыва при перемещении в «Выполнено».
  3. Проверка, что все подзадачи закрыты при перемещении в «Выполнено».
  4. Отправка бонуса менеджеру.

Система учета поступлений и распределение бонусов

Это, пожалуй, самая интересная часть, так как приходится выходить за рамки ПланФикса. Мы писали о ней в нашем блоге. У нас есть отдельная учетная система, позволяющая менеджерам вносить платежи, которые они ожидают, а директору или бухгалтеру их необходимо подтверждать. При подтверждении происходит создание нового проекта в ПланФиксе:

Пример учетной системы.
Учётная система.

Зачем мы сделали отдельную систему?

  1. Этот интерфейс у нас появился задолго до ПланФикса и, по сути, является мастер-системой, которая когда-то позволила переехать в ПланФикс без изменений бизнес-процессов у менеджеров.
  2. Нужна подгрузка данных с Google Docs, так как все данные, например, контрагенты, хранятся там, а в ПланФиксе дублируются.
  3. Когда требования к интерфейсу строгие, то в ПланФиксе приходится создавать «костыли». Например, у нас у каждого менеджера может различаться % премии, в ПланФиксе нельзя завести у сотрудника дополнительное поле, которое потом можно получить по API, нужно дублировать сущность в контактах.

После подтверждения у нас происходит вот такой процесс:

Подтверждение платежа.
Процесс подтверждения платежа.

Как видите, он объединяет все системы, которые сейчас имеются.

После завершения проекта в ПланФиксе срабатывает вебхук, который вызывает php-скрипт. Он отправляет строки в Google Docs с бонусами. В строке отправляется информация о том, какой менеджер выполнял проект и от какой суммы считается бонус. Так как в нашей специфике менеджеру бонус платится за сумму проекта за вычетом прямых расходов, например, на субподрядчиков или лицензии, то важно, чтобы бонус вычислялся по итогам проекта, а не на старте.

Ресурсное планирование

У нас работает порядка 15 программистов / тестировщиков и пара проектных менеджеров. Программисты разделяются на несколько стэков: 1С-Битрикс, Laravel, React, Prestashop. Какие-то из программистов могут делать только 1 стек, некоторые 3.

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

Распределение задач  между сотрудниками.
Распределение задач между сотрудниками.

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

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

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

Какие у нас планы дальше?

Все самое интересное еще не реализовано, а именно:

  1. Больше автоматических сценариев. Например, у нас сейчас есть процедура, при которой каждую пятницу менеджер пишет клиенту отчет о проделанных работах. Вне зависимости от того были работы или нет, если есть проект в активной фазе, значит отчет должен быть. Собираемся добавить автоматическую проверку на отправку и автоматическое формирование списка работ. 
  2. Запрос акта. Одна из самых главных проблем, что менеджерам интересно завершать проекты, но неинтересно заниматься получением всех документов. Автоматическое оповещение о необходимости отправить акт немного снизит нагрузку. 
  3. Переезд с trello в ПланФикс. Так вышло, что мы исторически на trello и для начинающих команд он прекрасен. Но вся отчетность по времени у нас в ПланФиксе, поэтому сейчас настроена самописная интеграция, которая ввиду технической сложности периодически сбоит. Планируем целиком команду разработки перевести на ПланФикс.

Буду рад вашим комментариям.


Алёна Талмазан: Путь, который начинают компании в ПланФиксе, всегда уникален. А потому, когда с нами делятся кейсами по внедрению ПланФикса, мы с радостью публикуем их. Если вы также готовы поделиться своими наработками — напишите об этом в Службу поддержки.

Не забывайте о наших социальных сетях: ВКонтакте, Telegram, Facebook, Twitter и YouTube-канал. Там появляются новости о доработках и новинках. Подпишитесь, чтобы ничего не пропустить.

2 Comments

Добавить комментарий