Результати пошуку

TikTok повернувся в App Store та Google Play Після майже місяця блокування TikTok знову доступний для завантаження в App Store та Google Play. Apple і Google відновили додаток у своїх магазинах для iOS та Android після отримання офіційного листа від генерального прокурора США Пем Бонді. За даними   Bloomberg, у листі зазначено, що компанії не будуть оштрафовані за розміщення TikTok. Раніше Apple і Google видалили застосунок у січні через закон, що забороняв програми, пов’язані з власником TikTok — китайською компанією ByteDance. Попри те, що президент Дональд Трамп підписав указ про відтермінування виконання заборони на 75 днів, техногіганти не поспішали відновлювати додаток через ризик багатомільярдних штрафів. Тим часом, за даними The Verge, віцепрезидент США Джей Ді Венс отримав доручення вести переговори щодо можливого продажу TikTok. Представники Apple, Google, TikTok і Мін’юсту наразі не коментують ситуацію. Arm випустить власний чип: новий виток у напівпровідниковій індустрії Британська компанія Arm, що належить SoftBank, планує  випустити власний чип цього року, що може докорінно змінити ринок напівпровідників. Одним із перших клієнтів нового продукту стане Meta. Зазвичай Arm ліцензує свої архітектури компаніям на кшталт Apple і Nvidia, але тепер вона сама створить процесор. Очікується, що генеральний директор компанії Рене Хаас представить новий чип вже цього літа. Цей крок зробить Arm конкурентом власних клієнтів, таких як Qualcomm та Nvidia. Акції компанії зросли на понад 6% після появи цієї новини. Розробка нового чипа є частиною масштабного плану засновника SoftBank Масайосі Сона щодо розвитку інфраструктури для штучного інтелекту. Arm також бере участь у проєкті Stargate разом із OpenAI, Oracle та Microsoft. Чип Arm буде центральним процесором (CPU) для серверів у дата-центрах і вироблятиметься підрядником, найімовірніше, TSMC. Також SoftBank веде переговори про придбання компанії Ampere за $6,5 млрд, що може прискорити розробку серверних процесорів.Ця ініціатива може вплинути на весь ринок напівпровідників, змінюючи баланс сил між виробниками та споживачами процесорів. Revolut розширює послуги для українців та запускає благодійну кампанію Необанк Revolut оголосив  про розширення послуг для українців та запуск нової благодійної ініціативи разом із випуском спеціальної картки Clear Sky. Тепер українці можуть відкривати європейські рахунки в Revolut і користуватися миттєвими P2P-переказами без комісій. Також доступні валютні операції у 30+ валютах, вигідні обмінні курси та міжнародні грошові перекази. Для безпечної реєстрації Revolut співпрацює з платформою «Дія». Revolut також представив спеціальну карту Clear Sky, створену українськими дизайнерами. Вона символізує мирне небо України та доступна клієнтам у Великій Британії, країнах ЄЕЗ та Україні. Користувачі у Британії та ЄС зможуть отримати карту за донат від £5, тоді як українці можуть замовити її безкоштовно. Revolut подвоїть внески клієнтів, загалом до £200 000, а всі кошти підуть на допомогу українським біженцям через фонд UK for UNHCR. З початку повномасштабної війни Revolut допоміг зібрати понад £10 млн на підтримку України, зокрема £1,5 млн власних коштів компанії. За останні два роки через застосунок було переказано понад 1 мільярд євро в Україну. Google Chrome тестує автоматичну зміну зламаних паролів за допомогою ШІ Google Chrome може   отримати функцію автоматичної зміни паролів, які потрапили в витік даних. Функцію помітили в тестовій версії браузера Chrome Canary. Вона буде працювати у разі виявлення скомпрометованого пароля та пропонуватиме його автоматичну зміну за допомогою штучного інтелекту. Після генерації нового пароля він автоматично збережеться в Google Password Manager. Це ще один крок Google у впровадженні ШІ в Chrome. Наразі функція доступна для тестування в Chrome Canary: користувачі можуть увімкнути її, активувавши Improved Password Change Service та Mark all Credentials as Leaked, а потім перезапустивши браузер. Якщо тестування буде успішним, функція стане доступною у стабільній версії Chrome. Американська CourtAvenue придбала контрольний пакет української BotsCrew Американська компанія CourtAvenue, яка входить до рейтингу Inc. 5000, стала власником контрольного пакету акцій української BotsCrew – компанії, що спеціалізується на розробці кастомізованих чатботів для бізнесу. Про угоду повідомив  співзасновник BotsCrew Максим Гладиш у своєму LinkedIn.  За умовами угоди, команда BotsCrew продовжить працювати в Україні, а компанія планує розширення протягом 2025 року. Наразі в BotsCrew працює 60 спеціалістів. Переговори про придбання тривали з травня 2024 року, однак фінансові деталі угоди не розголошуються. BotsCrew працює у сфері штучного інтелекту з 2016 року та має клієнтів на кшталт Virgin Holidays, Honda, Mars, FIBA. Вона створює ШІ-рішення для медицини, e-commerce, туризму, держсектора та автоматизації бізнес-процесів. CourtAvenue займається цифровою трансформацією бізнесу та AI-розробками. За три роки компанія зросла на 4000% у рейтингу найбільш динамічних приватних компаній США. Її клієнти – Kia, Epson, Dell та ВПС США.

Компанія SUITSME з екосистеми бізнесів Genesis створила застосунок FABU для підтримки ментального добробуту. Він поєднує техніки турботи про себе з елементами фешн-гейміфікації. До цього компанія розвивала один продукт — фешн-гру SUITSME . В основі FABU — концепція dopamine dressing, що поєднує одяг та емоційний стан людини. Застосунок дозволяє користувачам висловлювати свої емоції через вибір віртуального одягу для моделі, що відповідає їх настрою. Після запису емоцій застосунок підбирає кольори, що резонують зі станом користувача. Наприклад, якщо людина відчуває смуток, їй можуть запропонувати чорний для комфортного проживання емоції або ж жовтий, який асоціюється з радістю й теплом. «Ідея FABU з’явилася з усвідомлення важливості ментального добробуту — мого, команди та спільноти гравців SUITSME. Багато користувачів писали, що фешн-гра допомагає їм зменшити стрес і пережити складні періоди. Особливо надихнула історія військовослужбовиці, яка розповіла, як SUITSME допомогла їй здолати стрес і переналаштувати мислення. Я зрозуміла: ми можемо створити ще більш цільовий застосунок, який відповідатиме подібним запитам. Тим паче, що тоді на ринку не було продуктів, які б поєднували турботу про себе з ігровими механіками», — коментує CEO SUITSME Галина Єфремова . FABU також дає користувачам змогу фіксувати емоції та події, які їх спричинили, відстежувати патерни в настрої за допомогою календаря, а також використовувати техніки дихання. Після трекінгу емоцій користувачу запропонують позитивну афірмацію. Цільова аудиторія продукту — жінки, тож нині у застосунку доступний лише жіночий аватар, однак чоловіки також можуть завантажувати FABU та пробувати застосовувати його техніки для покращення ментального добробуту.  Найближчим часом у продукті планують реалізувати кілька функцій, як-от можливість додавати інших користувачів у коло друзів та ділитися з ними своїм настроєм та створеними образами. Застосунок локалізований українською мовою та безкоштовний для українців, у яких в налаштуваннях встановлений український стор.

