Исполнитель и многозадачность.

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

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

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

Однако в результате переключений на выполнение каждой задачи потребовалось ~7 дней. Первый менеджер получил задачу на 4 дня позже чем мог бы, соответственно были задержаны другие задания связанные с выполненным далее по цепочке (тестирование, релиз и т.п.), была задержана оплата и т.п.

multitasking_1.png

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

multitasking_2.png

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

multitasking_3.png

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

В заключение приведу несколько общих рекомендаций:

  • Создавайте очередь задач исполнителю с определенными приоритетами. Необходимо однозначное понимание что, зачем следует выполнять. Очередь необходима для того чтобы исполнитель мог переключаться на следующую задачу, при завершении текущей (а не сидеть в ожидании), либо при невозможности выполнения текущей (на время разрешенная появившихся вопросов) опять же дело не стаяло на месте.
  • Все задачи должны быть в одном месте (системе, программе или т.п.) Чтобы задания не терялись и не размывались между системами. Чтобы была возможность контролировать, кто, чем занимается в данный момент, сколько у кого уходит времени.
  • Каждая задача помимо приоритета должна иметь оцененный срок выполнения, чтобы менеджер мог эффективно управлять своими ресурсами.

3 Comments

  1. Прежде всего смущает, что менеджеры напрямую ставят задачи разработчику. Ему что, нечем заняться, кроме как разбирать входящий поток задач? Правильнее было бы поручить первичную оценку задач, их приоритезацию и выставление сроков кому-то другому, тимлиду, руководителю группы разработки. Глядишь, у разработчика больше времени стало бы уходить на выполнение его прямых обязанностей.

    И ещё. Немного странно слышать, что на переключение между задачами отдельно тратится значимое время. Конечно, если такие переключения всегда неожиданны, несомненно будут возникать сложности и паузы в работе. Но что мешает сразу всю деятельность разработчика строить так, чтобы переключения между задачами, параллельная разработка были естественными процессами? Я, по крайней мере, в своём отделе выстроила работу именно так, по конвейерному принципу. Если интересно, я пишу об этом в своём блоге (http://www.control-freak.ru/).

    Идея выстроить заказчиков в очередь — реальна ли? То есть мы можем этого хотеть, но скорее всего каждый заказчик сможет аргументированно и очень настойчиво проталкивать именно свою задачу. Вступать в вечный спор? Гарантированно разочаровать кого-то из-за того, что ему предпочли другого? Лучше начинать работу над несколькими задачами более-менее одновременно, собирать пулы похожих по каким-то критериям задач, и создавать, в результате, ощущение, что вы всё можете и можете быстро. А что каждому заказчику придётся ждать на день дольше — в подавляющем большинстве случаев совершенно некритично.

  2. Дорогая Евгения, хочу обратить внимание на ошибку «А что каждому заказчику придётся ждать на день дольше». Если посмотреть на картинку 2, то первому заказчику придется ждать 5 дней, что почти в 2 раза превышает срок самой задачи. За этим последует, более поздний feedback, более поздняя приемка, более поздняя оплата результата. Соответвенно фирме необходимо иметь большее количество оборотных средств, и в конечном итоге уменьшение прибыли.

    Может ли подождать заказчик? Конечно да! Если вы ценны как испольнитель и проекты не на 1 день, то обычно проект проходит несколько стадий, пока идет реализация проекта А, может начатся сбор требований проекта Б.

    Если заказчик мечется в агонии, что ему надо все сделать еще вчера, то его нужно просто уволить. Поверьте ваша жизнь станет намного лучше.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *