Как создать крутой ИТ продукт для государства
Украина взяла курс на цифровизацию: отдельное министерство, регулярные релизы цифровых государственных сервисов, признание электронных документов. И это начало. Новые идеи требуют внедрения, а это — огромный рынок ИТ-услуг.
Отже, як державні установи купують нові ІТ-сервіси? Спойлер: непросто.
Новий ІТ-продукт для держави. Де взяти?
Якщо ви хочете новий ІТ-продукт, у вас є три основні шляхи: купити один з наявних на ринку, розробити власноруч або замовити у профільної компанії за вашими вимогами.
З першим все відносно просто: шукаєте потрібне рішення, оцінюєте пропозиції та купуєте. За потреби — разом із налаштуванням. Такий шлях підходить для стандартних продуктів (е-комунікації, CRM, ERP, інші сервіси широкого вжитку). Коли ж йдеться про унікальні сервіси — доводиться або робити самим, або замовляти. Самостійна розробка має свої переваги: з’являється внутрішня експертиза, можна швидко адаптуватись до змін, а будь-яка задача береться в роботу «тут і зараз». Але де взяти власну команду? Боротися за таланти доводиться не тільки з українськими компаніями, а і з усім світом.
Реалістичніше замовити новий ІТ-сервіс у компаній, що розробляють програмне забезпечення. Таких в Україні тисячі, сам бізнес-напрям існує десятки років. Тож, що може піти не так? Насправді тут є всього два запитання: що і як купувати? Тут у гру вступає Закон «Про публічні закупівлі».
Заручники стандартів
Реформа державних закупівель вважається однією з найуспішніших. Однією з її сильних сторін є універсальність: механізм прозорих тендерів дозволяє купувати державі будь-що за єдиними правилами. Періодично ми всі усміхаємось із закупівлі одного пиріжка або поліетиленового пакета, але визнаймо: для переважної більшості закупівель чіткість і конкретність опису лота є беззаперечним благом. На тендері постачальники змагаються лише ціною, а предмет закупівлі залишається незмінним.
Добре оформлений тендер містить вичерпний опис того, що ми купуємо. Але чим складнішим буде предмет закупівлі, тим важче сформувати вичерпні вимоги для потрібної функціональності. Коли йдеться про закупівлю чогось унікального, перелік вимог до предмета перетворюється зі специфікації у технічне завдання — набір документів з максимально детальним описом об'єкта та його поведінки в різних обставинах.
Що ж саме потрібно написати в техзавданні? Існує багато стандартів, коли можна використовувати заздалегідь розроблені форми документів. Це добре працює, наприклад, в будівництві: всі учасники процесу, від архітектора до виконроба, однаково читають типові документи.
Але що робити, коли стандартів немає? Для ІТ-розробок, на папері існує 126 різноманітних ДСТУ/ГОСТ, датовані від 1978 до 2009 років. Уявіть, найновішому стандарту вже 12 років. І це в галузі, де підходи і технології можуть докорінно змінюватись за рік-два.
Гнучкі рішення
Бізнес-вимоги до програмного забезпечення змінюються. Часи, коли можна було спершу їх зафіксувати, а через кілька років, коли проект відбудеться, почати використовувати, лишились в 90-х. У випадку з державним сектором є ще й категорія обставин, які неможливо ані передбачити, ані відвернути. Це зміни до законодавства. Бувають ситуації, коли незначна, на перший погляд, правка в другорядний законопроект змушує терміново переробляти велику частину бізнес-логіки складних систем.
Бізнес вже давно вигадав рішення для обох обмежень. Це гнучкі методології розробки. На початку проекту фіксується візія і ключові цілі. А що саме і як буде зроблено, уточнюється вже в ході виконання проекту. Фактично ми кажемо, що «має стати добре», але що ми вкладаємо в це поняття і як цього досягатимемо — вирішуємо у процесі.
Гнучкі методології широко застосовуються вже десятиріччя і довели свою ефективність. Тож, чому б не використовувати подібний підхід і в держсекторі? Вся справа в закупівлі. Трохи раніше ми говорили, що хороший тендер — це тендер з максимально чіткими вимогами до предмету закупівлі. Але ж розробка за гнучкою методологією за своїм визначенням суперечить цій тезі. Замовник, прагнучи працювати за гнучкою методологією, просто не матиме, що написати в технічне завдання окрім візії і абстрактних цілей. А якщо все ж хтось спробує, то в кращому випадку на такий тендер ніхто не прийде, а в гіршому — халатний підрядник, користуючись пустою документацією, забере гроші, не зробивши нічого.
Лайфхаки від Прозорро.Продажі
Ми в Прозорро.Продажі знайшли шлях, який дозволив замовляти подібні продукти. Виявилось, що достатньо зробити декілька адаптацій відомих практик з управління проектами.
Time and Material — це підхід до формату проектів, коли замовник купує не результат, а процес. У випадку з ІТ-розробкою специфічні матеріали не потрібні: достатньо купити час спеціалістів і розумно ним скористатися.
Цей підхід має три важливі обмеження. По-перше, замовник має глибоко занурюватись в процеси. Підписати контракт і просто дочекатись результатів не вийде: в команді замовника мають бути люди, які координуватимуть роботу виконавця. Вони ж визначатимуться з пріоритетами та слідкуватимуть за якістю результатів. Така інвестиція часу себе виправдовує: команда замовника отримує кращий результат й експертизу для новоствореного продукту, що суттєво подовжує строк його експлуатації.
Друге обмеження — надлишкове використання ресурсів. Що як раптом замовник отримає рахунок на кількість годин вдвічі більшу від запланованої? Така ситуація — цілком реальний ризик, з яким стикається й бізнес. Тут допоможуть гнучкі методології.
Для ІТ-розробок, на папері існує 126 різноманітних ДСТУ/ГОСТ, датовані від 1978 до 2009 років
Ми взяли за основу методологію Scrum, адаптовану під реалії взаємодії з підрядниками. Практична користь для нас, як замовників, у плануванні роботи. Виконавець до початку роботи оцінює в годинах кожну окрему задачу. Відповідно, перед кожним циклом розробки (у нас це — два тижні) вже відома орієнтовна кількість годин, яку ми плануємо витратити. Умови договору, який укладає держпідприємство за результатами відкритих закупівель, вичерпно описують процес планування, допустиму похибку в оцінці, послідовність роботи над кожним завданням тощо. Вигадувати це не довелося. Класичні документи Scrum дають всю потрібну інформацію.
Ще одне обмеження — можливі зловживання. А раптом виконавець вирішить надурити та скаже, що робота зайняла 100 годин, хоча насправді на неї витратили лише 10? Тримати в штаті спеціалістів, які об'єктивно оцінять чесність виконавця, неефективно. Альтернатива, яку ми практикуємо — паралельна оцінка одних і тих же завдань різними виконавцями. Закон дозволяє проводити декілька тендерів на закупівлю годин спеціалістів «на вимогу» (коли у замовника з’являється потреба у використанні цих годин). Після укладання двох або більше подібних контрактів кожну задачу можна надавати для оцінки всім законтрактованим виконавцям. Фактичне замовлення врешті отримає учасник з кращою оцінкою. Загалом такий підхід нагадує рамкові закупівлі, а їх комбінація з практиками Scrum дозволяє ефективно керувати і процесом розробки, і результатом.