Читаем Как пасти котов. Наставление для программистов, руководящих другими программистами полностью

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

Гении бывают самые разные. Я не намерен воспроизводить характеристики всех подтипов (слишком их много); скажу лишь, что всем гениям свойственно одно и то же качество – исключительная способность к концентрации. Основной акцент они обычно делают на технологии, отодвигая кадры на второй план. Именно это обстоятельство мешает им стать полноценными лидерами. Спору нет, руководитель обязан обращать внимание на вопросы технологии, но основным приоритетом в его деятельности должны быть люди, которые работают с технологией. Код не возникает сам по себе. Его создание есть результат умственной работы программистов, стимулируемых интеллектуальной тиранией руководителей.

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

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

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

Гении рассматривают администрирование как работу «для других», недостойную их внимания.

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

Таблица 7.2. Как мыслит гений (Г) и лидер (Л)

Г: Какая методика разработки программного обеспечения может помочь решить данную проблему?

Л: Как мне привлечь других сотрудников к формулированию методик решения проблем?

Г: Сколько еще языковых средств мне удастся изучить в этом месяце?

Л: Какую образовательную подготовку стоит пройти моим сотрудникам, чтобы они смогли повысить показатели продуктивности?

Г: Сложность является препятствием только для невежд

Перейти на страницу:

Похожие книги

Основы программирования в Linux
Основы программирования в Linux

В четвертом издании популярного руководства даны основы программирования в операционной системе Linux. Рассмотрены: использование библиотек C/C++ и стан­дартных средств разработки, организация системных вызовов, файловый ввод/вывод, взаимодействие процессов, программирование средствами командной оболочки, создание графических пользовательских интерфейсов с помощью инструментальных средств GTK+ или Qt, применение сокетов и др. Описана компиляция программ, их компоновка c библиотеками и работа с терминальным вводом/выводом. Даны приемы написания приложений в средах GNOME® и KDE®, хранения данных с использованием СУБД MySQL® и отладки программ. Книга хорошо структурирована, что делает обучение легким и быстрым. Для начинающих Linux-программистов

Нейл Мэтью , Ричард Стоунс , Татьяна Коротяева

ОС и Сети / Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

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

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT
Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

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

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT