Тайм-менеджмент и оптимизация. Сокращаем временные затраты на десятки часов

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

Таблица 1. Пришло простое письмо

Когда же приходит электронное письмо "со скрепкой" (с прикреплённым файлом), то, если не учитывать время на собственно прочтение, обдумывание и написание ответа, обычно это выглядит так:

Таблица 2. Пришло письмо "со скрепкой"

А с учётом прочтения и обдумывания (если вложение серьёзное и ответ должен быть содержательным, иначе зачем это прислали) так:

Таблица 3. Пришло письмо "со скрепкой". Прочли, подумали и ответили

Ну и что?

Рассмотрим следующий кейс

Одна компания ("Разработчик") присылает другой компании ("Заказчик") файлы на утверждение. Сначала графические файлы, затем (после утверждения графики) присылает файлы с вёрсткой. Присылает электронными письмами, где в теле письма необходимые пояснения и рекомендации, что с этим дальше делать Заказчику, и "скрепкой" к письму - сам файл.

Со стороны "Разработчика" в процессе участвуют 3 человека (всего): дизайнер, верстальщик и эккаунт-менеджер, который курирует взаимодействия с Заказчиком. Со стороны Заказчика тоже 3 (всего): Product Owner (ответственный представитель компании), менеджер и верстальщик. То есть всего в процесс вовлечено 6 человек. В обсуждения и согласование каждого конкретного файла (в зависимости от того, что это за документ) вовлекается от 4-х до 6-ти человек.

Тогда посмотрим на общие затраты времени.

Сначала рассмотрим случай, когда 4 человека согласовывают 1 документ. Время на его создание здесь не рассматриваем, рассматриваем только коммуникации.

Итак, 3 участника получают по 1-му письму, изучают его, пишут ответы и отправляют ответы, используя опцию "ответить всем". Вследствие чего 4 участника получают ещё по 3 письма, которые пришли в ответ. Если на этом согласования закончились (то есть, за одну "итерацию" без повторов), то конец процесса.

Нетрудно посчитать, что общее число взаимодействий в пределах одной итерации без повторных согласований составило 12 (3 человека получили 1 письмо + 3 человека получили 3 письма = 12 взаимодействий, т.к. первый отправитель не отвечал на своё письмо).

Число взаимодействий = n² - n, где n - число участников.

То есть операция, приведённая в Таблице 3 (обработка 1 письма с 1-м вложением выполненная 1 человеком) выполнилась 12 раз. Мы принимаем во внимание, что каждый из участников должен ознакомиться с мнением коллег и встречно написать своё мнение (иначе зачем было отвлекать человека).

Мы знаем из Таблицы 3, что продолжительность одной такой операции составляет 17 минут. Тогда общая длительность = 3 часа 24 минуты.

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

Возьмём 3 повтора (повторим - это очень частая ситуация), получим 10 часов 12 минут согласовывают 1 файл 4 участника процесса. См. таблицу 4.

Таблица 4. Четыре человека согласовали документ

Периодически в процесс вовлекаются все шестеро участников, а не четверо.

Число взаимодействий в рамках 1 итерации = n² - n = 30

И тогда получается Таблица 5.

Как вы видите, число повторов выросло до 5-ти. Когда 6 человек согласовывают документ - 5 итераций. Это ещё достаточно оптимистичное значение.

Таблица 5. Шесть человек согласовали документ

Итак: 42 часа 30 минут на согласование одного документа. Для понимания: рабочая неделя составляет 40 часов.

Вы, может быть, этого не замечаете, поскольку эти потери "размазаны" по людям, по дням и т.д., но это настоящие потери. Мы просто Вам их показали.

И это "время нетто" на 1 документ трудолюбивых приличных людей (по условию задачи), а не чиновников-бюрократов. И нормы на каждую микрооперацию не завышены - даже, если Вы их поправите, картины это не изменит.

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

А как же быть? Как оптимизировать процесс?

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

Сначала рассмотрим только "электронное письмо". Как нам согласовывать документ не рассылая писем, не усложняя процесс? Есть немало приличных "велосипедов" для совместной работы, которые не только уже изобрели, но и "откатали".

Заменим отправку документа по почте выкладкой его для совместного комментирования (благо сервисов для этого немало, в том числе бесплатных) и проведём нормировку для этого случая.

Таблица 6. Это если не думать над сообщением

Таблица 7. Это если думать над сообщением

Обратим внимание на то как снизилось количество участников взаимодействий.

Например, если раньше дизайнер или верстальщик фирмы-разработчика направлял файл "по списку", то теперь документ "вывешивается на стену".

Это привело к тому, что, хоть комментировать формально может кто угодно, из 6-ти человек, но, по факту, в каждом конкретном согласовании (в зависимости от тематики) участвует уже не более 3-х. Например, дизайнер Разработчика, верстальщик Заказчика и product owner Заказчика или два менеджера с обеих сторон плюс product owner и т.п.

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

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

На 1 итерацию по данной схеме мы имеем 3 взаимодействия по 10 мин. 8 сек.

Количество повторных итераций сократилось до 2 (то есть, согласование при такой схеме работы проходит максимум за 2 круга), поскольку количество взаимодействий и "переключений" сократилось. Соответственно, сократилось и количество "неверных пониманий".

Таблица 8. Общие временные затраты

Сравним:

Дополнительно и важно.

При одном и том же методе работы ("письмо каждому"), прирост числа операций при вовлечении в коммуникации дополнительных участников возрастает по формуле:

Прирост числа операций = (m² - n²) + (n - m),

где n - предыдущее число участников, а m - новое число участников.

Например, если их было двое, а стало трое, тогда прирост составит 4 операции. Если же их было 5, а стало 7, то дополнительный прирост числа операций (за счёт коммуникаций) составил уже 22.

В нашем случае, когда число участников выросло с 4-х до 6-ти, прирост составил 18 операций и, соответственно, число операций выросло с 12-ти до 30-ти (как мы видим из таблиц).

Следующий шаг оптимизации - сократить количество файлов, которые надо согласовывать.

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

Затем, после утверждения графического файла, Разработчик присылал вёрстку (в архиве zip скрепкой к письму). Как Вы легко поймёте, "пробка во времени" образовывалась практически мгновенно и потом нарастала геометрически.

Даже и согласование графических файлов с трудом удавалось "приструнить". Хотя их и стали вывешивать на "стену", как описано выше, но одновременно вывешивалось сразу по несколько штук, чтобы показать Заказчику и разные варианты, и разные стадии в пределах каждого варианта (вот так "по умолчанию", вот так, "когда курсор навели", вот "открытое состояние", вот "закрытое состояние" и т.д., и т.п.).

А с вёрсткой (где архив из нескольких файлов) было ещё сложнее - что толку видеть значок архива на "стене", если всё равно надо распаковывать, "собирать" и потом показывать остальным участникам и т.д.

Знающие люди тут же насоветовали хорошие сервисы для упрощения совместного обсуждения графических файлов такого рода, чтобы не слать по почте. (Большое спасибо!)

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

Разработчик сначала возражал: "Зачем верстать, если Вы ещё не видели дизайн, вдруг Вы его не утвердите, мы будем тогда другой файл рисовать, а тогда первая работа верстальщика пропадёт".

Однако такое возражение резонно только на первый взгляд. Потери времени на перевёрстку, которые могут произойти, ни в какое сравнение не идут с потерями времени описанными выше. К тому же Заказчику легче согласовывать свёрстанную страницу, а Разработчику проще переписываться - не надо всякий раз писать трудоёмкие "сопроводиловки" "в этом файле показано…", которые ещё надо внятно описать.

А как у Вас со скрепками и тайм-менеджментом?

Материал опубликован на сайте "Открытые бизнес-методики и технологии TRIZ-RI" 10 октября 2016 г.