Изучите методы для лучшей оценки на работе

Самое неприятное для разработчика - это постоянно отвечать на один и тот же вопрос: сколько времени вам нужно, чтобы выполнить задачу?

Сюжетная точка, час, день… это та же старая история. Кто-то хочет знать, когда ваша задача будет готова. Если вы наденете место руководителя проекта, это нормально. У них есть время, крайний срок, GANTT, и они должны это знать. Но они никогда не вставляли в вашу. Как можно угадать правильное количество времени? Как просчитать все возможные недостатки? Как справиться с тем, чем вы занимаетесь впервые, и где вам нужно время для обучения?

Оценка задачи - очень сложная деятельность, которая занимает много времени и используется для общения с клиентами. Но почему это так сложно?

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

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

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

Проблема оценки задачи

Необходимость оценивать время - очень распространенная проблема. Представьте, что ваша машина сломана. Какой ваш первый вопрос механику? Я полагаю, «Когда моя машина будет готова», это звучит очень похоже на «Когда работа будет сделана». Хорошо, может быть, вопрос конкурирует с «Сколько это будет стоить?», Но в любом случае время имеет значение 😃. В разработке программного обеспечения это то же самое, что и во всех других работах, с той лишь разницей, что вы все время делаете разные вещи. В противном случае вы делаете одно и то же дважды и, вероятно, сможете вырезать и вставить или повторно использовать что-то (иначе, почему вы в платежной ведомости?). Это означает, что в любом случае вы будете знать точное время выполнения задачи только тогда, когда она будет выполнена. Что ж, сейчас мы находим приятный парадокс.

Мы можем точно сказать длительность задачи, когда задача завершена.

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

Чем больше времени я трачу на оценку, тем лучше оценка. Но если я потрачу слишком много времени на оценку, это будет слишком дорого. Какое время нужно потратить на это?

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

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

Даже в этом случае хорошим ответом будет правило 80/20 или Парето. Если вы приложите усилие, обеспечивающее точность 80%, вам потребуется в 5 раз больше усилий, чтобы достичь 100%.

Более практичный ответ: поймите, когда пора прекратить тратить время на оценку и немного рискнуть.

Методы оценки задачи # 1: опыт

Первый, более простой способ - использовать опыт. Вы делали то же самое раньше? Сколько времени вы на это тратите? Помня о проблемах, задачах и т. Д., Вы можете предсказать, какие усилия вы потратите на этот раз. Это также верно, если вы не разработчик. Если вы менеджер проекта и попросили разработчика оценить задачу, и он скажет вам один день, а на это потребовалось три, вы будете знать, что в следующий раз время для учета составит три дня. Это может быть не идеальным правилом, потому что могут быть тысячи факторов, которые повлияли на производительность (может быть, это первый раз, когда человек выполнял эту конкретную работу?), Но помогает иметь ссылку и взвешивать оценки того же человека.

Техника оценки задачи # 2: спросите эксперта

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

Техника оценки задачи # 3: оценочные игры

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

Уловки для хорошего планирования и оценки задачи

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

  • Возьмите буфер, но не слишком много. Буфер полезен, чтобы занять безопасную зону и компенсировать недостатки. Но что, если вы обратитесь к механику, и он скажет вам, что ему нужно три месяца, чтобы поменять колеса? Может быть, вы поменяете механику. Вот почему необходим буфер, но он должен быть устойчивым. Вы можете записать лучший и худший случай, который вы можете представить, а затем оставайтесь посередине. Это очень грубый метод, но он работает.
  • Не будьте превосходны, всегда спрашивайте эксперта (или своего коллегу). Обратная связь - одна из лучших возможностей, которые у нас есть. Всегда. Просто спросите своего коллегу. Он может увидеть множество угроз, которые вы игнорируете, или предложит некоторые идеи, чтобы упростить работу и сократить расходы.
  • Разделите риски. Если что-то сложно оценить, просто не делайте этого. Попросите время изучить проблему или найдите время для создания POC. Тратить время на оценку задач раздражает, но хуже всего не сказать клиенту расценки или пропустить дедлайн.
  • Не откладывайте это слишком долго. Могут возникнуть ситуации, когда вам понадобится время для оценки. Другое, чем вы будете так заняты, что не можете ответить. Что ж, во всех случаях не откладывайте это слишком долго. Людям нужна ваша информация, и вы должны дать им обратную связь. Если времени слишком много, попросите о помощи или отложите другие дела.
  • Выберите правильный инструмент. Задача управления - это не просто бросать кости и подбирать числа. Вам необходимо часто общаться и обрабатывать информацию, ограничивая время простоя. Как вы понимаете, электронная почта или чат - не лучший инструмент для этого. Asana - отличная платформа для управления задачами, и вы можете использовать ее для управления потоком задач. В этом примере вы можете использовать доску канбан с одним шагом оценки. Вы можете найти больше трюков с доской в ​​официальном руководстве. Если вы разработчик, вы можете оценить встроенную интеграцию с исходным кодом. AzureDevOps, GitLab или GitHub - хорошие альтернативы, которые объединяют задачи с процессом разработки. Мне нравятся доски AzureDevOps для задач, но вы можете добиться отличных результатов со всеми из них.