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

Определение объема - это не то, над чем вы можете потратить день во время проекта и никогда больше не думать о нем. Фактически, чтобы точно определить масштаб проекта, вам необходимо уделять внимание на протяжении всего проекта во время:

  1. Этап планирования: ранние этапы определения проекта и его целей.
  2. Фаза определения объема работ: время, когда большинство людей задумывается об определении объема работ. Здесь вы пытаетесь перечислить работу, которую необходимо выполнить с учетом целей проекта, и оценить, сколько времени потребуется для их выполнения.
  3. Этап исполнения: когда вы фактически реализуете проект.

Этап планирования

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

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

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

Снизьте риски проекта как можно скорее. Два распространенных способа снизить риски проекта включают (1) предварительную работу над наиболее рискованными частями и (2) создание прототипов наиболее рискованных частей с использованием фиктивных данных и / или строительных лесов. Когда используется новая система с открытым исходным кодом или внешняя служба, это обычно представляет большой риск.

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

Вот один из способов подумать об этом: изобразите влияние проекта с течением времени, где ось Y - это влияние, а ось X - время. В начале проекта влияние составляет 0%, а в конце проекта влияние составляет 100%. Вы хотите максимизировать площадь под кривой, выполнив сначала задачи с высокой рентабельностью инвестиций.

Постарайтесь по возможности избегать переписывания больших систем с нуля. При переписывании мы склонны (1) недооценивать объем работы, (2) испытывать соблазн добавить новые функции и улучшения и (3) создавать слишком сложную систему, потому что мы слишком сосредоточены на всех недостатках первая система.

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

Этап определения объема

  • Только инженеры, пишущие код, должны заниматься задачами. Ни их менеджеры, ни PM, ни ключевые заинтересованные стороны в компании.
  • Не поддавайтесь искушению недооценивать. Будьте честны в отношении того, сколько времени займут задачи, а не в том, сколько времени вы или кто-то другой (например, ваш менеджер или команда Go To Market) хотите, чтобы они выполнялись.
  • Разделите проект на небольшие задачи, каждая из которых займет два дня или меньше. Когда у вас есть задачи, которые ограничены «примерно 1 неделей», они часто занимают больше времени, потому что вы не перечислили все подзадачи, которые вам, возможно, придется выполнить.
  • Определите измеримые этапы для достижения цели проекта. Запланируйте каждый с определенной календарной датой, представляющей, когда вы ожидаете, что эта веха будет достигнута. Затем установите какую-то внешнюю подотчетность за эти вехи, например, передав их своему руководителю и установив контрольные отметки вех.
  • Думайте об оценке времени проекта как о распределении вероятностей, а не о лучших сценариях. Вместо того, чтобы говорить кому-то, что функция будет завершена через 6 недель, скажите ему что-то вроде «вероятность завершения функции составляет 50% за 4 недели, и вероятность того, что мы завершим ее через 8 недель, - 90% . »Это заставляет людей быть более реалистичными.
  • Добавьте буфер, чтобы учесть: (1) время разработки! = календарное время в связи с встречами, собеседованиями и праздниками. Я обычно умножаю время разработки на 1,5, чтобы получить календарное время. (2) Неожиданное время выполнения задач проекта, так как всегда есть задачи, которые вы не осознавали, что вам нужно выполнить их гораздо позже, например, рефакторинг старого кода, отладка, казалось бы, необъяснимого поведения, добавление тестов. Чем больше у вас опыта в области определения объема, тем меньше будет этот множитель.
  • Используйте исторические данные. Отслеживайте, были ли в прошлом вы склонны переоценивать или недооценивать проекты (большинство людей склонны недооценивать). Соответственно скорректируйте область видимости.
  • Имейте в виду, что двукратное количество людей не означает 1/2 кратного времени разработки из-за накладных расходов на коммуникацию, времени нарастания и т. Д.
  • Рассмотрите возможность временных рамок открытых частей проекта. Вместо того, чтобы «найти лучшую платформу обработки потоковой передачи для этой системы», на что могут потребоваться месяцы исследований и создания прототипа, установите временные рамки, чтобы «найти подходящую структуру обработки потоковой передачи за неделю». Используйте здесь свое суждение, чтобы сбалансировать это с долгосрочными операционными накладными расходами.

Этап выполнения

Регулярно пересматривайте объем во время выполнения проекта. Для каждой задачи отслеживайте, сколько времени, по вашим оценкам, займет задача, а затем сколько времени фактически потребовалось вам для ее выполнения. Делайте это для каждой измеримой вехи. Если ваша область охвата отклонена на 50% для первых частей проекта, скорее всего, ваша область охвата также будет отклонена на 50% для остальной части проекта.

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

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

Принимая во внимание кредит, здесь много информации можно получить из разговоров с инженерами и менеджерами, такими как Спенсер Чан и Нихил Гарг, чтения таких книг, как Эффективный инженер от Эдмонда Лау, и личного анализа большого количества проектов. с разной степенью точности.

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

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