Время, планы и параллельные проекты

Как написал Николай в статье о Распределение Парето:

то, что начинается как небольшое преимущество, с течением времени становиться все больше и позволяет захватить большую часть ресурсов

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

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

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

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

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

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

Подведем итоги:

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

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

А как вы считаете, выйдет что-то дельное или нет? И как можно развить это направление мысли?