Pull to refresh

Comments 23

Ну, один проект жирно, два — самое то. Переключаться полезно, потому что это слегка развеивает мозг. Столкнулся с непреодолимой проблемой в одном, поковырялся в другом, раз, начал чуть иначе думать, решил проблему в первом…
Поддерживаю.
Ещё и обучаемость повышается.
UFO just landed and posted this here
Проекты разные бывают.
а вот меня это бесит… сидишь, работаешь над задачей, а тебе пишут… там-то там-то надо сделать то-то, срочно! и раз уж ты будешь это делать, заодно сделай ещё и то.
ты понимаешь: да, это важно, и переключаешься, и делаешь… сделав идёшь передохнуть, выпить кофе, а потом снова садишься за первую задачу. вспоминаешь, где остановился… и если не повезёт — что-нибудь обязательно забудешь, и тебе придётся это исправлять, когда будешь заниматься новой задачей

конечно, при хорошо поставленном процессе, все эти переключения могут обходиться без багов. но время всё равно теряется
UFO just landed and posted this here
На многозадачных проектах так же возникает проблема с расстановкой приоритетов. Например, у вас два проекта и вы понимаете, что по одному из них вы уже не вписываетесь в сроки. Правильный ответ — нужно идти к руководителю проектов, чтобы он перерасчитал свои красивые графики с учётом новых сведений.

А теперь вопрос из практической области: «Сколько вы знаете руководителей проектов, которые будут динамические обновлять свои графики, а не нарисуют их один раз в начале, а потом будут пытаться всех изнасиловать, чтобы вписывались в первоначальные сроки»?
Если работать над одним проектом — ситуация схожая. Я в таких случаях иду к руководству и объясняю — я могу успеть в сроки, но это будет не конечный продукт. Этим продуктом можно будет пользоваться, можно будет показывать, но он еще должен быть в разработке и должен дорабатываться, рефакториться и т.п. А предлагать незаконченный продукт — портить свой имидж перед конечными пользователями. Руководство подумает-подумает и в итоге согласится.
Схожая, но более простая в психологическом смысле. При многозадачности у вас появляется замечательная возможность продолбать сроки по более чем одному проекту одновременно.
Значит, нужно не заниматься фигней, а подобрать сроки и работать. Мотивация — месяц на стройке и мозги начинают не то что действовать, а в передовом темпе!
кстати, если бы можно было провести дополнительный отпуск в месяц работая на стройке, хоть даже за зарплату строителя, я бы не был против. отличная возможность вернуться в хорошую физическую форму и заодно разгрузить мозг от всякого неизбежного мусора
Лично я соглашусь только на один вид многозадачности. Один приоритетный проект, плюс дополнительная работа на дополнительных, когда отсутствует работа по приоритетному. Соответственно, сроки выставляются и гарантируются только для приоритетного проекта.
Согласен. При этом дополнительные проекты как правило бывают глотком свежего воздуха и способствуют успешному продвижению основного.
В качестве дополнительных либо несрочные мини-проекты, либо реализация собственных мыслей, эксперименты и т.п.
Переключение на новую задачу полезно в случаях рестрикционизма и прокрастинации // о какие я слова знаю! %)

Главное, чтобы восстановилась продуктивность при возврате к первой задаче — а это уже не всегда само происходит, тут надо помогать сотрудникам.
Эм… Попробую перевести на русский. Переключение на новую задачу полезно в случаях, если вы сознательно или подсознательно работаете хуже, чем обычно? По моему мнению, в обоих случаях не поможет.
Для меня лично многозадачность однозначное зло.
У меня переключение контекста происходит очень долго и мучительно, и я не могу делать одновременно даже две несложных задачи, например, говорить по телефону и читать/писать что-то.

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

Главное — чтобы никто не дергал посреди выполнения этой подзадачи, в этом случае производительность падает на порядок.
Тут недавно как раз проскакивал топик с книгой «Факты и заблуждения профессионального программирования». Косвенно подтверждает основную мысль данного топика.

Если мы не можем с приемлемой точностью оценить сроки по одному проекту, то что мы получим, если возьмёмся сразу за несколько?
В Brain Rules говорилось, что многозадачности у человека нет, и говорить по телефону и вести машину одновременно он не может (что в принципе правда). Кому верить?
Наверное, надо говорить, что полноценно и то и то делать он не может, так как просто часто-часто переключается между этими двумя задачками. А в жизни то люди водят машину разговаривая по телефону — тот же наушник с блютусом вполне себе это позволяет.
Говорят, у французов была рекламная компания, нацеленная на повышение безопасности вождения. Вывешивались плакаты с надписью: Если ты одной рукой ведешь машину, а другой обнимаешь женщину, то знай, что и то, и другое ты делаешь плохо.

Вообще же все от индивидуальных особенностей человека зависит и даже от его пола. В среднем мужчина хуже справляется с несколькими одновременными задачами, чем женщина.
Хорошая статья. Но для полноты картины стоило бы оговориться, что есть проекты, на которых исполнители зависят от времени реакции других отделов/организаций и т.п. Иными словами, тремя людьми проект делается столько же времени, что и шестью. Потому что работы должны идти синхронно. И даже у трех специалистов возникают простои (а убрать никого нельзя, т.к. они — разных специализаций).
И в этом случае выдача параллельных проектов — неизбежность, никакой работодатель не захочет, чтобы его сотрудники в потолок плевали за его же деньги. Тем более, периоды безделья или совсем ненапряжной работе плохо сказываются на боевом духе.
И тут достаточно неплохим вариантом мне кажется чередование периодов плотной работы по одной задаче с периодами перескоков между мелкими задачками. Если соблюсти баланс между данными периодами (к слову, разный для разных людей), получится вполне себе неплохой результат.
В команде разработчиков так часто и получается (месяц разработки, потом — 2 недели внедрения).
> но проекты 2 и 3 во втором случае завершаются быстрее.

Может всё таки 1 и 2?
Третий то одновременно по обоим графикам.
Как project manager не согласен с графиками на рис. 2 и 3. Не бывает одновременного старта и окончания проектов у всех участников команды — разработка проектной документации, создание архитектуры проекта, проектирование БД, дизайна, тестирование, deployment и многие другие стадии выбиваются из стройного прямоугольника показанного на этих рисунках
Sign up to leave a comment.

Articles