Первоочередная задача и желательный результат деятельности любого хорошего менеджера заключается в обеспечении условий для достижения успеха подведомственной ему группой разработчиков. Впрочем, некоторые специалисты, занимающие ответственные должности, позиционируют себя «всего лишь» менеджерами и абстрагируются от лидерских аспектов деятельности. Если и вы придерживаетесь того же мнения, значит, вы, возможно, перегружены повседневными задачами и вам просто не хватает времени для стратегического планирования развития своей группы. Поймите меня правильно – менеджер действительно должен следить за тем, чтобы все текущие задачи своевременно исполнялись; лидер же, помимо решения повседневных задач по повышению продуктивности сотрудников, концентрируется на стратегических задачах своей группы и не ограничивает себя соблюдением контрольных сроков. Менеджеры иногда погрязают в хитросплетениях своей работы; лидеры, напротив, всегда стремятся разработать новые приемы, позволяющие подчиненным брать все более высокие планки. Этот своеобразный конфликт между функциями менеджера и качествами лидера напоминает хождение по канату – в том смысле, что нам все время приходится уравновешивать две в равной степени значимые для нашей профессии роли.

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

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

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

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

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

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

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

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

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

• бумажные носители очень удобны в тех случаях, когда информацию требуется изучить именно в то время и в том месте, в котором вам удобно;

• на бумаге удобно фиксировать ход дискуссии на совещании и в телефонном разговоре – писать на листке бумаги чуть проще, чем набирать текст на ноутбуке;

• бумажные носители не адаптированы для хранения, поиска, сортировки и многих других операций, с которыми блестяще справляются программные продукты;

• многие из нас воспринимают важную информацию лучше, считывая ее с бумажного носителя, и хуже, считывая ее с монитора;

• заложники собственной культуры, мы привыкли воспринимать информацию, зафиксированную на листах прямоугольной формы размером 210*297 мм.

Вполне возможно, что в будущем планшетные компьютеры смогут объединить в себе достоинства бумаги с широчайшими возможностями программного обеспечения. Лично я все жду, когда же появятся жидкокристаллические экраны толщиной с лист бумаги, на которых можно будет писать ручкой и карандашом, стирать записанную информацию, сохранять ее в электронном виде, а затем перезагружать на тех же листах уже другие данные. Не знаю, дождусь ли, – ведь хочется, чтобы такие экраны продавались в магазинах пачками по 500 штук и стоили не более 3,95 доллара.

В защиту бумаги отмечу, что на протяжении большей части XX века она оставалась основным носителем коммерческой информации и, скорее всего, в ближайшее время все еще будет играть важную роль. Скорее всего, вы поняли, к чему я это все говорю. Да, действительно – управляться с горами листов очень непросто. Они постоянно устаревают, вам вечно приходится думать о том, как бы не обанкротиться на одних только картриджах и т. д., и т. п.

Как же справиться с бумажной неразберихой? Придется усвоить несколько основополагающих принципов. Они излагаются на всех учебных курсах по основам бизнеса, но, по-моему, их стоит вспомнить и здесь[44]. Может быть, вам покажется, что принципы, которые я здесь излагаю, самоочевидны, но вы не представляете, какое количество менеджеров испытывают страшные мучения в попытках как-то упорядочить кипы бумаг – и все по той простой причине, что они игнорируют правила систематизации.

Итак, в том, что касается структурирования бумажных материалов, я предлагаю соблюдать нижеследующие принципы.

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

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

• Каждый листок бумаги, который по тем или иным причинам появился на вашем рабочем столе, необходимо переложить в соответствующую папку. Не доводите дело до появления на столе груды бумаг. Не забывайте, что папка для входящих документов – это лишь временный резервуар и ни в коем случае не постоянное хранилище. Стоит на вашем столе появиться кипам бумаг, как вы незамедлительно начнете опаздывать с выполнением организационных функций, которые, вполне возможно, необходимы для достижения успеха.

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

• Организуйте отдельное место для хранения литературы и соблюдайте в нем порядок. Скажем, профессиональные журналы нужно хранить отдельно от каталогов производителей. Все эти материалы следует сортировать по дате выхода и не слишком загромождать ими рабочее пространство. Если из целого журнала вашего внимания заслуживает единственная статья, вырежьте ее, положите в стопку, а от остальных страниц избавьтесь. Не стоит копить макулатуру лишь с той целью, чтобы удивить самого себя.

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

