Практически для любого незапланированная работа убивает несколько часов запланированной продуктивности. Для творческих работников, вроде тех, кто пишет программное обеспечение, это убивает дни.
Некоторое время назад на работе потенциальный клиент сказал нам, что если мы сможем анализировать их данные определенным образом, то они будут заинтересованы в ведении бизнеса с нами. У нас есть команда, которая обрабатывает специальные аналитические запросы, но в данный момент у этой команды не было возможности взяться за эту работу. Они просили помощи, и вот как я вмешался.
На протяжении своей карьеры я много занимался аналитикой, ориентированной на клиентов, и мне это не особенно нравится. Когда единственное определение «готово» - это «заказчик сказал, что он удовлетворен анализом», вы знаете, что масштаб вашего проекта будет постоянно расширяться, пока заказчик не решит обратить внимание на что-то еще. Несмотря на то, что я знал об этом, когда я стал участвовать, я заставил менеджеров проектов согласиться с очень конкретными критериями приемки: я делал X, Y и Z, а когда X, Y и Z были выполнены, мое участие было завершено.
Я знаю, что мое определение объема не имеет значения, но я почувствовал себя лучше после того, как приложил усилия. Я сделал X, Y и Z, и все сказали, что счастливы. Я ничего не слышал в течение пары недель, поэтому продолжил свою обычную работу, лишь изредка слыша голос моего прошлого опыта, изредка говорящий мне, что это всего лишь вопрос времени. Внезапно я получил электронное письмо с новыми запросами от клиента. Я согласился на X, Y и Z, но теперь они хотели A, B и C. Как всегда бывает с проектами такого типа, моя первоначальная оценка вообще ничего не значила - я не закончу, пока заказчик не скажет так.
Я очень ожидал, что прицел будет постоянно расширяться, поэтому меня это не сильно расстраивало. Что сводило меня с ума, так это моя абсолютная неспособность планировать работу. Моя команда работает по расписанию спринтов, и эти незапланированные запросы несколько раз прерывали мою запланированную работу в течение нескольких спринтов. Все мои обычные обязательства продвигались все дальше и дальше по календарю, потому что, когда один ресурс должен обрабатывать как разработку продукта, так и конечные результаты, ориентированные на клиентов, результаты, ориентированные на клиентов, всегда побеждают.
Этот опыт заставил меня задуматься о том, почему я так сильно отношусь к незапланированной работе. Большинство менеджеров и руководителей, с которыми я разговаривал по этому поводу, придерживались такой позиции: «мы платим за ваше время, поэтому мы можем решать, что заполняет это время, но и когда мы захотим». Я думаю, что это правда, но я также думаю, что отказ от плановой работы внеплановой работой плохо для бизнеса - иногда настолько плохо, что я видел, как это заставляет целые отделы останавливаться.
Первая причина, по которой я ненавидел незапланированную работу, - это то, о чем я видел, как многие другие люди упоминают:
Когда вы работаете над чем-то творческим, например над написанием кода, вы испытываете разные уровни продуктивности. Самые продуктивные уровни - это то, что некоторые люди называют «пребыванием в зоне». Вы не можете просто перейти в нужную зону, когда захотите - вам придется какое-то время работать менее продуктивно, пока вы не привыкнете делать определенные вещи автоматически, после чего вы сможете начать работать более продуктивно. Это похоже на то, как работает сон:
Вы не просто погружаетесь из бодрствования в глубокий сон. Вам предстоит пройти через разные этапы. Если кто-то будит вас неоднократно с непредсказуемыми интервалами, вам потребуется время, чтобы снова заснуть, и даже в этом случае вы не получите полной пользы от того, что вы спите. Точно так же, если кто-то постоянно прерывает вашу обычную работу, чтобы привлечь вас к чрезвычайным проектам, ваша обычная работа откладывается не только на время, которое потребовалось для выполнения побочного проекта. Дело не в том, что количество времени в день или неделю, не потраченное на чрезвычайный проект, не является достаточным, если взять его в целом, для того, чтобы уместиться в деятельности, которая завершила бы вашу обычную работу. Дело в том, что перерывы не дают вам попасть в достаточно продуктивную зону, чтобы действительно добиться стабильного прогресса.
Как только я получил электронное письмо с новым вопросом, я переставал продуктивно работать над тем, над чем я работал, даже если новый запрос не приходил на следующий день или даже неделю. Зная, что у меня теперь новый крайний срок, который я не планировал, я вынужден был жонглировать своими приоритетами, чтобы убедиться, что я смогу уложиться в этот крайний срок, который вытащил меня из продуктивности, которую я испытывал до того, как получил запрос. После того, как я перенес все, у меня иногда было время вернуться к своей обычной работе, прежде чем перейти к работе над новым запросом, но к тому времени новый запрос уже потратил несколько часов, заставляя меня медленно продвигаться обратно в продуктивную зону.
С учетом всего сказанного, по мере того как я размышлял об этом больше, я понял, что вытеснение из моей производственной зоны не было основной причиной, по которой я был разочарован незапланированной работой.
Наука о данных, как и многие другие профессии программиста, в значительной степени является дизайнерской работой. Проектная работа требует, чтобы много вещей было у вас в голове, а затем вы периодически переносите их части в код, документацию, диаграммы, политику или другие формы обеспечения. Другими словами, это творческое упражнение. После того, как у вас есть экземпляры частей, вам больше не нужно хранить их в памяти, но вы должны помнить, откуда они взялись - все части проблемы, которые касались тем, которые были помещены в документы, но не сами попадают в эти документы.
Человеческий мозг не может запомнить все, поэтому он регулярно объединяет воспоминания, чтобы хранить только информацию о вещах, которые были достаточно полезными или достаточно дорогостоящими, чтобы эта информация могла быть полезна для нас в будущем. Пока мы спим, наш мозг просматривает наши недавние воспоминания и редактирует информацию, не связанную с затратами или вознаграждением. (Вы можете найти техническое обсуждение здесь и нетехническое обсуждение здесь).
В этом проблема прерванных проектных работ. В любой момент действительно важная информация - информация, связанная с затратами или вознаграждением - уже выгружена в документы. Все остальное - это то, о чем мы еще не определились (другими словами, наш код содержит только те методы, которые, как мы знаем, нам понадобятся, а не методы, о которых мы еще не знали). Таким образом, большая часть информации, еще не задокументированной в то время, когда нас прерывает незапланированная работа, - это информация, которую наш мозг отредактирует в течение нескольких ночей сна.
Я думаю об этом так: новый проект подобен чистому листу бумаги. Каждый раз, когда я пишу код или документацию, я вырезаю из бумаги фигуру, маркирую ее и откладываю в сторону. Это позволяет мне быстро ссылаться на все части, которые я вырезал, поэтому, если мне нужно сложить части в другом порядке или расположить их все определенным образом, все, что мне нужно сделать, это посмотреть на формы и метки, и я может понять, что куда идет.
Иначе обстоит дело с остальной частью этого листа бумаги - частями, которые я не вырезал. Может быть, я тут и там сделал несколько заметок или сделал несколько надрезов, не вырезая полностью новую форму. До тех пор, пока я каждый день возвращаюсь к этой статье и напоминаю себе о том, что я уже сделал и что, по моему мнению, я мог бы сделать дальше, я могу по большей части опережать консолидацию ночной памяти моего мозга. Но если вдруг мне придется полностью перестать думать о бумаге, потому что мне придется неожиданно перейти к другому проекту, мой мозг по сути берет те части бумаги, которые остались неразрезанными, и скомкает их в маленький шарик.
Когда моя незапланированная работа заканчивается и я возвращаюсь к тому, над чем работал до прерывания, я не могу размять эту бумагу. Мне нужно либо вырезать фигуры из скомканного шарика, либо вытащить новый лист бумаги. Если я пытаюсь обойтись консолидированными воспоминаниями, которые оставил мне мой мозг, я в конечном итоге конструирую не для проблемы, как она есть на самом деле, а для проблемы, которая существует после прохождения через фильтры моего мозга. Если я откажусь от использования остатков своего мозга и попытаюсь создать дизайн из цельного материала, мне придется вытащить все элементы, которые я уже разработал, чтобы убедиться, что я не придумываю явно повторяющиеся или противоречивые решения. В любом случае, мне приходится тратить огромное количество времени (дни или даже недели по сравнению с часами, которые я потратил на то, чтобы выйти из своей зоны продуктивности), чтобы заново изучить масштаб и форму проблемы.
Я должен признать, что иногда консолидация памяти работает мне на пользу. Я уже писал о преимуществах ухода от проблемы, чтобы позволить моему мозгу консолидировать свои воспоминания и, если мне повезет, дать мне более четкое представление о том, что мне действительно нужно делать. Но то, что консолидация памяти иногда бывает хорошей, не означает, что она хороша в любой момент времени. Если я боролся с проблемой в течение нескольких месяцев и не могу найти удовлетворительного решения, то, вероятно, лучше уйти. Но если я вынужден отступать через неожиданные промежутки времени и каждый раз на непредвиденный срок, чтобы приспособиться к последней чрезвычайной ситуации в офисе, нет причин ожидать, что мой мозг будет достаточно полон информации о моем проекте, чтобы консолидировать эта информация будет вообще полезной.
Практически для любого человека незапланированная работа убивает несколько часов запланированной деятельности каждый раз, когда она происходит. Для творческих работников, таких как специалисты по обработке данных и инженеры, это убивает дни. Даже «быстрый вопрос» требует огромных затрат с точки зрения производительности и упущенных возможностей. Команды, которые осознают это и соответствующим образом структурируют свои приоритеты, делают больше.
