Как заказчику быть уверенным, что оплата на разработку отрабатывается на полную мощность, и уделяется оговорённое время на выполнение задач?

Сама формулировка вопроса классическая для нас, не классическая для Запада. В самом вопросе есть презумпция недоверия. Если есть недоверие, то, как правило, заказчик решает это следующим образом:
Сажает программистов в офис, будучи спокойным, что, если разработчик отсидел в офисе 8 часов, значит, он работал. С программистами такой подход неверный. Их время сложно оценить, потому что разработчики схожи с творческими людьми, как художники, писатели. Senior разработчики быстро разбираются в методах, алгоритмах внутри программы, в инструментарии разработки, поэтому делают все быстрее. 

Из чего состоит время работы программиста?

Должна решаться задача скорости работы разработчика. Работа разработчика оценивается не в часах, а в эффективности его работы.

Основные составляющие рабочего времени разработчика:

  • Написание самого кода (занимает до 30% всего времени работы разработчика);
  • Процесс создания идеи;
  • Умственный процесс в голове;
  • Архитектура и строение каждого элемента;
  • Проектирование реализации в коде имеющейся задачи. 

Разница между офисом и работой дома, с точки зрения эффективности, в том, что разработчик не отвлекается. Потому что, если разработчик отвлекается от мыслительных рабочих процессов, то ему понадобиться гораздо больше времени на тот же рабочий процесс, полностью погружаясь вновь в контекст.
Например, в компании Яндекс у разработчиков небольшие огороженные кабинеты, на 6-8 рабочих мест, внутри которых запрещено общаться между собой. Поэтому, если вникнуть в процесс работы разработчика, нужно понять, что главное, дать возможность разработчику работать и не отвлекать его.
Если это офисная работа, то какие-то встречи и stand up-ы лучше планировать на начало или конец рабочего дня, или планировать заранее какие-то переговоры, чтобы программист успел зафиксировать для себя результат текущего труда, и по возвращению, смог продолжить. 

Что касается оценки трудозатрат и уверенности заказчика, это классические вопросы, такие же, как и:

  • Как убедиться заказчику, что есть прогресс работы?
  • Как заказчику получать тот результат, который ему нужен, с учетом постоянных изменений и прогрессов? 

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

Как убедиться, что разработчики работают максимально эффективно? 

Если задачу решает один разработчик, сделать это очень сложно. Тут нужна уже некая экспертная оценка опытного человека, который бы соглашался или нет с выделенным временем на те или иные задачи. Когда начинает работать команда, особенно если в ней достаточно сильные специалисты, происходит оценка уже всей командой. Насколько сильна команда и Team lead, настолько эффективно быстро выявляется слабое звено, работа которого не соответствует общему темпу работы всей команды. 
Отставание по времени выполнения задач одним человеком сразу выбивается из общего контекста, и над этим можно работать. 
То есть, в команде есть также опытный человек, который понимает, достаточно быстро для своего уровня работает разработчик или недостаточно. Как правило, это роль Team lead-а.

Например, разработчик берет в работу задачу, делает ей оценку. Дальше, ежедневным stand up-ом и контролем Team lead-а, начинает формироваться понимание – динамика работы, ожидаемая или нет.

Как убедиться, что заложенная оценка задач является объективной?

Субъективная оценка одного человека имеет разную погрешность. Как правило, чем человек более зрелый, тем меньше эта погрешность, но все равно, она измеряется десятками процентов. Чем квалифицированнее и опытнее специалист, тем точнее его оценка поставленных задач, в частности, по исполнению заявленных сроков. Для повышения качества оценки и увеличения доверия к ней необходимо, чтобы:

  • оценка планирования задач происходила вначале спринта и на распределении задач между разработчиками;
  • согласование оценки происходило несколькими людьми на каждом этапе;
  • осуществлялось эффективное взаимодействие между оценщиками и тестировщиками на всех этапах проекта.

Соответственно, только командная оценка и совместный групповой контроль снижает погрешность и повышает уровень доверия к оценке.

Как повысить КПД разработчика?

КПД разработчиков, в отличие от механических операций, может отличаться в 5-10 раз, в зависимости от организации его труда. Если разработчику дать спокойный контекст для решения задач, не отвлекать его в процессе незапланированно, давать ему решать задачи в непрерывном режиме, то его эффективность колоссально велика. К оценке, выдвинутой самим разработчиком, следует также подходить с презумпции доверия, полагаясь на его ожидания.