Бумажные документы – это не единственная область, которую вам как менеджеру придется приводить в порядок. Несмотря на то что личные информационные секретари (Personal Information Managers, PIM) представлены на рынке в большом количестве, большинство руководителей до сих пор испытывают серьезные трудности в попытках организации электронных документов. Вполне возможно, что вы уже пользуетесь тем или иным программным продуктом для руководства проектом, он принят в вашей организации – и от него есть прок; если так, вы – счастливый человек. В то же время, по моим наблюдениям, многие компании и, в особенности, отдельные лица подходят к задаче систематизации электронных документов крайне индивидуально. Я неоднократно пытался приучить себя к применению разнообразных программ для руководства проектами и в результате понял, что все они оставляют желать лучшего. Я, пожалуй, не буду их называть. Выражусь так: все продукты одной компании, весьма популярной в северо-западных штатах Америки, оказались, с моей точки зрения, либо слишком сложными, либо чересчур ограниченными по своим возможностям, либо элементарно не соответствующими моим потребностям по части отслеживания организационных вопросов. Ну ладно, я назову имена – Microsoft Project, Team Manager (этот продукт поставляется на компакт-дисках MSDN). Не подошли мне и многочисленные видоизмененные (в плане объектной модели) версии Outlook. Lotus Notes, ACT! и многие другие личные информационные секретари вместе с программными продуктами для групповой работы также показались мне недостаточно гибкими и не подошли для систематизации моих рабочих процессов. Я вполне допускаю, что один из этих продуктов подойдет вам. Если так случится, вы получите шанс заметно продвинуться в деле ведения стаи за собой. Если же чуда не произойдет, придется обратиться к другому методу.

Так что же делать? Ведь я программист; все продукты, которые мне не понравились, созданы программистами; кроме того, я ностальгирую по тем временам, когда писал гораздо больше кода, чем сегодня. Таким образом, ответ для меня очевиден – нужно создать собственную программу управления проектами.

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

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

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

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

1. Проекты. Все задачи аккумулируются в рамках проекта – довольно удобной классификационной конструкции, связывающей те виды деятельности, которые направлены на производство качественного кода и зарабатывание денег для компании. Отдельные проекты, впрочем, не связаны с созданием продукта, предназначенного для продажи; однако если основным приоритетом для вас является успех компании на занятых ею рынках, вы, вероятно, согласитесь со мной в том, что любые продукты воплощаются в жизнь лишь благодаря способности группы разработчиков к созданию успешного программного обеспечения.

2. Источники. В качестве источника – то есть субъекта, поставившего задачу, – в зависимости от ситуации может выступать человек (зачастую вы сами), процесс или комитет (члены которого обычно не в меру ворчливы). Классификация задач по источникам помогает следить за выполнением собственных обещаний – в особенности если вы имели неосторожность дать их своему начальнику.

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

Ну ладно, хватит разглагольствовать! Лучше взгляните на рис. 4.1 – он представляет собой графическую иллюстрацию представленной выше концепции.

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

За утверждением задачи – в том виде, в котором она представлена на нашей схеме – следует этап ее реализации в программном продукте. На рис. 4.2 в традициях классического двухзвенного[45] MDI-приложения с нагруженной клиентской частью (в эпоху веб-приложений[46] такая схема кажется очевидно устаревшей) изображен графический пользовательский интерфейс, реализующий представленный выше принцип.

Согласно моей задумке, в окне, показанном на рис. 4.2, должны умещаться все данные, с помощью которых можно идентифицировать задания и отследить их выполнение. Три основных отношения – источник, назначенные задания и проект – дополняются стандартными и вполне ожидаемыми параметрами: состоянием, сроками начала и завершения, а также приоритетом. Кроме того, в моей версии программы присутствует запись-ссылка на область действия[47]. В некоторых компаниях она может сослужить хорошую службу. Среди прочих нелишних характеристик стоит упомянуть возможность создания документа с данными по конкретной задаче и, естественно, возможность сохранения собранной информации в базе данных. Раздел Details я выполнил в виде форматируемого поля, в которое можно встраивать внешнюю графику, – как известно, один рисунок способен сообщить программисту больше, чем тысяча слов.

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

Решение, к которому я обратился, предполагает наличие дочернего MDI-интерфейса, способного собирать в одном месте всю информацию о критически важных заданиях на сегодняшний день. Повторюсь: для того чтобы обеспечить соответствие конструируемого программного продукта задачам, которые он должен решать, необходимо постоянно подгонять самого себя и отслеживать работу подчиненных. В противном случае вы рискуете не справиться со своими функциями. Вспомните меткий призыв из главы 2 относительно ожидания результатов без проведения проверок, который я позаимствовал у какого-то университетского профессора. Отталкиваясь от его смыслового наполнения, я сконструировал показанный на рис. 4.3 экран.

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

