Например, когда я общался с Алексом, на большой доске висела карточка, относящаяся к проекту одной из больниц поставщика медицинских услуг. Речь шла о хранении данных о генетических тестах, которые проводили на детях. На тот момент данные хранились на сервере FTP. Команду Алекса попросили переместить эти данные в другую, более удобную для работы базу данных. Он объяснил мне, как будет реализован этот проект: «Мы знаем об этом проекте. В настоящее время он представлен в виде карточки в колонке “В плане”. Заказ поступил после трех других серьезных запросов, которые мы сначала должны выполнить. Когда дойдет очередь до этого проекта, мы его обсудим и определим, какие конкретные задания будут созданы в системе Asana или Jira. Что касается большой доски, то карточка будет перемещена в колонку “В разработке”».

Обычно Алекс созывает рабочее совещание каждое утро. Но если его команда плотно занята работой над проектом, общие собрания какое-то время проводятся раз в неделю, пока не потребуются более частые встречи.

Вот уже в третий раз мы наблюдаем аналогичную картину: информация о запланированной интеллектуальной работе размещается на карточках, которые распределяются в разных колонках на доске. Команда Алекса использует как настоящую грифельную доску, так и ее виртуальные аналоги в системе Asana. Компания Optimize внедрила систему Flow. Девеш, о котором мы говорили в предыдущей главе , использует платформу Trello.

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

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

Подобный подход к организации работы зародился в сфере разработки программного обеспечения, которая в последние два десятилетия все больше внедряет так называемые гибкие техники управления в своей деятельности. Основные идеи, лежащие в основе этого подхода, впервые были сформулированы в манифесте, составленном в 2001 году группой из 17 программистов и руководителей проектов. Текст манифеста начинается с оптимистичной фразы: мы ищем лучшие способы разработки программной продукции. Затем простым языком излагаются 12 принципов. Один из них гласит: «Наш приоритет — оправдать ожидания клиентов, заблаговременно и непрерывно снабжая его полезным программным обеспечением». Вот еще один принцип: «Необходима простота, и искусство добиться этого заключается в том, чтобы максимально увеличить количество работы, которую делать не нужно» [136] .

Чтобы понять суть гибкой техники управления, вы должны осознать, чему она пришла на смену. Процесс разработки программного обеспечения шел в соответствии с перегруженным информацией сложным планом, который искренне пытался заранее предусмотреть тот объем работы, который необходимо будет сделать, чтобы написать большую часть программного кода. Идея заключалась в том, что если у вас есть такой план, обычно пестрящий разноцветными любовно вставленными полосками диаграмм Ганта, то вы сможете точно определить, сколько программистов вам понадобится на каждом из этапов, и огласите заказчику точные сроки выполнения работ. В теории такой подход казался хорошим, но на практике подобные планы никогда не совпадали с реальностью, за исключением, может быть, самых простых проектов. Создавать программное обеспечение — это не автомобили собирать. Сложно точно оценить, сколько по времени займет тот или иной этап и какие проблемы могут возникнуть. Кроме того, стало ясно, что заказчики сами не всегда заранее представляют, что именно им нужно. Так что по ходу работы в проект вносились изменения, и график сдачи работ сдвигался.

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

Ключевое значение имеет слово «разные». Концепция гибких техник управления сама по себе не является организационной системой. Она очерчивает общий подход, который реализуется благодаря различным и многочисленным специализированным системам. В настоящее время наиболее популярны Scrum и Kanban, и если вы хоть немного знакомы с миром разработки программного обеспечения, то вы по меньшей мере слышали о них. Если описать в двух словах, то Scrum разбивает работу на короткие отрезки — спринты. Команда, работающая над проектом, полностью посвящает свои усилия тому, чтобы завершить работу над определенной версией продукта, прежде чем переключаться на следующую задачу. Kanban, напротив, делает акцент на непрерывной работе с помощью фиксированных этапов. Цель такого подхода — минимизировать объем незавершенных работ на любом этапе, чтобы не возникало задержек.

Давайте вернемся к доскам. Если глубже погрузиться в изучение этих двух подходов, вы заметите нечто общее между Scrum и Kanban. Они оба используют доски задач, где карточки с написанными задачами располагаются вертикально в колонках, каждая из которых представляет собой этап разработки программного обеспечения. Например, в системе Scrum часто есть колонка под названием «Незавершенные задачи». Туда помещаются те вопросы, которые сочтены важными, но пока не решены. Есть также колонка, куда помещаются задачи, над которыми в данное время трудится команда программистов, участвующих в спринте, колонка для завершенных продуктов, проходящих тестирование, а также колонка для готовых программ, которые уже протестированы и готовы к запуску на рынок.