Чтение онлайн

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

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

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

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

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

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

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

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

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

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

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

Мой друг и коллега Джеймс Макмурри [13] на заре нашей с ним карьеры поделился разработанной им системой, которая гарантировала хороший результат работы. Система поразила меня своей глубиной, особенно если учесть небольшой опыт ее создателя (возможно, он учел уроки, полученные от родителей), и я пользуюсь ею до сих пор. Не уведомляя руководство, он фиксирует хиты дня. Его задача — каждый день делать нечто такое, о чем можно было бы с гордостью доложить наверх. Это может быть пришедшая ему в голову идея или некое действие, могущее улучшить работу его отдела (см. Одна неделя хитов).

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

Понедельник. — Автоматизировать сборку!

Вторник. — Написать тесты для синтаксического разбора кода.

Среда. — Разобраться с инструментами объектно-реляционного проецирования, чтобы можно было больше вообще не писать SQL-запросы.

Четверг. — Написать сценарий развертывания веб-приложения.

Пятница. — Избавить проект от предупреждений компилятора.

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