Семь разноцветных деталей как базис для позиционного управления проектными задачами

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

Я эксперт по технологическому стеку 1С, программист, технический архитектор и не только – у меня много разных профессий.

В докладе я хочу рассказать об одной из своих методик работы. Я ее, конечно, не изобрел, я ее скомпилировал, сконструировал. Но именно эту методику я использую в своей производственной деятельности уже довольно давно.

Она нигде не описана, в полной мере я ее еще показывал только своим, и сейчас впервые собираюсь ее показать на публику. Поэтому доклад будет немного экспериментальный.

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

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

У доклада довольно странное название: «Позиционная классификация проектного стека и потока задач». Это инженерная методика, которая действительно позволяет управлять стеком и потоком рабочих задач, причем она абсолютно универсальна и масштабируется от уровня одного специалиста до уровня хоть всей Российской Федерации.

Но прежде чем мы перейдем к самой методике, посмотрим сначала на базовые основы – как мы вообще строим инженерные методики.

Есть разные принципы построения инженерных методик. Принцип, который я использую – не мое изобретение, я его как-то скомпилировал, сконструировал из существующих. И в шутку, а может быть и не в шутку назвал его «Принципом полковника Кольта».

Принцип очень простой – при работе с чем-то нам неизвестным мы последовательно задаем сами себе пять простых вопросов:

• Что это?

• Зачем это?

• Как это работает?

• Как мы с этим работаем?

• И какой технический профит мы как инженеры от этого получаем?

Я назвал этот принцип именем полковника Кольта, потому что эти вопросы как пять патронов в барабане револьвера Colt Paterson. И этот принцип настолько же простой и надежный.

 

Позиционное управление проектными задачами. Что это?

 

Начнем с проблематики и разберемся, какую же задачу мы решаем.

Несмотря на то, что мы ведем проектную деятельность не просто в ИТ, а во вполне конкретной отрасли, на вполне конкретном технологическом стеке, проблема, о которой пойдет речь, характерна не только для нашей отрасли и нашего сообщества, но и почти везде и у всех. И не только в профессиональной деятельности.

Проблема заключается в том, что времени перманентно не хватает. Времени всегда мало.

Давайте разберемся, почему, и подойдем к этому вопросу с инженерной точки зрения.

• У нас есть стоящие перед нами задачи, каждая из которых требует какого-то объема наших усилий.

• Усилия мы можем более-менее формально преобразовать в численный показатель рабочего времени.

• Но нам всегда могут набросать еще больше задач. И единственное, что их ограничивает – это наше рабочее время. Рабочее время всегда ограничено. Его ровно столько.

• Получается, что нам нужно распределить пока еще даже не совсем понятный нам объем задач по четко зафиксированному объему рабочего времени.

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

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

 

Зачем разрабатывать свою методику? В чем недостатки шаблонных подходов работы с задачами?

 

В чем секрет людей, которые все успевают? В том, что они ничего не успевают, но у них как-то получается успевать. Для этого и нужны инженерные методики.

Первым делом рассмотрим, какие вообще есть методики для управления потоком задач. Не мы же первые эту проблему нашли и обозначили. Эта проблема далеко не новая, я думаю, она была характерна еще в первом царстве Египта. Если мы попробуем расшифровать их папирусы, мы там увидим примерно то же самое.

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

• Можно управлять потоком и стеком рабочих задач стохастическим методом – например, вам пришло 55 писем, вы случайным образом открываете одно из них, распечатываете и работаете по нему. А как же остальные? А остальные вам обработать некогда. Это неэффективно, и даже иногда это может привести к крайне неприятным последствиям.

• Можно работать по триггеру. Это когда вы взаимодействуете с коллегами по задачам – по одной, другой, третьей. И, как только кто-то громче всех закричал в какой-то момент времени, вы переключаетесь на него. К вам приходит гневное письмо, звонок, сообщение в чат. А иногда приходят люди с вилами и факелами, спрашивают: «Почему не сделано?» – и тут же все силы бросаются туда. Это управление по триггеру.

• Можно ввести микроменеджмент и назвать его разными аббревиатурами, GTD (Getting Things Done), еще что-нибудь.

  • Можно все планировать по минутам, проводить план-фактный анализ и так далее. В конечном итоге ты обнаруживаешь, что ты 20 процентов времени тратишь на то самое планирование, фиксацию факта и план-фактный анализ – ты выбросил пятую часть своей проектной мощности просто на то, что тебе потом и не нужно.

  • Можно выставлять приоритеты. Начинается все с трех уровней – критично, важно, неважно. А потом внезапно оказывается, что есть: критично, но не совсем; важно, но критично; неважно, но нужно прямо сейчас. Начинается классификация, и примерно через полгода после внедрения такой техники управления задачами мы обнаружим, что все задачи внезапно критичные и важные. Либо же наоборот – многие задачи неважные, которые мы никогда и не делаем, но это то, что называется «технический долг». Какие последствия могут быть от его незакрытия – мы пока не знаем. У нас и так уже все в пене, все в мыле.

Это все не работает. Точнее работает, но плохо – объем работы, которая требуется для управления объемом работы, оказывается слишком высоким, отнимая время у полезной работы. Поэтому нам требуется какая-то другая методика.

 

Здесь мы подходим к понятию «инновация». Казалось бы, слова «новация» и «инновация» очень похожи. В чем разница?

Все очень просто. Новое – это просто хорошо забытое старое, переупакованное в новую упаковку. Все стало лучше, больше, мощнее – «Новый Фейри с красной крышечкой и двойным ароматом хвойного леса».

Возьмем наш айтишный пример – компьютер. Он не всегда был такой, как мы его привыкли видеть:

• первые компьютеры были механическими;

• потом электромеханическими;

• потом появились электронные лампы;

• потом – транзисторы;

• потом появились микросборки;

• а сейчас размеры этих микросборок – 3-5 нанометров.

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

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

А вот когда появится квантовый компьютер, это будет иное – не переупаковка чего-то придуманного 300 лет назад, а то, чего раньше не было никогда.

Кстати говоря, даже Бэббидж ничего нового не придумал, потому что первые компьютеры – это ткацкие станки. Там уже перфокарты использовались. А это, простите меня, 14 век. Там уже это было все придумано. А может даже и они это откуда-то взяли. Может это было еще во втором царстве Египта – мы не знаем просто, ничего не сохранилось, все сгорело.

Квантовый компьютер – это будет нечто иное, потому что квантовый принцип все-таки придумали уже в 20 веке. Когда его на практике применят и доведут до инженерии, вот тогда и посмотрим.

И нам в поставленных перед нами задачах – управлении стеком и потоком производственных задач отдельно взятого специалиста – тоже нужно нечто совершенно иное.

Я не могу сказать, что моя методика – это какая-то фундаментальная инновация, но кое-что «иное» в ней все-таки есть. Давайте посмотрим, что же в ней есть.

 

Как работает позиционное управление проектными задачами?

 

К любой проблеме нужно найти ключ. Это актуально не только для инженерных проблем: в науке это делается по-своему, в гуманитарке – по-своему, но нам всегда нужно просто найти ключ.

Поскольку мы работаем с задачами, у нас первым ключом будет сам термин «задача» – нам нужно понять, что такое задача.

Когда мы говорим «решить задачу», мы включаем не только семантическое, но и ментальное управление. Мы даем себе установку: «Я снова в школе, я решаю задачу, у меня есть условия задачи, я должен написать какие-то ответы в тетрадку и сдать учителю на проверку».

В реальном производстве, даже в айтишном, так не работает. Точнее, работает, но только на уровне стажера, который думает: «Я что-то сделал, а вы проверяйте. Ну получу двойку, потом перепишу». Это не эффективно и не рентабельно. Мы стараемся так не работать. Мы стараемся работать по-другому.

Для нас задача – это нижний уровень структуры в декомпозиции работ.

Причем для нас все работы являются проектными, потому что мы работаем в проектном бизнесе. Но процесс от проекта по управленческим техникам не отличается вообще ничем. Процесс можно считать повторяемым типовым проектом, а проект – это некий уникальный процесс. Даже в некоторых профессиональных литературных источниках описываются группы процессов для выполнения проекта. Точно так же для выполнения процесса могут быть организованы группы проектов. Это все софистика.

