Ресурсы и объем работ по подготовке технического задания

Размер банка	Количество выделенных для постановки задачи аналитиков	Примерное время для завершения этапа с учетом согласований	Примерный суммарный объем задания в страницах, с учетом комментариев
Небольшой	2-3	1 — 2 месяца	100-150
Средний	4-5	3 месяца	200-300
Крупный	6-8	4 — 5 месяцев	350-500

Вне зависимости от модели организации работы на проекте и степени вовлеченности внешних консультантов в проект с самого начала необходимо организовать регулярное и эффективное взаимодействие проекта с высшим руководством организации. Это позволит облегчить принятие требуемых решений, будет способствовать повышению статуса проекта, явится источником дополнительной мотивации и повышения ответственности участников проекта. Реализация такого взаимодействия обычно происходит в следующих формах.

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

Спонсорство — важный элемент проекта. Для проекта должен быть назначен спонсор (куратор), лицо из высшего руководства, один из членов проектного комитета, обычно близкий бизнес-подразделениям, который будет более активно взаимодействовать с менеджером проекта для помощи и консультирования. Он должен быть представителем руководства, уполномоченным принимать любые решения, который будет больше всех других высших менеджеров организации в курсе хода проекта и его проблем. Обычно это человек, который выступал инициатором проекта среди руководства или поддерживал его с самого начала.

Периодическая отчетность. Руководитель проекта должен готовить для информирования всех заинтересованных сторон о ходе работ специальные отчетные формы. Периодичность их зависит также от состояния проекта, но в общем должна быть чаще, чем заседания проектного комитета. Может быть рекомендована следующая схема. Если проект испытывает сложности, имеет место срыв сроков, недостаток бюджета и т.п., то отчетность должна предоставляться еженедельно. Если проблемы у проекта есть, но не очень значительные, отчетность составляется раз в две недели. И если у проекта нет каких-либо проблем, способных повлиять на срок, бюджет, то раз в месяц. В отчетах должен быть в удобной форме отражен текущий статус проекта, этап и его фаза, основные ближайшие контрольные точки, выполненный по сравнению с предыдущим отчетом объем работ, достижения проекта за период, основные риски, проблемы, действия по их минимизации и решения, открытые вопросы, прогноз по выполнению сроков и бюджета.

Разработка решений

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

Данная глава описывает основные требования к разработке программного обеспечения как собственными разработчиками, так и с использованием сторонних организаций. Кроме того, в ней определены обязательные этапы при создании и внедрении программных продуктов, требования к документированию каждой стадии и контролю качества продукта. Тестирование и внедрение, являясь составными частями разработки, будут рассмотрены в специально выделенных для этого главах. В настоящей главе мы не будем делать различий между разработкой программного обеспечения, его модификацией, доработкой и настройкой. Мы будем считать, что все перечисленные подходы входят в понятие разработки, являясь методами ее технического осуществления.

Итак, каковы основные участники процесса разработки?

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

Разработчик — проектная команда, сформированная на основе службы ИТ или сторонней организации, непосредственно работающая над разработкой, изменением и внедрением программного обеспечения.

Контролеры — сотрудники организации (кроме непосредственно разработчиков), осуществляющие наблюдение за созданием продукта. Контролерами могут выступать начальники подразделений или назначаемые ими сотрудники подразделения. Если заказчиком является организация, то контролеры назначаются руководством. Для больших проектов, важных для бизнеса, возможно привлечение в качестве контролеров сторонних консультантов.

Аналитики — специалисты в области банковских технологий, участвующие в постановке задачи и консультировании всех сторон в ходе проекта.

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

Качество документации должно отвечать следующим критериям:

• правильность:

— соответствие (трассируемость) требований и спецификаций соответствующей системе, и наоборот;

— последовательность в описании требований, спецификаций и функций;

• полнота:

— использование версий и дат документов для контроля изменений, доступность всех версий документов (в том числе рабочих);

— функциональность системы должна быть максимально полно описана в системных требованиях;

— документация должна предоставлять информацию для всех категорий пользователей, операторов системы и разработчиков;

• удобство и простота использования:

— использование оглавлений, алфавитных указателей, глоссариев и кросс-ссылок;

— логическая последовательность и непротиворечивость в использовании терминологии;

— уместный внешний вид документации (шрифты, формат).

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

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

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

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

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

