Комментарии 54
Не очень понял суть вопроса :) Во-первых, чтобы вести учёт рабочего времени сотрудника и оплачивать его работу, во-вторых, чтобы у клиента была четкая картина по прогрессу на проекте, подтверждённая числами.
Да, можно включить таймер и заниматься своими делами, но потом фактически затраченное время не совпадет с оценкой и нужно будет выяснять, что случилось :)
В целом такое поведение довольно быстро всплывает, поэтому нет нужды пытаться это как-то контролировать, здесь есть определённая степень доверия.
Таймер автоматизирует подсчёт рабочего времени, а мы любим автоматизировать)) Считать в голове или куда-то записывать, когда ты начал работу, потом всё это высчитывать вместо того чтобы сразу переключиться на срочную задачу… такое, в общем. Человеческий фактор лучше исключать насколько это возможно.
Тут обычно маятник может начнутся в другую сторону, когда оценки времени ставятся очень оптимистично. А т.к. точного учёта времени нет, то исполнитель, чтобы успеть, работает более 8 часов в день. При этом, судя по моему опыту, один и тот же человек, на аналогичных задачах разброс по времени может быть от 1,5 до 3 раз.
Например, вчера «погулял» сегодня «втыкал» в задачу два часа, хотя она делается за 15 минут. Ну или если решил при простуде не оформлять больничный, а поработать. В общем куча факторов, когда реальная стоимость по времени у разных людей в разных обстоятельствах, может скакать очень сильно на одну задачу. При этом они не будут «филонить» и наоборот будут добросовестно работать.
Уж извиняйте, отвечаю с позиции реального удаленщика с этими чертовыми таймерами. По гладкому ничего не бывает, по мне так лучше всего иметь статику в качестве зп за месяц например, не опасаясь что-то потерять из-за обстоятельств или сверх меры стремясь заработать. В таком случае просто делаешь работу, а не отвлекаешься на слежение за своим оплачиваемым временем.
Плюсом к этому то, что нагрузка по задачам идет неравномерная. В эту неделю на фултайм даже слишком отсидел, в другую отдыхал практически, т.к. серьезных задач нету. А париться о том, что «я вроде не против был, а тут ничего» остается на совести работника. Работодатель в такой ситуации с радостью заплатит 0.
Получается негативный моральный долг, когда ты каждый свой час работы меряешь. Лучше к этому вообще не прибегать, а по человечески работать.
Трекер не делает человека ответственным.
Задачи декомпозируются так, что она не может занимать более 8 часов.Это очень странное утверждение. В реальности есть огромный пласт задач, которые нереально декомпозировать до задач занимающих 8 часов или менее. Более того, время работы над ними часто бывает вообще непрогнозируемым. Например проблемы с производительностью. И таких задач, в зависимости от проекта, может быть достаточно много.
Ситуация вполне реальная, но мне кажется, что в повседневной работе devhub'а она обычно не встречается. Платформа и специфика заказов таковы, что можно получать ощутимые результаты для проекта за считанные часы.
сидеть неделю без гипотез нет смысла. если у человека нет идей что делать, возможно это не задача его уровня.
Гипотезы-то сформулировать можно, вот только формировать десяток гипотез, а потом сидеть их проверть глупо. Ибо «выстрелить» может уже первая гипотеза. А еще в ходе выяснении, например, третьей гипотезы вылезет дополнительная информация, которая позволит сформировать одинадцатую гипотезу, которая будет более вероятной чем предыдущие десять. Поэтому рационально решать задачу последовательно. Это не полноценная декомпозиция, в которой вы сначала формирруете список подзадач, а потом их решаете, а именно последовательное решение задачи, когда задачу N имеет смысл формировать только после решения задачи N-1.
Вообще, исследовательские задачи обычно крайне плохо поддаются декомпозиции.
гипотезы можно формировать последовательно, одну за другой, никто не запрещает, да это в общем и очевидно.
«Вообще, исследовательские задачи обычно крайне плохо поддаются декомпозиции.» — это вопрос опыта.
«Вообще, исследовательские задачи обычно крайне плохо поддаются декомпозиции.» — это вопрос опыта.Это не вопрос опыта, это вопрос типа задачи. Исследовательсткие задачи отличаются от задачи реализации именно тем, что в них заранее неизвестен результат и путь к нему.
я не писал, что вы писали, «что «у человека нет идей что делать»», читайте внимательно.Тогда к чему вы вообще подняли эту тему в ответ на мой комментарий?
Лично я не люблю скриншоты, по мне так это уже больше в сторону паранойи) Отслеживание активности по клавиатуре туда же. Разработчик может 20 минут тупить в экран, обдумывая решение задачи, гуглить, а эффективное решение в итоге займет 1 минуту. Что здесь дадут понять скриншоты и процент активности за временной промежуток, я затрудняюсь сказать :)
В ходе работы удаленной команды из моего опыта много времени тратиться на коммуникаци, это время все равно считается потраченной на задачу? и есть ли какие-то задачи, куда уходит время на работу с почтой, и прочие пожиратели времени?
Куча Email ов на каждый апдейт задачи?
А не пробовали доверять оценку задач тому, кто её делать будет?
Оценка — понятие относительное :) Один разработчик оценит в большую сторону, другой в меньшую. Обычно менеджер с лидом садятся и вместе идут по пулу новых задач, дают объективную оценку на основе предыдущего опыта.
Если доверить оценку неопытному разработчику, велика вероятность, что он, во-первых, сделает чересчур оптимистичную оценку, во-вторых, упустит какие-то моменты в реализации и на выходе получим неоптимальное решение задачи. Поэтому, если есть спорные моменты, лид с разработчиком также пересматривают оценку по необходимости.
Ну и в конце концов стопроцентной гарантии выполнения в срок грамотная оценка не даёт, так что она скорее выступает в качестве ориентира.
Есть люди, которые работают «на подхвате». Это менеджеры, лиды, архитекторы. У тебя вроде и есть «список добрых дел на сегодня», но в любой момент может всплыть проблема вселенского масштаба и тебе срочно нужно переключится. При этом нужно остановить таймер на текущей задаче, создать новый тикет (т.к часто обращение без тикета) и начать в нем фиксировать время.
Когда таких переключений контекста в день случается много тебе очень сложно переключатся между таймерами и в итоге сотрудник забивает на это и в конце дня выставляет время наугад.
У всех, кто «на подхвате», есть недельные задачи, куда списывается время на микроменеджмент. У меня задача всегда открыта в припиненом табе, куда можно быстро переключиться. Для статистики, в апреле команда сделала ворклоги в 39 коммерческих и внутренних проектах, в среднем РМ залогировал в 11, HR в 13, лид по фронтенду в 10 проектов.
Нюанс только в том, что нужно понимать сколько задач данный разработчик способен сделать за спринт.
А то если вводить логирование времени для оплаты почасовки, то даже неосознанно, но врать будут почти все.
По поводу вранья, может удивительно, но это так не работает. Мы собираем очень много данных о времени, что позволяет выявлять аномалии. Но главное здесь отношения — если ты открыто доверяешь человеку, то ему сложнее переступить черту морали. Скорее у нас возникает иногда проблема, что кто-то может недологировать, например, изучая новую для себя область. Это рабочий процесс и должен логироваться также, как при работе в офисе.
Не совсем понятно зачем его логировать вообще, особенно если есть компетенции и оценки задач спускаются сверху. В таск-трекере вполне можно смотреть время начала работы над задачей и время и передачи дальше и по нему смотреть сколько задача была in progress
В методичке для Императоров Всея Планеты под названием "Город Солнца" говорится, что программисты пишут код не по принуждению или за чашку риса, а по зову сердца, по велению души, по вдохновению.
Я у себя этот вопрос решаю просто. У каждого сотрудника есть определённый ежемесячный доход, который ему нужен для жизни. Это может быть фиксированная сумма, а может быть что-то плавающее. Но в любом случае оно плавает в определённых пределах. Соответственно, можно получить стоимость каждого часа содержания сотрудника — не важно, работает он, спит или играет в покемонов. Например, при ставке 100 тр/месяц стоимость каждого часа будет 100 000 р /(30 * 24 часа) ≈ 140 р/час. Таймер для сотрудников включен всегда — и ночью, и на выходных, и на праздниках.
Я могу за любой промежуток времени посмотреть что сотрудник сделал полезного и сколько компания на это потратила денег. Если виден профит для компании, то мне не важно сколько из этих часов было отработано, а сколько было потрачено на сон и покемонов. А если профита не видно, то надо или что-то менять, или прощаться друг с другом.
Непосредственный подсчёт отработанного времени хорош только с точки зрения психологии — по нему легче отчитываться перед заказчиком. Так исторически сложилось, что это — привычная для всех схема. Но насколько она эффективна для PMа в качестве инструмента контроля? Лично мне она только мешает, потому что, как уже многие заметили в других комментариях, трудно замерить какое время было рабочим, а какое — нет. Ещё более трудно понять где границы задачи и сколько времени в итоге займёт её решение. И все эти трудности приходится решать PMу в ущерб реальным полезным для проекта задачам.
С помощью Asyncio команда делает все бэкенды асинхронными.
Боже, зачем???
В офисе есть иллюзия контроля — на удаленке ее нет. Разговор с Девхаб