Управленческие техники для проектов и процессов не отличаются почти ничем. Просто в процессе у нас главное – регулярность, а в проекте – уникальность. Это как производство, которое может быть штучным, серийным или массовым. Управление производством не зависит от того, что мы изготавливаем – уникальные турбины для гидроэлектростанций или растительное масло. Техники управления производством везде едины, и они примерно похожи. Здесь ровно та же ситуация.

Итак, первый ключ к управлению потоком задач – это сам термин «Задача» в том виде, как мы его понимаем в рамках нашей производственной деятельности.

Здесь мы приходим к принципу позиционности, потому что наше участие в любой проектной задаче – это какая-то позиция, которая заключается в том:

• что ты обязан сделать в рамках задачи согласно своим должностным обязанностям – т.е. твоя позиция в проектной команде;

• что ты можешь сделать;

• что могут сделать другие – какую позицию занимают они.

Позиция может быть двигающей, блокирующей, нейтральной, слабой, сильной.

 

С задачей мы разобрались. Теперь переходим ко второму ключу – он здесь называется «коробка». Его можно назвать как-то иначе, но я в своей внутренней документации называю этот ключ так. Мне просто нравится слово «коробка». А вообще этот ключ можно назвать «пакетом», «контейнером», «разделом» – чем угодно.

Важно, что коробка – это не папка или тег, это именно ключ, потому что она отвечает за позиционную классификацию проектных задач:

• В один момент времени одна задача может находиться только в одной «коробке».

• Нахождение задачи (элемента структуры декомпозиции того или иного проекта) в одной из «коробок» означает нашу позицию внутри этой задачи.

• Сама структура коробки диктует нам алгоритм действий с тем, что внутри нее находится.

• Этих коробок несколько – в каждой из них применяются различные алгоритмы действий и различные критерии обработки задач.

• Задачи могут перемещаться из одной коробки в другую, потому что проектная (процессная) деятельность ведется непрерывно.

Главный ключ к методике – это то, что:

• каждая задача помещается в одну из коробок;

• и алгоритм действий по этим задачам различается в зависимости от того, как мы их позиционно классифицируем.

 

Ассоциативная классификация задач через метафору цвета

 

Почему именно цветные коробки – важен ли цвет, и является ли он на самом деле цветом?

Цвет здесь – понятие условное. Но я здесь должен все-таки отдать дань уважения замечательному психологу по фамилии де Боно, автору методики «Шесть шляп мышления», где описывается ролевая модель мышления в виде цветных шляп: думаешь об одном – надеваешь одну шляпу, думаешь о другом – меняешь на другую шляпу.

Его методика позволяет структурировать мышление и, как следствие, достичь эффективности в управлении своими задачами – как минимум производственными, но на самом деле и не только.

Идею своей методики я, конечно же, подсмотрел у него, потому что шляпы у него тоже цветные. Но у него этих шляп шесть, и это шляпы, а у меня семь, и это коробки. И хотя ничего общего между нашими методиками нет, кроме этих внешних признаков, тем не менее: «Спасибо, товарищ Эдуард».

Почему важен цвет?

Цвет отвечает за ассоциацию. Цвет – это вовсе не обязательно то, что ты видишь глазами. Я вот глазами уже почти пятый год не вижу ничего, тем не менее, я прекрасно понимаю, чем один цвет отличается от другого. Цвет можно описать словами – это тоже будет цвет.

Здесь мы немножко заходим в ассоциативное управление – этот цвет ассоциируется с определенной ситуацией, и нужный алгоритм сам собой всплывает в сознании.

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

Тем более что далеко не все, даже имея работающие глаза, обладают цветным зрением: примерно 7 процентов из всех нас цветным зрением не обладают. Эта статистика – вполне себе медицинский факт.

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

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

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

После того как я рассказал теорию, как это работает, расскажу, как мы с этим работаем на практике.

 

У нас есть 7 цветов – 7 коробок. Мы по ним очень кратко пройдемся.

Самый первый цвет – красный. Ассоциативно это цвет потенциальной опасности – мы понимаем, что ничего страшного еще не произошло, но может произойти.

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

