Как программист, вы обязаны делать расписания? [закрыто]

Расписания - это то, что мне никогда не нравилось, но тем не менее это требование в моей компании. Они не так сильно меня беспокоят, но, похоже, они действительно перемалывают чужие вещи. Я полагаю, у меня есть несколько вопросов, и обратная связь будет отличной.

1. Требуется ли вам составлять расписания, если вы не являетесь подрядчиком? (Это мне понятно).
2. Какова гранулярность расписаний, с которыми вам будет удобно или которые вы используете? (например: все записи должны быть не более двух часов).
3. Будут ли временные таблицы учитывать ваши причины отказа от работы или ухода с текущей?
4. Как управление в вашей организации оправдывает использование расписаний, если вы не выставляете счета клиенту?

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

1. Как бизнес большая часть нашей работы выполняется на основе времени и материалов. Без расписаний это явно не работает. У нас есть 10 клиентов и целый ряд различных проектов и продуктов, но мы недостаточно велики, чтобы посвятить людей клиентам или проектам на полный рабочий день, а это значит, что мы должны каким-то образом определить, сколько времени понадобилось. Даже если управлять командой не так, вам все равно нужно понимать, что и на что нужно время. Думаете, что старое приложение, которое используют парни из почтового отделения, требует больше времени для поддержки, чем оно того стоит? Что делать, когда кто-то спрашивает, сколько работы было добавлено в функцию X на новом веб-сайте, что удвоило продажи? Или когда ваши разработчики говорят, что вам следует нанять кого-то другого, и вас попросят рассказать, что они делают, чтобы помочь оправдать это?

2. Категории существуют для всех разумных «неработающих», включая наставничество, общие технические обсуждения, поддержку, встречи и так далее.

3. Исправление ошибок - мы записываем время против всего проекта, а не за ошибкой. Это, как правило, делает вещи намного проще - потратьте день на исправление ошибок, 7,5 часов исправление ошибок идет вразрез с проектом, и все готово. Не нужно пытаться понять, как оно было поделено между 13 исправленными вами ошибками.

4. Когда мы их реализовали, я пообещал, что никто не будет наказан / вознагражден за то, что было в их расписании, если оно было точным. Таким образом, нет отзывов в обзорах, основанных на прибыльности или использовании или что-либо еще. Это означает, что нет стимула искажать.

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

6. Если мне не нравится то, что я вижу - например, кто-то потратил слишком много времени на задачу X - расследование заключается в том, что мы можем сделать, чтобы сделать X быстрее, а не в том, чтобы что-то делать с расписанием.

7. Знание того, сколько времени вы потратили на то, чтобы что-то сделать, - отличный способ улучшить оценки.

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

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

Я не получаю вещь против расписания вообще. Расписания - это то, что заставляет вас получать деньги. Нет расписания, нет денег. Мне нравится получать деньги, поэтому мне нравятся мои расписания. У меня никогда не было расписания, на заполнение которого уходило больше пяти минут в день. Честно говоря, в моем дне гораздо больше раздражающих вещей, чем пятиминутное расписание.

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

Это также становится очевидным, если кто-то просто не производит.

Несколько запросов в трекере ошибок также помогают показать, где что-то может быть забито.

Мы бы предпочли, чтобы программисты по возможности избегали административных задач и верили, что люди делают свою работу.

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

Я за то, чтобы относиться ко взрослым как к взрослым.

Если вы не платите клиентам по часам, или если вы не являетесь подрядчиком, оплачиваемым по часам, я бы не ожидал, что заполню табели учета рабочего времени. По моему опыту, они контрпродуктивны - да, вам, как правило, нужно отслеживать количество ресурсов, выделяемых на проекты, но это может быть приблизительно ежемесячно («10 дней для проекта X и 9 дней для проекта Y и т. Д.»). Преимущества чего-либо более гранулярного часто перевешиваются стоимостью их записи, и, если они могут быть использованы в качестве палки, чтобы побить персонал, персонал просто запишет то, что является приемлемым, а не то, что является точным.

Другим непредвиденным недостатком для компаний является то, что если вы начнете следить за персоналом, вы, возможно, обнаружите, что начинаете регистрировать, сколько дополнительного персонала делают! Если вам платят за 40 часов и отслеживают за 40 часов, приходите через 40 часов - это невероятный стимул просто пойти домой. Персонал часто перестанет делать это немного больше, что может иметь значение.

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

На моей предыдущей работе мне приходилось учитывать каждые 15 минут. Это была компания, занимающаяся веб-разработкой, и на каждого из нас была возложена задача. Каждое задание имело определенное количество часов. Мы разделили общую цену, которую мы взяли с клиента, на 100 долларов в час, чтобы получить общее количество часов, доступных для проекта.

