Новые принципы делового общения

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

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

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

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

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

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

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