В программе присутствует средство генерации отчетов о задачах и встречах руководителя, а также списках назначенных заданий. Их можно как распечатывать, так и экспортировать. Любой список заданий предусматривает возможность фильтрации по сроку завершения в виде функции текущей даты; переключатели позволяют оперативно устанавливать разные режимы: режим сегодняшних заданий и всех долгов с предыдущих дней, режим заданий до 5 дней, начиная от текущей даты, а также представление всех заданий. Каждую полночь таймер в этой форме переустанавливает заголовки фильтров, чтобы они все всегда соответствовали заданному диапазону в 5 дней от текущей даты. Для того чтобы ввести новое задание с помощью предварительно выделенного комбинированного окна Assigned, щелкните на кнопке Add Mng Task. Для назначения нового задания щелкните на кнопке Add Asg Task.

В приложении А приводятся более детальные сведения об электронном администраторе (эта программа стала моим любимым проектом), а также о примененных в ходе его конструирования методиках и компонентах.

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

Не следует питать иллюзий – комплексный проект с многочисленными взаимозависимостями нельзя вести исключительно средствами простых программных продуктов вроде того, что я описал в предыдущем разделе. Решение о том, подходит ли тот или иной продукт для конкретного проекта, всецело зависит от вас. Более того, вы должны сами себя оценивать по части ведения всех организационных вопросов в своем отделе. Слово «администрирование» (administration) происходит от словосочетания «добавочное министерство» (added ministry); в некотором смысле, администрирование по отношению к основным задачам не является приоритетной областью вашей деятельности. Вопрос в том, сколько сил и энергии вы затрачиваете на улаживание организационных вопросов. Необходимо всегда иметь в виду, что в процесс вашей повседневной деятельности постоянно будут вмешиваться разного рода проблемы, которые придется решать дополнительно к выполнению ваших непосредственных функций. Повышая уровень своей личностной организации, вы фактически сокращаете сроки исполнения своих первоочередных заданий.

«Непосредственные функции» – выражение весьма двусмысленное. Администрирование – это полноценная область деятельности, и заниматься ею необходимо. В то же время программисты-менеджеры воспринимают административные функции в штыки. Здесь можно провести параллель с кодированием и комментированием. Код без комментариев трудно читать. Аналогичным образом руководство без администрирования становится неорганизованным и даже (иногда) неверным по своей сути. В этой книге я исхожу из того, что вы обязаны вести сотрудников своего отдела к намеченным целям. При этом ключевую роль как в чисто внешнем, так и в фактическом аспекте лидерства играет эффективная и стройная система администрирования.

Ключевую роль как в чисто внешнем, так и в фактическом аспекте лидерства играет эффективная и стройная система администрирования.

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

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

Рассмотрим список подконтрольных и неподконтрольных областей (табл. 4.1).

Таблица 4.1. Подконтрольные и неподконтрольные области

Подконтрольные области

Методы и действия, направленные на упорядочение и систематизацию информации.

Распределение конкретных задач между сотрудниками отдела.

Архитектура программного обеспечения.

Время, фактически выделяемое на выполнение заданий.

Ваши ожидания относительно собственной продуктивности.

Ваше отношение к трудным с точки зрения общения людям.

Неподконтрольные области

Потребность окружающих людей делиться с вами информацией.

Выбор проектов, над которыми вам предстоит работать. Проекты могут нравиться или не нравиться, но работать нужно со всеми.

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

Время, которое вы должны уделить решению задач в соответствии с внешними ожиданиями.

Ожидания окружающих относительно вашей продуктивности.

Трудные в общении люди, непосредственно вам не подчиняющиеся.

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

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

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

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

Столкнувшись с новым информационным блоком проекта, задайте себе несколько вопросов.

• Как новые данные отражаются на области действия проекта, на проектном решении, на конечном сроке сдачи проекта?

• Надежен ли источник информации; если нет, то можно ли его проигнорировать?

• Следует ли реагировать на поступление информации незамедлительно или можно немного подождать?

• Где и как сохранить информацию с тем, чтобы при необходимости к ней можно было бы оперативно обратиться?

• Каков срок действия информации? Когда она становится неактуальной?

• Как данная информация соотносится с тем, что уже известно о проекте?

Эти и подобные вопросы направлены на систематизацию данных. Систематизируя данные, вы обретаете контроль над ними, и, соответственно, они теряют контроль над вами.

