In English

О рисках скоростной разработки, о старых друзьях и недругах

29.03.2016

_MG_0138___.jpg
Михаил Македонский, руководитель «Аплана. Центр разработки» (группа компаний АйТи) продолжает рассуждать о том, почему при наличии тысяч готовых приложений потребность в заказной разработке только растет, как «конвейер разработки» помогает обеспечить высокую скорость изменений в ИТ, и что делать с устаревшими информационными системами. 


О быстрых изменениях по мотивам Грефа

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

Пример оперативного сотрудничества и быстрых изменений — наше сотрудничество с Центробанком. Мы давно разработали, поддерживаем и развиваем автоматизированную систему управления проектами (АСУП). Но в банке постоянно происходят организационные изменения, меняются требования законодательства. Жизнь кипит. И с каждым новым постановлением нужно вносить множество изменений во все компоненты АСУП. Наши специалисты работают на территории заказчика, чтобы к ним можно было прийти в любой момент. Запросы бывают разные, а нам нужно быстро отразить их в системе и обеспечить корректный результат. Мы сначала описываем пожелания заказчика, а дальше есть целая технология, чтобы изменения быстро прошли тестирование, апробацию и вошли в промышленную эксплуатацию. Допустим, заказчик просит: мне нужно срочно такой отчет. Мы сделаем его сразу, а уже потом будем встраивать в систему как базовую возможность.


 

Об унаследованных системах и отношениях с заказчиками

Бизнес заказной разработки и сопровождения информационных систем – обычно долгосрочное сотрудничество с заказчиком, которое требует взаимного доверия. Перед любым проектом обязательно оцениваем риски. В конце прошлого года был случай: прибежал заказчик со срочным проектом. «Гипс снимают, клиент уезжает!» Деньги нормальные и технология нам известная, вроде можно сделать. Но риски слишком большие — отказываемся. Риски связаны не с техническими причинами, а с окружением, с ситуацией, внутри которой придется работать. Порой заказчик настроен негативно, могут быть разные причины. Мы выиграли конкурс, а он привык работать с другим поставщиком услуг. Люди заказчика привыкли общаться с теми, с кем уже есть контакт, есть хорошие отношения. И они просто могут даже не давать нам нужную для проекта информацию, не предоставлять данные. Саботировать, бюрократизировать... Система, которую мы делаем, должна быть действительно НУЖНА кому-то, чтобы был человек у заказчика, заинтересованный и достаточно весомый, чтобы систему продвигать, потому что бывает сопротивление на местах. Так что в заказной разработке старый друг лучше новых двух! У нас в работе 15-20% проектов для новых заказчиков, остальные — для старых.

Поэтому значительную долю работы занимает поддержка «старых» систем, «возраст» которых превышает 10 лет.

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

К слову, многие международные банки до сих пор используют инф. системы, написанные на языке Algol. Я знаю это от коллег из Израиля, которые старше меня, они до сих пор пишут, вносят изменения, поддерживают эти системы. Так что тут главный критерий – не новизна, а выполнение возложенных на систему задач. И если стоимость поддержки и сопровождения унаследованной системы в разы меньше ее замены на новую, так и пусть себе работает! 

Центральный федеральный округ