Один офис хорошо, а два лучше

Россия богата на идеи и, как следствие, на концепции. Нет необходимости оглядываться на далёкое прошлое, достаточно начать с новейшей ИТ-истории. В 2010 году принимается очень прогрессивный концептуальный Закон № 210 об организации предоставления государственных и муниципальных услуг, основная задача которого — обеспечить повсеместную доступность услуг за счёт их перевода в электронный вид.

Страна закипела, зашевелилась. Заиграла в сером веществе айтишников молодецкая кровь, заклацали клавиатуры, зашуршали жёсткие диски, и начали коваться мегабайты кодов в ИТ-кузницах. Долго ли коды ковались, коротко ли — но были они наскоро скроены, с ошибками скомпилированы, друг с другом не согласованы…

Офис первый — проектный

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

Внедрение проектных подходов к реализации задач началось достаточно давно. Наработано огромное количество материалов о том, как построить проектный офис. Имеется масштабная база шаблонов документов, регламентов, описанных процессов, официальных стандартов и распоряжений Правительства РФ. Вышедший в 2011 году ГОСТ Р 54869-2011, «закреплённый» в 2016 году Постановлением Правительства РФ от 15.10.2016 №1050 об организации проектной деятельности в Правительстве РФ, фактически обязал весь госсектор внедрять проектное управление. Федералов – в явном виде, регионы – в рамках настоятельной рекомендации.

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

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

Фактическая ситуация

Государство практически перестало выступать качественным заказчиком в ИТ-сфере. Нет, заказчиком оно выступает, конечно. И вполне себе качественным — накупает огромное количество всякого разного на радость вендорам и интеграторам. Но над вопросами: «Зачем мне именно это?», «Как я буду это использовать?», «Как это будет интегрировано в существующую организационную и техническую среду?» — мало кто задумывается.

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

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

Панацея есть?

Чтобы всё-таки получить ответы на вопросы «Зачем нам это нужно?» и «Как сделать правильно?», нужно привлечь «специально обученных людей» — методологов. Причём, привлечь именно так, чтобы они работали на стороне госзаказчика и преследовали именно его цели и интересы.

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

И мы, как мышки из анекдота, идём к Мудрому Филину, чтобы получить ответ на вопрос: «Как нам выжить?». К сожалению, «Мудрый Филин НПА» здесь не помог: ни вышеупомянутый ГОСТ, ни Постановление ничего не говорят о выстраивании методобеспечения реализуемых проектов.

Дальнейшие поиски ответа на вопрос «Как?» привели к Распоряжению Правительства РФ от 29.12.2014 № 2769-р о концепции региональной информатизации, в соответствии с которой во всех регионах должен быть определен уполномоченный орган по информатизации, который, среди прочего, призван «осуществлять методическую и экспертную поддержку отраслевых органов и органов местного самоуправления».

 «Мышки, станьте ёжиками!» — сказал нам Мудрый Филин. Но поиски ответа на вопрос: «А как стать ёжиками?» — в точности повторил историю с мышами: «Это уже тактика, а я занимаюсь стратегией…»

Органам государственной власти субъектов РФ рекомендуется использовать механизмы проектного управления с учётом разрабатываемых Минкомсязи РФ методрекомендаций по организации системы проектного управления мероприятиями по информатизации в госорганах (распоряжение от 14.04.2014 № 26Р-АУ) и подготовленных Минэкономразвития РФ рекомендаций по внедрению проектного управления в госорганах (приказ от 24.04.2013 № 96).

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

Второй документ тоже в явном виде ничего не говорит о необходимости методологической проработки и экспертизе реализуемых проектов. Но в нём идёт речь о необходимости создания Рабочей группы проекта по информатизации (п. 3.6), которая среди прочего должна заниматься «формированием перечня функциональных, технических, качественных, эксплуатационных характеристик к закупаемым товарам, выполняемым работам (услугам), необходимым для реализации проектов по информатизации. Формирование и ведение базового плана проекта по информатизации, создание запросов на изменение базового плана проекта по информатизации» (п. 8.1).

Ну, в общем-то, и все. Финал точно такой, как в анекдоте.

Что же делать?

Вариант первый. Два офиса в одном. Помыл и пошел

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

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

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

Вариант второй. Нам помогут!

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

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

Вариант третий. Сделай сам!

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

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

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

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

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

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

Особенности: дойдя до стены, моментально берут другую задачу, поскольку не любят простаивать. Могут чрезмерно увлечься конкретным проектом, пытаясь довести ТЗ до совершенства, которого, как мы понимаем, не существует. Как правило, творческие личности, со всеми вытекающими... Думают «на завтра», в лучшем случае — на неделю вперед.

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

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

В заключение

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

Решать вам, коллеги, строители цифровой экономики! Желаю удачи!