Про вартість розробки та впровадження державних сайтів та реєстрів

В соціальних мережах, блогах та ЗМІ часто виникає дискусія щодо величини бюджетів на створення тих чи інших державних сайтів, сервісів чи реєстрів. Особливо гостро дискусія розгорілась на фоні розробки сервісу подачі електронних декларацій. В пресі то тут, то там з’являються публікації, що викривають “розпилювання" та "відмивання" коштів, витрачені “кругленькі суми” з думками “експертів”, які стверджують, що програмне забезпечення можна зробити майже безкоштовно (посилання не даю спеціально, щоб не поширювати ці “шедеври”). В цій статті мені хотілось би поговорити про розробку державних сервісів і про те, скільки це може коштувати, і, саме головне, чому.

В світі ⅔ проектів по розробці програмного забезпечення виконуються, як мінімум, з 25% перевищенням початкового бюджету і строків. Враховуючи, що над цими проектами працюють високопрофесійні і високооплачувані спеціалісти, то зі сторони такий факт може викликати подив. Насправді, спрогнозувати точну вартість розробки ІТ продукту досить важко, і саме тому всі оцінки є дуже приблизними.

Також в ІТ сфері поширений так званий трикутник “якісно”-”швидко”-”дешево", за допомогою якого можна швидко пояснити замовнику, чому швидко, якісно, дешево не буває.

Якісно + Швидко = Дорого
Дешево + Якісно = Повільно
Швидко + Дешево = Криво

Або:

• хочете швидко і якісно – ціна буде високою
• хочете дешево і швидко – постраждає якість
• хочете якісно і дешево – потрібно буде почекати

У випадку з державними сервісами чекати довго ми (громадяни) навряд чи захочемо, а якість 100% має бути високою. Тому що залишається? Правильно. Це буде дорого.

Що потрібно для того, щоб зробити якісний державний сервіс? Давайте розглянемо це питання детально (в контексті українських реалій).

1. Наявність експертизи в тій чи іншій сфері. У нашому випадку реальна експертиза розробки державних сервісів є лише у деяких маловідомих компаній, що працюють виключно на державний сектор (часто - це кишенькові компанії). Технічний рівень таких компаній зазвичай низький. Натомість у великих і професійних ІТ компаній немає досвіду роботи з державним сектором. Відповідно, одразу виникає питання - брати низькоякісних спеціалістів з розумінням предметної області чи високопрофесійних спеціалістів без розуміння того, як працює держава і її сервіси. Звісно, найкращим варіантом було б створення незалежного підрозділу чи агентства або незалежної гібридної ІТ команди, але будь-який подібний варіант приречений на критику на кшталт “а судді хто?” і звинуваченнями в кумовстві і відмиванні коштів.
2. Наявність чіткої постановки задачі. Думаю, що всі, хто читав технічні завдання на розробку державних сервісів, знають, якої якості ці документи. Проблема в тому, що їх складають, зазвичай, не технічні люди, а тексти прописані таким чином, щоб уникнути деталізації (і, як наслідок, відповідальності за майбутній потенційний факап), що є критичним для будь-якого проекту. Не раз спостерігав, коли міжнародні фонди чи міністерства виділяли кошти на розробку того чи іншого програмного продукту, проте не виділяли на розробку технічного завдання. Відповідно, іллюстрацію правила “Shit in. Shit out” можна спостерігати майже на всіх державних сайтах і сервісах.
3. Наявність високопрофесійних спеціалістів. ІТ спеціалісти - дорогі, причому в усьому світі. Є один нюанс - для розробки державних сервісів потрібні не просто хороші спеціалісти, а дуже хороші (часто - найкращі). Різниця в продуктивності і якості рішень просто хороших і найкращих спеціалістів - на порядок. Відповідно і коштують вони на ринку праці набагато більше. Крім, безпосередньо, розробників програмного забезпечення потрібні також спеціалісти по юзабіліті, безпеці, дизайну, підтримці, роботі з великими даними, devops тощо. Просто тому що а) державні сервіси працюють з персональними даними б) є високонавантаженими в) ними буде користуватись велика кількість людей г) ними будуть користуватись люди з обмеженими можливостями д) ними будуть користуватись на різних платформах, браузерах, пристроях е) ними будуть користуватись в абсолютно різних умовах, де не завжди буде хороший інтернет тощо. Звісно, щоб виконати всі умови, команди з двох-трьох людей не вистачить.
4. Необхідність забезпечити захист персональних даних. А, отже, програмне забезпечення має будуватись за зовсім іншими правилами і проходити низку додаткових тестів та перевірок.
5. Необхідність проходження сертифікацій та низки державних інстанцій. А це займає багато часу. Реально багато.
6. Необхідність створення детальної документації. Чим часто можна знехтувати при розробці звичайних сервісів. В цьому ж випадку документація має бути детальною, якісною (плюс відповідати всім бюрократичним правилам і законам). До речі, зараз до 70% бюджетів витрачається на документацію і бюрократію.
7. Необхідність забезпечити навчання персоналу. А це можуть бути тисячі людей в різних містах і областях, більшість з яких не завжди вміють користуватись навіть звичайним програмним забезпеченням. А це - тренінги, документації, навчальні відео, конференції, відрядження тощо.
8. Забезпечення підтримки програмного продукту. Уявіть собі скільки потрібно ресурсів щоб обробити, наприклад, пару тисяч звернень в день. Уявили?
9. Затрати на ліцензії (бази даних, операційні системи, додаткові компоненти, оновлення програмного і апаратного забезпечення).
10. Необхідність забезпечення інтероперабельності. Інтероперабельність - це здатність продукту або системи, інтерфейси яких повністю відкриті, взаємодіяти і функціонувати з іншими продуктами або системами без будь-яких обмежень доступу і реалізації. Простіше кажучи, здатність різних програмних продуктів взаємодіяти між собою. Зазвичай інтероперабельність забезпечується завдяки API та підтримкою галузевих стандартів. На жаль, про інтероперабельність багато хто говорить, проте мало хто робить.