Например, мы понимаем, что через неделю где-то на конкретном участке эксплуатационной зоны на той или иной СХД будет исчерпана дисковая память. Она просто закончится, если не предпринять какие-то меры – не убрать журналы регистрации, не расчистить пространство, не сжать данные, не дефрагментировать диск. Если никто в течение недели этого не делает, через неделю ваш операционный день начнется с того, что первая линия поддержки получит примерно 5000 обращений: «Недостаточно места на диске». И в этой ситуации мы ничего не можем сделать – нас не пускают в зону эксплуатации.

Это ситуация вида «красный» – красная коробка. Таких множество.

Или еще один пример – у нас на проекте есть проектная команда, а я ее руководитель. И проектная команда интересуется: «А как у нас будет с проектными премиями?»

Чтобы ответить на вопрос, мне нужно у руководства компании каким-то образом утвердить или скорректировать разработанный мной регламент проектного премирования. Но если этого не сделать за ту же самую неделю, команда будет дезориентирована, демотивирована, и дела на проекте пойдут гораздо хуже. Часть команды может даже и разбежаться, потому что: «Мы не понимаем, что происходит».

И это как раз ситуация, которая от меня конкретно не зависит, у меня там позиция слабая – я могу только писать письма, не сильно напрягая коллег с очень плотным графиком занятости.

Это тоже код «красный» – красная коробка: зависит не от тебя, но ты видишь, что есть риск аварии – неважно, организационной, управленческой, кадровой, технической и т.д.

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

 

Следующий цвет – оранжевый.

Это самый плохой цвет, его ассоциация – огонь. Если кто-нибудь просыпался внутри пожара, прекрасно знает, что цвет пламени – не красный, а оранжевый. Я, как человек, обладающий, к сожалению, таким опытом, прекрасно это знаю. Оранжевый цвет – это уже авария, когда плохое уже случилось, и «пожар» нужно тушить.

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

Примеров здесь огромное множество. Например, вчера ситуация была в красной коробке – мне как техническому эксперту по ТКВ от заказчика пришел запрос с просьбой проконсультировать по одному из типичных технических кейсов. В результате для заказчика была написана инструкция, как на одной физической машине развернуть три кластера разных версий 1С:Предприятие – разных сборок одного релиза. Чтобы был тестовый контур, подготовительный и рабочий – можно было проверить, на каком релизе работает, а на каком не работает.

Они попытались это сделать, и на следующий день от них приходит паническое письмо: «Сделали все по вашей инструкции, все базы исчезли». Это – оранжевый цвет.

Пример совершенно реальный. К счастью, базы исчезли только из реестра кластера, который почему-то не резервировался – насчет этого пришлось потом писать отдельную инструкцию. В общем, подключились, помогли. Думаю, у каждого такие были ситуации – тут примеров особо не надо.

Когда задача поступает в оранжевую коробку, алгоритм действий – все остальные мы отодвигаем и занимаемся тушением пожара. Мысленно надеваем на себя бронированную форму пожарного, выкатываем жутковатого вида пожарную машину, и едем с сиренами, брандспойтами и с запасом воды. Пока все не погасили, остальное не важно.

К сожалению, у нас бывают такие ситуации, поэтому мы должны быть к ним готовы.

 

Следующий цвет – это синий. Спокойный, размеренный цвет. Цвет синего воротничка.

Например, фирму IBM называют голубым гигантом, но она не голубой, она – синий гигант на самом деле. Называют по делу вообще-то.

Синий – это цвет спокойной запланированной работы, когда у нас есть какой-то стек задач, и мы с ним работаем.

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

На самом деле синяя коробка – это верхний уровень бэклога. Даже если мы не знаем, что такое Agile, что такое бэклог, мы все равно с этим работаем. Это задачи, запланированные к спокойному выполнению, причем с запасом по времени.

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

Что мы делаем с синей коробкой?

Все очень просто. Когда у нас нет чего-то более важного, нет пожаров, нет каких-то срочных коммуникаций, я просто открываю синюю коробку и сортирую задачи по удобному мне критерию. В качестве критериев могут быть не только приоритет и дедлайн – критериев может быть множество.

И потом я просто беру самую приоритетную задачу в работу, вхожу в поток и спокойно работаю, потом беру следующую, и все – это спокойная, продуктивная, неспешная работа.

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

 

Следующий цвет – это зеленый.

Коробка зеленого цвета – довольно странная коробка, здесь сложены задачи, по которым все уже сделано и не факт, что нами.

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

