Каймар Кару: причиной оплошности с EIS стала не человеческая ошибка, а плохое управление

Если процесс, основанный на цифровых решениях, не работает ожидаемым образом, это не человеческая ошибка. Это симптом плохого управления и, следовательно, недостаточного сотрудничества, который под влиянием плохих практик управления еще больше усугубился после возникновения проблем, как в случае с экзаменационной инфосистемой (EIS), пишет Каймар Кару.
Человеческая ошибка как обоснование часто является лишь попыткой ответственных лиц избежать ответственности, в подобных ситуациях стоит помнить и об этом. Проблема в системе.
Инфосистемы, которые по своей природе являются социотехническими системами со значительным влиянием человеческого фактора, не существуют вне управленческих структур, процессов и процедур организации или предприятия.
Постановка новых требований к достаточно хорошо функционирующим инфосистемам и выполнение необходимых работ для их выполнения являются обычным циклом разработки программного обеспечения, успех которого в значительной степени зависит от технологических аспектов, но еще больше – от качества сотрудничества между заказчиком и исполнителем.
Несколько десятилетий назад основным подходом при разработке информационных систем был однократный цикл попыток предсказать будущее, основанный на обширном предварительном анализе, следовавшей затем этап обслуживания и развития был проблемой кого-то другого. Сильная зависимость от денег европейских фондов, которые способствовала широкому использованию водопадной модели даже в неподходящих ситуациях, еще больше способствовала внедрению плохой практики.
Современные практики в разработке программного обеспечения учитывают, что создаваемое решение никогда не готово окончательно, потому что со временем меняются как потребности, требования, возможности, так и риски.
Чтобы последовательный цикл разработки функционировал, необходимо тесное сотрудничество между всеми сторонами не только на этапе разработки, но и на всех этапах, от принятия решений и определения приоритетов до вывода решения из эксплуатации. Больше всего информации о сильных и слабых сторонах решения у тех, кто работает с ним ежедневно.
Управление услугами в рамках цикла разработки продукта предоставляет основанную на процессе поддержку для понимания потребностей и принятия наиболее подходящих решений. В его отсутствие принятие долгосрочных решений часто происходит без понимания всего комплекса решений и цепочки действий, необходимых для их функционирования.
Кажется, в случае EIS несколько звеньев в этой цепочке были нарушены.
Во-первых, не были поняты роли и ответственность. Делать небольшую команду разработчиков козлам отпущения после дошедших в итоге до широкой публики проблем и искажать это – вульгарно и недопустимо.
Проблемы, вызвавшие сложившуюся ситуацию, кажутся долгосрочными и связаны с недостаточно продуманными объединением различных ведомств и перемещением задач и ответственности. Отсутствие координации между министром, министерством и подведомственными учреждениями (в данном случае harno) проявлялось и раньше.
Также непонятно, почему разработка такого рода инфосистемы проходила в структуре министерства так долго. Вопрос не в качестве проделанной работы, а в том, заключается ли роль Министерства образования и науки в разработке программного обеспечения, или фокус и необходимые компетенции министерства носят более стратегический характер.
Во-вторых, не поняли критичную важность приложения. Это непонимание с годами сказалось на финансировании, выборе технологий, а также на том, что наши ученики неожиданно оказались в роли тестировщиков системы в напряженный экзаменационный период.
Даже в системах, менее критически важных, чем EIS, тестирование вариантов использования является одним из основных требований, а не дополнительным действием, которое "было бы неплохо" сделать. Если разработчики системы не знают, как она будет использоваться, большей надежды на успех нет. Ответственность высшего руководства и менеджеров среднего звена заключается в том, чтобы донести понимание критической важности системы до менеджеров по продуктам и услугам и поддержать их необходимым вниманием и финансированием.
В-третьих, не была понята необходимость управления рисками. "Надежда на лучшее" не является для решения с таким количеством разных типов пользователей и множеством взаимозависимых компонентов подходящей стратегией. Также неприемлемо, когда в случае возникновения совершенно непредвиденных проблем отсутствуют предварительно подготовленные сообщения и четкий резервный план.
Параллельно разработанная и логистически подготовленная полномасштабная бумажная альтернатива поднимает вопрос об обоснованности затрат на цифровое решение, но риски также можно снизить, рассматривая различные аспекты один за другим. Четкое сообщение "продолжим через час", распределение нагрузки во времени, снижение зависимости от различных технологических аспектов общего решения (сетевое соединение, нагрузка на сервер и т. д.) – все это разумные шаги, которые следует рассмотреть и поддержать.
В-четвертых, не понятен целостный взгляд на приложение. Пользователи системы являются частью системы. Почему для разработки задач был выбран подход, который ранее не был достаточно протестирован, почему вообще можно было использовать непроверенный подход?
Критика неправильного использования системы или использования "неправильных" типов задач указывает на непонимание потребностей пользователей, недостаточную подготовку пользователей и пренебрежение уязвимостями системы.
Если возможные опасения были упущены разработчиками системы, вероятная причина в том, что разработчики и пользователи слишком отделены друг от друга. Однако еще более вероятная причина заключается в том, что риски, указанные разработчиками, либо не были поняты, либо просто игнорировались на протяжении многих лет.
Чиновники, ответственные за организацию экзаменов, должны иметь представление обо всей цепочке, включая используемые технологические решения и основные технологии, необходимые для их работы (включая сетевые сервисы). Если уязвимости решения им неизвестны или ими невозможно управлять, окружающая их система сломана.
В-пятых, не было понимания, что сделанные ранее выборы и решения должны время от времени пересматриваться.
Если на момент первоначального создания EIS на рынке действительно могло не хватать коммерческих решений, необходимых для школьной системы Эстонии, поскольку мы во многом опережали других с точки зрения цифровой инфраструктуры и пожеланий, то сейчас рынок существенно продвинулся вперед.
Хотелось бы надеяться, что в свете проблем и уроков EIS другие министерства и учреждения в своей административной сфере также получат поддержку со стороны политиков и высшего руководства учреждений, чтобы пересмотреть свежим взглядом риски и распределение ролей, а также привести выбранные подходы и методики в соответствие с хорошей практикой.
Редактор: Елизавета Калугина