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

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

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

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

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

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

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

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

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

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

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