Кстати, на железной дороге раньше вместо зеленого семафора использовался синий – там было понятие «синяя волна». Но на автомобильных дорогах цвет семафора заменили на зеленый – там «зеленая волна». И от этого «зеленый огонек» и все остальное.

Зеленый – это означает «свободно», «готово», «дали добро».

Но здесь наша позиция управляющая, здесь от нас зависит, пойдет ли исполнение задачи дальше.

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

Я это уже сделал, у меня посмотреть его коммит заняло 15 минут. Но для него разбор моего ревью может занять полдня, потому что он еще все-таки даже не специалист, он еще только учится.

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

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

А потом мы получаем ошибку, кривой релиз, факап и так далее.

Это пример именно в области разработки. Точно такие же примеры можно провести по бизнес-анализу, по руководству проектами, да по любой области нашего профессионального знания. Так делать не нужно. Поэтому мы реагируем не сразу.

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

У каждого свой график, свой ритм – если мы немедленно отвечаем реакцией, мы, скорее всего, сбиваем коллег.

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

Алгоритм действия очень простой: ежедневно просматриваем, оцениваем ситуацию и даем зеленый свет по тем задачам, которые можно двигать дальше.

Повторюсь, что наша позиция здесь – управляющая.

 

Следующий цвет – желтый. Это у нас хранилище идей.

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

Но у многих задач есть причина, есть причинно-следственная связь, какой-то предшественник, предок. Предком многих задач является идея: «А не сделать ли нам вот это?»

И это не обязательно наша идея – ее могут подсказать заказчики, пользователи, коллеги, руководители. Можно даже, наблюдая на улице за стаей воробьев или ворон увидеть идею – смотришь, как они там взаимодействуют и понимаешь: «Если я организую такой обмен сигналами, я же могу это перестроить на многопоточную обработку». Такое тоже бывает.

Идею можно увидеть, подсмотреть, получить – но это пока идея, это не задача.

Идея может превратиться в задачу, как пилотный эпизод может превратиться в сериал, а может не превратиться. Но если я не записал эту идею, она исчезнет, пропадет, я о ней забуду в потоке других задач.

Пример из личной практики – мне пришла в голову идея написать определенный текст. Запланировал я себе в голове такую статью и забыл записать – что-то меня отвлекло.

Через день начал вспоминать – какая-то чушь вспоминается. Тогда помнил, а сейчас уже не помню. Причем это не от возраста зависит, а просто от того, что мощность нашего интеллекта, нашего мозга, все-таки не беспредельна.

Поэтому идею мы записываем. Это тоже бэклог – только его нижний уровень.

Что с этим делать, каков алгоритм действий?

Желтая коробка – это как чулан. Нужно периодически просматривать ее содержимое. Не обязательно каждый день – регулярность подбираем как нам удобнее.

Смотрим: какая идея уже не актуальна – выбросить; какая идея пока непонятна – черт его знает, оставить пока в бэклоге; а какая уже действительно актуальна, созрела, и можно начинать действовать.

Тогда мы из желтой коробки перекладываем ее в синюю, а иногда и в красную. Или, бывает так, что и в черную.

Напомню, что по коробкам мы раскладываем именно задачи нижнего уровня декомпозиции работ проекта – наши личные, если мы говорим об управлении потоком, стеком задач. Но это же работает и для любой структурной единицы предприятия.

 

Раз уж мы упомянули «черную коробку», черный цвет – это не цвет траура, это цвет памяти, мемориала.

В черную коробку мы помещаем задачи, над которыми мы, может, даже не пытались работать, но мы их записали и работать над ними больше не планируем, по какой-либо причине. Это мемориальное кладбище. А зачем оно нужно?

Опять же, пример из личной практики: обращается ко мне заказчик с какой-то потребностью, хочет привлечь меня как подрядчика.

Я соглашаюсь и даже пишу под эту задачу технический проект – он сначала попадает в синюю коробку, потом в красную, потому что я не получаю ответа, потом в оранжевую, потому что я получаю какую-то невнятную реакцию. А потом мне уже первое лицо отвечает, что они передумали, не будут работать.

Выбросить мне эту задачу вообще, стереть всю информацию? Нет:

