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

З чого починається розробка програмного забезпечення?

Хтось скаже, що з написання технічного завдання, хтось — із опрацювання вимог, інші — з первинної оцінки вартості проєкту. Ми вважаємо, що розробка ПЗ починається з демонстрації Замовнику усвідомленого розуміння його вимог та бізнес-цілей.

Якщо розробник не розуміє глибинних мотивів, що спонукали Замовника до автоматизації процесів, він ніколи не зможе створити корисний продукт. У найкращому разі такий процес перетвориться не на випуск закінченого рішення, а на нескінченне доопрацювання «латок» за ваш рахунок.

Опрацювання проблематики та гнучкі межі проєкту

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

Практика — річ уперта: неможливо створити складний програмний продукт, який задовольнить реальні потреби бізнесу, якщо рухатися виключно за первинними паперовими інструкціями. У процесі живої розробки завжди виникають зміни.

Наприклад, під час розробки системи передачі даних через зовнішні причини (вимоги регулятора, зміна структури датчиків або протоколів зв'язку) може бути змінено сам алгоритм передачі пакетів. Без оперативного та гнучкого впровадження цієї зміни все готове програмне рішення в одну мить стане абсолютно марним для бізнесу.

Планування без ілюзій та розстановка пріоритетів

На наступному етапі мы затверджуємо детальний project-plan. Головне завдання тут — жорстка розстановка пріоритетів та фіксація реальних термінів. І замовник, і команда інженерів мають чітко бачити контрольні дати, склад етапів, архітектуру завдань та залучені ресурси.

Багато ІТ-компаній взагалі не надають клієнту project-plan. Замість нього вони дають три абстрактні оцінки: мінімальні, середні та максимальні терміни. Такий підхід на практиці свідчить лише про одне — ці підрядники до кінця не розуміють потреб вашого бізнесу і намагаються застрахувати власну невизначеність за рахунок вашого часу та бюджетів.

Програмування, безперервний контакт та здача проєкту

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

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

Після завершення розробки та фінального навантажувального тестування наша робота не закінчується. Ми беремо на себе відповідальність за легкий онбординг: допомагаємо команді Замовника швидко та безболісно адаптуватися до нового софту, впроваджуючи жорсткі автоматичні правила контролю, які захищають користувачів від «людського фактора».

Головний секрет якісного ІТ-продукту

Очевидно, що по-справжньому надійний продукт, який працює, може створити лише злагоджена КОМАНДА. І до цієї команди, крім нашого проджект-менеджера, архітекторів, розробників та QA-тестувальників, обов'язково входить повноважний представник з боку Замовника. Тільки в такій синергії ІТ-інструменти стають реальним важелем для зростання вашого бізнесу.