Поощрение разработчиков программного обеспечения для отслеживания времени

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

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

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

Это поправимо.

Вовлеките их в планирование.

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

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

• Если у вас есть произвольный срок, установленный руководством, хорошие оценки подскажут вам, чего вы действительно можете достичь за это время. В качестве бонуса у вас есть несколько хороших графиков, чтобы убедить менеджера, что вы знаете, о чем говорите.
• Вы должны продумать проект более тщательно. В статье, на которую я ссылаюсь, говорится: «Вы должны разбить свой график на очень маленькие задачи, которые можно измерить за часы ». Поскольку вы задумывались практически о каждом аспекте проекта (надеемся, что пишете спецификацию !), У вас гораздо меньше шансов удивиться тому, о чем вы не подумали.
• Это делает вас лучшим разработчиком. Со временем вы увидите, какие задачи вы склонны недооценивать, поэтому вы можете потратить некоторое время на улучшение этих конкретных задач, а не на слепую оптимизацию.

Вы можете сделать это стандартным способом - морковь и палочки.

Морковь (и) в этом случае может быть «улучшена оценка будущего путем понимания нашей текущей скорости», но вам придется выполнить ее до конца.

Ваш комментарий о том, что они не часто участвуют в планировании проекта, может сделать это жестким предложением.

Наиболее высокоэффективным среди них, особенно если у вас есть последователи PSP , является то, что вы помогаете им стать лучше.

Самая распространенная палка (чтобы побить их, а не держать морковку перед собой) - это «обязательно, сделай это». Хотя не так много мотивации; по крайней мере, позиция ясна.

Наконец, программное обеспечение, которое вы используете, способствует их сдержанности? Это неуклюжий? Должны ли они искать временные коды в Системе A, прежде чем затем поместить свое время в Систему B? Является ли он слишком гранулированным, не учитывает ли он время выключения и требует ли он учета 8 часов в день? Сделайте это как можно более свободным от трения, чтобы также помочь принятию.

Удачи

По моему опыту, следующие проблемы с большинством программного обеспечения для отслеживания времени:

• Разработчик не имеет возможности или полномочий разбивать задачу на более легко оцениваемые подзадачи на лету.
• Там нет хорошего способа учета для подзадач вы не знали о , пока не начал работать над чем - то, ситуацией , которая приходит все время в разработке программного обеспечения и отладке.
• Затраченное время вводится после факта, когда трудно точно вспомнить, сколько целенаправленных усилий ушло на выполнение задачи и сколько ушло на встречи, вопросы коллег, коллегиальные обзоры и прочие накладные расходы.
• Нет хорошего способа учёта неотслеживаемых задач. В конце дня вы откладываете 8 часов, хотя 6 из них были потрачены на встречи и тому подобное?
• Нет хорошего способа учесть неопределенность в ваших оценках и сообщить о ней.

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

Хороший способ

Используйте программное обеспечение, которое на самом деле делает это простым и почти прозрачным, как, например, Mylyn. Объедините его с такими инструментами, как, например, часовая диаграмма выгорания.

Плохой способ

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

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

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

Отслеживайте свое время или не платите. Миллионы людей делают это (консультанты, юристы и т. Д.), Почему не могут?

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

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

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

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

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

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

Разработчики, которые избегают предоставления доказательств, обычно

• Обеспокоены тем, как это может быть использовано и / или
• Обеспокоены по поводу достоверности данных

Вот почему оценка очков и подбор рубашек в последние годы значительно выросли. Он учитывает весьма неопределенную природу процесса оценки и позволяет «магии» (то есть усреднению по неопределенностям) взять под контроль планирование.

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

Scrum также позволяет разработчикам контролировать скорость, что означает, что они дают обещание достичь того, что вы выберете из A, B и C или A, Y и Z. Когда они дали такое обещание, разработчики не любят терпеть неудачу; но если вы дадите им это обещание, им все равно. Это твоя вина, если это не так.

Я понимаю, что вы говорите, что не будете использовать переоценки таким образом, но насколько уверены люди в вашей команде?

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

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

Точно так же, если у вас есть инструмент для ввода дизайнов, вы можете перехватывать там.

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

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

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

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

Техника использует таймер, чтобы разбить периоды работы на 25-минутные интервалы, называемые «Pomodori» (от итальянского слова «помидоры»), разделенные короткими перерывами. Тесно связанный с такими понятиями, как временные рамки, итеративная и инкрементная разработка, используемые в разработке программного обеспечения, этот метод был принят в контекстах парного программирования. Метод основан на идее, что частые перерывы могут улучшить умственную ловкость.

Вместо того, чтобы убеждать их вводить свои номера, используйте программное обеспечение, которое работает без усилий. Я использую ScreenAware: https://www.screenaware.com/en/ Он автоматически отслеживает ваше время и присваивает его соответствующим проектам. Так что это всегда точно, и никто не должен больше угадывать

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