На одном из проектов по документообороту мы уже реализовывали документ с бизнес-процессом и несколькими дополнительными изменениями. Работа заняла около 40 часов.
Через некоторое время появилась похожая задача. Заказчик вспомнил прошлую оценку и ожидал примерно такой же срок. Аргументировалось это тем, что проект тот же, тоже реализация нового документа и процесса. К тому же новую работу передали специалисту, у которого в целом было больше опыта.
Но в прежние 40 часов задача не укладывалась.
Мы не спорили с тем, что задачи похожи. Суть тут была в другом: первый разработчик давно работал на проекте, а второй только подключился. Первый помнил старые доработки, знал, где искать нужную логику, и представлял, какие участки нельзя менять без дополнительной проверки. Второму предстояло предварительно во всё это погрузиться и со всем ознакомиться.
Если отбросить людей из этой задачи, тогда разницы может никакой и не будет. Заказчик видел результат и прошлую цифру. Поэтому сразу начал задавать вопросы: если один специалист уже сделал похожую работу за 40 часов, почему другой не может?
До первого изменения кода
Обе задачи можно было записать одной строкой: «Реализовать документ с бизнес-процессом». Задачи реально были похожи и имели много общего.
Но перед реализацией второй задачи нужно было понять, можно ли использовать прежнее решение. Совпадает ли маршрут? Так же ли настроены права? Что происходит при возврате документа на доработку? Какие изменения уже внесены в общие механизмы проекта? Не затронет ли новая логика соседние процессы?
Первый специалист значительную часть ответов знал. Второму ещё предстояло выяснить, какие вопросы здесь вообще есть.
Он мог писать код не медленнее. Просто до кода ему нужно было дойти.
Синтия Корриторе и Сьюзен Виденбек изучали, как опытные программисты разбираются в незнакомой программе. Тридцать участников сначала знакомились с системой, а затем выполняли в ней несколько изменений в двух сессиях. По мере работы они переходили от отдельных участков к более широкому представлению о программе и в итоге просмотрели значительную часть кода.
Для нашей ситуации важен не сам объём просмотренного кода. Исследование показывает, что понимание существующей системы формируется постепенно и является частью работы по сопровождению. На проекте это означает, что перед изменением нового документа специалисту приходится восстановить связи с бизнес-процессом, правами и соседними механизмами. Первый разработчик значительную часть этих связей уже знал.
Синтия Корриторе и Сьюзен Виденбек изучали не скорость программирования, а то, как опытные разработчики разбираются в незнакомой программе. Участники работали с системой в двух сессиях и выполняли в ней изменения. По мере работы они выходили за пределы отдельных участков кода и формировали более широкое представление о программе. Исследование не показывает, сколько часов должно занимать такое погружение. Для нашей ситуации важен сам механизм: второй специалист сначала восстанавливал связи, которые первый разработчик уже знал. По сути, исследование подтверждает вполне предполагаемые факты.
Есть ещё история решений, которой в коде может не быть. Старый участник проекта помнит, какие варианты обсуждали раньше, почему от одного отказались и какие требования заказчик считает принципиальными. Обычно никто не переносит всю эту историю в каждую новую постановку. Для одного специалиста она уже стала знанием. Другому приходится собирать её заново.
Есть ещё одна мелочь, которая сильно сокращает время старого участника проекта: он знает, у кого быстро уточнить спорный вопрос. Новый специалист сначала ищет не только ответ, но и человека, который этот ответ может дать. В оценке такая работа обычно не выделяется, хотя в календаре она вполне реальна и её стоит учитывать.
Именно поэтому два человека могут в итоге изменить один и тот же модуль, но выполнить разный объём работы до первого изменения.
Более опытный специалист на незнакомом проекте
В нашем случае второй специалист не был слабее. У него был больший общий опыт разработки, но не было опыта именно в этой проектной базе.
Это различие легко потерять. Разработчик может хорошо знать платформу, уверенно проектировать новые механизмы и быстро разбираться в требованиях. Но он не обязан заранее понимать, почему несколько лет назад в конкретной базе изменили стандартный маршрут, где находится обходное решение и какие типовые механизмы здесь работают иначе.
Поэтому фраза «он опытнее» сама по себе не даёт оценку задачи. Нужно понять, работал ли специалист с этой конфигурацией, знает ли текущую базу, участвовал ли в прежних доработках и знаком ли с правилами, которые команда давно перестала проговаривать.
На знакомом проекте менее опытный разработчик иногда быстрее находит нужный участок просто потому, что знает местную архитектуру. Новый специалист может дольше разбираться, зато заметить риск, который старые участники уже не видят.
При этом незнание проекта не должно превращаться в постоянную надбавку. Если человек берёт вторую, третью, четвёртую похожую задачу, часть найденного контекста уже должна работать на него.
Что именно сравнивал заказчик
Заказчик сравнивал видимый результат. В прошлый раз появился документ, были сделаны доработки и заработал бизнес-процесс. Сейчас ожидался примерно такой же результат.
Но одна и та же формулировка может скрывать разный состав работы. В одном случае структура документа уже понятна, исполнители определены, тестовые данные готовы и найден подходящий маршрут. В другом нужно уточнять переходы, проверять права, разбираться с исключениями и смотреть влияние на соседние процессы.
На оценку влияет и постановка. В международном исследовании NaPiRE представители 228 компаний из десяти стран оценивали проблемы, с которыми сталкиваются при работе с требованиями. Среди предложенных вариантов неполные требования, нарушения коммуникации и изменение целей входили в число наиболее критичных проблем работы с требованиями. В открытых ответах участники связывали их в том числе с задержками и последующей переделкой.
Если такие проблемы будут присутствовать в задаче на разработку, то они так же окажут влияние на сроки её реализации.
Сотруднику нужно время на погружение. Новый человек задаёт больше вопросов, просит показать прежнее решение, проверяет детали, которые старому участнику кажутся очевидными.
Отдельно стоит договориться о том, что считается готовым результатом. Для одного участника «документ работает» означает, что его можно создать и провести по основному маршруту. Для другого сюда входят права, возврат на доработку, обработка исключений, проверка существующих данных и отсутствие проблем в соседних процессах.
Если прошлую задачу закрыли после проверки основного сценария, а новую оценивают вместе со всеми исключениями, прежние 40 часов уже описывают другой результат.
Почему прошлое число быстро становится обязательством
У заказчика уже есть ориентир, на который он основывается. И если не проработать это число, то первый вопрос после реализации с превышением этого срока будет «почему получилось больше сорока?».
Эрик Лёре и Магне Йоргенсен провели три эксперимента с участием 381 специалиста по разработке. Участники оценивали трудозатраты на описанные программные проекты. Те, кому перед оценкой называли высокое или низкое число, заметно смещали прогноз в его сторону - даже когда ориентир выглядел неправдоподобным или исходил от ненадёжного источника.
Нужно иметь это ввиду и при изменении ситуации не стоит ориентироваться на число, вокруг которого задает вопросы заказчик, а нужно объективно оценить с учетом изменившихся обстоятельств, какое может получится реальное количество часов для этой задачи.
Исполнитель тоже видит ожидание заказчика. Он может не включить в оценку обследование, принять сходство задач без достаточной проверки или рассчитывать разобраться по ходу работы. Неучтённая часть никуда не исчезает. Через несколько дней она возвращается уже как перенос срока.
Сейчас я бы не спорил с самими 40 часами. Я бы сначала поднял прошлую задачу и посмотрел, что именно в неё входило. Что уже знал исполнитель? Были ли готовы доступы и данные? Использовалось ли старое решение? Сколько замечаний появилось после сдачи?
Возможно такой разбор подтвердит прежнюю оценку. А возможно прошлый результат получился при удобном сочетании условий и плохо подходит в качестве нормы.
Магне Йоргенсен и Мартин Шепперд систематизировали 304 журнальные публикации об оценке программных работ. Они обнаружили, что результаты исследований методов оценки зависят от свойств использованных проектных данных, а организационный контекст нередко остаётся за пределами анализа.
Нужно учитывать все активности, которые необходимо осуществить для реализации. Одна реализация за 40 часов показывала, что такой срок возможен, но ещё не доказывала, что он повторится при другом исполнителе и других исходных условиях.
Если похожих задач было несколько, я бы посмотрел их вместе с учетом всех имеющихся переменных. Достаточно вспомнить, кто выполнял работу, насколько хорошо знал систему, были ли готовы исходные данные и что происходило после сдачи. С большим количеством аналитических данных уже можно сделать некие выводы, действительно ли задачи повторяются или совпадает только название. Если такие данные есть, то тут уже совсем другой разговор.
Что объяснять заказчику
Фраза «специалист новый, поэтому ему нужно больше времени» не для всех будет звучать, как хороший аргумент. Заказчик не видит, какая именно работа добавилась и когда она закончится. Лучше объяснить реальные причины
В нашем случае объяснение могло быть следующим: прошлую доработку выполнял человек, который давно знал проект. Новому специалисту сначала нужно разобрать действующий механизм и накопленные изменения. После этого оценку можно уточнить и уже предметно сравнить с предыдущей задачей.
Заказчику при этом не нужен подробный рассказ обо всём, что разработчик успел прочитать. Ему важно увидеть связь между дополнительной работой и будущим результатом. Если команда может назвать, что именно проверяет сейчас и когда вернётся с уточнением, разговор обычно становится более конструктивным.
Главное не уходить в защиту и оправдания. Гораздо полезнее назвать два-три отличия и момент, когда команда вернётся с уточнением. Тогда разговор остаётся про состав задачи
Есть ещё одна путаница, которая часто всплывает в таких обсуждениях. Сорок часов работы и готовность через пять рабочих дней - не всегда одно и то же. Специалист может ждать доступ, тестовые данные, решение по спорному сценарию или проверку другого участника. Активная работа почти не меняется, а дата сдвигается.
Бывает и обратное: дату сохраняют, но сокращают проверку или переносят часть сценариев. Формально задача закрыта вовремя, однако замечания приходят позже. Поэтому прошлый срок стоит сравнивать вместе с тем, что происходило после сдачи.
На проекте это видно, когда одна доработка проходит проверку сразу, а другая возвращается несколько раз. В отчёте обе могут выглядеть одинаково завершёнными. Для команды это разный объём работы.
Когда контекст перестаёт быть объяснением
Увеличение первой оценки можно объяснить погружением в проект. На второй и третьей похожей задаче это объяснение уже нужно проверять.
Специалист должен быстрее находить нужный код, реже возвращаться к разобранным вопросам и раньше сообщать о препятствиях. Нельзя заранее назначить точный процент ускорения, но изменения в работе должны быть видны.
Если человек повторно ищет уже найденную информацию, не использует документацию, поздно показывает промежуточный результат и после помощи коллег не становится самостоятельнее, дело уже не только в незнакомой базе.
Тогда нужно посмотреть, где теряется время. Сложно понять требования? Не удаётся локализовать изменение? Проверяются лишние варианты? Проблема слишком поздно становится видна руководителю?
В зависимости от ответа понадобится разное решение. По одному эпизоду я бы выводов о специалисте не делал. Если тот же разрыв повторяется в нескольких сопоставимых работах и после погружения ничего не меняется, это уже другой разговор.
Выводы
Ожидание заказчика было разумным. Похожую работу действительно уже выполняли за 40 часов, и этот опыт нельзя было игнорировать.
Но первый исполнитель пришёл в задачу со знанием архитектуры, прошлых решений и особенностей проекта. Второй часть этого контекста собирал уже внутри новой работы.
Поэтому прошлые 40 часов я бы оставил в обсуждении для отправной точки и в качестве вопроса к новой задаче: что именно тогда помогло уложиться в эту оценку и сохранились ли те же условия сейчас?
Для заказчика здесь важна предсказуемость. Даже если первая оценка выше прежней, команда должна объяснить, какая часть времени уйдёт на разбор существующего решения и когда прогноз можно будет уточнить.