Reviewing Engineer Estimates Before Client Delivery

Описание и применение

Сонал Джейн описывает процесс проверки оценок инженеров перед отправкой клиенту. Оценки часто точны для кодинга, но игнорируют тестирование, ревью и внешние зависимости. Решение включает 30-минутный аудит, выделение 10% времени на QA и пошаговый разбор первых пяти дней работы для выявления скрытых рисков.

Задача

Engineer estimates are often accurate for coding hours but fail to account for surrounding factors like dependencies, testing, reviews, and external blockers, leading to missed deadlines and client dissatisfaction.

Результат

A 30-minute review process that saves client relationships by ensuring estimates account for non-coding activities. It shifts responsibility for the timeline back to the engineering team through detailed walk-throughs and transparent risk management.

Рабочий процесс

• Check what the estimate assumes already exists (e.g., clean data models).
• Identify items outside the team's control (e.g., client approvals, vendor onboarding).
• Locate vague 'we'll figure it out' tickets, particularly integrations or migrations, and break them down.
• Account for code review and subsequent rework hours, which are rarely included in initial estimates.
• Allocate QA time at roughly 10% of build hours, regardless of AI-assisted coding speed.
• Conduct a day-by-day walk-through of the first five days with the engineer to surface hidden dependencies.
• Present the final estimate as a range with a specific reason for the upper bound and a date by which it will narrow.

Доказательства

That review takes me thirty minutes and it has saved more client relationships than any status report.

Источник

Our template pegs QA at roughly ten percent of build hours, and I no longer let anyone cut it, however confident the demo looks.

Источник