Від енергоефективності до веброзробки. Як використати експертизу в одній галузі, щоб отримати досвід у зовсім іншій

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Привіт! Мене звати Олексій Булгаков, я викладаю в Харківському політехнічному інституті та спеціалізуюсь на енергоефективності будівель. Останні кілька років мене захоплює веброзробка, але відсутність комерційного досвіду заважала повністю перейти в цю сферу.

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

У цій статті я розповім, як створив свій перший pet-проєкт, знайшов для нього реального клієнта та отримав гонорар, хоча не мав досвіду в IT.

Швидше за все, потреби бізнесу ви вже знаєте

Коли мені було 16, я влаштувався підсобником на завод на час літніх канікул. Здається, що знайти в цьому хоч щось релевантне для IT неможливо. Але не поспішайте з висновками. Це була важка й брудна фізична праця, але важливо, кому і в чому я підсобляв.

Я був помічником оператора верстата з числовим програмним керуванням. Технологічний процес на заводі будувався за системою Kanban, а контроль і облік виробництва велися в ERP через термінали, встановлені на кожній виробничій ділянці.

Рис. 1 Лазерний верстат з ЧПК

Озираючись назад, я розумію, що навчився не лише крутити гайки в правильну сторону, а й дізнався дещо корисне в контексті IT. Мені пощастило потрапити в колектив, де на мої нескінченні «чому» не відмахувалися, а давали пояснення й підігрівали мою цікавість. Це спонукало мене шукати способи оптимізувати процеси, щоб зменшити обсяг важкої праці. До програмування тоді справа не дійшла, але зараз я розумію, що варто було спробувати.

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

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

Правильно сформульована задача — наполовину розв’язана

Pet-проєкт, про який я розповім, — це вебзастосунок для визначення витрат на опалення. Але спершу я коротко введу вас у фізику цього процесу.

Якщо ви коли-небудь купували котел або кондиціонер, менеджер, найімовірніше, питав: «Яка у вас площа?», множив квадратні метри на 100 (або якийсь умовний коефіцієнт) і робив висновок, що вам потрібен прилад потужністю N кіловат. Завдання вирішене!

16-17 травня, Київ. Квитки тут!👇

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

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

Рис. 2 Енергетичний баланс будівлі

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

Чинний державний стандарт, що описує методику визначення енергоспоживання будівель, містить 156 сторінок і посилається ще на десяток таких самих за обсягом документів, які фахівці цієї сфери через певну профдеформацію можуть цитувати серед ночі. Очевидно, що в цих моделях є чимало речей, якими можна безболісно нехтувати, тому софт для цих розрахунків може виглядати як найпростіший калькулятор із кількома полями або як величезна САПР, для опанування якої потрібен окремий бакалаврат.

Рис 3. Приклад простого і складного розрахункового софту

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

Рис 4. Чернетка мокапа, яку я підготував для першої зустрічі з замовником

Я відкинув із технічних вимог більшість аспектів, які лякали своєю невідомістю, і в результаті концепт застосунку виглядав так:

• багатокрокова форма на Next.js;
• використання бібліотеки компонентів MUI;
• збереження стану в React Context;
• генерація PDF-звіту;
• відправка на електронну пошту користувача, який заповнив дані.

Увесь математичний розрахунок мав виконуватися на клієнті в об’єктноорієнтованій енергетичній моделі будівлі, а сам застосунок — хоститися на Vercel. Цього опису виявилося достатньо, щоб отримати дозвіл на розробку та узгодити кошторис.

Документація як основа

Оскільки раніше я не кодував нічого настільки об’ємного й складного, то не міг одразу взятися за написання коду. Тому спершу витратив чимало часу (зрештою, майже половину всього періоду розробки) на декомпозицію задачі.

Я дізнався про UML і спробував скласти діаграму класів так, як її розумів. Оглядаючись назад, розумію, що зробив все неправильно, але, попри це, навіть помилкова візуалізація допомогла мені не «загубитися в просторі» і вибудувати логічні зв’язки.

Рис. 5 Спроба накреслити діаграму класів

На глибшому рівні абстракції я описував методику в документації. Для цього я створив окремий вебсайт на Jekyll і розмістив його на GitHub Pages в межах репозиторію проєкту.

Варто зазначити, що це було зроблено не тільки для полегшення розробки. У ситуаціях, коли виробник приладу A декларує кращу ефективність, ніж прилад Б, критично важливо наводити докази та посилання на авторитетні джерела. Тому відкритість і публічність методики розрахунку спрямована на те, щоб забезпечити прозорість висновків, які надає калькулятор.

Рис. 6 Сайт документації проєкту

Щоб перевіряти правильність розрахунків під час кодування моделі, я створив окремий Excel-файл з еталонним розрахунком для тестової будівлі та порівнював результати. Це був перший і останній раз, коли я свідомо відмовився від написання тестів — більше такої помилки я не допущу. 😁

Головною метою, яку я ставив перед собою при описі математики, було скорочення кількості вхідних даних, які потрібно отримати від користувача. І це принесло свої плоди: у мене зʼявилася структура даних і повне розуміння того, з яких полів повинна складатися багатокрокова форма.

Дизайн, що економить час

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

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

Такий підхід вимагав побудови залежностей між різними кроками форми, оскільки поля на поточному кроці посилаються на дані, введені на попередніх. Однак це дало змогу зібрати всю необхідну інформацію про будівлю та її інженерні системи всього за 7 кроків. Весь цей user flow я спочатку реалізував у прототипі в Figma.

Рис 7. Прототип застосунку в Figma

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

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

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

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

Коли залишається тільки код

Завдяки навчанню в IT Generation і товаришам із Kottans, робота, яку я залишив наостанок, уже не становила великих складнощів. Єдине, що залишалося — це власне фронтенд.

Але зараз скажу річ, яка, можливо, когось здивує. Тільки на цьому етапі, коли майже всі загадки для мене були розгадані, я попросив аванс! Тобто для замовника весь мій попередній R&D не ніс жодних матеріальних ризиків, і це була не його вимога, а моя. Мене мотивував той факт, що людей, які, як і я, перебувають на перетині дисциплін, дуже мало — і тільки вони здатні створити щось подібне.

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

Але якась маленька частка страху має бути присутня, інакше, залишаючись у зоні комфорту, щоденна рутина з фултайм-роботою та спокусою відпочити на вихідних не дасть вам завершити проєкт ніколи.

Технічні проблеми в процесі власне кодування, звісно, були, але не такого масштабу, щоб ChatGPT і Stack Overflow не змогли запропонувати хоча б три варіанти вирішення.

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

Рис. 8 Результати розрахунку

Висновок

Досвід, навіть той, що здається нерелевантним, може стати потужним фундаментом для змін. Важливо розуміти зв’язок між своїми знаннями та можливістю їх застосування в іншій сфері. Безлад у кодовій базі, баги, bad practices та інші жахи не завадять створенню корисного продукту для конкретного бізнесу, але вони нададуть той самий досвід, який дозволить уникнути подібного в майбутньому.

Якщо в моїй розповіді ви впізнали себе або маєте питання з цієї теми, запрошую до обговорення в коментарях!

Посилання:

Сайт проєкту
Репозиторій проєкту
Документація