Мы, как технари, уделяем мало времени разговорам о коммуникации, управлении проектами и приоритизации. Это те навыки, которые превращают хорошего программиста в отличного инженера. Сегодня я собираюсь сфокусироваться на одном из аспектов управления проектами, в котором мы очевидно плохи – искусстве оценки сроков.
Если есть сомнения в том, что это действительно необходимый навык, вспомните этот ужасный, но часто задаваемый вопрос: «Как много времени это займёт?». Даже если вы супер-Agile и не верите в дедлайны, будьте уверены, что кто-нибудь сломается под давлением и выдаст дату, к которой и будет привязана ваша команда. И когда эта дата наступит, а вы не будете готовы к запуску, ваш менеджер будет злиться, потому что из-за вас она будет глупо выглядеть; отдел продаж будет злиться, потому что они обещали самым важным заказчикам продукт уже сегодня; и ваша команда тоже будет злой, потому что они работали пять выходных подряд пытаясь вложиться в невозможный дедлайн. Так что давайте избежим всего этого и создадим план, пригодный к жизни.
Для примера я хочу предложить упражнение, которое я позаимствовал из курса “Intro to Development” от Microsoft. Цель – оценить время покраски комнаты. Это тот тип упражнения, который не требует каких-то специфичных знаний о какой-то системе.
Теперь, прежде чем скроллить вниз, подумайте и набросайте свою оценку — сколько времени уйдет на то, чтобы покрасить комнату? Не пропускайте эту часть – важно записывать свои мысли, чтобы следить за их эволюцией.
Готово?
Я надеюсь нет, потому что вы даже ещё не знаете деталей задачи! Начните с запроса спецификации и задания уточняющих вопросов.
Даже такая, казалось бы, простая задача может требовать кучу уточнений. Окей, начнём сначала. Запишите вашу лучшую оценку, прежде чем читать дальше.
Ready?
Итак, давайте отвлечёмся от покраски на минуту, чтобы вернуться в мир ПО и отметить несколько похожих моментов.
Некоторые из этих шагов могут показаться глупыми. Дважды проверить цвет? Но если упустить что-то из деталей при составлении спецификации, вы можете потратить много времени на создание того, что не нужно никому. Мельчайшее различие в спецификации (“Ой, вы хотели водостойкую, разных оттенков и на одной стене?”) может дорого стоить в будущем, в данном случае – практически удваивая изначальные сроки.
Без исследований или прототипа, вы можете потратить кучу времени впустую. Упустить фреймворк, который делает именно то, что вам нужно, например. А прототип потом покажет, что документация фреймворка нагло врала, и он на самом деле вам не подходит! Если прототип был простым и дешевым, вы только что спасли себя от потраченного на попытки внедрения фреймворка времени.
Дальше, если не разбить задачи на несколько достаточно маленьких кусков, вы можете пропустить какие-нибудь важные моменты. Например, если вы забыли, что мебель нужно отодвигать, у вас может не оказаться напарника, чтобы сдвинуть эти гигантские книжные шкафы.
И самое главный фактор точности оценки времени – был у вас такой опыт раньше, или нет. Даже с долгим и дорогим исследованием трудно узнать, сколько слоёв краски понадобится на этой конкретной стене, какая у вас скорость покраски, или как влажность в комнате влияет на время высыхания. Фактически, если вы уже делали такой проект, вы можете пропустить шаги с первого по четвёртый. Но если же нет, вас постоянно будут удивлять вещи, про которые вы забыли, и ваша первоначальная оценка времени будет всё дальше от реальной. Это значит, что более-менее правдоподобные сроки появятся только после выполнения пункта 4. Всё, сказанное до этого момента, будет простой догадкой, о который можно потом пожалеть, так что самый безопасный способ – это сказать «Я не знаю, но смогу сказать через несколько дней».
ОК, вернёмся к краскам. Мы оценили проект примерно на 12 часов. Это всё?
Нуу… шаги с грунтовкой и покраской явно менее детальны, чем остальные. Смиритесь, вы всё ещё не знаете как будет реализована эта часть, и все оценки – опять же догадки. Применяя принципы выше, попробуем ещё немного углубиться.
Вы также обнаружите, что грунтовка не сильно отличается от покраски, так что увеличиваем ещё в два раза.
Итак, в случае всего одного слоя, получается 15 часов. Фуух, это действительно намного больше, чем мы предполагали вначале! И на всякий случай добавим ещё немного времени на всякие внезапности, вроде необходимости установки сетчатого фильтра. Так что округлим до 17 часов. Всё, начинаем красить, так?
Неа, всё ещё нет!
Да, мы оценили, сколько времени уйдёт на покраску. Но это не то, что все хотят знать. Они хотят знать, сколько пройдёт времени до того, как комната будет покрашена. Это тонкое, но важное различие. Когда я спрашиваю про баг, хорошо слышать, что вы можете накодить фикс за час, но то, что мне действительно надо знать – это что у вас до следующей недели не будет времени этим заниматься, так так что заплатку я получу через неделю плюс один час! Факт того, что я технически спросил только про время на создание исправления, может быть подмечен только инженером. -_-
Так что мы всё ещё упускаем? Перерывы на умывание и еду, случайные прерывания, и войну приоритетов. Работа может быть задержана кучей проблем, ожидаемых и неожиданных. Может сегодня нужно закончить пораньше, потому что день стирки, или случилось что-то внезапное. Как вообще можно что-то предсказывать в случае такой неопределённости?
Ответ – много буферного времени, добавленного на основе предыдущего опыта. Можно рассчитать множитель для своих оценок сравнивая оригинальный эстимейт для каждой задачи и время, реально потраченное на неё. Так как каждый проект отличается от предыдущего, такой способ не даст фантастической аккуратности. Но такой множитель, применённый к оценке времени всего проекта может покрыть всё, включая ваш природный оптимизм, увеличившееся количество митингов и время на прокрастинацию в интернете.
Я не буду вдаваться в детали, потому что на эту тему уже есть подробнейшая статья от Joel Spolsky Evidence Based Scheduling. Хотя такой метод может показаться долгим, отслеживание таймшитов хотя бы для пары проектов может серьёзно улучшить ваши оценки. Также как и все другие навыки, этот тоже требует времени и усилий.
Всё вышенаписанное хорошо в том случае, если вас попросили оценить время. Но, как программисту, оценка к вам обычно приходит уже в готовом виде вместе с проектом. Может быть дедлайн был установлен маркетингом, потому что они хотят получить это до Рождества, или менеджером, которому нужна дата для координации с другими командами, у которых тоже есть свои дедлайны. Или конкретных сроков нет, но по блеску в их глазах можно сказать об Определённых Ожиданиях. Суть в том, что если вы считаете, что сроки нереалистичны, про это надо сказать.
В идеале каждый инженер должен быть способен оценить свою часть работы самостоятельно, без привязки к выданному кем-то плану. Можно легко убедить себя, что можно сделать проект за две недели, или просто не заморачиваться сильно по поводу этого срока, поставленного менеджером. Можно понять, что всё плохо, только когда вы возьмётесь за реальную работу.
Действительно важно старательно оценить сроки как можно раньше и обсудить все нереалистичные дедлайны. Просто помните, что когда вы сопротивляетесь плохо поставленным срокам, вы не Дебби Даунер, которая сражается против магического мира, где вы заканчиваете проект к Рождеству и всё замечательно. Такого мира не существует. Вы просто предпочитаете мир, в котором все ищут компромиссы между датой и набором фич для достижения цели, миру, в котором дедлайны переносятся или им в угоду приносится огромный кусок функциональности. Если ваш тимлид или PM никак не купятся на это, направьте их на статью Evidence Based Scheduling.
Да, звучит так, как будто у нас много работы. Но я могу вас уверить – для любого важного проекта аккуратная оценка сроков может позволить избежать кучи неприятностей. Надеюсь, у вас теперь есть больше инструментов для лучшей оценки проектов.
Примечание переводчика. Не могу удержаться от цитирования знаменитой в узких кругах формулы :)
Если есть сомнения в том, что это действительно необходимый навык, вспомните этот ужасный, но часто задаваемый вопрос: «Как много времени это займёт?». Даже если вы супер-Agile и не верите в дедлайны, будьте уверены, что кто-нибудь сломается под давлением и выдаст дату, к которой и будет привязана ваша команда. И когда эта дата наступит, а вы не будете готовы к запуску, ваш менеджер будет злиться, потому что из-за вас она будет глупо выглядеть; отдел продаж будет злиться, потому что они обещали самым важным заказчикам продукт уже сегодня; и ваша команда тоже будет злой, потому что они работали пять выходных подряд пытаясь вложиться в невозможный дедлайн. Так что давайте избежим всего этого и создадим план, пригодный к жизни.
Для примера я хочу предложить упражнение, которое я позаимствовал из курса “Intro to Development” от Microsoft. Цель – оценить время покраски комнаты. Это тот тип упражнения, который не требует каких-то специфичных знаний о какой-то системе.
Теперь, прежде чем скроллить вниз, подумайте и набросайте свою оценку — сколько времени уйдет на то, чтобы покрасить комнату? Не пропускайте эту часть – важно записывать свои мысли, чтобы следить за их эволюцией.
Готово?
Я надеюсь нет, потому что вы даже ещё не знаете деталей задачи! Начните с запроса спецификации и задания уточняющих вопросов.
Исходные требования
- Комната большая? 12′ x 10′ x 10′, самая обычная комната.
- У вас уже есть материалы для покраски? Нет.
- В комнате много мебели? А дверей, окон и других штук, которые надо исключить из процесса покраски? Да, вы получите фотографии.
- Какого цвета комната сейчас, и в какой цвет её будут красить? Сейчас она цвета лягушонка Кермита, и мы хотим покрасить в светло-жёлтый.
Даже такая, казалось бы, простая задача может требовать кучу уточнений. Окей, начнём сначала. Запишите вашу лучшую оценку, прежде чем читать дальше.
Ready?
Разбиваем на задачи
- Подтвердите все требования. Нужно быть уверенным что все согласны именно на этот цвет, и собираются красить одни и те же стены. (5 минут)
- Узнайте как красить комнату, если вы ещё не знаете. Вы скорее всего проясните много важных вопросов про грунтовки, и как долго нужно ждать перед нанесением следующего слоя. Повторно уточните любые неясности у заказчика – может, вы только что узнали, что краска различается ещё и по степени блеска. (15 минут)
- Составьте список покупок и приобретите все необходимые материалы: краску, валики, лотки для краски, кисточки, спецодежду, etc. (2 часа)
- “Запрототипируйте” вашу работу на небольшом участке комнаты чтобы быть уверенным, что оригинальный цвет не проступает под новым. Это может сохранить много времени если, например, вы не думали, что понадобится грунтовка, а она понадобилась (10 минут на покраску, 2 часа на высыхание)
- Снимите все со стен: картины, шторы, крышки выключателей. Отодвиньте мебель, и накройте её чем-нибудь. И пол тоже, особенно если нужно красить потолок. (30 минут)
- Вымойте стены и осмотрите их на предмет наличия трещин или шероховатостей. Вам понадобится всё это исправить перед покраской. (1 час)
- Защитите всё, начиная с плинтусов, от капель краски. Заклейте малярным скотчем все края (окон и дверей, например). (1 час)
- Загрунтуйте комнату. (1.5 часа)
- Дайте грунтовке высохнуть. (30 минут, если начинать покраску с той же точки, где начинали грунтовку)
- Отмойте от грунтовки всё оборудование, необходимое для покраски. (20 минут, но можно делать это и пока краска сохнет)
- Нанесите краску. (2 часа)
- Уберитесь. (30 минут)
Итак, давайте отвлечёмся от покраски на минуту, чтобы вернуться в мир ПО и отметить несколько похожих моментов.
Некоторые из этих шагов могут показаться глупыми. Дважды проверить цвет? Но если упустить что-то из деталей при составлении спецификации, вы можете потратить много времени на создание того, что не нужно никому. Мельчайшее различие в спецификации (“Ой, вы хотели водостойкую, разных оттенков и на одной стене?”) может дорого стоить в будущем, в данном случае – практически удваивая изначальные сроки.
Без исследований или прототипа, вы можете потратить кучу времени впустую. Упустить фреймворк, который делает именно то, что вам нужно, например. А прототип потом покажет, что документация фреймворка нагло врала, и он на самом деле вам не подходит! Если прототип был простым и дешевым, вы только что спасли себя от потраченного на попытки внедрения фреймворка времени.
Дальше, если не разбить задачи на несколько достаточно маленьких кусков, вы можете пропустить какие-нибудь важные моменты. Например, если вы забыли, что мебель нужно отодвигать, у вас может не оказаться напарника, чтобы сдвинуть эти гигантские книжные шкафы.
И самое главный фактор точности оценки времени – был у вас такой опыт раньше, или нет. Даже с долгим и дорогим исследованием трудно узнать, сколько слоёв краски понадобится на этой конкретной стене, какая у вас скорость покраски, или как влажность в комнате влияет на время высыхания. Фактически, если вы уже делали такой проект, вы можете пропустить шаги с первого по четвёртый. Но если же нет, вас постоянно будут удивлять вещи, про которые вы забыли, и ваша первоначальная оценка времени будет всё дальше от реальной. Это значит, что более-менее правдоподобные сроки появятся только после выполнения пункта 4. Всё, сказанное до этого момента, будет простой догадкой, о который можно потом пожалеть, так что самый безопасный способ – это сказать «Я не знаю, но смогу сказать через несколько дней».
ОК, вернёмся к краскам. Мы оценили проект примерно на 12 часов. Это всё?
Нуу… шаги с грунтовкой и покраской явно менее детальны, чем остальные. Смиритесь, вы всё ещё не знаете как будет реализована эта часть, и все оценки – опять же догадки. Применяя принципы выше, попробуем ещё немного углубиться.
- Подготовьте краску, смешав всё в большом ведре. Налейте немного в лоток. (15 минут)
- Покрасьте края кисточкой, не забывая про углы, и пропуская всё, что не должно быть жёлтым. Если у вас уходит 3 минуты на полтора метра плинтуса, а всего его 65 метров, то всё займет около двух часов. Плюс 20 минут на ползание вверх-вниз по лестнице. И если у вас нет лестницы, хорошо бы её добавить в список покупок. (пускай будет 2.5 часа)
- Один рас обмакнув валик в краску, вы скорее всего сможете покрыть участок стены от пола до потолка шириной с валик за пару проходов, так что на секцию в полтора метра скорее всего уйдёт минут десять. (1,5 часа)
- Ваш «прототип» подскажет, сколько слоёв краски понадобится. Это может значительно увеличить общее время, так что это тоже нужно принимать во внимание. (Умножить на число слоёв, учитывая фактор времени высыхания)
Вы также обнаружите, что грунтовка не сильно отличается от покраски, так что увеличиваем ещё в два раза.
Итак, в случае всего одного слоя, получается 15 часов. Фуух, это действительно намного больше, чем мы предполагали вначале! И на всякий случай добавим ещё немного времени на всякие внезапности, вроде необходимости установки сетчатого фильтра. Так что округлим до 17 часов. Всё, начинаем красить, так?
Неа, всё ещё нет!
Внешние факторы
Да, мы оценили, сколько времени уйдёт на покраску. Но это не то, что все хотят знать. Они хотят знать, сколько пройдёт времени до того, как комната будет покрашена. Это тонкое, но важное различие. Когда я спрашиваю про баг, хорошо слышать, что вы можете накодить фикс за час, но то, что мне действительно надо знать – это что у вас до следующей недели не будет времени этим заниматься, так так что заплатку я получу через неделю плюс один час! Факт того, что я технически спросил только про время на создание исправления, может быть подмечен только инженером. -_-
Так что мы всё ещё упускаем? Перерывы на умывание и еду, случайные прерывания, и войну приоритетов. Работа может быть задержана кучей проблем, ожидаемых и неожиданных. Может сегодня нужно закончить пораньше, потому что день стирки, или случилось что-то внезапное. Как вообще можно что-то предсказывать в случае такой неопределённости?
Ответ – много буферного времени, добавленного на основе предыдущего опыта. Можно рассчитать множитель для своих оценок сравнивая оригинальный эстимейт для каждой задачи и время, реально потраченное на неё. Так как каждый проект отличается от предыдущего, такой способ не даст фантастической аккуратности. Но такой множитель, применённый к оценке времени всего проекта может покрыть всё, включая ваш природный оптимизм, увеличившееся количество митингов и время на прокрастинацию в интернете.
Я не буду вдаваться в детали, потому что на эту тему уже есть подробнейшая статья от Joel Spolsky Evidence Based Scheduling. Хотя такой метод может показаться долгим, отслеживание таймшитов хотя бы для пары проектов может серьёзно улучшить ваши оценки. Также как и все другие навыки, этот тоже требует времени и усилий.
Перехватывая плохие оценки
Всё вышенаписанное хорошо в том случае, если вас попросили оценить время. Но, как программисту, оценка к вам обычно приходит уже в готовом виде вместе с проектом. Может быть дедлайн был установлен маркетингом, потому что они хотят получить это до Рождества, или менеджером, которому нужна дата для координации с другими командами, у которых тоже есть свои дедлайны. Или конкретных сроков нет, но по блеску в их глазах можно сказать об Определённых Ожиданиях. Суть в том, что если вы считаете, что сроки нереалистичны, про это надо сказать.
В идеале каждый инженер должен быть способен оценить свою часть работы самостоятельно, без привязки к выданному кем-то плану. Можно легко убедить себя, что можно сделать проект за две недели, или просто не заморачиваться сильно по поводу этого срока, поставленного менеджером. Можно понять, что всё плохо, только когда вы возьмётесь за реальную работу.
Действительно важно старательно оценить сроки как можно раньше и обсудить все нереалистичные дедлайны. Просто помните, что когда вы сопротивляетесь плохо поставленным срокам, вы не Дебби Даунер, которая сражается против магического мира, где вы заканчиваете проект к Рождеству и всё замечательно. Такого мира не существует. Вы просто предпочитаете мир, в котором все ищут компромиссы между датой и набором фич для достижения цели, миру, в котором дедлайны переносятся или им в угоду приносится огромный кусок функциональности. Если ваш тимлид или PM никак не купятся на это, направьте их на статью Evidence Based Scheduling.
Да, звучит так, как будто у нас много работы. Но я могу вас уверить – для любого важного проекта аккуратная оценка сроков может позволить избежать кучи неприятностей. Надеюсь, у вас теперь есть больше инструментов для лучшей оценки проектов.
Примечание переводчика. Не могу удержаться от цитирования знаменитой в узких кругах формулы :)
