Що я зрозумів про розробку, роками спостерігаючи за програмістами збоку

Роки, проведені в бізнесі, особливо у сфері, далекій від IT, навчили мене однієї важливої речі: між «хочу» та «як це зробити» у світі програмування лежить справжня прірва. Я не програміст за освітою – мій шлях почався зі спорту, живопису, а потім економіки та ландшафтного дизайну. Проте, з початку 90-х років, коли я керував НПФ «Алькар» і ставив завдання програмістам з управлінського обліку, і до створення formspace.design у 61 рік, я постійно стикався з розробкою. І ось що я зрозумів про неї, спостерігаючи збоку.

Прірва між "хочу" та "як це зробити"

Найперше і, мабуть, головне, що я усвідомив – це фундаментальна різниця в мисленні. Підприємець, практик, мислить категоріями завдань та рішень для клієнта: «Нам потрібно, щоб клієнт міг вибрати рослини за певними критеріями», «Мені потрібен звіт про маржинальність проєктів». Програміст же мислить категоріями коду, алгоритмів, структур даних, ефективності та масштабованості. Він не бачить кінцевого користувача так, як його бачу я. Для нього завдання «вибрати рослини за критеріями» розкладається на базу даних, фільтри, запити, інтерфейсні елементи тощо. І часто в цій трансляції втрачається суть. Наприклад, я можу сказати: «Потрібна CRM для ландшафтного бізнесу», маючи на увазі облік до 20 одночасних проєктів, з 20-30 параметрами для кожної рослини та складним циклом робіт. Програміст же може почати з базової CRM, яка підходить для будь-якого бізнесу, не заглиблюючись у специфіку.

Важливість чіткого ТЗ і чому воно завжди "недостатнє"

Я багато разів складав технічні завдання – спочатку для систем управлінського обліку в «Алькарі», потім для автоматизації процесів у «Дім і Сад». І щоразу, здавалося б, я прописував усе до найдрібніших деталей. Але після першої ітерації я розумів, що чогось не вистачає. Програмісти не читають між рядків, вони не здогадуються про контекст. Якщо я не вказав, що при розрахунку вартості мощення ділянки площею 50 м² з трьома типами плитки потрібно враховувати 5% на відходи та різні ціни на укладання для кожного типу, то розрахунок буде простим множенням площі на ціну. Це не їхня провина, це моя відповідальність як замовника. Я зрозумів, що чому технічний борг у бізнесі починається з поганого брифінгу – це прямий наслідок неповного, хай і об'ємного, ТЗ. Кожна невизначеність – це потенційна помилка або затримка.

Мислення програміста: не "що", а "як"

Програмісти – це інженери, які будують мости з коду. Їм важлива міцність конструкції, її ефективність, швидкість. Мені ж, як власнику бізнесу, важливіше, щоб міст вів куди треба і по ньому могли пройти люди. Це не означає, що якість коду не важлива, але пріоритети часто розходяться. Програміст може годинами оптимізувати запит, який виконується за 0.01 секунди, щоб він виконувався за 0.005 секунди, тоді як бізнесу важливіше, щоб з'явилася нова функція, яка приносить дохід. Ця різниця у фокусі – одна з ключових причин, чому різниця між продуктом від програмістів та продуктом від практика така велика. Вони бачать код, я бачу вирішення проблеми клієнта.

Технічний борг та його коріння в комунікації

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

Як я навчився говорити їхньою мовою (або хоча б розуміти її)

З роками я зрозумів, що єдиний спосіб подолати цю прірву – це самому наблизитися до розуміння логіки розробки. Це не означає, що я став професійним програмістом, але я почав вивчати основи, розбиратися в архітектурі систем, розуміти принципи роботи баз даних. А з появою ШІ, у 61 рік, я отримав інструмент, який дозволив мені не просто ставити завдання, а формувати їх, спілкуватися з «кодом» безпосередньо, перевіряючи свої гіпотези і навіть створюючи прототипи. Це дало мені неймовірну свободу та можливість побудувати formspace.design, не маючи штату програмістів. Це шлях, доступний кожному, хто готовий зануритися в предметну область та проявити дисципліну.

