Мій шлях до formspace.design: коли програмісти не розуміли мене

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

Початок шляху: як я зрозумів, що потрібна автоматизація

Моя історія взаємодії з розробниками почалася ще в 90-х, коли я був заступником директора в НВФ «Алькар». Моїм завданням, серед іншого, було постановка завдань програмістам щодо управлінського обліку. Вже тоді я відчув, наскільки складно перевести інтуїтивні бізнес-процеси у строгу мову коду. Здавалося б, просте завдання – автоматизувати звітність або облік товарів – оберталося довгими поясненнями, які рідко призводили до очікуваного результату.

Пізніше, керуючи компанією «Дім і Сад» з 2000 по 2022 рік, я продовжував шукати способи автоматизації. Ми пробували впроваджувати різні CRM-системи, але кожна з них вимагала адаптації, а пояснення моїх потреб зовнішнім розробникам знову й знову наштовхувалися на стіну нерозуміння. Я детально описував ці складнощі у статті «Роки без нормального управлінського обліку в «Дім і Сад»: чим це обернулося». Це було замкнене коло: я витрачав час на пояснення, гроші на доопрацювання, а в підсумку отримував продукт, який лише частково вирішував завдання, або зовсім створював нові складнощі.

Проблема перекладу: бізнес-мова vs. технічна

Основна проблема полягає в різниці мислення. Підприємець мислить категоріями результату, ефективності, клієнтського досвіду. Моє бачення ландшафтного проєкту – це цілісна картина, де кожна деталь має своє значення, де є місце для творчості та гнучкості. Програміст же мислить алгоритмами, чіткими правилами та логічними операціями. Для нього важлива однозначність і передбачуваність. Коли я кажу: «Мені потрібно, щоб кошторис рахувався швидко та зручно», я маю на увазі, що система повинна враховувати безліч факторів: площу ділянки (наприклад, 10 або 15 соток), тип робіт (укладання рулонного газону, посадка дерев), обрані матеріали, складність рельєфу (коефіцієнт від 1.0 до 1.5). Програміст же почує «зробити кнопку ‘порахувати кошторис’» і чекатиме детальну формулу для кожного елемента, не завжди розуміючи контекст.

Типові помилки у постановці завдань

За роки я виділив кілька типових помилок, які здійснював сам і бачив у інших:

1. Недостатня деталізація. Загальні фрази на кшталт «зробити зручно» або «зробити красиво» не несуть жодної інформації для розробника. Йому потрібні конкретні сценарії використання.
2. Зміна вимог на ходу. Бізнес динамічний, і зміни неминучі. Але кожна така зміна без чіткої фіксації та перегляду ТЗ призводить до хаосу та додаткових витрат. Іноді ми могли витрачати 2-3 місяці на навчання співробітників роботі з новою CRM, тільки щоб зрозуміти, що вона не підходить через постійно мінливі вимоги.
3. Відсутність чітких сценаріїв використання. Я не завжди міг уявити всі можливі ситуації, в яких буде використовуватися програма. Відсутність «user stories» призводила до того, що система не працювала в реальних умовах.
4. Очікування, що програміст «сам здогадається». Це, мабуть, найпоширеніша помилка. Програміст не є експертом у вашій галузі. Він не повинен «здогадуватися» про неявні нюанси ландшафтного дизайну або управління проєктами. Моє завдання було чітко сформулювати ці нюанси.
5. Фокус на «як зробити», а не на «що має вийти». Іноді я занадто заглиблювався в технічні деталі, намагаючись підказати, як реалізувати ту чи іншу функцію, замість того щоб ясно описати бажаний кінцевий результат і бізнес-цінність.

Як навчитися говорити з програмістами

Мій досвід навчив мене кільком важливим правилам:

• Пишіть ТЗ максимально детально. Це має бути не просто список функцій, а опис бізнес-процесів, користувацьких сценаріїв, приклади вхідних та очікуваних вихідних даних. Чим більше конкретики, тим менше місця для інтерпретацій.
• Використовуйте прототипи та макети. Навіть намальований від руки ескіз інтерфейсу, скріншоти або прості прототипи у Figma можуть сказати більше, ніж тисячі слів. Вони дозволяють візуалізувати майбутній продукт і виявити непорозуміння на ранніх етапах.
• Розбивайте завдання на дрібні, вимірювані кроки. Замість одного великого завдання «зробити CRM», краще поставити 10–20 маленьких: «реалізувати додавання клієнта», «зробити фільтр за датою», «налаштувати відправку сповіщень». Це дозволяє контролювати процес і коригувати курс.
• Фокусуйтеся на бізнес-процесах та очікуваному результаті. Завжди починайте з питання: «Яку проблему користувача або бізнесу це вирішує?» та «Який конкретний результат ми хочемо отримати?».
• Наводьте конкретні приклади. Якщо функція повинна щось розраховувати, дайте приклади з цифрами. Якщо вона повинна обробляти дані, покажіть, як ці дані виглядають.

Наслідки неефективної комунікації

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

Відчай та народження ідеї formspace.design

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

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

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

Уявіть, що вам потрібно спланувати ділянку площею 18 соток. Ви починаєте з Модуля 1.0 «План ділянки», де легко задаєте межі, наносите існуючі будівлі та комунікації. Потім переходите до Модуля 1.1 «Зони», щоб інтуїтивно розмітити функціональні області: наприклад, зону барбекю розміром 4x5 метрів, дитячий майданчик 6x6 метрів, город, зону відпочинку. Ви бачите все це відразу, наочно, без необхідності пояснювати комусь свої задуми. Якщо у вас є загальне уявлення, але не вистачає конкретних ідей, використовуйте Модуль 2.1 «ШІ-концепція». Ви можете завантажити фотографію ділянки або навіть просто мудборд, описати свої вподобання – наприклад, «сучасний мінімалістичний сад з акцентом на вічнозелені рослини та водойму» – і штучний інтелект згенерує кілька варіантів концепцій. Для більш детальної візуалізації конкретних елементів, Модуль 3.1 «Дизайн за фото» дозволяє завантажити знімок існуючого місця та «приміряти» різні елементи дизайну: поміняти бруківку, додати чагарники, змінити колір фасаду будинку. Все це відбувається в режимі реального часу, і ви відразу бачите результат, без довгих листувань та правок, які неминучі при роботі із зовнішніми виконавцями. Це дозволяє зосередитися на творчості, а не на технічних деталях постановки завдань.

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

Чому так складно пояснити програмісту свої бізнес-процеси?

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

Які основні помилки підприємців при замовленні програмного забезпечення?

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

Як уникнути ситуації «отримав не те»?

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

Чи потрібен технічний бекграунд, щоб ставити завдання програмістам?

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

Що робити, якщо проєкт вже йде не так?

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

Чому formspace.design вирішує цю проблему для ландшафтних дизайнерів?

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

Які конкретні кроки допомогли мені перейти від «пояснень» до «створення»?

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

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