понедельник, 6 февраля 2023 г.

[work.experience] Отчасти наболевшее: учет рабочих часов

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

Ирония, однако, в том, что за время существования нашей крохотной компании у нас был всего один контракт, в котором сумма работ была фиксированной. Все остальные проекты для внешних заказчиков мы выполняли по схеме time-and-material. Соответственно, заказчикам выставляются счета с указанием выполненных работ и затраченных часов.

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

Но, как говорится, с волками жить -- по волчьи выть :)

Постепенно привык. Теперь этот учет ведется как-то на автомате. Стало частью ежедневной рутины.

Однако, не смотря на то, что к подсчету потраченных часов попривык, с этой темой для меня все-таки не все так просто как хотелось бы.

Оказывается, проще всего считать часы когда ты занимаешься кодингом и отладкой. Тогда все понятно. Скажем, я знаю, что за час проведенный за компьютером, отвлекаюсь от работы минут на 15. Ну там на почту что-то прилетит, напоминалка какая-то выскочит, на RSDN или LOR заглянешь пока проект компилируется и т.д., и т.п. Получается, что если просидел не вставая два часа, то 1.5 часа чистого рабочего времени смело можно записывать в табель.

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

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

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

Тогда переключаешься на что-то другое. Грубо говоря, бьешь баклуши следующие минут 40-50, а то и час-полтора. Пока в голове что-нибудь не перемкнет и не забрезжит какая-то слабая мысль на горизонте. После чего опять минут 20-30-40 размышлений и новый ступор. И так может быть несколько дней подряд.

Вот как считать рабочие часы в такие периоды я до сих пор не понимаю. Считаю их честно. Т.е. если за 5-6 часов непосредственно думал над проблемой 1.5-2 часа, то и фиксирую именно 1.5-2 плодотворных часа, а не те 5-6 часов формального нахождения в офисе.

Есть ощущение, что это не правильно, и что это ведет к недополученной прибыли. Но пока что так. Пересилить себя не могу, ибо считаю, что честность -- лучшая политика ;) Хотя и дорогая :)))

В общем, исходя из опыта получается, что чистого времени фиксируется не так уж и много. В реально плодотворные недели по 23-25 часов чистого времени. В среднем же от 3.5-4 часа в день. Чистого времени, повторюсь.

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

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

Однако, считаю, что если в продуктовой компании разработчиков заставляют вести учет рабочего времени, то это заставляет задуматься о том, а вменяемое ли там руководство (да и исполнители).

8 комментариев:

Alex комментирует...

Если руководство заставляет разработчиков вести учет рабочего времени, это свидетельствует, прежде всего о том, что руководство мало что понимает в разработке. Для руководства это бизнес и ничего больше. Именно такие руководителя являются ярыми приверженцами модных технологий вроде скрама, аджайла, покер-планирования и прочих кришнаитских ритуалов. Сами по себе эти технологии не являются ни злом, ни благом - все зависит от умения их применять. Так же как кухонный нож - его использование зависит от того, в чьих он руках. Но подобные руководители берут из технологий управления только то, что доступно их пониманию и может быть оценено количественно - контролю времени. Если у вас в руках молоток, то все вокруг представляется гвоздями.
Доказать такому руководству, что элементарная на их взгляд задача, иногда не так проста как это кажется, обычно не удается. По крайней мере не с первого и не со второго раза. Да, обычно это, действительно, просто. Ну, скажем, в половине случаев это похоже на правду. Но оставшаяся половина может оказаться сущей засадой: тронешь здесь - выскочит там ("Щелкни кобылу в нос - она хвостом махнет" как говорил Козьма Прутков).
Разработчики в массе своей воспринимают обязанность вести учет времени как тяжкую обузу. Особенно если это делается на ежедневной основе. Ну не прет сегодня работа! Или отвлекли. В транспорте поругался и т.д. Сломался поток сознания и разработчик сел на мель.
Понятно, что без контроля времени работа может вообще остаться невыполненной. Но в этом и состоит мудрость и квалификация руководителя - планировать так, чтобы разработчик с легким сердцем делал любую работу, зная, что над ним не висит этот проклятый отчет об использовании времени :)