Як можна побачити з цього списку, створення державного сервісу - це не лише РОЗРОБКА, а ціла низка інших задач, кожна з яких вимагає величезного обсягу роботи.

І все таки, скільки може коштувати розробка тої чи іншої системи? У мене немає детальної інформації про вартість розробки всіх державних сервісів в світі і Україні, тому буду користуватись даними, що доступні у відкритому доступі.

Зараз піде трохи зради, тому занадто вразливих прохання перестати читати статтю далі.

Отже, АІН наводить ось такі дані про державні реєстри:

Всього в Україні більше 135 держреєстрів, які належать більш ніж 40 органам. Найбільше реєстрів контролює Мін'юст (20), Фіскальна служба (15), МВС (12). На утримання кожного реєстру держава витрачає в середньому 21 млн грн на рік. Основні статті витрат: апаратне забезпечення - 45,91%; захист інформації, модернізація систем, сервісне обслуговування і підтримка - 40,13%.
Абсолютна більшість реєстрів - 78,26% - держоргани зберігають на локальних ЦОД або серверах. «Більшість державних ЦОД використовують застаріле обладнання і зажадають комплексної техніко-логічної модернізації протягом трьох років». Приватне хмара у оператора ЦОД орендують для реєстрів в 17,39% випадків. Що стосується безпеки, то лише у 60% держреєстрів є атестовані комплексні системи захисту інформації (КСЗІ).
Окремо дослідники розглянули проблему взаємодії держреєстрів між собою. Його нестача призводить до дублювання інформації і погіршення надання держпослуг. Так близько 80% полів в Єдиному демографічному реєстрі та Держреєстрі актів цивільного стану тотожні.

Кожного місяця один-єдиний реєстр обходиться в середньому 1.75 млн грн (~66.5 тис. доларів). Один реєстр. Кожного місяця. Нагадаю, що це ті самі реєстри, які не синхронізовані між собою, де присутня купа мертвих душ, немає API і експорту у вигляді відкритих даних.

Якби ці кошти виділялись на стартапи, то кожного місяця 135 стартапів могли б отримати по 66.5 тис. доларів - суму, що в 1,5-2 рази більша за середній чек на пре-сід раунді в більшості країн світу. І це лише реєстри.

Скажу чесно. Ці суми не є великими в порівнянні з бюджетами ІТ департаментів більшості розвинених країн. Проте в українських реаліях це величезні суми. Особливо пікантною виглядає ситуація на фоні того, що 80% державного сектору сидить на піратських копіях програмного забезпечення і 40% систем не пройшли навіть внутрішню сертифікацію щодо безпеки.