Правда, было бы замечательно, если бы мы могли работать только над теми проектами, которые нам лично интересны? К сожалению, в долгосрочной перспективе такой подход нежизнеспособен. Иногда задачи, которые ставит перед нами наше дело, идут вразрез с нашей эмоциональной реакцией на них. Таким образом, тщательное распределение заданий есть наилучший метод поддержания заинтересованности в их исполнении со стороны ваших сотрудников (да и с вашей стороны тоже). Люди бывают разные: одни лучше приспособлены к одним проектам, другие – к другим. В главе 1 эта проблема обсуждалась в контексте пород программистов.

Следует, правда, учитывать, что ваши возможности по наделению всех сотрудников интересной работой ограничены. Если вы хотите остаться на работе, придется выполнить все проекты, отведенные вашему отделу. В частности, вам не избежать необходимости разработки проблем, которые вам совершенно безразличны. Как преодолеть упаднические настроения, которые часто сопровождают начало очередного нудного проекта по сопровождению кода? Попробуйте перераспределять задания. В результате вы сможете избежать ситуации, при которой все самые утомительные функции ложатся на одного человека. Эти вопросы находятся в зоне вашего контроля. Варьируйте задания, перераспределяйте их между сотрудниками ежедневно или еженедельно – для этого у вас есть все возможности. Многие усматривают в разнообразии смысл жизни; по моему мнению, программистам разнообразие совершенно необходимо – оно помогает выводить наши мозги «на пик формы».

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

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

Роль технического лидера подробно рассматривается в главе 6. Вы еще успеете ее прочитать, а пока запомните, что контроль над программной архитектурой, применяемой в компании, в значительной степени определяет успешность конечного результата вашей деятельности. Какое отношение, спросите вы, имеют организационные навыки к архитектуре? Непосредственное, отвечу я. Методики, применяемые при систематизации потока административной информации, полностью применимы к проектированию программных средств. Подумайте, как классифицируются программные требования в расчете на их реализацию в объектах кода. Не кажется ли вам, что инкапсуляция кода во многих отношениях подобна наполнению папки для документов проекта? Я считаю, что совершенствование организационных навыков в одной области помогает добиться лучших результатов в другой.

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

На продолжительность вашего рабочего дня влияет великое множество факторов. Скорее всего, вы уже свыклись с тем, что сверхурочные (помимо стандартных 40 часов в неделю) в вашем положении есть неизбежное зло. Возможно, это действительно так. Когда компьютерная революция только начиналась, все мы надеялись на то, что она приведет к повышению производительности труда, что, в свою очередь, облегчит планирование продолжительности рабочей недели. Революция подошла к концу, но результаты в этом отношении двойственны. С одной стороны, с помощью компьютеров мы действительно сумели повысить эффективность своего труда. Часто это означает, что более серьезные результаты достигаются за меньшее время. С другой стороны, исходя из собственного опыта, я могу заключить: возможность выполнения большего числа заданий приводит к тому, что мы начинаем больше работать, в результате рабочая неделя неизбежно удлиняется, и вести нормальную жизнь вне рабочего пространства становится все труднее. Если вы будете работать дольше, чем обычно, вашему примеру обязательно последуют подчиненные. Эффект подобного рода изменений неоднозначен. Если вы человек несемейный, то, скорее всего, продление рабочего времени никак не скажется на вашей личной жизни. Те же ваши сотрудники, у которых есть семьи (а им, как известно, неплохо бы уделять определенное внимание), вряд ли будут радоваться удлинению рабочей недели. При принятии решения о том, какой пример подавать подчиненным, этот фактор нужно обязательно учитывать. В отрасли производства программного обеспечения переработка встречается сплошь и рядом. В то же время вы должны учитывать, что продолжительная беспрерывная рабочая деятельность неизбежно ведет к снижению производительности.

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

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

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

Не сомневаюсь, что вы предъявляете к себе самые что ни на есть высокие требования, – в противном случае вы вряд ли стали бы руководителем. Все это замечательно, ставить перед собой масштабные цели очень полезно. В то же время вы просто обязаны сопоставлять свои амбиции с реальностью. Реалист четко осознает, что время от времени он может действовать не лучшим образом. Реалист также понимает, что контролировать ожидания окружающих относительно него самого невозможно – если только он не сторонник раздачи невыполнимых обещаний. Кстати, об обещаниях – с ними нужно соблюдать осторожность. Именно от них зависит, какие требования к вам будут предъявлять ваши сотрудники и ваши коллеги. Держать чужие ожидания относительно себя самого под контролем вы сможете лишь в том случае, если будете благоразумны в своих обещаниях. Ричард Карлсон (Richard Carlson), заслуживший за свою книгу «Don't Sweat the Small Stuff» исключительной похвалы, рассуждает об обещаниях следующим образом:

