Как оцифровать и автоматизировать разработку, чтобы увеличить пропускную способность и ресурсоемкость производства

Всем привет! На связи KISLOROD — мы производственное агентство с фокусом на разработку и развитие eCom-проектов.

Узкое место разработки — пропускная способность и ресурсоемкость производства. Мы его обошли с помощью сбора данных и автоматизации.

Когда проектов и сотрудников становится много, то большинство проблем возникает не из-за объемов и сложности задач, а из-за неумения выстраивать и автоматизировать процессы производства. В этом мы убедились на собственном опыте.

Модель управления проектами

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

1. Стоимость — издержки, бюджет, то сколько ресурсов нужно на реализацию.

2. Объем — масштаб и сложность функциональности.

3. Время — сроки реализации.

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

Согласно модели треугольника управления:

1. Качество работы ограничено бюджетом, сроками и масштабом.

2. Изменения в одном ограничении потребуют изменений в других, иначе качество пострадает.

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

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

Проще говоря, не бывает много, дешево, быстро и качественно одновременно, а ресурсы всегда будут ограничены.

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

Проблемы в управлении, с которыми мы сталкивались

1. Некорректные планы. В плане не указаны ответственные, план-график работ устарел, нет четкого технического задания.

2. Бесконечные совещания и мозговые штурмы. Многочисленные совещания, к которым никто не готовится, не фиксируются договоренности и требования к результату.

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

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

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

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

А решили мы их с помощью планирования в производстве. У нас есть два уровня:

• оперативный — задачи на неделю для каждого сотрудника производства;

• стратегический — план реализации проекта от начала до конца.

Недельное планирование

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

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

• недельная выработка на каждом отдельном проекте может сильно «скакать»;

• выполнение задач может быть «рваным»;

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

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

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

До начала планирования каждый аккаунт-менеджер заходит в таблицу и проверяет оценку времени разработчиков, которые задействованы в его задачах. Только после этого начинается недельное планирование в соответствующем модуле, который мы разработали в рамках «Битрикс24».

В процессе планирования оценки по задачам вносятся в модуль планирования рабочего времени.

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

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

Задачи, которые необходимо выполнить, определяет аккаунт-менеджер проекта или тимлид, если он есть на проекте. Если на одном проекте необходимо выполнить много мелких задач, то менеджер суммирует нужное количество часов. Например, 6 часов уходит на 1 проект, куда входит множество задач по часу или 30 минут, а оставшееся время на другой проект.

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

Чтобы понимать, в какой стадии находится задача, каждая имеет свой внутренний статус. Мы доработали «Битрикс24», добавив два поля: «Статус задачи» и «Требуется уточнение».

Статусы задач:

1. Новая.

2. Распределение.

3. Ожидает начала выполнения.

4. Выполнение.

5. Ожидает продолжения выполнения.

6. Ожидает начала тестирования.

7. Тестирование.

8. Ожидает продолжения тестирования.

9. Ожидает тестирования на боевом сайте.

10. Ожидает начала отладки.

11. Отладка.

12. Ожидает продолжения отладки.

13. Готово к переносу на бой.

14. На контроле.

15. Завершена.

16. Отложена.

17. Ждет ответа от клиента (пауза).

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

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

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

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

Для сметных задач в отдельном столбце указывается плановое время на задачу, а в столбце «Факт» выводится фактически затраченное время. Это нужно, чтобы понимать: сколько было заложено в смете, сколько было потрачено в реальности, и сколько времени осталось на выполнение задачи.

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

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

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

Оперативная актуализация планов

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

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

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

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

Таким образом происходит оперативное перепланирование и актуализация плана. Все изменения вносятся в модуль планирования.

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

Отслеживание перерасхода времени на задачах

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

Чтобы подобного не происходило, мы создали специальную функцию для пакетных задач по Time & Material — трекинг перерасхода ранее запланированного времени.

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

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

В отчете учитывается, сколько часов в месяц отрабатывает каждый сотрудник: работает он полный рабочий день, полдня или уходит в отпуск. Также учитывается график отсутствия сотрудников. Кроме того, подсчитывается плановая выработка сотрудника на месяц и фактическая — сколько всего времени было отработано.

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

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

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

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

Предварительная оценка и расчет сметы

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

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

Это дает максимально приближенный к реальности план-график работ. Соответственно, оценки бюджетов также максимально реалистичны — так клиент может планировать финансирование.

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

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

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

Тема обширная, поэтому расписывать здесь не будем.

Планирование на крупных проектах

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

Трудозатраты по этапам работ для диаграммы берутся из предварительной сметы.

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

В диаграмме отмечаются последовательность и параллельность задач. Диаграмма Ганта дает возможность понять клиенту, на какой стадии находится проект и каковы планируемые сроки завершения. А техническому директору позволяет заранее сформировать команду проекта и выделить необходимый ресурс к определённому сроку в модуле производственного планирования.

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

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

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

Дополнительные отчёты

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

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

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

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

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

Отчеты для клиентов на техподдержке
Клиентам, которые работают по модели Times & Materials, отчеты доступны в реальном времени прямо из корпоративного портала «Битрикс24».

Отчет можно построить за определенный период или по оплаченным часам.

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

У тех, кто работает по T&M, в отчете высвечивается остаток часов по пакету. Так клиент понимает, когда ему нужно будет снова оплатить пакет работ.

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

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

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

Резюмируем

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

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

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

«Управлять можно только тем, что можно измерить»,
– Питер Друкер, отец американской философии управления.

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

Есть вопросы или личное мнение? Пишите в комментариях.