Нельзя автоматизировать хаос
Нельзя автоматизировать хаос
Прежде чем говорить о том, как управлять проектами, определимся сначала, что собственно подразумевается под термином “проект”. Авторитетная в области управления проектами, признанной специальной дисциплиной управления, организация Project Management Institute определяет проект как “совокупность действий (процессов), приносящих результат, во время которых людские, финансовые и материальные ресурсы определенным образом организуются с тем, чтобы результат соответствовал утвержденным спецификациям, стоимостным и временным затратам как по качественным, так и по количественным показателям”.
Как правило, инфосистемные проекты связаны с разработкой программного обеспечения, а профессионалы в области информационных систем являются либо непосредственными участниками, либо соучастниками этого процесса. Штат включает программистов-разработчиков, программистов-аналитиков, инженеров, которые ответственны за процесс тестирования программного обеспечения (или инженеров качества), системных аналитиков, аналитиков приложений, системных программистов, специалистов по аппаратному обеспечению во главе с руководителями и менеджерами проектов, а также некоторых специалистов смежных профессий, которые непосредственно не работают в области инфосистем, но тоже вовлечены в эти проекты.
Конечно, в принципе управление отделом разработки не отличается от управления любым другим подразделением компании, но, как показывает опыт, без учета особенностей этой сферы деятельности успеха не достичь.
Управление проектами по разработке программного обеспечения ставит своей целью вовремя выпустить качественный продукт, соответствующий заявленным в спецификации характеристикам, и при этом уложиться в отпущенный бюджет.
Грамотное управление подразумевает увеличение производительности труда, но с обязательным сохранением, а в идеале и улучшением качества выпускаемых систем. В свою очередь, улучшение качества, согласно аналитику из специальной группы ISSIG Project Management Institute Эдварду Демингу (Edwards Deming), всегда связано с соответствующим увеличением производительности.
Основная сложность разработки инфосистем состоит в том, что создаются уникальные интеллектуальные решения. Консультант ISSIG Луис Зеллс (Lois Zells) считает, что “в 9 случаях из 10 специалисты в области информационных систем работают над задачами, которые до этого ни они сами, ни кто-либо другой не выполняли. В отличие от каменщиков, десятилетиями кладущих одни и те же кирпичи одним и тем же способом, программисты не пишут одинакового кода”. Хотя концептуально это правильно, необходимо рассмотреть факторы, которые могут помочь, грубо говоря, привести работу программиста к работе каменщика.
При планировании проекта руководители вынуждены приспосабливаться к большой доле неопределенности. Чтобы было понятно, о чем идет речь, опишем кратко основные процессы планирования проекта, которое заключается в определении целей и критериев успеха проекта и в разработке рабочих схем их достижения:
Эта операция является наиболее важной в управлении проектом создания информационной системы, так как именно на этом этапе происходит снижение (именно снижение, а не устранение) той самой неопределенности, которая в конце концов оказывает прямое воздействие на сроки и стоимость проекта. В то же время степень детализации проекта должна зависеть от самого проекта и его сложности. Глупо требовать разбиения проекта вплоть до компонентов, которые содержат только одну строчку кода, но до функций или функциональных блоков, почему бы нет. Кроме того, необходимо требовать, чтобы разработке компонентов предшествовало ее проектирование с созданием проектного документа и обсуждением и принятием этого документа в команде проекта. Это только кажется, что конкретный исполнитель до конца понимает ту задачу, которую ему поручили, иногда даже руководитель проекта этого не понимает. Предварительное обсуждение перед непосредственным кодированием помогает снизить неопределенность и повысить вероятность исполнения задания по кодированию компонентов в предварительно объявленные сроки.
4.1. Детализация проекта и достижение полной ясности для ВСЕХ участников проекта по каждому компоненту проекта. Нельзя оценивать то, что никто не знает, ни как делать, ни что именно.
4.3. Соответственно, измерение производительности разработчиков приводит к селекции участников проекта, с целью создания команды из сотрудников, которые дают наиболее точные и соответствующие реальности оценки трудоемкости этапов;
Следующая особенность управления проектами по созданию информационных технологий заключается в их большом риске. Под “риском” в теории управления проектами понимается вероятность нежелательного результата, и обусловлено это может быть событиями различного характера: геофизического, политического, финансового и др.
В нашем случае к традиционным возможным задержкам инвестиций, прекращению аренды прежнего помещения и т. п. прибавляются субъективные причины, связанные с уникальным характером разработок, когда, к примеру, при увольнении выполняющей проект команды программистов проще заново разработать программу, чем разбираться в написанном коде. Это стандартное мнение о процессе программирования. Но руководитель должен строить свой проект таким образом, чтобы снизить риск подобного события. Для этого необходимо в рамках проекта выполнять следующие превентивные процедуры.
Борьба с риском осуществляется на стадии планирования проекта, где производится идентификация и оценка риска (определение и документирование событий, которые могут повлиять на проект и оценка вероятностей наступления событий, их характеристик и влияния на проект, соответственно), а также на стадии управления проектом.
При выполнении проекта очень важно организовать обратную связь между разработчиками и руководителем проекта с помощью периодических отчетов. Очень важно, чтобы создание отчетов об исполнении не зависело от погоды и состояния и настроения разработчиков. В отчетах должны содержаться информация о прогрессе исполнения той или иной задачи и, что весьма существенно, объяснение, почему та или иная задача была не исполнена в срок. Эта информация является ключевой для накопления статистики о производительности сотрудников и точности выдаваемых им оценок, а иногда свидетельствует о проблемах самого руководителя проекта, который неправильно организовал работу или не добился детализации и ясности проекта.
Несмотря на то что по науке перечисленные процессы относятся к вспомогательной группе, недостаточные усилия по снижению риска проектов в области инфосистем (уменьшения риска надо добиваться даже ценой увеличения трудоемкости) в основном и приводят к их провалам.
Решение коммуникационных проблем лежит в области налаживания стандартных процедур работы над качеством продукта. В отличие от создания самого продукта, процесс исправления ошибок в программе более формализуем, и оценки трудоемкости исправления могут быть очень точны (если уж здесь, на этом этапе, есть ошибки более 100%, то вам нужно менять отдел разработки). Стандартная процедура контроля качества может выглядеть, например, так:
Популярность современных компьютерных средств управления проектами растет, уже на протяжении ряда лет их использование перестало быть прерогативой крупных капиталистических магнатов, поскольку наряду с профессиональными дорогими системами, предназначенными, например, для регулирования строительства океанских лайнеров, самолетов или проектирования производственной линии химических препаратов появились универсальные продукты, ориентированные на пользователей настольных компьютеров, выполняющих более приземленные задачи. Сегодня на рынке такие продукты представлены в довольно большом ассортименте. Любое изобилие рождает проблему выбора, в данном случае она ложится на плечи менеджеров (или вышестоящего начальства), руководящих проектами в той или иной сфере.
Ниже остановимся на специфических требованиях, которым должны удовлетворять системы календарного планирования и контроля графиков выполнения работ корпоративных проектов по созданию и поддержке информационных систем.
Применяемые при создании инфосистем программные продукты календарного планирования должны учитывать неопределенность. Так, традиционные профессиональные пакеты оперируют с датами начала и конца каждой операции, однако, составляя расписание выполнения работ по проекту в области инфосистем, часто удобнее использовать относительные величины типа “сколько времени будет длиться операция”.
Отдельные программы позволяют вводить время с минимальным интервалом в сутки, для инфосистемных проектов это не годится, так как декомпозиция этапов должна быть буквально по часам.
Кроме того, обязательна возможность отслеживания выполнения работ не только по затраченным на ее исполнение рабочим часам, но и по проценту выполненного, поскольку эти величины не всегда находятся в прямо пропорциональной зависимости.
Очень важно, чтобы покупаемая система поддерживала постоянную корректировку курса и имела календарь ресурсов, объединяющий рабочее время всех сотрудников подразделения.
Поэтому весьма желательно, чтобы приобретаемая программа календарного планирования и контроля включала модуль управления риском, который позволяет автоматизировать эти процессы.
Для идентификации риска используются методы качественной оценки случайных событий; количественный анализ риска может быть выполнен с помощью различных инструментов: моделей риска, а также по метам Монте-Карло или PERT.
Для управления рисками также существуют специальные инструменты и технологии, одни из наиболее популярных: планирование случайностей (позволяет задавать многоуровневые ответные реакции на события риска), альтернативные стратегии (разработка действий по предотвращению событий риска) и другие.
Важность управления риском подкрепляется доказанными западными специалистами данными о том, что увеличение затрат на его анализ всего на 20% приводит к повышению вероятности успеха на 80%.
Используемая система управления проектами, как и любой универсальный продукт, должна обладать максимальной простотой и удобством применения. Здесь возможен компромисс, связанный с разницей целей руководителей и менеджеров проекта и его рядовых исполнителей.
Первые отвечают за реализацию проекта в целом, определяют приоритеты заданий и направлений работ, разрешают конфликты ресурсов и разрабатывают финансовую стратегию, поэтому им необходим достаточно мощный инструмент, соответствующий их целям и задачам (с возможностями анализа альтернативных планов, генерации наглядных отчетов и т. п.). Последним может быть целесообразно использовать упрощенный инструмент для планирования и контроля своей деятельности, который, правда, должен быть интегрирован в общую систему управления проектами.
TimeSlip (Computer Associates) первоначально был разработан с целью помочь юристам отслеживать затрачиваемое на клиентов время, которое, собственно, последние и оплачивают. Программа интегрирована с Super Project.
Вообще важно, чтобы все продукты, используемые как менеджерами и руководителями, так и рядовыми сотрудниками, обеспечивали единый стандарт управления проектами, т. е. одинаковое представление данных, отображение организационной, технологической и информационной структур, подходы к декомпозиции проекта, отчетные формы, стандартные обозначения.
Возможность интеграции в общую корпоративную информационную систему является абсолютно необходимым требованием к программным средствам для управления проектами. Имеется в виду совместная работа с используемыми на предприятии средствами ввода данных, системами электронного документооборота, управления документами, офисными программами.
Электронная почта используется повсеместно для обмена данными.
По сравнению с ней, системы автоматизации деловых процессов и контроля исполнения заданий пока используются реже, однако, учитывая требования к значительной интенсификации и четкой организации работы каждого сотрудника для достижения предприятием коммерческого успеха, предвидится их быстрое распространение.
Поэтому надо обращать внимание на открытость систем управления проектами, их совместимость со стандартами ODBC, OLE, DDE, наличие внутренних языков программирования и готовых макросов, облегчающих интеграцию с другими программными средствами поддержки деятельности предприятия.
В заключение хотелось бы отметить, что важно не только какой продукт использовать, но и как. Никогда нельзя упускать из глаз общую картину проекта. По мнению директора компании Time Line Дэвида Блэра (David Blair), 15% неудачных внедрений систем автоматизированного управления проектами в области разработки инфосистем связано с непониманием того, что собой представляет проект в целом. “Без этого нельзя сказать, как применять тот или иной инструмент”.
Автоматизация хаоса, или Записки консультанта
Ты скажи, че те надо.
Что требуется от корпоративной информационной системы? Заказчики формулируют это по-разному. Как правило, называют самые наболевшие проблемы: на кого налоговая наезжает из-за ошибок в отчетности, где-то себестоимость не известна, кому-то при затоваренном складе не удается обслуживать покупателей из-за отсутствия запасов нужной продукции. Заказчики сетуют на необходимость планирования финансовых потоков, на потерянные документы и сорванные поставки. Часто начальнику хочется постоянно видеть результаты работы подчиненных. Некоторые особо продвинутые пользователи жаждут иметь трехуровневое приложение с монитором транзакций и Java-сервлетами вместо их старенькой программы на FoxPro.
Предельным выражением этой функции является технологии WorkFlow, когда система наделяется знанием не только о том, что должно быть сделано, но и кем и в какой последовательности. Правда, в условиях «хаоса» WorkFlow умирает первой, и в реальной российской жизни эта технология мало применима.
Бухгалтер, милый мой бухгалтер.
Подавляющее большинство заказчиков в качестве основной цели внедрения информационных технологий указывает именно автоматизацию учета.
Хотя и управленческий, и бухгалтерский учет в основном имеет дело с одними и теми же первичными хозяйственными операциями, способы их отражения существенно различаются. Управленческий учет отличается от бухгалтерского так же, как финансовый директор от главного бухгалтера (см. врезку).
| Различия управленческого и бухгалтерского учета Имеются и другие различия. Например, для управленческого и бухгалтерского учета используются разные планы счетов и наборы проводок при отражении одних и тех же хозяйственных операций. |
Множество проблем при автоматизации учета возникает оттого, что заказчик часто не понимает этих различий. При отсутствии управленческого учета именно бухгалтерия является не очень качественным, но единственным источником финансовой информации. Поэтому руководители, испытывая недостаток оперативных данных, требуют их у бухгалтерии. Бухгалтерия же дать их не может, и задача постановки управленческого учета формулируется как улучшение работы бухгалтерии. Во многих случаях разработчики на это покупаются и начинают автоматизировать работу бухгалтерии. Тогда на объективную сложность создания системы накопления первичной информации накладывается задача отображения операций в бухгалтерские проводки, сама по себе весьма сложная и плохо формализуемая.
В результате разработка начинает буксовать, и за разборками с главным бухгалтером приходится забыть про высокую цель создания общего информационного пространства и отстреливать все, что не относится к выходу на баланс.
А главный парадокс этой ситуации заключается в том, что даже если героическими усилиями бухгалтерию удается автоматизировать, то руководитель все равно недоволен, так как не получает того, что ему на самом деле было нужно!
Разумным подходом является корпоративная система, реализующая накопление всей первичной информации с выходом на управленческий учет и последующий экспорт данных в бухгалтерскую программу. Но на практике таким образом удастся автоматизировать отнюдь не весь бухгалтерский учет, а только рутинную часть работы бухгалтерии, связанную с отражением основной производственной деятельности и составляющую около 80 процентов от числа проводок. Остальные факторы, влияющие на финансовую отчетность, даже если они и попадают в информационное пространство системы, проблематично автоматически отразить в бухгалтерском учете, поскольку на него сильно влияют быстро меняющиеся и трудно формализуемые соображения (вроде минимизации налогов в свете новой инструкции о переоценке основных фондов).
Покажи мне свои данные, и я скажу, что тебе надо
Существует много толстых книжек, описывающих, как надо «по науке» разрабатывать информационные системы. Как правило, там сказано, что нужно проанализировать функции автоматизируемого объекта и отдельных подсистем. Далее определяются функции конкретных типов рабочих мест и потоки данных и управления между ними. Затем специфицируются хранилища данных и способы доступа к ним для каждого рабочего места, все формализуется, и уже затем осуществляется кодирование.
Этот подход, сложившийся на Западе в 70-е годы, успешно применялся для автоматизации больших консервативных корпораций, работающих в стабильных условиях. Более того, на том уровне развития инструментария, когда любой элемент пользовательского интерфейса и любой запрос к данным нуждался в кропотливом и трудоемком программировании, иначе действовать, вероятно, было нельзя. Но с тех пор изменилось довольно многое. Жизнь стала гораздо более динамичной. Разработки, длящиеся год и более, что было нормальным явлением в 70-80-е годы, в современных условиях недопустимы. Вырос уровень инструментальных средств. Все современные CASE- и RAD-средства давно перешагнули уровень «языков 4-го поколения». Реляционные СУБД кардинально упростили реализацию запросов к данным. Фактически, все современные системы являются именно макетами в понимании «быстрого прототипирования» 80-х.
Традиционный подход «от функций» в нашем сегодняшнем хаосе работает плохо: как правило, функции плохо формализованы, а структура организации и распределение обязанностей зачастую меняются быстрее, чем разрабатывается система.
Очень часто в процессе обследования становится ясно, что автоматизировать существующие способы выполнения операций нельзя, но при этом непонятно, удастся ли реорганизовать работу фирмы. Причем для разных вариантов будущей организации бизнес-процессов мы получим различные проекты информационной системы.
Правда, реальные данные имеют, как правило, более сложную структуру, чем таблицы Excel или плоские файлы Notes. В «честной» модели предметной области появляется много разных типов объектов и отношений между ними, изменяющихся во времени. Поэтому требуются более сложные средства моделирования. В начале 80-х на реализацию подобной концепции стали претендовать реляционные СУБД. Очень популярны были декларации о «программирования без программиста», основанные на использовании реляционных моделей и QBE (Query By Example) в качестве среды для работы пользователя. Все оболочки популярных настольных систем (от dBase II до Access) разрабатывались именно исходя из этой парадигмы. Если вспомнить, так даже SQL создавался не как стандартный способ взаимодействия с серверами баз данных, а как язык запросов, ориентированный на неквалифицированного пользователя!
Но жизнь показала, что последний не способен воспринять сколько-нибудь сложную реляционную модель данных. Конечно, существует класс задач, для которого база данных в стандартной оболочке Access может использоваться достаточно квалифицированными пользователями как информационная модель предметной области, но разрабатывать таким способом корпоративную информационную систему может прийти в голову только в кошмарном сне.
При проектировании «от данных» ядро системы разрабатывается как специализированный редактор данных. При этом значительная часть бизнес-логики системы уходит на уровень поддерживаемых системой связей между данными, специфических ограничений целостности и специальных операций редактирования.
Такая простая функция, как суммирование указанных полей по текущей выборке, покрывает огромное множество запросов типа «А сколько у нас. «, каждый из которых при функциональном подходе пришлось бы описывать отдельно.
Конечно, нельзя надеяться, что при разработке корпоративной информационной системы удастся ограничиться реализацией информационной модели. Унифицированные интерфейсные решения удобны далеко не для каждого случая. Кроме того, некоторые типичные операции могут потребовать более одной операции ввода/редактирования данных. Поэтому для самых массовых или критических по времени операций и запросов могут потребоваться специальные интерфейсы. Как правило, не удастся избежать и реализации специализированных отчетов. Рано или поздно придется наделять систему активностью, чтобы обеспечивать контроль исполнения и отработку отложенных или массовых операций.
Но прелесть этого подхода заключается в том, что ядро системы в виде модели предметной области уже готово к работе, при этом дополнительную бизнес-логику можно подключать после запуска системы в эксплуатацию. Кроме того, разумная организация данных стимулирует возникновение разумных способов работы с ними и позволяет осуществлять некий «ползучий» реинжиниринг бизнес-процессов, когда старые процессы отмирают за очевидной абсурдностью, а новые возникают как бы сами собой.
Отдельно стоит рассмотреть реализацию объектов, характерных для учетных задач. Как правило, в процессе выполнения операций нам нужно накапливать некоторые итоговые числовые данные. Это может быть количество товаров на складе, начисленная работнику зарплата, число акций, принадлежащих акционеру, остаток на расчетном счете предприятия и т. д. В принципе все эти цифры (следуя бухгалтерской лексике, остатки) однозначно следуют из имеющихся у нас первичных данных и могут быть получены путем генерации соответствующих отчетов, но в реальных системах это обычно неприемлемо из-за того, что смотреть на эти итоговые цифры нужно постоянно, а генерация отчетов требует значительного времени.
Потому типичным является решение, когда ввод и редактирование данных об операциях автоматически сопровождается изменением значений остатков.
В остатках нас, как правило, интересует не только текущее их значение, но и значения на прошлые даты, а также динамика их изменения. Поэтому для развязывания логики операций и динамики остатков обычно вводят понятие, которое, по аналогии с бухгалтерией, будем называть проводками (датированная запись, описывающая элементарное изменение одного [полупроводка] или двух [полная проводка] остатков, содержащая ссылку на инициировавшую данную проводку операцию). При этом остатки могут изменяться только проводками, и при такой конструкции откатка/накатка остатков, анализ их динамики за период вообще не требуют знания логики операций.
| Отец реляционной алгебры Кодд в начале 90-х выдвинул новую идеологию, названную им OLAP (On-Line Analytical Proceeding). Моделью данных для поддержки OLAP является многомерный куб, где на измерениях определены некоторые иерархии, а в клетках этого куба находятся числовые значения. Например, динамика рынка ценных бумаг хорошо описывается измерениями Инструменты, Торговые площадки, Дата-время и Параметр (цена спроса, цена предложения, цена последней сделки, объем и др.), а значение параметра находится на пересечении этих измерений. Единичный факт (точка) выглядит, например, как «обыкновенные акции «Мосэнерго» на РТС имели 8 августа 1998 года в 15:00:00 bid (цену покупки) 1 цент». Операции извлечения данных из такого куба описываются в терминах поворотов, срезов и иерархического «схлопывания» измерений с агрегированием значений (суммирование, взятие среднего и др.). Эта метафора хорошо ложится на табличную организацию пользовательского интерфейса. Имеется также вариант этого подхода, называемый ROLAP (Relational OLAP), когда данные хранятся в реляционных базах данных, а работа с ними идет в OLAP-методологии и интерфейсе. Более того, последние версии SQL-серверов, например Oracle8i, содержат специальную поддержку характерных для OLAP способов организации данных, за счет чего их производительность на OLAP-задачах приближается к производительности специализированных хранилищ данных. |
Сейчас появилось довольно много модулей, обеспечивающих OLAP-подобные интерфейсы, и я очень рекомендую пользоваться ими для визуализации данных машины проводок.
Существует интересный психологический феномен. Часто человек, успешно сделавший нечто трудоемкое и значимое, извлекает из этого своего опыта некоторые очень общие и важные для него принципы и именно их воспринимает как главный результат своей деятельности. Но когда он пытается пересказать их окружающим, его энтузиазм вызывает легкое удивление, так как для подавляющего большинства эти принципы очевидны.
Проблема состоит в том, что для говорящего они наполнены конкретным содержанием, поскольку пропущены через его жизненный опыт, которого нет у окружающих. Поэтому для них эти принципы столь же тривиальны, сколь и бесполезны. И все же я надеюсь, что какие-то из изложенных мною соображений окажутся полезными людям, не имеющим подобного моему профессионального опыта.
