О человеческих часах

Надеюсь, все читали великолепного Брукса, ту его книжку с говорящим названием «Мифический человеко-месяц». Ну это как раз про то, что девять женщин могут родить ребёнка за один месяц. Или, цитируя Григория Остера: «Известно, чем больше денег вкладываешь в строительство, тем быстрее оно идёт. Родик вложил столько денег, что завод ремней построился буквально за один час». На самом деле нет.

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

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

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

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

И тут обнаружилась странность. Чем меньше я непосредственно писал код, и чем больше я занимался менеджерскими обязанностями, тем сложнее было связать часы, проведённые на работе, с конкретными задачами в таск-трекере. Вот тут я вроде этим занимался, вот тут — этим. А куда делись еще два-три часа? Так появлялись бесконечные (не потому, что их много, а потому, что они никогда не заканчивались) задачи со словом «communication» в названии. Ну или «management».

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

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

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

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

Почему я должен постоянно беспокоиться, чтобы на скриншоты не попал какой-нибудь не тот чатик? Нет, то, что посторонние чаты отвлекают от Работы — это другой вопрос. Нифига чаты не отвлекают. Уведомления отключены. К тому же, если я действительно застрял в решении какой-то сложной задачи, фиг меня отвлечешь, даже если встать рядом и орать на ухо. Но тут мне надо всегда помнить, что, когда я переключаюсь на чат с супругой, чтобы за две минуты обсудить планы на вечер, мне нужно остановить всебдящую тулзу.

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

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

А у вас какой расклад получается?

К чему это я? Я считаю, что повсеместное использование человеко-часов — абсолютное зло. Час работы конкретного человека над конкретной задачей не говорит ни о чём. Ни об эффективности работы этого человека. Ни о прогрессе выполнения задачи. Человеко-часы — это просто порочная привычка, к величайшему сожалению прочно засевшая в мозгах всех участников процесса разработки ПО.

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

Мы продолжаем использовать человеко-часы для расчёта заработной платы. Может, это удобно в каком-нибудь автосервисе, где все работы заранее определены производителем авто, и их трудоёмкость раз и навсегда задана в нормо-часах, и вот эти нормо-часы и оплачиваются. Но разве в программировании определены все задачи, которые приходится решать? Почему за час митинга по одному и тому же проекту менеджеру Пете заплатят в два раза больше, чем джуниору Васе, если Петя лишь спросил, как дела на проекте, а Вася полчаса распинался, как крокодил не ловится? Кто из них потратил больше сил? Сколько заплатят еще пятерым разработчикам, которые присутствовали на том же митинге, но не проронили не слова? А можно ли мерять меру участия в словах?

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

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

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

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

Между прочим, практика бездумной продажи часов разработчика исключительно как часов работы конкретного человека не важно над чем, главное, тому, кто платит деньги, носит весёлое название «body shop». В некотором роде это аналогично «Flesh Fair» из «И.И.»

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

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

Заказчики, за что вы платите деньги? За то, что менеджер Петя и джуниор Вася будут пытаться вам не соврать, что посвятили согласованное количество часов именно вашей проблеме? Или за то, что менеджер Петя и джуниор Вася (и не важно, кто там еще будет им помогать) действительно решат вашу проблему (или не решат, тут уже риски и репутация Пети и Васи) за оговорённые сроки и деньги? Неужели вы думаете, что сможете проверить, что озвученные Петей и Васей часы являются адекватной оценкой, и сможете удостовериться, что они потратили именно столько часов именно на вас? Может, у вас просто есть проблема, которую нужно решить за адекватный срок и за разумные, имеющиеся у вас, деньги? И, может, вам всё равно, сколько народу будет над этим работать и будут ли они спать ночами, если работа в конце концов будет выполнена?

Но как же без человеко-часов? Есть варианты. Например, то, что называется FFF (fixed price, fixed timing, flexible scope). Заказчик определяет лишь две цифры: стоимость и срок, и хочет, чтобы за указанную цену, в указанный срок, кто-нибудь решил его задачу наилучшим возможным способом. А сам обязуется постоянно следить за тем, что решение задачи действительно движется в благоприятном направлении. Исполнитель собирает команду разработчиков (а точнее — решателей проблем), которая с хорошей вероятностью сможет решить данную проблему в указанный срок. Берёт их зарплату за этот срок, добавляет ожидаемую прибыль (она же буфер на риски) и получает бюджет. Как только все цифры и желания у заказчика и исполнителя сойдутся, работа начинается. Не правда ли, две цифры — это проще, чем куча попугаев, помноженных на питонов?