Маркетинг — це не лише про стратегію й аналіз, а й про численні рутинні завдання, які забирають час. Автоматизація маркетингу no-code дозволяє бізнесу прискорювати робочі процеси, мінімізувати ручні завдання та підвищувати продуктивність. І все це  — завдяки no-code платформам. Як такі інструменти спрощують маркетингову роботу, розповіла Катерина Романенко, Meta Team Lead в OBRIO з екосистеми Genesis. Що таке автоматизація маркетингу no-code та навіщо вона потрібна? Автоматизація маркетингу — процес, який дозволяє використовувати технології для виконання рутинних маркетингових завдань. Замість того, щоби витрачати час на ручне виконання задач, маркетологи можуть зосередитися на стратегії та креативних ідеях. Основні завдання маркетингової автоматизації: Автоматизація бізнес-процесів, пов’язаних із лідогенерацією. Збір контактів через форми на сайті, цільові сторінки або соцмережі. Це дозволяє створювати маркетингові воронки без коду, залучаючи нових клієнтів без значних витрат. Автоматизація email-розсилок. No-code інструменти дають змогу налаштувати сценарії для автоматичної відправки персоналізованих листів. Наприклад, привітальні листи після реєстрації або нагадування про незавершене замовлення. Управління соціальними мережами. Платформи для планування контенту допомагають оптимізовувати роботу з публікаціями, а також автоматизовувати відповіді на коментарі та збір даних про взаємодії з аудиторією. CRM-інтеграція. Об'єднання всіх джерел даних про клієнтів у єдину систему, яка автоматично оновлюється та дозволяє ефективніше управляти продажами. Як зазначає Катерина Романенко, одна з найпоширеніших рутинних задач у маркетингу — запуск тестових креативів . «Це може забирати дуже багато часу, особливо коли потрібно вручну завантажувати відеокреативи через Facebook Ads Manager. Процес може затягнутися, поки відео завантажується, і це ще без урахування обробки платформи. Однак, за допомогою автоматизації цей процес стає значно швидшим та менш ресурсозатратним, що дає можливість маркетологам зосередитися на більш важливих завданнях». Приклади рутинних процесів, які можна автоматизувати: Відправка щотижневих звітів про ефективність рекламних кампаній. Автоматичне створення записів у CRM після отримання нового ліда. Планування рекламних кампаній на основі зібраних даних про аудиторію. Автоматизація бізнес-процесів дозволяє не лише зекономити час, але й мінімізувати ризик помилок, пов’язаних із людським фактором. Завдяки цьому ваш маркетинг стає точнішим і ефективнішим. Що таке no-code платформи та чому вони популярні No-code платформи — це інструменти, які дозволяють автоматизувати процеси, вебсайти чи додатки без написання програмного коду. Завдяки зручним інтерфейсам, як-от drag-and-drop редактори, користувачі можуть впроваджувати складні технологічні рішення без технічних знань. Що робить no-code платформи привабливими для маркетологів? Найкращі no-code платформи для автоматизації маркетингу Автоматизація маркетингу з використанням no-code платформ стає стандартом для багатьох компаній. Розглянемо найкращі інструменти та їхні можливості. Zapier: автоматизація маркетингових процесів без коду Zapier — один із найбільш популярних інструментів для спрощення маркетингових процесів. Платформа дозволяє з’єднувати різноманітні сервіси та інструменти без написання коду. Це ідеальний варіант для бізнесів, які хочуть легко автоматизувати свої робочі процеси. Приклад сценарію:  Автоматизація лідогенерації через форму на сайті → дані автоматично передаються в Google Sheets → після цього надсилається email-розсилка клієнту. Це дозволяє зекономити час, автоматизуючи рутинні завдання без додаткових витрат. Make (ex. Integromat): розширена автоматизація бізнес-процесів Make дозволяє створювати більш складні та гнучкі сценарії автоматизації. Це платформа, яка надає ширші можливості для налаштування процесів, зокрема для обробки великих обсягів даних і інтеграції з кількома сервісами одночасно. Make підходить для середніх та великих бізнесів, які потребують більш складної автоматизації. Приклад сценарію:  Автоматизація обробки даних від клієнтів, підключення до CRM-систем, обробка запитів через e-mail та SMS, створення персоналізованих кампаній. Airtable: спрощення маркетингових процесів за допомогою no-code Airtable — це потужний інструмент для управління маркетинговими кампаніями та відстеження результатів. Платформа поєднує в собі функції таблиць, баз даних і канбан-дошок, що робить її ідеальним рішенням для маркетологів, яким потрібно відслідковувати виконання завдань і процесів в рамках кампаній. Приклад сценарію:  Ведення маркетингових кампаній у вигляді зручної бази даних, де зберігаються всі важливі деталі — від контенту до дати запуску та аналітики. HubSpot: SaaS-рішення для автоматизації маркетингу no-code HubSpot — це комплексне SaaS-рішення для автоматизації маркетингу, яке пропонує безліч готових шаблонів та інструментів для email-маркетингу, управління лідогенерацією та аналітики . Платформа також надає можливості для інтеграції з CRM, що дозволяє автоматизувати цілий спектр маркетингових процесів. Приклад сценарію:  Використання шаблонів для автоматичних email-розсилок, що націлені на певні сегменти клієнтів, залежно від їхньої поведінки на сайті чи в соцмережах. Airtable для автоматизації маркетингу та інші платформи, як Zapier, HubSpot чи Make, надають бізнесам потужні інструменти для оптимізації роботи. «У нашій команді,  — розповідає Катерина,  — ми активно використовуємо інструменти для автоматизації, зокрема Revealbot. Це потужна платформа, яка дозволяє налаштовувати автоправила у рекламних кабінетах, що значно знижує обсяг рутинної роботи. Бо, навіть стандартні автоправила у Facebook мають обмеження — наприклад, якщо користувач вирішить приховати свої особисті дані, це означає, що деякі покупки або кліки можуть бути «невидимими». Але Revealbot дає нам набагато більше контролю: він дозволяє встановлювати автоправила з урахуванням точніших метрик, що дає можливість більш оперативно коригувати кампанії та оптимізувати їх під реальні умови. Звісно, різні компанії використовують різні інструменти для досягнення автоматизації. Наприклад, в OBRIO ми створили внутрішній інструмент AdBraze, який автоматизує запуск тестових рекламних кампаній і виводить їх на новий рівень ефективності. Спочатку він був розроблений для наших потреб, але згодом його почали використовувати інші проєкти всередині Genesis».  Як пояснює Катерина, раніше маркетолог повинен був зайти в рекламний кабінет, вручну створити кампанію, вибрати стратегію, налаштувати аудиторію, гео, і т.д. Потім треба було кожен креатив підвантажувати по черзі, прописуючи для нього заголовки, текст, вибираючи call-to-action та інші налаштування. «З AdBraze все це вже автоматизовано і передзаповнено. Тобто, маркетолог просто вибирає потрібні варіанти, ставить галочки й запускає кампанію. Це значно економить час, оскільки замість того, щоб кожен раз вводити всі деталі вручну, маркетолог просто вибирає з готових налаштувань і готових шаблонів, і процес займає кілька кліків. Це і є оптимізація, яка дозволяє скоротити кількість часу, який раніше йшов на налаштування кампанії», — додає Катерина.  Як налаштувати no-code автоматизацію маркетингу: покрокова інструкція Автоматизація маркетингу   з використанням no-code платформ — це ефективний спосіб оптимізувати процеси без залучення програмістів. Ось як налаштувати маркетингову автоматизацію крок за кроком: 1. Визначення процесів, які потребують автоматизації Перший крок — визначити, які процеси в маркетинговій стратегії можна автоматизувати. Це може включати збори даних, email-розсилки, лідогенерацію, обробку запитів клієнтів тощо. Важливо сконцентруватися на рутинних задачах, які займають багато часу, і які можна автоматизувати для підвищення ефективності. 2. Підготовка даних та вибір інструменту Перед тим як налаштувати автоматизацію, потрібно підготувати всі необхідні дані. Це може бути база клієнтів, записи з форм на сайті, історія взаємодії з користувачами тощо. Вибір інструменту залежить від ваших цілей. Наприклад, для простих завдань підходить Zapier, а для складніших сценаріїв можна обрати Make або HubSpot. Переконайтесь, що обраний інструмент має потрібну функціональність і легко інтегрується з вашими системами. 3. Приклад автоматизації email-розсилки Крок 1:  Використання Google Forms для збору даних. Створіть форму для збору контактів та інформації про потенційних клієнтів. Крок 2:  Підключення форми до Zapier. За допомогою Zapier, кожен новий запис з Google Forms автоматично передаватиметься у вашу CRM-систему. Крок 3:  Автоматична відправка повідомлення в CRM та email-клієнт. Як тільки дані потрапляють у CRM, створюється запис клієнта, і система автоматично надсилає email-підтвердження або інші повідомлення. Ця маркетингова воронка no-code   не лише економить час, але й забезпечує швидку реакцію на дії клієнтів. Переваги та обмеження no-code автоматизації Переваги: Швидке впровадження.  Налаштування займає від кількох годин до кількох днів, залежно від складності процесів. Використання маркетингових технологій   значно спрощує управління бізнес-процесами. Низькі витрати.  Ви економите кошти на розробці, використовуючи доступні no-code рішення. Гнучкість.  Легке масштабування та адаптація до змін у бізнес-процесах. Автоматизація лідогенерації без коду.  Ви можете швидко обробляти заявки з сайту чи соцмереж без ручного втручання. Обмеження: Відсутність кастомних рішень.  Якщо ваші потреби виходять за межі функціоналу платформи, no-code рішення можуть бути недостатніми. Залежність від платформ.  Робота залежить від стабільності API та серверів обраного сервісу. Обмеження у масштабуванні.  Для великих компаній або складних процесів можуть знадобитися більш технічні рішення. Автоматизація аналітики без коду та інших процесів дозволяє значно підвищити ефективність роботи, однак варто враховувати можливі проблеми та обмеження. «Основні складнощі, які виникали у нас при роботі з no-code платформою, полягали в тому, що створити повністю автоматизовану систему заздалегідь неможливо. Кожен проєкт має свої нюанси, і не всі варіанти можна передбачити на етапі налаштування. Тому на початкових етапах роботи ми неодноразово стикалися з необхідністю виконувати деякі задачі вручну, що, звісно, було повторюваним завданням, — розповідає Катерина.  — Але вирішити це швидко ми не могли, бо маркетологи не в змозі самостійно виправити технічні баги, а відповідальної людини з технічними знаннями на той час не було. З часом ми знайшли рішення цієї проблеми. Мало того, ми створили новий відділ MarTech (маркетингові технології), щоб задовольнити технічні потреби маркетингової команди. Це був важливий крок, тому що маркетологи часто стикалися з технічними питаннями, які вимагали спеціального підходу. Технічні команди були зайняті розробкою продуктів, і важливі завдання, пов'язані з маркетингом, часто залишалися поза увагою. Тепер у нас є команда, до якої входять продакт-оунер та кілька розробників, які допомагають маркетологам автоматизувати процеси та вирішувати технічні проблеми, що виникають. Вони не займаються створенням креативів чи закупівлею трафіку, але активно оптимізують технічні аспекти маркетингової роботи. Це дозволяє маркетинговій та технічній команді краще взаємодіяти, розуміти потреби одна одної й оперативно вирішувати будь-які питання, що виникають у процесі роботи». Кейси успішного використання no-code платформ у маркетингу Роль no-code платформ у маркетингу стартапів і середнього бізнесу така: вони дозволяють швидко тестувати гіпотези, автоматизувати ключові процеси та ефективно масштабуватися без значних інвестицій у розробку. Стартапи: швидке масштабування без значних витрат Для стартапів важливо швидко масштабувати бізнес та ефективно використовувати обмежені ресурси. No-code платформи, зокрема Zapier, дозволяють інтегрувати різні системи без потреби у програмуванні, що дає змогу автоматизувати ключові процеси. Наприклад, стартапи можуть використовувати Zapier для автоматизації лідогенерації, обробки заявок через форму на сайті та інтеграції з Google Sheets. Це дозволяє значно скоротити час на обробку запитів та зменшити потребу в додаткових ресурсах, що особливо важливо на етапі запуску бізнесу. Приклад:  SaaS-стартап може автоматизувати процес обробки запитів користувачів через форму на сайті. Дані з форми автоматично потрапляють в CRM-систему, а користувач отримує миттєвий email із деталями про продукт. Це не лише спрощує процес взаємодії з клієнтами, але й підвищує ефективність команди, значно скорочуючи час обробки заявок. Середній бізнес: приклад автоматизації роботи з клієнтами за допомогою CRM + Zapier Для середнього бізнесу важливо інтегрувати маркетингові процеси з іншими бізнес-системами для ефективного управління взаємодією з клієнтами. Zapier дозволяє створювати автоматизовані робочі процеси, які інтегрують CRM-системи, email-розсилки та інші канали комунікації, що дає змогу знижувати витрати часу та зусиль. Приклад:  компанія середнього бізнесу використовує Zapier для інтеграції CRM з email-розсилками, створюючи автоматизовану систему лояльності. Покупки клієнтів реєструються в CRM, і спеціальні пропозиції надсилаються через email або SMS. Це дозволяє автоматично реагувати на потреби клієнтів і підвищити ефективність маркетингових кампаній. «Як це відбувається у нас —- креативний маркетолог ставить таску дизайнеру для створення креативу, і вона потрапляє в нашу систему. Коли дизайнер починає працювати, він змінює статус на  «In progress». Як тільки він завершує роботу, статус змінюється на  «Done», і креативний маркетолог отримує сповіщення, щоб провести рев'ю. Якщо є помилки або щось потрібно виправити, він повертає завдання в «In progress». Якщо все в порядку  —- ставить його в статус «Reviewed». Далі, як User Acquisition Manager, ми отримуємо це завдання, і воно потрапляє в іншу вкладку, де ми запускаємо кампанії. Тут я просто обираю готову концепцію та відповідний template для кампанії, який можна змінювати чи додавати за потреби. Оскільки тести зазвичай запускаються в однаковому форматі, я обираю потрібний template, роблю кілька кліків і натискаю  «Launch». За кілька секунд креатив з’являється в рекламному кабінеті. Цей процес працює майже однаково швидко для статичних і відеокреативів. Раніше запуск таких кампаній займав кілька годин, а тепер ми робимо це за 10 хвилин. Це неймовірно спрощує роботу». Основні тренди в автоматизації маркетингу no-code платформами Світ автоматизації маркетингу швидко розвивається, а   безкодові інструменти стають все більш популярними серед бізнесів. Ось кілька трендів, які визначають майбутнє no-code автоматизації: Інтеграція зі штучним інтелектом No-code платформи поступово інтегрують функції штучного інтелекту для покращення маркетингових процесів. Наприклад: Автоматичне прогнозування результатів кампаній на основі історичних даних. Оптимізація контенту email-розсилок за допомогою ШІ. Використання ШІ для створення персоналізованих маркетингових воронок. Тренди автоматизації маркетингу свідчать, що штучний інтелект стане важливою частиною no-code платформ у найближчі роки. «Майбутнє автоматизації в рекламних креативах обіцяє бути дуже цікавим. Наприклад, вже зараз ми використовуємо ШІ-аватарів (цифрові персонажі, створені та керовані штучним інтелектом. Можуть виглядати як реальні люди, повторювати їхню міміку, говорити природним голосом та навіть взаємодіяти з користувачами в режимі реального часу). AI-анімація губ дозволяє розширювати рухи рота у відео, створюючи ілюзію, що персонаж говорить більше слів. Це дає змогу швидко адаптувати креативи на різні мови, синхронізуючи губи під нову озвучку без перезапису. Інструменти як HeyGen, Synthesia, D-ID роблять це ідеальним рішенням для масштабування контенту. Розширення функціоналу no-code платформ у 2025 році З кожним роком no-code інструменти стають потужнішими, а їх функціонал — більш спеціалізованим: Підтримка складніших інтеграцій через розширені API. Поява інструментів для створення більш персоналізованих маркетингових кампаній. Розробка вбудованих аналітичних модулів, які дозволяють бізнесу відстежувати ефективність кампаній у реальному часі. Майбутнє no-code автоматизації передбачає ще більше можливостей для малого та середнього бізнесу завдяки спрощенню складних технічних задач. Катерина Романенко сформулювала чотири ключові принципи, яких варто дотримуватись тим, хто починає працювати з no-code платформами.  Почніть із простих рішень і тестів. Не намагайтеся одразу створити складні логічні ланцюжки чи передбачити всі варіанти розвитку подій. Почніть із MVP або простих інтеграцій (наприклад, створіть 1-2 базові автоправила в Revealbot) і поступово ускладнюйте. Аргументуйте свої ідеї та ініціативи. Важливо чітко формулювати завдання для розробників , особливо в усній формі — на дзвінках або офлайн, щоб уникнути непорозумінь і з'ясувати можливі блокери. Не бійтеся пропонувати свої ідеї та ініціювати зміни. Важливо бути впевненим у своїх вимогах, щоб донести їх до розробників. Шукайте можливості для вдосконалення процесів. Навіть якщо завдання здаються незначними і займають не забагато вашого часу, не зупиняйтесь. Автоматизація дозволяє заощаджувати час у майбутньому, тому завжди шукайте способи зробити процеси більш ефективними. Плануйте майбутнє масштабування. Якщо проєкт буде рости, no-code може мати обмеження (повільність, дорогі API-запити). Тому варто продумувати перехідні сценарії на low-code або full-code рішення при зростанні навантаження.

