Здравствуйте, уважаемые подписчики и гости канала!
Как обычно, есть нюансы - работаете ли вы в команде или один. Если один, я рекомендую не думать больше, чем 1-2 часа, так как обычно первые мысли самые правильные, так как они находятся в контексте ваших ограничений по платформе, знаниям и текущим уже реализованным возможностям. Если вы не один, то читайте дальше.
Подход "здорового человека"
В умных книгах писали, что любая задача не должна быть оценена выше, чем 16 часов, так как, если программист оценивает ее выше, то отклонения от оценки будут слишком большие, причем как в меньшую, так и в большую сторону. Такая оценка, как вы понимаете ничего вам не скажет.
Так вот, совмещая эти теоретические знания с темой нашего разговора можно сказать, что если вы думаете или собираетесь думать долго, то вместо обдумывания большой сложной задачи, вам сперва надо (желательно с коллегами):
- разбить её на более понятные блоки
- взять отдельные задачи "Исследования" на обдумывание каждого блока
- защитить на техническом ревью перед другими коллегами предлагаемые решения
- начать делать задачи, при этом часть из них можете делать не вы, так как после предыдущих понятных блоков больше людей будет понимать, что в целом надо делать и как оно работает
Этот подход позволяет сделать планирование и оценку задачи более управляемым, и не замыкать задачу на себе, что хорошо для командной работы. Минусы тут понятные - на задачу сразу тратится больше времени многих людей, но плюсы, как мне думается, будут перевешивать.
Подход номер 2: путь одинокого воина
Есть другой подход - это когда вы получаете большую задачу и начинаете сами ее делать, ни с кем не посоветовавшись и не обсудив. В этом случае есть вот такие риски:
- вы на долго забуритесь в "продумывание", вероятно у вас не будет ни плана продумывания, ни документации (так как зачем, если вы один ее делаете и "все может поменяться")
- команда не понимает что происходит и почему именно так делается или команда узнает о техническом решении уже на ревью полностью готового кода
- вы начинаете поддерживать еще один кусок кода, который знаете только вы
- команда не развивается, как могла бы
В каких-то случаях этот подход тоже оправдан, например нехватка людей, но опыт показывает, что когда "воин" уходит в отпуск, то все быстро ломается, никто не знает как это чинить и для проекта целом - это провал.
Некоторое время назад для себя я решил, что с пути одинокого воина надо сворачивать, так как развития тут меньше, чем нужно.
А на этом всё, спасибо за внимание!
Подписывайтесь на канал, ставьте лайки, оставляйте комментарии - это помогает продвижению в Дзене.
Кроме этого:
Подписывайтесь в Telegram: https://t.me/lets_goto_it
#планирование задач #программирование #teamlead #python #php #менеджмент