• во-первых, работа была проведена, уже есть некоторые артефакты;

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

Если бы я этого не записал, через год я бы и не вспомнил о том, что мы уже общались. А посмотрев свои конкретные архивы, я увижу: «О, ребят, с вами лучше не работать, вы в черном списке». Либо работать, но давайте по-другому договариваться.

Это мемориал для памяти.

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

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

И дальше на базе этого можно сделать, возможно, еще что-то. Мы это не выбрасываем, мы помним.

А иногда оно обратно возвращается в работу, поэтому мы ведем архив. Это тоже бэклог, но это его прям самое дно. Это скорее даже ниже дна – это не совсем бэклог и не технический долг, это задачи, которые были, но остановились. Потом они могут запуститься.

Это бэклог с самым нижним приоритетом: «Скорее всего, нет, но вдруг да».

Эту информацию мы не выбрасываем, поэтому у нас есть черная коробка.

Алгоритм действий – проще не бывает: ничего с этим не делать, работаем по триггеру. Надо будет – вытащим, а так – положили да забыли. Но в подсознании помним и иногда просматриваем, как старые фотографии, чтобы освежить в памяти то, что было.

 

Последний цвет – белый.

На самом деле, он прозрачный, но изобразить прозрачный цвет в таблице, в диаграмме или в презентации довольно сложно, поэтому мы его сделали белым.

Здесь все вообще просто – это короткие операционные задачи длиной не более рабочего дня.

Почему для них отдельная коробка? Есть такой принцип, он называется «принцип брошенного щенка». Он правда страшный, поэтому никогда так не делаете, коллеги, никогда. Он гласит: если выбросить щенка на улицу, и он выживет и вырастет, он превратится в огромного пса, который вас за очередным углом подстережет и съест.

Здесь ровно то же самое – если мы будем выбрасывать короткие операционные задачи на потом, они скапливаются, их становится все больше-больше-больше, и получается то, что называется техническим долгом.

А по долгам приходится платить, и рано или поздно приходят те, кто этот долг взымает тем или иным способом. И мы оказываемся в ситуации, когда скопившиеся несделанные мелочи не дают мне запустить критично важную задачу – они уже переместились из белой коробки то ли в красную, то ли в оранжевую, там уже горит.

Это могут быть задачи:

• ответить на вроде бы неважное письмо;

• проверить вроде бы некритичную ошибку;

• сделать какое-то крохотное ревью;

• посмотреть апдейт по очередному релизу – это занимает 15 минут, даже с учетом конспектирования. Четверть часа, и ты уже более-менее понимаешь, что в новом релизе изменилось, чего ожидать, и что делать в твоих текущих производственных задачах, чтобы новый релиз вписался в наш проект или проекты.

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

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

Лично в моем рабочем графике я всегда последний час рабочего дня отводил на разбор этой самой белой прозрачной коробки. Это самое непродуктивное время, когда соображалка уже не работает, продуктивность упала почти до нуля, но простые моторные какие-то функции – ответить на неважное письмо и т.д. – ты выполнять еще вполне можешь.

Белая коробка всегда должна оставаться пустой, иначе мы нарабатываем технический долг, на него нарастают проценты, а дальше вы понимаете, что происходит с нашим рабочим графиком, нашим временем.

 

Варианты применения методики

 

Теперь, когда мы разобрали все цвета по очереди, наверняка возникнет вопрос: как все это вести, фиксировать – есть ли какие-то рекомендации или инструменты, готовые или неготовые.

Здесь я могу сказать только одно – в нашем инженерном деле каждый выбирает инструмент себе по руке. Любая инженерно-организационная (она же инженерно-управленческая) методика должна быть разработана и реализована так, чтобы быть инвариантной к инструментарию.

Работать по этой методике с задачами можно:

• банально в блокноте или ежедневнике цветными карандашами;

• в телефоне;

• в каком-то софте – кому что удобнее, тот этим и пользуется, здесь рекомендаций нет;

• я всегда пользовался банальными иерархическими списками – для структурирования информации, по-моему, ничего лучшего пока что не изобрели. Это до сих пор вполне актуальный инструмент, хотя есть и другие.

Важный момент: задачи коробки вовсе не обязаны храниться в каком-то одном месте – хранилище может быть распределено по нескольким местам хранения.

