Как ответить «Когда это будет сделано?»

9

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

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

Мэтт Слэйни
источник
3
Подход Blizzard или Valve: когда это будет сделано.
DeadMG
5
«Это зависит от того, как часто меня будут отвлекать люди, которые спрашивают, когда это будет сделано».
Инго
«Когда это будет сделано. Вы не можете спешить с кулинарией и кодированием».
Гилберт Ле Блан

Ответы:

24

Вы отвечаете на вопрос честно.

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

MattBelanger
источник
1
+1, и я хотел бы добавить к этому, что вы также добавите, что на основе вашей наилучшей оценки с тем, что вы знаете, вы ожидаете завершения в течение [периода времени завершения], а также добавьте предупреждение, что фактическое время завершения будет зависеть от [ причины]. Честность всегда лучше, и ваши клиенты с большей вероятностью будут работать с вами, если вы будете иметь с ними дело, не прибегая к ласковым словам, полуправде или откровенной лжи.
С.Робинс
7
@ S.Robins: опасность дать такую ​​лучшую оценку состоит в том, что она имеет тенденцию сообщаться вверх без предупреждения.
Майкл Боргвардт
1
Я бы дал оценку той части проблемной области, о которой вы знаете. «Я узнаю больше, когда буду исследовать х, и смогу обновить тебя».
Джеймс Снелл
10

Разработчики подходят к сложной проблеме, разбивая ее на более мелкие и решая их отдельно.

В идеальном мире решение проблемы было бы сложной проблемой A, и вы могли бы в определенный момент времени разложить ее на короткий список небольших задач от A 1 до A n , для каждой оценки времени достаточно просто, учитывая что время, необходимое для решения первоначальной сложной проблемы, будет:

введите описание изображения здесь

где D - процесс самого разложения.

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

Вы можете еще:

  • Разделите данную задачу (решение проблемы) на более мелкие куски, каждый из которых по-прежнему является сложной проблемой,

  • Оцените ожидаемое время для каждого куска и соответствующий риск.

    Например, задача 1 требует прибл. 5 часов, но риск быть заблокированным при этом высок, поэтому дайте клиенту 12 часов.

  • Оцените зависимости и как они влияют на время.

    Например, для задачи 19 требуется 2 часа, а риск настолько низок, что можно сказать, что это точно 2 часа. Не 1. Не 3. Но задача 19 опирается на задачу 24: задача 24 может повлиять на задачу 19 таким образом, что вам потребуется полностью переписать код задачи 19, используя другой подход.

  • Дайте все эти детали вашему клиенту. Не давайте сумму.

Последний пункт важен. Если вы дадите сумму, скажем, 192 часа, клиент считает, что это очень точный показатель, а время, которое вы потратите, скажем, от 189 до 195 часов.

Если вместо этого вы даете детали,

  • Клиент, который заботится, поймет, что это не 192 часа. Это 192 часа, если все пойдет не так, учитывая риск, определенный во время оценки. Еще 238 часов, если все пойдет еще хуже. Это также 85 часов, если все в порядке.

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

Арсений Мурзенко
источник
«В реальном мире единственная проблема заключается в том, что t (D) будет на самом деле больше, чем время, которое вы тратите на решение небольших проблем». Применение этого метода к гибким методологиям (например, SCRUM) означает, что вам нужно больше времени для подготовки для фактической реализации пользовательских историй.
Джорджио
Это не 192 часа и не 238 или 85 часов. Это все эти значения, каждое из которых сопровождается определенной вероятностью.
JensG
4

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

bdecaf
источник
Да, и это главная причина, почему большинство сложных подходов, как правило, пустая трата времени. Как вы оцениваете неизвестное? Ну, догадываясь. Зная это, еще более удивительно, что применение некоторого анализа неопределенности к своим оценкам кажется очень редко используемым навыком в наши дни.
JensG
1

Обычно я использую модифицированную формулу из CPM / PERT. Это что-то вроде этого:

Mn + Mx + C(T) / 2 + C, where
Mn is the minimum number of hours you think it will take,
Mx is the maximum number of hours you think it will take,
T is the typical number of hours it takes,
and C is a confidence factor from 1 - 3 based on how much you've done similar things.

(Я не уверен, как сделать все математическое форматирование; если кто-то захочет это отредактировать, то не стесняйтесь.)

So, if you think:
Mn = 60  hours
Mx = 180 hours
T  = 100 hours
C  = 2
Then: 60 + 180 + 2(100) / 4 = 110 hours.

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

Гейб Уиллард
источник
0

Объяснить расплывчатые сроки неопытным пользователям сложно. Это верно как на творческих этапах проекта, так и при обнаружении надоедливой ошибки. В обоих случаях традиционное «разложение работы на более мелкие части» не работает так же хорошо.

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

MathAttack
источник
0

Поскольку вы не можете объяснить неизвестные препятствия и непредвиденные сюрпризы, может быть сложно оценить с уверенностью. Идеи:

  • Попробуйте диапазон - «Я уверен, что это займет не менее N дней (например, 3), но может занять до 4N».
  • Ищите поддержку более старших инженеров в оценке и защите оценок.
  • Работайте в более коротких итерациях (стиль Agile / Scrum), чтобы создать минимальный код, который добавляет ценность для бизнеса (завоевывает доверие и доверие), а затем повторите.
  • Изучите навыки ведения переговоров из книги, подобной классической книге «Приступая к да» (http://www.amazon.com/gp/aw/d/0143118757).
codingoutloud
источник
0

Для новых разработок, особенно Agile разработки:

«Совершенство достигается не тогда, когда нечего добавить, а когда нечего убрать». - Антуан де Сент-Экзюпер

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


источник
0

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

natman3400
источник
0

Personal Software Process (PSP) фокусируется на улучшении оценок. Это достигается за счет дисциплинированной регистрации задач. Это, по сути, несколько «ускоряет» часть «опыта» оценки, поскольку у вас будут реальные данные о типичных задачах. Конечно, эта профессия все еще требует уникальных решений многих проблем, но по моему опыту, оценки лучше после использования PSP.

Тамас Селеи
источник