Как пасти котов. Наставление для программистов, руководящих другими программистами - Дж.Ханк Рейнвотер

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

Электронный администратор

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

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

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

Задача как объект – основной организующий принцип электронного администратора

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

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

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

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

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

Рис. 4.1. Задание

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

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

Рис. 4.2. Реализация задачи

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

Отображение и систематизация заданий

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

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

Рис. 4.3. Экран рабочего дня

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

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