Формат взаимодействия руководителей в условиях крайней занятости

[Андрей Абукас]

Здравствуйте, уважаемые пользователи форума!

Мне 27 лет, я занимаюсь научными исследованиями в области строительных материалов.
Моему партнёру 33 года, у него свой строительный бизнес.

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

Проблема:
У меня очень неоднородный рабочий график, в основе которого лежит 5-дневная рабочая неделя, но при этом я могу выделить 1-2 дня посреди недели.

Он тратит на бизнес 6 дней в неделю и работает по 14-16 часов в сутки. Свободное время есть только в воскресенье.

Раньше мы могли спокойно обмениваться сообщениями, например, в телеграме, и созваниваться время от времени. Общение за последнее время показало, что максимум, чем мы могли обменяться, это 4-5 сообщениями. Проект требует более значительных временных вложений. Нужно работать над ним хотя бы 1-2 часа каждый день.

В общем, мы в каком-то временном тупике, а т.к. мы начинающие, то ещё недостаточно хорошо умеем выстраивать свой рабочий график. Ломаем голову, как перестроить график, и ничего не можем придумать.

Может, есть какие-то схемы взаимодействия, позволяющие работать над несколькими проектами в наших условиях.

С уважением, Андрей А. и Андрей Л.

[StaFFорд]

Изучайте тайм менеджемент.

Первый, который в найме, после работы уделять время и разбор полетов.

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

[nomenix]

5 часов назад, Андрей Абукас сказал:

Может, есть какие-то схемы взаимодействия, позволяющие работать над несколькими проектами в наших условиях.

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

Что касается алгоритмов планирования в плотном графике, то после определенного количества задач использовать простые структуры, вроде матрицы Эйзенхауэра не получается и с определением важности и срочности постоянные проблемы, тем более, что они еще и бывают взаимосвязаны. Очень часто какая-то сложная задача внезапно захватывает время и здесь могут быть еще полезны SJN shortest job next - когда наиболее короткая задача имеет высший приоритет, такие задачи в графике ставятся первыми с целью уменьшить вероятность захвата времени и срыва последующих задач. Для тех задач, которые более-менее легко прерываются - циклический Round-robin (в классическом таймменеджменте его аналог скорее всего Метод «Помидора»), когда есть несколько задач и на каждую фиксированное время и по кругу.  Конечно же, это можно довести до абсурда и такой период в любом случае не одинаков. Если задача захватывает времени намного больше положенного, что угрожает другим задачам, то она останавливается, что в целом логично и способ удобен возможностью снова вернуться к задаче, которая была приостановлена ради других. Это предотвращает потерю времени, когда одна задача захватывает весь вечер\день, а так её можно перенести и т.п. играться с периодом времени, который выделен на каждую задачу из списка, поскольку угадать длительность разных задач обычно не выходит. Но не все задачи способны дробиться на части и порой такое переключение трудно или невозможно.

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

Отсюда любую область\отрасль\занятие\предмет есть смысл поделить на модули до удобного размера, что сильно облегчает управление и прокачку по ним навыков. Без этого планирование очень теряет в своей эффективности и на календарь\планировщик никак не натягивается. Такие модули сами обычно формируются, например, из файловой системы - библиотека и прочие файлы раскидываются по директориями, которые намекают на модульность. Обязательно что-то окажется относительно бесполезным и потери времени себя оправдывать не будут или еще какой-нибудь риск. Можно понизить чему-то приоритет, а разницу во времени направить на проект. Конечно же, можно попробовать более сложные очереди с приоритетами или выдумать свой подходящий способ управления задачами, но может начаться путаница и потери времени на такое планирование будут больше выигрыша. Если Вы будете все планировать, а кто-то связанный с Вами не будет, то эффективность планирования может запросто сойти на нет, поэтому вообще существует философский вопрос, эффективно ли планирование вообще, возможно и нет, поскольку графики обычно постоянно срывают другие люди, госструктуры и т.п., где никакого планирования нет в принципе.
 

Как ученый, Вы наверное больше должны быть заинтересованы в проекте, поскольку это прокачка Вашим навыкам, возможно, тут есть вариант сдвинуть свой график, смотря насколько критично время после работы: занятия с субботы\воскресенья на вечер четверга и пятницы, хотя тут лучше бы втюхать в один день, а то, что там было перенести на выходные, чтобы воскресенье или его половину сделать более-менее рабочим, тогда у Вас совпадут воскресенья. Конечно, за счет усталости после работы Вы что-то потеряете и если там будут мозговыдирающие задачи, специально поставленные после отдыха, то их никак не выйдет выполнить. Тогда есть вариант что-то заморозить, упростить, вообще убрать и т.п., но зато Вам не нужно никого уговаривать менять свой график, все же планирование - личное дело каждого)

[Андрей Абукас]

Исчерпывающий ответ. Благодарю всех за советы!

[Андрей Абукас]

17.01.2021 в 20:49, nomenix сказал:

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

