Статья только в электронной версии журнала
Александр Сомов
Новое -это хорошо забытое старое
Мадемуазель Бертен,
модистка Марии Антуанетты
Убедительная просьба к читателям - все неустановленные ссылки относить к Адаму, так как эта тема обсуждалась столь большим числом светлых умов, что без повторов обойтись просто нельзя. Со времен зари человечества люди постоянно занимаются разработками и попытками осуществления проектов самого разного рода и масштаба. Это почтенное занятие, такое же древнее как “самая древнейшая профессия”, являет собой на самом деле очень сложную работу. Не затрагивая проблем, связанных с проектами в различных сферах человеческой деятельности, остановимся лишь на проектах автоматизации информационных систем управления.
Эдвард Йордан - классик в области инженерного проектирования - в своей книге [1] дает определение безнадежного проекта как проекта, отклоняющегося от нормы более чем на 50%. По данным из других источников, таких проектов чуть менее половины от общего числа. Воистину весь мир сошел с ума. Иллюстрацией может служить серьезное обсуждение в американской прессе проекта полета на Марс космонавтов с запасом воды и пищи на 40 лет и без грамма горючего (!) на обратный полет.
Проекты в области создания программного обеспечения (ПО) зачастую очень похожи на приведенный выше, но обсуждают их не столь широко. Результаты же ввергают заказчика в шоковое состояние, из которого он долго не может выкарабкаться.
Очередная волна заинтересованности в овладении дисциплиной управления проектами в области создания автоматизированных информационных систем (первая пришлась на начало 70-х годов) связана прежде всего с качественно неудовлетворительными результатами в этой области, несмотря на лавину заявлений, что светлое будущее наступит уже завтра.
В России изменение экономических отношений добавило ряд как положительных факторов (появились дополнительные рычаги управления), так и отрицательных (смещение главной цели в сторону прибыли - начальный этап накопления капитала).
Что такое проект
Если какая-нибудь неприятность может случиться, она случается
(Закон Мэрфи)
Проект - временное предприятие, предназначенное для создания уникальных продуктов или услуг. Такое определение подходит для любого проекта в любой сфере человеческой деятельности. Тем не менее методы управления, успешно применяющиеся в других областях, в области управления разработки ПО могут привести к катастрофическим последствиям [2]. Например, осуществляя проект рытья котлована, можно, в случае отставания от графика, привлечь дополнительное число землекопов. Попробуйте повторить это при разработке ПО, и вы получите результат как при тушении пожара бензином. Решая задачи автоматизации, нельзя также забывать о принципе заинтересованности первого лица. Моральное состояние коллектива на всех этапах жизненного цикла проекта хорошо проиллюстрировано в книге Р. Гантера [4].
Итак, управление автоматизацией проектирования включает в себя следующие функции:
Слева приведены основные фазы, общие для проектов; справа - несколько уточненные для проектов по разработке ПО.
Что имеем, не храним, потерявши, плачем
Любые предложения люди понимают иначе, чем тот, кто их вносит.
(Третий закон Чизхолма)
Человека постоянно не отпускает чувство, что где-то там “за горизонтом” или “за поворотом” идет настоящая насыщенная жизнь, а здесь вокруг него все не так. И специалисты наши, конечно же, не те, что в столицах. И вот приглашают сторонних консультантов и платят им большие деньги за те рецепты, которые не хотели получать от своих местных. Затем нанимают сторонних шабашников (порой с громкими именами) - и совместно с ними разрушают существующую информационную систему. Стороннему специалисту все равно, что будет потом, он заинтересован в собственных валовых показателях, поэтому настроен максимально разрушить существующую систему и внедрить современную на уровне лучших мировых стандартов, включая и стоимостные. Последними доистребляются собственные кадры, и они уходят. При внедрении новой системы вдруг выясняется, что “чужаки” совершенно не знают предметной области вашего бизнеса. Они сначала теряют лоск и уверенность, а затем куда-то исчезают, произнося при этом какие-то мудреные заклинания на компьютерном жаргоне. И вот вы опять наедине с проблемой...
Чудес на свете не бывает
Неважно, что что-то идет неправильно.
Возможно, это хорошо выглядит...
(Первый закон Скотта)
Наша вера в чудеса пришла к нам из детства. Жизнь постоянно учит нас, что если чудеса и бывают, то не с нами. Но мы продолжаем верить в существование простых решений для сложных проблем. И вот появляется сладкоголосый представитель зарубежного “кудесника” и обещает нам за три месяца построить классический капитализм на нашем отдельно взятом предприятии. В эти моменты нам удается забыть и разбитые цеха, и голодных работников, и все, все, все... Но за все надо платить, и когда “кудесник” называет свою цену, опытный руководитель трезвеет и вспоминает, чему учила его жизнь.
Широко шагать - портки порвешь
Все, что хорошо начинается, кончается плохо.
Все, что начинается плохо, кончается еще хуже.
(Закон Паддера)
Причина этих неприятностей кроется, главным образом, в попытках “поскорее догнать” и в уповании на революционные изменения. Весь наш житейский опыт учит, что в большинстве случаев ничего не происходит неожиданно и всякое событие можно предвидеть. Но в своей производственной деятельности мы слишком изуродованы “образованщиной” и легко доверяем нескольким страницам малопонятных, но солидных выкладок при всей видимой несуразице предлагаемых нам выводов. Нас еще в общеобразовательной школе при решении задач приучили, что “формула всегда права”.
К настоящему времени накоплено достаточно много положительного опыта в области реализации проектов. Его правильное использование может значительно уменьшить риск провала, по крайней мере тогда, когда проект изначально не попадал в область проваленных. В управлении проектами используются численные методы (например, расчет численного состава или производительности труда) и сетевые графики. И те и другие относятся к жестким методам управления. Но значительным шагом вперед стало осознание огромного влияния на выполнение проекта человеческого фактора (мягкие методы управления). Искусное сочетание мягких и жестких методов управления позволяет получать результаты значительно лучшие, чем при применении одного из них. Болезнь “левизны” характерна лишь для начинающих управленцев-школяров.
Менеджер проекта должен обладать определенными полномочиями. Если полномочий для выполнения проекта не хватает, то менеджер начинает действовать по схеме: есть начальник, он скажет - мы сделаем, если что и не так, то мы не виноваты... (продолжение очевидно: “Жираф большой...”). В случае, когда у менеджера очень большие или даже абсолютные полномочия, за проект можно не волноваться, он будет выполнен любой ценой. Но такая ситуация чревата для фирмы негативными последствиями. Например созданием внутренней биржи труда, которая поставляет людей для проектов. Здесь ситуация предельно простая: спросом пользуются только высококвалифицированные специалисты, остальные в конце концов уходят. А специалисты, поработав в таком изматывающем режиме, через пару лет заметно отстают от современного уровня из-за простой нехватки времени на повышение своей квалификации. Потогонная система такого рода без притока свежих сил практически исключает возможность профессионального роста. Поэтому власти у менеджера проекта должно быть столько, сколько нужно для нормального завершения проекта, и не больше. Это та золотая середина, которую все ищут.
Реальная жизнь заставляет работать с теми, кто есть, нельзя полагаться на то, что завтра вдруг придет кто-то и все решит. Руководитель должен формировать коллектив, заботиться о повышении квалификации всех работников и пестовать из них гениев, если хотите. Уже давно не секрет, что производительность двух программистов может различаться почти на два порядка.
Загрузка специалистов разной специализации на разных стадиях проекта сильно варьируется. Поэтому небольшой коллектив разработчиков способен одновременно вести несколько проектов, смещенных во времени. Это очевидно, но далеко не всегда используется. Нельзя только забывать, что ряд специалистов должен быть задействован в проекте на всем его жизненном цикле, даже в период промышленной эксплуатации. Это менее очевидно, но на деле получается именно так. Если находится ошибка, то это - всегда предпоследняя ошибка, и ее нужно исправлять.
Кроме того, у руководителя должен быть резерв для маневра - на случай отпусков, болезней и увольнения сотрудников. Как тут не вспомнить еще одну крылатую фразу: “Кадры решают... ну, почти все”.
Наиболее целесообразно работать с переменным составом специалистов, это могут быть как сотрудники вашей организации, так и привлекаемые специалисты внешних фирм. Последние подключаются на нужном этапе, выполняют требуемую работу, документируют ее. После чего их можно привлекать к другому проекту, так как в этом доля их участия резко сокращается.
Объять необъятное
Нельзя заранее правильно определить,
какую сторону бутерброда мазать маслом.
(Закон своенравия природы)
Существует два подхода к решению задачи автоматизации: метод “шахт” и метод “пластов”. Первый предполагает решение одной конкретной задачи (подсистемы), практически оставляя без внимания другие. Положительные стороны: заказчик получает решение в разумные сроки и платит за него разумные деньги. Отрицательные - отсутствие связи с другими задачами (подсистемами), что может потребовать коренной ломки уже сделанного. Второй подход обеспечивает системное решение всей задачи автоматизации, но при этом сроки реализации крайне туманны, а сумма затрат впечатляющая. На практике ни тот, ни другой подходы не применяются в чистом виде. Реальная жизнь в нашем изменчивом мире требует грамотного комбинирования этих двух подходов.
Итак, любой проект начинается с определения целей. На этом этапе рождается документ, в котором формулируются цели проекта, служащие основой (базой) для всех последующих проектных решений. Документ кроме самих целей содержит оценку стоимости, оценку рисков, оценку затрат ресурсов, т. е., другими словами, оценку осуществимости. Если она удовлетворяет и заказчика, и исполнителя, то в документе фиксируется принятие решения о начале работы по проекту.
План, план и еще раз план...
Неточно спланированная программа требует в три раза
больше времени, чем предполагалось;
тщательно спланированная -только в два раза.
(Из законов мира ЭВМ по Голубу)
Любой проект имеет свой жизненный цикл. Хороший разработчик должен представлять все метаморфозы, происходящие с его детищем. Уместно отметить, что термин “бизнес-план” пришел к нам не из планово-распределительной экономики, а “оттуда”...
Планы создаются под реальные ресурсы (под ресурсами здесь понимается все, что требуется для решения задачи: финансы, люди, техника, время и пр.) Никогда нельзя оправдывать отсутствие плана тем, что он, как правило, не выполняется, или цейтнотом.
Само по себе организационное управление не является полностью детерминированным. Всегда существует неопределенность события и, естественно, есть риск, связанный с наступлением того или иного события или с его ненаступлением. План должен быть всегда. Планировать с учетом случайных факторов - непростая задача. Тем более когда постоянно чувствуешь давление со стороны начальства, желающего исключить все случайности, т. е. свести разработку к полностью детерминированному процессу.
Планирование “в большом” - стратегическое, планирование “в малом” - тактическое. Стратегический план должен отвечать на вопросы “что” и “когда”, тактический - на вопрос “как”.
Процесс планирования состоит из ряда подпроцессов:
- планирование бюджета
- формирование организационной структуры
- планирование и декомпозиция работ
- планирование использования ресурсов
- управление рисками
- управление качеством
- другие вспомогательные процессы
“Пилотный” проект: когда он необходим
Число гипотез, объясняющих данное явление,
обратно пропорционально объему знаний о нем.
(Теория Эдингтона)
Пилотный проект позволяет в кратчайшие сроки показать заказчику, что он будет иметь и чего он ни в коем случае не будет иметь после реализации задачи. Его создание сближает разработчиков и заказчиков - непосредственно тех, кто в дальнейшем будет эксплуатировать систему. Позволяет формализовать те “местные” особенности, которые при формальном обследовании могут быть упущены. Короче говоря: идет сближение позиций. Именно пилотный проект показывает, что самое правильное, когда и исполнитель, и заказчик ориентированы на конечный результат. Желательно, чтобы эта ориентация сохранялась и при выполнении основного проекта.
Ниже рассмотрим более подробно некоторые этапы выполнения программного проекта.
Функциональный анализ
Внутри каждой большой задачи сидит маленькая,
пытающаяся пробиться наружу.
(Закон больших задач Хоара)
Этот этап во многом решает судьбу проекта. Именно на этой фазе ошибки дороже всего обходятся заказчику. Именно в это время участие заказчика в проекте определяет точное его исполнение. На этом этапе уточняется бюджет проекта, определяется выбор программных и аппаратных средств, уточняется потребность в ресурсах. Именно на этом этапе происходит уточнение целей (виды целей), планируются работы и распределяются финансовые ресурсы по фазам проекта.
Алгоритмическое представление задачи
Ни один талант не может преодолеть пристрастия к деталям.
(Восьмой закон Леви)
Обычно этот этап характеризуется максимальной активностью разработчиков. В это время происходит последовательная детализация способов решения задачи, формируются данные для испытания системы и ее характеристик. Это - внутренняя работа, если можно так выразиться. Как правило, ее выполняют сами разработчики. Риски на этом этапе очень высоки. Руководитель не застрахован от событий, которые способны повлиять на сроки выполнения дальнейших этапов проекта. Иногда возникает ситуация, когда невозможно определить формальное (читай: математическое) решение (достаточно редко), в этом случае могут быть изменены цели проекта или способы решения задачи. (То есть эта часть работ перекладывается на человека и не подлежит автоматизации.)
Моделирование структур данных
Всегда не хватает времени, чтобы выполнить работу как надо, но на то,
чтобы ее переделать, время находится.
(Закон Мескимена)
Человек, имеющий одни часы, твердо знает, который час.
Человек , имеющий несколько часов, ни в чем не уверен.
(Закон Сегала)
Для выполнения этой работы должны привлекаться специалисты самой высокой квалификации, так как модель данных разрабатывается с учетом развития системы и предполагает в дальнейшем осуществление целого ряда проектов. Моделирование проводится после того, как определены основные требования и к проекту, и к коллективу, и к методам реализации. Здесь закладывается база для функционального расширения задачи. Реляционная модель скоро отметит свое 30-летие. О нормализации данных и ее пользе слышали уже все. Но обследование баз данных у заказчика, как правило, выявляет 5 - 7-кратное дублирование данных. Во многих случаях причина кроется в использовании dbf-формата и попытке любой ценой увеличить скорость получения результата. И такое встречается настолько часто, что молчать об этом нельзя. Преобладание на рынке реляционных СУБД совсем не означает, что для какого-то проекта она будет лучшим выбором, возможно, таковым может стать сетевая или иерархическая СУБД. Выбор определяется целями - финансовыми, временными и др. Типичное поведение в условия ограниченных ресурсов.
Программирование и отладка. Тестирование
Нет невыполнимой работы для человека,
который не обязан делать ее сам.
(Закон Вейлера)
Если бы строители строили здания так же,
как программисты пишут программы,
первый залетевший дятел разрушил бы цивилизацию.
(Второй закон Вейлера)
Эти процессы наиболее понятны. Но все же скажем несколько слов и о них. Проблемы, которые сопровождают нас со времен создания первой программы, кроются в постоянном снижении качества программного обеспечения, ранее считавшегося чуть ли не эталонным: операционные системы, трансляторы и пр. Суть этого уже была высказана в прессе: “Мы живем в мире (-версий”. А далее делается вывод, что виноваты в этом сами пользователи, идущие на поводу у фирм-производителей, навязавших нам такие правила игры. Кроме того, проблема еще и в том, что одни задачи хорошо решаются с помощью одного вида программного обеспечения, другие - другого, но интерфейс между ними или очень сложен, или его нет вовсе. Сюда могут быть добавлены проблемы, вытекающие из использования разного аппаратного обеспечения. И только немногие фирмы берутся сегодня за поиск способа увязать все это вместе.
Документирование и документооборот. Стандарты
Работающая над программой группа питает отвращение
к еженедельной отчетности о достигнутых результатах,
поскольку она слишком явно свидетельствует об отсутствии таковых.
(Из законов мира ЭВМ по Голубу)
О пользе документирования немало сказано и написано, тем не менее именно эта работа или вовсе не выполняется, или выполняется крайне неудовлетворительно. Но документирование - это не та область, на которой можно экономить. Несмотря на большой объем работ, связанных с документированием, их надо выполнять. И при выполнении необходимо руководствоваться стандартами. Многие специалисты грешны по отношению к стандартам. Программисту бывает проще написать еще десяток модулей, чем документацию к одному. Это - жизнь. Возможно, наиболее правильное в этой ситуации - не заставлять программиста делать всю работу до конца, а использовать его рабочие материалы для того, чтобы другой специалист, которому легко дается создание читаемых документов, сделал окончательную документацию. По поводу отечественных ГОСТов ничего плохого сказать нельзя, но выполнять их из-за отсутствия методик крайне затруднительно. Из собственной практики: пока не нашлась переведенная книжечка-учебник, многие параграфы ГОСТа на “техническое задание” вызывали тоску при их заполнении.
Следующие три вида работ относятся к стадии окончания проекта. Тем не менее расслабляться еще рано. Время великих потрясений еще не прошло.
Внедрение задачи
Нетрудно свести лошадь к воде.
Но если вы заставите ее плавать
на спине -вот это значит, что вы чего-то добились!
(Первый закон Хартли)
Внедрению всегда должна предшествовать разработка комплекса организационно-технических мероприятий. Именно они определяют ключевые события, связанные с обучением персонала заказчика, планированием сопровождения задачи, распределением ресурсов и, наконец, планированием развития системы. К этому времени должна быть подготовлена вся документация, зафиксированы все полученные результаты по проекту, в том числе и негативные. В этот момент начинается расформирование проектного коллектива. А сам проект, точнее, результаты, передаются, как эстафетная палочка, от исполнителя заказчику.
Опытная эксплуатация задачи
Человек время от времени спотыкается о правду,
но чаще всего он вскакивает и бодро продолжает идти.
(Комментарий Хансена относительно человека)
Этот этап должен быть достаточно продолжительным, чтобы можно было отработать достаточно большое число реальных событий и ситуаций.
На данном этапе от заказчика требуется мобилизация дополнительных человеческих ресурсов, так как должны функционировать как старая, так и новая системы (для сравнения результатов их работы). Этап завешается тогда, когда заказчик (пользователь) оценивает результаты работы новой системы как удовлетворительные.
Промышленная эксплуатация и сопровождение
Никогда не пытайтесь повторить удачный эксперимент.
(Закон лаборатории Фета)
Создайте систему, которой может пользоваться даже дурак,
и только дурак захочет ею пользоваться.
(Принцип Шоу)
На этом этапе прекращает жизнь старая система и начинает работать новая. Именно здесь оптимизм пользователя может смениться пессимизмом из-за каких-либо отклонений в работе системы, не выявленных на этапе опытной эксплуатации. Тем не менее проектный коллектив уже расформирован. Сопровождение системы может вестись как силами заказчика, так и исполнителя. Сторона, осуществляющая сопровождение, определяется соответствующим документом. Если сопровождение системы осуществляет заказчик, то объем передаваемой документации сильно возрастает (например, исходные тексты программ), что обычно влияет на стоимость проекта в целом. Если сопровождение осуществляет исполнитель, в проектах, выполняемых одновременно с сопровождением, должны вноситься корректирующие поправки на возможность отвлечения части ресурсов на работы по сопровождению. Финансирование сопровождения может закладываться как в проект, так и в отдельный договор. Эта деятельность относится к управлению контрактами.
Планирование финансов и риски
Все можно наладить, если вертеть в руках достаточно долго.
(Второй закон Вышковского)
Бесплатная работа отошла в небытие. А любой бизнес сопровождается риском. Разумная политика в области финансирования проектов - это и наука, и искусство. Ей нужно учиться, в том числе, к сожалению, и на собственных ошибках. Риски сопутствуют проекту на всех его этапах. Может быть, отечественного читателя утешит тот факт, что и там, где к автоматизации подходят более масштабно, ситуация ненамного лучше. Так, по данным Earl Hadden&Assosiates, до 80% корпоративных хранилищ данных (data warehouse) не решают всех поставленных перед ними задач. Почти половина из их числа - практически полностью проваленные проекты. Чем сложнее становится структура данных, тем менее эффективны (в смысле времени выполнения) приложения. Обеспечить эффективную работу можно только для очень ограниченного числа приложений, и, как правило, за счет понижения эффективности других. Такова жизнь. Человек всегда ставит такие задачи, которые трудны для сиюминутного решения.
Как уже понял внимательный читатель, риск сопровождает проект на всем его жизненном цикле. Поэтому основные работы менеджера проекта связаны с планированием рисков, учетом исполнения, т. е. учетом рисков, которые не произошли и уже не произойдут. По возможности необходимо иметь программу реагирования на наступление события, связанного с риском. Выполнение такой программы должно быть направлено на сведение нежелательных последствий к минимуму. Беспечность и неготовность менеджера к наступлению негативных событий может привести к провалу проекта, который в других условиях был бы выполнен. Опыт поведения в негативных ситуациях и принятия правильных решений бесценен.
Отметим, что в силу эмпирического характера управления проектами многого ожидать от программных средств поддержки автоматизации управления проектами не приходится. Несмотря на достаточно высокую стоимость, реальная польза заканчивается красиво оформленной информацией по проекту (диаграммы Ганта, графики использования ресурсов, сетевые графики) и расчетом затрат с информацией об их нехватке (просьба не воспринимать как антирекламу).
Заканчивая на такой минорной ноте, тем не менее надеемся, что данная публикация поможет избежать хотя бы части ошибок в нелегком труде управления автоматизацией управления.
Заключение
Работая над решением задачи, всегда полезно знать ответ.
(Правило точности)
В заключение позволим себе отметить, что мы специально не указывали в каждом пункте средств для автоматизации той или иной деятельности, в том числе и средств автоматизации управления проектами. Этих средств очень много. Факторов, влияющих на их выбор, тоже достаточно много: от стоимости продукта до привычек специалистов. Не секрет, что нами руководят наши же привычки. Главное, чтобы эти средства действительно помогали решать поставленную задачу.4
Литература
E. Yourdon. Death March. The Computer Software Developers’s Guide to Surviving “Mission Impossible” Projects. Prentice Hall, 1997.
Ф. П. Брукс мл. Как создаются программные комплексы. Москва, Наука, 1979.
К. Кастеллани. Автоматизация решения задач управления. Москва, Мир, 1982.
Р. Гантер. Методы управления проектированием программного обеспечения. Москва, Мир, 1981.
Мир управления проектами. Под редакцией Х. Решке, Х. Шелле Аланс. Москва, 1994.
В. И. Либерзон. Основы управления проектами.
А. Сомов - ведущий специалист компании “Софтсервис ССП”. К нему можно обратиться по телефонам: (095)333-6310, 128-9314, 128-1821, по
E-mail: somov@softexpress.ru или через Интернет: http://www.softexpress.ru.