• приемы написания эффективного кода. Эти правила могут быть связаны с использованием эффективных структур данных и алгоритмов, созданием максимально производительных запросов к базам данных и т.п.

Представители заказчика обязаны принимать участие и контролировать процесс разработки на всех этапах. Должны быть назначены представители заказчика (подразделения организации или выделенные эксперты), отвечающие за разработку, — контролеры. Это могут быть сотрудники банка, знающие в деталях бизнес-процессы, для поддержки которых создается система, сотрудники службы информационных технологий или сторонние консультанты. Для максимальной отдачи от внедрения разрабатываемых систем крайне необходимо тесное взаимодействие с разработчиками.

Ответственность за разработку систем помимо назначенных сотрудников или консультантов несут соответствующие руководители подразделений или организации в целом.

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

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

Целью разработки новых систем и модификации существующих является повышение эффективности бизнес-процессов, поэтому помимо разработки программного обеспечения необходимо параллельно рассмотреть другие варианты мер, влияющих на эффективность организации (дополнительное обучение сотрудников, реорганизация подразделений, незначительное изменение или всеобъемлющий реинжиниринг бизнес-процессов с привлечением сторонних консультантов и т.п.). Эта проблема очень важна, и поэтому она будет детально рассмотрена в рамках главы «Управление изменениями».

Этап инициации проекта, с точки зрения разработчика, должен включать подготовку заказчиком требований к новой системе, описание ее функций и структуры, оправдание ее с точки зрения бизнеса и получение одобрения со стороны руководства для того, чтобы приступить к следующим этапам разработки. Если заказчиком выступает подразделение организации, необходимо одобрение руководителя подразделения, если заказчик — организация в целом, то руководителей организации.

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

Оценка проекта и его согласование были рассмотрены выше, поэтому мы здесь лишь упомянем о них.

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

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

Итогом данного этапа должны явиться одна или несколько спецификаций системы, которые готовятся разработчиком при поддержке заказчика. Мы уже отмечали, что для наших целей не будем различать различные типы спецификаций. Отметим лишь, что вне зависимости от их названия они должны содержать:

• описание бизнеса (бизнес-процессы и функции, которые будут автоматизированы):

— детальное описание существующих бизнес-процессов и каким образом они будут затронуты при внедрении системы;

— детальное описание новых бизнес-процессов, которые будут созданы или получены при изменении существующих;

— описание мер контроля, которые будут внедрены в новой системе;

• описание программно-аппаратного обеспечения, необходимого для функционирования системы:

— операционная система(ы), которая будет использоваться;

— сетевая среда, оборудование и протоколы;

— средства разработки новой системы;

— средства защиты информации;

— как новые платформы будут включены в существующую информационную инфраструктуру;

• спецификация функциональности системы:

— общее описание функциональности системы как в повествовательной форме, так и в виде диаграмм;

— разбиение системы на модули;

— соответствие модулей бизнес-требованиям к системе. Должно быть описано, каким требованиям отвечает каждый модуль. Все бизнес-требования должны покрываться модулями системы;

— модель данных, используемая в системе (диаграмма «сущность— связь» или аналогичные). Функциональность, вынесенная в серверную часть системы;

— описание того, каким образом будут реализованы требования к информационной безопасности, производительности и надежности системы;

— детальное описание интерфейсов с другими системами;

— список разрабатываемых программ (включая вспомогательные) и параметры для их запуска;

— список ошибок и предупреждений, генерируемых системой;

— спецификация должна быть четко структурированной и содержать оглавление, алфавитные указатели, глоссарий и список используемых терминов.

Все спецификационные документы подписывает разработчик и предоставляет для ознакомления заказчику.

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

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

• рамки проекта могут быть значительно расширены без формального одобрения, так как пользователи системы могут добавлять «полезные» с их точки зрения функции;

• прототипы описывают только интерфейсы пользователей, и такие вопросы, как информационная безопасность, могут быть упущены на этапе проектирования;

• не для всех компонент системы можно создать прототипы;

• использование прототипов не так детально описывает разрабатываемую систему, как написание спецификаций. Следствием могут явиться трудности с поддержкой и сопровождением в долгосрочной перспективе, а также недостаточный уровень тестирования каждого модуля. На этапе конструирования формально описанные требования к системе, созданные на стадии анализа и проектирования, преобразуются в рабочую систему. Разработка включает в себя создание структуры программы, кодирование, создание структуры базы данных и тестирование на уровне модулей системы, системы в целом и интерфейсов с внешними приложениями.

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

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

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

