Magic Tasks — решаем внеплановые задачи наравне с плановыми

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

    Magic Tasks — это такие задачи, которые не входят в план в краткосрочной перспективе, но их решение сейчас необходимо.

    UPD: Перенес в Учись Работать.

    Далее более подробно обо всем этом.

    Пример.


    Предположим что у вас есть группа разработчиков, которая занимается каким-то проектом и задачи в плане связаны всегда с этим проектом. Вдруг появляется задача, которую надо решить, но ее решение сейчас в принципе не требуется, да и есть куча ошибок (фич), которые надо срочно-срочно править сейчас, поэтому команда загружена на N месяцев вперед. Вероятней всего на такую задачу мы повесим ярлык «срок годности с + N месяцев вперед».

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

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

    На помощь решения этого вопроса приходят Magic Tasks.

    Основные принципы.


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

    Решение задачи.
    1. Задача решается в то время, когда разработчик не занят основной задачей. Например в перерывы между работой, когда он читает новости, либо пишет в свой блог. Это даст ему разгрузку, только более выгодной для него в профессиональном плане и выгодной для компании в трате времени ресурсов.
    2. Для решения задачи выбирается интервал, например месяц, с разбивкой на этапы, например неделя. Это означает, что каждую неделю должны быть какие-то итоги по задаче, т.е. она должна двигаться и завершиться через месяц.
    3. Решение задачи публикуется в корпоративной Wiki, где каждый разработчик всегда сможет увидеть какие вопросы уже решены, и что требуется решить.
    4. Руководитель проекта (либо тот, кто поставил задачу), является оператором задачи и отслеживает ход ее выполнения, т.к. он заинтересован в первую очередь в ее выполнении.

    Плюсы такого подхода по сравнению с обычной постановкой в план:
    + Плановые задачи не сдвигаются, а выполняются.
    + Команда укрепляется за счет совместного решения поставленной задачи.
    + Разработчик отбивается от рутины, путем решения новой задачи (либо задачи, которая может быть не похожа на ту, которую он делает ежедневно), что дает ему дополнительную профессиональную точку роста.
    + Задача которая нужна будет очень сильно потом, решится уже сейчас.
    + Задача может исходить от любой ресурсной единицы проекта, а это дает дополнительную мотивацию людям, которые хотят не просто исполнять, но и создавать лучшие для себя инструменты (читайте условия).
    + Команда гораздо четче представляет специфику работу каждого из членов команды, в зависимости от конкретной Magic Task.

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

    Буду благодарен за любую критику, комментарии, дополнения.

    @degravia
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 31

      0
      На моей памяти так всегда и делалось. Задача откладывается до первого «окна» в основном проекте. Просто расставление приоритетов, смена «обстановки». Участвуют те кто освобождается и кто реально может решить задачу.

      Как бы ничего сверхнового, никакой магии.

        0
        Очень редко бывает так, что в плане высвобождается свободное время у кого-либо из сотрудников. Если задача завершена раньше срока (что бывает достаточно редко), то за ней следует дальше плановая задача. Я же предлагаю, чтобы вся проектная команда участвовала в решении этой задачи.
          0
          Перенесите в блог — «Учись работать»
            +1
            У меня к сожалению, недостаточно совести кармы.
      • НЛО прилетело и опубликовало эту надпись здесь
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            Присоединяюсь к вопросу: «А как вы еще успешно(с пользой) используете корпоративную Wiki?»
              +2
              Мне сложно представить разработчика, который готов 8 часов подряд отпахать без каких-либо перерывов. Кого-то устраивает прогулка, кто-то же читает новостные (либо другие информационные сайты). Разгрузка должна всегда происходить, а какая она для разработчика — решать ему, главное чтобы разработчик не злоупотреблял всем этим. В нашей компании строго не запрещается (по крайней мере для IT отдела) доступ к каким-либо сайтам. Насколько эффективно расходует свое время сотрудник, видно из того, насколько эффективно он решает поставленные перед ним задачи.

              В качестве продукта, мы используем Atlassian Confluence. Туда пишем новости компании, планы, документацию, фиксируем идеи, обсуждаем какие-то насущные вопросы. В ней помимо всего прочего есть все необходимые документы (как уйти в отпуск, выходные дни на 20XX год, и так далее).
              • НЛО прилетело и опубликовало эту надпись здесь
                  0
                  То есть вы предлагаете вместо удобного для меня перерыва решать дополнительную задачу? (Я сейчас говорю от лица разработчика). К примеру, раз в два часа вот уже десять лет подряд я делаю перерыв на 10 минут — иду на улицу на перекур и прогулку. Такой перерыв помогает переключиться, минимально компенсировать гиподинамию, ну и покурить заодно.

                  А вы предлагаете вообще убить перерывы и 8 часов не поднимаясь работать на компанию? Где мотивация? Кроме дополнительной точки профессионального роста.
                    –2
                    Нет, я не предлагаю убить перерывы, я лишь назвал место, в котором разработчик может найти время для решения своей задачи, по собственному желанию.

                    У разработчика есть то, что он должен сделать и есть «бонус» в виде задачи, которую он может делать когда ему захочется. По итогам недели, он должен по ней продвинутся, сделает он быстрей свои основные задачи и займется бонусной, будет делать бонусную во время перерывов, будет делать бонусную по итерациям от основных — решать ему, этот процесс контролируется постфактум, по прошествию недели. Из этого объяснения (в рамках одного разработчика) может и не видно ничего сверхестественного (появилась какая-то задача, которую он должен когда-то делать), в рамках команды это решается совсем по-другому. Задача как правило небольшая, но делает ее вся команда. Вклад каждого участника позволяет сделать ее быстрее.

                    Мотивация точно такая же как и у всей работы в целом, это же не отдельный какой-то процесс. Вид задачи другой просто. К тем мотивациям которые заставляют сотрудника двигаться вперед, добавляется еще одна — точка профессионального роста.
                      +1
                      А почему бы вам вместо прочтения хабра не пойти «бонусом» пропылесосить квартиру? Заодно:
                      — выбейте ковер,
                      — выгуляйте собачку,
                      — посетите с сыном цирк,
                      — пропылесосьте автомобиль,
                      — помойте в нем коврики,
                      — приготовьте на семью вкусный ужин,
                      — и завтрак заодно,
                      — приберите хлам в документах на компьютере,
                      — разгребите фотоархив,
                      — рассортируйте папку со скачанными файлами.

                      И не говорите, что устали и что хочется отдохнуть. Отдыхать надо с пользой для семьи! Заодно вот отвлечетесь, разнообразный труд полезен ведь.

                      P.S: через неделю отчитайтесь.
                        0
                        И не говорите, что вы — не домохозяйка.

                        Разнообразный труд полезен, будете профессионально расти. А то, что вам не интересно расти в эту сторону — никого не волнует.
                    0
                    Я не совсем понял, как человек сознательно променяет свой «отдых», например, чтение новостей, на разработку внеплановой, если не сказать, левой задачи? Если он привык читать новости полчаса в день, он и будет продолжать искать эти полчаса, теперь уже уменьшая свое «полезное» время работы…
                  0
                  Напомнило подход гугла 80 на 20, только там мотивация разработчиков будет несколько сильнее, чем в вашей схеме, но, правда, результат никто не гарантирует. Но это просто пример того, что ничего революционного в этой схеме нет, как и сказали выше, обычно там и стараются поступать.
                    +5
                    Разница в том, что у гугла эти 20% свободны от основного дела, а автор предлагает ничего в графике сотрудников не менять, но еще одну задачу им впихнуть.
                    +3
                    На практике это будет выглядеть так:

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

                    — Тут дело есть — надо вот еще один проект сделать, да не когда-нибудь, а прямо сейчас.
                    — !!!??? Мы же заняты на 150%, еще и по вечерам задерживаемся на работе, какой еще дополнительный проект?!
                    — Вань, ну ты же кофе пьешь? Обед ешь? Хабр читаешь? А ты вот не ешь, не пей и не читай, а делай вместо этого еще вот проект. Отдыхать, Вань, надо с пользой для компании! А то ишь чего удумали, блоги читать! Срок тебе — месяц, отчитываться будешь еженедельно, не сделаешь — уволю.
                      0
                      Вы уже приводите крайности.

                      Начальник в первую очередь заинтересован не тем, чтобы придумать какую-либо светлую идею, и впихнуть ее своим сотрудникам, а тем, чтобы все то, что запланировано было сделано в срок. Дополнительная задача — это плюс для сотрудников, в статье, в графе минусы такого подхода, я написал "— Задача не всегда может решиться в заранее прогнозируемый срок.", т.к. этому способствует загруженность сотрудников по плановым задачам.

                        0
                        Плюс для сотрудников — это дополнительная зарплата, а не дополнительная задача. Если ваши сотрудники не садо-мазо, конечно ;-)

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

                          Дергать его никто и не собирается. Никто же не говорит, что сотрудника вытащили из-за своего места и дали ему новую задачу. Сотрудник сам решает, когда приступить к другой задаче, а когда нет. Нередко бывает, что для решения задачи сотрудник может «бить» ее, но так ничего у него и не получится, он переключается на другую задачу, а потом уже со «свежими» мозгами занимается той, что бросил ранее и это гораздо эффективнее для него будет. Также и тут.
                            0
                            Дело в том, что дергать все равно будут. Увы, но не бывает так, что не возникает проблем с ранее разработанными проектами(например, доработка или багфиксы слишком сложные для суппорта) или появление более или равно приоритетных задач при всех занятых сотрудниках.
                            Так что уж гораздо лучше и премия сотруднику и сотрудник, который рад будет на время отвлечься от текущей задачи. Ведь бывают моменты, когда решая сложный кусок задачи, просто тянет делать что-то мелкое/рутинное/не сложное, а решение сложного куска задачи пустить в «фоновом процессе».
                        +1
                        Это даст ему разгрузку, только более выгодной для него в профессиональном плане и выгодной для компании в трате времени ресурсов

                        Обычно «лишние» задачи только загружают, а не разгружают. Отдыхать тоже надо, погулять немножко, разгрузить мозг. В противном случае эффективность работы снижается. Разве что премию дать, тогда все будет нормально.
                        А то предлагаете вместо отдыха, который как я считаю просто необходим, добавить работы, предполагая, что это даже лучше отдыха.
                        Разработчик отбивается от рутины, путем решения новой задачи

                        Обычно (или может я работал в таких уникальных фирмах) бывает задач — на любой вкус. Выбирай любую. Ну или почти.
                        Лично я не вижу в этом ничего нового или оптимизаторского. Тут лишь предложение примять рабочее время сотрудника и добавить еще одну работку
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • НЛО прилетело и опубликовало эту надпись здесь
                            +2
                            Тут сложно говорить о пользе и эффективности данного способа. Кому-то это будет очень интересно, а кому-то нет. Хотя вобщем-то я когда работал дизайнером было точно так же. я в свободное время занимался решением внеплановых задач. Но только мозг иногда дает сбой, этот способ не дает разгрузку на самом деле. Наоборот дает дополнительную нагрузку.

                            А вот при планировании основных задач, выделить 10-15% рабочего времени на форс-мажоры, и из группы разработчиков найти того кому подобное было бы интересно… это да верный путь.

                            Хотя это все ИМХО
                              0
                              Согласен, что форс-мажоры надо планировать, не ущемляя отдых. При отсутствии форс-мажора время отведенное на него используется для решения текущих задач. По мне — это лучшее решение
                                +1
                                Я бы поступил следующим образом: Выделил в каждый день, 10-15% на «неопределенное», плотненько побеседовал с разработчиками и узнал что кого интересует.

                                Ну а потом, имея, хоть какое-то представление о интересах сотрудников, предлагал им решить ту или иную задачу. Этот метод давно используется в Гугл, да и тут собственно о подобном говорится.

                                как-то у нас сидел разработчик JAVA котороый придумал JAVA месенджер(он так его назвал) он им занимался в те временные отрезки что есть 10-15%, их только для отдыха планировали.

                                В итоге я с фирмы ушел, а он с фирмой на основе своего творения придумал софтину, CRM-Подобную для локального пользования + там почту локальную прикрутил… еще что-то и фирма пихала это как свой продукт. Ну и ему проценты капали.
                              +1
                              Автор объясните пожалуйста, что имеется ввиду:
                              + Плановые задачи не сдвигаются, а выполняются.


                              А вообще очень не ясная для меня статья. Как идея, так и сама новизна этой идеи под вопросом. Соглашусь с alexey_uzhva, его комментарий про светлую идею верен на все 100%.
                                0
                                Объясняю.

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

                                Дальнейший ответ на вопрос, я привел в развернутом комментарии

                                0
                                «UPD: Перенес в Учись Работать.»
                                Почему все считают необходимым написать куда они перенесли статью? Я и без этой надписи могу видеть в каком блоге она находится. Зачем мне нужно знать что она находилась где-то еще до этого?
                                  0
                                  Кнут для разработчиков вижу, а где пряник?

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

                                  Самое читаемое