Никогда не пропускайте сроки и всегда сдавайте проекты вовремя ⏰
Клиент 😎: «Сколько времени вам нужно, чтобы создать API для этой новой модели?»
Вы😰: «Мммм, два дня? Две недели? Позвольте мне вернуться к вам по этому поводу».
Ага. Мы все были там. Будь то клиент, наш босс или скрам-мастер команды, мы часто получаем вопрос о том, сколько времени займет задача.
Обслуживание модели машинного обучения, исправление конвейера данных или строительство Сиднейского оперного театра; все эти задачи требуют планирования. Однако мы часто обнаруживаем, что срываем сроки и превышаем бюджеты, особенно те, которые устанавливаем сами. Почему это?
Ошибка планирования
Установление сроков только для того, чтобы превысить их на несколько недель, занижая бюджет проектного предложения и переоценивая легкость предстоящего пути. Это знакомое явление называется «ошибкой планирования».
Даниэль Канеманн и Амос Тверски впервые ввели этот термин при исследовании предвзятости в суждениях для Министерства обороны США еще в 1977 году. Совсем недавно Канеманн описывает симптомы ошибки планирования как планы и прогнозы, которые нереально близки к наилучшему сценарию. сценарии».
Я собираюсь показать вам, как ошибка планирования влияет на меня и как я использую метод датского эксперта по планированию Бента Фливбьерга, чтобы избежать ее.
Почему так или иначе происходит ошибка планирования?
В своей книге «Думай быстро и медленно» Канеманн объясняет, почему ошибка планирования является результатом того, что «внутреннее» и «внешнее» взгляды так сильно отличаются друг от друга.
«Взгляд изнутри» основан на текущих фактах в вашем проекте. Это включает в себя количество активных членов команды и их старшинство, задачи, которые команда успешно выполнила, и, конечно же, то, что команда планирует делать дальше. Чтобы сохранить мой пример с модельным API; мое внутреннее мнение заключалось в том, что мы оба работали с конечными точками раньше и что тяжелая работа по обучению моделей уже сделана, все, что осталось, — это обслуживать их. Легко, верно?
У людей есть привычка экстраполировать продолжительность предстоящих задач на основе уже выполненных. В моем случае обучение модели казалось сложной частью проекта, так что, конечно же, обслуживание той же модели должно быть гораздо более короткой задачей?
Проблема с использованием вашего «взгляда изнутри» для оценки будущих задач заключается в том, что он ослепляет вас в отношении «неизвестных неизвестных» Дональда Рамсфелда.
Это непредсказуемые события, которые не учитываются на этапе планирования и могут серьезно задержать вашу работу на этапе выполнения.
Эти «черные лебеди», как любит их называть Нассим Николас Талеб, часто задерживают время, необходимое для выполнения задачи. В нашем случае мы никогда раньше не развертывали конечные точки API на специально подготовленном сервере, а не в облаке. Внезапно наш предыдущий опыт стал иметь гораздо меньшее значение.
Теперь давайте рассмотрим три шага Flyvbjerg по использованию «взгляда со стороны» при планировании проекта.
Шаг 1: Определите ссылочный класс
Первый шаг — убедиться, что вы точно знаете *что* вы планируете. Нам нравится заменять сложные вопросы более простыми в соответствии с теорией замены атрибутов Канемана.
Часто при работе над проблемой машинного обучения ваша задача может состоять из различных инструментов, методов и протоколов. Когда мы планировали обслуживать модели через API, мы могли выбрать «API», «обслуживание моделей ML» или даже «ML в производстве» в качестве эталонного класса. В нашем случае клиент специально запросил веб-API, к которому можно было бы получить доступ через конечные точки на сервере. Довольно просто, нашим эталонным классом были «API, развернутые на частном сервере».
Если эталонный класс не столь однозначен, вы можете попытаться сосредоточиться на том, какие задачи определяют ваш проект. В нашем случае было важно использовать определенный инструмент (API) и развернуть его на определенной архитектуре (частный сервер). Что, если бы клиент попросил конечные точки использовать только метод GET? Что ж, это была бы дополнительная часть эталонного класса.
Шаг 2: Получите базовую ставку
Итак, теперь вы точно знаете, что именно вы оцениваете, пришло время собрать некоторые данные! Неопределенность в отношении времени выполнения задачи может быть связана, среди прочего, с отсутствием предыдущего опыта и непредсказуемыми событиями. Получение базовой ставки позволяет компенсировать недостаток опыта и быть в курсе возможных непредвиденных событий.
Во-первых, определитесь с некоторыми показателями, которые могут определить эталонный класс. Примером может быть простая продолжительность задачи или сложная количество развертываний в среде разработки. Цель здесь состоит в том, чтобы выбрать статистику, которая даст вам представление о том, как обычно выполняются эти задачи.
Для нашего проекта я решил использовать «количество недель, необходимое инженеру машинного обучения для развертывания модельного API». Я опускаю множество деталей, таких как стаж и опыт инженера, но мы вернемся к этому на следующем шаге.
Когда у вас есть метрика, вы можете начать собирать данные. Фливбьерг создал себе хорошую базу данных, содержащую различные строительные проекты (эталонный класс) и их расходы, превышающие бюджет (показатель), чтобы использовать их в качестве эталона. Конечно, никто систематически не просматривает Интернет в поисках неопровержимых фактов о статистике управления проектами в области ИТ и разработки программного обеспечения… или, по крайней мере, большинство людей этого не делает. Полезный способ сбора данных — расспросить своих коллег или прочитать блоги в Интернете о реализации проектов машинного обучения.
В нашем случае среднее время развертывания конечных точек API составляло одну рабочую неделю. Некоторые оценки, которые составляли это среднее значение, включали полный набор тестов и интеграцию с AWS, в других пользовательских историях команда из 3 человек работала над обновлением некоторых существующих конечных точек в большей кодовой базе. Все эти оценки были полезны при построении базовой ставки.
Шаг 3: Приспособьтесь к уникальным обстоятельствам
Базовая ставка — это хорошо, но, как мы видели ранее, не все проекты одинаковы. У некоторых, возможно, был опытный старший шлифовщик кода, как будто завтра не наступит, в то время как другие могли быть замедлены корпоративной бюрократией.
Взгляните на свою ситуацию и найдите конкретную информацию, которая может изменить вашу базовую ставку. Другими словами, скорректируйте эту среднюю метрику в зависимости от уникальных обстоятельств вашей задачи. Эта корректировка может идти в любом направлении. Например, большинство людей, с которыми я разговаривал, и множество блогов, которые я читал в Интернете, упоминали какую-то облачную инфраструктуру, которая уже позаботилась о внутренней сети. В нашем случае мы работали на частном сервере со слоем док-контейнеров сверху, поэтому нам пришлось немного увеличить среднее значение.
Будьте осторожны, внося коррективы в свою пользу, так как часто существует тенденция смотреть на будущее (особенно на свое собственное) сквозь розовые очки. Что бы вы ни получили в качестве окончательного значения, это будет гораздо лучшая и более обоснованная оценка, чем если бы вы не принимали во внимание внешний вид.
Шаг 4: Прибыль!
Вот и все! Кажется простым, верно? Самая важная часть этого метода — быть честным как с самим собой, так и с клиентом или заинтересованным лицом.
Это означает, что вы всегда можете сказать «Я не знаю, позвольте мне вернуться к вам по этому поводу», когда вас попросят оценить продолжительность задачи. Все мы люди, и никто не ожидает, что мы все время будем знать все.
Хорошая новость заключается в том, что вы не только оценили продолжительность своей задачи, но и можете объяснить ее причины. Больше никаких решений, основанных на интуиции!
Кормить зверя
Простой и эффективный метод оценки длительности задач. Похоже на надежный фреймворк, верно? Загвоздка в том, что он работает только тогда, когда ему подается правильная информация.
Это означает, что чем лучше ваши данные для оценки базовой ставки, тем точнее будет ваша окончательная оценка. Мой совет: записывайте продолжительность задач и обстоятельства проекта, как ваши собственные, так и обстоятельства ваших коллег, по мере их возникновения. Создайте свою собственную базу данных, как Bent Flyvbjerg.
Последний совет
Один из способов покрыть «вашу шестерку», если вы не уверены в окончательной оценке, — это старый добрый метод добавления буфера. Я обнаружил, что в целом буфер в 20% даст вам некоторую передышку. Это означает, что эти 5 рабочих дней превращаются в 6, давая вам некоторое пространство, чтобы меньше обещать и делать больше.
Буфер в 20% всегда даст вам передышку
В обзоре
Сделайте первоначальную оценку, получите базовую ставку и скорректируйте ее с учетом обстоятельств. Вот и все. И если вы когда-нибудь сомневаетесь, не стесняйтесь добавлять буфер в 20%. На всякий случай.
Надеюсь, вам понравилось читать! Нажмите кнопку «Подписаться», если вы это сделали 👨🌾
P.S. Оставьте комментарий, если вам удастся применить этот метод для оценки какой-либо задачи в вашей повседневной рутине. Хотелось бы услышать ваши истории.
Днем я инженер по машинному обучению 👨💻, любитель жизни по выбору 💫 и фанат футбола по проклятию ⚽️. Всегда ищу возможности пообщаться с крутыми ботаниками в LinkedIn.