«Некоторые обещания, которые мы даем окружающим людям, на первый взгляд, и не кажутся таковыми. Иногда мы даем их, сами того не сознавая. Чего стоят выражения типа «я тебе перезвоню позже», «я подъеду к тебе на работу», «на следующей неделе я вышлю тебе экземпляр моей книги», «я с удовольствием куплю ее тебе», «если тебя понадобится сменить, дай мне знать». Даже невинные в первом приближении фразы типа «без проблем» представляют для сказавшего некоторую опасность – дело в том, что их часто воспринимают как предложение выполнить некоторое действие, хотя на самом деле вы либо не хотите этим заниматься, либо не располагаете для этого достаточными ресурсами. Фактически, сказав так, вы позволили собеседнику высказать к вам более серьезную просьбу, чем раньше, – ведь это не проблема!»[48]

Отдельные личности склонны ожидать от руководителей больше, чем те способны сделать. С такими ожиданиями нужно смириться. Некоторые начальники – я имею в виду тех, кто находится выше вас в руководящей иерархии – предъявляют к своим подчиненным чрезмерно высокие требования, но при этом не удосуживаются посвящать их в подробности своих замыслов. Если это именно ваш случай, не вините себя. На самом деле виноват ваш начальник, а читать его мысли вы пока не научились, так? О том, как взаимодействовать с начальником, мы поговорим более подробно в главе 9. Пока что запомните: дать отпор несбыточным ожиданиям можно за счет ваших организационных способностей. Обязательно уточняйте, что от вас хотят. Если ваш начальник темнит относительно того, чего он от вас ожидает, поднажмите на него, заставьте четко сформулировать требования. Без четко определенных исходных данных добиться успеха в области конструирования программных средств невозможно. Организованность в этом процессе есть лучший способ избежать ситуаций, при которых первая версия продукта оказывается для остальных подразделений компании неожиданным и нежелательным сюрпризом.

Возможно, вы слышали такое высказывание: «контролировать проблему трудно, но контролировать отношение к проблеме в ваших силах». Для того чтобы осознать справедливость этой мысли, мне потребовалось довольно много времени. А как думаете вы? Если ваше отношение к этому принципу скептическое, скорее всего, во взаимоотношениях с трудными людьми вам суждено проигрывать. Организованность отнюдь не ограничивается умением раскладывать документы по папкам и вводить данные в программу управления проектом. Куда важнее уметь должным образом обращаться с трудными подчиненными. Ларри Константайн (Larry Constantine) – ведущий исследователь проблем персонала в проектах по разработке программных средств – мыслит в этом контексте следующим образом:

«Попытки справиться с трудными ситуациями следует начинать с постановки ряда вопросов. По моему опыту, задав нужный вопрос, вы кардинально повышаете шансы на получение нужного ответа. Вместо того чтобы возмущаться, почему с тем или иным сотрудником так сложно говорить, я предпочитаю задаться вопросом о том, почему у меня возникают трудности во взаимодействии с ним. Я прекрасно понимаю, что вылавливать мелкие недочеты в деятельности коллег значительно проще, чем устранять собственные недостатки, – даже если они очень существенны. И все же я утверждаю, что любая нервотрепка в процессе общения с трудным человеком – это одновременно возможность лучше узнать самого себя. Придерживаясь этого принципа, вы, скорее всего, со временем обнаружите, что людей, с которыми вам трудно общаться, остается все меньше»[49].

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

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

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

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

Мотив: Производить гениальные продукты и тем самым зарабатывать для компании деньги.

Воздействие: Путем продуктивного и эффективного использования компетентных специалистов и прочих ресурсов свести непроизводительные издержки к минимуму.

Мотив: Забавляться с технологией.

Воздействие: Оптом скупать свежие программные средства и бесцельно генерировать забавные программы.

Мотив: Пройти очередной этап к реализации ваших непомерных амбиций.

Воздействие: Работать без отдыха в надежде на повышение или, пользуясь своим положением, участвовать в интригах и добиваться повышения во что бы то ни стало любыми средствами.

Лишь первый мотив из трех вышеперечисленных можно признать допустимым. Остальные либо вторичны, либо в корне неверны. О существе третьего мотива я расскажу в главе 7, посвященной обратной стороне лидерства. Вы должны четко уяснить, что амбиции вполне допустимы, но лишь в том случае, если на первое место вы ставите планы компании и лишь на второе – свои планы. Второй мотив, приведенный в табл. 4.2 (забавы), при удачном стечении обстоятельств становится побочным продуктом первого.

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