Что касается алгоритмов планирования в плотном графике, то после определенного количества задач использовать простые структуры, вроде матрицы Эйзенхауэра не получается и с определением важности и срочности постоянные проблемы, тем более, что они еще и бывают взаимосвязаны. Очень часто какая-то сложная задача внезапно захватывает время и здесь могут быть еще полезны SJN shortest job next - когда наиболее короткая задача имеет высший приоритет, такие задачи в графике ставятся первыми с целью уменьшить вероятность захвата времени и срыва последующих задач. Для тех задач, которые более-менее легко прерываются - циклический Round-robin (в классическом таймменеджменте его аналог скорее всего Метод «Помидора»), когда есть несколько задач и на каждую фиксированное время и по кругу.  Конечно же, это можно довести до абсурда и такой период в любом случае не одинаков. Если задача захватывает времени намного больше положенного, что угрожает другим задачам, то она останавливается, что в целом логично и способ удобен возможностью снова вернуться к задаче, которая была приостановлена ради других. Это предотвращает потерю времени, когда одна задача захватывает весь вечер\день, а так её можно перенести и т.п. играться с периодом времени, который выделен на каждую задачу из списка, поскольку угадать длительность разных задач обычно не выходит. Но не все задачи способны дробиться на части и порой такое переключение трудно или невозможно.

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

Отсюда любую область\отрасль\занятие\предмет есть смысл поделить на модули до удобного размера, что сильно облегчает управление и прокачку по ним навыков. Без этого планирование очень теряет в своей эффективности и на календарь\планировщик никак не натягивается. Такие модули сами обычно формируются, например, из файловой системы - библиотека и прочие файлы раскидываются по директориями, которые намекают на модульность. Обязательно что-то окажется относительно бесполезным и потери времени себя оправдывать не будут или еще какой-нибудь риск. Можно понизить чему-то приоритет, а разницу во времени направить на проект. Конечно же, можно попробовать более сложные очереди с приоритетами или выдумать свой подходящий способ управления задачами, но может начаться путаница и потери времени на такое планирование будут больше выигрыша. Если Вы будете все планировать, а кто-то связанный с Вами не будет, то эффективность планирования может запросто сойти на нет, поэтому вообще существует философский вопрос, эффективно ли планирование вообще, возможно и нет, поскольку графики обычно постоянно срывают другие люди, госструктуры и т.п., где никакого планирования нет в принципе.
 

Как ученый, Вы наверное больше должны быть заинтересованы в проекте, поскольку это прокачка Вашим навыкам, возможно, тут есть вариант сдвинуть свой график, смотря насколько критично время после работы: занятия с субботы\воскресенья на вечер четверга и пятницы, хотя тут лучше бы втюхать в один день, а то, что там было перенести на выходные, чтобы воскресенье или его половину сделать более-менее рабочим, тогда у Вас совпадут воскресенья. Конечно, за счет усталости после работы Вы что-то потеряете и если там будут мозговыдирающие задачи, специально поставленные после отдыха, то их никак не выйдет выполнить. Тогда есть вариант что-то заморозить, упростить, вообще убрать и т.п., но зато Вам не нужно никого уговаривать менять свой график, все же планирование - личное дело каждого)

Предложил эту схему своему коллеге. В принципе, у нас вроде как есть возможность её применить, да более того, мы даже попробовали это. Вроде как удалось поработать, но пока тяжёловато. У него есть пул нерешённых юридических вопросов, а также других дел. И как их разобрать на "менее важные - более важные" он пока сам не понимает. Вчера 3 часа общались по скайпу, так он то и дело был вынужден отвлекаться на звонки по телефону. Честно говоря, сильно мешает и отвлекает, но тем не менее, хоть что-то. Попробуем доработать схему.

Посоветуйте пожалуйста ещё что-нибудь, а также хорошую литературу, попробую врубиться сам.

[nomenix]

17 часов назад, Андрей Абукас сказал:

Посоветуйте пожалуйста ещё что-нибудь, а также хорошую литературу, попробую врубиться сам.

тут я бы и сам был не против, чтобы мне подсказали или посоветовали книжек, мне интересен ТМ\проектный менеджмент\системная инженерия, знать и делать я хочу очень много, а вот времени на это все очень мало). Я честно пытался найти литературу, но большая часть подходов, которые мне встречались содержат очень резкий теоретико-практический перескок: термины и различные виды времени описываются неплохо, но потом начинается субъективизм, практически применить его трудно из-за непредсказуемости нашей жизни, да и как уже отмечал: чем более сложен личный график и содержит больше событий, тем он более хрупок и легко нарушаем другими людьми, юрлицами, государством и т.п. форс-мажорами. Скорее тут фундаментальная проблема из-за тесного соприкосновения всех наук друг с другом, где анализ спотыкается об отсутствие знаний в другой области, поскольку дьявол в деталях и общих знаний недостаточно, а все выучить нельзя, забывание, разброс знаний, прогресс и т.п.
 

