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

Две истины о встречах:

1) встречи необходимы;

2) встречи часто оказываются бесплодной тратой времени.

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

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

 

Отказ от участия

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

Иногда встреча посвящена теме, которая представляет для вас интерес, но не является строго необходимой. Решайте сами, сможете ли вы выделить для нее время. Будьте осторожны – такие встречи способны поглотить все ваше рабочее время.

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

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

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

 

Уход со встречи

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

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

Разумеется, не нужно в гневе выбегать из помещения с восклицанием: «Какая скука!» Не нужно проявлять неуважение. Просто спросите в подходящий момент, насколько необходимо ваше присутствие. Объясните, что вы не можете выделить больше времени, и спросите, нельзя ли ускорить обсуждение или изменить повестку дня. Важно понять, что оставаться на встрече, расходующей ваше время, в ход которой вы не можете внести сколько-нибудь значительного вклада, было бы непрофессионально. Вы обязаны разумно тратить время и деньги своего работодателя, поэтому в выборе подходящего момента для обсуждения вашего ухода нет ничего зазорного.

 

Повестка дня и цель

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

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

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

 

Пятиминутка

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

1. Что я сделал вчера?

2. Что я буду делать сегодня?

3. Какие сложности мне предстоит решить?

Вот и все. Ответ на каждый вопрос должен занимать не более 20 секунд, так что на каждого участника уйдет не более минуты. Даже в группе из 10 человек встреча будет закончена за 10 минут.

 

Встречи планирования итераций

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

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

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

У меня есть простое эмпирическое правило: встреча не должна занимать более 5 % общего времени итерации. Таким образом, для недельной итерации (40 часов) встреча должна завершаться в пределах двух часов.

 

Ретроспективные встречи по итерациям и демонстрации

Эти встречи проводятся в конце каждой итерации. Участники группы обсуждают, что прошло хорошо, а что плохо. Ключевые участники видят демонстрацию новых возможностей. При неправильной организации эти встречи могут занимать очень много времени; планируйте их за 45 минут до завершения последнего дня итерации. Выделяйте не более 20 минут на ретроспективу и 25 минут на демонстрацию. Не забудьте, что прошли всего одна-две недели, так что материала для обсуждения не так уж много.

 

Споры и разногласия

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

Технические разногласия порой заходят за край. У каждой стороны имеются всевозможные обоснования своей позиции, которые редко подкрепляются данными. Без данных любой спор, который не приходит к согласию за несколько минут (от 5 до 30), попросту не способен прийти к согласию. Единственное, что можно сделать в такой ситуации, – это раздобыть данные.

Некоторые люди пытаются выиграть в споре за счет демонстрации характера. Они кричат, пытаются давить или изображают снисходительность. Это не важно; сила воли не может разрешить спор на продолжительное время. Данные – могут.

Другие занимают пассивно-агрессивную позицию. Они соглашаются просто для того, чтобы закончить спор, а затем саботируют результат, отказываясь участвовать в решении. Они говорят себе: «Вы так хотели, вот теперь сами и разбирайтесь». Вероятно, это худший из вариантов непрофессионального поведения. Никогда, никогда не поступайте подобным образом. Если вы соглашаетесь, то вы обязаны участвовать.

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

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

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

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

 

Простите, если этот раздел отдает то ли метафизикой «эпохи Водолея», то ли ролевой системой «Dungeons & Dragons». Просто я отношусь к этому вопросу именно так.

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

Я не знаю, что такое «мана концентрации», но мне кажется, что это некая физическая субстанция (а может быть, ее отсутствие), влияющая на внимательность и восприимчивость. Чем бы она ни была, вы чувствуете, когда она есть, и чувствуете, когда ее нет. Профессиональные разработчики учатся управлять своим временем так, чтобы в полной мере использовать свою ману концентрации. Мы пишем код, когда резерв маны высок, а когда ее остается мало – занимаемся другими, менее творческими делами.

Кроме того, мана концентрации – недолговечный ресурс. Если не использовать ее, пока она есть, то, скорее всего, вы ее потеряете. Это одна из причин, по которым встречи часто приводят к таким значительным затратам. Если вы потратите всю ману концентрации на встрече, то у вас останется меньше ресурсов для программирования.

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

 

Сон

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

 

Кофеин

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

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

 

Перезарядка

Мана концентрации частично перезаряжается отвлекающими занятиями. Хорошая долгая прогулка, беседа с друзьями, просто взгляд из окна – все это поможет восстановить резерв маны.

Одни люди медитируют. Другие выбирают восстановительный сон. Третьи слушают подкасты или листают журналы.

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

 

Физические упражнения

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

Моей любимой формой физической концентрации является велоспорт. Я езжу на велосипеде час или два, иногда на 20–30 километров. Мой маршрут пролегает по тропе, параллельной реке Дес-Плейнс, так что мне не приходится иметь дело с машинами.

Во время поездок я слушаю подкасты об астрономии и политике. Иногда я просто ставлю свою любимую музыку, а иногда снимаю наушники и слушаю природу.

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

 

Ввод и вывод

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

 

Помидоры и распределение времени

Для управления своим временем и концентрацией я также использую чрезвычайно эффективный помидорный метод планирования. Основная идея очень проста: вы ставите стандартный кухонный таймер (традиционно такие таймеры оформляются в виде помидора) на 25 минут. Во время работы таймера ничто не должно мешать вашей работе. Если звонит телефон, вы отвечаете и вежливо просите перезвонить через 25 минут. Если кто-то заходит к вам, чтобы задать вопрос, вы вежливо предлагаете зайти через 25 минут. Независимо от вида прерывания оно откладывается до момента срабатывания таймера. Вряд ли найдется так уж много неотложных дел, которые не могут подождать 25 минут!

По сигналу таймера-«помидора» вы немедленно прекращаете свою текущую работу. Пришло время разобраться со всеми проблемами, возникавшими во время работы таймера. Затем вы делаете перерыв примерно на пять минут, снова ставите таймер на 25 минут и начинаете следующий «помидорный» период. Каждый четвертый период отдыха делается более продолжительным, 30 минут или около того.

Этот метод управления временем описан достаточно подробно; я рекомендую познакомиться с ним подробнее. Тем не менее даже это краткое описание дает начальное представление об этой методике.

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

Сколько «помидоров» можно сделать за день? В хорошие дни – 12 и даже 14. В плохие может выйти 2 или 3. Если подсчитать «помидоры» и построить график, вы быстро получите представление о том, какая часть рабочего времени расходуется продуктивно, а какая тратится на «всякую всячину».

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

 

Иногда у вас попросту «сердце не лежит» к работе. Например, порученная задача вас пугает, кажется неудобной или скучной. А может, вы думаете, что она приведет к конфликтам или неминуемо загонит в сложную ситуацию? Или вам просто не хочется ее выполнять?

 

Инверсия приоритетов

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

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

Конечно, такое поведение непрофессионально. Профессионал оценивает приоритет каждой задачи независимо от своих личных страхов и предпочтений и решает эти задачи в порядке приоритетов.

 

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

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

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

 

Грязь, болота и трясины

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

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

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

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

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

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

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