Как ответить, когда вас просят оценить?

Нас, программистов, постоянно спрашивают: «Сколько времени это займет?»

И вы знаете, ситуация почти всегда так:

• Требования неясны. Никто не сделал глубокий анализ всех последствий.
• Новая функция, вероятно, нарушит некоторые предположения, которые вы сделали в своем коде, и вы сразу же начнете думать обо всех вещах, которые вам, возможно, придется реорганизовать.
• У вас есть другие дела из прошлых заданий, и вам нужно будет составить оценку, которая учитывает эту другую работу.
• Определение «сделано», вероятно, неясно: когда это будет сделано? «Готово», как в только что законченном кодировании, или «готово», как в «пользователи используют его»?
• Независимо от того, насколько вы осведомлены обо всех этих вещах, иногда ваша «гордость программиста» заставляет вас давать / принимать более короткие времена, чем вы изначально предполагали. Особенно, когда вы чувствуете давление сроков и ожиданий руководства.

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

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

Каков ваш личный процесс для принятия решения и оценки? Какие техники вы нашли полезными?

От прагматичного программиста: от подмастерья до мастера :

Что сказать, когда попросили оценить

Вы говорите: «Я вернусь к вам».

Вы почти всегда получаете лучшие результаты, если замедляете процесс и тратите некоторое время на выполнение шагов, описанных в этом разделе. Оценки, данные в кофемашине (как кофе) вернутся, чтобы преследовать вас.

В разделе авторы рекомендуют следующий процесс:

• Определите, какая точность вам нужна. На основании продолжительности вы можете процитировать оценку с различной точностью. Сказать «от 5 до 6 месяцев» - это не то же самое, что сказать «150 дней». Если вы немного проскользнете в 7-й месяц, вы все еще довольно точны. Но если проскочить в 180-й или 210-й день, не так уж и много.
• Убедитесь, что вы понимаете, о чем спрашивают. Определите масштабы проблемы.
• Смоделируйте систему. Модель может быть ментальной моделью, диаграммами или существующими записями данных. Разложите эту модель и составьте оценки из компонентов. Присвойте значения и диапазоны ошибок (+/-) каждому значению.
• Рассчитайте оценку на основе вашей модели.
• Отслеживайте свои оценки. Запишите информацию о проблеме, которую вы оцениваете, вашу оценку и фактические значения.
• Другие вещи, которые необходимо включить в оценку, - это разработка и документирование требований или изменений в спецификациях требований, создание или обновление проектной документации и спецификаций, тестирование (единица, интеграция и принятие), создание или обновление руководств пользователя или README с изменениями. Если 2 или более человека работают вместе, это накладные расходы на общение (телефонные звонки, электронные письма, встречи) и слияние исходного кода. Если это длинная задача, при выборе даты доставки учитывайте такие вещи, как другая работа, свободное время (праздники, отпуск, больничное время), встречи и другие служебные задачи.

Оценка программного обеспечения является наиболее сложной единственной задачей в программной инженерии, а второе - определение требований.

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

1. Внимательно посмотрите на ваши требования.
2. Сделайте предположения, чтобы заполнить пробелы, основанные на ваших лучших предположениях о том, что они хотят
3. Запишите все свои предположения
4. Заставьте их сесть, прочитайте и согласитесь с вашими предположениями (или, если вам повезет, заставьте их сдаться и дать вам реальные требования).
5. Теперь у вас есть подробные требования, которые вы можете оценить.

Как будто моя мать в детстве угрожала мне: «Поторопись и выбери одежду, или я выберу ее для тебя!»

Я занимался разработкой для парня, который был непреклонен в желании получить точные оценки. Мы остановились на том, что сработало очень хорошо:

• Я выставил счет за все время, потраченное на оценку. Это составило около 20-25% от того, что я выставил.
• Я сделал очень подробный анализ заданий. Нет стрельбы из бедра. Я пошел в код, выяснил, какие строки нужно изменить, на какие другие части программы это повлияет, сколько тестов мне нужно сделать, чтобы убедиться, что все работает. Я бы оценил каждый кусок в единицах по 0,1 часа (6 минут).
• Я отправил ему свою оценку для каждой задачи вместе с этим подробным описанием.

20-25% биллинга звучит как много.

Но он попросил меня внести изменения XYZ, думая, что это займет около 2 часов. За 1 час детальной оценки я бы определил, что это займет 8,5 часов. Поэтому он решит, стоит ли это 8,5 часов оплаты. Если нет, то он сэкономил 7,5 часов сверх того, что стоило бы ему, если бы я сделал это без оценки.

