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

Джеймс Стэньер*, технический директор компании Shopify, уверен: улучшить ситуацию помогут небольшие изменения в подходах к задачам. В своей заметке он описывает некоторые модели поведения, которые на первый взгляд кажутся продуктивными, но фактически мешают рабочим процессам. Наряду с этим Джеймс описывает альтернативные варианты того, как можно справляться с задачами — гораздо более быстро и эффективно.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

Ошибка №1. Слишком много внимания к свободным ячейкам календаря

Это трагически распространенный сценарий. Вот в чем он заключается.

Допустим, вам нужно решить какой-то вопрос, и вы определяете список сотрудников, необходимых для достижения консенсуса. Представим, что это 7 человек из нескольких команд. Вы открываете календарь и находите свободный часовой слот, в рамках которого все они могут собраться для обсуждения проблемы. Правда, из-за плотного графика одного-двух коллег, слот удается назначить только через 9 дней. «Отлично», — думаете вы, — «мне удалось найти время, когда все нужные мне специалисты свободны!». Зная, насколько сложно бывает организовать встречу с этой группой людей, вы довольно улыбаетесь.

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

В течение следующих 9 дней ничего не происходит.

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

В то же время в альтернативной вселенной, возможно, произошло следующее.

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

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

Итак, в этой альтернативной реальности вы сэкономили целых 8 дней. И для этого потребовалось потратить всего 20 минут на составление письма.

Ошибка №2. Страх делиться несовершенным результатом

Рассмотрим другой сценарий.

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

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

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

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

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

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

Во время работы над прототипом вы поняли, что есть нескольких вариантов того, как данные могут быть предоставлены из вашей функции. И решили обратиться к командам, которые будут использовать эту функцию — ведь они ваш заказчик. Вы отправили им сообщение: «Есть ли у вас мысли по поводу того, как бы вы хотели получать данные из нашей функции? Я только начал исследовать этот вопрос». Один из инженеров ответил вам: «У нас уже есть внутренние библиотеки для этого, посмотрите» — и приложил ссылку на репозиторий GitHub и документацию.

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

Ошибка №3. Передача контроля над ситуацией в никуда

И прежде чем я закончу, ещё один пример.

Вы совершенствуете прототип, чтобы развернуть его в рабочей среде для первоначального тестирования с другими командами. Тратите несколько дней на написание документации, увеличение тестового покрытия и приведение в порядок некоторых фрагментов кода. Затем составляете подробный pull-request и отправляете его на рассмотрение. Вы видите, как CI создает запрос, запускает тесты, а затем ставит зеленую галочку — все готово. Довольный результатом, вы закрываете вкладку браузера.

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

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

В альтернативной вселенной, возможно, произошло следующее.

После отправки pull-request вы написали командам, которые собираются использовать ваш сервис, что теперь он доступен в рабочей среде. И поинтересовались, есть ли у них время опробовать его. «Конечно», — ответил один из инженеров. «Я сделаю это, вот только закончу с развертыванием». Спустя час и после череды комментариев, все было замерджено и развернуто.

Так ваше «я» из альтернативной вселенной сэкономило целых 3 дня, отправив всего одно сообщение.

Вместо выводов

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

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

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