Жизненная ситуация.

Вы ПМ. Даёте программисту задание, он регулярно встречается с Вами для дискуссий о задании. Но работа идёт очень медленно. Он не успевает выполнить это задание, то ли он недопонимает, то ли у него другие задачи.

Надавите на него? Будете молча ждать? Отдадите другому коллеге задачу, а этому скажете "стоп, хватит"? Посмотрите, какие у него другие задачи?

то ли он недопонимает, то ли у него другие задачи.

Ваша задача это выяснить. Почему бы не спросить у него самого?

Но работа идёт очень медленно.

Настя, а что значит медленно:

- Сроки обговорены, согласованы с программистом?

- Какие критерии выбраны для оценки скорости выполнения задачи, есть промежуточные цели или это твоё субь"ективное мнение, что медленно и что можете не уложиться?

- Он тоже согласен с тем, что медленно? Что он сам говорит по этому поводу?

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

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

П. С. Я в своих тимах на еженедельном ревью распределяю задания, терминирую, по актуальным темам спрашиваю какие сложности. Уже из опыта знаю, кого из коллектива нужно "детально, но нежно" дёргать в еженедельном ритме, а кого реже, но его пункт тоже стоит на повестке/opl. В принципе, как-то исторически сложилось, что в коллективах здоровое понимание процесса + у меня, кроме прочего, и рычаги воздействия тоже есть, которые были на совещании озвучены: не будет результатов от того или иного работника (или не в полной мере) и причин для этого тоже не будет=> перед следующим current forecast разговариваю с гл этого работника и если внятного объяснения не будет, то ставка, скажем с 0,7, сокращается в соответвии с проделанной работой на 0,4. Поэтому, во избежание таких ситуаций ребята эксперты сразу говорят: маркиза, мне приоритеты вот так расставили, тебя это устроит или нужно думать, что будем делать.

Здесь возможно "два путЯ":

1. Наняли лодыря;

2. Перегрузили человека заданиями.

Какой случай Ваш?

Присоединяюсь к выше написАвшим: "хорошо-плохо", "быстро-медленно" - это относительные и/или субъективные понятия. На что равняемся?

Это не моя задача, а задача тамошнего ПМа :)

Я просто наблюдаю, как он себя ведет и удивляюсь.

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

Замечания на полях...

-Климат у вас нормальный? Может быть он делает так долго, потому, что это единственное " хорошее " задание. Как выполнит его, ему сразу навалят 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?" такое ПМ не делают?

Вы ПМ. Даёте программисту задание, он регулярно встречается с Вами для дискуссий о задании. Но работа идёт очень медленно. Он не успевает выполнить это задание, то ли он недопонимает, то ли у него другие задачи.

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

Убедитесь, что понял правильно, задайте вопросов несколько.

Если все понял и тормозит, то спросите почему.