Разрабатываемое программное обеспечение тщательно тестируется (методика тестирования будет рассмотрена подробно в следующей главе). Должен быть разработан план тестирования, который включает этапы тестирования модулей системы, системы в целом, интерфейсов с внешними программами, интерфейсов пользователя, тестирование систем безопасности и надежности системы. Согласно этому плану необходимо разработать набор тестов, которые помимо покрытия функциональных требований к системе (тестирования по методу «черного ящика») покрывали бы внутреннюю структуру исходного кода (покрытие условных переходов, метод «белого ящиками).

Тестовая среда, база данных и исполняемые модули должны быть отделены от рабочей системы. Разработчики не должны иметь доступ к рабочей системе после ее внедрения и запуска.

Результаты тестирования должны быть зафиксированы, в случае обнаружения ошибок они исправляются разработчиком, и это должно быть отображено в отчете по тестированию. Результаты тестирования — найденные ошибки и как они были исправлены — должны быть подписаны разработчиком и предоставлены заказчику.

На этапе конструирования разработчик разрабатывает документацию для пользователей и администраторов системы в электронном и бумажном виде. Документация должна иметь надлежащую структуру, содержание, формат и внешний вид.

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

В случае необходимости могут быть описаны дополнительные меры, необходимые для внедрения системы. Например, установка нового оборудования, перепланировка используемых помещений, изменения в структуре организации и обязанностях сотрудников, описание необходимых административных процедур и т.д.

На этапе внедрения, особенности которого также будут рассмотрены в отдельной главе, разработанная система должна быть установлена на серверы и рабочие станции, подготовлена и передана заказчику документация, проведено обучение пользователей и администраторов системы. На этой стадии система окончательно принимается заказчиком.

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

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

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

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

Документ о завершении внедрения системы подписывают заказчик и разработчик.

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

Тестирование систем

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

Тестирующий сотрудник не только пытается обнаружить недостатки, но и проверяет программу в работе, оценивает ее надежность, безопасность и безотказность в эксплуатации. Присутствует также экономический аспект. Для более крупных проектов больший объем тестирования обычно выявляет большее количество ошибок. Когда следует прекратить тестирование и какую степень наличия ошибок следует считать приемлемой? Если количество ошибок не превышает определенной допустимой величины, то программное обеспечение может быть квалифицировано как удовлетворяющее требования пользователей и допущено для эксплуатации. Необходимо помнить, что тестирование предполагает, что требования к системе уже сформулированы и не модифицируются.

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

В зависимости от характера и сложности информационного решения банк будет выбирать объем необходимых процедур тестирования. Процесс тестирования может включать все описанные ниже этапы в случае собственного программного обеспечения и некоторые из этих этапов — в случае покупки готового программного обеспечения.

Тестирование «белый ящик» выполняется с целью обнаружения проблем во внутренней структуре программы. Это требует от проверяющего глубокого знания внутренней структуры и, следовательно, не может быть выполнено обычным пользователем. Общая задача такого тестирования — обеспечить проверку каждого шага по алгоритму программы. Основное преимущество всех типов стратегий тестирования «белый ящик»: при тестировании принимается во внимание структура всей программы, что облегчает обнаружение ошибок даже в том случае, когда спецификации программного обеспечения недостаточно определенные или неполные.

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

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

Тестирование «черный ящик» состоит в поиске отсутствующих или неправильно выполняемых функций с целью оценки, насколько хорошо программа отвечает требованиям. Функциональные тесты обычно подтверждают правильность данных на вводе и выходе. В этом случае пользователь — идеальный проверяющий. Иногда такое тестирование называют пользовательским. Тест функциональности состоит в том, чтобы проверить правильное выполнение отдельных функций системой. Проверяющие проводят тесты, которые, по их мнению отражают использование системы в будущем, ее функциональных возможностей.

