На одном из мероприятий планируется доклад о качестве государственных сайтах и методах его повышения. Полный доклад готовит Иван Бегтин, я внесла несколько моих тезисов.
Начнем с того, что качество государственных сайтов упало после относительных высот, достигнутых в 2010-2011 годах. Тогда вступил в действие 8 ФЗ и регулирующее его исполнение Постановление Правительства, Минэкономразвития вел большой мониторинг исполнения всех пунктов, и за проблемы с исполнением устраивали иногда выволочки на уровне министров. Огорченный министр давал отрицательное подкрепление по всей цепочке ответственных и, в итоге, на ведомственном сайте появлялась информация о всех ФЦП, свежие документы и действующие телефоны департаментов. Сейчас фокус внимания сместился, и министерский портал может месяцами висеть с очевидным нарушением, и ничего не случится.
При этом, если брать последние 10 лет — то есть, примерный срок существования государственного веба в его современном виде, произошло еще несколько интересных вещей. Во-первых, внешний вид всех госсайтов улучшился. Монстров из начала нулевых осталось совсем мало.
Средний госсайт выглядит вполне себе аккуратненько. Что не делает его обязательно хорошим — вот в чем беда. Веселые нарядные лэндинги тоже делать (вернее, заказывать) научились.
Второе — появилось немногочисленное новое поколение очень больших и очень крутых госсайтов. Над ними работают годами огромные команды и получается продукт мирового класса. Я о kremlin.ru, который, в отдельных своих решениях даже слишком хороший и слишком сложный для своей задачи, возможно, после окончания бета-тестирования, таким же примером выдающегося городского портала нужно будет признать mos.ru. То, что эти мегапорталы у есть — хорошо для всех нас, то, что по ним меряют уровень развития всего госвеба и успокаиваются — плохо.
Третье обстоятельство состоит в том, что за официальными порталами ФОИВ еще есть какой-то присмотр, а десятки сайтов-сателитов живут своей бесконтрольной и часто довольно жалкой жизнью. Без правил, без мониторинга, многие — без открытой статистики.
Средний «главный информационный портал» может быть и таким:
с посещаемостью два человека в день, один из которых — я. Или таким:
с непонятной посещаемостью и метриками.
У нас даже каталога этих сайтов нет, никто толком не знает, сколько их. Что там говорить о мониторинге, сопоставлении ТЗ и результата, оценки достижения каких-то внятных ключевых показателей. Сколько стоит один контакт с гражданином на портале «Здоровье работающего населения»? С такой бурной посещаемостью, вероятно, очень дорого.
Поскольку я перестала быть разработчиком и стала консалтером, то есть, перешла на сторону заказчика, могу точно сказать, что нужно сделать для повышения качества государственных сайтов на фоне резкого снижения цены эффективного контакта с целевым пользователем:
- Начать указывать подрядчика и субподрядчиков на всех сайтах. Долгое время эта мысль вызывала брезгливое отторжение: «Что это мы, частную компанию рекламировать будем?», сейчас отношение начало меняться. Во-первых, это не реклама, и не стоит переживать, что разработчик наживет с упоминания на министерском сайте особый барыш. Я проверяла. Во-вторых, при всей номинальной прозрачности госзакупок, реальную картину, кто что наделал, увидеть невозможно. Свежий рейтинг разработчиков сайтов органов власти, госорганов и корпораций помогает плохо, потому что участвуют в нем только по самозаписи, обобщить информацию весьма затруднительно, ну и значительная часть ссылок на работы победителя не показана.
- Повышать культуру разработки ТЗ. «ТЗ и ЧТЗ по ГОСТу» все научились писать, потому что это очень легко: шаблон документа дает такой дикий объем, что о содержательной части можно особенно не беспокоиться. Я сейчас проделала небольшой эксперимент: отметила в техническом задании (не по ГОСТу) из конкурсной документации на разработку некого информационного портала с стартовой ценой около 10 миллионов рублей собственно описание работ и получилось:
первая часть — перечень нормативных документов, включая Конституцию Российской Федерации, и общие цели-задачи, длинная таблица — это тоже самое, что в выделенном зеленым, только с сроками этапов и названиями отчетных документов, которые еще раз повторяют содержание работ. Как вы понимаете, две страницы могут быть ТЗ для лэндинга или там блога на WP, но не здорового портала. Тем более, что и в содержательной части техзадания много общих выражений типа «единый дизайн представления веб-контента». И я знаю, как пойдет дело после заключения госконтракта: разработчик будет действовать сообразно своему пониманию ТЗ (минимизировать трудозатраты), заказчик или будет отжимать из разработчика объем работ сообразно своему видению результата, которого в документе просто нет, либо, если разработчик окажется наглым и зубастым, страдать. Все это приведет к суровым затратам времени с обеих сторон, общей нервности и не совсем тому результату, который изначально предполагал заказчик. Вы можете сказать, что исполнитель сам написал это недоТЗ, и все уже понятно, половина работ — сделана, но нет. Как раз это не тот случай, когда выставляется мегаконтракт с сроком выполнения в 1 месяц, да и там по-разному бывает.
- Проект и ТЗ необходимо делать отдельно от разработки по своему небольшому контракту, который может включать еще и проектное управление. Потому что составление ТЗ самому себе — конфликт интересов и нездоровая практика. 200-300-500 тысяч на этот контракт сэкономят несколько миллионов рублей: проработанное ТЗ снизит риски исполнителей, и они смогут не закладывать в цену неизбежные при непонятном техзадании переработки и переделки, на конкурс придут новые свежие игроки, готовые работать в прозрачной ситуации. Возможно, окажется, что все цели и задачи реализуются не разработкой нового решения, а готовым продуктом, который нужно только настроить.
- ТЗ на разработку, модернизацию/развитие и поддержку нужно публиковать на каком-то понятном одном ресурсе и давать возможность сопоставить заявленные требования с результатами
- И самое главное — основное условие создание качественных государственных сайтов — перенос практик, принятых в коммерческом секторе: UX, работа с пользовательскими сценариями, развернутая работа с аналитикой. Ни один подрядчик не покроет все своими компетенциями, поэтому при выполнении крупных работ нужно быть готовыми к созданию объединенной команды из нескольких организаций-смежников. В этой ситуации особенно важно проработанное ТЗ и проектное управление.
Это первая часть тезисов, продолжение следует.
