• Заведите для каждого проекта несколько папок различных цветов; каждый такой цвет должен указывать на срочность действий, связанных с хранящимися в папке документами. К примеру, в красных папках можно собирать информацию, которая требует с вашей стороны незамедлительных действий. В синих папках имеет смысл хранить документы, с которыми можно ознакомиться чуть позднее, а в зеленых – все документы, связанные с денежными вопросами. Все эти правила просты и очевидны; если их не забывать, то даже после беглого просмотра документов вы сможете определиться с тем, что делать в первую очередь.
• Организуйте отдельное место для хранения литературы и соблюдайте в нем порядок. Скажем, профессиональные журналы нужно хранить отдельно от каталогов производителей. Все эти материалы следует сортировать по дате выхода и не слишком загромождать ими рабочее пространство. Если из целого журнала вашего внимания заслуживает единственная статья, вырежьте ее, положите в стопку, а от остальных страниц избавьтесь. Не стоит копить макулатуру лишь с той целью, чтобы удивить самого себя.
Скорее всего, в том, что касается систематизации бумажных документов, у вас есть какие-то собственные приоритеты и методы; возможно также, что в вашей компании существует четкая политика по этой части. Если вы не справляетесь с постоянно поступающими бумажными документами, скорее всего, это приведет к смещению приоритетов. Если бы безбумажное делопроизводство уже превратилось в реальность, то никому не нужно было бы подключать к корпоративным сетям многочисленные принтеры. Однако если уж вы ими пользуетесь, будьте любезны, разберитесь в своих распечатках.
Безбумажная волокита
Бумажные документы – это не единственная область, которую вам как менеджеру придется приводить в порядок. Несмотря на то что личные информационные секретари (Personal Information Managers, PIM) представлены на рынке в большом количестве, большинство руководителей до сих пор испытывают серьезные трудности в попытках организации электронных документов. Вполне возможно, что вы уже пользуетесь тем или иным программным продуктом для руководства проектом, он принят в вашей организации – и от него есть прок; если так, вы – счастливый человек. В то же время, по моим наблюдениям, многие компании и, в особенности, отдельные лица подходят к задаче систематизации электронных документов крайне индивидуально. Я неоднократно пытался приучить себя к применению разнообразных программ для руководства проектами и в результате понял, что все они оставляют желать лучшего. Я, пожалуй, не буду их называть. Выражусь так: все продукты одной компании, весьма популярной в северо-западных штатах Америки, оказались, с моей точки зрения, либо слишком сложными, либо чересчур ограниченными по своим возможностям, либо элементарно не соответствующими моим потребностям по части отслеживания организационных вопросов. Ну ладно, я назову имена – Microsoft Project, Team Manager (этот продукт поставляется на компакт-дисках MSDN). Не подошли мне и многочисленные видоизмененные (в плане объектной модели) версии Outlook. Lotus Notes, ACT! и многие другие личные информационные секретари вместе с программными продуктами для групповой работы также показались мне недостаточно гибкими и не подошли для систематизации моих рабочих процессов. Я вполне допускаю, что один из этих продуктов подойдет вам. Если так случится, вы получите шанс заметно продвинуться в деле ведения стаи за собой. Если же чуда не произойдет, придется обратиться к другому методу.
Так что же делать? Ведь я программист; все продукты, которые мне не понравились, созданы программистами; кроме того, я ностальгирую по тем временам, когда писал гораздо больше кода, чем сегодня. Таким образом, ответ для меня очевиден – нужно создать собственную программу управления проектами.
Итак, я поставил перед собой задачу создать программный продукт, с помощью которого мне было бы удобно справляться со своими организационными обязанностями. Он должен был стать чем-то средним между личным информационным секретарем и полноценной программой управления проектами; естественно, я также намеревался избавиться от излишнего усложнения и ограничений, присущих обоим названным типам программных продуктов. Работать над своим проектом мне пришлось по ночам, в нерабочее время и в гордом одиночестве. За первые полгода применения своего детища я скомпоновал более 200 исполняемых версий – все это время я обнаруживал очередные ошибки и подстраивал продукт под свои потребности. Несколько раз он очень помог мне справиться с административными задачами. По крайней мере, теперь, когда он у меня есть, я четко знаю, на сколько опаздываю, мне не приходится постоянно трястись от неопределенности и сознания груза несделанных дел. У меня хотя бы есть возможность измерить этот самый груз и распечатать соответствующий отчет – из него я узнаю, сколько ночей придется провести без сна, чтобы успеть все сделать к установленному сроку.
У моего личного проекта было несколько очевидных преимуществ. Во-первых, мне не пришлось собирать коммерческие требования, поскольку сценарии вариантов действий проявлялись регулярно. Во-вторых, в роли пользователя выступал я сам, а значит, реализация потребностей пользователя ограничивалась конструированием подходящего мне интерфейса. Это ведь мечта программиста – писать программы для самого себя. На этапе бета-тестирования я также не встретил никаких особых проблем. Обнаруживая ошибки, я брал исходный код и исправлял их. Помимо прочего, при работе над этим проектом я не испытывал синдромов, часто встречающихся у нагруженных административными функциями программистов, у которых не находится достаточного времени для кодирования. Оторваться от клавиатуры ведь довольно трудно, не так ли?
Итак, далее я познакомлю вас с собственноручно разработанным программным продуктом, который, по моему скромному мнению, помогает успешно организовать производственный процесс, направленный на достижение результата. Если этот продукт вам понравится (или вы осмелитесь адаптировать его к собственным потребностям), обратитесь к приложению А. В нем приводится более подробная информация, а также сведения о том, как получить исходный код.
По большому счету, все задачи, которые решаются в ходе разработки программных продуктов и соответствующей административной деятельности, можно разделить на три типа.
1. Проекты. Все задачи аккумулируются в рамках проекта – довольно удобной классификационной конструкции, связывающей те виды деятельности, которые направлены на производство качественного кода и зарабатывание денег для компании. Отдельные проекты, впрочем, не связаны с созданием продукта, предназначенного для продажи; однако если основным приоритетом для вас является успех компании на занятых ею рынках, вы, вероятно, согласитесь со мной в том, что любые продукты воплощаются в жизнь лишь благодаря способности группы разработчиков к созданию успешного программного обеспечения.
2. Источники. В качестве источника – то есть субъекта, поставившего задачу, – в зависимости от ситуации может выступать человек (зачастую вы сами), процесс или комитет (члены которого обычно не в меру ворчливы). Классификация задач по источникам помогает следить за выполнением собственных обещаний – в особенности если вы имели неосторожность дать их своему начальнику.
3. Назначенные задания. За распределение заданий между сотрудниками рабочей группы ответственны вы. О тех людях, с которыми вам приходится работать, я говорил на протяжении трех предшествующих глав. Теперь же мы обратимся к более приятной теме неодушевленных объектов. Обычно они молчат, хотя наличие на моем компьютере синтезатора речи лишает их этой замечательной особенности. Я немного отвлекся, хотя здесь тоже прослеживается важный принцип, касающийся перевода из рядов программистов в менеджеры. Мы лучше обращаемся с «вещами», чем с людьми.