Как не отвлекаться на раздражители

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

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

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

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

Как справиться с этой задачей? Лучше всего еженедельно назначать всем программистам перечни задач, аннотируя их приоритетами и сроками завершения. Поскольку цикл разработки всегда отличается непостоянством, перечни эти могут меняться каждую неделю, а иногда – даже каждый день. Ответственность за составление и корректировку этих списков ложится, опять же, на вас^[33]. Вы себе не представляете, сколько менеджеров считают программистов чуть ли не телепатами и пребывают в уверенности, что график работы они составляют с помощью интуиции. Таких убеждений придерживаются даже некоторые директора. Подобный подход регулярно приводит к тому, что вместо работы во имя пользователей программисты трудятся для программистов, а руководители обнаруживают свою бесполезность в контексте упрочения позиций компании.

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

Скорее всего, вам не удастся сильно продвинуться в вопросах физического размещения программистов, но все-таки при любой возможности требуйте, чтобы каждый сотрудник вместо отгороженной кабины имел отдельное помещение. Если руководство вашей компании больше думает не о продуктивности, а об арендной плате, у вас мало шансов – и, тем не менее, гните свою линию. Один из наиболее заметных раздражителей в деятельности программистов создают инженеры-технологи компаний с их квадратно-гнездовым мышлением. Фильм «Office Space», в котором, так сказать, «в естественном виде» изображены программисты в своих кубышках, должен стать обязательным для просмотра вредителями, планирующими офисное пространство. Факторы, влияющие на «отупение» сотрудников, на примере 32 346 компаний изучили Том Димарко (Tom DeMarco) и Тимоти Листер (Timothy Lister). На составленной ими диаграмме видна четкая обратная зависимость между степенью отупения сотрудников и объемом выделяемого каждому из них офисного пространства^[34]. О чем это говорит? О том, что шум, отвлекающие факторы и все прочие побочные эффекты политики снижения затрат серьезно снижают продуктивность работы.

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

Когда проект разрастается

Я имею в виду классическое понятие разрастания проекта. Если аналитик бизнес-требований утверждает, что занимается уточнением рамок, знайте: он их раздвигает. Не важно, как этот процесс называть. Факт тот, что специфицировать и сконструировать программу, избежав разрастания требований, не удавалось еще никому. Объясняется это натурой человека – невозможно с первой попытки сформулировать все функции, которые предполагаемой программе предстоит выполнять.

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

1. Замысел. У кого-то появляется блестящая идея.

2. Специфицирование. Куча людей пытаются описать эту идею.

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

4. Конструирование. Бессонными ночами и нескончаемыми днями программисты программируют.

5. Тестирование. Обнаруживается, что конечная реализация блестящей идеи не так хороша, как хотелось бы, или, еще хуже, что идея-то отнюдь не блестящая.

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

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

В своей немного устаревшей, но, тем не менее, сохраняющей значимость книге под названием «Managing the Software Process» Уотс Хамфри (Watts Humphrey) сформулировал принцип, актуальный по сей день:

«Когда программисты берутся за оценку объема кода реализации какой-либо функции, результаты неизменно оказываются заниженными. Этому есть множество возможных объяснений. В этом контексте следует понимать, что их оптимизм есть относительно прогнозируемая функция состояния проекта»^[35].

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

• любой процесс продлится дольше, чем вы надеетесь;

• всегда появляется что-то, о чем вы не подумали.

Вооружившись этими аксиомами и введенным Хэмфри понятием «состояния проекта», старайтесь контролировать разрастание и обязательно убедите ваших подчиненных в том, что вы человек проницательный, поскольку предсказывали такую возможность и учли ее в процессе тщательного планирования. «Тщательное планирование»! Звучит замечательно, но что же это означает в контексте выпаса котов? А вот что. Вернитесь к главам 1 и 2, еще раз пробегитесь по изложенным в них принципам и попытайтесь сделать их неотъемлемыми элементами своего характера. Помните, что лидерство происходит от сердца, а не от ума^[36].

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

Таблица 3.3. Нереалистичный план проекта

Руководствуясь таким планом, вы рискуете нарваться на кучу неприятностей. Будучи глубоко убеждены, что конечная дата сдачи проекта будет равняться сумме временных интервалов A + B + C + D + E + F, вы немало удивитесь, обнаружив, что это совершенно не так.

Рассмотрим более реалистичный план, показанный в табл. 3.4.

Таблица 3.4. Реалистичный план проекта

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

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