Если мне дали 10 часов для выполнения моих задач, и это заняло у меня 15 часов, то я должен компании 5 часов сверхурочной работы. Я использовал ежедневник из Франклин Кови, чтобы следить за временем.

Я работаю веб-разработчиком / менеджером проекта в небольшой компании (всего 10 человек), и каждый, включая генерального директора, должен записывать, что они делают. Все, что занимает более 5 минут, должно быть зарегистрировано.

Типичное расписание будет выглядеть так:

07:46 - 08:01: Клиент A - Проект B - Программирование - Необязательное примечание
08:01 - 08:38: Клиент B - Проект C - Исправление - Необязательное замечание
08:38 - 08:46: Клиент B - Проект D - Управление проектами - дополнительное замечание
08:46 - 09:00: клиент A - проект B - поддержка клиентов - дополнительное замечание
...

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

Я не делаю табель рабочего времени. Существуют конкретные проекты, в которых я отслеживаю оценки относительно фактического времени (я не использую таймеры). Это не обязательно, но я чувствую необходимость работать над моей способностью оценивать.

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

Программное обеспечение, используемое для расписаний, совершенно отстой, но мне все еще требуется около 5 минут, чтобы заполнить расписание, потому что они находятся на очень высоком уровне: 8 часов в день, отмечают выходные / больничные дни и помещают некоторые заметки о том, что работал над в течение недели. Я делаю заметки каждый день, поэтому у меня не займет много времени придумать несколько строк для ввода в расписание.

1. Да, сотрудники обязаны составлять табели учета рабочего времени, и я не вижу ничего необычного в этом.
2. Обычно они разбиты на различные категории, например, поддержка или какая-то важная функция, например поиск по сайту, с минимальной продолжительностью 15 минут на каждую запись, что составляет 0,25 часа.
3. Нет, расписания - это просто административная функция, которую я привык воспринимать как часть моей работы. Может быть интересно разбить мою работу на различные группы, такие как административная работа, поддержка и разработка.
4. Есть несколько разных оправданий того, что разработчики делают расписания:
   1. Существуют различные правила учета того, как некоторые расходы можно капитализировать и амортизировать, чтобы они лучше смотрелись в бухгалтерских книгах, или, по крайней мере, это то, что я помню, услышав их пару раз.
   2. Количественная оценка нашего распределения времени позволяет руководству увидеть, сколько времени потрачено в различных областях, которые в некотором смысле могут быть использованы для стратегического планирования. Если есть группа разработчиков, которые тратят много времени на поддержку, то, возможно, имеет смысл создать новую группу поддержки, которая возьмет это на себя, чтобы привести пример здесь. Другая мысль заключается в том, что, хотя мы являемся внутренними работниками, все еще остается вопрос о том, из какого бюджета поступают наши зарплаты. Если мы в основном выполняем проектные работы, то это выходит за рамки бюджета проекта, который, возможно, не совпадает с бюджетом поддержки.

Я должен заполнить несколько расписаний.

Сначала есть расписание, которое идет в HR. Этот график просто показывает, работал / не работал, и используется для отслеживания ВОМ и больничных дней. Таким образом, он всегда заполняется кратно 8 (весь день или работает весь день).

Тогда есть расписание, которое идет в бизнес. Я занимаюсь разработкой программного обеспечения в крупной корпорации; большинство (99%) наших проектов предназначены для внутренних пользователей. Эти проекты оплачиваются пользователям на почасовой основе; таким образом, проект, скажем, для юридического отдела будет оплачиваться из бюджета юридического отдела. Этот график является наиболее политизированным; руководство ИТ-отделов вынуждено отводить как можно больше своего времени проектам, а владельцы проектов - отводить ИТ-отделам как можно больше времени (т. е. на встречи персонала, неформальное обучение и т. д.). Кроме того, перед выполнением какой-либо работы над каким-либо проектом, он «оценивается» и выделяется определенный «бюджет» часов. Таким образом, чтобы растянуть часы, все стороны должны проявить творческий подход к расписанию; отметка 8 часов в один и тот же день для одного и того же проекта вызывает красный флаг, который заставляет 3+ менеджеров поразить ваш куб. Сверхурочное время НИКОГДА не помечено, поскольку оно не имеет смысла (моя зарплата такая же, и она уменьшает доступные часы быстрее). Точность в этом расписании может нанести вред вашей карьере.

Наконец, есть расписание проекта. Это тот, который идет владельцам проекта; это не в разбивке по дате, но по часам. Так что это лист с надписью «Я потратил 9 часов на ваш проект на этой неделе; задачи A и B были выполнены, а ошибки X и Y были исправлены». Этот график - работа полной беллетристики; учитывая, что он получает свой номер часов из предыдущего расписания, соотношение задач к времени совершенно неточное. Тем не менее, этот график действительно используется только для определения того, достигли ли мы вехи X за определенный час использования Y, так что это более общий показатель прогресса, чем что-либо еще.

