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

Intelligent Enterprise: Какие задачи ставятся перед вашей организацией и каково назначение ПО, которое разрабатывает ваша команда?

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

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

Какова ваша инфраструктурная база и насколько масштабны приложения, которые вы разрабатываете и поддерживаете?

У нас три технологические площадки. Офисная находится в Центре международной торговли, где работает основная часть сотрудников. Технологическая — в помещении СО ЦДУ, где расположены основные серверы и дисковые массивы. И наконец резервная площадка на территории ЦОДа DataFort — там мы арендуем стойки и держим комплект оборудования, необходимый для проведения торгов и расчетов. В общей сложности это более 120 серверов, шесть дисковых массивов, ленточные библиотеки. У нас оборудование среднего класса. Сейчас многопроцессорные серверы IBM System p под управлением AIX сменяют машины IBM хSeries. В качест­ве технологической платформы на серверах IBM хSeries используется Linux, в основном Red Hat. Операционную систему Microsoft Windows используем весьма ограниченно и вынужденно, поскольку некоторые приложения работают только в этой среде. Основная СУБД — Oracle, есть несколько приложений на Microsoft SQL Server, например «1С: Бухгалтерия», которая применяется в качестве учетной системы при финансовых расчетах.

Основные средства разработки — Oracle PL/SQL и Java, а также, в меньшей степени, Borland Delphi. Клиентская часть — тонкий клиент, архитектура условно трехуровневая, поскольку вся бизнес­логика и данные хранятся в СУБД Oracle. Интерфейс отрисовывается на сервере приложений (Tomcat или Oracle Application Server). В итоге клиент получает HTML­интерфейс, что удобно с точки зрения администрирования. Пользователями ПО, которое мы разрабатываем, являются около трехсот сотрудников НП АТС и ЗАО «ЦФР» (Центр финансовых расчетов — дочерняя организация АТС. — Прим. ред.).

Как организован ваш департамент? Какие ресурсы выделены под разработку? Привлекаете ли вы внешние компании?

Нашдепартамент состоит из че­­тырёх отделов. Отдел проектирования занимается сбором и уточнением требований, подготовкой технических заданий, в методологии CDM/PJM его работа укладывается в первые два этапа: стратегия и анализ. Отдел программирования пишет софт, тестирует и документирует его. Затем ПО передается в отдел эксплуатации. Четвертый отдел — информационной безопасности, или ИБ, — в нашей организации входит в ИТ­департамент. По этому поводу были споры, поскольку на других предприятиях, в том числе в РАО ЕЭС, ИБ относится к общей безопасности. Но я считаю, что так как ИТ­безопасность — это на 99,9% ИТ, то и находиться данное подразделение должно в ИТ­департаменте. При таком подходе проблемы, конечно, возникают, но еще больше их бывает, когда этот отдел относится к общей безопасности. На мой взгляд, именно интеграция ИБ в ИТ позволила создать и ввести в промышленную эксплуатацию удостоверяющий центр оптового рынка электроэнергии всего за три месяца.

Суммарная численность четырех отделов — 70 человек: шесть аналитиков, более двадцати — в отделе программирования, более тридцати — в отделе эксплуатации. В проекте разработки участвуют сотрудники НП АТС и внешние подрядчики — в соотношении примерно 50:50. Распределение работ между своими и внешними такое же, и со стороны внешних подрядчиков 15 — 20 человек заняты соб­ственно написанием ПО для нас. Таких постоянных подрядчиков у нас несколько. Мы работаем с компанией ФОРС, хорошо известной «в мире Oracle», с консалтинговой фирмой «Карана», с компаниями «Вебсофт» и IBS; по мере необходимости привлекаем и других. Основной критерий выбора — экспертиза в узкой, необходимой нам области. В разработке софта важна преемственность, странно было бы постоянно менять подрядчиков, теряя темп и качество на переходах. Поэтому их пул, в отличие от поставщиков оборудования, должен быть стабилен.

Какую методологию процесса разработки вы используете? Какие инструменты применяете?

В свое время я имел большой опыт работы с технологиями Oracle, и мы «держим в уме» методологию CDM/PJM для разработки информационных систем на базе СУБД этого вендора. В соответствии с этой достаточно универсальной методологией структурируем проект на основные этапы и задачи. На разных этапах используем разнообразные средства автоматизации. Для сбора и обработки требований у нас применяется продукт DOORS компании Telelogic. Анализ проводится с помощью средств, поддерживающих стандарты IDEF, — пакетов ERWin и BPWin от Computer Associates. Мы написали софт, который связывает требования, описанные в DOORS, с BPWin, и научились автоматически генерировать технические задания по ГОСТ 34 из базы данных DOORS и IDEF0­диаграмм бизнес­процессов.

