Кэл Ньюпорт – Новые принципы делового общения (страница 33)

Другими словами, хороший производственный процесс должен предельно точно обрисовывать рабочую ситуацию и свести к минимуму беспорядочную коммуникацию, необходимую для завершения работы. Обратите внимание, все вышеизложенное не ограничивает независимость сотрудников и не диктует, как именно они должны выполнять свою работу. Основное внимание уделяется координации действий. Обратите также внимание на то, что рабочие процессы с подобными характеристиками не приведут к формированию жесткой бюрократической системы, поскольку направлены на то, чтобы сократить потребление ресурсов (в плане внимания и времени), с помощью которых производится ценный продукт. Сотрудники компании Optimize Enterprises, где рабочие процессы четко систематизированы, скорее всего, чувствуют себя более уверенно и меньше беспокоятся, чем те, кто попали в ловушку гиперактивного коллективного разума.

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

Некий руководитель — назовем его Алекс — управляет командой из 15 человек в рамках независимой недавно созданной компании, которая сотрудничает с ведущим в стране поставщиком услуг в области здравоохранения. Его сотрудники занимаются анализом данных. Допустим, вы исследователь и работаете с этой компанией. Вы выиграли грант и теперь должны произвести ряд сложных операций с данными. Команда Алекса снабдит вас необходимыми инструментами. Кроме того, его сотрудники разрабатывают проекты для внутреннего пользования, чтобы поставщик услуг в области здравоохранения мог работать более эффективно. А некоторые из предложенных решений даже становятся самостоятельными программными продуктами. Учитывая разнообразие задач, Алекс, как вы понимаете, должен регулировать посягательства на рабочее время своих сотрудников.

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

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

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

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

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

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

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

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

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