Я работал с парнем по имени Рао. Рао родом из южного штата Индии Andhra Pradesh, но он жил в США и работал вместе с нами. Рао мог написать любой код, о чем бы вы его ни попросили. Если вам было нужно низкоуровневое системное программирование - это к нему, если высокоуровневое прикладное, он мог сделать почти что угодно.
Однако, что делало Рао по-настоящему удивительным, так это то, что он делал это до того как вы его попросили. У него была эта сверхестественная способность предсказать то, что вы собирались попросить его сделать, еще до того как вы об этом подумали. Это было сродни магии. Мне кажется, я даже обвинил его однажды в обмане, но не было никакой возможности обмана. Я бы сказал: "Рао, я думал о смене способа инкапсуляции контроллера на нашем фреймворке приложений[1] . Если мы изменим его немного, то можно будет его использовать не только для веб-приложений. Что думаешь?". "Я сделал это на прошлой неделе", - ответил бы он - "Это есть в системе управления версиями. Посмотри." С Рао постоянно так было. Настолько часто, что единственный способ, чтобы все это было совпадением, как если бы Рао делал все что можно представить с каждым участком кода, над которым работала наша команда.
В то время я возглавлял команду архитектуры приложений [2]. Среди прочего, мы разрабатывали и сопровождали фреймворки для использования в приложениях компании. Мои коллеги проводили много времени, обсуждая, как мы хотим видеть разработку ПО для улучшения компании. Мы также обсуждали роль ключевых инфраструктурных компонентов в этих улучшениях.
Вот где оказывались полезными фокусы Рао. Он не говорил много во время этих бесед, но и не отключался от них. Он слушал внимательно. И, раскрывая секрет, чего не делает ни один фокусник, он позднее рассказал мне, что он делал только то, о чем я уже сказал, что хочу это сделать. Просто я говорил об этом настолько тонко, что даже я не представлял, что сказал это. Мы могли ждать пока сварится кофе, и я мог рассказывать как здорово было бы если бы наш код имел дополнительную гибкость. Если я говорил об этом достаточно часто или произносил достаточно убедительно, даже если я не включал это в список дел, Рао мог заполнить перерывы в "настоящей работе", в поиске возможности внедрения одной из этих вещей. Если это было легко (и дешево) он мог сделать это на скорую руку и проверить.
Предвидение имеет отношение не только к вашим менеджерам, но также и к заказчикам. Если они дают вам правильные намеки, вы можете добавить ту функциональность, о которой они либо собирались попросить вас, либо могли бы, если бы представляли, что это возможно. Если вы всегда делаете то, о чем просят заказчики, то они просто удовлетворены. Однако, если вы делаете больше, чем они просят, или уже сделали что-то заранее, вы поразите их - это в том случае, пока ваша способность к телепатии правильна.
Этот фокус с чтением мыслей не совсем безопасен. Это как натянутый канат, по которому вы избегаете ходить без страховочной сетки. Основные риски (с предполагаемыми смягчениями) следующие:
-
вы тратите средства компании, делая работу, о которой вас никто не просил. Что, если вы ошибаетесь? Начните с малого. Делайте только предположения о заполнении пауз в вашей текущей работе, так что влияние изменений минимально. Если хотите, делайте это в свободное от работы время.
-
каждый раз как вы добавляете код в систему, существует очень большой шанс того, что код станет менее гибким для изменений. Избегайте предположений, если это может привести к снижению или пределу того, что система может выполнять[3]. Когда влияние изменений достаточно велико, нужны бизнес решения. И в этом случае редко только разработчики влияют на решение.
-
вы можете изменить функциональность системы, о чем просили вас заказчики, таким образом, что решение неожиданно для вас станет менее полезным или желательным для заказчика. Остерегайтесь угадывания, особенно если дело касается пользовательских интерфейсов.
Управление людьми и проектами - сложная работа. Люди, которые могут двигать проект в правильном направлении, без указки высоко ценятся их часто перегруженными работой менеджерами и заказчиками. Штука с чтением мыслей, если она сделана правильно, заставляет людей полагаться на вас - замечательный рецепт для развития карьеры. Этот навык стоит изучения и развития.
Действуйте!
-
Ранний рецензент этой книги Карл Брофи (Karl Brophey) предлагает для вашего следующего проекта или системы, которую вы разрабатываете, начать делать записи о том, что вы думаете, о чем хотят попросить менеджеры или заказчики. Будьте креативными. Попытайтесь посмотреть на систему с их точки зрения. После составления списка не-таких-уж-очевидных функций, подумайте о том как наиболее эффективно внедрить каждую.
-
Когда вы попали в проект или задачу по улучшению системы, следите за успехами. Как много ваших догадок действительно попросили разработать? Когда ваши функции были внедрены, была у вас возможность использовать эти идеи при мозговом штурме?[4]
[1] I would say, "Rao, I've been thinking about changing the way we're encapsulating the controller on our application framework"
[2] At the time, I was leading my company's application architecture team.
[3] Avoid mind-reading work that may force the system down a particular architectural path or limit what the system can do in some way.
[4] When your guessed features did come up, were you able to use the ideas you came up with in your brainstroming sessions?