Ни для кого не секрет, что лучший способ научиться что-то хорошо делать — это постоянная практика. Так же обстоят дела и с оценками работы на проекте. Но мало просто оценивать. Надо потом отслеживать реальный результат, анализировать его и делать выводы, чтобы ваша методика оценивания постоянно совершенствовалась. Без этого важного компонента вы никогда не научитесь оценивать классно. Но что если найти некий способ тренироваться в оценках «на кошках»? Причем, как можно чаще и интенсивнее. О таком способе и пойдет речь в статье...
Некоторое время назад я написал статью о том как можно с помощью правильной организации своего рабочего времени и техники Pomodoro существенно улучшить свои навыки в оценивании. Сейчас же речь пойдет больше о совершенно несвязанной с разработкой областью жизни большей части из нас — передвижению по городу. Мы все так или иначе делаем это, кто-то на общественном транспорте, кто-то на автомобиле. Причем, как минимум пару раз в день. Почему бы не использовать ваши поездки для тренировки оценок?
Каждый раз, когда вы собираетесь куда-то поехать, вы задаете себе вопрос: «через какое время я буду на месте?». Чтобы ответить на этот вопрос, включаются механизмы оценки: вы вспоминаете прошлые ваши поездки, смотрите на пробки по карте, анализируете состояние машины и прочие факторы. В результате у вас возникает некая оценка. Точна ли она? К сожалению, люди делятся на пунктуальных и не очень. У пунктуальных эта оценка будет более точной, возможно дополнительно заложен буфер на различные риски. Поэтому они чаще всего приезжают вовремя и с ними приятно иметь дело.
Итак, метод очень прост:
- перед очередной поездкой дайте временную оценку;
- по мере продвижения сверяйте ее с реалиями и старайтесь изменить план на лету, чтобы вложиться в данную оценку;
- запоминайте обстоятельства, которые вам помешали, и как именно они повлияли на вашу оценку;
- по приезду подведите итоги и сделайте выводы.
Я увидел много схожего в процессе передвижения по городу и разработке ПО.
Во-первых, вроде цель и объем работ понятны и прозрачны — вы точно знаете адрес и у вас есть карта. Но как именно будет выглядеть дорожная ситуация и какие возникнут проблемы вы предсказать не можете. Так же и в разработке — вроде все понятно, но по мере выполнения работы может очень много всего приключиться, что нелегко предсказать.
Во-вторых, очень многое зависит от внешних факторов — других водителей, ДТП, светофоров и т.д. В разработке также есть тестировщики, аналитики, заказчик, менеджер и прочие роли, которые могут существенно повлиять на сроки выполнение работ. А еще есть техническая сторона вопроса — новые инструменты и фреймворки, дефекты в чужом коде, железо… Все, что от вас зависит очень мало, а вот воздействие на вашу работу имеет очень большое.
В-третьих, большая доля успеха зависит от мастерства и знаний водителя. Какой маршрут выбрать, в какую полосу перестроиться, где схитрить и объехать пробку. В разработке индивидуальные качества исполнителей не менее важны — опытные разработчики умеют варьировать решение и искать обходные пути.
Что же дает такой метод оценок? Ведь его результаты и полученный опыт неприменимы к области разработки.
Прежде всего, вы учитесь быть гораздо более реалистичными и убиваете в себе оптимизм разработчика, о котором уже не раз писали. Проваленные оценки заставляют вас работать над ошибками и учитывать различные факторы, закладывать временные буфера на разного рода риски. Второе преимущество — это работа с этими самыми рисками. Вы анализируете их и оцениваете влияние на ваши оценки. Это заставляет вас в последствии при оценке другой работы задавать себе вопросы: «что может пойти не так? какие есть риски и как они отразятся на времени выполнения работ? что я могу сделать, чтобы себя обезопасить?». Это очень полезное качество для разработчика, которое позволяет ему работать более предсказуемо и надежно. Ну и наконец, вы начинаете понимать, что важен не сам план, а процесс планирования. При попытке дать оценку вы задаете себе много полезных вопросов, продумываете основную стратегию, альтернативные сценарии. И это самое важное. Ведь при таком количестве внешних факторов любой план — это очень хрупкая конструкция. А вот готовность и возможность адаптироваться к сложившимся условиям без срыва оценок — это очень конкурентное преимущество для разработчика.
Не смотря на то, что разработка ПО — очень сложная и трудно предсказуемая область, находите похожие модели в других областях и тренируйтесь на них. Учитесь на своих ошибках и не повторяйте их в будущем! Ну и удачи на дорогах…
Автор: xpinjection