Например, работа с задачами той самой белой или прозрачной коробкой распределена по нескольким пространствам:

• Для почты мне удобно применять пустые черновики ответов на письма. Когда приходит письмо, на которое нужно ответить, я, вместо того чтобы ставить какие-то теги, перемещать в какие-то папки, нажимаю кнопку: «Ответить всем», а потом «Сохранить как черновик». И в конце дня я просматриваю папку «Черновики» и пишу ответы.

• Что-то из ежедневных задач я отражаю в моем Workflowy – это замечательный инструмент, правда сейчас в наши недружелюбные времена он работает не очень хорошо, там есть сложности с оплатой из России, но инструмент очень хороший.

• Что-то я отражаю в заметках, и так далее.

По инструментарию всё уже индивидуально – кому что удобнее.

 

Чтобы выполнять максимальное количество задач за ограниченное количество времени – не забывайте о своей позиции внутри задачи

 

Любая инженерно-управленческая методика не должна быть какой-то догмой. Это не учебник высшей математики, где написано, как решать дифференциальные уравнения. Нет, это идея.

Любая методика декомпозируется на три составляющие:

• Концепция. Концепция методики заключается ровно в том, что у нас есть два ключа: «задача» и «коробка». Задачи кладутся в коробки, причем они могут перекладываться между коробками: из красной в оранжевую, из синей в красную, из красной в зеленую и т.д. Два ключа – это концепция методики, и ее менять нельзя. Это основание.

• Теоретическая часть – это какие цвета у коробок, какие алгоритмы. Это уже не догма: в каких-то областях деятельности этих коробок может быть больше, в каких-то – меньше; цвета могут быть другими, алгоритмы другими; это вообще могут быть не коробки – контейнеры, чайники, еще что-то. Это можно представить как матрешку – тут разные варианты. Но сама идея, что задачи нижнего уровня декомпозиции раскладываются по местам хранения, маркированные своим цветом, и цвет означает алгоритм действий, а не просто покрашен – это мы не меняем. А все остальное – не догма, это все подстраивается под конкретную деятельность. У разных компаний, у разных команд, у разных специалистов, у разных индивидов это может быть по-разному. Коробок может быть семь или пять, но лучше больше семи не делать, потому что тогда начинается путаница. Семь – это не священное число, это просто число, за пределами которого в сознании начинается путаница. Если что-то тяжело запомнить, мы тратим время неэффективно. А наша задача – утилизировать наше рабочее время с максимальной эффективностью и максимальным результатом по нашим производственным задачам,

• И, наконец, практика – это инструментарий, как это делать. Здесь полная свобода действий. Главное – не забыть описать свой личный алгоритм действий по работе с этой методикой и положить его в то место, где мы храним личные рабочие регламенты.

Понятие позиционности – это наверное все-таки третий ключ и к методике, и к тому феномену, когда люди, которые, казалось бы, ничего не успевают, на самом деле успевают все.

Для успешного выполнения задач важно иметь понимание своей позиции внутри задачи: слабой позиции, сильной позиции, управляющей позиции, блокирующей позиции.

Небольшой пример: красная коробка – это когда есть потенциально аварийная задача, которую кто-то ее блокирует, а наша позиция – наблюдатель. А зеленая коробка – наоборот, когда по задаче все сделано, а мы ее блокируем.

Если мы ведем проектную коммуникацию, то:

• на нашей стороне эта задача в зеленой коробке – мы дадим «зеленый свет», когда захотим и сочтем нужным, оптимальным, эффективным, правильным;

• а на той стороне это в красной коробке – потенциальная авария, ничего не происходит, нас блокируют.

Тут нет хорошего и плохого. В инженерном деле вообще хорошо и плохо – это ни о чем, мы не работаем с такими категориями.

Здесь важно:

• понимать свою позицию внутри задачи;

• согласно этой позиции определить задачу в правильную коробку;

• вовремя перемещать задачу из одной коробки в другую;

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

Так мы побеждаем любые проблемы на наших проектах и в наших производственных задачах. А то, что где-то красное, а где-то зеленое – это не хорошо и не плохо, это просто означает: здесь «стой подожди», а здесь «подожди переключись», не более чем.

 

************

Видео доклада