TypeScript — найпопулярніша мова програмування в українському IT. Згідно з дослідженням DOU, TypeScript обійшов JavaScript, який змістився з першого місця одразу на третє . Її використовують близько 17% українських айтівців. Хоча в комʼюніті досі продовжуються суперечки, схоже, що розробники нарешті розібралися в головних перевагах. Віктор Галочка, Front-End Developer в Lift, який у свій час перейшов з JavaScript на TypeScript, розповів, як пережити мовний «джетлаг» та не припуститися помилок. У колонці для блогу Genesis Віктор прокоментував, чому TypeScript — це дещо більше, ніж просто анотація типів, а використовувати стилістику JS у проєктах TS — те саме, що колоти горішки девайсами Dyson. А також пояснив, чому забути про 'undefined' is not a function — безцінно. І тільки за це можна пробачити цій мові всі недоліки. TypeScript — мейнстрим чи необхідність На початку 2010-х команда Microsoft шукала рішення, яке б дозволило створювати на JavaScript великі та складні програми. На той час JS активно зростала та розвивалася, здобуваючи прихильність розробників. Ця мова давала багато свободи й водночас недостатньо контролю. Щоразу, коли проєкти починали зростати, у командах змінювалися люди, підтримувати код на JS ставало все складніше. TypeScript був розроблений під керівництвом Андерса Хейлсберга, надихаючись іншими мовами програмування — Java, C# і Objective-C. За словами Райана Кавано , Lead Engineer в Microsoft та одного з творців TypeScript, команда бачила концептуальний розвиток JS саме через статичну типізацію. Попередні експерименти із синтаксисами та створенням нових мов, на кшталт Script# чи CoffeeScript, не вдалися. На цей раз вони вирішили просто взяти JavaScript і додати статичні типи поверх нього. Так 2012 року зʼявився суперсет TypeScript, який дозволяв розробникам написати більш масштабований і легкий у підтримці код, надаючи такі функції, як статичний тип, інтерфейси, класи та модулі. Це рішення мало покращити якість коду та зменшити кількість помилок у фінальній збірці продукту. А головне — забезпечити більшу надійність, водночас зберігаючи гнучкість і простоту JavaScript. Спершу спільнота сприйняла TypeScript без ентузіазму. Скоріше за все, мало хто зрозумів, навіщо так ускладнювати звичний JavaScript. Переломним моментом став 2016 рік, коли вийшла друга версія Angular — популярного фреймворку із відкритим вихідним кодом для створення вебзастосунків. Спочатку він працював на JavaScript, але 2016 року був переписаний на TypeScript, після чого їхня популярність почала пропорційно зростати. Це добре видно у статистиці запитів на Stack Overflow. За що програмісти люблять TypeScript З моменту розробки TypeScript активно розвивається. Сьогодні складно уявити великий складний проєкт на фронтенді, написаний на JS без використання TS. Звичайно, хороший розробник може створити чітку архітектуру на JS, але, з мого досвіду, ця мова частіше використовується тоді, коли для задачі критична швидкість. Наприклад, потрібно зробити лендінг і покрутити пару днів рекламу, щоби потестити якусь ідею. У такому випадку недоцільно прописувати його на TS, закладаючи перевикористану логіку та витрачаючи дорогий час розробки. Головна цінність TypeScript — можливість писати стабільні та масштабовані проєкти. Розробникам, що прийдуть у проєкт пізніше, буде легше розібратися в задумці тих, хто його створював. Коли бачиш прописану сувору типізацію, чітко розумієш, за що відповідає той чи інший компонент. Якщо раптом один із них не відповідає певній задачі, можна створити інший та закласти в це певну логіку, без утворення безладу. У проєкті, написаному на TypeScript малоймовірна ситуація, що в коді одна функція робить половину всього. Переваги TypeScript: Має добре реалізовану підтримку ООП, дозволяє розробникам ефективніше використовувати класи, інтерфейси. У результаті код виходить більш структурним та цілісним. Надає можливість писати модульний код, придатний для повторного використання. Простіше працювати в команді та підтримувати код, розуміти, яку логіку закладав попередній розробник. Завдяки редактору IDE є можливість виявляти та виправляти помилки ще під час розробки, а не на етапі тестів чи ще гірше — після релізу. Підтримка на рівні всіх платформ — у вебі, мобільних та десктоп застосунках. Інтеграція з різними бібліотеками та фреймворками JavaScript. Крім Angular, може використовуватися з такими популярними інструментами, як React, Vue. Перехід з JS на TS: як подолати джетлаг Я починав свій шлях на фронтенді з вивчення JavaScript. Пізніше працював на Angular, де познайомився з TypeScript. Із цього й почалося «доросле» програмування. Коли довгий час пишеш на JS, а потім різко переходиш на TS, виникає джетлаг. Ти звикаєш до певної швидкості написання коду, а тут усе складніше й довше: підготовка, написання, виправлення помилок, пошук відповідей. Наприклад, коли знаходиш цікаве рішення на Stack Overflow, написане на JS, знадобиться додатковий час, щоби конвертувати його під свій проєкт та вимоги. Поріг входу до TS вищий. Це той випадок, коли для того, щоби писати на TypeScript, треба знати дві мови — JavaScript та безліч нюансів статичного набору тексту, додаткового синтаксису, дженериків та інтерфейсів. Бажано бути в курсі специфікації, але найголовніше — розуміти концепцію, для чого був створений TS. Я стикався з багатьма проєктами, написаними джуніорами та мідлами. У момент, коли їх треба було масштабувати, виявлялося, що на старті про це не подумали. Після такого досвіду не виникає питань, навіщо проєкту типізація та інтерфейси. Тип ‘any’ та локальні пожежі Зниження швидкості розробки при переході на TS спричинює найпоширенішу помилку — розробники починають писати, зберігаючи стиль JS. Наприклад, створюючи компонент, прописували тип ‘any’. Це як гаджетами Dyson колоти горіхи — у тебе є крутий інструмент, але ти його не використовуєш за призначенням. Буває, що немає часу повноцінно адаптувати знайдене рішення на JS під усі вимоги TS, тому його швидкома переписують за принципом «щоб працювало». Але важливо це помічати й обовʼязково потім фіксити. Бо якщо таких «вставок» буде багато, неодмінно почнуться локальні пожежі, і ви втратите головні переваги проєкту на TS — стабільність та масштабованість. Раджу одразу звертати увагу на сувору типізацією, намагатися використовувати й інтерфейси й типи, дженерики й декоратори. Фокус на тому, що ці зусилля — не даремні, і в майбутньому ваш проєкт бути швидким, стабільним та зрозумілим для інших розробників, може допомогти. Їсти на сніданок вівсянку теж не хочеться, але бенефіти обовʼязково прийдуть. Недоліки TypeScript: Складність входу. Для розуміння та ефективного використання додаткового синтаксису та функцій може знадобитися час. Довший час розробки. Складніші налаштування проєкту TS, може потребувати додаткових інструментів і конфігурацій. Довгий час компіляції: оскільки TypeScript вимагає етапу перетворення коду у JavaScript, це може ускладнити швидку ітерацію. Проблеми сумісності при використанні сторонніх бібліотек або фреймворків. Ускладнений найм. Чотири міфи про TypeScript 1. TS гарантує надійність коду. Використання TypeScript є одним із компонентів, який надає йому стійкість, як і покриття юніт-тестами. Жодною із цих складових не варто нехтувати. TS не захищає від помилок архітектури або механічних, корнер-кейсів, того, що розробник щось не врахував, і в результаті застосунок «склався». Він не вирішить усіх проблем, але точно додасть певний відсоток стабільності. 2. У великих проєктах на TS код стає занадто складним, дублюється. TS — це просто інструмент. Ручкою можна писати охайно та не дуже. Так і тут. Повтори фрагментів коду — це питання стилістики, і неважливо, якою мовою ви пишете. Можна на TS писати дуже поганий код, а на JS — хороший. Інтерфейси є потужною функцією TypeScript, яка може допомогти зробити код більш придатним для повторного використання та модульним. З їхньою допомогою можна зменшити кількість зайвого коду та полегшити його обслуговування. 3. Аналізатор помилок лише заважає. При переході на TS редактор IDE може дратувати, збивати та ще більше сповільнювати й так нешвидку розробку. Ніби у вас на смартфоні раптом включили Т9. Але на дистанції це дає перевагу, бо є змога на ранньому етапі врахувати та виправити помилки. Також не забувайте, що можна налаштувати конфігурацію під свій проєкт, наприклад, що редактор вважатиме помилкою, а що ні. 4. Проєктувати на TS — дорого. Розробка на TS збільшує етап написання коду, але спрощує інші процеси, наприклад, код-ревʼю, та економить час на виправлення помилок. Не боятися побачити після релізу 'undefined' is not a function — безцінно. Тож ця інвестиція значною мірою окупається. Отже, довгий час TypeScript сприймався як мейнстрим та використовувався не за призначенням. Але коли розробники справді зрозуміли його цінність та філософію, він почав швидко зростати. На мою думку, на цей час немає технології, яка б могла його затьмарити. З кожним оновленням, розробники намагаються зменшити його недоліки, зробити простішим та швидшим. Так, нещодавно вийшов TypeScript 5.0. Основні зміни стосуються вдосконалень у структурі коду, алгоритмах та роботи з даними. Оновлення вийшли не глобальними, але є цікаві речі, з якими варто ознайомитися: Загальне покращення швидкодії коду на 10-20%. Оптимізація використання памʼяті. Розмір самого пакету суттєво зменшився — на 41% (з 63,8 mb до 37,4 mb) порівняно з TypeScript 4.9. Декоратори (інструмент, що дозволяє розширити поведінку класів і методів). Якщо попередні версії підтримували експериментальні версії декораторів та вмикалися лише за допомогою флагів experimentalDecorators, то тепер вони вбудовані в TS і можна ознайомитись, як вони працюють. Ймовірно, на цей крок пішли, щоби зберегти сумісність, якщо декоратори стануть частиною стандарту ECMAScript . ModuleResolution bundler. Щоби оновити застарілі moduleResolution node, node16 і nodenext, які мали проблеми з експортом, були незручними та громіздкими, в TypeScript 5.0 додали сучасний --moduleResolution bundler. Він має гібридну стратегію, чудово ладнає з класичним Node-style та підтримує правила експорту та імпорту. Підтримка кількох конфігураційних файлів у extends. Ця фіча використовується, коли треба звернутися до певних файлів 'tsconfig.json', що містять ті чи інші налаштування. В останньому оновленні зʼявилася можливість звертатися одразу до кількох файлів.

