Здравствуйте, peer, Вы писали:

P>Ставит день, делает три дня. И так постоянно.

Значит вам попался идеальный разработчик.
З.Ы.: Хорошие часы это не те которые не отстают и не спешат, а те что делают это предсказуемым образом.

Здравствуйте, peer, Вы писали:

P>Я тимлид.

Еврей штоле?

P>Есть разработчик, который постоянно срывает сроки.
P>На сроки я не давлю — он сам назначет.
P>Ставит день, делает три дня. И так постоянно.

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

P>Взял задачу на 3 дня, в первый день поставил 50%, во второй 90%. А оставшиеся 10% делал еще 5 дней.

Э-э-э... а что в этих цифрах НЕНОРМАЛЬНОГО? Он у вас копает ямы? Шьёт простыни? Почему вы считаете, что работа программиста имеет фиксированную скорость? (напоминаю — вы вообще-то ВЕДУЩИЙ разраб., т.е. должны иметь нехилый опыт)

P>Спрашиваю "В чем сложности?", говорит, "ну вот там сложности, тут сложности выплили, тут пришлось переделать.

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

P>Как быть, чтобы сроки не срывались?

Сроки — это такая менеджерская игрушка, к программированию НИКАКОГО отношения не имеющая. Если программист сказал "два", умножай на три по-любому. Сроки, бóльшие чем 5 дней (до умножения) вообще игнорировать — эти знания вам надо бы подчерпнуть из управленческой литературы (вы много читали об этом?).
Тут надо понимать, что "решение задачи" — это не взятие интеграла, это ИНЖЕНЕРИЯ, т.е. решение НЕИЗВЕСТНЫХ задач известными методами. В процессе решения возникает тысяча ньюансов, предусмотреть которые просто невозможно. Давайте вместе прикинем, что может возникнуть в процессе решения:
1. Прогеру(П) поставили не задачу, а "сделай, чтоб было ТАК". Даже чтобы понять как это ТАК, требуется время. И даже сделав ТАК, иногда интуитивно понимаешь, что это не совсем то и на НЕМНОГО НЕ ТАК уходит ещё 70% времени. Вопрос: вы уверены, что П решал именно конкретно сформулированную, техническую задачу?
2. Есть задача, есть инструменты. Не мне вам объяснять, что тупой пилой пилить в 10 раз медленнее. Все ли ваши инструменты хороши? А вы сами их использовали?
3. Инструменты хороши, а работников — шиши. Владеют ли ваши работники инструментами в совершенстве? Хоть один рубль потрачен на обучение персонала?
4. Сами по себе инструменты и библиотеки могут быть объективно сложными. Очевидный пример — WPF: для простого формоклепания идёт на ура, но стоит залезть в шаблоны-байндинги-стили и всё, можно ухайдокать два дня на единственную верную строчку (если она вообще существует). Сам не раз тратил море времени на вещи, на которые ВДРУГ мелкософт решила забить. Вы даёте запас на сложность инструментов?
5. Да чё пенять на мелкософт — СВОИ ЖЕ библиотеки могут быть написаны через анус! Только для мелкомягких уже давно придуман обходной путь, а со своими ещё придётся повозиться! Совместимость, "неожиданные" соглашения, устаревший или чужой код и т.п.Ваши библиотеки не вызывают проблем использования? Вы собирали об этом мнение ВСЕХ разработчиков?
6. "Хорошая программа должна быть написана минимум два раза". Это закон и вы его обязаны знать. Нередко именно в конце приходит "просветление" и желание сделать как надо. Тут уже на личное усмотрение: хотите — держите говнокод, пока он не врастёт в систему и станет невыковыриваемым, плодя через связи другие говноблоки. Хотите — выделите время (особ. для многозависимых вещей) и этот строительный блок ещё не раз порадует вас функциональностью.
7. Бывает просто сложно подступиться к задаче: то ни одного решения, то три сразу (и надо выбрать лучшее), то хорошее решение находится только в середине реализации, да мало ли чего! Тут полезно устраивать посиделки с другими специалистами — всегда находится интересная идея. Если идей — море, нужно подобрать соответствующее стандартам компании.Вы уверены, что исполнитель получил максимальную помощь? У вас вообще друг другу помогают?

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

Сложно, да? И это говорю вам я, простой прогер, имеющий в опыте всего лишь программинг. Психологи ещё добавят вёдер десять, вот тогда и начинайте спрашивать: "А чойта он так долго пишет?". Я верю, что вы и сами половину прекрасно знаете, только это нужно не только знать, но и осознавать.

