Как внедрить систему вовремя

Мнения
7053
0
Сергей Цевин, директор центра развития бизнес-приложений департамента аналитических систем, R-Style Softlab
Одним из ключевых показателей успешности ИТ-проекта является соблюдение плановых сроков. Однако практика показывает, что довольно часто сроки сдвигаются, причем, как правило, в сторону увеличения. Почему это происходит? Взглянув на проблему с позиции вендора, мы поняли, что причиной такого сдвига могут быть не только действия исполнителя, но и определенные ошибки заказчика. О них и пойдет речь.


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

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

Итак, какие основные ошибки совершают заказчики?

1. Переоценка собственных сил

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

2. Неготовность учетных систем банка

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

3. Желание вместе с автоматизацией текущего бизнес-процесса добавить в проект побольше новых требований

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

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

4. Необоснованность требований

Все требования должны быть обоснованы — это следует принять как аксиому. Многие, вероятно, не согласятся с данным утверждением. Но давайте посмотрим, как могут выглядеть требования к системе, поступившие от пользователя, который до реализации проекта строил отчетность в Excel. Если он работал с большими объемами данных, то вполне может потребовать, чтобы система выводила на экран более миллиона строк. Какой простор для творчества может дать такое простое и незатейливое требование! Но, стоит начать задавать этому пользователю уточняющие вопросы, как выяснится, что все дело в том, что в Excel более 1 млн строк на лист не помещается. Прежде чем отправлять требование разработчику, необходимо узнать, зачем оно нужно, что конкретно под ним имеет в виду пользователь. Увеличить срок проекта на несколько дней для уточнения требований или потерять месяцы на реализацию возможностей, которые не актуальны или просто не нужны, — решать заказчику.

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

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

Все статьи

Комментарии



Подписка на рассылку
Сортировать
Теги:
Все теги
Выберите интересующий Вас продукт компании
Любой продукт
Сортировать по году:
2017 2018 2019