И если он действительно хотел потратить 8,5 часов, детальная работа, которую я сделал для оценки, была работой, которую я должен был бы сделать в любом случае.

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

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

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

Они почти всегда получают смысл.

Это зависит от того, для чего оценка.

Для начальной, высокоуровневой оценки для бизнес-кейса ключевыми являются следующие вещи:

1. Скорость. Какой бы метод вы ни использовали, он должен быть быстрым. Все дело в том, что заинтересованные стороны не уверены, стоит ли вообще заниматься проектом, поэтому им нужны цифры для бизнес-кейса. Если бы бизнес-обоснование было солидным, им не понадобились бы ваши оценки. Большая часть этих проектов не будет реализована, поэтому важно не тратить слишком много усилий на оценку.
2. Дайте диапазон. Сделайте это широким. У вас не было времени проанализировать требования, провести семинар с заинтересованными сторонами, проверить предположения. Получатели сметы сообщают широкий диапазон: «Программные проекты естественно сложны и рискованны - если вы хотите получить правильную оценку, вам нужно дать мне больше деталей и больше времени». Проблема с указанием одного числа или узкого диапазона заключается в том, что он загоняет вас в угол, устанавливая ожидания до того, как будет проведен какой-либо реальный анализ.

Я нахожу лучшую технику, чтобы выбрать сопоставимый проект, который "чувствует" то же самое «Чувство» является полностью субъективным, но с такой оценкой мой опыт подсказывает, что вы не найдете объективных измерений. Тогда предоставьте широкий ассортимент. Я читал некоторые книги, в которых говорится, что диапазон от -50% до + 100% - это хорошо, но это зависит от многих факторов.

Для подробной оценки низкого уровня:

1. Вам нужна базовая линия. Если базовый уровень не стабилен, оценка не имеет смысла.
2. Лучше снизу вверх. Получите подробную разбивку работы, оцените каждый компонент, а затем сверните его в большее число. Я считаю планирование покера отличной техникой.
3. Документ на случай непредвиденных обстоятельств. Укажите, где добавлено какое-либо непредвиденное обстоятельство (если оно есть). Это добавлено к каждой позиции? Или в целом оценить? Или к конкретным рискам? Или нет?
4. Выскажите свои предположения. Подтвердите как можно больше с учетом временных рамок.
5. Укажите явно, что включено и исключено в оценке. Например, включен ли обзор? Включены ли технические задержки?

Несколько советов от темной стороны от того, кто научился трудному пути.

Требования неясны. Никто не сделал глубокий анализ всех последствий.

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

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

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

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

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

Определение «сделано», вероятно, неясно: когда это будет сделано? «Готово», как в только что законченном кодировании, или «готово», как в «пользователи используют его»?

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

Независимо от того, насколько вы осведомлены обо всех этих вещах, иногда ваша «гордость программиста» заставляет вас давать / принимать более короткие времена, чем вы изначально предполагали. Особенно, когда вы чувствуете давление сроков и ожиданий руководства.

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

Проблема здесь в следующем: допустим, вы и Джо делали оценки времени для одной и той же задачи (но между двумя отдельными сотрудниками, не подозревая об обеих оценках одновременно). Вы доблестно оцениваете «одну неделю» . Это нормально, вы думаете, вы будете работать более 100 часов в неделю, без оплаты сверхурочных. Теперь ты опоздал на три дня.

Между тем Джо оценивает 5 месяцев. Вы думаете, что это смешно, вы думаете, что можете справиться с этим за одну неделю. Сколько работает Джо? 10 часов в неделю? ... кроме того, что он заканчивает вовремя ровно через 5 месяцев.

Угадай, кого воспринимают как осла? Это верно, ты. Джо, кажется, отличный работник, ты выглядишь ненадежным сейчас. Не имеет большого значения, что вы могли бы достичь еще лучшего результата в ~ 7% времени, которое занимал Джо. Важно то, что у вас было 3 выходных дня после одной недели.

Никогда не ошибайтесь в сторону более жесткой оценки. Ошибка на стороне более слабой оценки. У вашей компании есть репутация, и она не будет основываться на длине ваших оценок почти так же, как на точности ваших оценок. Легко быть точным с оценкой, которая слишком длинна, вы просто получаете больше времени, чтобы работать над проблемой и решать ее лучше. Слишком короткая оценка не оставляет вообще никакой передышки, вы либо отчаянно ее встречаете, либо вас облажали.

