Тортик

Самый лучший подарок, какой только можно придумать -

Памятные даты

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

Считается, что тайм-шит это инструмент, который помогает руководителю понять чем же на самом деле занимался программист в течение дня. Строгий и эффективный инструмент контроля, дающий объективную картину происходящего. =)

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

Жаль, я не смог найти статью Тима Евграшина, посвященную тайм-шитам, там было несколько интересных выводов. А так же я не буду пытаться объять необъятное, и пытаться объективно оценить пользу от тайм-шитов со всех сторон, как в статье с хабра. Просто расскажу о нашей компании.

В нашей компании заполнение тайм-шитов не будет слишком эффективным.

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

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

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

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

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

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

Закончить хотелось бы фразой из Голдрата -

"Учёт затрат - самый большой враг продуктивности!"

Желаю вам хорошего дня и хорошего кода. А я пойду подготовлю себе шаблончиков для тайм-шитов с получасовой дискретой, посмотрим чем это закончится.

Мнение выраженное в этом сообщении является частным мнением и может не совпадать с официальной позицией компании.