Как стать автором
Обновить

Трекинг времени и его влияние на эффективность разработки

Уровень сложностиПростой
Время на прочтение4 мин
Количество просмотров6.5K
Всего голосов 12: ↑10 и ↓2+10
Комментарии11

Комментарии 11

Процессы, которые были на заводах в 20-ом веке могут не работать сейчас и это нормально.

Интересно, а куда делись эти заводы сейчас и про какие неработающие процессы идёт речь? На заводах стали работать по удалёнке?

Сейчас есть огромное количество способов грамотно следить за эффективностью команды. 

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

Полагаю, что главная ценность — это вовремя доставлять функциональности приложений и сервисов. 

Бизнес - это про деньги, маркетинг - это про подсаживание на постоянные траты для вашего продукта. А тут я вижу какой-то юношеский максимализм. Вы правда считаете, что всегда нужно делать приложения без багов? Тогда вы остались в нулевых. ;)

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

«Так приведите их и обоснуйте чем они лучше.»

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

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

«Трекинг ведут не для постоянного отслеживания, а для анализа, если вдруг такой понадобится. »

Если трекер делает скрин экрана, то это большой перебор. Следить чтобы работник работал - 8 часов, тоже перебор.

доверять работнику и смотреть по сделанной работе

Это вы очень зря про доверие. Смотреть по сделанной работе - это если у вас есть КПИ, строчки кода и т.д., иначе руководство должно разбираться в КАЖДОЙ узконаправленной должности и понимать ценность сделанной работы, а ещё важнее в творческой составляющей. И это совсем уж оторвано от реальности. Это как по количеству нот судить о музыкальном произведении.

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

Это если вы работаете командами а ля Скрам и т.п., это частный случай! А ведь разработка бывает не только в АйТи.

Если трекер делает скрин экрана, то это большой перебор. Следить чтобы работник работал - 8 часов, тоже перебор.

Перебор через что? Зависит от задачи и методов поощерения или наказания. Если вам укажут на исследования, которые подтвеждают, что отвлечения на другие задачи мешает достижению результата, то что вы в ответ аргументируете? Сам автор говорит, что офис его отвлекает, а дом этого нет. Противоречим сами себе получается.

Ну давайте представим, что вам во время операции хирург вдруг бросает всё и уходит, мотивируя, что это перебор. Есть виды работ, где это необходимо, охранник за пультом, например, а лучше представьте себе авиадиспетчера. Только 21 век во многих профессиях ещё не настал и вряд ли настанет так быстро.

И первое препятствие - это отсутствие умения объективно оценивать работу. Но так мы с вами до "Капитала" договоримся.

>Смотреть по сделанной работе

В чём тут проблема? Работа «сделана» означает что она принята потребителем этой работы, в случае производства это другой отдел. Кроме потребителей есть такой древний отдел под названием «Контроль качества», контролирует работу на соответствие заданным параметрам ещё до приёмки её заказчиком.

«КПИ» и прочие нововведения можно оставить высоко эффективным менеджерам. Есть работа измеряемая, к примеру количество единиц продукции в единицу времени, и не измеряемая – любая разработка. Но некоторым эффективным менеджерам очень хочется измерить и такую работу – отсюда появляются KPI на количество строчек кода / текста / исследований, закрытые задач и прочие удивительные показатели.

 

Доверие же строиться между руководителями – именно они договариваются о сроках и ресурсах на выполнение работы, своего рода внутренняя купля-продажа и придерживаются принципа «вассал моего вассала, не мой вассал». В такой системе руководитель озабочен только своим отделом, а вышестоящий менеджер «не лезет» в работу отдела, то есть занимаются только Эпиками, а не Таксками, которыми владеет руководитель отдела.

 

Откуда вы взяли что Скрам живёт не только в АйТи разработке? Он отлично себя чувствует и в разработке реального продукта. Но я не спорю, российская промышленность далека от передовых технологий…

методы мониторинга времени как на заводе, совершенно не подходят к современной разработке.

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

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

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

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

Кто-то очень умный сказал: «Чем больше отчётности, тем меньше доверия».

Несколько мыслей по этой теме:
Подобный учёт рабочего времени порой «сводит на нет» внутри командное взаимодействие между коллегами – каждый озабочен об отчёте за потраченное время на помощь друг другу.

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

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

У меня и у многих моих коллег такая система отчётности вызывает ощущения взаимодействия с работодателем по типу «раб – надзиратель».

PS: Довелось мне работать в одной компании с разработкой реального осязаемого продукта. Как-то раз сменилось начальство (не буду уточнять которое из них было более эффективным), а новое ввело правильно повременного отчёта за день, формата: задача – потраченное время.
Не малая часть персонала «разбежалась» уже в течение нескольких месяцев после такого нововведения. Хотя одна очень сообразительная сотрудница уже через пару недель навострилась писать отчёта на всю неделю вперёд по понедельникам, но всё равно ушла через полгода.
Я же после введения такого отчёта полностью перестал заниматься работой в нерабочее время, а занимался я тогда маркетингом. Поначалу писал отчёт по полчаса-час в день, а через месяц так же приспособился и навострился ваять их за 10 минут.

Подобный учёт рабочего времени порой «сводит на нет» внутри командное взаимодействие между коллегами – каждый озабочен об отчёте за потраченное время на помощь друг другу.

Я с таким сталкивался в реале. Чтобы написать вопрос чуваку в Слаке нужно сразу же, вместе с вопросом, отправлять ссылку на тикет в Джире. Иначе ответа можно и не дождаться.

Если трекинг носит не аналитический, а репрессивный характер, то вода все равно дырочку найдет: или сотрудники научатся фиктивную активность трекать, или работу поменяют.

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

Работодателю так удобнее. Зная, что работник будет работать 4-5 часов из восьми, делим его дневную ставку на восемь и платим за 4-5 настоящих часов. Профит. Можно даже умножить ставку раза в полтора, всё равно будет профит.

А если работник начнёт четырёхчасовые задачи трекать как восемь, то к нему возникнут вопросы.

как говорит один мой знакомый: "любую идею можно довести до абсурда"
так и тут, ну что за детский сад с дихотомией: хорошо-плохо, работаем-не работаем
ведь даже на токарном станке (если он не ЧПУ, а человек работает) общие нормы допускают довольно большой зазор по времени: от и до. и нормальное планирование руководством рабочего времени позволяет сотруднику и поговорить и покурить и план выполнить.

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

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории