среда, 3 июля 2013 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 комментария:

Александр Кунташов комментирует...

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

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

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

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

Те кто знаком, могут узнать в этом элементы технологии Управляемого внедрения Александра Белова. Мы у себя внедрили - заработало.

Green FiLin комментирует...

Я учитываю тот момент, что, возможно, я не вижу всей картины целиком и в этом есть какие-то моменты, которых я пока просто не понимаю. Так что тут я настроен не столько критиковать, сколько предложить несколько хороших практик из Agile. А про управляемое внедрение спасибо, надо бы пересмотреть в контексте ситуации.

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

временное говно.

Отправить комментарий