Мою книгу трудно отнести в одну категорию с формализованными учебниками по руководству проектами. Но факт остается фактом – для того чтобы преуспеть в области лидерства, вы должны стать хорошим руководителем проекта. В литературе, имеющейся на рынке, эта область описана очень комплексно, и ряд рекомендуемых работ по данной теме есть в разделе «Библиография». Шаг за шагом вам предстоит овладевать все новыми и новыми навыками руководства проектами и в особенности – специальными методиками управления проектами по разработке программного обеспечения. По словам автора одной из моих самых любимых книг на эту тему: «основная причина неудач в процессе разработки программных продуктов заключается в неадекватном руководстве проектами»[50]. Обратите внимание на ключевое слово – «адекватность». Действительно, наличие организационных навыков, ориентированных на управление проектами, есть основной залог успешной реализации последних. На первый взгляд приведенная цитата кажется чрезмерно упрощенной. В то же время, если вы ознакомитесь с рекомендуемыми мною литературой и предложениями по руководству проектами, многочисленные причины, по которым это высказывание представляется справедливым, станут для вас очевидными.

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

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

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

Если вы работаете в небольшой компании, скорее всего, выделение в ней отдела руководства продуктами будет связано с большими трудностями или просто окажется слишком дорогим и неэффективным. Это, впрочем, не отменяет необходимости в выполнении функций таких отделов. Возможно, они даже войдут в ваши обязанности. В таком случае мои вам соболезнования – мне приходилось заниматься обоими видами деятельности, и, скажу я вам, переключаться между двумя ролями очень трудно. В идеале вам следует сориентировать своих подчиненных не на описание продуктов, а на их разработку. Я совершенно не хочу сказать, что программисты не способны к восприятию коммерческих потребностей, – напротив, чем больше осведомлен программист, тем лучше. Тем не менее нужно иметь в виду, что программист призван реализовать существующее описание; переделывать его заново совершенно не стоит. По моим наблюдениям, даже без участия сотрудников из других отделов программисты способны мгновенно организовать разрастание области действия. Продукт легче всего разработать, если он четко описан. Более того, им удобнее управлять – по крайней мере, по сравнению с не в меру инициативными кодировщиками, бредящими очередной специальной функцией.

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

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

Обратите внимание: речь идет не о «руководстве проектом». Представить себе неопределенный проект довольно сложно. Процесс определения проекта следует непосредственно за описанием продукта. В этом контексте вам придется приложить свои административные способности. В предыдущей главе, как вы помните, мы говорили о том, чем нереалистичный цикл разработки продукта отличается от реалистичного. В основном различия между проектом, организованным по принципу Алисы в Стране Чудес, и проектом, который имеет шанс увенчаться созданием качественного продукта, кроются в деталях. За этапом определения следуют этапы специфицирования, проектирования, макетирования и многие другие итеративные процессы, формирующие очертания процесса в целом. Все эти процессы можно отнести к разработке, однако следует иметь в виду, что цикл разработки выводится исходя из контекста различных мелких элементов проекта.

При организации проекта вы должны отталкиваться от опыта работы с предыдущими проектами – вне зависимости от того, насколько они были успешными или, наоборот, провальными. Наибольший воспитательный эффект мы получаем от неудач (хотя и успехи в этом отношении очень полезны). Прежде чем подписаться на методику программной инженерии, основательно подумайте. Методика эта полностью применима к некоторой части крупных проектов, однако в том, что касается программного обеспечения, мастерство оказывается важнее инженерии. Это мое мнение. Его разделяют многие другие специалисты, но как к нему относиться – решайте сами. В конце концов, купив эту книгу, вы заплатили за мое мнение определенную цену. Выражусь иначе: если ваша группа сможет договориться со спонсорами по поводу этапов работы над проектом, то при утверждении сроков завершения работы вряд ли вам придется тыкать пальцем в небо. Дата выпуска программных продуктов часто рассматривается как движущаяся цель; чтобы справиться с неопределенностью, постарайтесь уяснить одну простую вещь – выпуск невозможен без предварительного комплексного тестирования. Очевидно, что тестирование проводится после кодирования, кодирование после проектирования и т. д. Я совершенно не хочу навязать вам какой бы то ни было процедурный шаблон с условием обязательного применения во всех проектах. Я просто пытаюсь напомнить о том, что прежде конструирования нужно тщательно определить и структурировать процессы, реализуемые в рамках проекта.

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