Останній понеділок січня 2025 року розпочався для Nvidia непогано: її ринкова вартість була рекордною у світі й становила понад $3,4 трильйона. Однак уже до вечора американський виробник мікросхем опустився на третє місце, поступившись першістю Apple та Microsoft. Цього ж дня компанія побила  ще один рекорд: її капіталізація впала на 17% — це майже $600 млрд. Водночас впали показники індексів Nasdaq та S&P 500 — на 3,1% та 1,5% відповідно.  У Європі сталося  дещо подібне: ціна акцій ASML, голландського виробника обладнання для виробництва мікросхем, впала більш ніж на 10%, а акції Siemens Energy, що виробляє апаратне забезпечення, пов'язане зі штучним інтелектом — на 21%. «Постраждали»   також 500 найбагатших людей світу, зокрема співзасновник Nvidia Дженсен Хуанг (він втратив $20,1 млрд, тобто 20% своїх статків), засновник Oracle Ларрі Еллісон ($22,6 млрд) та засновник Dell Майкл Делл ($13 млрд). Загалом найбагатші люди світу залишилися без $108 мільярдів.  Причину настільки амплітудного коливання ринку штучного  інтелекту слід шукати у китайському місті Ханчжоу. Саме там знаходиться дослідницька лабораторія DeepSeek, яка і наробила галасу у всьому світі.  Що варто знати про DeepSeek DeepSeek заснували  2023 року під крилом китайського хедж-фонду High-Flyer, який використовував машинне навчання для торгівлі акціями. Очільником нового проєкту став Лян Веньфен, один з трьох співзасновників High-Flyer. Лабораторія на пов'язана з торгівлею акціями й працює окремо від фінансового бізнесу High-Flyer.  Лян Веньфен почав скуповувати  графічні процесори Nvidia ще 2021 року — до того, як США заборонили їхній експорт до Китаю. Спочатку всі розцінили цей крок як нове екзотичне хобі мільярдера, однак потім виявилося, що все не так просто. Випущені раніше графічні процесори Nvidia у парі з дешевшими мікросхемами, які все ще може імпортувати Китай, дозволили Ляну запустити чат-бот. Лян особисто бере участь у дослідженнях DeepSeek, а його кадрова політика щодо технічних фахівців базується  на наймі молодих докторантів та недавніх випускників провідних китайських вишів.  У чому феномен DeepSeek Перший чат-бот з’явився у грудні минулого року. Але по-справжньому дослідницькою лабораторією зацікавилися після випуску новішої моделі, DeepSeek R1. За можливостями продукт не поступається продуктам OpenAI, Google та Anthropic. «Чутки, що ця модель краща — перебільшення. Це логічний розвиток технологій ефективного тренування моделей», — каже Ігор. Чим же DeepSeek вдалося так сильно вразити технологічний світ? По-перше, для запуску нейромережі знадобилося близько 2048 чипів Nvidia та близько $6 млн, стверджують  розробники. Це повністю змінює правила гри на ШІ-ринку, де провідні гравці не фокусуються на оптимізації процесі тренування та витрачають на них та підтримку інфраструктури мільярди доларів.  Численні тести показують, що китайська мова модель, попри дешевизну та меншу кількість необхідних для тренування чипів не поступається «старшим» мовним моделям. Джерело: https://huggingface.co/deepseek-ai/DeepSeek-R1   По-друге, DeepSeek R1 — open-source проєкт. Відкривати ваги моделі — це доволі розповсюджена практика: так давно роблять Meta, Google, Mistral, аби пришвидчити ШІ-революцію. « Деякі компанії стимулють використання своїх open source напрацювань. Meta, наприклад започаткувала ініціативу Llama Impact Grants , видаючи гранти за рішення з найбільшим впливом на основі своєї моделі Llama, а Google проводить конкурси на платформі Kaggle повʼязані з використанням open source моделі Gemma . Втім, DeepSeek пішли далі: вони опублікували технічний звіт  для state-of-the-art моделі. Знову таки, подібні звіти викладали й раніше, але тоді мовні моделі не були настільки потужними. Зараз це роблять набагато рідше, тобто рішення DeepSeek — це майже безпрецедентний кейс», — говорить Ігор Крашений.  По-третє, командна значно просунулася у розвитку автономного навчання моделей ШІ, мінімізуючи залежність від великих обсягів даних і оптимізуючи використання обчислювальних ресурсів. Вони вдосконалили архітектуру своїх моделей за допомогою власних схем зв’язку між мікросхемами, зменшення пам’яті та інноваційного поєднання існуючих методів, як-от Multi-head Latent Attention (MLA) і Mixture-of-Experts. Найважливіше — моделі DeepSeek навчилися генерувати інформацію автономно завдяки чистому навчанню з підкріпленням і ретельно розробленим функціям винагороди. Вони також можуть генерувати довгі ланцюжки думок і навіть самостійно перевіряти власну роботу.  Ще одна особливість — цензура, яка, утім, не оминає й інші китайські чат-боти, як-от Ernie Bot від Baidu. На запитання про Сі Цзіньпіна, політику щодо уйгурів чи Тайвань DeepSeek R1 пропонує   «поговорити про щось інше». Оновлено: Perplexity уже інтегрувала R1 у свій сервіс — пошукову систему на основі штучного інтелекту. Завдяки цьому користувачі можуть уникнути цензури, оскільки дані оброблятимуться на серверах у США. Правда, щоб використовувати «прокачаний» пошуковик потрібна платна підписка. Як відреагували ринки  Розробка DeepSeek R1 спричинила   дискусію у Кремнієвій долині: чи вдасться американським компаніям зберегти першість у ніші штучного інтелекту.   Венчурний інвестор та засновник а16z Марк Андріссен назвав  DeepSeek «одним із найдивовижніших і вражаючих проривів, які він коли-небудь бачив».  Олександр Ван, СEO Scale AI визнав , що модель від китайців «має найкращі або приблизно однакові з найкращими показниками американських моделей» і додав , що це «wake-up call для індустрії в Штатах».  Джим Фан, Senior Research Manager у Nvidia оцінив  хід з open source код: « Ми живемо в часи, коли неамериканська компанія підтримує оригінальну місію OpenAI — справді відкриті передові дослідження, які дають змогу всім». Сем Альтман, CEO OpenAI вважає , що «R1 дійсно вражаюча модель, особливо за свою ціну» ( вартість обробки мільйона токенів у DeepSeek — $0,14, тоді як OpenAI бере за це $2,5 — ред. ). Однак додав, що «ми [OpenAI]  запропонуємо набагато кращі моделі», а «те, що у компанії з'явився новий конкурент, дуже надихає».  До релізу R1 ніхто не думав конкурувати з гігантами на кшталт OpenAI чи Meta на цьому полі. Але тепер «стало цілком зрозуміло, що інші компанії можуть створювати такі системи. DeepSeek використовував методи, які кожен може скопіювати», — говорить  Тім Деттмерс, дослідник Інституту штучного інтелекту Аллена в Сіетлі та професор інформатики в Університеті Карнегі-Меллона.  Тим часом Лян став  предметом національної гордості на батьківщині. Цього тижня його запросили на зустріч підприємців із другим за впливовістю у країні Лі Цяном. Підприємцям запропонували «сконцентрувати зусилля на прориві в ключових базових технологіях». Засновник DeepSeek Лян Веньфен. Джерело: The New York Times Утім, не встигнувши запуститися компанія уже зіштовхнулася з певними труднощами. По-перше, через день після запуску реєстрацію нових користувачів призупинили  через масштабну кібератаку. По-друге, OpenAI звинуватила  DeepSeek у використанні їхніх моделей для навчання власної нейромережі. Заявляють про ознаки «дистиляції» — методу, за якого вихідні дані потужніших моделей застосовують для покращення продуктивності слабших, що порушує умови користувацької угоди OpenAI.  Крім того, релізу багатообіцяючої моделі o3 від OpenAI ще не було, але, за чутками , її продуктивність у стандартних еталонних тестах була більш вражаючою, ніж будь-що інше на ринку.  «Глобальна експансія R1 можлива, і, ймовірно, роботи з продуктизації відкритої версії моделі вже ведуться. Люди люблять безкоштовне. Навіть OpenAI уже відреагував і знизив ціну для ChatGPT Plus до $10 для нових користувачів. Але я думаю, що такий прецедент призведе скоріше до більш агресивної гонки великих мовних моделей, і, замість гонитви за відсотками на бенчмарках, вони будуть ганятись ще і за відсотками в ефективності тренування й дешевизни продуктизації», — розмірковує Ігор Крашений.