Я тимлид.
Есть разработчик, который постоянно срывает сроки.
На сроки я не давлю — он сам назначет.
Ставит день, делает три дня. И так постоянно.
Причем проставление % выполнения в TFS тоже не особо помогает.
Взял задачу на 3 дня, в первый день поставил 50%, во второй 90%. А оставшиеся 10% делал еще 5 дней.
Спрашиваю "В чем сложности?", говорит, "ну вот там сложности, тут сложности выплили, тут пришлось переделать.

Как быть, чтобы сроки не срывались?

Здравствуйте, peer, Вы писали:

P>Я тимлид.
P>Как быть, чтобы сроки не срывались?

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

21.11.2012 23:33, dleo пишет:

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

> Так что неумеющие по-хорошему должны всю жизнь ходить в вечных джуниорах.
Просто не надо браться за те задачи, в которых ожидаются подводные
камни. Можно браться только за те, которые хорошо известны и будешь
эффективным работником для начальства (правда со сменой работы будут
траблы).

Здравствуйте, peer, Вы писали:

P>Здравствуйте, alpha21264, Вы писали:

A>>Здравствуйте, peer, Вы писали:

P>>>Я тимлид.
P>>>Есть разработчик, который постоянно срывает сроки.
P>>>На сроки я не давлю — он сам назначет.
P>>>Ставит день, делает три дня. И так постоянно.
P>>>Как быть, чтобы сроки не срывались?

A>>Ну умножай его срок на три. В чем дело-то?
A>>Для психотерапии почитай вот это.

P>т.е. смысла подходить к начальнику отдела разработки нет, типа чего делать с Петровым, который постоянно сроки фукает?
P>проблема в том, что Сидоров тоже делает быстрей в 2 раза и сроки верно назначает

Ну ты чё, не знаешь, что такое "ефрейторский зазор"?

[Флегматично]
1) Разница в производительности между хорошим и плохим программистом может быть и в тридцать раз...
2) Самолично видел как один такой "лучший перфомер" загнал проект в тупик.
3) По твоим словам (со слов Петрова) Петров кроме порученной задачи делает еще что-то
(типа рефакторинга смежных кусков) а Сидоров этого не делает.
4) Если тебе есть из чего выбирать, можешь заменить этого человека, но я уверен, что ты об этом пожалеешь.
5) Но заменить всё равно надо, потому что ты приобретешь опыт. Если обожгешься — отрицательный,
если выиграешь — положительный.

Но мне лично кажется, что ты просто пока еще молод и не научился
1) ценить то, что есть и вообще "в чужом огороде огурцы слаще"
2) работать с людьми с учетом их недостатков (и достоинств тоже)
3) не знаешь, чем человека можно стимулировать (этого конкретного человека и человека вообще)
4) вообще слишком эмоционально воспринимаешь то, что происходит на работе.

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

Здравствуйте, Osaka, Вы писали:

O>... Например, распишите подзадачи для таска "иногда отчёт ххх выдаёт неверные значения ууу".

(1. Обрати внимание, что это не таск. Таском это станет, когда будет записано в виде "Исправить ошибку значения yyy в отчете xxx. Приложение: 1) логи, 2) входные данные, на которых происходит сбой, 3) ....".
2. А еще ключевым тут является слово "иногда"...)

Подзадача 1:
добиться воспроизведения ошибки в отчете xxx и зафиксировать в багтрекере, при каких условиях — какие входные данные/нажатия на кнопки/переход между окнами/разрыв сети/whatever? — она воспроизводится.
(Причем заметь, что в этой подзадаче 1 программисту делать нечего — это задача для подразделения техподдержки/тестеров/etc.) Ну или же не воспроизводится, в последнем случае работа опять таки не для программиста, а для руководителя — принять решение о дальнейшем статусе этой ошибки: ACTIVE, WORKSFORME.... etc, если ошибка требует дальнейшего накопления статистики, либо UNCONFIRMED — если ошибку следует закрыть. До решения подзадачи 1 спрашивать у программиста "какие следующие подзадачи? когда пофиксишь?" довольно таки бессмысленно.

Здравствуйте, matumba, Вы писали:

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

Здравствуйте, Nick Sergeev, Вы писали:

NS>Здравствуйте, peer, Вы писали:

P>>Я тимлид.
P>>Как быть, чтобы сроки не срывались?

NS>Очень просто — сроки должен ставить тим-лид в зависимости от объективной сложности задачи.
NS>Если девелопер не в состоянии их выдержать, то нужно ставить в известность проджекта.

