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

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

В некоторых компаниях отдел разработки рассматривается как производственный цех, который, принимая на входе спецификации, в конечном счете выпускает готовый продукт. Будь это правдой, я, наверное, предпочел бы сменить профессию и из наемного рабочего превратиться во владельца такой фабрики. Во многих консалтинговых компаниях на полном серьезе рассуждают о «фабриках программных продуктов». Большинство таких компаний базируются за океаном, а выводы свои строят исходя из высокой стоимости и низкой окупаемости инвестиций – действительно, многие отделы разработки программного обеспечения в американских компаниях демонстрируют такую динамику. В двух книгах Эдварда Иордона (Edward Yourdon) – «Decline & Fall of the American Programmer» (Yourdon Press, 1993) и «Rise & Resurrection of the American Programmer» (Yourdon Press, 1996) – раскрываются причины, по которым в кругах разработчиков программного обеспечения планирование зачастую проводится недостаточно тщательно или вообще игнорируется. Возможно, связано это с тем, что мы упорствуем в восприятии программирования как одного из видов искусства[97]. Если бы мы подготавливали запуск ракеты на Луну, уверяю вас – обойтись без планирования было бы невозможно.

Кстати, скажу несколько слов об американской космонавтике. Как могло произойти, что в 1960-е годы, когда существующие программные средства уступали уровню типичного современного карманного компьютера, нам удалось высадить человека на Луну? Секрет в том, что причастные к этому проекту специалисты, исходя из имеющихся инструментальных средств, планировали свою деятельность с расчетом на успешный финал. В своих мемуарах, рассказывая о Центре управления полетами, Джин Кранц[98] (Gene Kranz) раскрывает принципы, которые, по его мнению, определили заметные успехи подведомственной ему структуры.

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

• Компетентность. Космические проекты не терпят небрежности и безразличия – требуется полная готовность к выполнению задания и тотальная устремленность на успех.

• Уверенность. Вера в себя и окружающих; сознание необходимости задушить страх и неуверенность.

• Ответственность. Понимание того, что поставленную задачу нельзя никому передоверить; есть всего две альтернативы: либо сделать то, что требуется, либо потерпеть фиаско.

• Упорство. Нацеленность на преодоление возможных трудностей; последовательность в достижении цели, даже если для этого необходимо пройти по сложному пути.

• Командные усилия. Уважение к способностям друг друга и их разумная эксплуатация; ощущение работы над общей целью и коллективной ответственности за результат.

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

Применимы ли принципы Кранца в нашей области? Думаю, вполне, и мне к ним даже нечего добавить. Это четкие, справедливые принципы, которые неплохо бы записать на бумажке, приклеив ее к монитору. Как я уже неоднократно говорил, совершенствование лидерских качеств повышает шансы на достижение успеха, а в части планирования без лидерства не обойтись. Не стоит сваливать эти обязанности на начальницу – не забывайте, что помимо вашего отдела ей, скорее всего, подчинены несколько других. Представьте себя локомотивом коммерческих достижений компании. Если следовать этой аналогии, получается, что вам, с одной стороны, требуются топливо и грамотная эксплуатация, с другой – кто-то должен жать на газ. Может быть, вы – свеча зажигания? Насколько резво вы искрите? Хватает ли вашей увлеченности, чтобы зажечь искру энтузиазма среди подчиненных?

<p>Знайте свой потолок</p>
Перейти на страницу:

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

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

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

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

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

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

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

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

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

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

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

Все жанры