Как известно, изменения в нашей жизни есть единственное постоянное явление. Этот принцип вы слышали не раз, не так ли? Даже в курсе по основам физики утверждается, что в замкнутых системах следует ожидать повышения энтропии. Так почему же тогда мы пишем книги, читаем код, занимаемся другими структурированными видами деятельности? Надо полагать, что-то (или кто-то) способствует упорядочению, которое противостоит естественной, присущей всей Вселенной тенденции к дезорганизации. «Что это он такое мелет? – спросите вы. – Уж не хочет ли он сказать, что мне предстоит стать "Богом управления процессами"?» Да, именно это я и имею в виду. Хотите более замысловатый титул – можете называть себя «владыкой изменений». Главное, как вы понимаете, – не наименование, а действие. В рамках общей, единой для вашей компании стратегии вы должны руководить процессом определения продуктов и проекта.

Изменения делятся на два основных типа: намеренные и случайные. Изменения, относящиеся к первому типу, обычно планируются; вторые же, как правило, непредсказуемы. Если вы ориентированы на успех, старайтесь тщательно управляться с намеренными изменениями – тогда вы сможете получить определенный контроль над случайными изменениями. Подумайте, какое воздействие модификация продукта окажет на сетевую инфраструктуру? А как насчет изменения механизма взаимодействия с пользователем во второй версии продукта? Учитываете ли вы все эти моменты? Кодирование не есть изолированный процесс. По словам Томаса Мертона (Thomas Merton), «нас согревает огонь, а не дым; через океан мы плаваем на кораблях, а не на волнах, которые они оставляют за собой»[51]. К сожалению, слишком часто программные продукты создаются без достаточного анализа воздействия технических решений на окружающую среду – «дым» и «волна» наших усилий в таких случаях приводят к дестабилизации деятельности компании.

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

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

• Каким представляется воздействие изменения на архитектуру системы и процесс сопровождения?

• Как предполагаемое изменение воздействует на сетевую инфраструктуру, в которой оно будет проводиться?

• Как предполагаемое изменение повлияет на способность пользователя эффективно и продуктивно взаимодействовать с данным программным продуктом?

• Какое влияние предполагаемое изменение окажет на действия сотрудников отделов, которым его придется испытать на собственной шкуре?

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

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

Если программист считает, что справился со своим кодом «неплохо», насторожитесь! Дело в том, что эпитет «неплохо» можно трактовать по-разному. В любом случае в деле выявления ошибок контрольный сценарий, написанный бизнес-экспертом, приносит большую пользу, чем программист, просматривающий функцию собственного сочинения. Ни один человек не способен в одиночку адекватно оценить последствия побочных изменений в программном продукте. Наличие группы тестирования, сотрудники которой также ответственны за развертывание, есть необходимое условие достижения успеха. Тестеры должны быть вашими лучшими друзьями. Именно они помогают выпускать качественные продукты; они же составляют первую линию защиты от некачественных графических пользовательских интерфейсов.

Многие считают, что физические условия, в которых ежедневно трудятся сотрудники компании, не слишком существенны. Если и вы придерживаетесь этого мнения, подумайте еще раз. В главе 3, рассуждая о том, как разбираться с внешними раздражителями, я мельком упомянул проблему рабочего пространства. Стандартные офисные клетушки не подходят для программистов. Совместное пользование одним компьютером – это тоже не про нас. Не менее разрушительной в контексте деятельности программистов представляется практика непрекращающихся боевых действий с системными инженерами с целью получения доступа к важным системным ресурсам. Все эти элементы физического окружения, которые совершенно необходимы для успешной деятельности группы программистов, стоят денег, и немалых. Задарма ничего не выйдет. С другой стороны, если сопоставить продуктивность (в категориях времени и стоимости) работы в плохих условиях с продуктивностью в нормальной рабочей среде, мы придем к выводу, что вложения в физическую инфраструктуру вполне оправданы.

На то, чтобы говорить, и на то, чтобы думать, у программистов должно быть время. Некоторые утверждают, что тем и другим они могут заниматься одновременно; впрочем, исходя из результатов многолетних наблюдений, я с подозрением отношусь к подобного рода заявлениям. По моему мнению, для того чтобы программисты достигали в своей деятельности определенных успехов, у них должна быть возможность, с одной стороны, некоторое время поработать в коллективе, с другой – пораскинуть мозгами в полном одиночестве. У каждого программиста должно быть собственное помещение с дверью, которая действительно закрывается. Конкретный метраж обусловливается теми средствами, которые вы готовы вложить в улучшение физических рабочих условий. Скажу лишь, что если на каждого программиста будет приходиться менее 130 квадратных футов, вы рискуете нарваться на неприятности. Как мне удалось вычислить эту величину с такой точностью? Дело в том, что 130 квадратных футов – это средний метраж спальни американского подростка. Если уж подростки, проводящие свои юные годы на таком пространстве, способны добиваться определенных успехов, то же можно сказать о программистах.

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

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

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

