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

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

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

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

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

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

В идеальном мире решение проблемы было бы сложной проблемой A, и вы могли бы в определенный момент времени разложить ее на короткий список небольших задач от A ₁ до 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 часов, если все в порядке.

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

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

Обычно я использую модифицированную формулу из 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.

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

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

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

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

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

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

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

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

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

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