(function(m,e,t,r,i,k,a){m[i]=m[i]||function(){(m[i].a=m[i].a||[]).push(arguments)}; m[i].l=1*new Date(); for (var j = 0; j < document.scripts.length; j++) {if (document.scripts[j].src === r) { return; }} k=e.createElement(t),a=e.getElementsByTagName(t)[0],k.async=1,k.src=r,a.parentNode.insertBefore(k,a)}) (window, document, "script", "https://mc.yandex.ru/metrika/tag.js", "ym"); ym(96449955, "init", { defer: true, clickmap:true, trackLinks:true, accurateTrackBounce:true }); ym(96449955, 'hit', window.location.href);

Как управлять производством в digital и расти на 50% в обороте от года к году

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

В 2022 году, несмотря ни на что, мы выросли на 50% к прошлому году. В 2023 планируем рост 80%. Основная точка роста, на наш взгляд — пропускная способность и ресурсоёмкость производства. В статье рассказали о том, как управляем производством и на основе каких данных принимаем управленческие решения.

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

1. Некорректные планы.

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

2. Бесконечные совещания и мозговые штурмы.

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

3. Постоянный перенос сроков.

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

4. Неясные цели.

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

5. Спонтанное увеличение объема проекта.

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

6. Отсутствие понятной отчетности в производстве.

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

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

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

  1. Стоимость — издержки, бюджет, то сколько ресурсов нужно на реализацию.
  2. Объем — масштаб и сложность функциональности.
  3. Время — сроки реализации.
Треугольник управления проектами

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

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

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

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

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

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

Дальше перейдем к планированию в производстве. У нас есть два уровня планирования: оперативное — задачи на неделю для каждого сотрудника производства и стратегическое — план реализации проекта от начала до конца.

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

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

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

  • недельная выработка на каждом отдельном проекте может сильно «скакать»;
  • выполнение задач может быть «рваным»;
  • часто необходимо перебрасывать ресурсы с одной задачи на другую или с одного проекта на другой.
Таблица задач

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

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

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

Главный критерий оценки её эффективности — отзывы наших клиентов.

А как вы управляете проектами? Расскажите о своем опыте.

KISLOROD специализируется на росте и развитии e-com проектов, и если у вас есть амбициозные и сложные цели — мы всегда готовы помочь: предоставить нашу техническую экспертизу и продуктовую команду роста.

Расскажите нам о своих задачах.

Чтобы узнать больше про продуктовый подход в e-com проектах — присоединяйтесь к нашему каналу в Telegram и подписывайтесь на блог на VC.RU.

0
12 комментариев
Написать комментарий...
Илья Горбаров

Классно, что делитесь опытом! А сколько у вас разработчиков и дизайнеров? Просто, чтобы понимать с каким объёмом вы управляете такой системой.

Ответить
Развернуть ветку
KISLOROD E-COMMERCE
Автор

Да, считаем, что так мы вносим небольшой, но весомый вклад в развитие нашего рынка. На данный момент суммарно нас 50+.

Ответить
Развернуть ветку
Прохор Белеванцев из ANIT

Крутая аналитика и для заказчика полезно в плане прозрачности.

Ответить
Развернуть ветку
KISLOROD E-COMMERCE
Автор

Да, мы всегда за прозрачные отношения с клиентами)

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Ольга Леонтьева

"насколько хорошо продаются часы сотрудника" Дальнейшие действия какие возможны в зависимости от показателя? Какие критерии по опыту в итоге влияют на этот показатель?

Ответить
Развернуть ветку
KISLOROD E-COMMERCE
Автор

Следующий шаг — анализ, чем занимался разработчик в рамках внутренних часов. Мы работаем с проектами разного уровня на разном уровне развития и чем выше уровнем разработчик, тем выше вероятность, что ему будет под силу больше коммерческих задач. Если причина в этом, то предлагаем подтянуть скиллы, сдав соответствующий грейд. Вторая причина — если разработчик новый, то аккаунты не всегда готовы в большем объёме отгружать ему задач, то на производственном планирование происходит добровольно принудительное распределения для самых смелых) Ну, а если не желание отдавать свои задачи обусловлено большим количеством багов или чем то ещё, что влияет на качество реализации задач, то здесь применяются более радикальные меры и вопросы вокруг этого разбираются индивидуально с HR-ом и ответственными за производство. На самом деле, если кто-то не был в большей степени задействован в коммерческих задачах за конкретный период, то это чаще своего рода инвестиция, реже простой. Он мог писать кейсы по итогу своих закрытых задач, участвовать в пресейле или во внутренних проектах, например.

Ответить
Развернуть ветку
petr yilov

вообще удивительно, как с такими кривыми процессами, битриксом и экселем вы собрали 50+ человек.

то что описано в статье - езда на давно изобретённом велосипеде.

и вдогонку, есть поговорка: "без ТЗ результат хз".

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

Ответить
Развернуть ветку
KISLOROD E-COMMERCE
Автор

Странный вывод))) Ну ок...видимо имеет место быть) Специально зарегили аккаунт вчера, чтобы оставить тут этот комментарий?)

Ответить
Развернуть ветку
Макс Симченко

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

Ответить
Развернуть ветку
KISLOROD E-COMMERCE
Автор

Мы не претендуем на стандарт отрасли — это наш опыт, которым мы делимся с рынком, т.к. у нас это работает. Всё вышеизложенное — это результат работы команды в рамках рабочих групп. Комментарий, от которого пошла эта ветка, более чем поверхностный, те кто погружён глубже в проблематику и без этого пояснения это поймут. Почитайте все книги Элияху Голдратта и Михаила Рыбакова про процессы. Вот в этой статье рассказали, как внедряли у себя общие принципы Рыбакова: https://vc.ru/flood/26427-linear-processes

Ответить
Развернуть ветку
Андрей Погорелый

А как вы подходите к вопросу эффективности часов разработчиков?
Поясню: существует 40 рабочих часов в неделю, но не существует разработчика, отгружающего 40 рабочих часов в неделю.

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

Я встречал два подхода. Первый - "не паримся, отгружаем все 40". Это позволяет не трекать мелкие перерывы, и в целом удобнее считать.
Второй - вводить какой-то коэффициент утилизации по сотруднику, предполагая, что из его 40ч в неделю эффективными имеем например 32, и вот их уже считаем как доступные для продажи.

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

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

Ответить
Развернуть ветку
KISLOROD E-COMMERCE
Автор

У нас первый подход - «не паримся, отгружаем все 40».

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

Для задач по t&m принцип тот же, только оценка программиста очень примерная (вилочная) и корректируется по ходу выполнения задачи.

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

Ответить
Развернуть ветку
9 комментариев
Раскрывать всегда