Багато власників бізнесу, особливо малих і стартапів, вважають, що бренд — це логотип, кілька дизайнерських рекомендацій і трохи сувенірної продукції. Але насправді бренд — це щось значно більше за візуал.  Видавництво Strerovych нещодавно презентувало книжку про те, як будувати бренд, маркетинг і комунікації , яку написала Юлія Колесник, Head of Brand & Communications у Hily, продукті IT-компанії appflame. Авторка говорить, що про бренд неможливо говорити, якщо не говорити про людину. Найбільша помилка — не враховувати людський фактор у продажах, і тоді  всі «магічні маркетингові таблетки» та «завжди ефективні підходи всього за $99 чи $1,999 чи $99,999» перетворюються на культ Карго. У колонці для High Bar Journal Юлія розповідає про своє бачення процесу побудови бренду та про те, чому гроші на брендинг — не витрати, а інвестиція в майбутнє бізнесу. Direct response маркетинг і всі його похідні називали «вбивцями бренд-маркетингу» ще не так давно. Раніше вважалося, що правильна воронка та відтестовані до ідеалу креатив и легко піднімуть бізнес на вершину і допоможуть там закріпитися. Зараз для багатьох бізнесів, що покладалися на 100% на direct response маркетинг, очевидно, що CAC не стає нижчим рік від року, а ROAS падає, як тільки скейлінг виходить на значні об‘єми. Що робити?  Короткотермінові підходи працюють справно, проте обмеження, поза якими така модель починає втрачати ефективність. Тут і починають звертатися до бренду — саме він здатен покращити й direct response-зусилля, і органічні продажі.  Де насправді живе бренд? У фінансовому світі бренд відносять до групи нематеріальних активів бізнесу, таких як авторські права, патенти, контент, ноу-хау, особливі процеси, бази клієнтів тощо. Вартість цього нематеріального активу — бренду — не оцінюється вартістю, яку ви заплатили за лого або брендбук. Наприклад, бренд Samsung коштує $99,4 мільярди. Чому так? Суть бренду полягає в сприйнятті, а не у візуальних елементах. Це не набір символів, а асоціації, які ці символи викликають у свідомості аудиторії. Логотип стає брендом і бізнес-активом лише тоді, коли він несе в собі значення та цінність, що виходить за межі його візуальної форми.  Крім гарного лого, потрібно ще щось, що це лого може символізувати. Тобто, потрібні асоціації, і вони мають бути достатньо стійкими, щоби згадатися споживачеві тоді, коли у нього виникне потреба в продукті. Це те, що Байрон Шарп називає mental availability. Зараз новинні та соціальні стрічки користувача забиті контентом під зав’язку. Потрапити йому на очі просто, але бути поміченими і виокремленим із потоку — набагато складніше. Сприйняття аудиторії змінюється — воно розвивається з часом під впливом зовнішніх факторів, змін на ринку та культурних зрушень. Якщо щось достатньо довго не знаходиться у полі уваги, воно перестає для нас існувати. Тож бренд має постійно формувати себе і зміцнювати свою ідентичність, адаптуючись до цих змін та повторюючи себе знову, знову і знову. Побудова бренду як безперервний процес На відміну від фізичних активів, бренд взагалі не є статичною величиною. Компанія не може просто «побудувати» бренд і очікувати, що він залишатиметься ефективним постійно. Він потребує регулярних інвестицій — і не лише фінансових. Досягти яскравої «хвилини слави» через влучний ТіkТок, ролик або PR-скандал можна, а от закріпитись у пам'яті споживачів набагато складніше. Це схоже на спорт: якщо після марафону припинити тренування, рівень фізичної підготовки знизиться, і за певний час повторити те саме досягнення буде неможливо. Так само, якщо бренд перестає зміцнювати свою присутність і актуальність, він поступово зникає з пам’яті споживачів.  Це робить очевидним те, чому підхід «ми зробили новий логотип, написали проникливу місію, тож продажі повинні зрости» не працює. Бренд — це точно не те, що покаже миттєвий високий ROI. Це довгострокова інвестиція, результати якої стають помітні не одразу і накопичуються з часом. Тому процес роботи над брендом варто розділяти на дві частини . По-перше, це розробка бренду, результатом якої стане брендбук, з візуальною та сенсовою частинами. На первинних етапах це, в кращому випадку, добре аргументована гіпотеза стратегії бренду та приваблива для аудиторії візуальна айдентика. І по-друге, це  побудова бренду —  все, що відбувається в контакті зі споживачем, в ідеалі, кожного разу коли він взаємодіє з брендом.   Баланс, завдяки якому живе бренд  Сильний бренд — водночас мистецтво і наука. Це дослідження, психологія споживачів, тести, метрики та стратегічне планування у поєднанні з креативом, сторітелінгом, дизайном та встановленням емоційного зв’язку.  Втім, у цьому рівнянні ще є одна пара протилежностей — ризик та дисципліна. Зазвичай, це стосується людей, які відповідають за бренд, —  маркетинг-директорів, бренд-менеджерів, CBO, CMO або будь-якої іншої людини, яка волею випадку опинилася на місці того, хто приймає рішення про «запускати чи не запускати». Почнемо з ризику. Будь-який яскравий хід несе певні ризики, адже ви часто робите щось, що до вас не робили, — щоби виділитися на фоні інших. Це постфактум такі кампанії та ходи виглядають 100% правильними та геніальними, а в моменті прийняття цього рішення все дуже неясно і невпевнено, і багато хто до ризику не є готовим. Повна протилежність цьому — це дисципліна. Знову і знову ставити лого; вперто візуалізуватися в фірмовому кольорі, а не в кольорі сезону; знову і знову використовувати теглайн, який качаєте роками. Бренд вимагає балансувати між тим, щоб ризикувати і тим, щоби наполегливо робити щось знову, і знову, і знову.  Чому побудова бренд — це інвестиція, а не витрати Багато компаній вважають бренд другорядним і чимось, що існує для краси. Вони припускають, що якісний продукт або послуга самі себе продадуть. І вони дійсно себе непогано продають на ринку, де існує велика проблема із якістю. Втім, більшість сучасних ринків є насиченими пропозиціями, які приблизно одного рівня якості і об’єктивно мають мало суттєвих, продуктових відмінностей. Взуття це взуття. Газований лимонад — це газований лимонад. Функціональні переваги трапляються, але якщо бути відвертими, — з точки зору споживача в 90% випадків вони важать небагато або залишаються непоміченими.  Візьмемо бігове взуття Nike. Чи купують його частіше за взуття бренду Norda тому, що воно функціонально краще? Ні. Чи згадаєте ви Norda якщо я вас попрошу навести бренди кросівок? Теж ні. Тож купують більше не взуття , а саме бренд  Nike. Просто тому, що люди його знають, мають певні асоціації та не хочуть «паритися» забагато цим питанням. Професійні атлети, які бігають трейл, мабуть, оберуть Norda, але ж пересічний споживач — не спортсмен, правда? І з точки зору бізнесу, атлетів тисячі, а от простих людей — сотні мільйонів.  Реклами кросівок Nike (ліворуч) та Norda Споживачі купують бренди, а не товари, в тих категоріях, де сильні бренди існують. Вони існують там, де хтось найуспішніше зміг закріпитися в свідомості споживачів. А бренди починають будувати в тих категоріях, де є потенціал масштабування на дійсно масову аудиторію. Все це має цілком конкретну бізнес-цінність. Чи означає це, що всім треба швиденько запускати широкі brand awareness кампанії з телебаченням та зірками? Ні. Але варто інвестувати в бренд з самого початку — не обов’язково шляхом великих бюджетів, а через чіткість та послідовність у брендингу і побудову стосунків зі споживачами.  Бренд — це «довга гра», а його побудова — це довгостроковий процес, що вимагає терпіння, уміння брати на себе ризики, стратегічного бачення та постійної роботи. Найуспішніші бренди — не ті, що мають яскраві логотипи, а ті, що послідовно зміцнюють свою ідентичність у свідомості аудиторії. Крок за кроком, канал за каналом та активація за активацією. Люди забувають, особливо зараз, коли інформації та яскравих рухливих картинок настільки багато. Тож бути терплячими, послідовним та нагадувати про себе, знаходячи яскраві способи привернути людську увагу — це і є те, що будує бренд.

19 січня у Сполучених Штатах набув чинності   закон, що забороняє роботу TikTok. Цього можна було уникнути, якби китайська компанія-власниця застосунку, ByteDance, погодилася його продати. Однак заборона протрималась 12 годин — її на 75 днів відтермінував новий президент США Дональд Трамп. Застосунок привітав користувачів словами «Дякуємо за ваше терпіння і підтримку. Зусиллями президента Трампа TikTok повернувся до США!». Його використовують 170 млн жителів Сполучених Штатів. Розбираємось у ситуації навколо TikTok. Заборона TikTok: таймлайн Чому TikTok намагались заборонити Законодавчі органи Штатів роками висловлювали стурбованість щодо конфіденційності даних у застосунку. Це й не дивно — закони Китаю дозволяють   уряду отримувати дані від китайських компаній під час збору розвідувальної інформації.  З чого все почалось? У вересні 2019 року The Washington Post написав , що TikTok — єдина соцмережа, де відсутній контент стосовно протестів проти авторитарного режиму і поліцейського тиску у Гонконгу. У відповідь платформа наголосила, що є місцем для розваг, а не для політики. Тоді ж стало відомо , що внутрішні правила компанії зобовʼязують модераторів видаляти або обмежувати доступ до відео, що стосуються чутливих для Китаю тем, зокрема, протестів на площі Тяньаньмень у 1989 році та незалежності Тибету. У січні 2020 Пентагон заборонив усім військовослужбовцям використовувати TikTok. У серпні того ж року Дональд Трамп видав указ, що заборонив американським бізнесам усі можливі транзакції з TikTok, а наступним — указ, що вимагав ByteDance припинити роботу застосунка у США на 90 днів. Однак 2021 року почалася каденція Байдена, який призупинив усю діяльність із заборони TikTok у Штатах.  У 2022-му TikTok спочатку зіштовхнувся із звинуваченнями у розповсюдженні контента, який провокує розлади харчової поведінки у підлітків. У відповідь платформа внесла зміни до своєї політики стосовно контенту. Того ж року стало відомо, що співробітники ByteDance у Китаї мали доступ до приватної інформації користувачів. TikTok переніс дані юзерів на сервери у США — під опіку компанії Oracle.  У грудні 2022 року ФБР попередили громадян США, що китайський уряд може маніпулювати рекомендаційним алгоритмом. За два місяці Білий дім наказав видалити TikTok з державних   мобільних — було зрозуміло, що дані користувачів можуть потрапити до китайського уряду.  Навесні минулого року законопроєкт ухвалили обидві палати парламенту США.  17 січня 2025 року Верховний суд також одноголосно підтримав федеральний закон про заборону TikTok, якщо ByteDance не продадуть його за межі Китаю. Користувачам TikTok у Сполучених Штатах закрили доступ до платформи за кілька годин до того, як закон набув чинності, — ще 18 січня. Застосунок видалили з AppStore  і Google Play, а на його веб-сайті користувачам повідомлялося, що платформа короткого відео більше не доступна. Вже 20 січня Трамп, щойно заступивши до обовʼязікв, випустив виконавчий указ, що відтермінував заборону на 75 днів.  Як діє указ Трампа Як пише   BBC, виконавчий указ Трампа не скасовує заборону TikTok, а доручає генпрокурору США тимчасово не виконувати закон. За цей час Адміністрація президента може визначити подальший план дій. Але навіть після закінчення 75 днів скасування заборони Трамп може доручити Міністерству юстиції США ігнорувати закон. При цьому він залишиться у силі.  Якщо уряд Штатів повідомить Google та Apple, що за доступ до завантаження TikTok їм не загрожує покарання, закон не буде фактично діяти, хоча й залишиться чинним. Трамп натякає, що охочих купити TikTok багато. Він вже говорив про розподілення TikTok 50% на 50% між ByteDance та США, хоча й не розʼяснив, як це буде влаштовано. Також можливо, що ByteDance внесе структурні зміни, які задовільнять вимоги адміністрації Трампа і дозволять застосунку працювати.  25 січня NPR написали, що Білий дім обговорює  з Oracle та «американськими інвесторами» угоду, що врятує TikTok. Згідно з нею, у ByteDance залишиться міноритарний пакет акцій , але алгоритми TikTok, збір даних та оновлення програмного забезпечення контролюватиме Oracle, яка вже забезпечує основу веб-інфраструктури застосунку. 27 січня Трамп сказав  журналістам, що переговори про придбання TikTok веде Microsoft, але не дав деталей. Все ще не зрозуміло, кому, на яких умовах і чи погодиться взагалі ByteDance продати застосунок.Чи стане заборона у США прецедентом для країн, де TikTok працює без проблем?

