NAT чем работаете?

Конференция Главгосэкспертизы РФ «Развитие института строительной экспертизы» 2017 года сломала стереотипы о консервативной организации процедур, длящихся годами. С 2015 года экспертиза проводится только в электронной форме, включая прием документации и выдачу заключений с использованием электронно-цифровой подписи. О том, как устроена «машина изобретений» у соседей из Центральной Азии, журналу RUБЕЖ рассказал управляющий директор по разработке информационных систем АО «НАТ Казахстан» Константин Левин.

Как долго существует компания NAT?

КОНСТАНТИН ЛЕВИН: День рождения компании 4 августа 2000 года. Те есть уже 17 лет. NAT — это аббревиатура первого полного названия — «NewAgeTechnologies». В 2008 году у нас произошла реорганизация, сменился формат управления и вместе с этим название. С тех пор мы — АО «НАТ Казахстан».

Компания создавалась сразу как разработчик ПО?

К. ЛЕВИН: Изначально компания позиционировалась на рынке как системный интегратор, который может разработать программное обеспечение, оказать услуги ИТ-консалтинга, а также выполнить поставку необходимого серверного оборудования. Сейчас же в нашей компании акцент смещен с поставки оборудования на ИТ-консалтинг и разработку ПО.

Проект, с которого, можно сказать, началась история NAT, был самым амбициозным для нас — создание системы приема и обработки электронных форм налоговой отчетности Республики Казахстан. Заказчиком данной системы в то время было Министерство государственных доходов РК (сейчас — Комитет государственных доходов РК). В течение почти 6 лет наша компания принимала участие в этих работах. В пиковые моменты количество участников проектной команды NAT доходило до 80 человек, которые вместе с командой заказчика внедряли и расширяли функциональность системы. На пространстве СНГ это была первая система, обеспечивавшая прием налоговой отчетности в электронном виде, чем мы очень гордимся.

В портфеле компании много крупных, социально значимых реализованных проектов. Среди них такие, как:

• государственная база данных физических лиц РК;
• информационная система ЗАГС РК;
• таможенная информационная система РК и др.

Как распределялись функции среди этих 80 человек?

К. ЛЕВИН: Это были разные специалисты. В то время у нас были отделы разработчиков ПО, инженерно-технического персонала, тестировщиков, внедренцев, консультантов службы поддержки, руководителей проектов. В отдел разработки на простые, но рутинные задачи активно привлекали студентов.

Каким вузам отдавали предпочтение?

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

На какой масштаб проектов вы сейчас ориентируетесь?

К. ЛЕВИН: На средние и крупные проекты. За мелкие не беремся, потому что организационная модель компании такова, что мелкие проекты нам делать не выгодно — мы для них слишком дорогой исполнитель. Производственный механизм «заточен» на государственный сектор, на крупные проекты республиканского масштаба, чем в основном и занимаемся.

Если говорить про структуру портфеля, за управление которым я отвечаю, то примерно 95% его объема составляют проекты по госзаказу. Оставшиеся 5% — это активности и инвестиции, направленные на развитие собственных продуктов, которые мы собираемся использовать либо внутри компании, либо вывести на рынок.

Как организовано управление?

К. ЛЕВИН: У нас хорошо налажены процессы внутри компании. Три года назад мы первыми в Казахстане прошли аттестацию по CMMI (Capability Maturity Model Integration — оценка зрелости процессов в софтверной компании) и прошли ее на 3-й уровень, чем тоже гордимся. У нас тогда появилось желание выйти на внешний рынок, и нужны были подтверждения нашего опыта, уровня, способности делать серьезную работу. Мы решили, что аттестация CMMI послужит одним из таких подтверждений, однако движение на внешний рынок оказалось не настолько простым, как в то время мы себе представляли. Сертификацию прошли, но за пределами Казахстана пока не работаем.

Какие методы управления используете при разработке ПО: классические (waterfall), гибкие — Agile — или гибридные?

К. ЛЕВИН: Внутренние проекты мы делаем с использованием гибких методов/фреймворков — это Scrum, Kanban. В проектах на заказ гибкости гораздо меньше, поэтому там больше Waterfall с элементами Agile, которые могут использоваться в разных ситуациях. Если возникает критическая ситуация, применяем на коротких интервалах практики гибких методов (dailymeeting, спринт, ретроспектива и т. д.). Когда ситуация выравнивается, начинаем снова больше применять процессный подход. Процессы реализации ИТ-проекта прописаны у нас во внутренней нормативной документации.

Когда мы разрабатывали свою процессную модель, то делали анализ таких методологий, как RUP (IBM), MSF (Microsoft), рассматривали стандарты PMI, P2M, Prince2, IPMA. Из этих методологий и стандартов взяли то, что сочли ценным для нашей компании, и включили их в первую редакцию системы процессов.

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

Сколько лет заняла систематизация процессов?

К. ЛЕВИН: Работы в данном направлении у нас начались в 2005 году. Когда компания растет, то требуется систематизация, внедрение регламентов и процессов. Иначе теряется управление. На момент, когда у нас появился первый пакет документов с описанием процессов, в компании работали около 300 человек. Без системы было сложно. В период подготовки к аттестации CMMI, когда в компанию пришел внешний эксперт-оценщик, мы иначе взглянули на процессы, на свои сильные и слабые стороны, на практики, которые используем. Я считаю, что в тот момент мы были на пике понимания и регламентации производственных процессов.

