У моего личного проекта было несколько очевидных преимуществ. Во-первых, мне не пришлось собирать коммерческие требования, поскольку сценарии вариантов действий проявлялись регулярно. Во-вторых, в роли пользователя выступал я сам, а значит, реализация потребностей пользователя ограничивалась конструированием подходящего мне интерфейса. Это ведь мечта программиста – писать программы для самого себя. На этапе бета-тестирования я также не встретил никаких особых проблем. Обнаруживая ошибки, я брал исходный код и исправлял их. Помимо прочего, при работе над этим проектом я не испытывал синдромов, часто встречающихся у нагруженных административными функциями программистов, у которых не находится достаточного времени для кодирования. Оторваться от клавиатуры ведь довольно трудно, не так ли?
Итак, далее я познакомлю вас с собственноручно разработанным программным продуктом, который, по моему скромному мнению, помогает успешно организовать производственный процесс, направленный на достижение результата. Если этот продукт вам понравится (или вы осмелитесь адаптировать его к собственным потребностям), обратитесь к приложению А. В нем приводится более подробная информация, а также сведения о том, как получить исходный код.
По большому счету, все задачи, которые решаются в ходе разработки программных продуктов и соответствующей административной деятельности, можно разделить на три типа.
Ну ладно, хватит разглагольствовать! Лучше взгляните на рис. 4.1 – он представляет собой графическую иллюстрацию представленной выше концепции.
Как и обещано, на этой схеме изображены все три отношения между задачей, с одной стороны, и информационным потоком и процессом администрирования, с другой.
За утверждением задачи – в том виде, в котором она представлена на нашей схеме – следует этап ее реализации в программном продукте. На рис. 4.2 в традициях классического двухзвенного[45] MDI-приложения с нагруженной клиентской частью (в эпоху веб-приложений[46] такая схема кажется очевидно устаревшей) изображен графический пользовательский интерфейс, реализующий представленный выше принцип.
Согласно моей задумке, в окне, показанном на рис. 4.2, должны умещаться все данные, с помощью которых можно идентифицировать задания и отследить их выполнение. Три основных отношения – источник, назначенные задания и проект – дополняются стандартными и вполне ожидаемыми параметрами: состоянием, сроками начала и завершения, а также приоритетом. Кроме того, в моей версии программы присутствует запись-ссылка на область действия[47]. В некоторых компаниях она может сослужить хорошую службу. Среди прочих нелишних характеристик стоит упомянуть возможность создания документа с данными по конкретной задаче и, естественно, возможность сохранения собранной информации в базе данных. Раздел Details я выполнил в виде форматируемого поля, в которое можно встраивать внешнюю графику, – как известно, один рисунок способен сообщить программисту больше, чем тысяча слов.