Ну вот есть у тебя к примеру объективная сложность марафона — 42.125 км.
Кому-то чуть больше 2-х часов на это потербуется, а кто-то шагом за пару дней эту дистанцию одолеет.
Аналогия понятна? Я уж не говорю про "объективную" сложность, спускаемую сверху...

Здравствуйте, Nick Sergeev, Вы писали:

NS>Здравствуйте, bkat, Вы писали:

B>>Ну вот есть у тебя к примеру объективная сложность марафона — 42.125 км.
B>>Кому-то чуть больше 2-х часов на это потербуется, а кто-то шагом за пару дней эту дистанцию одолеет.
B>>Аналогия понятна? Я уж не говорю про "объективную" сложность, спускаемую сверху...

NS>Тимлид должен дать такую оценку, чтобы как минимум покрыть время разработки своими девелоперами, а в идеале чтобы еще и время осталось.
NS>Время нужно защищать перед заказчиком, так как деньги платит он, а не перед тем кто сверху.
NS>Ну элементарные же вещи.

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

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

Здравствуйте, peer, Вы писали:

P>Ставит день, делает три дня. И так постоянно.

Тебе повезло. Он предсказуем, а это очень важно на проектах.

Здравствуйте, bkat, Вы писали:

B>Ну а жалобы на девелопера ПМу клиенту точно ничего не дадут...

Ну почему же ничего. Знаю случай, когда пара похожих жалоб от одного тимлида привела к увольнению. Тимлида. Как говорится, стало последей каплей.

P>Я тимлид.
P>Есть разработчик, который постоянно срывает сроки.
P>На сроки я не давлю — он сам назначет.
P>Ставит день, делает три дня. И так постоянно.
P>Причем проставление % выполнения в TFS тоже не особо помогает.
P>Взял задачу на 3 дня, в первый день поставил 50%, во второй 90%. А оставшиеся 10% делал еще 5 дней.
P>Спрашиваю "В чем сложности?", говорит, "ну вот там сложности, тут сложности выплили, тут пришлось переделать.
P>Как быть, чтобы сроки не срывались?
Не совсем понятны ваши функции, если вы всё ещё ему верите

Здравствуйте, peer, Вы писали:

P>Как быть, чтобы сроки не срывались?

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

2. Проверять выполнение задачи и следование плану в середине пути, а не просто смотреть на проценты.

3. Оценить риски задачи, понять из-за чего могут поплыть сроки. В первые дни выполнения задачи сосредоточится на проверке технологических рисков. Скорректировать сроки при срабатывании рисков.

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

Здравствуйте, Nick Sergeev, Вы писали:

NS>Если девелопер не в состоянии их выдержать, то нужно ставить в известность проджекта.

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

Здравствуйте, Nick Sergeev, Вы писали:

NS>Здравствуйте, Miroff, Вы писали:

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

NS>Если девелопер не влазит в оценки, которые дали заказчику, то это потеря бабла компании, ставить ПМа в известность в таких случаях нужно обязательно.

Если вы сделали оценки не спросив девелопера и он в итоге не успевает, то это ваш косяк.

Здравствуйте, Nick Sergeev, Вы писали:

NS>Есть предел оценки, которая может быть продана заказчику, и если девелопер в эту оценку не укладывается, то зачем держать его на проекте?

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

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

Ну а жалобы на девелопера ПМу клиенту точно ничего не дадут...

Здравствуйте, peer, Вы писали:

Programmer Time Translation Cheatsheet -or- Why Programmers Are Bad at Estimating Times.

Здравствуйте, peer, Вы писали:

P>Я тимлид.
P>Есть разработчик, который постоянно срывает сроки.
P>На сроки я не давлю — он сам назначет.
P>Ставит день, делает три дня. И так постоянно.
P>Как быть, чтобы сроки не срывались?

Ну умножай его срок на три. В чем дело-то?
Для психотерапии почитай вот это.
http://www.wunderwaffe.narod.ru/Magazine/BKM/index.htm
Это про кораблики. Посмотри, был ли хоть один карапь в русском флоте, который сдали в срок.


PS.
Вообще-то был — крейсер "Варяг", но при этом он:
1) Строился не в России
2) Для достижения ТТХ пришлось снять орудийные щиты
3) Он имел проблеммы с силовой установкой весь срок службы.

Здравствуйте, alpha21264, Вы писали:

A>Здравствуйте, peer, Вы писали:

P>>Я тимлид.
P>>Есть разработчик, который постоянно срывает сроки.
P>>На сроки я не давлю — он сам назначет.
P>>Ставит день, делает три дня. И так постоянно.
P>>Как быть, чтобы сроки не срывались?