Какую систему планирования предпочитаете?

К. ЛЕВИН: Если говорить об информационной системе управления проектами, то большую часть времени существования компании мы использовали Microsoft ProjectServer. Года три назад мы перешли на ОpenSource. Мы используем продукт Tuleap. Это движок, Application Lifecycle Management (ALM), который позволяет гибко настраивать формы для комфортной работы всех участников проекта. В данном продукте есть возможности вести проекты в Agile (SCRUM), есть Kanban доска, можно организовать работу в Waterfall, быстро без привлечения программистов формировать, адаптировать формы и создавать шаблоны проектов.

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

Как происходит тестирование продуктов?

К. ЛЕВИН: Тестирование зависит от потребностей заказчика в уровне качества, которое нужно обеспечивать для проекта. Традиционно используем регрессионное, дымовое тестирование. На крупных проектах применяем нагрузочное и автотестирование. Например, сейчас пишем автотесты для нашего собственного продукта, который  называется BanksGate и используется в банковской среде. Тем самым обеспечиваем качество исходного кода, качество обновлений, которые мы регулярно поставляем. Также автоматизацию тестирования применяем и в проектах по разработке заказного ПО. В основном для крупных, многолетних проектов. Для выполнения работ используем продукт Selenium.

Тестированием занимается отдельное подразделение?

К. ЛЕВИН: С 2000 года, когда у нас было множество подразделений каждое со своим функционалом, NAT сильно модифицировался. Сейчас подразделений стало значительно меньше и они стали более кроссфункциональными. В данный момент у нас есть подразделения программистов и консультантов.

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

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

Какие языки программирования применяются чаще всего?

К. ЛЕВИН: Так сложилось, что пока у нас проектов на платформе .NET больше, чем на Java. На рынке потребность в Java-разработчиках растет, и она уже достаточно высока. У нас есть желание нарастить эту категорию специалистов. Но, к сожалению, специалистов с адекватными требованиями найти не так просто, поэтому быстро расширить штат не получается.

В какой пропорции привлекаете аутсорсеров на проекты?

К. ЛЕВИН: У меня, как у руководителя производственного направления компании, есть ограничение на объем субподрядных работ. Оно устанавливается в стратегических целях организации. На самом деле мы прикладываем максимум усилий для выполнения проектов собственными силами. Так надежнее.

По какому алгоритму встраиваете субподрядчиков в проект?

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

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

Как у вас настроена система соблюдения дедлайнов? Какой путь пришлось пройти, чтобы научиться соблюдать сроки?

К. ЛЕВИН: Мы используем методы управления по контрольным точкам. Это не новое изобретение, они известны, просто нужен определенный опыт для того, чтобы все получалось как надо. За это отвечают руководители проектов, а цель достигается за счет зрелости и слаженности работы руководителя проекта и его команды.

В портфеле заказов продукты только верхнего уровня? С прошивками для «железа» не работаете?

К. ЛЕВИН: Услуги низкоуровневой разработки ПО (firmware) мы не предлагаем. Это не наш профиль деятельности. В основном мы занимаемся автоматизацией бизнес-процессов. Но у нас есть подразделение инженеров и определенный опыт разработки систем мониторинга оборудования и сервисов. Сейчас предпринимаем действия, чтобы вывести на рынок новую услугу — внедрение системы мониторинга сервисов и оборудования организации. Такое ИТ-решение мы уже внедрили в трех компаниях, в том числе у себя, и научились хорошо это делать. Инженерный состав, в частности, занимается настройкой, запуском и сопровождением таких систем. Данная система построена на основе OpenSource-продуктов, что делает ее относительно не дорогой. Результаты мониторинга красиво оформляются в виде дашбордов, графиков, стрелок, спидометров.

Информация отображается очень удобно, с поддержкой интерактивности и функции DrillDown. Если хочешь посмотреть детали, то по одному клику мыши можно «провалиться» на более низкий уровень детализации, посмотреть, в каком узле инфраструктуры проблема и почему он не работает.

Для каких типов оборудования уже делали подобное?

К. ЛЕВИН: Большой спектр: сайты, серверы, программные продукты, рабочие станции пользователей, оргтехника и периферия, сетевое оборудование, физическая среда (температура, электричество), системы резервного копирования, гипервизоры. Если один из объектов начинает сбоить или вышел из строя — это можно мгновенно увидеть на цветном дашборде.

У нас в компании дашборд такой системы отображается на телевизоре в coffee room. Вся картина о состоянии работы инфраструктуры организации постоянно на виду. Если система сигнализирует о проблеме, то вопрос оперативно решается.

Как строите работу с заказчиками? Как происходит снятие потребностей и их формализация в проектной документации?

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

Мы нацелены на то, чтобы максимально сократить время между получением требований и выпуском релиза. Сейчас есть тренд — DevOps. Это тесная интеграция разработчиков ПО, тестировщиков и эксплуатационников, что позволяет значительно сократить время выпуска релиза/патча и его поставку заказчику. В этом направлении мы хотим двигаться. В течение двух последних лет на одном из крупных проектов разработки заказного ПО бывало, что мы выпускали до 6-10 патчей/релизов в неделю. Обычно компании-разработчики выпускают патчи/релизы примерно раз в месяц, а те, кто работают по Agile (Scrum), — 1 раз в 2 недели. Это был высокий темп работы, тем самым мы быстро наращивали функциональность системы. Мы считаем, что это правильный способ, и заказчики это ценят.