Системный тест представляет собой более полную версию теста на проверку внешней функции, но в максимально приближенных к «боевым» условиям и среде. При системном тестировании техническая платформа должна быть как можно ближе к фактическим условиям эксплуатации, включая такие факторы, как комплектация оборудования, а также объем и сложность базы данных. В ходе воспроизведения будущих условий эксплуатации системы можно точнее протестировать более сложные черты системы (характеристики, безопасность и безотказность). Однако воспроизводить среду пользователя для системного теста слишком дорого, к тому же может не хватить времени на проведение испытания.

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

Ретроспективное тестирование представляет собой обязательную проверку, выполняемую на модифицированном программном обеспечении, с целью достижения уверенности в том, что изменения в программу внесены правильно и не оказали отрицательного воздействия на другие компоненты системы.

«Приемо-сдаточное испытание» — это проверка готовой системы

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

Рассмотрим некоторые типичные ошибки, совершаемые организациями в результате попыток провести эффективное тестирование программного обеспечения. Эти ошибки можно разбить на 4 категории.

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

2. Недостатки в планировании процесса тестирования. Во многих случаях при планировании тестирования чрезмерное внимание уделяется тестированию функциональности в ущерб тестированию потенциального взаимодействия и системных характеристик. Недостаточное внимание к документации по тестированию и к документации по инсталляции также довольно рискованно.

3. Неправильный подбор персонала для тестирования. Функцию тестирования нельзя поручать младшему персоналу, Группа тестирования должна включать специалистов ИТ по системе и конечных пользователей. Группа тестирования не может действовать эффективно, если ее состав не диверсифицирован.

4, Слабая методика тестирования. Точно так же, как программисты часто предпочитают кодирование написанию алгоритмов, тестирующий персонал часто уделяет чрезмерное внимание самим тестам в ущерб времени, отведенному на составление планов тестирования. Тесты должны дать подтверждение, что программный продукт способен адекватно выполнять свои функции.

Внедрение систем

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

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

Внедрение, пожалуй, — самый ответственный момент проекта замены информационной системы. Это связано с рядом причин.

Во-первых, как мы уже отмечали при рассмотрении управления изменениями, это всегда наиболее сложная составляющая работы.

Во-вторых, даже если на предыдущих стадиях была создана очень хорошая информационная система, до тех пор, пока она не внедрена, ее ценность равна нулю. Часто менеджеры стараются до бесконечности совершенствовать продукт, наслаждаясь им в узком кругу программистов и ИТ-экспертов, не понимая, почему ни у кого больше их многолетние изыскания не вызывают оптимизма.

В-третьих, внедрение — это не экзамен, а нечто большее, и поэтому даже блестяще оттестированные и подготовленные системы, сдавшие все «экзамены», могут не подойти по тем или иным причинам. Думать, что заранее можно предвидеть все проблемы, недальновидно. Во время внедрения все проблемы, конфликты, которые не были решены ранее, были забыты или решены неправильно, отложены, недодуманы, скрыты, всплывают практически в один момент, требуя непомерных профессиональных знаний и личных усилий всех участников проекта.

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

Можно ли избежать этого? Ответ практикующих менеджеров проектов в 99,9% случаев — «да». Набор инструментов для достижения такого результата достаточно уникален и индивидуален и является во многом профессиональным ноу-хау (Know-How) руководителя проекта. Мы же рассмотрим некоторые основные составляющие таких организационных действий, которые позволяют сделать даже проблемное внедрение успешным.

Снятие противоречий и конфликтов. Первый вопрос, который необходимо прояснить, — всем ли нужно внедрение как в самой организации, так и среди подрядчиков? Кому оно невыгодно по тем или иным причинам? Кто против в настоящее время или был против на ранних стадиях проекта? Кто не принимал участия? Даже это может быть важно, потому что успех одного руководителя может автоматически снижать авторитет тех, кто не верил в исход проекта или был против него. Не стоит искать конфликты только среди руководства, они могут быть и на более низком уровне и при этом иметь очень большое значение. Задача руководителя проекта состоит в том, чтобы не только найти все эти центры противоречий и конфликтов, но и свести их на нет или по крайней мере добиться, чтобы их влияние на проект было минимальным.

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

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

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

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

Мотивация персонала на достижение результата. Возможно, самый главный пункт — это мотивация всех участников проекта и прежде всего его непосредственных работников на достижение результата. Мы уже останавливались на основных подходах по мотивации, когда рассматривали управление ИТ-персоналом, поэтому не будем здесь повторяться.

