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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Общий план раскладывается на персональные планы отдельных менеджеров.

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

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

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

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

Выборочно мы публикуем эти кейсы в нашем телеграм-канале.

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

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

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

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

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

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

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

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

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

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

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

Внутренний отчет по коммерческим и некоммерческим часам

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

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

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

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

Отчеты для клиентов на техподдержке

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

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

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

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

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

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

Отчет по зарплате

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

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

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

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

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

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

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

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

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

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