"Две недели!"

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

Я пытаюсь обойти это, пытаюсь действительно думать о том, сколько времени, по моему мнению, что-то займет, пытаясь идентифицировать все потенциальные проблемные места и кусочки, которые выглядят слишком черными, чтобы я мог их точно оценить. И постарайтесь понять, что если мой ответ «Две недели!», Я, вероятно, не смог этого сделать.

Практически каждый хороший менеджер, которого я имел, научился распознавать "Две недели!" как ответ, который требует мягкого словесного шлепка в ответ.

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

Я сам не пробовал, но хотел бы, чтобы увидеть, насколько точны мои оценки.

Это зависит от организации и того, как используются оценки.

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

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

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

Оценки за что? Небольшие задачи или полные решения.

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

Небольшие задачи - я считаю, что планирование покера работает очень хорошо (не идеально, некоторые задачи с 1pt заняли намного больше времени, а некоторые задачи с 5pt заняли минуты, но в конце все выровнялось).

Представьте диапазон, основанный на том, что вы знаете сегодня. Используйте Конус Неопределенности, чтобы обеспечить диапазон вокруг ваших начальных предположений.

Каждую неделю подсчитывайте, сколько еще нужно сделать, переоценивайте на основе того, что вы знаете. Как только вы наберете достаточный объем выборки для того, сколько работы вы проделываете каждую неделю, обеспечьте 90% доверительный интервал для того, что осталось, чтобы дать (обычно) постоянно сужающийся диапазон дат по мере выполнения проекта и объема работы (надеюсь) ) сжимается.

Уверенно. Я не могу сказать вам, сколько раз я провалил первоначальную встречу с клиентом, не прибегая к профессионализму при оценке. Даже если вы выдыхаете цифры из воздуха - убедитесь, что вы всегда держите некоторую оценку. Тем не менее, будьте осторожны, чтобы не оценить себя в дыру. Разные вещи требуют разного количества времени, усилий и ресурсов, чтобы собрать их вместе. Вот хороший способ сделать это:

ИМ: Сколько это будет стоить?

Я: Это зависит от того, что вы хотите, чтобы я сделал. Как правило, я начинаю этот проект примерно с $ X.

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

Однажды мы решили поделиться своим опытом и знаниями о процессе оценки программного обеспечения и определили четыре различных типа оценок :

• Примерная цифра
• оценка услуг
• оценка характеристик
• компонентная оценка

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

Как правило, клиентам нужна ориентировочная фигура в начале проекта. И наш совет: обсуждение проекта и предоставление приблизительных данных должны быть просто шагами к получению компонентной оценки (которая является гибкой, можно использовать компонентную оценку типа для всего процесса разработки. Нет необходимости переоценивать с нуля, когда Вы хотите добавить, удалить или заменить функции, услуги и т. д.).

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

Вы можете прочитать больше на нашем блоге!

http://blog.lemberg.co.uk/project-management/software-estimation-process/

Надеюсь, эта информация поможет вам!

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

Звучит так, будто вас просят об обязательстве, а не о смете. Это разные вещи, но если вы сможете надежно управлять обязательствами, это действительно поможет вашему авторитету и карьере.

Несколько советов, основанных на моем ~ 10-летнем опыте:

• Всегда указывайте диапазон (т.е. нижнюю и верхнюю границу). Это сообщит ваш уровень неопределенности
• Если у вас очень большая неопределенность, попросите об отсрочке (например, 1 день для анализа, а затем укажите более узкий диапазон)
• Если задача слишком большая, разбейте ее и укажите диапазон для каждой части

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

Но все же все планирование поможет только в определенной степени. Только когда вы начнете кодировать, вы сможете найти точные проблемы

Если вы выполняете много проектов для одного и того же босса или клиента, вы можете попытаться оценить в общих чертах сложности, а не в неделях или месяцах, возможно, в размерах футболки. Определите несколько прошлых проектов и присвойте им размеры S, M, L, XL.

А затем спросите себя: на какой проект это похоже? И тогда вместо того, чтобы отвечать «2 месяцами», вы можете ответить «звучит как L для меня» (или что бы то ни было, ваша калибровка для проекта оказывается).

Это довольно легко понять, и также ясно, что в этих предположениях много неопределенности.

Затем, когда требования меняются, вы можете сказать: «это изменение делает его более похожим на XL».

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