Про управление задачами все давно всё знают. К сожалению, или к счастью, знать там особо нечего. На любой совет, методику, практику найдутся сотни, если не тысячи комментариев, советов и ссылок, где та же информация будет рассказана подробнее, интереснее, красочнее и «на основе научного подхода».
Но, несмотря на объемы знаний, проблем в практике меньше не становится. Разговариваешь, например, с менеджером проекта – вроде он все должен знать про управление задачами. Ну да, вроде все знает. Смотришь на систему, в которой он работает – и неловко замолкаешь. Чего ж ты, чувак эдакий, при таком объеме знаний снова, в очередной, уже миллионный раз, превращаешь деятельность людей в неуправляемый кисель?
Висят задачи, которым больше года. Почему висят? Начинает заходить, читать. А, это давно сделали, надо закрыть. О, а эту уже не надо делать, заказчик давно уволился. Ух, а это классная задача, странно что мы ее просмотрели. А эта почему не двигается? Разработчик задал вопросы, а заказчик не ответил? А он знает, что надо ответить? Блин, надо проверить систему оповещений.
В управлении задачами важны не знания, а практика, воплощение знаний в рутинной, ежедневной работе. Ключевое отличие задач, как сущности, или явления природного – они бесконечны. В смысле, никогда не кончатся. Именно подсознательное желание «как можно скорее все это сделать и забыть», когда оно не сбывается (=всегда), отталкивает людей от управления задачами, заставляя переключиться в режим «все как-нибудь само устроится».
Я сам иногда впадаю в такое же состояние, хотя и знаю, насколько это вредно. Потом убеждаюсь, на цифрах, что из-за НЕуправления задачами я, или команда, или вся компания просела вдвое, в то и втрое. Это – цена невыполнения элементарных правил в обращении с задачами. Это же – стимул все-таки следовать правилам, выполнение которых увеличивает количество (и/или вес) решенных задач в 2-4 раза.
Правила нехитрые, всем понятные, им нужно только следовать.
Жизненный цикл
Суть всех правил одна – у задачи есть жизненный цикл, который она должна прожить. Все проблемы возникают из-за того, что задача зависает в каком-то этапе этого цикла, не двигается дальше и, как следствие, не завершается. Схожим образом в психологии рекомендуют обращаться со стрессом – завершить его цикл, тем или иным способом, иначе он тоже «зависает» и портить жизнь. Например, пройти через стрессовую ситуацию, испытать страх, и т.д.
Жизненный цикл задачи в упрощенном виде выглядит так: постановка – исполнение – закрытие. Если ограничиться этими тремя состояниями, то нас ожидают проблемы, потому что не понятно, как задача переходит между состояниями.
Например, мы работаем с заказчиком по задачам, используя приватные репозитории в гитхабе. Представители заказчика пишут задачи (issues), т.е. осуществляют постановку – первый этап жизненного цикла. Вроде все просто – бери и делай.
Но просто брать и делать не получается. Во-первых, задач очень много – десятки, сотни одновременно. Нужны правила выбора – какую выполнять в первую очередь. Во-вторых, не всегда понятна постановка, нужно задать уточняющие вопросы. В-третьих, мы не всегда согласны с тем, что задачу надо делать (она может быть дублем или уже решенной ранее).
Трудностей много, итог один – задача находится в непонятном состоянии. Вроде записана, а исполнение не идет. Мы задаем вопрос по задаче, заказчик не отвечает. Задача сейчас в каком состоянии? Мы написали, что решение уже есть, дали ссылку. Заказчик не отвечает, задачу не закрывает. Она в каком состоянии? Непонятно.
Вот это «непонятно» порождает массу проблем. Разработчик, заходя в список таких задач, иногда просто не понимает, что ему делать. Сначала задачу выбрать не может. Когда все-таки выберет, не может понять, надо ее делать или нет – может, еще обсуждение не закончилось. Когда сделал, написал в задаче комментарий, заказчик не проверяет. Опять непонятно.
Понятно только два состояния задачи – поставлена (появилась в списке open) и закрыта (перешла в closed).
Как именно контролировать и управлять жизненным циклом задачи, все уже знают – через систему статусов. В гитхабе есть, как минимум, два варианта реализации статусов – через метки (labels) и через вехи (milestones). Наверное, управление статусами есть в любой системе, поэтому правила можно считать универсальными.
Статусы задач
Статусов должно быть ровно столько, сколько нужно для конкретной ситуации. Нет «правильного», или «универсального» набора статусов. Главное условие – всем должно быть точно известно, кто, что и когда делать с задачей определенного статуса.
Это немного странно звучит, но с задачей, в разное время, нужно делать разные действия разным людям. В один момент нужен кодер, пишущий код. В другой момент нужен тестер, проверяющий результат. В третий момент нужен заказчик, тестирующий на своих данных. В четвертый момент нужен менеджер, постоянно напоминающий заказчику о необходимости закрыть задачу.
В зависимости от статуса различаются и подходы к работе с задачами. Элементарно, когда задача – к исполнению, с ней работает один человек. Или наоборот – один человек работает с одной задачей. Выбрал из списка, или система приоритетов выбрала, сел и делаешь.
В статусе вроде «еще не принято в работу» подход другой – один человек работает с несколькими задачами. В каждую заходит, читает, и принимает решение. Одну задачу надо отправить на доработку, задав вопросы заказчику. Другую задачу надо принять к исполнению, написать комментарий для исполнителя и поменять статус.
В статусе «выполнено, ждет проверки заказчиком» ничего особо делать не нужно, только следить за сроками. Если выполнено вчера, можно ничего не делать. Если прошло 3 дня, нужно написать комментарий, чтобы напомнить заказчику о необходимости проверки. Если прошел месяц, то пора писать менеджеру заказчика, чтобы подопнул рядовых специалистов.
Вроде все понятно, спасибо кэп. Но различия в подходах, в зависимости от статуса, должны порождать различия в процессах, в выборе алгоритма, режима и даже времени суток для такой работы.
Например, с задачами в статусах, требующих групповой обработки, нет смысла работать несколько раз в день. Намного проще и эффективнее с ними разобраться с утра, потратив полчаса, а то и меньше. Если таким правилом не руководствоваться, то придется в течение дня несколько раз отвлекаться – например, на прилетевшую новую задачу. Затраты на отвлечение оказываются неоправданно высокими (перестал выполнять текущую – прочитал новую – вникнул – что-то ответил – поменял статус – вернулся к текущей – а нет, надо покурить – а теперь кофе попить – а как после кофе не покурить?).
Как ни глупо звучит, но для задач в разном статусе нужна разная энергия. Я не специалист в энергии, определяю интуитивно, но разницу ощущаю остро. Попинать заказчиков, чтобы проверяли выполненные работы – одно. Программировать – совсем другое.
Пройдемся коротенько по статусам.
Статус «Задача поставлена»
Этот статус присваивается автоматически любой поступившей задаче. Обычно там, где я работал, источников задач два: заказчики (внутренние или внешние) и команда (разработчики, менеджер).
Тут главная, наверное, проблема в том, что не все задачи в этот статус попадают. Говоря проще, не все задачи записываются.
Несмотря на повсеместное использование автоматизированных систем управления задачами, проблема незаписанных задач еще очень актуальна. Кто-то попросил что-то сделать на совещании, или скайп-конференции. Кто-то подошел в курилке. Кто-то заглянул в кабинет и с порога начал вещать, чего ему там надо сделать.
Особенно часто задачи остаются незаписанными на заводах, где много людей, не желающих работать с компьютерами. Туда же можно отнести «крутых управленцев», которые считают, что одним своим словом, обращенным к программисту, уже оказали ему большую честь. Соответственно, он должен внимательно выслушать и «сам записать в свою сраную систему» задачу.
Отдельный поток потерянных задач – всевозможные электронные коммуникации вне системы, в основном – почта и мессенджеры. Да, есть боты, есть во многих системах автозагрузка почты. Но на 100 % проблему они не решат.
Задачи нужно записывать. Заказчиков всех видов нужно заставлять задачи записывать. Не сразу, постепенно, но приучать к мысли: если задача не записана должным образом, решена она не будет. Без обид.
Отдельной строкой хочется отметить разработчиков, которые не записывают задачи, но берутся их делать. Это невероятная гадость, потому что появляется второй, неуправляемый поток работы. Заказчики привыкают к тому, что, несмотря на объявленные правила, всегда есть запасной вариант – «вон, Колян, нормальный парень, безо всякой этой хрени берет, и делает». А уж если менеджер, или тимлид, на основе записанных задач пытается управлять эффективностью, то наличие второго потока сведет его усилия на нет.
Задача из статуса «Поставлена» должна переехать в другой – «отправлена на доработку» или «принята в работу». В бюрократических системах еще добавляются согласования – например, начальника ИТ-отдела, или руководителя подразделения заказчика, или смежных подразделений, если задеваются их процессы.
Статус «Отправлена на доработку»
Если заказчик ватный (а таких - большинство), то такой статус жизненно необходим. Он перекидывает камень в огород заказчика – делает его ответственным за участок судьбы задачи. Разумеется, отправка на доработку должна сопровождаться нормальным комментарием или вопросом, чтобы было понятно, в чем причина и что нужно сделать.
Без наличия этого статуса исполнители, всем отделом, становятся в глазах остальных эдакими терпилами, которым можно «кидать задачи», по принципу «отправил и забыл». Если поставленная задача автоматически считается принятой, качество постановки начнет стремительно снижаться, как и эффективность работы исполнителей.
Заказчик должен понимать свою ответственность в решении задачи. Наличие статуса «отправлена на доработку» помогает такую ответственность воспитать.
Путей из статуса «отправлена на доработку» два: либо обратно в «Поставлена», либо «фтопку» - такое решение может принять заказчик, если комментарии исполнителей его убедили в том, что задачу решать не следует (например, если он просит дублирующий функционал).
Разумеется, не стоит увлекаться отправкой в доработку без причины.
Статус «Принято в работу»
Тут все понятно. Приняли в работу – будем делать. Как, когда, в каком порядке – уже другая тема, не относящаяся, собственно, к жизненному циклу задачи.
У принятой в работу задачи два пути: «Выполнена» и снова «Отправлена на доработку». Понятно, что в процессе исполнения может оказаться, что задачу все-таки делать не надо. Или невозможно сделать (хотя на приемке казалось, что возможно). Или слишком затратно. Или по ходу исполнения выяснилось, что аналогичный функционал появился в одном из используемых модулей внешних поставщиков.
Но основной путь, конечно, это «Выполнено».
Статус «Выполнено»
Когда задача отмечается, как выполненная, ответственность вновь переходит к заказчику – он должен проверить результат, на своих данных. В этом месте много вариаций с промежуточными статусами, вроде внутреннего тестирования разработчиком, работы отдельного тестера, документирования и т.д., но я, для простоты, эти этапы пропущу.
В статусе «Выполнено» зависает очень много задач. Причина проста – заказчик уже получил результат (если он в продакшене), и выполнять какие-то дополнительные действия ему банально лень. Работает же, чего еще надо.
Но для исполнителей, а особенно – для их менеджера – крайне важен перевод в статус «принято заказчиком». Зачастую от этого зависит его доход. Да и банально – задача должна уйти из списка, иначе он быстро распухнет, как и затраты на его администрирование. Одно дело – двигать 10 задач, совсем другое – 100.
У задачи из статуса «Выполнено» два пути – либо она будет принята заказчиком, и ее жизненный цикл завершится, либо будет возвращена исполнителю, если результат оказался неудовлетворительным.
Управление жизненным циклом
Управлять жизненным циклом, т.е. изменением статуса задачи, можно по-разному. У вас, наверняка, есть свой богатый опыт такой работы. Добавлю и свой в копилку. Главное здесь, повторю, не знать, а делать.
Постановка задач
Первое, что нужно исповедовать – запись всех задач. Тут правило простое: задача не записана – задача не решена. В зависимости от заказчиков, их поведения и характера, можно поступать двумя способами. Первый – заставлять их записывать задачи их собственными руками. Второй – иногда записывать задачи самому, со слов заказчика. Лично мне кажется, что вторым способом увлекаться не стоит – быстро привыкают, и потом сложно отучить, воспринимают как личное оскорбление. Хотя совсем избежать роли секретаря, скорее всего, не удастся – у любого менеджера есть вышестоящий менеджер, который имеет формальное и моральное право диктовать задачи устно.
Фильтрация списков
Второе, что важно для любых статусов – возможность быстро и просто увидеть списки задач по каждому этапу жизненного цикла. В большинстве систем это делается элементарно, но бывают исключения, когда вместо простых статусов плодятся красивые бизнес-процессы с негруппируемыми этапами. В таком случае, чтобы понять состояние задачи, нужно в нее зайти и прочитать сверху донизу.
Ну и, даже при наличии красивой фильтрации по статусам, всегда есть проблема ленивых исполнителей и менеджеров, которые этот статус банально не меняют. Прочитали новую задачу, задали вопрос заказчику, а статус «отправлена на доработку» не поставили. Заказчик, конечно, получил уведомление по почте, что надо ответить на вопрос, но это случилось поздно вечером, а наутро он просто забыл. Зашел, как учили, в список своих задач, отфильтрованный по статусам «отправлено на доработку» или «выполнено», увидел пустоту, с полным удовлетворением пошел заниматься своими делами. И задача зависла.
В идеале, списки должны быть преднастроенными, особенно для заказчика. Ему, по сути, достаточно двух – «отправлено на доработку» и «выполнено», с фильтрацией по постановщику. Наличие задач в этих списках означают, что ему надо предпринять какие-то действия, т.е. у него есть задача «обработать задачи». Если списки пусты – все хорошо, от него ничего не требуется. Если захочет помониторить, зайдет в список «в работе» и посмотрит (хотя, что он там увидит?).
Аналогично должен быть преднастроенный список для менеджера исполнителей – поставленные задачи. Если в нем чего-то есть, то надо поработать – либо принять к исполнению, либо отправить на доработку. Зашел с утра, отработал, опустошил список – пошел дальше заниматься своими делами.
Сроки изменения статусов
Была у меня такая практика – обозначение сроков для статусов. Например, на принятие решения по новой задаче – один рабочий день, после чего задача начинает «краснеть».
Аналогично нужны сроки для заказчиков, только они, обычно, более мягкие. Для задач, отправленных на доработку, можно смело ставить месяц, потому что с точки зрения исполнителей такая задача как бы не существует. А раз не существует, то и переживать о ней нет никакого смысла.
Для выполненных задач, ожидающих проверки заказчиком, нормальным сроком будет 3-5 рабочих дней. Слишком короткий срок смысла ставить нет, его никогда не выполнят. Это мы, исполнители, только и делаем, что работаем с задачами. Заказчик же, с высокой вероятностью, занят совсем другими делами, какой-то своей деятельностью, и с нашими задачами может работать, в лучшем случае, раз в день.
Хранение информации о дате статуса
Выделю отдельным пунктом, хотя это вроде очевидно. Но не все системы управления задачами такую информацию содержат, увы.
Когда статус меняется, в задаче (или где-то рядом, не важно) должна сохраняться дата и время этого изменения. Некоторые полагают, что достаточно иметь такую информацию в системе версионирования, а не в самих данных. Не знаю, возможно, в каких-то системах с версиями обращаться так же просто, как с данными, мне такие не попадались в практике. Версии не надежны, их может почистить админ или регламентная процедура, вроде сжатия БД. Ну и версий ведь много, и чтобы найти ту самую, в которой изменился статус, придется повозиться. В том же гитхабе вычислить дату изменения статуса можно только через API, либо мотать комментарии и искать, где, когда и кто «added labels».
Гораздо проще добавить к объекту задачи несколько реквизитов примитивных типов (дата и время), и хранить изменения в них. Тогда очень просто вычислять «красноту» и время, прошедшее с изменения статуса. Информация о времени изменения статуса невероятно полезна при управлении, потому что жизненный цикл задачи становится измеримым. Мы точно знаем, сколько времени зада торчит в непринятых, или непроверенных, и можем принимать решение о ее дальнейшей судьбе.
Санкции
Обычно, в традиционных моделях управления задачами, санкции любого рода предъявляются только к исполнителям – за несвоевременное исполнение задачи. Но, как мы теперь знаем, жизненный цикл задачи зависит не только от исполнения.
Поэтому я предпочитаю применять санкции ко всем этапам жизненного цикла, особенно к той части, где ответственность лежит на заказчике. Понятно, что суть санкций будет зависеть от того, в каких юридических взаимоотношениях с заказчиком вы состоите.
Наиболее действенными санкции становятся, если заказчик – внутренний. У меня в практике встречались санкции вплоть до штрафов, т.е. депремирования, за неисполнение обязательств по работе с задачами, но это, конечно, перебор.
Мне больше нравятся «натуральные» санкции. Например, если заказчик поставил 10 задач, из которых 5 были отправлены ему на доработку, и он уже долгое время ничего с ними не делает, то ему закрывался доступ к постановке новых задач. Пока у него новые задачи не появляются, ситуация сохраняет статус-кво. Когда же новая задача появилась, и возможности ее поставить нет, 5 зависших задач магическим образом начинают двигаться. Конечно, некоторые проныры просто просили поставить задачу своих коллег, но такие случаи редки.
Другой пример, более мягкой санкции – автоматически закрывать задачу, которую заказчик не проверил в течение 5 рабочих дней. Это даже не санкция, а сервис, для ленивых заказчиков очень удобный.
Ситуация сложнее, когда заказчик – внешний. Приходится балансировать, и применять только очень мягкие санкции. Например, спам – тупо каждый день, или с другой разумной периодичностью, напоминать о необходимости проверить выполнение, или уточнить постановку задачи. С постановкой легче – там объективно понятно, в т.ч. заказчику – если постановку не уточнить, то задача с места не сдвинется.
С проверкой результата можно использовать хитрость – в новых задачах ссылаться на непроверенную и утверждать, что есть строгая внутренняя взаимосвязь данных или алгоритмов, и пока не будет проверена предыдущая, новую нельзя делать.
Немного статистики
Управлением задачами я, как и многие из вас, занимаюсь много лет. И до сих пор, каждый раз, удивляюсь, насколько эффективнее может стать этот процесс, если управлять жизненным циклом задач.
Каждый раз, попадая в новую компанию, или новую команду, или работая с новым заказчиком, я первое время говорю себе – нет, тут такая банальщина не нужна. Здесь сидят толковые люди, которые все сами знают, и правильно поступают. Ну не может быть, чтобы везде были одни и те же проблемы.
Несколько недель, или месяцев, я, как говорится, «не лезу не в свое дело». Работаю так, как заведено в команде. И каждый раз вижу одно и то же – стабильность. Одна и та же выработка, одно и то же количество задач в период, один и тот же перечень зависших, никакой динамики.
Терпение лопается, и начинаем управлять жизненным циклом задач. И опять результативность, и эффективность растут, и почти всегда – вдвое. Эффективность растет так же, как и результативность, потому что затраты постоянные.
Вот пример из последнего проекта. С октября начали, вышли на стабильную цифру, торчали на ней до марта, с апреля начали управлять жизненным циклом задач – и сразу прыгнули вдвое. Май – уже на уровне среднемесячной, хотя прошло меньше половины месяца, а рабочих дней в начале мая – и того меньше.
Пояснение к картинке: красная линия – основной разработчик, желтая – вспомогательный, синяя – суммарная результативность. Результативность считается, как сумма оценок в баллах по решенным задачам, проверенным заказчиком. Оценка в баллах – по системе покера планирования.
По материалам https://business-programming.ru