Две работы назад я заполнил табели. Они были сделаны для того, чтобы регистрировать оплату (нам платили сверхурочно) и выставлять счета клиенту (большая работа была T & M) и проверять предположения и фактические данные по проектам с фиксированной ценой. Я также нашел, что они полезны для регистрации некоторой моей собственной информации, вместо того, чтобы вести личный журнал против журнала расписания. Это работало отлично.

Однажды назад я пытался использовать табель учета времени таким же образом (условия были очень похожи), но в этом случае компания подвергала бы сомнению каждую мелочь в расписании. У меня были телефонные разговоры о том, что я поместил в свое расписание, и которое длилось дольше, чем указанное время. Я перестал записывать точное время, потому что это было абсурдно. Другие люди, похоже, тоже лежали в своем расписании, когда их допрашивали.

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

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

К сожалению, да.

Но не только один табель. Мы должны:

• Заезд и выезд по прибытии / отъезде
• Заполните табель для нашей материнской компании в конце месяца
• Наше идиотское правительство ( Хорватия ) недавно добавило еще одну неприятность: заполнение еще одного ежедневного расписания. Зачем? Таким образом, они могут отправить «проверку», чтобы украсть ваши деньги, если каждый сотрудник не заполнил их полностью.

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

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

Для них табели времени абсолютно бесполезны.

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

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

Я ненавижу заполнять их на работе, ненавижу со страстью ... что могло бы объяснить, почему я сейчас на три месяца отстал. У меня есть мои электронные письма, календарь, задачи в нашем программном обеспечении для отслеживания задач, проекты для добавления в наше «более крупное» программное обеспечение для отслеживания проектов. И все же они по-прежнему настаивают на заполнении расписания, которое ссылается на проекты / задачи в других программах. Это просто беспорядок.

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

Тем не менее, фриланс, у меня нет проблем с их заполнением. Я держу файл Excel с простым «дата, комментарий, часы». Это просто, это быстро , и это работает намного лучше.

Я не пытаюсь уложиться в сроки, установленные менеджером и настолько смехотворно случайные, что кажется, что кости были брошены, потому что со мной не советовались. Задача A, я получаю 2 часа ... но я знаю, что это займет день. Задание B Я получу за 20 часов ... но я знаю, что смогу справиться с этим за 15 минут.

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

1. точнее оценить подобные задачи
2. хорошо планируйте задачи, чтобы занять себя в течение недели, и
3. знать заранее, если они пропустят какие-либо сроки

Кроме того, стоимость проекта может быть отслежена.

Однако неизменно всегда одна проблема быстро появляется. Вот шаблон последовательности событий:

1. Руководство получает запах «измеримости». Они воображают, что это инструмент управления.
2. Зарегистрированные часы будут подвергнуты сомнению, объяснения будут запрашиваться для любого числа, большего, чем некоторое число (скажем, 6), все в смысле ложного контроля и управления.
3. Затем команда будет сравнена и сопоставлена ​​с тем, кто ведет больше часов. Результат будет контролироваться с точки зрения потраченных часов.
4. Они будут нанимать координатора табеля или какую-то другую роль, чтобы помочь этому процессу.
5. Этот человек, чтобы доказать свою точку зрения, добавит еще несколько полей в шаблон и дополнит процесс . Теперь время, затрачиваемое на табель рабочего времени, неожиданно увеличивается в четыре раза.

Таким образом, система, которая когда-то была предназначена для помощи программистам, становится узким местом.

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

Единственный раз, когда я не возмущался заполнением расписаний, это когда я работал в команде, использующей XP. Я полагаю, это было потому, что

1. эти карточки заполнялись как часть стоящего собрания каждое утро (это был первый раз, когда я действительно мог видеть собрания, имеющие высокий результат / время)
2. На самом деле я мог видеть результаты используемых усилий (для расчета времени, необходимого для выполнения будущих задач)

OTOH, я использую самодельный лист Excel, чтобы отслеживать свое сверхурочное состояние (и то, что я делал каждый день) в течение более десяти лет. Поэтому в настоящее время я обычно заполняю расписание в пятницу перед тем, как уйти из компании, копируя из моего листа Excel.

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

Из всего, что он / она знает, я мог бы просто скопировать / вставить кусок кода из блога, который решает трудную проблему в первые десять минут, и потратить оставшееся записанное время на чтение интересных дискуссий на P.SE.

Мы не работники хлопковых плантаций и не должны рассматриваться как таковые.

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

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

