Как проводить ревью оценок
• каждая задача не должна превышать 16 часов, иначе ее следует разбить на подзадачи. Исключение — болпарк оценки;
• сопоставить оценки с типовыми видами работ и сравнить часы. Например, часто на интеграцию с платежной системой разработчику требуется около 40 часов;
• проверить работы на состав и полноту;
• проверить зависимости;
• есть ли в оценке наши предположения, так называемые асампшены (крайне редко бывает так, что при анализе требований все воспринимается однозначно и без предположений);
• проверить, есть ли асампшены напротив задач, которые оказались непонятными;
• проверить наличие буферов/заложенного времени на непредвиденные ситуации;
• проверить коэффициенты на те работы, которые высчитываются по формулам и расчетам. Например, тестирование 30% от программирования, +10% на юнит-тесты, +20% на багфикс. Уточните, можно ли провести точную оценку, действительно ли уместно закрываться коэффициентами.
Что же это за разговоры и что и когда спрашивать? Хронологически это выглядит так:
• проверьте разработчика на масштаб его мышления с помощью тестового задания.
Отдельно я бы выделил такое качество, как матерость. Иначе говоря, сообразительность, которая покрывает при определенном уровне опыта часть отсутствующих знаний. Сотрудник может самостоятельно решить ситуацию наилучшим образом в текущих обстоятельствах. Это тот сотрудник, который может работать, не спрашивая, что надо делать и как. Фактически, оставаясь подчиненным, он может работать в формате управления по целям (management by objectives), в то время как остальные еще работают в режиме управления по инструкциям (management by instructions). Если нужной инструкции нет, то матерый специалист свою работу не останавливает. Может предвидеть развитие ситуации и запросить ресурсы, дать советы, предупредить для удачного исхода.