A>Ну умножай его срок на три. В чем дело-то?
A>Для психотерапии почитай вот это.

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

Вообще сроки могут ставиться с погрешностью.
Например, 5 +- 3 дня.
Нулевая погрешность возможна, если полностью отсутствуют факторы неопределенности.
К факторам неопределенности относятся
— неполная или неактуальная документация.
— действия третьих сил в прошлом или настоящем.

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

N>1. Просить оценку не в виде "сколько всего", а в виде "распиши и оцени подзадачи"
Не все задачи, которые можно сделать, можно заранее спланировать. Например, распишите подзадачи для таска "иногда отчёт ххх выдаёт неверные значения ууу".
N>Для некоторых задач этого будет мало, на других время будет потрачено впустую.
Почему будет потрачено? Если разработчик сделает раньше, разве он принципиально станет высиживать сколько запланировано?

A>5) Но заменить всё равно надо, потому что ты приобретешь опыт. Если обожгешься — отрицательный,
A> если выиграешь — положительный.
Ой, не факт. Петров не устранит "сложностей" за "профуканные" три дня, и Сидоров будет бороться с их последствиями, чётко соблюдая сроки по каждой задаче, месяц. "Месяц окончится, будет представлен отчет: вывезено на столько-то больше, чем в прошлом месяце. Министр доволен, мэр доволен, все довольны."(ц) А что можно было вместо месяца 1 раз лишние 3 дня побороться со "сложностями", про то никто и не узнает.

Здравствуйте, peer, Вы писали:

P>Как быть, чтобы сроки не срывались?

Очень просто, вам надо понять, что программеры очень редко обладают даром предвидения, поэтому те сроки, которые они озвучивают относятся к той работе, которую они знают как сделать. В эти сроки конечно же не войдет время работы которую разработчики не знали как сделать, пока не начали. И уж точно туда не войдет время той работы которая была добавлена в процессе реализации, в следствии того, что требования стали более понятными (или вообще изменились).

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

Здравствуйте, peer, Вы писали:

P>Я тимлид.

Как ты им стал?

Здравствуйте, peer, Вы писали:

P>проблема в том, что Сидоров тоже делает быстрей в 2 раза и сроки верно назначает

Это ничего не значит, нужно разбираться в деталях с каждой задачей. Если Сидоров такой успешный, может быть имеет смысл делать совещание, где он озвучит схему решения, а Петров должен вникнуть и реализовать. Или предложить своё решение и расписать недостатки другого решения. Вобщем, "найти лентяя" можно всегда, попробуй найти реальные причины — может у вас в команде самородок, которому "решения побырому" от Сидорова антагонистичны и он хочет написать идеальное решение!
В любом случае, если человек недоволен своим кодом — это хороший знак, хуже когда доволен всегда.

Здравствуйте, bkat, Вы писали:

B>Ну вот есть у тебя к примеру объективная сложность марафона — 42.125 км.
B>Кому-то чуть больше 2-х часов на это потербуется, а кто-то шагом за пару дней эту дистанцию одолеет.
B>Аналогия понятна? Я уж не говорю про "объективную" сложность, спускаемую сверху...

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

Здравствуйте, Miroff, Вы писали:

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

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

P>Я тимлид.

Ты не тимлид, ты падаешь и умираешь.

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

Здравствуйте, bkat, Вы писали:

B>Если вы сделали оценки не спросив девелопера и он в итоге не успевает, то это ваш косяк.

On 16.12.2012 22:52, Nick Sergeev wrote:

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

Здравствуйте, peer, Вы писали:

P>Я тимлид.
P>Есть разработчик, который постоянно срывает сроки.
P>На сроки я не давлю — он сам назначет.
P>Ставит день, делает три дня. И так постоянно.
P>Причем проставление % выполнения в TFS тоже не особо помогает.
P>Взял задачу на 3 дня, в первый день поставил 50%, во второй 90%. А оставшиеся 10% делал еще 5 дней.
P>Спрашиваю "В чем сложности?", говорит, "ну вот там сложности, тут сложности выплили, тут пришлось переделать.

P>Как быть, чтобы сроки не срывались?

Бывают такие индивидуумы. Можно попытаться по разному подойти. На моем опыте некоторым подобным разработчикам помогало совместно составить детальный план (проект) решения задачи. Т.е. расписать подробно решение сразу. Исходит это от того что разработчик не представляет сразу архитектуры решения. Если продумает (или его направить на путь истинный), возможно точность повысится. Ну и необходим ежедневный контроль за исполнением проекта (все ли идет по намеченной дороге). И своевременно его совместно корректировать.

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