І все таки, скільки може коштувати розробка нормального повноцінного сучасного державного порталу чи сервісу?

It depends. Але справедлива оцінка затрат на розробку та впровадження для середніх компаній - 200-400 тис. доларів, для великих компаній - 300-600 тис. доларів, для корпорацій та професійних зарубіжних компаній - 1-2 млн доларів. Важко повірити, знаю. І враховуючи, який батхерт піднявся з приводу гонорару Джамали, що склав без малого 1 млн грн, мало хто притомний і чесний в Україні захоче братись за таку задачу. Можна потім і не вибратись з-під лайна, яке 100% поллється на компанію - розробника програмного забезпечення. Це як мінімум. Як максимум, прийде маски-шоу. Тому програмне забезпечення у нас роблять не відомі в світі компанії - розробника програмного забезпечення, а невідомі широкому загалу компанії з сайтом в стилі “привіт із 80-х”.

Маємо дуже фігову ситуацію. Замість win (держава отримує працюючий сервіс високої якості) - win (компанія-розробник отримує прибуток і платить податки) - win (громадяни отримують зручний і робочий сервіс) отримуємо lose (витрачені кошти державою чи міжнародним фондом) - lose (нормальний бізнес не отримує замовлення або отримує потоки лайна і маски-шоу) - lose (громадяни отримують дуже поганий сервіс).

І все-таки, чому такі бюджети на розробку якісних державних сервісів вигідні?

1. Вони економлять купу часу пересічним громадянам. А, отже, громадяни витрачатимусь більше часу на роботу, дозвілля, сім’ю.
2. Вони економлять час державним органам, а отже, немає сенсу утримувати величезний штат не ефективних співробітників.
3. Спрощення процедур означатиме підняття країни в різних рейтингах, а це, в свою чергу, дає сигнал бізнесу і інвесторам.

Звісно, в цьому місці багато хто може сказати, що автор просто виправдовує роздуті бюджети (тут ще любителі відкритого програмного коду з’являться і деякі колишні топ-менеджери фінансових установ, які на словах можуть зробити все майже безкоштовно) і, можливо, сам хоче сісти на “потоки”.

Але зачекайте піддавати автора анафемі і спалювати його на вогнищі. Дочитайте статтю до кінця.

По-перше, на державному рівні відсутнє розуміння того, як будувати програмні комплекси. Є окремі острівки адекватності, проте на загальному рівні переважна більшість ІТ систем - це ізольовані програмні продукти без жодної сумісності з іншими системами, часто - з загубленим програмним кодом або кодом, що належить стороннім компаніям, і без підтримки останніх 10-15 років.

По-друге, більшість державних сервісів та сайтів, що робляться за умовних 100-200 тис. грн - це, по суті, косметичний ремонт старих фасадів, які ось-ось розваляться (або вже розвалились). По факту - витрачені кошти. Сайти та сервіси, які створюються в 2017 році, повинні відповідати сучасним вимогам та викликам, а саме:

• мати повну локалізація контенту, як мінімум, англійською мовою;
• бути доступними для людей з обмеженими можливостями;
• враховувати підхід mobile-first та cloud-first;
• мати можливість експорту у машинночитабельні формати;
• мати API;
• мати уніфікований стиль та юзабіліті;
• бути інтероперабельними;
• бути оптимізованими для пошукових систем та соціальних мереж;
• сторонні організації повинні мати можливість створювати додаткові сервіси поверх державних сервісів.

Як багато програмних продуктів чи державних сервісів, що відповідають цим вимогам ви можете назвати? Не так багато.

Тому ні за 50 тис., ні за 100 тис., ні за 300 тис. грн новостворені чи вдосконалені сайти держадміністрацій, “унікальні” міські портали по відкритим даним не потрібні. Просто тому, що всі ці портали ментально і функціонально залишились в 90-х, і в даний момент не виконують жодну корисну функцію. В той час, коли весь світ йде в хмару, створюючи велику кількість мікросервісів, що взаємодіють між собою, а також механізми віддаленного керування бізнесом та голосування на виборах з будь-якої точки земної кулі, в Україні змінюють шрифти і іконки, і шарахаються від слів “API” та “markdown”.

Ось невеликий перелік задач, на які потрібно звернути увагу перед тим, як створювати нові державні сервіси та портали:

1. Створити єдиний уніфікований стиль державних сайтів (читай - брендбук), де будуть прописані основні вимоги до юзабіліті, структури, дизайну, API, безпеки тощо.
2. Створити уніфіковані сервіси, що будуть використовуватись іншими програмними засобами (пошук, авторизація, засоби для імпорту та експорту даних, реалізація BankId/MobileId у вільному доступі для всіх платформ та технологій).
3. Створити єдиний механізм взаємодії з сервісами міста/країни (такий собі персональний кабінет), де можна буде отримувати всю інформацію від державних органів, подавати запити та отримувати на них відповіді.
4. Створити уніфіковані платформи, що вирішують ті чи інші вузькоспеціалізовані задачі, наприклад, портал “бюджет участі” чи “система петицій” (деякі з таких платформ уже функціонують).
5. Створити механізми (юридичні та технічні) щодо подальшої підтримки сервісів.
6. Створити бізнес моделі, за допомогою яких державні сервіси будуть отримувати кошти на свій розвиток та підтримку, громадяни - якісні сервіси, а бізнес - прибуток завдяки створення додаткових сервісів та покращенного сервісу.
7. Провести інформаційну кампанію серед населення, під час якої детально розповідати про всі моделі, процеси та бюджети та переконати громадян в тому, що процеси будуть відкритими і прозорими.

І саме головне. Для якісного стрибка в цьому напряму потрібно повністю змінити логіку дій (читай - архітектуру технічних рішень). На сьогодні алгоритм дій про цифровізації тих чи інших процесів виглядає наступним чином: вчора ви мали принести довідку, що видав орган А, сьогодні ж - ви маєте принести цю саму довідку, проте її можна замовити через інтернет або ви можете записатись на прийом до чиновника, що видасть вам цю довідку через інтернет. Як на мене, саме сумне тут те, що люди з радістю лайкають і поширюють саме 2 і 3 варіант замість того, щоб вимагати заборонити довідки в будь-якому вигляді - паперовому чи електронному, оскільки це задача державних органів отримати цю інформацію про своїх громадян, а не громадян.

Для цього потрібно повністю змінити логіку. Замість того, щоб автоматизовувати чи оцифровувати хаос - потрібно абстрагуватись від всіх проблем, заборон, обмежень і спроектувати бізнес-процес так, як би він мав працювати в ідеалі. І потім паралельно починати впроваджувати цей бізнес-процес на державному рівні, після чого здійснити заміну старого процесу.

Приклад:

Соціальна допомога при народженні дитини.

Раніше. В пологовому будинку дають довідку при народженні. З довідкою потрібно йти в РАГС, де дадуть свідоцтво про народження. Зі свідоцтвом про народження потрібно йти в банк і відкривати спеціальний соціальний рахунок. Зі спеціальним рахунком потрібно йти в службу соціального захисту і оформлювати допомогу. Через певний час гроші починають поступати на рахунок сім’ї.

Зараз. В пологовому будинку дають свідоцтво про народження. Зі свідоцтвом про народження потрібно йти в банк і відкривати спеціальний соціальний рахунок. Через форму на сайті потрібно завантажити скани документів для оформлення допомоги. Через певний час гроші починають поступати на рахунок сім’ї (тут можуть бути певні неточності, оскільки процес був описаний в публічних джерелах і я не може бути впевнений за 100% достовірність).

Як повинно бути? В пологовому будинку дають свідоцтво про народження і банківську карту з коштами на ній.

Відкриття рахунку, прив’язку до місця проживання/прописки, заяви і інші речі повинна робити держава або приватний бізнес. Громадяни в даному випадку повинні народжувати дітей і користуватись допомогою, що гарантована державою.

Висновки

Всі ці думки неодноразово були озвучені під час робочих зустрічей з громадськими організаціями, міжнародними фондами, державними агентствами та представниками різних міністерств. На жаль, поки що великого оптимізму ці розмови не викликають, хоча і позитивних зрушень є чимало.

Всі ідеї, озвучені в статті, використовуються нами для створення та розвитку проекту ДонорUA. Сподіваюсь, що ці ідеї знайдуть своє місце в інших організаціях та державних сервісах.

Оригінал: Блог проекту ДонорUA - швидкий пошук донорів крові.