Как оценивать время на разработку

Оценка времени требует практики и труда. Иногда так много труда, что имеет смысл отдельно оценивать время на оценку задачи, особенно, если речь идет об оценке большой задачи.

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

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

Когда взять время на некоторое исследование задачи невозможно, то сначала вы должны четко и ясно установить, что именно означает ваша оценка. Сформулируйте это значение как первое и заключительное части вашей оценки в письменном виде. Подготовьте письменный ответ, разбирая задачу на более мелкие задания, в идеальном случае, требующие не больше одного рабочего дня. Самое важное здесь - ничего не забыть. Например, очень важно время на документирование, тестирование, планирование, взаимодействие с другими командами, отпуска. Если вы каждый день тратите часть времени на общение с неумными людьми, добавьте отдельную строку на это в общую оценку времени. Это даст вашему боссу общее видение того, что отнимает у вас немного времени, а на что вам его требуется гораздо больше.

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

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

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

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

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

Следующее: Как искать информацию