Здравствуйте, Nick Sergeev, Вы писали:
NS>Здравствуйте, peer, Вы писали:
P>>Я тимлид. P>>Как быть, чтобы сроки не срывались?
NS>Очень просто — сроки должен ставить тим-лид в зависимости от объективной сложности задачи. NS>Если девелопер не в состоянии их выдержать, то нужно ставить в известность проджекта.
Ну вот есть у тебя к примеру объективная сложность марафона — 42.125 км.
Кому-то чуть больше 2-х часов на это потербуется, а кто-то шагом за пару дней эту дистанцию одолеет.
Аналогия понятна? Я уж не говорю про "объективную" сложность, спускаемую сверху...
Здравствуйте, Nick Sergeev, Вы писали:
NS>Если девелопер не в состоянии их выдержать, то нужно ставить в известность проджекта.
Если ставить в известность ПМа, дело быстро кончится заменой тимлида, потому как тимлиды нужны чтобы снимать с проджекта часть головняков, а не добавлять новых.
Здравствуйте, bkat, Вы писали:
B>Ну вот есть у тебя к примеру объективная сложность марафона — 42.125 км. B>Кому-то чуть больше 2-х часов на это потербуется, а кто-то шагом за пару дней эту дистанцию одолеет. B>Аналогия понятна? Я уж не говорю про "объективную" сложность, спускаемую сверху...
Тимлид должен дать такую оценку, чтобы как минимум покрыть время разработки своими девелоперами, а в идеале чтобы еще и время осталось.
Время нужно защищать перед заказчиком, так как деньги платит он, а не перед тем кто сверху.
Ну элементарные же вещи.
Здравствуйте, Miroff, Вы писали:
M>Если ставить в известность ПМа, дело быстро кончится заменой тимлида, потому как тимлиды нужны чтобы снимать с проджекта часть головняков, а не добавлять новых.
Если девелопер не влазит в оценки, которые дали заказчику, то это потеря бабла компании, ставить ПМа в известность в таких случаях нужно обязательно.
Здравствуйте, Nick Sergeev, Вы писали:
NS>Здравствуйте, bkat, Вы писали:
B>>Ну вот есть у тебя к примеру объективная сложность марафона — 42.125 км. B>>Кому-то чуть больше 2-х часов на это потербуется, а кто-то шагом за пару дней эту дистанцию одолеет. B>>Аналогия понятна? Я уж не говорю про "объективную" сложность, спускаемую сверху...
NS>Тимлид должен дать такую оценку, чтобы как минимум покрыть время разработки своими девелоперами, а в идеале чтобы еще и время осталось. NS>Время нужно защищать перед заказчиком, так как деньги платит он, а не перед тем кто сверху. NS>Ну элементарные же вещи.
С этим в целом соглашусь. Но то, что ты тут описал — это немного сложнее
простого спускания сроков на девелопера и жалоб ПМу если девелопер не успевает.
Я к примеру, девелоперу сроки не спускаю. Смысла в этом нету никакого.
Общаюсь с ним чтобы он понял что надо сделать и сам прикинул сколько надо времени.
Если это вписывается в проект, то пусть делает.
Если не вписывается, то надо смореть кто ему может помочь или может лучше отдать другому.
Ну еще конечно надо каждый смореть как оно развивается...
Здравствуйте, Nick Sergeev, Вы писали:
NS>Здравствуйте, Miroff, Вы писали:
M>>Если ставить в известность ПМа, дело быстро кончится заменой тимлида, потому как тимлиды нужны чтобы снимать с проджекта часть головняков, а не добавлять новых.
NS>Если девелопер не влазит в оценки, которые дали заказчику, то это потеря бабла компании, ставить ПМа в известность в таких случаях нужно обязательно.
Если вы сделали оценки не спросив девелопера и он в итоге не успевает, то это ваш косяк.
Здравствуйте, Nick Sergeev, Вы писали:
NS>Есть предел оценки, которая может быть продана заказчику, и если девелопер в эту оценку не укладывается, то зачем держать его на проекте?
В реальной жизни оценки — это все же результат торговли.
Не учитывая девелоперов ты всегда будешь гадать на кофейной гуще и оценки будут по сути с потолка.
Грубо говоря, твое шестое чувство против реальности, которая все равно все раставит по своим местам.
Обычно это вываливается в авралы и прочие нервотрепки, лишь бы уложиться
в сроки, которое начальство спустило сверху не учитывая реальные возможности.
Не спрашивать тех, кто реально делает работу — это грубая ошибка менеджмента.
Решение подобных проблем — это разные итеративные методы разработки и постоянный контакт
с клиентом, чтобы он был в курсе что происходит и был по сути частью разработки.
Ну а жалобы на девелопера ПМу клиенту точно ничего не дадут...
On 16.12.2012 22:52, Nick Sergeev wrote:
> Есть предел оценки, которая может быть продана заказчику, и если > девелопер в эту оценку не укладывается, то зачем держать его на проекте?
Если есть, кто укладывается, то конечно незачем.
Здравствуйте, peer, Вы писали:
P>Я тимлид. P>Есть разработчик, который постоянно срывает сроки. P>На сроки я не давлю — он сам назначет. P>Ставит день, делает три дня. И так постоянно. P>Причем проставление % выполнения в TFS тоже не особо помогает. P>Взял задачу на 3 дня, в первый день поставил 50%, во второй 90%. А оставшиеся 10% делал еще 5 дней. P>Спрашиваю "В чем сложности?", говорит, "ну вот там сложности, тут сложности выплили, тут пришлось переделать.
P>Как быть, чтобы сроки не срывались?
Бывают такие индивидуумы. Можно попытаться по разному подойти. На моем опыте некоторым подобным разработчикам помогало совместно составить детальный план (проект) решения задачи. Т.е. расписать подробно решение сразу. Исходит это от того что разработчик не представляет сразу архитектуры решения. Если продумает (или его направить на путь истинный), возможно точность повысится. Ну и необходим ежедневный контроль за исполнением проекта (все ли идет по намеченной дороге). И своевременно его совместно корректировать.
Некоторым другим помогало, когда к ним подсаживали других разработчиков. Или хотя бы совместно решали задачу.
