Комментарии 6
1) Если задача не решается по ходу я трачу на нее дополнительно час-полтора (обычно это не критично для других задач)
2) Если решение не находится я советуюсь с коллегами (тут как раз можно получить взгляд со стороны или подсказку)
3) Если подсказки не нашлось и взгляд со стороны ничего внятного не дал я сообщаю менеджеру что есть проблема: появилась не прогнозируемая по времени задача. Тут или можно пойти на компромис и сделать что-то предсказуемое и по-проще или менеджер решает сколько еще времени я могу потратить на поиск решения.
4) Если я потратил и дополнительное время, а решения все равно нет — тут уже надо думать. Или передавать задачу другому человеку или решать проблему с точки зрения бизнеса (отказываться вообще, ощутимо менять требования и т.д.)
Пока все с чем сталкивался решалось именно так и все были довольны.
Как правило, сотрудник тупит на контексте. Он не понимает, с чего начать. Не знает, что в окружении задачи вообще есть, будь то фреймворк или предметная область.
Мой опыт это утверждение не подтверждает. Если сотрудник (здесь и далее имею ввиду исключительно разработчика) "тупит" из-за того что не может (не знает как) начать, то он потеряет пару дней в самом худшем случае. Достаточно просто ежедневно отслеживать прогресс по каждой задаче. Да, тот самый пресловутый скрам дейли митинг сэкономит вам кучу человеко-часов/дней/недель "тупки", потому что если человеку уже второй день нечего объективно сказать по задаче, которая в прогрессе, то у него там затык, надо звать более квалифицированного на помощь.
Гораздо хуже, если он начал кое-как. Использовал неэффективный дизайн, требующий большого количества костылей, или если он (или кто-то другой в цепочке) истолковал постановку задачи неверно. Тогда дневные отчёты выглядят великолепно, код добавляется, документация пишется, даже уточняются мелкие детали. Всё это очень усыпляет внимание контроля. И чаще всего только на завершающих шагах вдруг внезапно выясняется, что делалось совсем не то, что было нужно!.. Поэтому большая часть в лучшем случае летит в помойку, а в худшем — её следы остаются жить в проекте навсегда и конфузят исполнителей следующих задач.
Экономика взаимопомощи