Более полезным оказался Лимончелли - Тайм-менеджмент для системных администраторов, ибо книга сама по себе построена на аналогиях и он натолкнул на мысль позаимствовать идеи из других сфер. Прямую ссылку прикладывать поопасаюсь, поэтому загуглите лекцию на ИНТУИТ-е "Лекция 3: Планирование процессов", часть цикла лекций Основы операционных систем, случайно напоролся на неё и вроде бы неплохо и доступно объясняется все то, что я бегло упомянул в предыдущем комменте.
 

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

Увы, более-менее работоспособной методики для подобных приоритетов я не знаю. Для личного менеджмента есть такой вариант: в любом модуле можно выделить две части - общую и прикладную. Общая - базис с теорией наиболее важна в силу своей универсальности и переноса на разные инструменты, она формирует профессиональное мышление. Поэтому те вещи, которые непосредственно на неё влияют, улучшают или поддерживают более полезны, хотя это может быть лишь временно из-за связи с прогрессом. Те инструменты\действия и т.п., которые на общую часть влияют мало в сравнении с потерями на них времени, пересекаются с задачами других инструментов и т.п. могут быть менее ценны. Хотя и тут нужен баланс, поскольку платят-то по большей часи за инструменты)
 

Но это опять-таки скорее вырождается во взвешивание плюсов и минусов в классическом проектном менеджменте и можно попытаться натянуть, например, на известный MoSCoW - Must have, Should have, Could have, Want to have, добавляя еще атрибуты вроде полезности, стабильности, трудоемкости, риска и т.п. Получается, что в случае выше все строится вокруг выгод для личности, а во втором - для проекта, поэтому задача объединить это за счет соприкосновения с экономикой в альтернативных издержках и максимизировать функцию полезности для обоих, но скорее выйдет все равно тык пальцем в небо. Но здесь видна связь между личным управлением временем и проектным
 

Это соприкасается также и с проектным менеджментом и системной инженерией, смотря как Вы развиваете свой проект, поскольку особенности сроков, ограничений, требований и т.п. будут влиять на выбор задач.
Это соприкасается с психологией или искажением восприятия: во множестве важных задач {A,B,C...}, при увеличении элементов на каждый элемент будет приходиться меньше времени, при уменьшении - больше. При недостаточной загрузке человек думает, что более важны существующие задачи, веря в их эффективность и они блокируют новые, если же сразу накидать их, то он начинает в микрооптимизации и выискивать убийц времени. Взаимодействие - все же группа людей, в игру вступают эффекты Рингельмана, эффект пульсара и т.п. На анализ важности может влиять разные искажения: Баадера-Майнхоф, профдеформация, Даннинга — Крюгера в части соприкосновения задачи с другими отраслями, которые слабо известны, много их разных, что сильно осложняет планирование как таковое.

Такой книжки, которая этот разброс объединяет я пока не встречал, увы.
 

17 часов назад, Андрей Абукас сказал:

И как их разобрать на "менее важные - более важные" он пока сам не понимает.

Как и в любых занятиях - опыт все улучшит, главное что-то делать начать. По той же аналогии если сразу нагрузить планирование сложностью, то может быть еще хуже. Везде же постепенно идет обучение, хотя в комментах я скорее ориентировался на Вас, но кому-то может зайти и классика: Матрица Эйзенхауэра, принцип Парето, Кови и т.п. материала в сети много. Для знатной части случаев они наверное подойдут, особенно если прикрыть их методами анализа рисков: Fault tree analysis\Event Tree Analysis\HAZOP и т.п. в самом упрощенном виде. В таком сочетании грубое планирование + риск-менеджмент оно понадежнее выглядит, хотя тоже очень хлипкое. Но с выбрасыванием задач нужно все равно быть осторожным, например, помните курс диалектики общенаучной там есть закон перехода количество - в качество, который может здорово здесь подгадить: вы убираете задачу, но количество её отмен стакается и оказывается, что это нехило начинает влиять на всех и вся после определенного периода. Хотя мне кажется, как бы ни планировал, просто или сложно - все равно будут проблемы)
 

17 часов назад, Андрей Абукас сказал:

Вчера 3 часа общались по скайпу, так он то и дело был вынужден отвлекаться на звонки по телефону

Вашему партнеру есть смысл глубже посмотреть логистику. Там не только рассматривается грузы и перемещение товара, а вообще потоки как таковые. В части звонков можно определить поток информации, которую можно поделить на несколько потоков по времени обратной связи, где менее важная может где-то накапливаться. Тут же сразу можно заметить обратную зависимость качества ответа на звонок от времени на его обдумывания: на звонок он отвечает без глубокого анализа, что там происходит, за счет ограничений памяти не помнит много звонков подряд и хронология событий смазывается. Эффективность такой связи может быть крайне низкой на самом деле, чем ему в тот же мессенджер настакали голосовых сообщений, хотя опять же, смотря что за звонки. Еще есть теория организации и управления, но  как по мне потоки нагляднее, хотя и там и там графы.