Для проектирования базы данных тоже используется ERWin. Для проектирования архитектуры ПО никаких специальных средств не применяем. В управлении конфигурацией ПО и процессом внесения изменений используется продукт той же Telelogic — Synergy. Документация делается в MS Word. Мы пытались для этой цели внедрить SGML, предположив, что этот мета­язык позволит добиться многократного использования готовых элементов документации. Но, к сожалению, разметка оказалась неоправданно трудозатратной, а «реюзабилити» — неуловимым призраком, и мы от этой идеи отказались. Выяснилось, что производительность труда при этой технологии в 3 — 5 раз ниже, чем при использовании MS Word.

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

Насколько ваш реальный режим меняет предписанные методологией способы работы?

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

Для нас это означает, что программирование ведется в экстремальном режиме. По нашей пропускной системе я вижу, что ключевые программисты и основные сисадмины в «пиковые периоды» проводят на работе по 250 — 320 часов в месяц. Такие режимы у нас не редкость.

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

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

Если процесс внесения изменений не столь интенсивен, то с точки зрения организации процесса мы приближаемся к модели, задаваемой CDM/PJM. Хотя классическое соотношение — треть времени на проектирование, треть на кодирование и треть на тестирование — не выполняется. Бывают периоды, когда изменения очень существенные и софт переписывается на 50%, а бывают более спокойные времена, но и тогда такое соотношение обеспечить не удается. Разве только отдельные куски софта разрабатывались в таком режиме.

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

Как вы подбираете кадры и как работаете с людьми?

Подбор ведем по трем каналам. Основной — личной связи. Я сам всю жизнь работаю в области разработки ПО — начальников отделов, программистов знакомых достаточно. Второй — департамент по работе с персоналом, его сотрудники тоже ищут, в частности посещают дни открытых дверей ведущих вузов. Они, так же как и я, мониторят Интернет. И третий канал — кадровые агентства, которые тоже иногда кого­то подкидывают.

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

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

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

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

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

Зависимость от конкретного человека, оценка качества работы, измерение эффективности труда программистов — как вы решаете эти задачи?

В свое время я имел возможность подробно посмотреть коды западных пакетов бизнес­ПО — систем автоматизации банков, ERP­систем. И вот что мне бросилось в глаза преждде всего: с логической точки зрения код разбит на очень большое число предельно простых кусочков. Настолько простых, что можно взять человека с улицы, на ходу ему что­то объяснить, и он сможет продолжить работу. В России традиционно другая культура программирования: код более сложный, массивный. Но сложность работы с нашим ПО связана в первую очередь с экстремальным режимом работы, с недостаточно детальным проектированием и документированием. Кроме того, мы, к сожалению, не имеем времени, чтобы дать человеку возможность хорошо и подробно разобраться в логике уже написанного кода. Поэтому зависимость от конкретных людей остается довольно высокой, но мы уже пять лет живем в таком режиме. Костяк команды сохраняется. Кроме того, мы стараемся дублировать функции, особенно высококритичные, чтобы любому сотруднику всегда была замена.

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

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

Каким образом у вас организовано тестирование?

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

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

Каковы по вашему мнению условия успеха проектов по разработке и в чём состоят их основные риски?

Основными рисками при разработке ПО я считаю следующие.

Во­первых, неточная постановка задачи. Много лет назад в отчете одной консалтинговой компании я вычитал, что точность технических заданий на разработку ПО в среднем не превышает 30%! Отсюда — ошибки в определении требуемых ресурсов и сроков. Красивые диаграммы Ганта становятся бессмысленными уже через одну­две недели после запуска проекта. Вообще управление проектом в условиях высокой степени неопределенности задачи требует отдельного подхода. Традиционные методы, «выросшие» в таких отраслях, как строительство, где точность технического задания равна 100%, неприменимы. В софт­верных проектах на первый план выходит управление изменениями.

Во­вторых, нереальные сроки, устанавливаемые заказчиками. Была когда­то такая песенка: «Нет­нет­нет, мы хотим сегодня, нет­нет­нет, мы хотим сейчас». Такое впечатление, что ее про себя поют многие заказчики, не понимая, что в итоге это обернется для них потерей качества заказываемого продукта.

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

Ну и наконец дефицит квалифицированных программистов и менеджеров проектов. Это вечная проблема: «много званых, да мало избранных».

Что же касается успеха, то главным его условием всегда было и остаётся наличие профессиональной команды плюс минимизация тех рисков, о которых я говорил. В руководстве по CDM/PJM написано, что основное качество менеджера проекта — умение здраво мыслить. С этим нельзя не согласиться. Ну и нацеленность на результат. Профессионализм, основанный не на общем понимании, а на реальном опыте.