Роберт Мартин - Идеальный программист. Как стать профессионалом разработки ПО

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

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

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

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

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

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

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

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

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

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

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

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

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

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