Проблема с расписаниями в типичной работе программного обеспечения состоит в том, что работа слишком динамична, чтобы вписываться в маленькие приятные пакеты. Например, в моем текущем выступлении: в обычный час я мог бы потратить 17 минут на ответы по электронной почте от Marketing, 11 минут на вопросы из службы поддержки по поводу некоторых проблем с клиентом, 12 минут на помощь новичку и 20 минут на работу. официальный вопрос ЧР, который может быть четко расписан. Смешайте эти интервалы случайным образом, и у вас будет типичный час старшего разработчика.

Конечно, не каждый час каждого дня подобен этому, но это достаточно часто, чтобы делать табли практически бесполезными. Если вы не пытаетесь измерить, сколько времени затрачивается на конкретную оплачиваемую задачу (чего здесь никогда не бывает), это, по сути, пустая трата времени (как времени разработчика, так и времени платежной ведомости).

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

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

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

1. Я забыл их. Девять раз из десяти я заканчиваю тем, что забываю на пару дней, а затем возвращаюсь и заполняю ее в основном неточной информацией.
2. Я взрослый человек, который очень способен распределять свое время. Если я потрачу слишком много времени на что-то, я сообщу своему менеджеру. Я не нуждаюсь в них , чтобы сказать мне , когда я трачу слишком много времени на что - то.

Наше приложение расписания также используется для отслеживания отчетов об отпусках и расходах.

Ввод времени осуществляется с точностью до 1/2 часа. Это сделано для целей отчетности старшим менеджерам. Некоторые разработчики отказываются делать это, и поэтому в конечном итоге перед ними ставится задача ежеквартально прекращать работу и своевременно обновляться. Я пытаюсь напомнить ребятам, что если они потратят 12 часов в день, и они напишут 8 часов, идиотам наверху придет идея, что нам вообще не нужны новые разработчики - мы справимся с нагрузкой. У нас был марш смерти, который включал 7-дневную рабочую неделю в течение многих месяцев прошлой зимой. Половина разработчиков написали 40 часов в неделю в приложении для составления отчетов, в то время как некоторые из нас сообщили реальные цифры. В соответствии с федеральным законом, программисты «освобождаются» (что означает освобождение от сверхурочной работы в случае отсутствия профсоюзного контракта, и наоборот), поэтому если мы сообщаем о сверхурочной работе, нам не платят сверхурочно, но цифры все равно будут отображаться в отчетах.

Время, потраченное на работу над ошибками и новым кодом, отслеживается (вроде) в Team Foundation Server, и мы отслеживаем его только с гранулярностью 1 целый день. Это мы пытаемся сделать, чтобы лучше оценить, сколько времени потребуется, чтобы сделать что-то, поскольку наш процесс оценки отключен на -25% до + 1000%. На данный момент метание дротиков в календаре по комнате примерно так же точно, как и наши процессы оценки.

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

Я заполнил табели рабочего времени, как на полный рабочий день, так и в качестве подрядчика, в течение почти десятилетия, на 4 различных работах, поэтому нахожу небольшое трение в использовании тогда, однако я не верю в то, чтобы быть слишком увлеченным мелочи задач. Самое гранулированное, что я когда-либо пойду, это 1/4 часа, и это редко.

Однако недавно я использовал Grindstone для отслеживания того, что я делаю (к счастью, моя нынешняя должность позволяет мне отправлять свой собственный график, а не заставлять заполнять собственную систему, основанную на интрасети).

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

Мне никогда не приходилось заполнять расписание и не думаю, что я присоединюсь к компании, которая потребовала бы от меня этого. Во всех компаниях, где я работал, меня всегда судили по тому, что я сделал, а не по тому, сколько времени это заняло . Результаты и производительность намного важнее, чем то, сколько времени понадобилось, чтобы их получить. На самом деле, первое включает второе: если бы я сделал столько же за год, как другой разработчик на аналогичной должности за месяц, моя оценка, вероятно, была бы не очень хорошей. И наоборот, ничего не получается: зная, что один человек провел на работе 60 часов на этой неделе, а другой потратил 40, недостаточно, чтобы сделать какое-либо осмысленное суждение. Некоторые из самых эффективных разработчиков тратят меньше всего времени на работе именно потому, что они эффективны.

Более того, я был наемным работником на каждой работе, поэтому мне не платили больше или меньше, потому что я потратил больше или меньше часов. Так что информация в расписании никогда не будет в моих интересах. Наконец, какое у вас дело, чем я занимаюсь, чтобы завершить проект? Если я буду производить лучшее программное обеспечение в компании, но вы обнаружите, что я бродю по сети 4 часа в день, вы меня уволите? Откуда ты знаешь, что веб-серфинг не важен для моего умственного процесса? Более того, даже если бы я занимался веб-серфингом 4 часа в день, я бы, вероятно, не поместил бы его в свое расписание, что означает, что информация в любом случае довольно бесполезна. Я думаю, что у меня возникнет соблазн заполнить его BS и передать в конце недели свой отчет TPS ...