Как справиться с хроническими проблемами времени?

Question

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

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

Мои вопросы:

1. Какие виды наказаний за превышение срока являются эффективными?
2. Какими способами я могу заставить этого сотрудника контролировать его действия (оценки времени и т. Д.)?

UPDATE : На основании ответов; вот что я понял.

1. Наказание - плохая идея.
2. Для работника естественно быть неспособным исправить проблемы оценки без вмешательства.
3. Не устанавливайте крайние сроки, если не будет последствий для компании (потерянный контракт), если они не будут выполнены к тому времени.
4. Используйте доступные методы (Agile, контрольный список Джоэла), чтобы помочь разработчику лучше оценить.

Спасибо за ссылки и информацию. Также спасибо за обновление моего мышления.

Answer 1

Не думаю, что проблема в том, что он пропускает эти сроки.

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

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

Answer 2

Есть интересная статья Джоэла Спольски: Планирование на основе доказательств

1) Перерыв вниз

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

Это заставляет вас на самом деле понять, что вы собираетесь делать. Напишите подпрограмму foo. Создайте это диалоговое окно. Разобрать файл Fizzbott. Отдельные задачи разработки легко оценить, потому что вы уже написали подпрограммы, создали диалоги и проанализировали файлы.

Если вы неряшливы и выбираете большие трехнедельные задания (например, «Внедрите Ajax Photo Editor»), то вы не задумывались о том, что собираетесь делать. В деталях. Шаг за шагом. И когда вы не думали о том, что собираетесь делать, вы не можете знать, сколько времени это займет.

Установка 16-часового максимума вынуждает вас создавать чертову функцию. Если у вас есть волнистая трехнедельная функция под названием «Редактор фотографий Ajax» без детального дизайна, я извиняюсь за то, что вам ее сломали, но вы официально обречены. Вы никогда не думали о шагах, которые он собирается предпринять, и вы наверняка забудете о многих из них.

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

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

И, конечно, меньшие итерации и большая детализация с задачами. Установите максимальную продолжительность задачи 1 день. Это правило у нас есть.

Answer 3

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

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

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

Answer 4

Какие виды наказаний за прохождение какие сроки эффективны?

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

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

Помогая ему найти правильный способ оценки.

Answer 5

Во-первых, убедитесь, что вы абсолютно прозрачны в своих требованиях.

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

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

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

Помните, что вы выполняете требования, но разработчик ВСЕГДА делает оценки и не должен склоняться к тому, что "мы можем сделать это быстрее", если вы также не указываете функциональность, которую следует отбросить.

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

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

Вы ДОЛЖНЫ знать, сколько времени было потрачено на выполнение чего, точно, прежде чем вы сможете узнать, где был ползучий, или что можно с этим сделать.

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

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

Это поможет вам выяснить причину проблемы. Точное понимание проблемы, скорее всего, станет фактическим решением.

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

Наказание и принуждение являются подходящими ответами на умышленное правонарушение в определенных ситуациях.

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

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

Answer 6

Хорошо, это довольно часто - разработчики настроены оптимистично. Задача менеджмента - справляться с этим. Если кто-то должен быть наказан, это менеджер (вы?)

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

Когда я был молодым, мой первый хороший менеджер справился с этим следующим образом:

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

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

Затем, перед составлением своего графика, он удвоил все мои оценки (не сказав мне).

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

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

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

Провал проекта или графика Виртуально НИКОГДА не виноват разработчик (за исключением нескольких хронических случаев, когда он на самом деле не поддается исправлению или не имеет какой-либо ценности и нуждается в увольнении). Менеджер принял плохие решения, либо наняв разработчика, доверяя ему, управляя им, либо укомплектовывая персонал проектом.

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

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

Answer 7

На ваши вопросы:

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

Но у меня есть несколько вопросов, о которых, я думаю, вам нужно подумать.

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

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

Answer 8

Мотивация

Прежде всего: прочитайте Peopleware

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

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

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

Оценка

Как указано выше, оценки являются оценочными. В нашей команде мы не делаем никаких индивидуальных оценок, мы делаем оценки как команда. (Я немного неохотно называю то, что мы делаем, Scrum, но большинство из них пытается подражать, если не меньше). Я думаю, что это действительно отличный способ сделать оценки: каждому члену команды дают колоду карт, состоящую из цифр 0 , 1 / 2,1,3,5,8,13,20,40,60,100 и при оценке задачи каждый разработчик выбирает карту (карты скрыты до тех пор, пока все не выберут карту, чтобы избежать влияния на оценки) и среднее значение выбранные карты принимаются за оценку.

Обратите внимание, что числа становятся все менее точными. Это сделано специально, потому что большие оценки по необходимости менее точны.

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

Как предписывает Scrum, разработка выполняется в течение двух недель, после чего новая версия развертывается в производственной среде. После каждого спринта мы берем сумму оценок выполненных задач и делим ее на запланированные рабочие дни для спринта. Этот фактор является основой для оценки того, сколько «идеальных человеко-дней» команда может провести за двухнедельный период.

Фактические рабочие элементы, выполненные отдельным разработчиком, не нуждаются в оценке. Первое приближение всегда составляет 1/2 - 1 день для завершения. Если эта оценка окажется ложной, просто возьмите другого разработчика и сделайте это вместе, чтобы сделать это. Или вы разбиваете рабочий элемент на более мелкие задачи, чтобы его можно было лучше распределять.

Answer 9

Какие виды наказаний за прохождение какие сроки эффективны?

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

Исправьте свою формулировку.

Answer 10

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

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

Решение этой проблемы состоит в том, чтобы изменить то, как вы делаете оценки - для всех. Разработчики могут плохо оценивать абсолютное время, но они довольно хороши в относительном времени. Таким образом, в понедельник вместо того, чтобы «сколько времени потребуется, чтобы добавить whoosiwhatsit?», Спросите «что вы можете сделать для whoosiwhatsit менее чем за неделю?» Это становится их задачей на неделю.

В следующий понедельник вы посмотрите, как все прошло. «Ну, я установил floogle за два дня, но оказалось, что это повлияло на mcphee ... так что на этой неделе мне нужно разделить этих парней, чтобы файлы whoosiwhatsit не перезаписывались» Хорошо, есть их задача на неделю.

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

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

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