Введение
С момента выхода блестящей книги Николаса Карра «Блеск и нищета информационных технологий: Почему ИТ не являются конкурентным преимуществом» прошло 16 лет, но за это время мало что изменилось. Затраты на программное обеспечение (ПО) по-прежнему являются настоящей чёрной дырой для бюджетов компаний и государственных органов управления, ведь зачастую их конечный результат практически невозможно увидеть.
Стандартизация используемых программных продуктов (ПП) и их элементов (блоков) — единственно верный способ для организации в несколько раз снизить затраты на ПО и повысить их эффективность.
Этот текст предназначается, в первую очередь, управленцам: руководителям и тем, кто занимается организацией работ по созданию, использованию и сопровождению ПП. В нём мы рассмотрим проблемы, которые могут возникнуть в ходе стандартизации, и способы их решения.
Организационные вопросы
Прежде всего скажем о необходимых затратах. По мировому опыту, экономический эффект от применения стандартов в 5–10 раз превышает стоимость их разработки. Сам процесс стандартизации непрерывен, а его эффект нарастает с момента старта работ.
Для разработки стандартов организации требуются квалифицированные ИТ-специалисты. Поскольку большинство руководителей не являются специалистами в области ИТ, им бывает сложно оценить уровень реальной компетенции своих сотрудников. Помимо компетенции важно учитывать и их мотивацию. Начальники ИТ-подразделений, как правило, ориентированы на конкретного разработчика, которого используют для проведения ИТ-экспертизы по всему спектру деятельности. В этом нет ничего плохого, поскольку самостоятельно ориентироваться во всём спектре быстро меняющихся технологий невозможно. Однако руководителю важно убедиться, что интересы начальника его ИТ-подразделения не расходятся с интересами организации.
Прежде чем приступить к разработке стандартов, необходимо проанализировать эффективность используемых ПП. Для этого нужно сверить данные бухгалтерского учёта о наличии используемых ПП с их фактическим наличием и использованием. Реальное использование ПП можно определить по анализу количества обращений пользователей. Следует заметить, что этот анализ должен проводиться только автоматически. Фактически речь идёт о сборе и анализе журналов событий (логов), фиксирующихся всеми ПП. Если вас будут убеждать в том, что такой анализ требует много сил и времени, у вашей организации серьёзные проблемы.
Проанализируйте текущие затраты по каждому ПП. Многих руководителей здесь ждут неприятные открытия. Например, ПП висит на балансе, затраты на его сопровождение есть, а сам ПП при этом не используется. Важно удостовериться в том, что организация получает конечный экономический эффект от каждого используемого ПП. Такой анализ позволит вам отсечь весь информационный мусор и определить перечень по-настоящему необходимых организации ПП. Только наведя элементарный порядок, можно приступать непосредственно к работам по стандартизации.
По моему опыту, в подавляющем большинстве организаций в настоящее время ПП представляют собой «зоопарк» из различных технологий, написанных на разных программных платформах. Едва ли какая-то организация может позволить себе эффективно разрабатывать, поддерживать, эксплуатировать и развивать весь спектр ИТ.
Принципы и методы стандартизации в ИТ-индустрии точно такие же, как в других сферах деятельности. На первом этапе необходимо чётко определить и зафиксировать ограниченный перечень программных платформ, технологий и решений, оптимальных для вашей организации. Этот небольшой документ имеет ключевое значение, поскольку на его основе будут приниматься дальнейшие управленческие решения. Разрабатывать и принимать документ в государственной организации должен научно-технический совет (НТС), в коммерческой организации — его аналог.
Поскольку задачи, стоящие перед организацией, постоянно меняются, а ИТ стремительно развиваются, необходимо также разработать и утвердить порядок ведения перечня и внесения в него изменений.
Эти два документа дают старт проведению единой технической политики в организации. Все дальнейшие действия по заказу, проектированию и развитию ПП производятся в соответствии с ними.
Технические проблемы на пути стандартизации в ИТ
1. Разработка и сдача заказчику ПП, созданного в соответствии со стандартом.
Любому специалисту ясно, что поддержание технической документации в актуальном состоянии — обязательное условие создания и эффективной эксплуатации любого ПП. Проблема в другом: как этого достичь, когда документация представляет собой обширный набор технических документов, которые не должны противоречить друг другу по содержанию.
Для специалиста, занимающегося подготовкой нормативной документации и хотя бы раз обеспечивавшего свод замечаний, очевидно, что текстовый редактор (Microsoft Office Word, LibreOffice Writer, МойОфис Текст) решить этой задачи не сможет.
Как обычно готовится нормативный документ в текстовом редакторе? Контрольный экземпляр проекта документа создаёт ответственный за эту работу исполнитель, и только он имеет право вносить к текст документа правки по поступившим замечаниям и предложениям. Нарушение этого принципа ведёт к печальным последствиям — как в миниатюре Аркадия Райкина «Кто сшил костюм?».
В любой крупной структуре технические документы рассматривает большое количество специалистов соответствующего профиля, обычно в системе электронного документооборота. При этом специалистам, как правило, направляют лишь отдельные документы, поскольку на просмотр всего объёма технической документации у них элементарно нет времени. Замечания, поступившие от специалистов заказчика разного профиля, направляются непосредственно исполнителю работ.
На сложном проекте у исполнителя замечания от заказчика также отрабатывают несколько специалистов разного профиля, и тоже, как правило, в условиях жёсткого цейтнота. Выходит, что никто не видит всей картины в целом — ни со стороны заказчика, ни со стороны исполнителя.
В таких условиях проблема синхронизации данных в различных документах для целей стандартизации приобретает критический характер. В текстовом редакторе нет инструментов, позволяющих выполнить эту задачу.
Поскольку сейчас в большинстве технических заданий (ТЗ) на разработку ПП содержится требование представления технической документации именно в формате текстового редактора (обычно — Microsoft Office Word), получается, что заказчик сам пилит сук, на котором сидит. Максимум, что он может получить, — это актуальную документацию на конкретную дату сдачи-приёмки ПП. Обычно — лакированную картинку, подготовленную техническими писателями и подогнанную под формальные требования нормативных документов. Подготовленную не теми, кто непосредственно вёл разработку, а теми, кто зачастую даже не представляет себе работу ПП.
Идеальным техническим решением проблемы может стать непрерывное (синхронное) изменение документации при внесении изменений в программный продукт. На сегодняшний день разработаны необходимые технологии, обеспечивающие этот процесс на основе средств контроля версий, текстовой разметки документации, автоматического тестирования и генерации документации. (Подробные примеры технических решений приведены в докладе коллеги на конференции Heisenbug 2022 Spring: здесь.)
Что же мешает руководителям реализовать эту очевидно эффективную технологию? Не всё здесь зависит только от работы программистов. Ключевое значение приобретает качество организации процесса разработки и сопровождения программного продукта.
Любая изначальная документация на разрабатываемое ПО, как правило, имеет ряд требований к инфраструктуре, взаимодействию со смежными системами и т. п. Таким образом в документации появляются значительные куски, актуальность которых невозможно обеспечить, действуя только в рамках разработки конкретного ПО.
В реальности же мы чаще имеем ситуацию, когда разработчик отлаживает ПО в соответствии с заданными конкретно ему требованиями, а остальные участники процесса выступают в роли зрителей и судей.
Наличие внешних требований в ТЗ должно автоматически вести к вовлечению в данный процесс всех причастных «смежников» — как правило, владельцев инфраструктуры и разработчиков смежных систем. По каждому такому куску документации должны быть разработаны частные ТЗ, обеспечивающие в том числе автоматическую синхронизацию документации.
Руководителю важно понимать, что знание технологий непрерывного документирования требует определённой квалификации ИТ-специалиста. Неумение документировать свою работу говорит о низкой квалификации программиста.
К сожалению, нередки ситуации, когда организация-разработчик и программист сознательно оформляют документацию таким образом, чтобы сторонний специалист не смог разобраться в коде (обфускация документации) и клиент вынужден был дополнительно платить за каждый «чих». В этом случае, если вы выступаете в роли заказчика и эксплуатанта ПП, есть повод задуматься о целесообразности сотрудничества.
Для стандартизации структуры документации необходимо чётко ориентироваться на требования ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов».
Повторю ещё раз: обеспечение актуальности технической документации — обязательное условие проведения стандартизации ПП.
2. Переход на отечественное ПО.
По сути, это всего лишь красивый лозунг, который в ряде случаев может даже привести к печальным последствиям. Рассмотрим пару примеров.
Шрифты. Шрифтами в России много лет занимается компания «Паратайп». И хотя с визуальной стороной дела у компании, на мой взгляд, всё обстоит прекрасно, техническая часть явно недоработана. (С аргументированной критикой шрифтового дела компании «Паратайп» можно ознакомиться здесь.) Если оставить в стороне вопросы создания хорошо читаемого текста, то основной проблемой отечественных шрифтов можно назвать отсутствие ряда общепринятых символов. Скажем, то же семейство шрифтов Liberation, распространяемое по открытой лицензии OFL, значительно функциональнее.
Офисные пакеты. В условиях санкций российские компании начали активно отказываться от использования Microsoft Office. В частности, ряд органов государственного управления заявил о переходе на МойОфис. Однако отечественные альтернативы явно уступают Microsoft Office в функционале. (С результатами тестирования офисных пакетов Р7-Офис, МойОфис, LibreOffice и Microsoft Office можно познакомиться здесь.)
Пока что оптимальной альтернативой для разработчиков ПП является только LibreOffice. Из всех рассматриваемых это единственный офисный пакет, который распространяется по лицензии свободного ПО.
В текущей политической ситуации оптимальным для государственного управления решением было бы принятие аналога закона Итальянской Республики (2019), обязывающего публиковать всё разработанное для государственных нужд ПО как Open Source (открытое ПО). (Подробнее об итальянском законе можно прочитать здесь.)
В целом же, прежде чем бросаться покупать отечественные аналоги, необходимо для начала определиться со стратегией развития стандартизации.
3. Координация деятельности участников процесса стандартизации
Определившись с ключевыми техническими решениями по стандартизации, необходимо создать инструмент, с помощью которого все заинтересованные лица смогут получить доступ к актуальной информации по ним и, что очень важно, — к примерам их использования для решения конкретных задач. Таким инструментом может стать специальный портал со вшитой в него автоматической генерацией документации на стандартные технические решения. Это создаст организационные условия синхронизации изменений во всех ПП организации с текущей версией стандарта. Делать портал закрытым или открытым — это зависит от ИТ-стратегии организации. Пример такого портала можно посмотреть здесь.
Заключение
Как видим, организация работ по стандартизации достаточно проста, технические проблемы решаемы. Основные управленческие проблемы будут связаны с отсечением структур и специалистов, занимающихся ловлей рыбы в мутных водах информатизации и цифровизации, и организацией постоянной совместной творческой работы ИТ-специалистов, привыкших к высокой степени самостоятельности в своей деятельности.
Для организации эффективного взаимодействия персонала целесообразно хорошо знать и уметь использовать принципы менеджмента качества. В эту тему не требуется глубокого погружения. В последние 20 лет в мире идёт мощный тренд на снижение качества выпускаемой продукции. Наглядный пример – ситуация в автомобилестроении. Поэтому опасно использовать опыт современных «передовых» компаний. Достаточно ознакомиться со взглядами классиков (Г.Форд, В.Шухарт, Э.Деминг, Дж.Джуран, К.Исикава, А.Фейгенбаум, Г.Тагути и др.) чьи идеи прошли проверку временем и дают реальный практический результат.
Надеюсь данный текст поможет облегчить решение стоящих перед вами задач.