Коли продукт потрібен "тут і зараз", а не "коли допиляють"

Бізнес не може чекати ідеального продукту роками. Потрібен MVP (Minimum Viable Product) – мінімально життєздатний продукт, який вирішує основну проблему клієнта, навіть якщо він не ідеальний. Програмісти часто прагнуть до досконалості, до бездоганної архітектури, до відсутності багів. Це похвально, але в реальному світі це означає втрачені можливості та втрачених клієнтів. Мій досвід навчив мене цінувати швидкість та ітеративність. Краще випустити продукт з 80% функцій, які дійсно потрібні, і швидко доопрацювати його на основі зворотного зв'язку, ніж відточувати 100% функцій, які можуть виявитися непотрібними.

Як мій досвід відобразився у formspace.design

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

Як спланувати ландшафт у formspace.design

Уявіть, що ви хочете створити на ділянці 15 соток зону відпочинку з перголою та невеликою водоймою. formspace.design розроблений як міст між вашою ідеєю та її реалізацією, оминаючи складні пояснення з технічними спеціалістами. Спочатку я б завантажив аерофотознімок або намалював контур ділянки в модулі 1.0 «План ділянки». Це дозволяє швидко отримати основу для роботи.

Потім, використовуючи модулі зонування (1.1 «Зони»), я б визначив місце для зони відпочинку, дитячого майданчика та городу, враховуючи сторони світу та ухил. У модулі 2.1 «ШІ-концепція» можна отримати кілька варіантів дизайну, просто описавши свої побажання. Наприклад, «сучасний стиль, мінімалізм, переважання хвойних рослин». ШІ запропонує ідеї, які потім можна деталізувати, додаючи об'єкти (1.2 «Об'єкти») — ту ж перголу, лавки, світильники. А модуль 3.1 «Дизайн за фото» дозволить побачити, як вибрані елементи виглядатимуть на реальному знімку вашої ділянки. Це дозволяє побачити загальну картину та уникнути багатьох помилок ще до початку робіт, не вдаючись до дорогих послуг проєктувальників або довгих пояснень з виконавцями.

Поширені запитання

Чи можу я обійтися без програмістів, якщо у мене є ШІ?

ШІ значно спрощує процес розробки та дозволяє не-програмістам створювати складні продукти, як я це зробив з formspace.design. Однак повністю обійтися без розуміння базових принципів програмування або без сторонньої допомоги на складних етапах поки що важко. ШІ — це потужний помічник, але не заміна глибоким знанням.

У чому головна відмінність у підході між бізнесом та IT?

Бізнес орієнтований на кінцевий результат, на вирішення проблеми клієнта та отримання прибутку. IT-фахівці фокусуються на процесі створення, на якості коду, його ефективності та масштабованості. Головна відмінність — у пріоритетах: бізнес цінує швидкість та функціональність, IT — надійність та архітектурну чистоту.

Як уникнути нескінченних доопрацювань та переробок?

Ключ до успіху — максимально детальне та однозначне технічне завдання, а також ітеративний підхід з частим зворотним зв'язком. Розділяйте проєкт на дрібні, перевіряються етапи (MVP) та тестуйте кожну функцію одразу після її реалізації. Це дозволяє коригувати курс до того, як помилки стануть критичними.

Чи варто вивчати основи кодування для кращої комунікації?

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

Чому програмісти часто не розуміють "очевидних" для бізнесу речей?

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

Як вибрати правильного розробника для свого проєкту?

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

Мій продукт занадто нішевий, чи варто його автоматизувати?

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

Що таке "технічний борг" з точки зору бізнесу?

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

Мій шлях до formspace.design був довгим, повним помилок та відкриттів у спілкуванні зі світом розробки. Але кожне з цих розумінь зробило мене сильнішим і допомогло створити продукт, який, я сподіваюся, буде корисний тисячам людей. Головне – не боятися заглиблюватися в те, що здається складним, і завжди пам'ятати, для кого і навіщо ви створюєте свій продукт. Це і є справжній досвід.

Пов'язані матеріали

• Читати далі