Как бы вы повели себя в такой ситуации
Жизненная ситуация.
Вы ПМ. Даёте программисту задание, он регулярно встречается с Вами для дискуссий о задании. Но работа идёт очень медленно. Он не успевает выполнить это задание, то ли он недопонимает, то ли у него другие задачи.
Надавите на него? Будете молча ждать? Отдадите другому коллеге задачу, а этому скажете "стоп, хватит"? Посмотрите, какие у него другие задачи?
то ли он недопонимает, то ли у него другие задачи.
Ваша задача это выяснить. Почему бы не спросить у него самого?
Но работа идёт очень медленно.
Настя, а что значит медленно:
- Сроки обговорены, согласованы с программистом?
- Какие критерии выбраны для оценки скорости выполнения задачи, есть промежуточные цели или это твоё субь"ективное мнение, что медленно и что можете не уложиться?
- Он тоже согласен с тем, что медленно? Что он сам говорит по этому поводу?
Я бы поговорила с ним сначала и выяснила в чем дело, действительно ли есть риск сорвать срок, дело важное и срочное или пока только важное, или таки все идёт по плану. А уже потом от этого плясать.
Вполне может ему гл другие прио назначил, а программист молчит и пытается вам обоим угодить.
П. С. Я в своих тимах на еженедельном ревью распределяю задания, терминирую, по актуальным темам спрашиваю какие сложности. Уже из опыта знаю, кого из коллектива нужно "детально, но нежно" дёргать в еженедельном ритме, а кого реже, но его пункт тоже стоит на повестке/opl. В принципе, как-то исторически сложилось, что в коллективах здоровое понимание процесса + у меня, кроме прочего, и рычаги воздействия тоже есть, которые были на совещании озвучены: не будет результатов от того или иного работника (или не в полной мере) и причин для этого тоже не будет=> перед следующим current forecast разговариваю с гл этого работника и если внятного объяснения не будет, то ставка, скажем с 0,7, сокращается в соответвии с проделанной работой на 0,4. Поэтому, во избежание таких ситуаций ребята эксперты сразу говорят: маркиза, мне приоритеты вот так расставили, тебя это устроит или нужно думать, что будем делать.
Присоединяюсь к выше написАвшим: "хорошо-плохо", "быстро-медленно" - это относительные и/или субъективные понятия. На что равняемся?
Да, нужно примерно заранее планировать количество времени и ставить его коллеге. А не просто наблюдать, как прогресс ползет как черепаха
Замечания на полях...
-Климат у вас нормальный? Может быть он делает так долго, потому, что это единственное " хорошее " задание. Как выполнит его, ему сразу навалят Legacy код разбирать...
или наоборот, это задание такое дибильное, что у него нет мотивации его делать... А отказаться нельзя...
-Ты ему четко описала задания? Или как всегда сделай что-нибудь, не знаю что ( с точки зрения обьема работ)
-может быть на него давят? т.е. задание на 2 недели, а шеф ему в приказном тоне сказал "Надо что бы ты сказал 2 дня работы. Твои реальные estimate меня не интерисует". Работник вместо того, что бы делать Überstunden, делает все так надо, просто потому, что сроки совсем не реалистичные.
-У него есть все для выполнения задания? Интроверты молчат и не жалуются. Может так случится, что он:
* плохо знает Framework, боится спрашивать помощи.
* Ему не дали (кормят завтраками) сервер, базу данных, большой HDD,
* Что-то еще его блокирует. Тут ключевое то, что ты, или кто-то 3. ему пообещал и не выполняет обещания.
* Его шеф заставляет что-то делать, что не надо. На пример что бы имена функций были на английском, и не длинее 8 символов. (или другой очевидный идиотизм)
* Ему понятно, что конкретно нужно сделать, а что нет.
* Ему понятно, что обшивать все бисером да в 3 ряда не нужно?. Главное функциональность, концепт по LIN
- Что говорит коллега, который сделал Code Review этого сотрудника? Он
генерирует правильный код, или красит большой дом кисточкой 3мм в диаметре?
-Он в других проектах одновременно участвует? Может он с 11 до 16 занят поиском и решением каких-нибудь очень горящих багов.
-может быть он тесты пишет, и пока они 100% кода не покрывают, не останавливается.
Дальше перечислять?
Есть такая книга, в русском переводе называется "Путь Камикадзе" . Эдварда Йордона . Читала ее?
Просто "соль на рану". Я буквально на прошлой неделе наконец-таки закрыла проект, который был рассчитан на 6-9 месяцев, а длился 3 года!
Из-за недостаточно детализизированных целей проекта, из-за архисложного согласования между отделами, из-за изменений в тупах, от которыго зависило техническое исполнение.
Т.е сама команда работала абсолютно эффективно, но постоянно натыкалась на какие-то препоны и сидела ждала чужих телодвижений.
А что касается программмистов, то даже лучшие из них очень зависят от точности постановки задачи. Иногда приходится выяснять детали в разы дольше, чем писать сам код. Иногда даже и ПМ в этом не виноват, а сам заказчик не знает точно что хочет. И только в процессе технической имплементации начинает над деталями задумываться.
Господин 
achest очень подробненько все расписал.
А что касается программмистов, то даже лучшие из них очень зависят от точности постановки задачи.
В советские времена программистам-сдельщикам платили по количеству строк кода. 
Вот они, наверное, индусам, и преподают.
А вообще, с учетом менталитета, все абсолютно логично. У последних: успех - это удовольствие от процесса, а не результат. 
Надавите на него? Будете молча ждать? Отдадите другому коллеге задачу, а этому скажете "стоп, хватит"? Посмотрите, какие у него другие задачи
а спросить "Wo der Schuhe drückt?" такое ПМ не делают?
Вы ПМ. Даёте программисту задание, он регулярно встречается с Вами для дискуссий о задании. Но работа идёт очень медленно. Он не успевает выполнить это задание, то ли он недопонимает, то ли у него другие задачи.
Если регулярно с вами встречается, то более конкретно ему задачи и ставьте. Чтобы не нужно было ему домысливать-правильно он понял или нет.
Убедитесь, что понял правильно, задайте вопросов несколько.
Если все понял и тормозит, то спросите почему.