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