Одна з найбільш затребуваних професій на ІТ-ринку — продакт-менеджер. Він знайде спільну мову з розробниками, переконає дизайнера, яка кнопка зрозуміліша користувачу та допоможе маркетологам із позиціонуванням продукту. Він першим дізнається про баг та знайде, який «біль» користувача може вирішити продукт. Його роль, навички і компетенції відрізнятимуться залежно від розміру та структури компанії. Але без нього не обходиться жоден успішний запуск. Як проходить день продакт-менеджера, що він повинен знати й уміти, та як ним стати, розповіли Денис Латиш, Product Manager в Headway та Олександра Міщенко, Head of Product в Boosters. > Чим займається та за що відповідає > Як проходить день продакт-менеджера > Навички та компетенції > Що всі знають про роботу продакт-менеджера, але помиляються > Вхід у професію: як стати продакт-менеджером Чим займається та за що відповідає Продакт-менеджерів називають «нервовою системою» проєкту. Це спеціалісти, що працюють на стику бізнесу, маркетингу і технологій та синхронізують роботу всіх департаментів. Головна мета продакт-менеджера — створити прибутковий продукт, що відповідатиме очікуванням та потребам користувачів. Якби в команді не було продакт-менеджера, робота різних департаментів не стикувалася б між собою, а ще, вірогідно, кілька людей виконували б одне й те саме (непріоритетне) завдання. «Продакт-менеджер відповідає за запуск нових та розвиток існуючих продуктів, а тому працює на стику розробки, дизайну, маркетингу та бізнесу. Важливим є розуміння, хто користувачі продукту, та які в них потреби», — зазначає Денис Латиш, Product Manager в Headway. Часто на етапі стартапу та створення MVP (мінімально життєздатнього продукту) роль продакт-менеджера бере на себе СЕО. А коли компанія починає зростати, і його уваги потребують інші напрями, у команді з’являється продакт-менеджер. Або навіть декілька — для кожного нового продукту чи напряму. Продуктова команда зазвичай складається з відділів розробки, тестування, аналітики, маркетингу та дизайну. Продакт-менеджер — це людина, яка поєднує, контролює та координує їхню роботу. Звітувати за результати він має перед СЕО. Чим займається продакт-менеджер: Дослідження ринку, конкурентів, потреб користувача . В команди є десятки ідей, як покращити продукт. Щоб визначити, які фічі найкраще відповідають потребам користувача, продакт-менеджер досліджує ринок, проводить глибинні інтерв’ю. Висування та перевірка гіпотез . Якщо надсилати пуш-сповіщення активним користувачам, це може збільшити метрику «day-to-day retention» на 15%. Або, навпаки, спричинить її обвал? Продакт-менеджер має перевірити цю гіпотезу за допомогою А/В-тестів. Реліз нових фіч . Коли в команді приймають рішення реалізувати нову фічу, продакт-менеджер готує технічні завдання, розподіляє їх між командами, визначає дедлайни та технічні вимоги, а потім — відстежує прогрес. Він має організувати процес таким чином, щоб команди працювали синхронно: дизайнери вчасно зверстали екрани, тестувальники перевірили код, маркетологи підготували рекламну кампанію тощо. Управління беклогом (системою переліку завдань для розробників). Грумінгом беклогу називають наведення порядку в цій системі, визначення статусу, що виконано, а що ні. Пріоритезація завдань . Для кожної команди він визначає пріоритети: наприклад, цей баг виправити критично, а цей — можна в останню чергу. Пошук слабких місць . Коли застосунок потрапляє до тематичної підбірки рекомендацій App Store, продакт-менеджер має передбачити, що трафік та навантаження на сервер можуть різко зрости, та з розробниками вжити заходів, щоб він не «ліг». Розробка або зміна стратегії розвитку продукту . Наприклад, прибуток застосунку не покриває витрат, а кількість користувачів зростає досить повільно. Продакт-менеджер аналізує ситуацію та пропонує зробити півот — змінити фокус та позиціонування продукту. Планування . Наприклад, СЕО компанії хоче запровадити в проєкті нову технологію. Продакт-менеджер прораховує з відділом розробки, скільки ресурсів для цього потрібно, складає план, визначає дедлайн та презентує результат СЕО. Як проходить день продакт-менеджера «Перше, з чого починається мій робочий день — це перевірка всіх метрик на дешбордах», — розповідає Олександра Міщенко, Head of Product у Boosters. Дешборди — інформаційна панель, що відображає дані в реальному часі. У фокусі продакт-менеджера зазвичай такі метрики: рівень утримання користувачів (retention); статистика пуш-сповіщень; конверсія проходження «онбордингу» (етап знайомства нового користувача із функціоналом продукту); конверсія першої цільової дії; конверсія підписки; конверсія передплати та повторних оплат (rebill). Шлях користувача від завантаження застосунку до рішення придбати платну версію має певні етапи — реєстрація, знайомство, користування протягом пробного періоду тощо. Конверсія — це показник, скільки користувачів перейшло від одного етапу до наступного. Хтось видалить застосунок одразу після завантаження, хтось — після перших спроб використання. Зі 100 користувачів лише одиниці дійдуть до етапу оплати та стануть постійною аудиторією. Усі ці метрики відображаються на дешборді та ретельно вивчаються продуктовою командою. Вони вказують на слабкі місця та проблеми у застосунку. Якщо людина не зрозуміла, як користуватися продуктом, якщо виник баг з реєстрацією чи оплатою, якщо користувачам не сподобалася нова фіча — продакт-менеджер одразу побачить, що ця метрика «впала», та почне шукати проблему. «Якщо нічого не «зламалося», усі показники в нормі, я займаюся запланованою активністю: написанням технічних завдань, вивченням аналітики, дослідженням ринку та конкурентів, проводжу зустрічі із СЕО, керівниками команд, плануванням та грумінгом беклогу. Загалом 50–80% часу займає комунікація», — ділиться Олександра Міщенко. Продакт-менеджер взаємодіє з кожним, хто працює над створенням продукту. Він координує їхню роботу, але всі ці люди не підпорядковуються йому напряму, адже в кожній команді є свій керівник. Комунікація з департаментами передбачає як особисті зустрічі, так і спілкування в робочих чатах. Популярні інструменти для організації роботи: Slack — для комунікації; Jira — для ведення беклогу; Figma — для роботи з дизайнерами, створення прототипів та мокапів; Miro, Notion, Confluence — сервіси для спільної роботи, ведення завдань, управління проєктами та планування; Google Analytics, Amplitude, Tableau, Excel — аналітика та дешборди. Навички та компетенції Мартін Еріксон у книзі «Лідери продукту» пояснює суть компетенцій так: продакт-менеджер знаходиться в точці перетину трьох кіл — UX, технології та бізнесу. Бажано, щоби він мав досвід щонайменше в одній сфері та розумівся на базовому рівні в інших. «Я прийшов у продакт-менеджмент із технічним бекграундом, і вже в процесі заглиблювався в дизайн та аналітику. Вивчити базові принципи, зрозуміти, якими категоріями мислить дизайнер, з якими інструментами працює та на що звертає увагу — це необхідний мінімум», — розповідає Денис Латиш. Одночасне перебування продакт-менеджера в трьох сферах диктує один із найважливіших скілів — «helicopter view», тобто бачення загальної картини. Він має одночасно пам’ятати про юніт-економіку продукту (прогнозоване співвідношення прибутку та витрат — ред.), потреби користувача, враховувати доступні ресурси, слідкувати за дедлайнами, синхронізувати різні департаменти тощо. Щоб висувати та перевіряти гіпотези, продакт-менеджер має володіти інструментами збору та аналізу даних: інтерв'ю, опитування. «Для мене найскладнішою була технічна частина, бо я не маю відповідного бекграунду. Але в основних поняттях та концепціях можна розібратися. Продакт-менеджер не має писати код або верстати екрани, але він має розуміти суть цієї роботи», — пояснює Олександра Міщенко. Хард-скіли продакт-менеджера: пріоритезація завдань; формування та перевірка гіпотез; розуміння UI/UX дизайну; прийняття рішень на основі даних; знання різних циклів розробки та розвитку продукту; планування; системне та аналітичне мислення; збір та аналіз даних — проведення інтерв’ю з користувачами, створення опитувальників. Софт-скіли продакт-менеджера: вміння слухати, домовлятися, переконувати; ефективна комунікація; тайм-менеджмент; емпатія; helicopter view; тактичне та стратегічне мислення. «Важлива навичка — завжди залишатися стоїком. Проблеми регулярно трапляються в усіх проєктах. І треба не панікувати, а спокійно шукати рішення. Ця робота передбачає багато відповідальності, варто бути готовим до цього», — Олександра Міщенко, Head of Product у Boosters . Що всі знають про роботу продакт-менеджера, але помиляються Міф № 1. Обожнює спілкуватися з людьми. Насправді, це може навіть заважати, оскільки комунікація має приносити максимальну користь на кожну хвилину розмови. Цінно, коли продакт-менеджер вміє зрозуміло пояснити суть завдання та відповісти на запитання за 15, а не 60 хвилин. Міф № 2. Керує всіма командами. Продакт-менеджер — це скоріше про побудову здорових стосунків із людьми та лідерство, ніж управління та владу. Якщо у нього виникають непорозуміння з кимось із команди, вирішувати їх він має через керівника цієї людини. Міф № 3 . Сам вигадує продукти чи фічі. Насправді «вигадування» в класичному розумінні немає. Продакт-менеджери уважно стежать за ринком, як поводяться користувачі, прямі й непрямі конкуренти, що відбувається в суміжних нішах. Міф № 4 . Продакт-оунер, продакт-менеджер, проджект-менеджер — одне й те саме. Певні їхні обов’язки справді співпадають, але є й відмінності в цілях, завданнях, сферах відповідальності та компетенціях. Продакт-менеджер відповідає за повний життєвий цикл продукту . Він взаємодіє з усіма людьми, що беруть участь у створенні та розвитку продукту. Продакт-оунер — роль із методології Scrum . Його робота зав’язана більше на розробці, менше — на вивченні потреб користувача, UI/UX-дизайні. Він не фокусується на стратегічних питаннях. Проджект-менеджер в продуктовому напрямі відповідає за окремі складові продукту : організацію та планування робочих процесів. Класична ієрархія передбачає, що в цілому за продукт відповідає Head of Product. Якщо це велика компанія, в його підпорядкуванні може бути кілька продакт-менеджерів, які відповідають за окремі фічі чи напрями. Проджект-менеджер та продакт-оунер підпорядковуються продакт-менеджеру. В різних компаніях компетенції та зони відповідальності цих позицій можуть суттєво відрізнятися. В сервісних ІТ-компаніях роль проджект-менеджера значно більша ніж в продуктових. Вхід у професію: як стати продакт-менеджером У закладах вищої освіти не вивчають продакт-менеджмент. Тому зараз єдиним шляхом до цієї професії є перехід зі суміжних сфер. Найчастіше продакт-менеджерами стають розробники, маркетологи, бізнес-аналітики, проджект-менеджери. Перехід можливий трьома способами: розвиток всередині компанії; навчання на курсах, інтенсивах, в школах; самонавчання. «Я перейшов до продакт-менеджменту з позиції продакт-оунера. А перед цим був тимлідом розробників. У певний момент я зрозумів, що мене більше драйвить шукати рішення не на рівні конкретної задачі: коду, оптимізації, алгоритму, а на рівні потреб користувачів, запитів, продукту та бізнесу в цілому. Справді надихає, коли бачиш, що рішення, які ти втілив з командою, зробили кінцевого споживача щасливішим, вирішили його проблему. І в результаті покращилися бізнес-метрики та якість продукту», — Денис Латиш, Product Manager в Headway. Кар’єрне зростання можливе за грейдами: від джуніора до сеньйора. Піднімаючись на вищий рівень, у продакт-менеджера в підпорядкуванні з’являється більше людей та збільшується зона відповідальності. Також можна зростати за складністю продукту або за ієрархією: продакт-менеджер може стати Head of Product, Chief Product Owner та навіть CEO, створивши власний проєкт.

