Как эффективно реализовать правило 80/20 для времени разработчика?

Я разработчик в банке, где реализовано правило 80/20. 80% времени вы работаете над назначенным вами проектом, а 20% вы работаете над тем, что вас интересует. Однако я не совсем уверен, как это сделать. Я надеюсь, что есть другие, которые могут дать мне совет, как это сделать.

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

Должен ли я работать 4 дня над чем-то и 1 день над чем-то другим? или 4 недели и 1 неделя?

Я знаю, что это зависит от компании, но я надеюсь понять, как это делается в отрасли.

Разделите все свои задачи на подзадачи (задачи «80%», а также «задачи 20%») и запишите их. Каждое задание должно быть достаточно маленьким, чтобы его можно было выполнить максимум за несколько часов, и достаточно большим, чтобы вы могли попасть в «зону» для него (если это задание, требующее вашей концентрации таким образом). Затем выберите заказ для выполнения тех задач, которые соответствуют правилу 80/20 в неделю или в месяц, в зависимости от того, что будет уместно в вашей компании.

Я думаю, что если 20% - это политика компании, и вы выполняете свои основные проекты, боссу все равно, куда вы потратите эти 20%. Я бы постарался не слишком тратить время, по крайней мере, один день, работая над чем-то последовательно. А когда вы попадаете в зону, просто потратьте еще день или два, а потом попробуйте компенсировать, больше работая над вашими основными проектами.

Моя компания, хотя и не внедряет правило 80/20 как таковое, побуждает нас постоянно быть в курсе новейших технологий, читать другие блоги и посты, такие как программисты и т. Д., И в основном следить за тем, чтобы наши личные разработки и интересы оставались актуальными. Дата.

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

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

Каждый из нас в команде сам управляет своим временем, поэтому им решать, как они это делают. Некоторые члены команды усердно работают в начале недели, чтобы выполнить свои задачи, и в любое оставшееся время они расслабляются в своих собственных интересах. Другие, как я, склонны смешивать это в течение недели, так как я довольно часто сталкиваюсь с препятствиями в своем проекте / задаче. Так что в этот момент я перепрыгиваю на что-то другое, что довольно часто является моим собственным интересом. Однако, поскольку мы руководствуемся задачами / проектами, мне все еще нужно убедиться, что я выполнил свою работу, поэтому я обязан следить за тем, чтобы не использовать все свое время для личных задач в ущерб команде.

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

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

Если бы у меня было что-то подобное (я бы хотел), я был бы склонен сделать это так:

1. Поговорите об этом со своим боссом и убедитесь, что он / она согласен, что так оно и будет.

2. Дайте другим людям понять, что при работе над назначенными проектами они могут свободно вас прерывать / говорить / спрашивать. Но когда вы работаете над своими исследованиями и разработками, они не могут ошибаться, вы будете работать нормально.

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

На мой взгляд, у вас есть два варианта, если у вас есть законная политика компании, которая дает вам 20%. Убедитесь, что ваш план утвержден вашим менеджером.

1. Заблокируйте 2 часа каждого 8-часового дня в своем календаре на время исследования
2. Проводите один день в неделю на исследованиях, а остальные четыре - на основном проекте

Что касается того, что вы собираетесь исследовать / изучать, найдите время, чтобы создать учебный план и поставить цели. Поговорите с вашим менеджером и узнайте, есть ли у него какие-либо предложения относительно того, на чем следует сосредоточиться. Затем воспользуйтесь предложением Дока Браунса, чтобы разбить учебное время на обычные задачи. Подумайте о том, что вы изучаете в блогах.

Что бы вы ни выбрали, убедитесь, что у вас есть план и документ, который вы делаете, чтобы показать своему работодателю. Сидеть и просматривать веб-страницы, читать случайные статьи - это здорово, и вы многому можете научиться, но вам нечего показать. Отслеживание статей, которые вы читаете, помогает в этом.

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

Я понимаю, что некоторые новые технологии не поддаются стабильному развитию (CTP, Beta и т. Д.), И я не сторонник того, чтобы вы смешивали эти вещи со своей обычной работой. Если это не то преимущество, на котором движется ваша компания.