eao197 комментирует...

@Alex:

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

Или же бизнес состоит ровно в продаже жопочасов :)

Не, если серьезно, то когда разработка под заказ ведется по модели time-and-material (т.е. заказчик оплачивает трудозатраты исполнителя), то отчет по затраченным часам -- это очень прозрачный и понятный для всех сторон способ понять за что платятся деньги.

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

Alex комментирует...

> Не, если серьезно, то когда разработка под заказ ведется по модели time-and-material (т.е. заказчик оплачивает трудозатраты исполнителя), то отчет по затраченным часам -- это очень прозрачный и понятный для всех сторон способ понять за что платятся деньги.
У меня приятель работает как раз по такой модели. Что только не делают разработчики и их руководители, чтобы увеличить time. На изменение цвета надписи на кнопке уходит по 4 часа, при том, что работы там от силы на пару-тройку минут. Главное - найти лоха-заказчика, которому это можно впарить. И ведь находят!
Такой подход, к сожалению, безобразен. И по отношению к лоху-заказчику, и по отношению к своим профессиональным обязанностям. Первого обманывают, пользуясь его некомпетентностью. Вторые деградируют в морально-этическом плане. Но, как говорил один римлянин своему сыну: деньги не пахнут.

eao197 комментирует...

> У меня приятель работает как раз по такой модели. Что только не делают разработчики и их руководители, чтобы увеличить time.

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

> Главное - найти лоха-заказчика, которому это можно впарить. И ведь находят!

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

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

Так что в нашем случае доверие есть и оно работает.

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

sv комментирует...

Мне кажется, ответ на вопрос, как оценивать время своей работы, можно найти только поработав с другими людьми. Поработайте, посравнивайте. И если вы это сделаете, то заметите, насколько все гораздо проще, чем вы считаете. В индустрии очень много бездельников, но даже не бездельники работают далеко не так продуктивно, как вы считаете. Поэтому, ваша задача - быть просто лучше остальных. Если 95% разработчиков решили задачу за 3 часа, и еще 5 часов прокрастинировали, укажите свое время решения задачи в 7 часов и все, вы на вершине. Вы можете сказать, что "но это не честно". Но нет, вы же и сами понимаете, и сами тут же пишете, что работать продуктивно 8 часов подряд не возможно, так может быть те моменты прокрастинации между этими 8-ю часами тоже общепринято считаются "работой", просто вы об этом не знаете?

В общем, поработайте в команде, понаблюдайте за людьми, и вам очень многое откроется, так просто здесь это все не описать.

eao197 комментирует...

@sv

> В общем, поработайте в команде, понаблюдайте за людьми, и вам очень многое откроется

Для этого работу придется поменять, а этого в планах нет :)
Хотя, по нынешним временам, планы длиннее пару месяцев нет смысла строить.

XX комментирует...

Считаю нормальным учитывать часы работы с точностью до 5-6 минут. По идее 5-10 минутный перерыв в течении часа тоже должен считаться рабочим временем. Если мысли о рабочей задаче не отпускают на прогулке или перед сном - то это тоже нужно фиксировать как рабочее время. Если занимаешься поиском информации или самообучением, необходимым для решения рабочей задачи - то это рабочее время. А вот если час или два бесцельно читаешь Хабр (допустим), то это время не рабочее, хоть ты и сидел в офисе.

Кроме того, час работы специалиста одной квалификации не равен часу работы специалиста другой квалификации. Например, если час разработчика высокой квалификации реально стоит, допустим, 100$, а заказчик ему платит 20$, то будет честно и работать в 5 раз меньше в течении часа.

eao197 комментирует...

> Считаю нормальным учитывать часы работы с точностью до 5-6 минут.

ИМХО, точность меньше 15 минут могут обеспечить только люди, увлеченные тайм-менеджментом.