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

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

С чего всё началось?

Несколько лет назад, работая в веб-студии, я был назначен руководителем производственного отдела, в состав которого входили программисты-разработчики, дизайнеры и верстальщики. Поскольку до этого уже был опыт руководства коллективом (10 лет в отраслевом НИИ, из которых последние 4 года в должностях заведующего сектором и заместителя заведующего лабораторией), я начал с того, что попытался выстроить удобный, прозрачный, контролируемый, управляемый и комфортный процесс. Удобный, прежде всего, для самого себя, потому что я считаю, что необходимо организовать работу так, чтобы потом было удобно и просто. Как говорилось в известном советском мультфильме, «лучше день потерять, зато потом за пять минут долететь». Причём ещё работая в НИИ я уже что-то такое применял – что-то интуитивно, что-то уже с учётом научных подходов и принципов, благо и работа лаборатории была связана с организацией производственных процессов в отрасли, автоматизацией и разработкой нормативно-методической документации (отраслевых стандартов, инструкций, регламентов и т.п.).

В общем, начал я, как и полагается «новой метле», с некоторых реформ.

Собственно, реформы сводились, в большей степени, к организации работ. По счастью, в компании уже была внедрена собственная самописная автоматизированная система учёта рабочего времени (УРВ), работа была чисто проектная, так что всё можно было относительно легко проанализировать и формализовать.

Проанализировав журнал УРВ, я увидел, что распределение основной проектной работы по созданию сайтов заказчиков и работ по поддержке (исправление багов, внесение правок по заказам клиентов в готовый сайт и т.п.) соотносится как 80% к 20%. И нет, это не распределение имени Парето, хотя цифры похожие. Просто так получилось.

Дальше последовала структуризация работ отдела. Проектные (по основным текущим проектам), разумеется, были в приоритете. Дальше – работы по поддержке (я тогда ещё про ITIL/ITSM не знал, поскольку неоткуда было, но интуитивно к чему-то подобному шёл, набивая собственные шишки).

В этих работах по поддержке ранее разработанных сайтов заказчиков выделялись два типа:

К заказным изменениям относились работы, которые не были заложены в исходную разработку, но потребность в них возникала после приёмки сайта в эксплуатацию. Например, захотел заказчик какую-то несложную (не требующую больших трудозатрат и перепроектирования архитектуры) функцию на сайт добавить, или что-то прикрутить из дизайна – обычно, сделать тематическое оформление к праздникам, типа еловых лап со свечками и шариками на новый год или оформление на 23 февраля и 8 марта. Работы несложные, весь сайт переделывать не надо, но определённое время на их выполнение требовалось, и опыт накапливался, в т.ч. в виде каких-то универсальных заготовок, которые можно было использовать в других проектах.

При этом обнаружилось, что есть, прямо как у Дуайта Эйзенхауэра в его матрице, срочные и несрочные , критичные и некритичные работы - т.е. возник некий аналог SLA, о котором тогда мы тоже ещё не слышали.

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

Причём задачи по доработке мы выделили в отдельный день. Обнаруженное соотношение затрат времени между разными задачами 4/1 (оно же 80/20) позволило распределить их по дням недели: с понедельника по четверг – основные проектные работы, в пятницу – доработки по заказу. Ну и, естественно, если возникали задачи экстренного исправления (к счастью, нечасто), их выполняли в первую очередь, сдвигая остальные. Разумеется, с информированием причастных (менеджера проекта, менеджера по сопровождению, аккаунт-менеджера, коммерческого директора).

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

И это дало свои плоды. За счёт сокращения неуправляемого (и порой неконтролируемого) переключения между задачами, «дефрагментации» графика и освобождения людей от ненужного отвлечения на обработку входящих заявок (я это всё завязал на себя, принимая решение о том, на кого перераспределить или вообще отклонить, особенно по рекламациям, если они возникали не по вине нашего отдела), мы стали экономить около 20-25% времени.

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

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

Какой же вывод?

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

P.S. Про вовлечённость будет отдельный пост.