Комментарии 21
НЛО прилетело и опубликовало эту надпись здесь
по-моему, такая детализация подходит лишь для управления стажерами, которые жаждут наставничества. Эффективность нормальных программистов просядет от отсутствия автономии. К тому же, детализируя так сильно, вы теряете много собственного времени, в итоге управлять сможете лишь очень маленькой группой.
Юрий, для разных типов производств немножко отличается специфика.
Не всегда автономный программист, которому на вход дали задачу «на языке менеджера» = «эффективный программист».
Вопрос потерь времени же нужно рассматривать комплексно. Вот вы быстро ставите задачу-тост разработчику и тот, решая её, генерирует багов на 40 часов. В зависимости от ставок и стратегии компании — это может быть как потеря, так и экономия.
Стратегии, ставки разработчиков — зависят, в среднем, от рынка, на котором живут компании.
Не всегда автономный программист, которому на вход дали задачу «на языке менеджера» = «эффективный программист».
Вопрос потерь времени же нужно рассматривать комплексно. Вот вы быстро ставите задачу-тост разработчику и тот, решая её, генерирует багов на 40 часов. В зависимости от ставок и стратегии компании — это может быть как потеря, так и экономия.
Стратегии, ставки разработчиков — зависят, в среднем, от рынка, на котором живут компании.
T1 — Test — желаемое состояние, к которому мы стремимся, какое оно?
О — Operation — какие действия мы должны делать, чтобы достигнуть результата?
T2 — Test2 — по каким признакам мы поймём, что продвинулись в сторону результата?
E — Exit — по каким критериям мы поймём, что результат окончательно достигнут?
Не совсем понятен подход.
T1 — ок, понятно.
O — если мы говорим о коротких задачах, нужно формулировать только джуниору. Мидл сам должен принять решение как решать задачу, по этапам.
T2 — непонятно. Мы вслепую тычемся в разные стороны и у нас есть критерий, по которому мы решаем что последний "тык" был правильным?
E — я чего-то не понимаю, или E = T1 ?
O — какие действия надо делать
Т2 — как понять, что мы на правильном пути
Е — как понять, что мы дошли до финала
Т2 — как понять, что мы на правильном пути
Е — как понять, что мы дошли до финала
Ставлю задачу по этой же схеме
T1 — я знаю чем отличается T1 от E
O — пишете, чем отличается E от T1 (а не что оно делает)
T2 — в одном преложении есть E и T1; и предложение описывает разницу, а не общие черты.
E — я знаю чем отличается T1 от E
T1 — я знаю чем отличается T1 от E
O — пишете, чем отличается E от T1 (а не что оно делает)
T2 — в одном преложении есть E и T1; и предложение описывает разницу, а не общие черты.
E — я знаю чем отличается T1 от E
Я увидел DPE
D — description — краткая формулировка
P — plan — полан действий, даже для опытных кодеров, они, этот план могут сами для себя написать
E — exit — use cases, короткий кейс тестирования, который может провести кодер сам, чтобы убедится, что задача завершена и ее можно отдавать в тестирование
и все сложилось :)
D — description — краткая формулировка
P — plan — полан действий, даже для опытных кодеров, они, этот план могут сами для себя написать
E — exit — use cases, короткий кейс тестирования, который может провести кодер сам, чтобы убедится, что задача завершена и ее можно отдавать в тестирование
и все сложилось :)
А в чем сакральный смысл времени, выделенного на подзадачу, и кто его придумывает?
Прогноз времени как таковой нужен для трёх вещей:
— чтобы попытаться спрогнозировать время отгрузки результата
— чтобы поиграть в расчёты capacity производства
— чтобы вовремя обращать внимание на затупивших разработчиков и помогать им выйти из ступора
— чтобы попытаться спрогнозировать время отгрузки результата
— чтобы поиграть в расчёты capacity производства
— чтобы вовремя обращать внимание на затупивших разработчиков и помогать им выйти из ступора
Между прогнозом времени и [видимом] временном лимите при постановки задачи есть существенная разница.
Имхо это создает ненужное психологическое давление и отвлекает внимание от важного (т.е. решение поставленной задачи). Я бы оценки делал, но оставлял их при себе — они помогали бы мне достигать все трех поставленных целей, но без лишнего давления на работника.
Как считаете?
Имхо это создает ненужное психологическое давление и отвлекает внимание от важного (т.е. решение поставленной задачи). Я бы оценки делал, но оставлял их при себе — они помогали бы мне достигать все трех поставленных целей, но без лишнего давления на работника.
Как считаете?
Я считаю, что число с оценкой — это не самое страшное из психологических давлений. И я бы не рассчитывал на разработчика, которого это выводит из равновесия.
Я бы переживал не насчет выведения из равновесия, а насчет неявного поощрения «срезания углов» за счет изначально неправильно поставленной задачи. Время выполнения не должно быть критерием успешности, по моему мнению.
[ИМХО] Любой руководитель может прикинуть, сколько займет задача, и иметь это ввиду, но только для того, чтоб знать, когда прояснить статус задачи и предложить помощь.
А разработчик должен сконцентрироваться на главном — самой задаче и качестве ее решения.
[ИМХО] Любой руководитель может прикинуть, сколько займет задача, и иметь это ввиду, но только для того, чтоб знать, когда прояснить статус задачи и предложить помощь.
А разработчик должен сконцентрироваться на главном — самой задаче и качестве ее решения.
Я соглашусь, время решения не должно быть единственным критерием успешности.
И я считаю, что если разработчик делает задачу хорошо на протяжении 20 часов, когда заказчик ожидает получить её через 2 часа (в силу его, заказчикового неглубокого понимания ситуации) — это негативная ситуация, которой нужно избегать.
И я считаю, что если разработчик делает задачу хорошо на протяжении 20 часов, когда заказчик ожидает получить её через 2 часа (в силу его, заказчикового неглубокого понимания ситуации) — это негативная ситуация, которой нужно избегать.
интересный кейс, давайте разберем ситуацию. Дано:
(время исполнения) Висп: 20 часов
(ожидаемое время) Вож: 2 часа.
Задача имеет некоторый объем, идеальное время исполнения идеальным исполнителем — Вид.
Предположим:
Вид = 20 часов. Тогда, ожидания заказчика неоправданны. Кто должен разрулить эту ситуацию и как с этим поможет TOTE?
Вторая вероятность:
Вид = 10 часов. Ожидания заказчика неоправданны, но исполнитель выполняет задачу дольше, чем идеальное время исполнения. Кто виноват (если есть такие), кто должен разрулить эту ситуацию, и как с этим поможет ТОТЕ?
(время исполнения) Висп: 20 часов
(ожидаемое время) Вож: 2 часа.
Задача имеет некоторый объем, идеальное время исполнения идеальным исполнителем — Вид.
Предположим:
Вид = 20 часов. Тогда, ожидания заказчика неоправданны. Кто должен разрулить эту ситуацию и как с этим поможет TOTE?
Вторая вероятность:
Вид = 10 часов. Ожидания заказчика неоправданны, но исполнитель выполняет задачу дольше, чем идеальное время исполнения. Кто виноват (если есть такие), кто должен разрулить эту ситуацию, и как с этим поможет ТОТЕ?
О — Operation:
На мой взгляд задача тимлида: выстроить рабочий процесс и поддерживать темп разработки.
Он не должен и не может бегать за каждым разработчиком и расписывать ему задачу по часам.
Детализация задачи (включая оценку времени) — это ответственность самого разработчика. Задача тимлида проверить эту детализацию, согласится с ней или попросить скорректировать. Такой подход гораздо лучше «масштабируется» + сразу ясно насколько разработчик понял требования
В случае с junior-ом или новым сотрудником — тимлид может первое время помогать с оценкой или делегировать эту задачу более опытному сотруднику (ментору / наставнику).
На мой взгляд задача тимлида: выстроить рабочий процесс и поддерживать темп разработки.
Он не должен и не может бегать за каждым разработчиком и расписывать ему задачу по часам.
Детализация задачи (включая оценку времени) — это ответственность самого разработчика. Задача тимлида проверить эту детализацию, согласится с ней или попросить скорректировать. Такой подход гораздо лучше «масштабируется» + сразу ясно насколько разработчик понял требования
В случае с junior-ом или новым сотрудником — тимлид может первое время помогать с оценкой или делегировать эту задачу более опытному сотруднику (ментору / наставнику).
Такое ощущение, что с аналитиками в проектах никто не работает. Заказчик сразу приходит к PM или тимлиду выкладывает им суть на листике, а те уже нарезают листик на куски отдают их разработчикам. Эти советы больше относятся к работе аналитиков, они для того и придуманы, чтобы переводить потребности заказчика в спецификации требований, пригодные для передачи команде разработчиков. А вот тут уже и должен вступать тимлид и бить спецификации на задачи и раздавать их разработчикам.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Постановка задач для начинающих тимлидов