В распоряжении любого программиста должен быть быстродействующий компьютер с максимально возможным объемом памяти. Кроме того, программисту нужна тестовая машина, воспроизводящая стандартные характеристики пользовательских компьютеров. Вполне вероятно, что в вашей компании наличествует сетевая инфраструктура, призванная обеспечивать поддержку разрабатываемых продуктов (веб-серверы, метафреймы Citrix Metaframe и т. д.). Соответственно, для тестирования результатов разработки эти продукты следует дублировать зеркалами. Иногда они могут использоваться совместно с группой тестирования, однако имейте в виду, что отделение сред разработки и тестирования от непосредственного производства себя оправдывает. Мне приходилось встречаться с компаниями, которые бездумно разрешали программистам напрямую редактировать веб-сайты путем удаленной загрузки файлов. Это самый неудачный метод, какой только можно себе представить. Он, конечно, удобен, но чрезвычайно опасен.

Если вашим сотрудникам приходится переходить с места на место (или сверхурочно работать дома), лучше всего приобрести для них ноутбуки. Сегодня они практически не уступают по своим возможностям настольным компьютерам, поэтому экономить не стоит. Не забывайте к тому же, что программисты предъявляют к своим машинам значительно более высокие требования, чем средние пользователи. Возможно, вам придется скорректировать принятую в компании политику технического обеспечения с учетом потребностей ваших подчиненных. Программистам нужно предоставить полномочия администратора в отношении прав доступа и конфигурирования их собственных машин. Если кто-то из них запутается в конфигурации, покажите, как решить проблему, которую он сам себе создал. Прибегать к услугам специалистов следует лишь в крайнем случае. Программисты, которые не знают, как сконфигурировать операционную систему или установить ее с чистого листа, просто недостаточно научены. Их уровень владения понятиями TCP/IP не должен уступать уровню системных инженеров.

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

• Допускают ли ваши собственные рабочие условия оперативность при превращении информации в действия? Если нет, постарайтесь систематизировать делопроизводство в соответствии с рекомендуемыми методиками в этой области – так, чтобы, помимо просто руководства, вы могли взять на себя лидерские функции.

• Работайте над теми сферами своей деятельности, которые поддаются контролю, и смиритесь с тем, что некоторые из сфер неконтролируемы.

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

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

В следующей главе мы поговорим о том, какую роль вы должны исполнять на совещаниях. Организационные навыки, проявляемые на совещаниях, вносят существенный вклад в достижении поставленных целей. В идеале совещания с другими группами (и, в особенности, с собственными сотрудниками) должны проводиться исходя из четко сформулированных целей и не менее определенных представлений о предполагаемых результатах. По мере ознакомления с материалом моей книги вы постепенно придете к мысли, что решить все проблемы сразу не получится. Вряд ли, к тому же, вам удастся извлечь из этой книги точные схемы действий в тех или иных ситуациях. Темы, которые я поднимаю, придется переосмыслить – так, чтобы выстроить материал согласно специфике исполняемых вами функций. Итак, вперед – читайте сердцем! Делайте с моим материалом все, что сочтете нужным, – я не обижусь.

Примечания:

4

Ellen Ullman, Close to the Machine (San Francisco: City Lights Books, 1997), p. 20.

5

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

44

Я просмотрел несколько изданий по бизнесу и кое-какие из них мне понравились. В частности, возьмите на заметку издание Ronni Eiscnberg. Organize Your Office (Hyperion, 1998).

45

Имеются в виду не логические, а физические звенья.

46

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

47

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

48

Richard Carlson, Don't Sweat the Small Stuff at Work (New York: Hyperion, 1998), p. 74.

49

Larry L. Constantino, Beyond Chaos: The Expert Edge in Managing Software Development (New York: Addison-Wesley, 2001), p. 4.

50

William Н. Brown et al, AntiPatterns in Project Management (New York: John Wiley & Sons, 2000), p. xxi.

51

Thomas Merton, No Man Is an Island (New York: Harcourt Brace Jovanovich, 1955), p. 117.