Product Owner — це роль чи позиція? В аутсорсингових чи в продуктових ІТ-компаніях? Він підпорядковується продакт-менеджеру чи керує ним? Насправді компетенції, обовʼязки та ступінь впливу цього фахівця залежать від компанії, її розмірів, структури бізнесу, продукту та ще багатьох факторів. Артем Садурський, Chief Product Owner в Solidgate, партнерській компанії Genesis, розповів про дві популярні моделі взаємодії Product Owner з командою, про обовʼязки, ключові навички та виклики, а також пояснив, чим відрізняється ця позиція від продакт-менеджера. > Product Owner — роль у Scrum чи позиція > Чим відрізняється Product Owner від Product Manager > Чим займається Product Owner > Ключові навички > Виклики > Як стати Product Owner Product Owner — роль у Scrum чи позиція Поняття Product Owner вперше зʼявилося в методології управління проєктами Scrum у 90-х. Суть цього підходу — у гнучкості та пріоритезації завдань, які треба виконати протягом спринту (проміжок часу від одного до чотирьох тижнів). Власне, за це і відповідає Product Owner. А ще — за цінність продукту, комунікацію зі стейкхолдерами та всередині команди, щоби всі однаково розуміли цілі й завдання. Головна ідея цієї ролі — збирати вимоги стейкхолдерів, клієнтів, користувачів, обирати з них ключові та доносити команді разом зі своїм баченням кінцевого продукту. Цю роль можуть виконувати люди різних позицій — наприклад, бізнес-аналітик або навіть власник бізнесу. Крім Product Owner до традиційної Scrum-команди також входять розробники та Scrum-майстер, який відповідає за ведення беклогу і регулярні зустрічі. Але залежно від розмірів команд, специфіки компанії, ніші та багатьох інших факторів, цей фреймворк зазнає змін. Кожна команда адаптує його під себе. Так, у маленьких командах зазвичай немає Scrum-майстра, а всі його обовʼязки переходять Product Owner. А якщо в компанії є декілька команд, вимальовується зовсім інша схема взаємодії та зʼявляються нові ролі. Згодом ці трансформації фреймворку зайшли так далеко, що роль Product Owner стала окремою позицією. Чим відрізняється Product Owner від Product Manager Описи вакансій на ці дві позиції часто ідентичні — для однакового переліку обовʼязків компанії просто використовують різні назви посад. Але як взаємодіють ці спеціалісти в одній команді? Розділення обовʼязків та відповідальності продакт-менеджерів та Product Owner — дуже субʼєктивне. «Залежно від геометрії команди цей спеціаліст може стояти на різних сходинках ієрархії — бути керівником продакт-менеджера або навпаки підпорядковуватися йому» — говорить Артем Садурський, CPO в Solidgate. Розберемо дві найпоширеніші моделі команд та роль Product Owner в них. Модель № 1 Ця схема близька до класичної Scrum-команди. Product Owner комунікує зі стейкхолдерами, Scrum-майстром, а ще — продакт-менеджером (наявність цієї ролі не передбачена в базовій Scrum-команді). Продакт-менеджер взаємодіє з користувачами або клієнтами, бере на себе дослідження їхніх потреб та поведінки, проводить кастдеви (спосіб тестування ідей та прототипів майбутніх проєктів). Його завдання — працювати з аналітикою, знаходити інсайти, формувати гіпотези та презентувати все це Product Owner. Разом вони формують завдання команді, пріоритезують та віддають Scrum-майстру, який з командою втілює ці ідеї. Таких команд у Product Owner може бути декілька. Загалом він відповідає за місію й цінність продукту, те, яким він буде в результаті, та комунікацію між усіма учасниками процесу. Модель № 2 В цій моделі Product Owner підпорядковується продакт-менеджеру й певною мірою «розвантажує» його. Ідея полягає в тому, щоби розділити продукт компанії на частини — компоненти, і створити для них окремі команди, кожну з яких має очолити Product Owner. Вони відповідають за тактику та середньостроковий розвиток своїх частин продукту. А продакт-менеджер — за стратегічний розвиток продукту та взаємодію зі стейкхолдерами, у яких також є певні вимоги та очікування. Залежно від компонента, поруч із продакт-менеджером можуть додавати спеціалістів — технічних райтерів, продуктових дизайнерів тощо. Чим займається Product Owner в межах свого компонента: розуміє потреби бізнесу та збирає вимоги до продукту; забезпечує роботу команди розробки; контролює виконання та оцінює прогрес; працює з цілепокладанням (KPI або OKR); керує Scrum-процесами (планування, пріоритезація завдань, наповнення і грумінг беклогу, церемонії тощо); складає епіки та юзер-сторі; організовує кастдеви, фічер-квести; вивчає аналітику та розуміє, що в продукті працює, а що ні; складає специфікацію; шукає інсайти, формує гіпотези та перевіряє їх; відповідає за технічний і продуктовий дизайн; обирає якісні методи вирішення тієї чи іншої проблеми. За моделлю № 2 працює команда Solidgate, партнерської компанії Genesis, яка створює фінтех продукт — платіжний провайдер, що надає онлайн-підприємцям можливість приймати всі види популярних у світі платежів. «Цей рік ми починали в складі трьох команд, зараз їх шість, а на початку наступного року — буде сім. Тому останнім часом ми будували окремі продуктово-технічні команди на рівні компонентів. Така структура дає сформувати чіткий фокус у командах та ефективніше керувати ними», — Артем Садурський, CPO в Solidgate . Коли команд було декілька, функції продакт-менеджера в команді виконував СРО. Саме він синхронізував роботу всіх команд. Але кількість команд зростала, і зʼявилася потреба вводити в ієрархію продакт-менеджерів. Вони відповідатимуть за роботу зі стейкхолдерами, довгострокову стратегію й побудову дорожньої карти розвитку компонентів. Але може бути й третя модель — коли в компанії немає Product Owner, а всі його функції виконує продакт-менеджер . Ключові навички Product Owner Комунікація Аналітичні здібності Системне мислення Знання методології розробки Scrum та таск-трекерів Відповідальність та вміння приймати рішення Управління проєктами, планування, контроль Лідерство та менеджмент Гнучкість та адаптивність Емоційний інтелект Вміння досліджувати та аналізувати потреби користувачів Product Owner — позиція, яка вимагає великого діапазону особистих якостей. Ця людина вміє домовлятися, аргументувати та доносити свою позицію. Знаходити спільну мову не тільки зі стейкхолдерами, але й із технічною командою — розуміти суть процесів їхньої роботи, скільки часу потрібно для того чи іншого завдання. Залежно від продукту чи його компоненту, можуть бути затребуваними специфічні бекграунди: технічний; маркетинговий; операційний; аналітичний; стратегічний; Growth. «Комусь потрібен спеціаліст, який вийшов із дизайну та може відповідати за UI/UX частину. Комусь — технічний фахівець, який може спілкуватись однією мовою з розробниками, писати API-специфікації, створювати Activity та Sequence діаграми, взаємодії між різними сервісами та системами. А комусь потрібен фахівець із бізнес-бекграундом, який буде доносити команді, скільки грошей вони сьогодні зароблять, і чому це важливо для компанії — каже Артем Садурський. Тому, відгукуючись на вакансії, або наймаючи на цю позицію, важливо чітко формулювати, що входить у перелік обовʼязків саме для цієї компанії. Виклики для Product Owner Головний виклик Product Owner — розвиток продукту або його компоненту, за який він відповідає та досягнення цілей, які стоять перед компанією загалом. На думку Артема, це є найскладнішим і одночасно найцікавішим на цій позиції. Окрім цього є багато інших викликів, які залежать від специфіки продукту. Наприклад, в одному продукті викликом буде робота з аналітикою, зокрема сегментами користувачів, щоби знайти якісь інсайти та розв’язати проблеми у воронці. А в іншому — побудова складних логік системи на бекенді. У такому випадку Product Owner має придумати нову фічу та реалізувати її в системі з великою кількістю розгалужень так, щоби не зламати все інше. Solidgate — саме такий продукт, де цьому фахівцю необхідне системне мислення. «Є технічна архітектура — як виглядає продукт з точки зору коду, інфраструктури. А є продуктова архітектура — коли тобі потрібно думати, як правильно побудувати послідовність функціональностей. Тому що ти не завжди можеш просто придумати та реалізувати якусь фічу: можуть виникнути проблеми, доведеться вигадувати «костилі». І врешті твій продукт схожий на Франкенштейна. А якщо ти не продумав їхню послідовність або пропустив важливий етап, ти вже не матимеш змоги змінити свою систему, щоби не зламати все», — Артем Садурський, CPO в Solidgate . Як стати Product Owner Рішення світчнутися на цю позицію приймають спеціалісти з різних сфер. Зазвичай вони хочуть більше впливати на продукт та бачать на цій позиції потенціал свого розвитку. Ними керує бажання створювати сам продукт та кінцеву цінність для користувачів. Сфери, з яких приходять на позицію Product Owner: продуктовий дизайн; маркетинг; бізнес-аналітика; системна аналітика; дата-аналітика; розробка. Спеціалісти кожної з цих сфер мають свою унікальну комбінацію знань із різних сфер, ніш та аудиторій і мають попит на ринку. Якщо людина хоче світчнутися із суміжної сфери, їй варто розібратися і специфіці створення ІТ-продуктів, а також вивчити методики управління проєктами на спеціальних курсах або самостійно.

SoftBank планує інвестувати до $25 млрд в OpenAI Японський інвестор SoftBank веде перемовини щодо вкладення до $25 млрд у OpenAI, що зробить його найбільшим фінансовим партнером розробника ChatGPT. Разом компанії реалізовують масштабний проєкт зі створення інфраструктури штучного інтелекту, повідомляє   FT.  Минулого тижня OpenAI та SoftBank оголосили про спільне підприємство, яке витратить $100 млрд на будівництво дата-центру Stargate. Протягом чотирьох років інвестиції можуть зрости до $500 млрд. SoftBank вже пообіцяв понад $15 млрд для Stargate та планує вкласти ще $15-25 млрд безпосередньо в OpenAI. Загалом його інвестиції можуть перевищити $40 млрд. Засновник SoftBank Масаесі Сон прагне стати лідером у сфері штучного інтелекту, тісніше співпрацюючи з CEO OpenAI Семом Альтманом. Очікується, що ці вкладення допоможуть OpenAI зменшити залежність від Microsoft та розвивати власні технології. Тім Кук висловився про DeepSeek та подальші плани Apple у сфері ШІ Гендиректор Apple Тім Кук назвав моделі штучного інтелекту DeepSeek «інновацією, що підвищує ефективність», відповідаючи   на запитання аналітиків під час квартального звіту. Він підкреслив, що Apple використовує гібридний підхід до ШІ: прості завдання виконуються локально на фірмових чипах, а складніші — у хмарі через партнерів. Зараз єдина співпраця Apple у сфері ШІ — з OpenAI, що дозволяє ChatGPT відповідати на запитання користувачів iPhone у приватному хмарному середовищі. Цього тижня OpenAI заявила, що DeepSeek незаконно використовував її моделі для навчання власного ШІ, порушуючи політику компанії. Також є сумніви щодо реальної ефективності тренування китайського ШІ, оскільки воно могло потребувати більше обчислювальних ресурсів, ніж стверджує DeepSeek.  Більше про DeepSeek та події навколо неї — читайте в матеріалі Apple натякнула, що в майбутньому може інтегрувати й інші моделі, зокрема Google Gemini або Anthropic Claude, хоча про DeepSeek поки не йдеться. Крім того, Apple Intelligence зіткнувся з труднощами: запуск ШІ-функцій не приніс очікуваного зростання продажів iPhone. Компанія також призупинила роботу ШІ-аналізу новин через помилки, серед яких вигадана інформація у заголовках. Марк Цукерберг попередив співробітників Meta про «інтенсивний рік» – витік із закритої зустрічі Гендиректор Meta Марк Цукерберг під час закритих внутрішніх зборів , запис яких потрапив у мережу, заявив, що 2025 рік буде «інтенсивним» і закликав співробітників «пристебнути ремені», повідомляє Business Insider. Він наголосив на ключовій ролі штучного інтелекту в стратегії компанії та прокоментував нещодавні зміни у політиці Meta. Зокрема, Цукерберг розповів, що Meta прагне запустити «високоінтелектуального та персоналізованого» цифрового асистента для 1 мільярда користувачів, що дасть компанії довгострокову перевагу. Він також визнав, що впровадження ШІ може зробити деякі посади зайвими, але водночас збільшити попит на інженерів, які працюють із новими технологіями. Meta змінює підхід до модерації контенту, відмовляючись від сторонніх фактчекерів на користь системи спільнотних нотаток, як у соцмережі X. Цукерберг висловив оптимізм щодо ефективності цього методу. Також компанія скоригувала свою політику щодо програм різноманіття, рівності та інклюзії (DEI), зважаючи на нові юридичні та регуляторні вимоги у США. Цукерберг підкреслив, що Meta й надалі розглядає різноманіття як перевагу, але змушена адаптуватися до змін у законодавстві. Kuna припиняє роботу: користувачів просять вивести кошти Криптобіржа Kuna повністю згортає діяльність. Засновник Михайло Чобанян заявив, що сервіс не продаватиметься, а користувачі мають вивести кошти протягом двох місяців. 28 січня в Україні почали блокувати Kuna на вимогу Бюро економічної безпеки (БЕБ), яке звинувачує біржу в ухиленні від сплати податків. За даними   Forbes, розслідування підтвердило умисне порушення, а збитки держави оцінюються у 50 млн грн. Чобанян пояснив, що закриває біржу, щоб зосередитися на соціальних ініціативах та GovTech. Також він анонсував новий проєкт зі штучним інтелектом Symbiocracy. У грудні 2024 року Kuna змінила назву на «Момент Ексчендж», а її новим власником став громадянин Таджикистану Нурдінзода Хукмідіні Нурідін. Чобанян заявив, що більше не веде бізнес в Україні та не коментуватиме зміну власника. Український стартап Huless залучив $1 млн інвестицій для розвитку військового зв’язку Розробник системи зв’язку Huless, учасник ініціативи Brave1, залучив $1 000 000 інвестицій. Фінансування надійшло від міжнародних інвесторів, грантової програми Brave1 та державного банку, повідомив  у своєму Telegram-каналі Михайло Федоров.  Отримані кошти компанія спрямує на розвиток екосистеми мобільного військового зв’язку, зокрема на вдосконалення дронів Highline-T. Ці дрони можуть зависати на висоті 100 метрів, працювати навіть в умовах радіоелектронної боротьби (РЕБ) та виконувати функції ретрансляторів, що збільшують дальність зв’язку під час військових операцій. Познайомитися з ангельськими інвесторами команда змогла на саміті Defense Tech Valley, організованому Brave1. Учасники ініціативи наголошують, що українські технології у сфері Defense Tech викликають дедалі більшу зацікавленість у міжнародних партнерів, оскільки не мають аналогів у світі.

