"Ми принесли державі понад 28 млрд гривень". Як працює ІТ-команда Prozorro.Продажі
Я Олександр Акуленко, заступник начальника відділу інформаційних технологій і телекомунікацій «Prozorro.Продажі». Це формальна назва посади. Фактично я відповідаю за створення і розвиток продукту. У цій статті розповім, як з інструменту для продажу активів банків-банкрутів Prozorro.Sale перетворились на інструмент для продажу та оренди будь-якого майна та активів. Ви дізнаєтесь, як зробити зі стартапу успішну реформу.
На мою думку, інформація про те, як розпоряджаються державним та комунальним майном, кому його продають або здають в оренду, має бути за замовчуванням відкритою для всіх громадян. Ключова ідея електронної торгової системи Prozorro.Sale і полягає в тому, щоб допомогти державі ефективно розпоряджатися майном, а громадянам — відстежувати цей процес.
Я приєднався до команди у листопаді 2016 року, за тиждень до проведення першого реального аукціону, і став шостим членом команди. У нас була підтримка з боку донорів і перших майданчиків, але ресурсів вистачало тільки на запуск першої версії системи. Одне з питань, яке мені ставили на співбесіді: «Чи є у тебе можливість принести власний стілець для роботи?» :)
Стілець приносити не довелось, але якийсь час потрібно було попрацювати на власному ноутбуці. Поки ми не змогли придбати техніку для команди. За час роботи системи ми провели 23,5 тисячі успішних аукціонів і принесли державі понад 28 млрд гривень.
Сергій Бут, фінасовий директор, та Олександр Акуленко, заступник начальника ІТ-відділу
Що таке «Prozorro.Продажі»
Дворівнева електронна торгова система (ЕТС) «Prozorro.Продажі». Ми визначаємо загальні правила роботи системи, відповідаємо за розробку і роботу центральної частини. Але не взаємодіємо безпосередньо з організаторами та учасниками аукціонів. Цим займаються комерційні майданчики, які за допомогою API підключаються до ЕТС. Наразі їх близько 40.
Схожий підхід усуває корупційні ризики, забезпечує конкуренцію і рівний доступ до торгів для всіх охочих, а також дає змогу надавати якісний сервіс організаторам та учасникам аукціонів. Кожен майданчик самостійно займається розробкою своєї частини. Відповідно у кожного свій стек і підходи до організації роботи.
На нашому боці залишається взаємодія зі стейкхолдерами, синхронізація з іншими відділами (з юристами та проєктними менеджерами), проєктування нових типів процедур продажу та аукціонів, підготовка технічних завдань для підрядників і майданчиків, координація і синхронізація їх роботи, тестування майданчиків, участь у розробці юридичних документів, якщо необхідно описати правила роботи системи або навпаки — спроєктувати та зафіксувати нові правила гри, відповідно до яких потрібно буде здійснити розробку й оновлення ЕТС.
Як усе починалось
Робота системи «Prozorro.Продажі» розпочалася із продажу активів ліквідованих банків у 2016 році. Ініціатором її створення став Фонд гарантування вкладів, якому потрібно було ліквідувати понад 90 банків-банкрутів. Не просто ліквідувати, а отримати ринкову ціну за продаж активів та забезпечити прозорість і довіру до цього процесу.
На той час система публічних закупівель Prozorro вже вийшла на національний рівень і її використання стало обов’язковим. Так і з’явилась ідея використати такий самий підхід і в інших державних сферах.
У червні відбулося підписання меморандуму щодо намірів співпраці у побудові в Україні прозорої та ефективної системи реалізації активів неплатоспроможних банків і банків, що ліквідуються. До меморандуму приєдналися Фонд гарантування вкладів фізичних осіб, Національний банк, Міністерство економічного розвитку і торгівлі та ГО «Трансперенсі Інтернешнл Україна». На базі ГО і сформували проєктний офіс, який займався запуском реформи і який потім трансформувався у державне підприємство «Prozorro.Продажі». Вже восени запустили електронну торгову систему і приєднали до неї перші комерційні майданчики.
Першу версію системи розробляв підрядник, який брав участь і в запуску системи для напряму закупівель — Quinta Group. На створення першої процедури продажу пішло три місяці. Бізнес-логіка була реалізована на Python, працювали с нереляційною базою даних CouchDB. Систему розгортали в AWS, активно використовували рішення EC2, S3, ELB, CloudWatch, CloudFront.
За час роботи продали майна та активів на більше як 28,5 млрд грн, середнє зростання стартової вартості під час аукціону становило 24%. Один з останніх прикладів — продаж готелю «Дніпро». Це найбільший аукціон в історії «Prozorro.Продажі». Стартова ціна з 80 млн грн злетіла аж до 1,111 млрд грн.
Такий вигляд має завершальний етап аукціону. Це був найбільший аукціон в історії «Прозорро.Продажі» — продаж готелю «Дніпро»
Ще один приклад: «Укрпошта», яка на перших 7 аукціонах з продажу нерухомості у червні
Для створення прототипу системи продажів ми використали напрацювання, які вже були у Prozorro. На перший погляд ідея здавалася простою: взяти наявний аукціон із публічних закупівель і «перевернути» його навпаки. Звичайно, завдання виявилось набагато складнішим, адже, окрім самого аукціону, треба було розробити все необхідне для проведення процедури продажу. Так ми почали розвивати свою систему окремо, з урахуванням специфіки аукціонів та окремих напрямів роботи.
Специфіка проведення аукціонів:
- Різні бізнес-процеси у різних напрямах роботи. У простих випадках достатньо провести аукціон і завантажити у систему договір купівлі-продажу, у складних — пройти шлях від публікації об’єкту приватизації у реєстрі до фіксації оплати та етапу виконання вимог організатора після завершення аукціону.
- Наявність кількох різновидів аукціонів з різною механікою роботи, які використовують відповідно до особливостей активів, що продаються. Наприклад, використання гібридного нідерландського аукціону з можливістю зниження стартової вартості на першому етапі аукціону для активів, у яких складно визначити ринкову стартову ціну.
- Автоматизація частини стадій. Наприклад, автоматичне проведення серії аукціонів з поступовим зменшенням стартової ціни, якщо попередній аукціон не відбувся через відсутність учасників.
- Робота з приватними документами у деяких випадках. Водночас за замовчуванням у більшості напрямів усі документи організаторів та учасників мають бути публічними.
- Різні вимоги до опису активів і валідації даних у різних напрямах роботи тощо.
Напрями, за якими працює «Prozzoro.Продажі», та суми, на які було реалізовано майна
Як працює ІТ-команда
Зараз IT-команда складається з 8 людей: BA, PM, системний адміністратор, двоє QA, спеціаліст з безпеки, CTO, Head of Product Development. Безпосередньо у штаті ДП «Prozorro.Продажі» розробників немає, основні завдання з розробки та адміністрування системи виконують підрядники. Сьогодні їх кілька, і вони відповідають за різні частини системи. Робота розділена так:
- Основна розробка системи: Python, MongoDB, React для фронтенду модуля аукціонів.
- Адміністрування системи: Amazon Web Services, CouchDB, MongoDB, OpenStack Swift Drive, Kubernetes. Стара версія працює в AWS, нову запускаємо у ЦОД на території України. До повного переходу на роботу з новою версією системи за всіма напрямами роботи адміністратор має одночасно забезпечувати функціонування старої версії.
- Тестування системи та майданчиків. Оскільки у штаті усього два QA, для виконання низки робіт з тестування періодично залучаємо сторонніх QC та QA-спеціалістів.
- Розробка та адміністрування публічного порталу: PHP, Python, ElasticSearch. Його досить давно не оновлювали й запустили з обмеженими ресурсами. Цього року плануємо почати масштабне оновлення порталу.
- Розробка та підтримка модулю аналітики: Qlik Analytics.
Основна комунікація з підрядниками та майданчиками відбувається у Slack, для роботи із задачами використовуємо Jira та Gitlab, для організації зустрічей — Google Meet.
Крім повсякденного спілкування щодо поточних завдань, проводимо регулярні зустрічі з підрядниками для синхронізації, планування подальшої роботи та обговорення важливих технічних і організаційних питань. Постійно експериментуємо з підходами та намагаємось оптимізувати як процеси всередині команди та компанії, так і процеси взаємодії з партнерами.
Особливість роботи над системою, яка визначає підходи до розробки — законодавче регулювання більшості напрямків (на рівні законів України або постанов Кабінету міністрів). З фіксацією конкретних термінів початку роботи за новими напрямами або змін до вже наявних.
Наше завдання — реалізувати всі необхідні зміни на центральному рівні, перевірити готовність майданчиків до роботи після внесення оновлень та синхронно з ними викласти зміни на продуктове середовище. І це все в умовах обмежених ресурсів. Тому використовуємо гібридний підхід до управління проєктами та розробки. Де це можливо, застосовуємо Scrum. Частина процесів більше схожа на Waterfall. Активно працюємо з MVP та пілотними проєктами. Це подібно до процесів у колег із Prozorro. Попри те, що це інша організація, у нас все ще багато спільного.
Представник IT-команди, зазвичай це Head of Product Development, інколи ще CTO, BA, QA або PM, бере активну участь у роботі над новим напрямом (наприклад, запуском малої приватизації або оренди державного та комунального майна через «Prozorro.Продажі») ще на етапі обговорення концепції всередині команди, підготовки законопроєкту або постанови КМУ. Це один з найкритичніших етапів, бо якщо тут щось не врахувати або написати вимоги, які потім технічно буде складно або дорого реалізовувати, виправити це буде майже неможливо. І це одна з ключових відмінностей від роботи у комерційному секторі.
Відтак формується ТЗ для розробки центральної частини ЕТС. Залежно від термінів, доступних ресурсів і конкретних даних це може бути або MVP для виконання основних вимог, збору та аналізу статистики та подальшого розвитку, або вже фінальна версія процедури продажу. Бувають випадки, коли фінального тексту документа, який визначає правила роботи, ще немає і є вірогідність внесення суттєвих виправлень. А терміни запуску вже є. Тоді ми беремо на себе певні ризики, формуємо ТЗ з урахуванням можливих змін, обговорюємо це з розробниками системи та майданчиків, окреслюємо варіанти та намагаємось розробити каркас процедури так, щоб у разі внесення змін не довелося все переписувати. ТЗ презентуємо розробникам і майданчикам, за потреби уточнюємо щодо технічної реалізації без принципової зміни бізнес-логіки. Далі створюється беклог задач, план запуску процедури на тестовому середовищі та план виходу на production.
Паралельно оновлюємо вимоги до майданчиків і складаємо план їх тестування. Як тільки віддаємо першу версію API нової процедури на тестовому середовищі, починається активна розробка на стороні майданчиків. І тестування їх у міру готовності. Якщо процедура складається з великої кількості етапів або ми дуже обмежені в часі, запуск функціоналу і тестування проводимо частинами. У найпростішому випадку це публікація інформації про аукціон і робота із заявами на участь, безпосередньо проведення аукціону та кваліфікація переможців після завершення торгів.
Після готовності перших майданчиків проводимо демо функціоналу організаторам аукціонів, враховуємо побажання до інтерфейсів майданчиків, якщо вони є, і запускаємо перші аукціони на проді. Збираємо статистику та зворотний зв’язок, дивимось, що можна поліпшити, вносимо зміни у систему або беремо участь у підготовці пропозицій для внесення змін до законів або постанов КМУ для того, щоб забезпечити розвиток системи у майбутньому.
«Prozorro.Продажі» — платформа, яка об’єднує системи електронної комерції. Всі організатори публікують інформацію про аукціони в центральній базі, після чого вона показується на всіх під’єднаних майданчиках. Відкриття даних спричиняє асиметрію інформації (у нашому випадку — інформації про предмет торгів і умови проведення аукціону в різних учасників). Щойно прибираємо асиметрію, все працює ефективніше: велика кількість підключених майданчиків забезпечує рівний доступ до аукціонів для всіх охочих і чесну конкуренцію. Це дає змогу організаторам продавати активи за ринковою ціною. А учасникам — придбати активи, доступ до яких раніше був обмежений або взагалі відсутній.
Під час розробки центральної частини ЕТС використовуємо рішення на базі open source. Вихідний код системи теж опубліковано у відкритому доступі під ліцензією Apache 2.0. Це один з наших принципів. Загалом вважаю, що державний сектор має віддавати перевагу open source рішенням. А вихідний код продуктів, створених за кошти платників податків або донорські кошти, має бути за замовчуванням відкритим (крім обмежених випадків, пов’язаних з державною таємницею та безпекою). Інформація про аукціони доступна у відкритому доступі у відкритому API. Всі охочі можуть використовувати ці дані для аналітики та моніторингу або ж створення додаткових сервісів.
Динаміка доходу. На сьогодні уже реалізовано майна на 28,71 млрд грн
Що далі, спитаєте ви...
Нещодавно ми завершили підготовку до проведення аукціонів з розподілу квоти підтримки «зеленої» енергетики. Запускаємо новий тип аукціонів для підвищення ефективності продажу необробленої деревини. Завершуємо останні приготування для проведення аукціонів з оренди державного та комунального майна, відповідно до постанови Кабінету міністрів, яку було нещодавно ухвалено. Займаємось проєктуванням системи для роботи з переліками майна, яке планують передати в оренду. Це дає змогу всім охочим спостерігати за тим, наскільки ефективно держава та органи місцевого самоврядування розпоряджаються майном. І маємо багато інших планів.
Нові типи аукціонів запускаємо вже on-premise, у дата-центрі на території України для того, щоб мати змогу пройти сертифікацію КСЗІ (комплексної системи захисту інформації) відповідно до вимог законодавства. Ми вирішили скористатись цією нагодою і написати систему «з нуля», враховуючи попередній досвід. Відмовились від прив’язки до сервісів AWS, використали Python 3.8 замість 2.7, підтримка якого була завершена на початку року, перейшли з CouchDB на MongoDB, частково змінили архітектуру системи, побудували повноцінний процес CI/CD. Реалізували можливість конфігурувати частину налаштувань аукціонів. Поступово плануємо перенести і всі теперішні напрями роботи в нову систему. Якщо все піде за планом, повне перенесення завершимо у другому кварталі 2021 року.
