Впервые с необходимостью учета рабочих часов (т.е. фиксации в отдельном табеле сколько и чем ты занимался в течении рабочего дня) я столкнулся, наверное, в далеком уже 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:
> Если руководство заставляет разработчиков вести учет рабочего времени, это свидетельствует, прежде всего о том, что руководство мало что понимает в разработке.
Или же бизнес состоит ровно в продаже жопочасов :)
Не, если серьезно, то когда разработка под заказ ведется по модели time-and-material (т.е. заказчик оплачивает трудозатраты исполнителя), то отчет по затраченным часам -- это очень прозрачный и понятный для всех сторон способ понять за что платятся деньги.
В продуктовой же разработке (которую компания делает своими силами) ситуация другая. Здесь считать часы можно разве что чтобы навести порядок в разработке, если там уже случился бардак, в котором никто не разбирается.
> Не, если серьезно, то когда разработка под заказ ведется по модели time-and-material (т.е. заказчик оплачивает трудозатраты исполнителя), то отчет по затраченным часам -- это очень прозрачный и понятный для всех сторон способ понять за что платятся деньги.
У меня приятель работает как раз по такой модели. Что только не делают разработчики и их руководители, чтобы увеличить time. На изменение цвета надписи на кнопке уходит по 4 часа, при том, что работы там от силы на пару-тройку минут. Главное - найти лоха-заказчика, которому это можно впарить. И ведь находят!
Такой подход, к сожалению, безобразен. И по отношению к лоху-заказчику, и по отношению к своим профессиональным обязанностям. Первого обманывают, пользуясь его некомпетентностью. Вторые деградируют в морально-этическом плане. Но, как говорил один римлянин своему сыну: деньги не пахнут.
> У меня приятель работает как раз по такой модели. Что только не делают разработчики и их руководители, чтобы увеличить time.
Ага. Более того, там работа так устроена, что разработчиков, которые не могут расписать все положенные 8 часов в день, имеют всяко разно и разнообразно.
> Главное - найти лоха-заказчика, которому это можно впарить. И ведь находят!
Тут не все так однозначно. У нас текущий заказчик один из самых адекватных из всех, с кем доводилось иметь дело. Да и до этого все вполне себе вменяемые были, без закидонов, с пониманием предмета.
Но это может у нас специфика такая, т.к. и мы маленькие, и проекты делаем небольшие, объем, сложность и качество сделанного оценить можно, и заказчики не корпорации необъятных размеров.
Так что в нашем случае доверие есть и оно работает.
Но как бы дело было, если бы на нашей стороне было человек 20, а на стороне заказчика -- раз в 10 больше, даже и не знаю. Наверняка бы обе стороны приняли бы как данность, что погрешность измерений составляет далеко не единицы процентов.
Мне кажется, ответ на вопрос, как оценивать время своей работы, можно найти только поработав с другими людьми. Поработайте, посравнивайте. И если вы это сделаете, то заметите, насколько все гораздо проще, чем вы считаете. В индустрии очень много бездельников, но даже не бездельники работают далеко не так продуктивно, как вы считаете. Поэтому, ваша задача - быть просто лучше остальных. Если 95% разработчиков решили задачу за 3 часа, и еще 5 часов прокрастинировали, укажите свое время решения задачи в 7 часов и все, вы на вершине. Вы можете сказать, что "но это не честно". Но нет, вы же и сами понимаете, и сами тут же пишете, что работать продуктивно 8 часов подряд не возможно, так может быть те моменты прокрастинации между этими 8-ю часами тоже общепринято считаются "работой", просто вы об этом не знаете?
В общем, поработайте в команде, понаблюдайте за людьми, и вам очень многое откроется, так просто здесь это все не описать.
@sv
> В общем, поработайте в команде, понаблюдайте за людьми, и вам очень многое откроется
Для этого работу придется поменять, а этого в планах нет :)
Хотя, по нынешним временам, планы длиннее пару месяцев нет смысла строить.
Считаю нормальным учитывать часы работы с точностью до 5-6 минут. По идее 5-10 минутный перерыв в течении часа тоже должен считаться рабочим временем. Если мысли о рабочей задаче не отпускают на прогулке или перед сном - то это тоже нужно фиксировать как рабочее время. Если занимаешься поиском информации или самообучением, необходимым для решения рабочей задачи - то это рабочее время. А вот если час или два бесцельно читаешь Хабр (допустим), то это время не рабочее, хоть ты и сидел в офисе.
Кроме того, час работы специалиста одной квалификации не равен часу работы специалиста другой квалификации. Например, если час разработчика высокой квалификации реально стоит, допустим, 100$, а заказчик ему платит 20$, то будет честно и работать в 5 раз меньше в течении часа.
> Считаю нормальным учитывать часы работы с точностью до 5-6 минут.
ИМХО, точность меньше 15 минут могут обеспечить только люди, увлеченные тайм-менеджментом.
Отправить комментарий