Зачастую появляются такие задачи, которые сложно поставить в план, т.к. вроде их и решать надо, но есть более приоритетные задачи по проекту. Поэтому в компании которой я работаю, я придумал и внедрил относительно недавно такую вещь как Magic Tasks.
Magic Tasks — это такие задачи, которые не входят в план в краткосрочной перспективе, но их решение сейчас необходимо.
UPD: Перенес в Учись Работать.
Далее более подробно обо всем этом.
Предположим что у вас есть группа разработчиков, которая занимается каким-то проектом и задачи в плане связаны всегда с этим проектом. Вдруг появляется задача, которую надо решить, но ее решение сейчас в принципе не требуется, да и есть куча ошибок (фич), которые надо срочно-срочно править сейчас, поэтому команда загружена на N месяцев вперед. Вероятней всего на такую задачу мы повесим ярлык «срок годности с + N месяцев вперед».
Пример: Команда занимается мобильным проектом, социальной сетью, видеосервисом, напоминалкой, игрой (список можете дополнить по своему желанию), а тут появился вопрос как открыть железную дверь с электрозамком при помощи сенсора мобильного телефона. Задача явно ничего общего не имеет с проектом, но вот решить ее очень как бы хотелось, чтобы потом, можно было дать возможность всем пользователям открывать свои офисы таким образом, установив на сервер ПО и проделав определенные операции с электрозамком для того, чтобы все это чудо заработало.
Что мы видим из задачи?
1. Не очевидно кого именно кроме мобильного разработчика надо привлечь для решения этой задачи.
2. Неизвестно без определенного исследования сколько времени уйдет на решение этой задачи.
3. Очевидно, что есть более важные проблемы сейчас, нежели эта задача.
На помощь решения этого вопроса приходят Magic Tasks.
Создание экспертной группы для решения задачи.
1. Выбираются необходимые разработчики (и другие товарищи), когда понятно, кто должен делать эту задачу.
2. Участвует вся команда разработчиков.
Решение задачи.
1. Задача решается в то время, когда разработчик не занят основной задачей. Например в перерывы между работой, когда он читает новости, либо пишет в свой блог. Это даст ему разгрузку, только более выгодной для него в профессиональном плане и выгодной для компании в трате времени ресурсов.
2. Для решения задачи выбирается интервал, например месяц, с разбивкой на этапы, например неделя. Это означает, что каждую неделю должны быть какие-то итоги по задаче, т.е. она должна двигаться и завершиться через месяц.
3. Решение задачи публикуется в корпоративной Wiki, где каждый разработчик всегда сможет увидеть какие вопросы уже решены, и что требуется решить.
4. Руководитель проекта (либо тот, кто поставил задачу), является оператором задачи и отслеживает ход ее выполнения, т.к. он заинтересован в первую очередь в ее выполнении.
Плюсы такого подхода по сравнению с обычной постановкой в план:
+ Плановые задачи не сдвигаются, а выполняются.
+ Команда укрепляется за счет совместного решения поставленной задачи.
+ Разработчик отбивается от рутины, путем решения новой задачи (либо задачи, которая может быть не похожа на ту, которую он делает ежедневно), что дает ему дополнительную профессиональную точку роста.
+ Задача которая нужна будет очень сильно потом, решится уже сейчас.
+ Задача может исходить от любой ресурсной единицы проекта, а это дает дополнительную мотивацию людям, которые хотят не просто исполнять, но и создавать лучшие для себя инструменты (читайте условия).
+ Команда гораздо четче представляет специфику работу каждого из членов команды, в зависимости от конкретной Magic Task.
Минусы:
— Неэффективная трата профессиональных ресурсов на те области, в которых они не специализируются.
— Задача не всегда может решиться в заранее прогнозируемый срок.
Буду благодарен за любую критику, комментарии, дополнения.
@degravia
Magic Tasks — это такие задачи, которые не входят в план в краткосрочной перспективе, но их решение сейчас необходимо.
UPD: Перенес в Учись Работать.
Далее более подробно обо всем этом.
Пример.
Предположим что у вас есть группа разработчиков, которая занимается каким-то проектом и задачи в плане связаны всегда с этим проектом. Вдруг появляется задача, которую надо решить, но ее решение сейчас в принципе не требуется, да и есть куча ошибок (фич), которые надо срочно-срочно править сейчас, поэтому команда загружена на N месяцев вперед. Вероятней всего на такую задачу мы повесим ярлык «срок годности с + N месяцев вперед».
Пример: Команда занимается мобильным проектом, социальной сетью, видеосервисом, напоминалкой, игрой (список можете дополнить по своему желанию), а тут появился вопрос как открыть железную дверь с электрозамком при помощи сенсора мобильного телефона. Задача явно ничего общего не имеет с проектом, но вот решить ее очень как бы хотелось, чтобы потом, можно было дать возможность всем пользователям открывать свои офисы таким образом, установив на сервер ПО и проделав определенные операции с электрозамком для того, чтобы все это чудо заработало.
Что мы видим из задачи?
1. Не очевидно кого именно кроме мобильного разработчика надо привлечь для решения этой задачи.
2. Неизвестно без определенного исследования сколько времени уйдет на решение этой задачи.
3. Очевидно, что есть более важные проблемы сейчас, нежели эта задача.
На помощь решения этого вопроса приходят Magic Tasks.
Основные принципы.
Создание экспертной группы для решения задачи.
1. Выбираются необходимые разработчики (и другие товарищи), когда понятно, кто должен делать эту задачу.
2. Участвует вся команда разработчиков.
Решение задачи.
1. Задача решается в то время, когда разработчик не занят основной задачей. Например в перерывы между работой, когда он читает новости, либо пишет в свой блог. Это даст ему разгрузку, только более выгодной для него в профессиональном плане и выгодной для компании в трате времени ресурсов.
2. Для решения задачи выбирается интервал, например месяц, с разбивкой на этапы, например неделя. Это означает, что каждую неделю должны быть какие-то итоги по задаче, т.е. она должна двигаться и завершиться через месяц.
3. Решение задачи публикуется в корпоративной Wiki, где каждый разработчик всегда сможет увидеть какие вопросы уже решены, и что требуется решить.
4. Руководитель проекта (либо тот, кто поставил задачу), является оператором задачи и отслеживает ход ее выполнения, т.к. он заинтересован в первую очередь в ее выполнении.
Плюсы такого подхода по сравнению с обычной постановкой в план:
+ Плановые задачи не сдвигаются, а выполняются.
+ Команда укрепляется за счет совместного решения поставленной задачи.
+ Разработчик отбивается от рутины, путем решения новой задачи (либо задачи, которая может быть не похожа на ту, которую он делает ежедневно), что дает ему дополнительную профессиональную точку роста.
+ Задача которая нужна будет очень сильно потом, решится уже сейчас.
+ Задача может исходить от любой ресурсной единицы проекта, а это дает дополнительную мотивацию людям, которые хотят не просто исполнять, но и создавать лучшие для себя инструменты (читайте условия).
+ Команда гораздо четче представляет специфику работу каждого из членов команды, в зависимости от конкретной Magic Task.
Минусы:
— Неэффективная трата профессиональных ресурсов на те области, в которых они не специализируются.
— Задача не всегда может решиться в заранее прогнозируемый срок.
Буду благодарен за любую критику, комментарии, дополнения.
@degravia
