Как мы избавились от отчетов о выполненных работах
История об избавлении от бессмысленной траты времени
Введение
Вам когда-нибудь приходилось работать с отчетами о выполненных работах? Заполнять их? Утверждать их? Носиться с ними по всему офису?
Было ли это похоже на время, потраченное с пользой?
Заявление 1: Отчеты о выполненных работах иногда полезны.
Заявление 2: Но очень часто ничего подобного.
История
Жила-была компания по разработке софта и я устроился в нее руководителем отдела разработки.Это была интересная и клевая работа, но одним из моих каждонедельных раздражителей была обязанность собирать и утверждать отчеты о выполненных работах. Десятки и десятки отчетов, сотни бумажек. Одной из забот отдела кадров было пинать меня, чтобы я сдавал отчеты вовремя, а мне, соответственно, приходилось пинать моих разработчиков об этом каждую неделю.
Это раздражало. Не только потому, что это просто занимало время и отвлекало всех, но и потому, что моя работа по «утверждению» отчетов было в основном игрой в угадайку. У меня не было никаких рабочих способов узнать, правилен ли отчет. Это все раздражало, но не настолько, чтобы начать суетиться из-за этого – я был тут новичком и хотел сосредоточиться на более проблемных вещах.
Одной из самых больших проблем было то, что люди «уработывались до смерти». Многие разработчики выглядели как бледные приведения; они уже были в офисе утром, когда я приходил, и все еще торчали там, когда я уезжал вечером. Один из ключевых разработчиков даже умудрился отправить заявление на отгул на предстоящую субботу. Я подумал, что он перепутал и ввел неправильную дату, но выяснилось, что он работал все выходные уже несколько недель, и очень хотел пойти домой хотя бы на один день в предстоящие выходные. Заявление на отгул на субботу было смешным, но очень эффективным способом указать на серьезную проблему.
Почему же модуль Планирования и учета работ не выдал никакого Предупреждения о Вусмерть Заработавшемся Разработчике? Если этот модуль не может сделать даже такой простой и важной вещи, то нафига он вообще? Представьте себе самолет или атомную станцию с модной системой мониторинга, которая записывает всю возможную информацию, но никогда не предупреждает, когда что-то очевидно идет не так…
К счастью, я мог увидеть знаки этого Предупреждения и так, так как я сидел с разработчиками (И я был рад, что отказался от персональной комнаты в офисе, которую мне предложили вначале).
Долго-ли, коротко-ли, но через несколько недель основные проблемы уже были более-менее под контролем, так что я добрался до отчетов о выполненных работах. К тому времени, мне уже нужно было делать немало разных отчетов, но кроме всех недостатков от этого, было и одно преимущество: для других расточительных процедур места уже совсем не было.
Отчеты о выполненных работах не просто раздражали меня, мне было любопытно. Зачем они нужны нам? Откуда они поступают и куда идут потом? Так что я начал расспрашивать.
Мой начальник (CEO) сказал, что они нужны бухгалтерии. Бухгалтерия сказала, они нужны отделу кадров. Отдел кадров сказал, что они нужны компании, который мы отдали на аутсорсинг расчет зарплаты. И так далее. Это стало моим фоновым проектом – когда у меня было немного времени, я продолжал свое расследование «Тайны Отчетов о Выполненных Работах».
В итоге, я узнал, что происходило с бумагами. После серии передач из рук в руки, они заканчивали свою жизнь в той аутсорсинговой компании, где каждый отчет вручную забивался в электронную систему учета кадров.
Хм…
Мдааааааа…
Ну то есть я имею ввиду, что вообще это не очень эффективно.
Будучи IT-гиком в сердце, я немедленно начал думать о том, как упростить процесс. Так, каждый разработчик может заполнять свои работы онлайн, их локальный тим лид также просматривает все отчеты онлайн и жмет Ок, чтобы утвердить их, затем я смотрю на высокоуровневые итоги и тоже жму Ок, чтобы принять их и все это отправляется автоматом аутсорсинговой компании. Ухты, все довольно гладко. Хмм, может быть подключить эту систему к Eclipse, чтобы оно автоматом логгировало время в выполненных работах в зависимости от того, какой проект разработки открыт на компьютере? Может мы можем сразу сынтегрироваться напрямую с той системой учета кадров, которую использует аутсорсинговая компания? Это скорее всего хорошо ляжет на SOA…
Подождите.
«Нет ничего более бесполезного, чем делать эффективно то, что не нужно делать вообще»
— Peter Drucker
Я напомнил себе, что моим начальным вопросом была эффективность (Effectiveness) отчетов о выполненных работ, а не их производительность (Efficency).
- Производительность – соотношение выхода системы к ее входу.
Пример: Количество строк кода в час. - Эффективность – качество способности принести желаемые результаты.
Пример: ROI за релиз.
Я до сих пор не знал, для чего же использовались отчеты о выполненных работ. Ответы, который я получал, часто были чем-то глупым типа «мы должны заполнять выполненные работы, потому что это наш стандарт» (то есть типа «мы должны, потому что должны»). Что мне только не рассказывали об отчетах о выполненных работах, но что мне действительно хотелось знать – для чего нужны эти цифры.
Так что я стал задавать вопросы по-другому. Вместо вопросов «Почему нужны отчеты о выполненных работах», я стал спрашивать «Что случится, если мы «потеряем» отчеты» или «Что случится, если мы «нечаянно» сгенерируем содержимое отчетов случайным образом».
В итоге, всплыла настоящая цель отчетов. Главное, для чего они использовались, — чтобы вычислить, сколько выплатить компенсации за переработки. Были и другие цели, но они уже покрывались и другими отчетами. Так что единственной важной целью был именно расчет за переработки. А, еще они нужны были, чтобы рассчитать «flex time», традиция шведской индустрии, которая, по сути, позволяет людям приходить иногда на работу попозже, если в другой день они пришли пораньше. Отчеты о выполненных работах использовались, чтобы подтвердить, что все суммируется в как минимум 40 часов в неделю + X, где X – овертайм.
Сладкий вкус истины.
Теперь, вооружившись Истиной, я собрал несколько разработчиков и задал им риторический вопрос – «нравится ли вас заполнять отчеты о выполненных работах»? Выражение их лиц было тем ответом, что был мне нужен:
Тогда я продолжил примерно так:
«Сейчас мы используем эти отчеты, чтобы считать овертайм. Но заполнять отчеты уныло, а работать овертайм – это еще более уныло. Мы все знаем, что один час энергичной, мотивированной, сфокусированной разработки полезнее целой недели зомби-кодинга».
(Навскидку я не помню ни одной конкретной ссылки, ну я уже потерял счет исследованиям, которые показывают, что связь между продолжительностью рабочей неделю и произведенной ценностью мала или ее нет, по крайней мере, когда речь идет о творческой работе типа разработки софта. Важна мотивация и фокус, а не часы).
«Так что такое предложение. Больше нет отчетов. И больше нет овертайма. С сегодняшнего дня Овертайм значит «Работать тогда, когда ты не хочешь» Если ты демотивирован или устал – иди домой. Если ты хочешь задержаться и покодить потому что ты «в потоке» — задерживайся. Это не овертайм. Если ты чувствуешь, что ты работал допоздна несколько дней – возьми выходной. Если неделя выдалась медленной – догоняй в субботу, если хочешь. Найди свой ритм, найди ритм своей команды».
«Конечно, иногда могут быть исключения. В таких случаях будет работать традиционная система компенсаций за переработки. Мы будем стараться минимизировать такие случаи и разбираться с ними в каждом отдельном случае. Если сомневаетесь – позовите меня».
«Manage for the normal and treat exceptions as exceptional»
— Edwards Deming
«Ну и наконец. Меня не волнует, сколько точно часов в неделю вы отработаете, пока это примерно соответствует стандартной полной занятости. Меня волнует, что вы сфокусировны и смотивированы, когда вы работаете. Могу я доверить вам отнестись к этому ответственно?»
Все с энтузиазмом кивают.
Я собрался с мужеством, пошел к CEO, и сказал ему, что мы больше не будем отправлять отчеты о выполненных работах. Диалог прошел примерно так:
Я: «Мы больше не будем отправлять отчеты о выполненных работах»
СЕО: «Почему?»
Я: «Это пустая трата времени».
СЕО: «А отдел кадров не расстроится?»
Я: «Я дам им то, что им нужно более эффективным способом».
СЕО: «Ок, клево».
Вау, это было проще, чем я ожидал. Я приготовился к самым разным вопросам… Нравился мне тот CEO :o)
Затем я пошел к кадрам.
Я: «Мы больше не будем отправлять отчеты о выполненных работах».
Кадры: «Но вы должны. Таков стандарт!»
Я: «Стандарт меняется, я только что поговорил с CEO» (Ну да, немного приврал, признаю).
Кадры: «Как мы теперь узнаем, сколько платить людям?»
Я: «У вас есть трудовые договоры каждого. Просто платите всем их нормальную месячную зарплату».
Кадры: «Что с овертаймом?»
Я: «Его больше почти не будет. Если же будет, я дам вам знать. В остальное время, считайте 40 часов в неделю».
Кадры: «Но нам не хочется менять наши процедуры и стандарты, может вы просто будете присылать отчеты как раньше?»
Я: «Я могу сделать, чтобы они генерировались автоматом с 40 часами в неделю и автоматом отправлялись к вам по почте каждую неделю. Вам это нужно?»
Кадры: «Мда, получается довольно глупо».
Я: «Ну тогда я не буду посылать их. Если хотите. можете считать, что вы получаете от нас пачку 40-часовых отчетов, и вводить это все в систему, как вы обычно делаете. Меньше будем марать бумаги, и вам больше не придется пинать меня за опоздавшие отчеты».
Кадры: «Ок, вполне справедливо, давайте попробуем».
Никто больше не заикался про отчеты о выполненных работах.
Мораль истории
- Многие организации бесполезно тратят кучу времени на выполнение всяких процедур, предписанных стандартами – различные бесполезные правила, практики и процедуры. Смотрите на это свежим взглядом. Относитесь к этому позитивно – это хорошие возможности для улучшений.
- Даже самая бесполезная на первый взгляд процедура имеем за собой какую-то цель.
- Если вы встречаете сопротивлению отказу от бесполезной процедуры, найдите ее причину. Узнайте, какую потребность закрывает эта процедура. Предложите не такой затратный и бесполезный способ закрыть эту потребность.
- Будьте настойчивы. Нужно время, чтобы устранить процедуру, которая глубоко «въелась» в организацию.
- Не обвиняйте предшественников, которые ввели эту процедуру. Скорее всего, это было хорошее решение для реальной проблемы в прошлом. Хотя могло и не быть. В общем, это уже не важно, сфокусируйтесь на будущем.
“Things are the way they are because they got that way” — Jerry Weinberg - Не путайте эффективность с производительностью. Сфокусируйтесь вначале на эффективности, а уже потом на производительности.
- Час – это мера усилий, а не мера ценности.
FAQ
После такого, как не стало овертайма, не привело ли это к тому, что вы стали меньше успевать делать
Хорошо, это привело к тому, что меньше кода стало писаться. Меньше Плохого Кода. Меньше бажного кода. Меньше мусора. А поэтому, и меньше времени на вылавливание багов, на ответы на панические звонки в службу поддержки, когда система скрашилась, на поддержку списка багов, на выпуск исправлений и на расшифровку кривого кода.
А значит, и больше времени на написание Хорошего Кода.
Мы все заметили ясное и заметное улучшение продуктивности после отказа от овертайма. Продуктивность в смысле ценности для пользователя, производимой в единицу времени.
Разве вам больше вообше никогда не нужно было учитывать отработанное время?
Ох, иногда есть вполне корректные причины того, что нужно знать, сколько времени тратится на определенный проект, например, если есть внешний клиент, которому нужно выставить счет. Но это легко сделать и без отчетов о выполненных работах. Если одна команда из 8 человек потратила 3 спринта работая над проектом X, и каждый спринт занял 2 недели, то можно примерно считать, что 8 человек работало полный день 3×2 недели. Итого 40 часов x 6 недель x 8 людей = 1920 часов. Правда, может быть так, что часть своего времени они тратят на поддержку продукта Y в тоже самое время. В таком случае, на каждой ретроспективе я прошу команду примерно оценить, какой процент времени они занимались проектом Y, например, 80%/20%. Вполне просто учесть это в вычислениях.Некоторые команды делает это каждый день — перед тем как идти домой, каждый член команды ставит метку на графике на доске, примерно распределяя свое время за день по разным работам. Это дает еще большую точность, в то же время при маленьких затратах.
Однако, я бы был тут осторожнее. Многозадачность — это обычно очень плохая идея. Если нам приходится делать сложную систему, чтобы учитывать точно, как люди распределяют свое время по проектам, то мы точно фокусируемся не на том — мы должны исправлять проблему (занятие сразу слишком большим количеством проектов параллельно), а не симптом (проблемы с учетом выполненных работ).
Допустим, я потратил понедельник работая над четырьмя разными проектами, 2 часа над каждым, 8 часов суммарно. Я отмечу 2 часа на каждый проект в системе учета выполненных работ, но со всеми этими “переключениями контекста” эффективное время будет скорее всего ближе к 30-60 минутам на проект. Так что большая часть дня потрачена зря.
Система учета времени, которая трачет пустые траты времени, сама является пустой тратой времени.
Если же каждый работает только над одним проектом за раз, то учем выполненных работ становиться тривиальным.
Не получается ли так, что некоторые разработчики перестали получать кучу денег за овертайм?
Я поднял зарплаты так, что компенсации за овертайм перестали быть движущей силой. Прибавка была значительной во многих случаях. Никто на это не жаловался, никто не предлагал перейти на старую систему.Исследования показывают что денежные стимулы могут сделать производительность хуже, а не лучше, когда это касается такой сложной и творческой работы, как разработка софта. Вместо этого, просто платите людям достаточно, чтобы они не задумывались о деньгах. Вот тут короткая и очень клевая презентация на эту тему, must-see, — Drive: The surprising truth about what motivates us.
Платить людям за овертай было одной из самых глупых вещей из всех, это просто дало нам очень уставших разработчиков и “технический долг” (много кривого кода, недоделок и т.п., отложенного на потом)
Что было дальше?
Я написал книгу “Скрам и XP из окопов”. К моему удивлению, она стала очень популярна в сообществе разработчиков (я написал ее больше для себя, чтобы просто вынести все мысли из головы на бумагу) и с тех пор я уже потерял счет людям со всего мира, которые сказали мне, что моя книга вдохновила их сменить то, как они организуют свой процесс разработки софта. Очень клево, спасибо за отзывы!
Эта статья, это всего лишь другая сторона той итории. Самое важное в том, что мы никогда не смогли бы сделать то, что мы сделали, если бы не продолжали постоянно агрессивно убирать все пустые траты времени, с которыми мы сталкивались (отчеты о выполненных работах были только одним из примеров). Хмм… почему слово “Lean” сразу всплыло в моей голове? :o)
Это все было в 2006 году. С тех пор я ни разу не трогал и не заполнял никакой таблицы с часами — даже не смотря на то, что последние 4 года я занимаюсь консалтингом. Если будущий клиент поднимает этот вопрос, то я узнаю его реальную потребность и нахожу альтернативный способ ее закрыть.