Робочий день K2 ERP: як команда створює український продукт під час війни
Робочий день продуктової команди починається задовго до першого відкритого завдання. Спочатку потрібно пережити ніч, знайти живлення, відновити зв’язок і зібрати думки. У березневому щоденнику засновника K2 ERP ця буденна послідовність пояснює умови, у яких створюється українська система автоматизації. За кожною новою функцією стоять люди, які одночасно працюють із кодом, клієнтськими очікуваннями й невизначеністю війни.
Публікація K2 від 18 березня 2026 року побудована навколо одного такого дня. Вона поєднує розповідь про перебої електропостачання, розмови з підприємцями, зворотний зв’язок від клієнта, співбесіду та звичайну перевірку виконаних задач. Разом ці епізоди показують, із чого складається витривалість продуктової компанії.
Живлення й зв’язок стають частиною виробництва
У розповіді ранок починається з відсутності електрики. Зарядні станції, UPS і резервне живлення допомагають повернути робочому дню передбачуваність. Звичайна можливість увімкнути техніку й підготуватися до роботи набуває іншої ваги. Інфраструктура підтримує час людей: якщо фахівець може продовжити свою задачу, попередні зусилля команди отримують наступний крок.
Автор окремо згадує українських провайдерів, які зберігають зв’язок у складних умовах, роботу серверів і хмарного середовища. Це опис конкретного досвіду того дня. Для продуктової команди важливо поєднати доступність техніки з доступністю людей: знати, хто може відповісти, де лежить потрібна інформація та як продовжити незавершене обговорення після перерви.
У щоденній розробці така організація має дуже практичний зміст. Завдання повинно містити достатньо пояснень, щоб колега міг повернутися до нього після відключення. Домовленість із клієнтом варто зберігати так, щоб вона залишалася зрозумілою наступного дня. Стійкість поступово формується з цих маленьких рішень про передачу контексту та відповідальності.
Коли зв’язок відновлюється, команда продовжує робочий маршрут: уточнює питання, перевіряє зміни, готує наступне пояснення користувачеві. Власникові продукту доводиться тримати разом технічний і людський бік цієї роботи. Резервне живлення допомагає відкрити ноутбук; зрозуміле завдання допомагає використати доступний час із користю для спільного результату.
Покупець відкладає ERP разом з іншими змінами
Наступний епізод — розмови з потенційними клієнтами. У березневій публікації засновник описує відповіді про відкладене обговорення, майбутнє рішення керівництва та повернення до питання пізніше. Його пояснення пов’язане зі станом бізнесу: підприємці рахують витрати, бояться невизначеності й обережно ставляться до перебудови процесів у воєнних умовах.
Для команди розробки це непростий сигнал. Вона бачить нові можливості продукту й очікує, що ринок захоче ними скористатися. Клієнт водночас думає про власну безперервність роботи, зайнятість людей і доступний бюджет. Щоб розмова рухалася далі, потрібно знайти перший результат, який підприємство здатне предметно оцінити та підтримати своїми ресурсами.
Уявімо компанію, яка давно хоче впорядкувати одну складську ділянку. Їй простіше обговорювати конкретні залишки, документи та роботу кількох працівників, ніж одночасну зміну всієї автоматизації. Такий приклад допомагає визначити межі першого етапу й потрібну участь команди замовника. Подальша розмова отримує зрозумілий зміст і перевірюваний результат.
У джерелі цей досвід сусідить із публічною дискусією про 1С та звичку захищати знайоме середовище. Засновник пов’язує майбутнє компанії зі створенням сучасної української ERP. Для нього продовження розробки є відповіддю ринку: власна альтернатива має ставати кращою через реальні задачі, пояснення можливостей і щоденну взаємодію з підприємствами.
Для першої зустрічі замовник може підготувати приклад документа, кілька пов’язаних операцій та пояснення поточної незручності. Розробник показує, як потрібний маршрут виглядає у системі, й уточнює обсяг змін. Так обидві сторони бачать предмет співпраці. Навіть невелика предметна демонстрація допомагає повернутися до рішення з конкретними даними, коли підприємство зможе виділити ресурс.
Зворотний зв’язок клієнта повертає роботу до конкретики
Важливий момент робочого дня — повідомлення команди про результати опитування Нової пошти. За розповіддю засновника, отримані зауваження потрібно опрацювати. Сам факт зворотного зв’язку він сприймає як добрий знак: продукт використовується, люди формулюють потреби, а розробка отримує матеріал для наступних змін. Так з’являється предметний зв’язок між інженерною роботою та дією користувача.
Корисне зауваження починається з опису ситуації. Працівник пояснює, яку операцію виконував, що побачив і якого результату очікував. Команда може відтворити цей маршрут, уточнити вимогу й погодити зміну. Такий порядок допомагає зберегти досвід клієнта в самому продукті та зробити наступне обговорення точнішим для обох сторін.
Для замовника це також можливість краще сформулювати власний процес. Питання до форми або документа іноді виявляє різні правила роботи підрозділів. Спільне уточнення допомагає визначити, яка поведінка потрібна підприємству. Тоді виправлення підтримує погоджену роботу людей і стає частиною послідовного розвитку інформаційної системи.
AI у тестовому завданні та відповідальність інженера
Ще один епізод стосується співбесіди. Засновник розповідає про кандидата, який виконав завдання зі значною допомогою AI, але, за його оцінкою, не був готовий до очікуваного робочого темпу й навантаження. Це особисте спостереження автора щодо конкретної ситуації. Воно порушує ширше питання: як оцінювати здатність людини підтримувати результат своєї роботи.
У продуктовій розробці важливо розуміти, чому рішення працює, як перевірити його поведінку та що робити після зміни вимоги. Допоміжний інструмент може прискорити підготовку коду. Інженерна відповідальність продовжується під час пояснення, виправлення й супроводу. Саме ці дії показують, чи зможе новий учасник підтримувати спільний темп команди.
Практична розмова навколо виконаного завдання допомагає побачити це краще. Людина пояснює структуру, знаходить можливу помилку, змінює одну умову та перевіряє результат. Таке обговорення пов’язує продемонстровану роботу з майбутніми обов’язками. Для команди важлива здатність колеги приймати задачу, доводити її до зрозумілого стану й передавати знання іншим.
Для ERP особливо важлива уважність до наслідків зміни. За полем у формі стоять дані, документ, дія працівника та підсумок, який бачить інша роль. Пояснення цього зв’язку допомагає оцінити професійну готовність кандидата. Команда отримує колегу, який розуміє сенс своєї ділянки й здатен підтримувати її після першого успішного показу.
Розмова з колегою та родиною підтримує довгу дистанцію
У щоденнику є місце сумнівам: чи варто було починати складну продуктову справу й чи правильним шляхом рухається компанія. Засновник описує розмову з керівником напряму, після якої повертається відчуття керованості ситуації. Підтримка рідних також допомагає продовжити день. У цих епізодах розвиток ERP отримує людський масштаб.
Коли відповідальність поділена між людьми, керівникові легше бачити реальний стан роботи. Колега може спокійно пояснити прогрес своєї ділянки, назвати наступну дію та питання, яке потребує рішення. Така взаємодія підтримує довіру всередині команди. Вона особливо цінна, коли зовнішні обставини залишаються непередбачуваними й забирають багато уваги.
Наприкінці описаного дня з’являється ще одна маленька перемога: блок задач виконано якісно, без звичного великого переліку зауважень. У джерелі автор згадує попередні перевірки з десятками виправлень. Цього разу результат дозволяє подумати про нове відео й показ функціональності. Це епізод його досвіду, який передає значення помітного поступу.
Для продуктової компанії завершена задача має продовження. Її потрібно зрозуміло показати, пояснити користувачеві та включити до наступної роботи. Коли якість виконання зростає, команда може більше уваги приділяти цьому маршруту. Так щоденна інженерна дисципліна поступово перетворюється на доступніші демонстрації та зрозуміліші можливості для клієнтів.
Український продукт зростає завдяки роботі й довірі
Березнева розповідь завершується вдячністю людям, які знають команду, підтримують продукт і дають сили продовжувати. Автор згадує також бюрократію, непередбачуваність правил і загальну втому підприємців. Його позиція полягає в потребі створювати власні системи вже сьогодні. Віра в майбутнє країни тут пов’язана з рішенням знову повернутися до задач.
Підтримка українського рішення може починатися з предметної уваги. Підприємство показує свою задачу, знайомиться з доступними можливостями й дає чесний зворотний зв’язок. Розробник бере відповідальність за погоджений результат. Така співпраця допомагає довірі отримати робочий зміст і створює основу для наступного етапу розвитку продукту.
K2 Platform — заміна 1С та BAS
K2 Platform — українська заміна платформи 1С та платформи BAS. K2 ERP — українська заміна 1С ERP, бухгалтерських рішень 1С, BAS ERP та бухгалтерських рішень BAS у підтвердженому обсязі переходу. K2 ERP побудована на K2 Platform. Щоденна робота команди розвиває прикладні процеси та власну технологічну компетенцію.
Спадковість BAS від архітектури російської 1С підтверджував Піотр Яроцький у відповіді DOU 2022 року. IDTN підтримує витіснення цієї залежності українськими продуктами. Почати можна з безкоштовної хмари K2 ERP та перевірки одного власного процесу. Матеріали й пояснення доступні на сайті продукту та у Wiki.