HOLYWATER , медіакомпанія з екосистеми Genesis, перерахувала 1 млн грн на користь Veteran Hub задля відновлення функціонування телефонної Лінії підтримки. Раніше проєкт змушені були призупинити через рішення про паузу для фінансування програм міжнародної допомоги USAID. Лінія підтримки — це національна телефонна лінія, яка надає безоплатні послуги ветеранам, ветеранкам та родинам і близьким воїнів телефоном і онлайн. Команда надає фахові юридичні та психологічні консультації, підтримує у пошуку роботи, освітніх програм і грантових можливостей. Щомісяця фахівці опрацьовують понад 1300 звернень, а з початку повномасштабного вторгнення на Лінію підтримки звернулися понад 29 500 разів. Протягом чотирьох днів вимушеної зупинки на Лінії зафіксовано щонайменше 240 запитів, які залишилися без відповіді. Спеціалістка Лінії підтримки Veteran Hub Кошти від HOLYWATER забезпечать функціонування Лінії підтримки протягом місяця. «Ми раді відновити лінію підтримки для воїнів, ветеранів і ветеранок, а також їхніх близьких, — це станеться вже 1 лютого. За дні без зв'язку ми пропустили понад 200 дзвінків і саме це стало нашим найбільшим викликом. HOLYWATER першими підтримали організацію та завдяки їхньому внеску Лінія знову працюватиме», — з азначила співзасновниця та голова правління Veteran Hub Івона Костина. Ветерани і ветеранки, а також їхні близькі можуть отримати такі послуги на Лінії:   юридична підтримка: консультації з оформлення документів, статусів, виплат, проходження ВЛК та інших правових питань;  психологічна підтримка: первинні та кризові консультації. Психологи працюють із гострими стресовими станами, тривожністю і депресією, підтримують під час горювання; пошук покликання: супровід  в пошуку роботи, перекваліфікації, можливостей для навчання або грантів на відкриття власної справи.   Телефон Лінії підтримки 067 348 28 68. Працює щодня з 9:00 до 21:00.

Обʼєктно-орієнтоване програмування — найпоширеніша парадигма в розробці. Про цю концепцію знає кожен девелопер, а про застосування принципів питають на кожній співбесіді, проте в комʼюніті є чимало помилкових упереджень на цю тему. Чи можна розробити якісну підтримувану архітектуру без ООП? Якою була початкова ідея ООП та наскільки вона трансформувалася у сучасній розробці? Що не так з інкапсуляцією та як не ускладнити код надмірними інтерфейсами? Дмитро Гринець, co-CEO та співзасновник компанії PlantIn з екосистеми Genesis, спростував найпоширеніші міфи. PlantIn — застосунок-помічник для догляду за різними видами рослин з використанням ШІ. > ООП гарантує якість коду > Початкова концепція ООП була сильно перекручена > Бізнес-потреби заважають будувати якісну ООП-архітектуру, зокрема на етапі MVP > Задля безпеки системи потрібно інкапсулювати дані та методи з усіх класів > Інтерфейси спрощують тестування, підтримку коду та забезпечують консистентність > ООП застаріло, прийшов час для нової парадигми МІФ №1 ООП гарантує якість коду. Тільки з цією парадигмою можна розробити архітектуру і підтримувати її, не витрачаючи зайвих ресурсів ООП вважається найбільш зрозумілою та простою парадигмою програмування. Функціональний та процедурний методи побудовані на функціях, які обробляють дані без збереження стану. ООП орієнтоване на об'єкти, які мають стан і поведінку, що відповідає природному способу мислення людини. Це дає спеціалістам цілісну картину продукту, який вони створюють, значно спрощує розробку і розуміння коду. Загальна ідея ООП полягає в полегшенні взаємодії різних частин коду, можливості перевикористовувати їх, не змінювати те, що непотрібно, та фокусуватися на головному, наприклад, що виконує певний клас чи функція. Водночас ООП не є магічною формулою, яка автоматично розв'язує всі проблеми програмування. Спагеті-код можна створити будь-якою мовою чи парадигмою — написати погано структуровані класи, що некоректно працюють з даними, чи використати функцію, яка має побічні ефекти або виконує безліч різних дій. Так само хороша архітектура можлива з будь-якою парадигмою. Є чимало прикладів якісних програм, написаних за допомогою С — популярною раніше процедурною мовою, з якою розробники чудово справлялись і будували класні системи. Отже, жодна парадигма програмування не гарантує якості та не звільняє від помилок. Це лише інструмент, використання якого залежить від розробника та його досвіду. МІФ №2 Початкова концепція ООП була сильно перекручена Чимало розробників переконані, що від початкової концепції ООП, коли об'єктам надсилаються повідомлення, які також є об'єктами, залишився лише виклик методу, що принципово мало відрізняється від процедурного програмування. Певне спрощення концепції справді відбулося — і це цілком природно. Метод зʼявився як експериментальна концепція у 1960-х роках — в часи, коли код писали на перфокартах. Принципи ООП дозволили швидше створювати складніші системи та знизити поріг входу до програмування. З того часу зʼявилося безліч мов, фреймворків, напрямів програмування, стрімко розвинулися технології. Сьогодні принципи ООП набули ширшого застосування і водночас використовуються менш прискіпливо. Наприклад, принцип наслідування з часом відійшов на другий план, давши дорогу композиції, і вже досить рідко можна зустріти в коді багаторівневу структуру наслідування. Розробники нерідко застосовують принципи ООП помилково. Наприклад, фокусуються на викликах розрізнених методів, які можна було просто написати функціями. Тобто в коді немає поточного стану обʼєкту, взаємодії чи, скажімо, інкапсуляції. Виходить, це простий виклик функції, який можна було б написати й без ООП. Невірне застосування принципів ООП трапляється часто, але це залежить передусім від розробників. Сама концепція ООП не змінилася — метод залишається важливим у сучасному програмуванні, розвивається та адаптується до нових викликів і потреб. МІФ №3 Бізнес-потреби заважають будувати якісну продуману ООП-архітектуру, зокрема на етапі MVP Бізнес і справді не хвилює, яка парадигма використовується в коді, як побудована архітектура чи структура класів, чи якою є технічна реалізація бізнес-ідеї. Проте це не є проблемою, адже програмування покликане розв'язувати завдання бізнесу, а не навпаки. Отже, інженери мають побудувати архітектуру, враховуючи обмеження та цілі компанії. Етап MVP — створення першого версії продукту з обмеженим функціоналом. Його мета — швидко протестувати гіпотезу, не витрачаючи багато ресурсів. Звідси сформувалося упередження, що на цьому етапі немає часу та можливості заморочуватися питаннями архітектури. Якщо ідея злетить, код можна переписати. Найвідоміший успішний кейс — Slack, який було переписано з нуля. Проте часто підхід переписування буває невдалим: можна витратити чимало часу, а новий код міститиме нові помилки та проблеми. Тому ефективніше рішення — подбати про якісну архітектуру на етапі MVP та надалі допрацьовувати її, і переписуючи лише окремі фрагменти. Насправді досвідченому розробнику не так складно написати якісну продуману архітектуру на етапі MVP з першого разу. МІФ №4 Задля безпеки системи потрібно інкапсулювати дані та методи з усіх класів Інкапсуляція — один з найскладніших принципів, який часто застосовують неправильно. Основна проблема полягає в тому, розробники часом занадто ускладнюють її, ховаючи усе, що бачать. Їхній мотив — подбати про безпеку, зокрема проєктів з чутливими даними. Тоді посилання на дрібні інкапсульовані обʼєкти розростаються вибуховими темпами, та інкапсуляція виглядає як навала незграбних взаємопереплетених методів, що викликають один одного. Якщо складність інкапсуляції двигуна платіжної системи ще можна виправдати, то надмірне використання в інших кейсах лише погіршує код. Визначаючи ступінь інкапсуляції розробник має балансувати між безпекою та гнучкістю. Для малих та простих об'єктів може бути прийнятним більше відкритого доступу до даних і методів, але важливо зберігати інкапсуляцію там, де це необхідно для забезпечення цілісності та безпеки програми. Якщо коректно застосовувати цей принцип, він не ускладнить код та не заважатиме доступу до даних і методів класів. МІФ №5 Інтерфейси завжди спрощують тестування, підтримку коду та забезпечують консистентність Фактично є два підходи до інтерфейсів в ООП: або їх взагалі не використовують, або застосовують всюди, де тільки можна. В чому їхній сенс, та чи потрібні вони в коді — поширена тема для дискусій серед розробників. Інтерфейси є важливою концепцією в об'єктно-орієнтованому програмуванні. Це елемент абстракції, який визначає набір методів без їхньої конкретної реалізації. Інтерфейс вказує, які операції можуть бути викликані для об'єктів, але не накладає обмежень на саму реалізацію методів. Вони мають конкретне завдання, і їх потрібно застосовувати тоді, коли розумієш, що у процесі роботи з цією частиною коду, може зʼявитися необхідність змінити реалізацію. Наприклад, спосіб кешування обʼєктів: зараз ми кешуємо у пам'ять програми, а згодом можемо робити це через Redis. Цю проблему можна передбачити, використавши інтерфейс взаємодії. Тоді зміна реалізації буде безболісною, а кінцеві користувачі цього навіть не помітять. Водночас це зручно розробнику: працюючи з кодом, він не фокусується на конкретній організації кешування, а планує загальну реалізацію, яку потім можна змінити в будь-який час. Якщо ж певна реалізація не буде змінюватися, писати інтерфейс немає сенсу. В Java та її фреймворку Spring все пишеться через інтерфейси — кожен клас та сервіс, який ти використовуєш. Якщо їхня реалізація не змінюється протягом десятиліть розробки цієї програми, в чому тоді полягав сенс? Це просто марне витрачання часу і коду. МІФ №6 ООП застаріло, прийшов час для нової парадигми У 2015-2020 роках періодично зʼявлялася низка критичних статей відомих науковців та розробників — Річарда Столмана, Едсгера Дейкстри, Алана Кея та інших. Вони детально описували, що не так з ООП у сучасному програмуванні та наводили переваги інших парадигм. Ймовірно, це було спробою розширити межі комʼюніті, змінити домінування ООП-first мов та привернути увагу до альтернативних технологій. Це мало сенс, адже сьогодні люди часто приходять в ІТ, випадково обирають ООП-мову, та перше, про що вони дізнаються на лекції — що таке ООП. Потім вони починають програмувати та навіть не знають, що існують інші парадигми, які насправді в певних ситуаціях працюють ефективніше. Наприклад, для завдань Machine Learning чи Data Science ООП взагалі не підходить. Проте зміни домінування ООП так і не відбулося. Насправді нові парадигми зʼявляються не так часто. В останні десятиліття класична наука про інформацію (Computer Science), коли науковці займалися фундаментальною теорією, розробкою мов та систем, перейшла до суто практичного застосування. Розробкою нової парадигми зараз глобально просто не займаються. Можливо розвиток ШІ призведе до появи нового методу. Як варіант — трансформується саме поняття парадигми та конкретної мови, і розробники ставитимуть завдання звичайними словами, або зміниться саме поняття програми. Варто памʼятати, що ООП може інтегруватися з іншими парадигмами програмування для створення більш потужних і гнучких програмних рішень. Ця парадигма може існувати поруч і взаємодіяти з функціональним, реактивним, процедурним та іншими методами програмування. Вибір конкретної парадигми або їх комбінації залежить передусім від потреб проєкту та завдань, які ви намагаєтеся вирішити.