Широкое информирование заинтересованных сторон. Отдельная задача в ходе внедрения — информирование всех заинтересованных сторон, включая обычных сотрудников организации, о ходе и статусе работ. При недостатке информирования проект обрастает слухами, которые будут очень мешать в работе. С другой стороны, поддержка со стороны всей организации очень полезна для работы, является дополнительным источником мотивации. Но это возможно только при наличии информации и понимания, в противном случае отношение будет очень негативным.

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

Существенная часть временных затрат при внедрении систем должна быть потрачена на подготовительные работы технического и административного характера. Данные работы включают:

• доработку программного обеспечения и его тестирование;

• подготовку компьютерной техники, приведение ее к необходимым техническим требованиям разработчика;

• обучение пользователей и администраторов системы;

• разработку конверторов данных из существующей системы в новую, разработку и тестирование методик контроля правильности переноса данных;

• разработку руководств пользователей и администраторов системы;

• разработку инструкций на случай технологических сбоев в системе.

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

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

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

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

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

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

— запуск интерфейса взаимодействия с внешними платежными системами, маршрутизация платежей филиалов;

— формирование баланса и прочей ежедневной и оперативной отчетности;

— ввод простейших платежных документов в систему пользователями, ведение расчетно-кассового обслуживания;

— учет сложных операций (покупка-продажа валют);

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

— учет операций физических лиц;

— учет внутренних операций банка: расчет зарплат, ведение хозяйственных договоров, учет основных средств;

— учет и ведение кредитов банка;

— учет прочих операций банка, включая торговые операции на бирже.

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

Переход на рабочую эксплуатацию системы обычно заканчивается подписанием акта о проделанной работе. Однако большое количество недоработок и недовольство пользователей нельзя назвать успешным завершением. Таким образом, взаимодействие с разработчиками не заканчивается рабочей эксплуатацией, а переходит в новую стадию— сопровождение. Не стоит требовать от разработчиков немедленного устранения всех недочетов. Лучше в течение некоторого времени дать пользователям поработать с новой системой, почувствовать ее возможности и преимущества перед старой. И только после того, как отрицательные эмоции улягутся и пользователи смогут более квалифицированно говорить о достоинствах и недостатках нового решения, необходимо провести их опрос и составить план устранения действительно важных недоработок. При этом часть проблем к этому времени смогут снять сотрудники автоматизации банка. А остальные решит компания разработчика, которая, получив аргументированные и понятные претензии, не сможет отказать своему клиенту.

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

Анализ рисков при реализации проектов

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

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

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

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

Данная глава рассматривает методику, позволяющую оценить риски при реализации крупного проекта и минимизировать потери от них. Эта методика была предложена и принята рядом западных компаний и адаптирована к отечественным условиям в результате многочисленных проектов в российских кредитных организациях. Мы уже рассматривали тему управления рисками. Остановимся на этом вопросе еще раз и более детально разберем его с точки зрения проектного управления.

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

Первый этап рассматриваемых работ — определение ответственных за различные типы рисков. В зависимости от ответственности за риски их условно можно разделить на три группы.

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

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

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

2. Технические риски связаны с проблемами реализации технических решений. Основными проблемами здесь обычно являются проблемы разработки (способность разработчиков реализовать ту или иную задачу), неудовлетворительная производительность системы, внедрение и затруднения, связанные с окончательной адаптацией системы под конечных пользователей.

Ответственное лицо за решение подобных проблем — обычно технический руководитель проекта или ведущий аналитик.

3. Бизнес-риски связаны с финансовой поддержкой проекта. Неожиданные сокращения бюджета, вызванные внешними факторами, могут привести не только к сокращению проекта и задач, которые он решает, но и к его полному провалу в случае недостижения главной цели. Для компании-разработчика к данному типу рисков обычно относятся ошибки в оценке рынка данного решения. В российских организациях также к подобного рода нештатным ситуациям относится потеря интереса к проекту со стороны конечных пользователей.

Ответственным лицом в кредитной организации за подобные проблемы может быть заказчик (куратор) проекта или руководитель проектного комитета. Он должен заранее определить приоритеты и организовать резервы для решения приоритетных задач каждого этапа.

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

В качестве спецификации возможна разработка менеджером проекта таблицы рисков (табл. 16).

Таблица 16