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

У квітневому дайджесті вакансій - позиції для досвідчених фахівців із менеджерським бекграундом та лідерськими навичками. Якщо маєте досвід управління командами продукту, маркетингу або сапорту, знайдете у переліку щось для себе. Head of Product (вакансія закрита) SUITSME — стартап в екосистемі Genesis, що розвиває мобільну фешн-гру для 10 млн користувачів у всьому світі. В команду шукають досвідченого фахівця зі створення цифрових продуктів, який очолить напрям та забезпечить високу залученість користувачів та ефективну монетизацію продукту. Кандидат має представити в резюме досвід на аналогічній посаді від п’яти років, бажано в міжнародній компанії, обов’язково в ігровій індустрії. Окрім цього, команда очікує підтверджені результати роботи кандидата над продуктом (продуктами) у минулому. Кандидат має володіти відмінними аналітичними та менеджерськими навичками, мати практичний досвід управління.  Майбутній керівник команди буде визначати та впроваджувати роадмеп продукту, який розвиває компанія. Також серед його задач буде розробка інноваційних функцій для кращого утримання користувачів та запуск нових продуктів. Окрім цього, Head of Product буде встановлювати й відстежувати OKR для вимірювання результатів команди, а також співпрацювати з іншими командами для досягнення цілей продукту.  Marketing Analytics Team Lead (вакансія закрита) Частина екосистеми Genesis — Universe Group — шукає керівника команди маркетинг-аналітики для свого флагманського бізнесу Guru Apps. Продуктами групи компаній користуються нині більш ніж 60 млн юзерів в усьому світі.  Основною задачею нового члена команди Universe Group буде масштабування бізнесу через аналіз маркетингових даних. Окрім цього, майбутній тимлід матиме змогу зібрати власну команду та працювати з великою кількістю даних, впливаючи на процеси й результати бізнесу. Також на цій позиції треба буде адаптувати аналітику під зміни технологій, управляти фахівцями, планувати беклог завдань та співпрацювати із командами перформанс-маркетингу, продукту та розробки.  Від кандидата очікують мінімум три роки досвіду роботи з аналітикою даних та мінімум один рік в ролі менеджера, а також впевнені знання Python, SQL, математичної статистики, теорії ймовірностей. Проактивність, критичне мислення, бізнес-орієнтованість будуть перевагою.  Team Lead Customer Support (вакансія закрита) Один з проєктів екосистеми Genesis, що надає послуги Customer Success для різних бізнесів, нині в пошуку досвідченого фахівця, який очолить команду підтримки користувачів. За останній рік проєкт виріс з двох до 150+ спеціалістів, та продовжує зростати. В команду шукають керівника, який має попередній досвід роботи на посадах QC/Team Lead та знає як створювати процеси у команді сапорту, вміє працювати з програмними продуктами та сервісами Zendesk, організовувати та планувати роботу відділу підтримки, має організаторські та управлінські здібності, а також відмінні комунікативні навички. Будуть плюсом розвинуті навички стресостійкості та бізнес-орієнтованість.  Тимлід буде менеджерити команду підтримки, контролювати KPI та якість наданих агентами підтримки послуг, матиме змогу брати участь у формуванні команди та процесі найму фахівців. Окрім цього, керівник буде брати участь у глобальних проєктах та ініціативах всередині екосистеми для вдосконалення продукту та досвіду користувачів.  Chief Marketing Officer Освітній стартап Codefinity відкриває вакансію CMO. Платформа, на якій навчаються програмування мільйони користувачів у світі, шукає фахівця із принаймні трьома роками досвіду у цифровому маркетингу з фокусом на рекламі в Facebook. Також кандидат має бути обізнаним в управлінні маркетинговими бюджетами обсягом понад $100 000 на місяць, мати сильні аналітичні навички та розуміти загальні принципи залучення користувачів.  Майбутній директор із маркетингу буде мати наступні обов’язки: визначення та впровадження маркетингової стратегії в усіх каналах, створення користувацького досвіду, який буде сприяти підвищенню залучення і конверсії. Окрім цього, керівник матиме запускати цифрові маркетингові кампанії та оцінювати їх ефективність, і, звичайно, керувати командою маркетологів, встановлювати та відстежувати їх KPI.  Що почитати про компанії, які шукають фахівців на керівні посади:  Genesis Crew: Дмитро Канєвський — від Junior Product Manager до Head of Product Історія Head of Product компанії Universe — Дмитра Канєвського, який потрапив у компанію, успішно закінчивши Genesis IT School, а згодом — став продакт-менеджером на продукті Translator Guru. Дмитро розповів про те, як за два з половиною роки йому вдалося вирости з рядового менеджера до хеда напрямку на одному з нових продуктів компанії. Також він розповів про особливості роботи над продуктами-утилітами в різних нішах, інструменти для зростання на позиції продакт-менеджера та поділився секретами роботи в ситуації надшвидкого зростання.  Пряма мова. СЕО SUITSME — про роботу в телекомі, монетизацію в іграх та інтернаціональну команду Гра   SUITSME  від однойменної компанії з'явилась в App Store і Google Play Market у листопаді 2021 року, й одразу потрапила до списку застосунків, рекомендованих Apple та Google у 44 країнах світу. Засновниця і СЕО стартапу Галина Єфремова розповіла про свій професійний шлях, історію створення SUITSME, а також про те, на що користувачі готові витрачати десятки тисяч доларів.

У травневому дайджесті вакансій головними стали бекенд-розробники. Чи хотіли б ви попрацювати в українському фінтеху? А із застосунком з короткими історіями? Тоді у переліку є пропозиції саме для вас. А, можливо, саме зараз ви наймаєте першу людину до бекенд-команди та шукаєте оптимальні питання на співбесіду? У матеріалі знайдете найповніший перелік питань на співбесіду. Гортайте до кінця! Back-end (Node.js) Developer (вакансія закрита) Ви працюватимете в Holy Water – це паблішер застосунків, заснованих на даних, та рольових мобільних ігор. Аби розвивати застосунок з різноманітними історіями, команда шукає Node.js Back-end Developer. У обов’язки буде входити реалізація A/B-тестування контенту на бекенді, інтеграція рекомендаційної системи та оптимізація швидкості обробки запитів. Щоби приєднатися, потрібен не менш як дворічний досвід, досконале володіння TypeScript , знання реляційних і нереляційних баз даних, а також технологій NestJS, GraphQL (Apollo), Docker та AWS. Back-end Engineer До одного з нових проєктів екосистеми Genesis шукають бекенд-розробника рівня джуніор. Аби обійняти посаду, достатньо навичок написання гнучкого та масштабованого коду та обізнаності в таких технологіях: Golang або Node.js, REST чи GraphQL, SQL, Docker, Kubernetes, Terraform та AWS. Пул завдань невеликий — розробка мікросервісів, інфраструктури та робота з CI/CD. Вакансії партнера Golang Engineer (вакансія закрита) Solidgate — це B2B-продукт у сфері онлайн-платежів. Команда будує фінтех-екосистему, аби її клієнти могли безпечно та вигідно приймати оплати в усьому світі. Її посилить Golang Engineer, який архітектурно пропрацює проблеми з ідемпотентними запитами, візьме участь у проєктуванні вебрішень (Payment Page, Payment Form, SDKs тощо) й покращить підходи до розробки, а також архітектуру коду та сервісів. Йому знадобиться мінімум два роки комерційного досвіду, з яких рік — роботи з Golang, розуміння принципів побудови високонавантажених систем, вміння працювати з Docker, AMQP, а також з PostgreSQL та Elasticsearch. Загальний стек технологій продукту: Golang, Kotlin, PostgreSQL, RabbitMQ, ELK, Docker, AWS. Java/Kotlin Developer (вакансія закрита) Ще один розробник, якого шукають до Solidgate, працюватиме з командою Finance Engineering. Вона відповідає за фінансовий супровід діяльності продуктів Solidgate. Завдання відповідні: налагодити процес формування бухгалтерських балансів, забезпечити правильний порядок реалізації інвойсів, автоматизувати звірку даних з еквайрами та контроль комісій IC+. Ідеальний кандидат має п’ять років досвіду в розробці на Kotlin або Java, знає PostgreSQL або MySQL та працював із Spring Boot та Spring. Перевагою буде досвід роботи у фінтеху, а також знання AWS чи Apache Kafka. Що почитати за темою: 6 міфів про бекенд. Спростовує Back-end Developer в Boosters Бекенд та фронтенд-розробники справді постійно ворогують? Писати код треба щодня? А програмувати доведеться одними лише фреймворками? Якщо ви відповіли «ні» на всі три питання, вітаємо — ви справжній знавець, непідвладний стереотипам. Якщо хоч десь закралося «так» — пропонуємо ознайомитися з матеріалом вище. Спростували в ньому найпоширеніші міфи у спільноті, зазначили, де правда, а де вигадка, та пояснили, чому бекенд — це не так складно, як здається, а конфронтація з фронтенд-розробниками сильно перебільшена. 180+ питань на співбесіду Golang для Junior, Middle та Senior Об’ємна шпаргалка з питаннями для тих, хто буде проходити чи проводити технічне інтерв’ю. Зібрали майже дві сотні питань для різних ґрейдів, втім лякатися не варто — кандидатам ніколи не ставлять весь пул запитань. Якщо ж ви поки не збираєтеся масштабувати команду чи змінювати роботу, список допоможе побачити прогалини у своїх знаннях та вчасно їх заповнити.

Після «великого вибуху», який спричинив ChatGPT, ШІ-інструменти почали з’являтися масово. Великі компанії та стартапи запускають платформи під різні завдання — і для різних фахівців. Які з них підходять для роботи бізнес-аналітика? Про це у колонці для High Bar Journal розповідає Микита Мельник , Business Analysis Manager у EPAM та викладач курсів з бізнес-аналітики та Generative AI. Він також розмірковує, чому промпт-інженер — це професія минулого, та наводить кілька прикладів підводних каменів, на які варто зважати всім, хто працює з ШІ-інструментами.  AI-toolkit для бізнес-аналітика Серед моїх професійних напрямів — бізнес-аналіз, робота над проєктами, продакт-менеджмент, викладання тощо. Для завдань у кожному з них, таких як опис вимог, формулювання ТЗ, написання SQL чи XML-коду для діаграм, я періодично застосовую ШІ. Основних інструментів три:  ChatGPT від Open AI  — допомагає з будь-якими тасками, де потрібна генерація тексту — і звичайного, і коду. Останнім часом я використовую GPTs — вони дають змогу написати інструкцію один раз, і користуватися нею далі для багатьох схожих завдань. Gemini від Google —  схожий на попередній, але, на відміну від ChatGPT, він з самого початку підтримував можливість працювати з таблицями, які потім легко копіювалися в Google Sheets чи Exсel. Крім того, Gemini може інтегруватися в GCP та працювати з SAS-додатками, як-от BigQuery. Claude від Anthropic останнім часом використовую частіше, адже у ньому з’явилися артефакти. Це фічі, які дають змогу, наприклад, згенерувати прототип вебсторінки, поклікати на кнопки та одразу побачити, як все працюватиме. Такий «фокус» можна зробити й з іншими нейронками, але тут це найзручніше.  Окрім них, я користуюся низкою інших інструментів. Правда, ситуативно, під різні завдання на кшталт генерації діаграм чи інших зображень. Це, наприклад, Poe AI — платформа, яка працює як агрегатор, і дає доступ до різних чат-ботів та агентів на кшталт GPTs.  Багато з «великих» продуктів, які використовують аналітики, також мають вбудовані ШІ-асистенти. Наприклад, існує цілий маркетплейс асистентів для Jira і Confluence; функції Miro дають змогу генерувати графіки та діаграми, а розширення для Figma — зображення та прототипи. Утім, особисто я у роботі з графіками та діаграмами надаю перевагу тим, що створені через XML-код. Його  можна згенерувати через Draw.io . Тоді на виході у мене є якісна діаграма, а не просто зображення, яке може бути неточним. Крім того, раніше ми користувалися інструментами для запису дзвінків, але коли подібні функції з’явилися у Google Meet і Microsoft Teams, потреба у них відпала.  Якщо завдання вимагає особливої уваги до кібербезпеки, я використовую наші внутрішні інструменти. Наприклад, EPAM Dial — це open-source інструмент, він підходить для великих або середніх компаній, яким потрібна особлива увага до безпеки даних. Вони можуть розгорнути цей інструмент у своєму середовищі, підключити потрібні моделі й безпечно використовувати ШІ безпечно для своїх цілей. Інший інструмент, Elitea (Alita), дозволяє створювати агентів різної складності з підключенням різних джерел даних. Таким, наприклад, може бути база знань конкретного продукту.  Чи справді необхідний вдалий промпт Фреймворки для промптів, яких нині безліч, не завжди гарантують якісний результат. Є цілі бібліотеки, де користувачам пропонують подібні шаблони, однак я не чув про жодну справді успішну ініціативу. Ба більше — існує ціла професія промпт-інженера , яка свого часу спричинила багато галасу. Однак я вважаю, що напрям переоцінений. Якщо минулого року на сайтах пошуку роботи з’являлося багато вакансій з зарплатами у $200 000-300 000 на рік, то нині я знайшов лише чотири подібні позиції на Djinni. І то — після більш уважного погляду вони виявилися пропозиціями для розробників.  Моя думка: навряд чи ця професія буде розвиватися. Промпт-інженерів потребуватимуть тільки справді великі компанії, які розробляють LLM  або великі продукти на основі LLM. В інших випадках промт-інженерія має стати додатковою навичкою, яка має бути у різних фахівців.  Ефективний промпт іноді може складатися з одного слова. Наприклад, «далі» або «продовжуй». Крім того, ШІ-продукти, які ми використовуємо, мають вбудовані системні промпти. Це означає, що навіть коли ви пишете простий запит з одного або кількох слів, він покращується автоматично, і модель одержує вдосконалену версію. Через це відповідь на виході буде більш-менш точною, навіть якщо запит написаний з помилками.  Головне, про що варто пам’ятати — необхідність «заонбордити» модель у завдання та декомпозиція великих завдань на менші. Наприклад, якщо вам потрібно написати вимоги до функціональності великого проєкту чи фічі, краще розкласти ТЗ на кілька кроків, і попросити інструмент почати з окремої ідеації цієї функціональності. «Порізавши» на шматочки весь функціонал, ви зможете відстежити, що і де пішло не так, а не генерувати  усе завдання спочатку.  Підводні ШІ-камені  Їх може бути кілька:  зникнення певних навичок. Наприклад, вміння бренштормити, сторітелінгу, критичного мислення тощо. Якщо довго не користуватися, то скіл можна втратити.  погіршення розуміння продукту, чого бізнес-аналітик не може собі дозволити.  погіршення комунікаційних навичок. Йдеться про те, що взаємодія з ШІ у наказовому тоні може переноситися і на комунікацію з колегами в проєкті — у нас уже траплялися подібні випадки. Тому краще формулювати запити для інструменту більш ввічливо.  Як викладач, я веду два курси: з генеративного ШІ та бізнес-аналізу. Студентам останнього я забороняю використовувати штучний інтелект впродовж навчання. Виняток — останній блок, де ми знайомимося з різними інструментами для виконання конкретних завдань. Але тоді люди уже мають знання, яких достатньо для того, щоб розрізнити, де ШІ помиляється і пише нісенітниці.   Загалом, думаю, що бізнес-аналітики будуть останніми, кого змінить ШІ, якщо таке взагалі трапиться. Більш ймовірно те, що люди стануть виконувати більше завдань за одиницю часу, та використовувати ШІ як свою конкурентну перевагу.

Вчений та викладач Стенфордcького університету, дослідник машинного навчання, член ради директорів Amazon, співзасновник Coursera та засновник Deeplearning.ai Ендрю Ин опублікував ґайд із порадами щодо побудови карʼєри у сфері ШІ. Ми ділимось основними ідеями та інсайтами з нього.  Програмування ШІ як нова базова грамотність На початку свого міні-підручника Ендрю Ин нагадує, що ще кількасот років тому вміння писати та читати не вважалося навичкою, потрібною усім.  «ШІ — це нова електрика. Він змінить та покращить усі сфери людського життя», — каже Ендрю Ин. Знання у галузі ШІ та data science можна використати усюди. Навіть у піцерії ML-модель на основі лінійної регресії допоможе краще оцінити попит та точніше прогнозувати продажі.  Ин розділяє побудову карʼєри у ШІ на три кроки: Вивчення базових навичок . Отримання технічних знань у машинному навчанні, data science та знання основ ШІ, науці про дані та основах штучного інтелекту. Створення власних проєктів. Застосування навичок на практиці, наповнення портфоліо, що відображатиме ваші скіли. Пошук роботи. Використання навичок і проєктів для отримання бажаної посади у сфері ШІ. Нижче зануримось детальніше у кожен з трьох кроків.  Які технічні навички потрібні для старту кар'єри в ШІ Через швидкий розвиток галузі спеціалістам потрібно постійно навчатися. Щоб опанувати цю звичку, Ин радить звернутися до техніки маленьких кроків. Він цитує книгу Бі Джі Фогга «Крихітні звички» : «Замість того, щоб одразу намагатися займатися спортом по 30 хвилин на день, почніть з одного відтискання і виконуйте його стабільно щодня». Технічні знання, яких потребує карʼєра у ШІ, Ин розподіляє на чотири групи:  Основи машинного навчання ( machine learning ) . Розуміння ключових моделей ML, таких як лінійна та логістична регресія, нейромережі, кластеризація та дерева рішень. Також важливо розуміти основні концепції, як-от упередженість/дисперсія, функції втрат, регуляризація, алгоритми оптимізації та аналіз похибок. Глибинне навчання (deep learning) , а саме базові принципи нейромереж, згорткові мережі, моделі послідовностей та трансформери, і також вміння налаштовувати гіперпараметри.  Розробка програмного забезпечення : вміння програмувати суттєво підвищить вашу конкурентоспроможність. До цього блоку Ин відносить основи програмування, структури даних (особливо ті, що стосуються машинного навчання, як-от фрейми даних), алгоритми, знання Python і бібліотек TensorFlow, PyTorch і scikit-learn. Математика , а саме галузі, потрібні для роботи з машинним навчанням, — лінійна алгебра, теорія ймовірності і статистика. Також Ендрю називає дослідницький аналіз даних (EDA), який вважає недооціненим, — використання візуалізації та інших методів для систематичного вивчення датасету. Також він каже, що для того, щоб гарно розумітися на моделях машинного навчання, вже не потрібно мати такі глибинні математичні знання, як колись.  Проте розуміння математики все ще дуже важливо при роботі з алгоритмами deep learning, зокрема, допоможе краще тренувати нейромережу і розуміти природу її помилок при навчанні. Ин називає онлайн-курси найбільш ефективним способом отримувати нові знання, адже, до прикладу, самостійне читання підручників потребуватиме набагато більше часу. При цьому варто вивчати саме те, що вас цікавить.  Створення проєктів. Які ідеї вартують розвитку «Однією з найважливіших навичок архітектора ШІ є здатність знаходити ідеї, варті того, щоб над ними працювати», — каже вчений.  Пʼять кроків оцінки проєктів, які пропонує Ендрю Ин: Визначте бізнес-проблему. Запитайте експерта у галузі, яка вам цікава: «Які три речі мають працювати краще? Чому це досі не так?» Наприклад, в галузі зміни клімату оператори енергомереж можуть мати проблеми з точним прогнозуванням того, скільки енергії здатні виробляти вітер і сонячна енергія в майбутньому. Згенеруйте декілька ідей для рішень на основі ШІ . Наприклад, для прогнозування виробництва енергії можна використовувати супутникові знімки (для точнішого картографування місцезнаходження вітрових турбін, оцінки висоти та потужності турбін), а також метадату, щоб прогнозувати хмарність. Рішення на основі ШІ може й не існувати,  — і це теж нормально. Визначте майлстоуни, яких варто досягти . Якщо ви обрали ідею, знайдіть критерії, за якими рішення мають визнати ефективним. Це мають бути як метрики, повʼязані з ШІ (до прикладу, точність моделі), так і бізнес-показники.  Оцініть здійсненність і потенційну користь від рішення. Ви можете переглянути опубліковані наукові дослідження, подивитись, що зробили конкуренти, або швидко перевірити концепт. Також вам допоможуть консультації з експертами в галузі. Складіть бюджет. Подумайте про все, що необхідно для проєкту: дані, персонал, час та будь-яку підтримка від інших команд. Наприклад, якщо необхідно придбати супутникові знімки, це слід врахувати в бюджеті. «Робота над проєктами — це ітеративний процес. Якщо на будь-якому етапі ви зрозумієте, що поточний напрямок є нездійсненним, повернутися до старту і переосмислити рішення — нормально», — каже Ин . Також дослідник радить обирати проєкти згідно ваших карʼєрних цілей. Щоби знайти проєкт, спілкуйтеся з іншими представниками ринку, продовжуйте вдосконалювати знання та оберіть галузь, на якій хотіли би зосередитись.  У роботі над проєктами є два підходи: 1. Ready, Aim, Fire (готуйся, цілься, стріляй) : ретельне планування та детальна валідація. ​​Перехід до виконання — лише тоді, коли є впевненість у обраному напрямку.  2. Ready, Fire, Aim (готуйся, стріляй, цілься) : розробка та реалізація — одразу. Цей підхід дозволяє швидко виявляти проблеми і змінювати напрямок за потреби. Ин каже, що цей підхід працює краще при створенні ML-розробки як частини продукту. Але коли ухвалення рішення вимагає вагомих витрат або веде до рішення, яке складно скасувати, часто варто витратити більше часу на те, щоб переконатися, що це хороша ідея. Як шукати роботу у сфері ШІ Розглядаючи наступне місце роботи, визначтесь, змінюєте ви роль чи галузь. Якщо ви шукаєте свою першу роботу, повʼязану з ШІ, вам не варто одночасно змінювати і роль, і галузь, адже це може викликати забагато стресу. У випадку, коли ви розглядаєте зміну ролі, стартап може бути кращим вибором, адже розподілення ролей там є більш гнучким.  Шукаючи роботу, варто провести декілька інформаційних інтервʼю. Це неформальна розмова з людиною, яка працює на цікавій для вас посаді та/або у цікавій вам компанії. Така практика особливо важлива для тих, хто планує працювати у галузі ШІ, оскільки вона дуже швидко розвивається, і різні компанії використовують різні терміни для позначення посад. Десь data scientist може займатись переважно аналітикою бізнес-даних, а десь — писати і підтримувати код. Інформаційне інтервʼю допоможе визначити, з чим працює ШІ-спеціаліст у конкретній компанії та які навички там потрібні. Ин наголошує на важливості дослідження можливих ролей і компаній, створення сильного резюме та підготовки до співбесід. Він також підкреслює, що варто звертати увагу на команду, адже класні колеги можуть суттєво вплинути на ваш розвиток і задоволення від роботи. У підсумку, на ваш успіх у галузі ШІ впливають пʼять чинників: здатність працювати у команді (не тільки давати поради, а й приймати критику), нетворкінг (навіть якщо ви інтроверт, як і сам Ин), увага до пошуку роботи, самодисципліна та альтруїзм.

PMM — роль, яка викликає чимало непорозумінь. Хтось вважає, що це лише про маркетинг, інші впевнені, що PMM — це те саме, що Growth чи Product Manager. Дмитро Цапій, Product Marketing Manager в Universe Group , спростовує поширені міфи про цю роль, а також про трактування метрик, підходи до побудови воронок, продуктову аналітику та конверсії.  >  PMM займається лише воронками та новими нішами >  PMM — гібридна роль між маркетингом і продуктом >  Кожну метрику можна розглядати окремо >  Product First чи Marketing First >  Велика кількість аналітики уповільнює процеси Вважається, що головне (і чи не єдине) завдання продакт-маркетинг менеджера — побудувати воронку, зробити її привабливою та ефективною. Насправді роль PMM (Product Marketing Manager) — комплексна і набагато ширша. Окрім роботи з воронками, продакт-маркетинг охоплює безліч різноманітних функцій. Йдеться про стратегічну роботу над продуктом, дослідження ринку, аналіз потреб клієнтів, комунікацію з аудиторією, роботу з платежами та розвиток нових напрямів.  Інше упередження про задачі PMM полягає у тому, що цей спеціаліст лише запускає нові кампанії та шукає нові ніші. Запуск — це важлива частина роботи PMM, але це не все. Значна частина часу приділяється аналітиці, покращенню та оптимізації вже наявних продуктів, процесів і кампаній.  Часто роль PMM сприймають як суміш маркетингу і продукту, яка виконує функції обох. Насправді це самостійний фахівець, який не лише координує дії команд маркетингу та продукту, але й має інші зони відповідальності: пошук нових ніш та перспективних напрямів, генерація і тестування гіпотез, а також ініціювання змін у продукті. PMM також може виступати драйвером створення нових продуктів чи напрямів. Загалом він шукає нові можливості для зростання і масштабування продукту.  Product Marketing Manager має бути супермобільною людиною, яка знає, як знаходити, генерувати і перевіряти нові гіпотези. Наприклад, корисним скілом може бути вміння провалідувати велику фічу/гіпотезу нового продукту за тиждень, а не витрачати місяці на розробку, щоби дізнатися результат. Це можна зробити через додавання маленького питання в онбордінг квіз. Наприклад, «чи хотіли б ви мати таку фічу в продукті?» або «чи стикалися ви з певною проблемою?». Відповіді назбираються точно швидше ніж розробка і тестування, і це збереже час і гроші для бізнесу. Іншим інструментом впливу PMM є проведення Fake Door Tests — імітація функціональності для замірювання конверсії. Наприклад, ми зробили дослідження і знайшли проблему користувачів, яку хочемо допомогти вирішити. Перш ніж створювати великий продукт, спочатку потрібно зрозуміти попит на нього (наскільки це доцільно для користувачів). За допомогою Fake Doors процес скорочується в рази: ми створюємо нову воронку, налаштовуємо кампанії з невеликими бюджетами та дивимось на поведінку. В кінці користувач побачить банер: «Вибач, * назва продукту * зараз недоступний, чи цікаво тобі отримати його зі знижкою?». Так буквально за тиждень ми можемо зрозуміти чи варто розробляти такий продукт. Продакт-маркетинг — настільки комплексний напрям, що коли ви описуєте свою роботу в межах якоїсь функції, люди поза контекстом ймовірно скажуть «це ж те саме, що…». Наприклад, шукати нові ніші та воронки — нагадує їм Growth Marketing. Покращувати меседжі, які команда показує у воронці, щоби збільшити конверсію, — виглядає як Content Marketing. Відповідати за взаємодією користувача з продуктом та воронкою — схоже не продакт-менеджмент. Певною мірою робота PMM перетинається з іншими ролями, але на них лежать різні функції. PMM — це людина, яка стратегічно відповідає за маркетинг продукту, створення go-to-market плану, позиціонування продукту, донесення цієї цінності до користувача і, відповідно, за імплементацію та виконання метрик. Усі бізнеси дивляться на Customer Acquisition Cost (CAC) і LTV (Lifetime Value). Окремо від інших жодна з цих метрик не дасть чіткого розуміння про успішність бізнесу або кампанії. Якщо ви запустили новий бізнес, CAC 300$ —  це багато чи мало? Або 30$? Так само із LTV. Важлива їхня взаємодія, результатом якої є позитивна юніт-економіка. Метрики, ізольовані від контексту бізнесу, не мають значення. Єдиним виключенням може бути ROMI, оскільки ця метрика чітко показує успішність ваших кампаній. Однак, у цьому випадку потрібен теж додатковий контекст, який дасть зрозуміти, який ROMI є прийнятним для вашої компанії. Для одних це може бути 1.05, тоді як для інших і 1.5 може бути недостатнім. Так само важливо розуміти, які саме дії покращують Retention Rate та LTV, а які — навпаки. Наприклад, вважається, чим більше дій робить у продукті користувач, тим вищими будуть його лояльність та тривалість взаємодії з продуктом. Насправді це не завжди так. Коли користувач вимушений робити низку дій, це може погіршити досвід і знизити бажання повертатися.  Інший приклад з минулого досвіду — в одному з проєктів ми відправляли користувачам багато пуш-сповіщень про акції або спеціальні пропозиції. Ми дивилися на високий open rate і були переконані, що він має пряму кореляцію з кількістю замовлень та ретеншеном. Певною мірою це так, але велика кількість сповіщень рано чи пізно набридає. Тоді користувач їх відключає, і ви вже не зможете до нього достукатися. І це негативно впливає на ретеншн і взаємодію з застосунком довгостроково. Темами для дискусій в комʼюніті найчастіше стають успішні чи неуспішні A/B-тести, фреймворки роботи з новими воронками та платежі. Коли доходить до пошуку нових воронок, зазвичай PMM діляться на два табори: тих, хто спирається на маркетинг і тих, хто на продукт.  У першому підході основою є загальна воронка продукту, на яку залучають користувачів, тестуючи нові ідеї та напрями. Наприклад, якщо ваш продукт пов’язаний із продуктивністю, можна почати говорити про суміжні теми, як-от боротьба з прокрастинацією. Спочатку це буде частиною основної воронки. Якщо результати тестування креативів покажуть, що ця тема має хороший відгук, її виділяють в окрему воронку, яка вже стосується конкретно антипрокрастинації. У такий спосіб навколо продукту створюються нові маркетингові напрями чи воронки для залучення аудиторії.  У другому підході створення нових воронок базується на аналізі самого продукту. Наприклад, продуктивність як широка ніша може охоплювати різні аспекти: психологічний стан, побудова режиму дня чи формування корисних звичок. Тут ідея нової воронки не виникає через тестування креативів, а формується як окрема бізнес-модель із прорахунком власної юніт-економіки. Обидва підходи є правильними, і вибір залежить від бізнесу та стратегії. Скільки ресурсів слід вкладати в продуктову аналітику? З одного боку, вважають, що аналізу багато не буває, і варто вимірювати все, що можна. А з іншого боку — надмірна кількість даних може сповільнювати процеси та команду. Важливо тримати баланс і розуміти, як метрики взаємодіють між собою і впливають одна на іншу. Щоби команда не втрачала швидкість, варто пріоритезувати головні показники і фокусуватися на них. Швидкість заради швидкості, так і аналітика заради аналітики не мають сенсу. Має бути правильний баланс між швидкістю та аналітикою. Обсяг даних, необхідних для корисного аналізу, суттєво відрізняється залежно від кількох факторів:  тип аналізу;  складність проблеми; наявна якість даних.  Добре структуровані, якісні дані з відповідними функціями можуть бути ціннішими, ніж великі набори даних із шумом і нерелевантною інформацією. Для вірної оцінки результатів A/B тестувань важливу роль відіграє статистична потужність: під час перевірки гіпотез розмір вибірки, необхідний для адекватної статистичної потужності, залежить від очікуваного розміру ефекту, перемінності даних і бажаного рівня достовірності. Більші вибірки зазвичай дають більш надійні результати. Тому ще до запуску А/В-теста треба визначити метрики (основну і другорядні), зміни яких покажуть, чи є нова функціональність більш успішною. Тест нового функціоналу зазвичай впливає не на одну цільову, а на ряд метрик. Тому ми дивимося на зміни в цілому і маємо чітко розуміти, що зміни однієї конверсії, яка не набрала мінімальну вибірку і не є стат. потужною, недостатньо для прийняття рішень. Спершу ми визначаємо метрики, на які також може впливати тест, розраховуємо мінімальну вибірку, збираємо стат. значущість і стат. потужність, аналізуємо основні і додаткові метрики, та лише потім приймаємо рішення. Загальні рекомендації: Маленькі аналізи: від кількох сотень до кількох тисяч точок даних може бути дос татньо для дослідницького аналізу або простих візуалізацій. Аналіз помірного масштабу: для надійнішого статистичного аналізу часто потрібні десятки тисяч точок даних. Широкомасштабний аналіз: для складних моделей машинного навчання, особливо в таких сферах, як розпізнавання зображень і мови, зазвичай потрібні сотні тисяч або мільйони точок даних. Таким чином, «правильна» кількість даних залежить від конкретного контексту аналізу, цілей і використовуваних методів.

Конкуренція вебпереглядачів була однією з найгостріших в історії ІТ. Інноваційні браузери швидко здобували першість і так само втрачали її. Монополіст з долею в 96% ринку за кілька років перетворився на продукт, яким користуються один раз, щоби завантажити «нормальний» вебпереглядач.  У процесі перегонів компанії створювали технології, які невдовзі стали базою сучасного фронтенду та повністю змінили ландшафт інтернету. У цьому матеріалі ділимося історією розвитку вебпереглядачів та рефлексуємо, як працювалося розробникам під час баталій браузерів та як розвиватиметься ця конкуренція надалі.  📄 Спочатку був WWW 📄 Круїз-контроль для інформаційної магістралі 📄 Поява Internet Explorer та перші перегони 📄 Opera. Розвиток в тіні 📄 Монополія Internet Explorer 📄 Фенікс, що піднявся з попелу 📄 Другий раунд. Протистояння монополістів 📄 Нечесна гра. Чому монополісти не змінюються 📄 Що далі. Все буде ШІ Спочатку був WWW Перший у світі веббраузер фактично був безіменним. Тім Бернерс-Лі, співробітник Європейської лабораторії з ядерних досліджень (CERN), який створив  поняття «всесвітнього павутиння», не заморочувався з неймінгом і випустив перший вебпереглядач з назвою World Wide Web. Його опублікували 1990 року разом із протоколом HTTP, мовою HTML і форматом посилання URL, а також презентували перший у світі сайт www.info.cern.ch .  Пізніше CERN перейменували браузер у Nexus. Він мав графічний інтерфейс, редактор стилів, підтримував протокол FTP. Це був не просто перший браузер, але й редактор сайтів — як для першої спроби виглядало дивовижно. Проте було вагоме «але». Nexus розроблявся на операційній системі NeXTSTEP на ультрапотужних та дорогих компʼютерах Next — одному з творінь Стіва Джобса. Їх міг дозволити собі навіть не кожен дослідницький центр, а про масове використання навіть не йшлося. У пошуках простішого рішення CERN створили текстову версію браузера Line Mode Browser. Він був кросплатформним, запускався на будь-якому компʼютері, проте був незручним. Фактично це був текстовий редактор з підтримкою HTTP. Користувачам потрібне було рішення із графічним інтерфейсом. Тоді Жан-Франсуа Грофф, один з колег Бернерса, переклав основні компоненти першого браузера мовою С, а також зібрав і опублікував в мережі бібліотеку LibWWW для інтерпретації онлайн-сторінок. Так інструменти для створення браузерів стали доступними для всіх, і це стало поштовхом до їхнього розвитку. Допитливі програмісти з наукових центрів та університетів почали експериментувати та створювати нові браузери для власних завдань. Кожен з них мав свої особливості: один мав перші вкладки, другий міг відображати таблиці, третій — формули.  1993 року в мережі було всього 130 сайтів і зоопарк з 12 різних браузерів. Епоха універсальних вебпереглядачів починається з виходу Viola, який створив студент каліфорнійського університету Пей Юань Вей. У ньому було чимало фічей: закладки та історія переглядів, кнопки вперед-назад, пошук та навіть можливість вставляти в HTML-сторінки обʼєкти з кодом, які будуть виконуватися одразу у браузері. Цей продукт усім сподобався, зокрема Марку Андріссену, спеціалісту NCSA (National Center for Supercomputing Applications) та майбутньому співзасновнику венчурного фонду A16Z. Незабаром він випустив Mosaic — перший переглядач, який міг показувати картинки разом з текстом, а не в окремому вікні. Він був простим, безкоштовним, кросплатформним, а згодом — всесвітньо відомим.  Netscape Navigator — «круїз-контроль для інформаційної магістралі» Надихнувшись успіхом Mosaic, Андріссен йде з NCSA та разом із Джеймсом Кларком засновує Netscape Communications Corporation. 1994 року вони починають роботу над новим браузером. Це був вже не експеримент дослідницького центру, а справжній бізнес.  Перший реліз Netscape Navigator 1.0 містив усі переваги Mosaic та на додаток безліч нових опцій. Одна з них — швидкість. У перших браузерах сторінки відображалися лише після повного завантаження контенту, а при тодішньому інтернеті це тривало довго. Дуже довго. Netscape навігатор були першими, хто виправив це.  «Netscape є потужним комерційним навігатором для інтернету, що пропонує мережеву навігацію з допомогою миші. Він оптимізований для безперебійної роботи на модемах 14,4 кб/с, забезпечуючи продуктивність щонайменше в десять разів вищу, ніж в інших браузерах» — так описується у першому пресрелізі  інноваційний браузер, який 1995 року вразив світ. «Новий Netscape Navigator забезпечує круїз-контроль для інформаційної супермагістралі», — зазначив Тім Вейл, Senior Systems Engineer у British Telecom і перший користувач цього вебпереглядача. 1995 року розробнику Netscape Брендану Айку дають завдання написати скін для реалізації скриптів. Вони мали доповнювати можливості HTML і CSS, дозволяючи створювати більш динамічні та інтерактивні вебсторінки. Ідея Netscape полягала в тому, щоби створити легке інтерпретоване рішення для непрофесійних програмістів. Дедлайн був стислий — 1,5 тижня. «Тоді у травні я завзято працював протягом 10 днів. І мало спав», — так Айк описував ті часи на конференції dotJS 2007 року. Новій технології дали назву Mocha. Через низку перейменувань та доопрацювань пізніше вона стала усім відомою JavaScript .   Перша версія мови була випущена разом з новою версією Netscape Navigator 2.0. Тривалий час у комʼюніті розробників критикували цю мову та не сприймали серйозно. Через угоду з SUNmicrosystems до її назви додали «Java», і доводилося усім пояснювати, чому JavaScript — це не Java, і не Script. Попри це, навколо цієї мови незабаром виросте екосистема інструментів, без яких сучасного вебу не існувало б.  1996 року Netscape Navigator стає найпопулярнішим веббраузером. Він має близько 80% ринку, великі плани розвитку і тотальну любов користувачів. Здавалося б, що може трапитися? Проте на арені зʼявився Microsoft з серйозними намірами захопити цю нішу.  Поява Internet Explorer та перші перегони Microsoft помічає, що веб стрімко розвивається, а у ніші браузерів уже є стійкий лідер, та ухвалює рішення вступити в цю гонитву.  Часу починати розробку власного браузера з нуля вже не було, тому компанія купує ліцензію Mosaic, погоджуючись виплачувати відсотки з продажів. 1996 року компанія створює на її базі Internet Explorer та випускає, як власний продукт. Цього ж року з претензій Mosaic починається перший судовий процес у майбутній війні браузерів.  Перші версії Internet Explorer містили лише основні функції для перегляду вебсторінок і взаємодії з ними. Проте з кожною новою версією він поступово наздоганяв Navigator. Netscape не відставав. Так розпочалися перегони інновацій. Компанії релізили нові HTML-теги й фічі, що були несумісними одне з одним. Під час перегонів усім було не до стандартів — доходило до того, що на сайтах ставили відмітки, у якому браузері краще його переглядати. Opera. Розвиток в тіні Паралельно з Netscape Navigator та Internet Explorer у світ вийшов браузер Opera. Йон Стефенсон фон Течнер та Гейр Іварсьой, співробітники норвезької телекомунікаційної компанії Telenor працювали над розробкою сайту компанії — на той час неймовірна та інноваційна задача. Самі вони користувалися браузером Mosaic, і в процесі виникла ідея створити свій — MultiTorg Opera 1.0.  Вихідний код браузера був написаний на С++ без використання сторонніх API, системні вимоги були мінімальними навіть для машини того часу. Це зробило браузер досить швидким.  Тоді автори браузера створили компанію Opera Software ASA та сфокусувалися на розвитку цього продукту. Тривалий час Opera впроваджувала інновації, такі як швидкий доступ до вебсторінок, вбудований блокувальник реклами та можливості налаштування інтерфейсу. Крім того, Opera була першою, хто впровадив вкладки в браузері та швидке завантаження сторінок за допомогою технології Turbo. Проте цей вебпереглядач був значно меншим порівняно з Internet Explorer та Netscape Navigator, тому довгий час залишався в тіні та був популярним лише серед ентузіастів. І хоча частка ринку поступово збільшувалася, Opera ніколи не мала високої популярності.  Монополія Internet Explorer Навігатор залишався потужним інноваційним браузером, проте мав суттєвий недолік. Він був єдиним джерелом доходу невеликої Netscape, тоді як Microsoft могла працювати у величезний мінус, заробляючи на інших продуктах. Крім того, остання мала монополію на ринку операційних систем. Так, Internet Explorer 4.0 було включено до операційної системи Windows 95, що зробило його дефолтним безкоштовним браузером без необхідності завантажувати його окремо. Паралельно компанія укладала угоди з виробниками комп'ютерів та іншими партнерами, які передбачали передвстановлення Internet Explorer на комп'ютери. Це обмежувало конкуренцію, адже чимало користувачів навіть не знали про існування інших браузерів.  У відповідь на це Netscape, а за ним й уряд США, подали в суд на Microsoft, звинувачуючи її в зловживанні монопольним становищем на ринку браузерів. Судовий розгляд завершився угодою Microsoft та уряду США, яка передбачала зупинку практики звʼязувати Internet Explorer з операційною системою та надання можливості користувачам обирати альтернативні браузери. Водночас Microsoft знайшла рішення, як обійти угоду. Замість того, щоб видаляти Internet Explorer з операційної системи, компанія додала можливість обирати браузер при налаштуванні операційної системи. Це була досить складна маніпуляція для пересічних користувачів, тому першість залишилася за Internet Explorer. Так він здобув 96% ринку і виграв першу битву браузерів.  Фенікс, що піднявся з попелу Завершення першої фази війни поклало кінець швидким інноваціям. На початку нульових років веб поглинув технологічний застій. Не маючи мотивації розвиватися, Microsoft сфокусувався на корпоративних і серверних рішеннях, а між 2001 і 2006 роками вийшла лише одна нова версія Internet Explorer. Крім того, перемога завела Microsoft у глухий кут: тепер компанія мусила підтримувати усі старі версії браузерів з помилками та «кривими» реалізаціями стандартів, які компанія ігнорувала весь цей час. Повністю виправити усі помилки їм так і не вдалося. «Я стикнувся з проблемами пізніх версій Internet Explorer, коли він фактично вже був Legacy-продуктом. Тоді працював із CRM-продуктом Microsoft для вебу, тому орієнтація на Internet Explorer була пріоритетом. Під них ми писали кластерний код, працювали на чистій JavaScript, без фреймворків та бібліотек — усе доводилося писати вручну, навіть компілятори, — згадує Віктор Галочка, Front-end Team Lead в Lift. — Це було боляче — чи не кожну сторінку ми перевіряли через емулятори, як вони виглядатимуть у різних версіях браузера. Часом виникали проблеми з анімацією — вона не програвалася або взагалі блокувала подальший код. Підтримка цим браузером нових методів, фічей, які зʼявлялися в CSS, і в JavaScript, була дуже низькою. Регулярно зʼявлялися проблеми з DOM: щоби виділити певний елемент, доводилося вигадувати «костильні» рішення. Незграбність цього браузера уособлює бібліотека jQuery, яку Microsoft популяризувала». Netscape своєю чергою отримав змогу почати з чистого листа. Команда заснувала Mozilla, спільноту вільного програмного забезпечення, та розпочала роботу над новим проєктом під назвою Fenix. Бета-версія нового браузера побачила світ 2002 року та отримала схвальні відгуки за швидкість, безпеку та додаткові компоненти — його головну відмінність від Internet Explorer 6. У листопаді 2004 року команда офіційно презентувала Mozilla Firefox. За дев’ять місяців його завантажили 60 мільйонів користувачів. Розвиток вебу відновився.  «Mozilla Firefox оголосили вбивцею Internet Explorer, і це була перша серйозна альтернатива після Netscape. Шанувальники навіть зібрали гроші, щоб заплатити за його рекламу на всю сторінку в New York Times», — згадує   Том Воррен, технічний оглядач The Verge.  Firefox запропонував такі функції, як вкладки, блокувальник вікон, що спливають, розширення та теми. Більшість з цих фічей не були новими — їх вже містив браузер Opera. Але поєднання швидкості, зручності та орієнтація на конфіденційність зробили Firefox фаворитом. Протягом п’яти років браузер здобув 32% ринку, а 2009 випередив Internet Explorer. Проте у нього зʼявилися два інші конкуренти — Safari та Chrome.  Другий раунд. Протистояння монополістів На початку 2003 року Apple презентував Safari як найшвидший веббраузер. «Ми повертаємо інновації до цієї категорії, створивши перший вебпереглядач за останні роки», — зазначив  Стів Джобс під час презентації на Macworld Expo. Команда заявила, що оригінальна версія Safari завантажує сторінки втричі швидше за Internet Explorer, має блокувальник реклами, механізм рендерингу сторінок WebKit, а також доступ до пошуковика Google та інструментарію для завантаження файлів. Мобільна версія Safari для iPhone була випущена у 2007 році.  Водночас розробники відзначали низку недоліків Safari. Зокрема, невідповідність стандартам, неправильну інтерпретацію деяких сторінок та елементів, проблеми із продуктивністю, оптимізацією та синхронізацією закладок та іншої інформації. «Старі версії Safari були дуже схожими на Internet Explorer — такі ж болі та проблеми для розробників. Зараз він регулярно оновлюється, проте деякі рішення досі працюють специфічно, наприклад, реалізація івентів. З цим доводиться жити, адже це дефолтний браузер на iOS-девайсах», — ділиться Віктор Галочка.  1 вересня 2008 Сундар Пічаї анонсував Google Chrome в офіційному блозі компанії. Вже наступного дня стала публічною перша бета-версія браузера. Також розробники Google оголосили про створення відкритого і вільного проєкту Chromium, щоби допомогти конкурентам (Opera, Mozilla, Microsoft) розвивати інтернет.  Google зосередився на вебстандартах і дотримувався HTML5, пройшовши тести Acid1 і Acid2 з першим випуском Chrome — те, у чому Microsoft сильно провалилася. «Першим моїм браузером як користувача був Internet Explorer. Як і в багатьох інших, тоді не було розуміння, що існує щось краще. Проте щойно я побачив і спробував Chrome, було відчутно, що це суттєвий крок вперед в історії браузерів. Його кілер-фічею стала швидкість, продуктивність і зручний UX/UI. Крім того, у Chrome зʼявилися екстеншени, — пояснює Віктор. — Також цей браузер завжди був більш зручним для розробників. Робота з консоллю, запитами, cookies, Local Storage — усе тут працювало швидше і зручніше».  Нечесна гра. Чому монополісти не змінюються Спочатку керівники Mozilla не бачили в Chrome загрози. «Chrome не має на меті конкурувати з Firefox, адже ми не пропонуємо службу пошуку та не продаємо рекламу. Скоріше, він створений для конкуренції з Internet Explorer», — стверджував  президент Mozilla Europe Трістан Нітот. Компанії мали схожі цінності, крім того, Mozilla щойно підписала трирічний контракт із Google про рекламу.  Проте невдовзі Google почав застосовувати нечесні методи. Нові вебстандарти в першу чергу впроваджувалися у Chrome, створюючи недоліки в продуктивності та проблеми сумісності у браузерах-конкурентах. У липні 2018 року менеджер програми Mozilla Кріс Петерсон звинуватив Google у навмисному сповільненні роботи YouTube у Firefox. Регулярно виникали проблеми з продуктивністю у Gmail і Google Docs, деякі сайти помилково блокували Firefox як «несумісні». Крім того, браузери-конкуренти заполонили навʼязливі пропозиції завантажити переглядач Chrome.  Один з розробників Microsoft скаржився на поведінку Google і ділився скриншотами, де чимало сервісів були заблоковані в інших вебпереглядачах. «Google Meet, YouTube, Google Earth блокують доступ у браузері Microsoft Edge, а також не підтримуються у Firefox. Коли найбільша вебкомпанія у світі блокує конкурентів, це пахне не стільки випадковістю, а скоріше стратегією», —   так описував  цей випадок   Том Воррен на сторінках The Verge. На його думку, антиконкурентна практика Chrome робила його все більш схожим на Internet Explorer 6. Завдяки агресивній експансії Google Chrome став найпопулярнішим браузером у світі, забравши користувачів як Internet Explorer, так і Firefox та Opera. До 2017 року їхня доля впала нижче 5%. Chrome став головним способом доступу людей до інтернету на різних пристроях і утримує ці позиції й сьогодні. На початок 2024 року його частка ринку складає понад 65%.  На рушій Chromium невдовзі перейшли Edge (новий браузер від Microsoft), Opera та інші дрібні браузери. Що далі. Все буде ШІ Після переходу на Chromium браузери частково втратили свою індивідуальність. «Тут можна провести паралель із мобільними телефонами: до появи iPhone були й «розкладушки», і слайдери, і моноблоки. Зараз всі телефони виглядають плюс-мінус однаково. Так само серед браузерів відбувається певна уніфікація та синхронізація — її забезпечив Chromium, і тим самим допоміг перетворити Google в остаточного монополіста», — вважає Віктор Галочка.  Сьогодні підтримка «зоопарку» браузерів вже не складає суттєвих проблем, як раніше. Коли виходить нове оновлення CSS, JavaScript чи інших інструментів, розробники користуються сервісом CanIUse , щоби визначити, чи підтримують його останні версії браузерів. Для адаптації вебпродуктів на старі версії браузерів використовують компілятори при збірці фінального бандлу коду.  «Раніше потрібно було вручну додавати автопрефікси під різні браузери, щоби нові властивості працювали однаково. Сьогодні цю роботу виконують популярні фреймворки (React, Nest, Angular, Vue), які стали значно розумнішими під капотом», — згадує Віктор.  Як розвиватиметься історія браузерів надалі? Один з імовірних сценаріїв — масова інтеграція AI-інструментів та початок нових перегонів. Культура серфінгу інтернетом та пошуку інформації може кардинально змінитися найближчим часом. Це відбувається вже зараз, хоча пройшло ще дуже мало часу від початку масового використання LLM-моделей .  «Microsoft намагалися діяти на випередження та направили ресурси на розвиток Bing з ChatGPT. Хоча його доля досі залишається мінімальною, виглядає, що Google прогавив момент, коли варто було включатися в ці перегони. Компанія помітно відстає від Microsoft, Amazon та Meta, — зазначає Віктор. — Цілком можливо, що першість у цій ніші незабаром перейде до когось іншого».

OpenAI кидає виклик Google: планує запускати браузер OpenAI розглядає можливість запуску власного веббраузера, який буде інтегрований із чатботом, а також веде переговори про впровадження пошукових функцій на сайтах для подорожей, нерухомості та роздрібної торгівлі, пише The Information . Компанія також обговорює співпрацю із Samsung, ключовим партнером Google, з метою впровадження функцій штучного інтелекту в її пристрої. Це може стати схожим на угоду OpenAI з Apple, де її технології вже інтегруються в екосистему. Компанія нещодавно найняла двох розробників Google Chrome — Бена Гуджера та Даріна Фішера, які стояли біля витоків створення браузера. Якщо OpenAI все ж вирішить запустити власний браузер, це зробить її потужним конкурентом Google, яка домінує на ринку браузерів через Chrome і в пошуку через Google Search.  Bluesky досягла 20 млн користувачів  Соціальна мережа, яка позиціонує себе як конкурент X (колишнього Twitter), продовжує швидко зростати  на тлі відтоку користувачів із платформи, що належить Ілону Маску.  Хоча база користувачів Bluesky залишається меншою за Threads, яка налічує понад 275 мільйонів щомісячних активних користувачів, аналітики Similarweb вважають , що збереження нинішніх темпів зростання може дозволити Bluesky наздогнати Threads у майбутньому.  З моменту відкриття Bluesky для широкої аудиторії в лютому мережа показує вражаючі темпи зростання. У вересні платформа мала понад 9 мільйонів користувачів, а після виборів у США її аудиторія почала збільшуватись приблизно на 100 тисяч користувачів щодня. 13 листопада Bluesky досягла 15 мільйонів, а менш ніж за два тижні перевищила 20 мільйонів. Частина нових користувачів переходить на Bluesky через суперечки довкола X. Наприклад, зміни у функції блокування чи нова політика Маска щодо продажу даних користувачів для навчання AI відштовхнули багатьох. До того ж кампанія Маска на підтримку Дональда Трампа лише посилила відтік. ЄС вимагатиме передачі технологій від китайських компаній  ЄС готується запровадити нові правила, які зобов’яжуть китайські компанії передавати інтелектуальну власність європейським підприємствам в обмін на доступ до субсидій, повідомляє Financial Times .   Нові критерії передбачають, що китайські компанії, які претендують на гранти ЄС, мають відкривати виробництва в Європі та ділитися своїми технологіями. Ці вимоги будуть застосовані вже в грудні, коли Брюссель оголосить конкурс на виділення грантів у розмірі 1 млрд євро для розвитку виробництва акумуляторів. Такі заходи нагадують китайську модель, яка зобов’язує іноземні компанії ділитися своїми технологіями для доступу до ринку Китаю.  Посилення вимог викликане побоюваннями щодо перенаправлення китайського експорту до Європи, якщо США підвищать мита на китайські товари до 60%, як це пропонує новообраний президент Дональд Трамп. На тлі цих подій китайські виробники, як-от CATL, уже відкривають заводи в Європі, інвестуючи мільярди євро у виробництво в Угорщині та Німеччині. Інші компанії, як-от Envision Energy, розгортають виробництво в Іспанії та Франції. Водночас у Китаї уряд радить своїм компаніям обмежувати інвестиції в Європу через політичну нестабільність у регіоні.  Португальський стартап Tekever залучив $74 млн на розвиток дронів, які використовуються в Україні Гроші компанія планує  витратити для вдосконалення своїх технологій та розширення на нові ринки, зокрема в США. Фінансування очолили шотландська інвестиційна компанія Baillie Gifford & Co., яка раніше інвестувала в SpaceX, та Фонд інновацій НАТО — оборонний венчурний фонд на €1 млрд, створений у 2023 році для підтримки технологій у сфері безпеки, оборони та стійкості. Tekever, заснована в Португалії, також працює у Великій Британії та Франції. Її дрони цивільного призначення використовувалися для спостереження за контрабандистами в Ла-Манші. Найбільший дрон компанії, ARX, здатен управляти кількома меншими апаратами для моніторингу як морських, так і наземних територій, а також полів бою. Дрони Tekever вже застосовуються в Україні, а також за контрактами з Європейським агентством морської безпеки та Міністерством внутрішніх справ Великої Британії. Мінцифри презентувало платформу для популяризації цифрових досягнень На щорічному саміті Tallinn Digital Summit заступниця Міністра цифрової трансформації Валерія Іонан анонсувала   запуск нової платформи Digital State UA . Ця ініціатива об’єднає ключові досягнення України у сферах GovTech, IT та технологій. Платформа має на меті не лише демонструвати успіхи України у цифровій трансформації, а й сприяти залученню інвестицій у технологічний сектор та обміну найкращими практиками з іншими країнами. Офіційний запуск Digital State UA запланований на січень 2025 року. Проєкт реалізується за підтримки Міністерства цифрової трансформації України у співпраці з ініціативою «Підтримка цифрової трансформації», яку фінансують USAID та UK Dev.

Глобальне підприємницьке ком'юніті Endeavor відкрило український офіс та сформувало Раду директорів Endeavor Ukraine, в якій головує Віталій Лаптенок, співзасновник Genesis та венчурного фонду Flyer One Ventures. Також до Ради директорів увійшли топменеджери українських IT-компаній та венчурних фондів — MacPaw, Reface, Svitla Systems, Stratmind VC, UMAEF  та інших бізнесів.  Основна задача українського філіалу організації — підтримувати українських підприємців у їх бізнес-викликах: підготовка до M&A чи ІРО, експансія у нові країни та пошук найкращих профі на міжнародних ринках. Окрім цього, Endeavor матиме змогу дати українцям доступ до міжнародного нетворку, який утворився в межах організації — нині вона об'єднує підприємців з 46 країн світу. Основний фокус українського Endeavor буде зосереджено на технологічних компаніях з високим потенціалом зростання та сильними і амбітними фаундерами.  Український Forbes пише , що процес відбору до членства у організації складатиметься з чотирьох етапів і може тривати 6–18 місяців. Перший — це знайомство локального офісу Еndeavor із засновником компанії. Другий — зустріч із менторами Еndeavor. Завдання ментора – зрозуміти, на якому етапі розвитку перебуває компанія, які виклики перед нею стоять, як мислить засновник, чи може компанія швидко зростати. Третій етап — зустріч підприємця із членами локального борда Еndeavor. Що таке Endeavor?  Endeavor — це організація зі штаб-квартирою в Нью-Йорку, заснована 1997 року для того аби підтримувати талановитих підприємців, які мають потенціад для економічного та соціального впливу у своїх регіонах.  Організація об'єднує успішних лідерів, інвесторів та фахівців різних галузей, які готові ділитися знаннями та досвідом із підприємцями-початківцями. Це допомагає фаундерам зосередитися на масштабуванні бізнесу та реалізовувати інноваційні рішення, що мають потенціал змінити ринок. Нині мережа охоплює 2600 підприємців, чий сумарний дохід сягає $67 млрд.

«Останні 50 років геополітичну ситуацію визначало місце розташування нафтових резервів. У наступні 50 років важливим стане те, де будуть знаходитися підприємства з виробництва чипів», — сказав  генеральний виконавчий директор Intel Пет Гелсінджер у березні 2024 року. Він має рацію: не випадково глобальні лідери нині борються за вплив на невеликому острові у Східній Азії. Саме там створюються мікрочипи, які вже стали частиною життя кожного, хто користується бодай якоюсь технікою.  Пояснюємо це у великому експлейнері разом з Applied Scientist у компанії SQUAD та викладачем факультету прикладних наук УКУ Ігорем Крашеним та інвестиційним аналітиком фонду Flyer One Ventures Михайлом Перевозником. Що таке напівпровідники й навіщо вони потрібні Напівпровідники лежать в основі мікросхем та чипів, які використовуються в усіх електронних пристроях: машинах, телефонах, ноутбуках, комп'ютерах, зброї тощо. Їх не варто плутати з графічними процесорами, які виробляє, наприклад, Nvidia .  Напівпровідником називають хімічний елемент або сполуку, яка проводить електричний струм за певних умов і блокує його за інших. За своїми властивостями вона знаходиться десь посередині між діелектриками, що добре проводять струм, та ізоляторами, що його не пропускають. Найпопулярніший напівпровідник — кремній, на честь якого одержав  свою назву найбільший технологічний кластер світу. Також поширені германій, фосфор, бор, арсенід галію, фосфід індію тощо. Як виробляють мікросхеми Для цього потрібні гігантські фабрики та надзвичайно складне та дороге обладнання. Виробництво мікросхем відбувається на атомному рівні, тож воно потребує особливих умов та найкращих спеціалістів.  Основа чипа — це пластина з чистого напівпровідникового матеріалу на кшталт кремнію (будь-які домішки впливатимуть на властивості матеріалу). Все починається з вирощування монокристала, який розрізають на тонкі пластини. На поверхню такої пластини наносять шар діоксиду кремнію та фоторезисту — матеріалу на основі полімерів, який стає більш або менш розчинним, коли на нього впливає світло. Процес дає змогу створювати точний візерунок компонентів за допомогою ультрафіолетового променя.  Після фотолітографії (так називається процес, який ми описували вище) електрично-активні домішки вводять у пластину для утворення окремих p- та n-областей. Інакше кажучи — транзистори формують в самій пластині напівпровідників. Увесь процес виготовлення чипу триває кілька місяців і потребує не лише спеціального обладнання, а й складних систем для фільтрації повітря, регулювання температури та вологості.  Найважливіший прилад — це фотолітографічна машина, в основі якої —  технологія екстремального ультрафіолетового випромінювання (EUV). EUV-літографія використовує світло з довжиною хвилі 13,5 нанометрів. Високоточний лазер проходить   через спеціальні маски , які блокують світло в певних ділянках і пропускають його в інших. Таким чином на поверхні напівпровідника з’являється малюнок.  Провідним виробником систем фотолітографії є ASML, яка розташована в Нідерландах. Щоби розробити такий апарат, команді знадобилося 10 років та понад $6 млрд.  Увесь цикл виробництва не контролює жодна країна. «Типовий чип може бути розроблений за кресленнями британської компанії Arm, яка належить Японії, групою інженерів у Каліфорнії та Ізраїлі з використанням програмного забезпечення зі США. Після завершення розробки проєкт надсилається на підприємство в Тайвані, яке закуповує в Японії надчисті кремнієві пластини та спеціальні гази. Дизайн вирізається на кремнії за допомогою одного з найточніших у світі верстатів, здатних травити, наносити та вимірювати шари матеріалів товщиною у кілька атомів. Ці інструменти виробляються переважно п’ятьма компаніями — однією голландською, однією японською та трьома каліфорнійськими, без яких виробництво сучасних чипів практично неможливе. Потім чип пакується і тестується, часто в Південно-Східній Азії, після чого відправляється до Китаю для складання в телефон або комп'ютер», — пише Кріс Міллер у своїй книзі «Чипова війна».  Як з’явилися перші мікросхеми  Коли йдеться про винахід мікросхем, зазвичай згадують одне ім’я — Джек Кілбі. У 1958 році він працював у компанії Texas Instruments та придумав спосіб, як розмістити активні (тобто такі, що можуть підсилювати або контролювати електричний сигнал — наприклад, транзистори або діоди) та пасивні (елементи, які не підсилюють сигнал і не контролюють його, але можуть зберігати, обмежувати або змінювати електричний струм — це резистори, конденсатори тощо) компоненти на пластині з напівпровідника. Однак вважати його єдиним винахідником не зовсім справедливо.  Створенню мікросхем передували три фундаментальні проблеми, які 1958 року сформулював шведський інженер Торкель Волмарк:  Інтеграція. На початку 1960-х неможливо було розмістити н а кристалі напівпровідника багато різних електронних компонентів. Ізоляція. Способу ізолювати напівпровідникову пластину від компонентів на ній не було.  Поєднання. Ефективного методу електричних з'єднань компонентів схеми не існувало (окрім надзвичайно дорогого і складного монтажу золотим дротом). У 1959 році проблему ізоляції вирішив Курт Леговец, інженер-фізик компанії Sprague Electric у США. Він запропонував технологію ізоляції на кристалах за допомогою p-n-переходів, що розміщувалися між двома послідовно з'єднаними напівпровідниковими областями. Це рішення дозволило підвищити ефективність та надійність напівпровідникових компонентів та забезпечило їхнє стабільне функціонування без взаємного впливу. Приблизно тоді ж, у 1959 році, Роберт Нойс трохи удосконалив конструкцію Кілбі: використав кремній замість германію й розробив більш практичний метод з'єднання компонентів за допомогою техніки — планарний процес, який передбачав нанесення шарів і травлення на кремнієві пластини. Вирішення цієї проблеми було критично важливе для серійного виробництва мікросхем. Які основні компанії домінують на ринку чипів та напівпровідників Найбільша з них — це тайванська компанія TSMC. Її частка становить  62% ринку. За нею йде корейський технологічний гігант Samsung, який займає 13% ринку. Серед інших гравців — тайванська UMC (5%), китайська SMIC (6%) та американська GlobalFoundries (5%).  Що таке «дефіцит чипів» і як він вплинув на світову економіку  Пандемія коронавірусу 2020 року та вимушена диджиталізація усіх сфер життя значно вплинули на ринок мікрочипів. Криза зачепила понад 169 галузей, зокрема виробництво відеокарт, смартфонів, ігрових консолей та автомобілів. Раптове збільшення часу в онлайні (а отже — навантаження на серверне обладнання) та попиту на користувацьку електроніку змусило виробників нарощувати потужності.  Спочатку виробникам вдавалося задовольняти потреби ринку, однак на початку 2021 року почав відчуватися дефіцит. Окрім пандемії на це вплинула ще низка факторів:  кліматичні чинники, такі як посуха на Тайвані у травні 2021 року, що стала найбільшою за 56 років. Резервуари для води на TSMS заповнювалися лише на 11-23%, тоді як для очищення приміщень та пластин потрібно 63 тонн води на день. Пізніше Тайвань страждав уже від сильних дощів, які загрожували повінню. Схожа ситуація трапилася у США, де снігопади у лютому 2021 року спричинили масові відключення електроенергії. Через це постраждав, зокрема завод Samsung в Остіні;  популярність криптовалют, яка спричинила збільшений попит на відеокарти;  пожежі на японській фабриці Asahi Kasei Microsystems (AKM) та на заводі Renesas Electronics наприкінці 2020-го-початку 2021 років. Завод AKM був одним з найбільших виробників високоякісних аналогово-цифрових та цифро-аналогових перетворювачів, які використовуються в аудіообладнанні, медичних приладах, автомобільній електроніці тощо, а Renesas Electronics постачав 30% світового ринку мікроконтролерів для автомобілів. «Дефіцит чипів, викликаний локдаунами та логістичними обмеженнями, показав, наскільки вразливий ланцюг постачання складників. Постраждала логістика призвела до браку мікросхем, що вплинуло на виробництво процесорів та відеокарт, і, відповідно, на стан усього ринку електроніки», —  каже Ігор Крашений.  Додатковий тиск на ринок спричинили торговельні обмеження між США та Китаєм. Санкції, введені США у 2022 році, обмежили  імпорт китайських мікросхем, що погіршило ситуацію з поставками. Які геополітичні чинники впливають на цей ринок Напружені відносини Китаю і США підігріваються бажаннями Пекіну лідирувати у технологічних перегонах. І камнем спотикання у цій боротьбі є саме Тайвань з зосередженими на ньому виробництвами напівпровідників. Сам Китай інвестує  близько $2 мільярдів у власного виробника мікрочіпів, компанію Yangtze Memory, однак у короткостроковій перспективі ці вливання можуть не спрацювати: виробництво мікросхем потребує кваліфікованих кадрів і відповідного обладнання. У виробництво мікросхем активно вкладається і США, які закупил и у Тайваня рекордну кількість виробничих потужностей. Одна така фабрика може коштувати  $20 мільярдів.  2022 року президент США Джо Байден підписав  закон CHIPS and Science Act, який передбачав значні (понад $280 мільярдів) інвестиції у розбудову напівпровідникової галузі в США. Найбільша конкуренція розгортається у сфері штучного інтелекту — галузі, яка вимагає найбільш потужних чипів, здатних обробляти величезну кількість інформації.  Чи впливає геополітична ситуація навколо мікросхем та чипів на інвестиційні рішення у цьому секторі? В цілому так, каже інвестиційний аналітик Flyer One Ventures Михайло Перевозник. «Це впливає на рішення великих гравців інвестувати в хардвер, бо вони розуміють, що виробництво критично важливих чипів в США, Європі або інших дружніх демократичних країнах зменшує ризики, що їх становище може бути підірване через геополітичні потрясіння, наприклад, в Тайвані», — каже він.  Чому не можна зробити повний цикл виробництва мікрочипів в одній країні Теоретично можна, але це складно. «Є кілька факторів. По-перше, всі основні гравці як-от TSMC використовують обладнання нідерландської ASML, яка єдина у світі виготовляє прилади для екстремальної ультрафіолетової літографії. Це критично важлива технологія для сучасних мікросхем. Побудувати такий завод — довго і дорого, а без нього виробництво неможливе.  Крім того, багато країн і регіонів мають свою власну інфраструктуру, побудовану навколо цих компаній. Наприклад, Тайвань значною мірою залежить від TSMC, і теоретичне переведення виробництва потребувало б не лише обладнання, але й перенесення екосистеми, яка його підтримує», — каже  Ігор Крашений. З якими викликами зіштовхується галузь Окрім геополітичного напруження, дослідниця напівпровідників Стенфордського університету Срабанті Чоудхурі виділяє  низку інших проблем. Найперше — люди. Тих, хто свідомо обирає кар’єру в цьому напрямі, не вистачає. Через специфіку сфери результатів своєї роботи доводиться чекати роками — а це часто демотивує. Друга проблема — невідповідність між академічним середовищем та промисловістю. Попри перший пункт, завдань та шляхів реалізації у бізнесі доволі багато, але, за словами Чоудхурі, про це не говорять достатньо виразно.  Про інші виклики галузі розповідає Ігор Крашений: «За останні 20 років основні елементи мікросхем, транзистори, фактично не змінилися, однак суттєво зменшилися. Сьогодні розмір одного структурного елемента транзистора може складати лише три нанометри — майже міжатомна відстань.  Закон Мура  передбачає, що кількість транзисторів на квадратний сантиметр буде зростати вдвічі що два роки. Однак ми вже наближаємося до фізичних меж: неможливо зробити транзистор меншим за відстань між атомами. Наслідком може стати те, що кремній, як основний матеріал для мікросхем, поступово вичерпуватиме свої можливості. Тому потрібно буде переходити на нові матеріали з іншою атомною структурою на кшталт германію чи арсеніду галію — а вони набагато менш поширені в індустрії».  Варто зазначити, що 60% експорту германію та 80% експорту арсеніду галію припадає  на Китай, який рік тому ввів обмеження на їхній експорт. Чого очікувати в майбутньому  Срабанті Чоудхурі виділяє кілька напрямів, на розвиток яких напівровідники вплинуть найбільше. Найперше — штучний інтелект. «Ми намагаємося інтегрувати емоції у систему штучного інтелекту та створювати роботів, подібних до людей. [...] Поки що ми не можемо створити роботів — або, точніше, мікросхеми, необхідні для таких роботів — настільки ж ефективних, як люди, але ми рухаємося в цьому напрямку», — зазначає дослідниця. Інший напрям — медицина. Технології дадуть змогу людям, у яких немає доступу до новітньої медицини, одержувати висококваліфіковану медичну допомогу навіть дистанційно. Третій аспект — енергетика. Нині вона значною мірою залежить від нафти, але за переходу на відновлювані джерела енергії для неї також знадобляться напівпровідники.  Після попереднього дефіциту чипів прогнози щодо майбутнього галузі були позитивними. Втім, за прогнозами консалтингової компанії Bain & Co. , є «...кілька непередбачуваних чинників, які можуть спричинити нові збої, як-от глобальна економіка, геополітичні напруження та дефіцит обладнання». Одним з найбільш суттєвих факторів майбутнього дефіциту чипів є зміни у політиці Китаю, міністерство торгівлі якого нещодавно оголосило  про впровадження експортного контролю на продукти, пов’язані з галієм та германієм, «щоб захистити національну безпеку та інтереси». За деякими припущеннями, цей крок став відповіддю на експортні обмеження  США.  «Якщо такий дефіцит чипів станеться знову, це, безумовно, вплине на ринок, але повного коллапсу не буде. Ланцюжки постачання, ймовірно, відновлюватимуться досить повільно, але врешті-решт все стабілізується, — припускає Ігор Крашений. — Брак мікросхем може призвести до скорочення виробництва нових автомобілів, відеокарт, комп’ютерів та іншої електроніки — і відповідно, до зростання цін на ці товари. Однак наявна техніка продовжить працювати. Якщо програмісти зможуть оптимізувати код, на основі якого працює подібна електроніка, це подовжить термін служби старих пристроїв та пом’якшить наслідки потенційного дефіциту».

Як за пару років пройти шлях від невдалого запуску та півоту до першого мільйона юзерів та lovemark? Віра фаундера, скрупульозний та вивірений дизайн, знання своїх сильних сторін, правильні поглинання — ось секрет успіху, який привів Notion у топ.  Останнім часом компанія активно розширювалася, інтегрувала ШІ-асистента, а нещодавно — оголосила про майбутній реліз власного поштового клієнта. Про що свідчить така продуктова стратегія? Чи зможе Notion створити суперзастосунок, який покладе край домінуванню Google та Microsoft? Разом з фахівцем у розвитку продуктів Реєм Астафічевим, CEO Asta Academy та кофаундером AstaCorp, занурюємося в продуктову історію компанії. Design first Notion не одраз у став інс трументом для ефективності та командної взаємодії. Спочатку, у 2013 році, Айван Чжао та Саймон Ласт запустили no-code інструмент для розробки персоналізованих комп’ютерних програм. Перший мав ступінь з когнітивістики в Університеті Британської Колумбії, різноманітні захоплення та досвід роботи програмістом у стартапах. Другий вивчав комп’ютерні науки в Університеті Меріленду, а до того, як запустити Notion, був стажером-програмістом в Nebula, Inc та Науковому інституті космічних телескопів. Потреби в їхньому продукті ринок не мав, тому стартап довелося закрити.  Чжао та Ласт розпустили команду (на той момент у них працювало четверо людей) та переїхали із Сан-Франциско до Кіото. Мати Чжао позичила їм $150 000 й партнери почали перебудовувати свій продукт. З одного боку, вони залишили гнучкість та адаптивність як ключову ідею майбутньої розробки. З іншого — навіть їм двом для планування та проєктування доводилося використовувати занадто багато різних інструментів. Це спонукало задуматися про створення єдиного засобу, який містив би все необхідне для спільної роботи. Основним рушієм розробки став дизайн. Через скрупульозність Чжао, який захоплювався фотографією та мав бекграунд розробника вебсайтів, кожен елемент піддавався кільком ітераціям, допоки повністю не задовольняв фаундерів. Пізніше ітеративна філософія дизайну стала центральним елементом бізнес-культури Notion.  За рік активної роботи, у 2016 році, перша версія була готова. Вона вже містила канбан-дошки, продуктові роадмапи, wiki-сховища та понад 30 шаблонів для документів — значна функціональність, як для початкового релізу. Notion 1.0. запустили у вебі, також створили десктопний застосунок для MacOS. Релізи для Windows та iOS з’являться пізніше, у 2017 році, а застосунок для Android — у 2018-му.  На той час ринок застосунків для продуктивності був досить насиченим, але Notion вирізнявся здатністю охоплювати широкий спектр  користувацьких сценаріїв, виходячи за межі роботи лише з документами. Юзери високо оцінювали зручність редагування, різноманіття шаблонів на будь-який випадок і функціональні бази даних. Інтуїтивно зрозумілий інтерфейс, над яким так ретельно працював Чжао, став помітною перевагою, особливо порівняно з громіздким Confluence, що залишався основним вибором для продуктових команд. Незабаром після запуску Notion представила свою першу інтеграцію, яка дозволила користувачам під’єднувати платформу до Slack. Хоча ідея створення all-in-one застосунку вже мала перші успіхи, Чжао та Ласт не збиралися конкурувати з месенджерами й (на той момент) поштовими сервісами, адже розуміли, що програють. Інтеграція зі Slack стала елегантним і водночас стратегічно виваженим рішенням. Say hi to Notion У 2018 році вийшов реліз Notion 2.0. — з таблицями, базами даних та іншими можливостями для користувацьких сценаріїв. Він одразу ж став хітом на Product Hunt, отримавши відзнаку «Продукт місяця». Цей факт, а також схвальний огляд платформи у The Wall Street Journal  значно прискорили зростання кількості споживачів.  Ажіотаж та популярність підігрівало не стільки те, що Notion усував потребу в десятках окремих інструментів, скільки зручність організації баз даних, яку пропонувала платформа. Розуміючи свою сильну сторону, восени 2018-го компанія представила Rollups — функцію, яка давала користувачам змогу збирати та узагальнювати дані з інших таблиць, створюючи кастомізовані результати. Rollups дали звичайним користувачам змогу робити обчислення у спосіб, для якого раніше була потрібна допомога програмістів.  У березні 2019 команда представила функцію імпортування даних із застосунку Evernote, супроводивши її доволі агресивною комунікацією: « Tired of Evernote? Say hi to Notion».  Однак юзерів такий зухвалий хід не збентежив: уже у вересні 2019-го Notion похвалився першим мільйоном користувачів. На той час у компанії працювало лише 18 штатних співробітників. Чжао від початку був противником активного найму. Він вважав, що продукт можна створити невеликими силами, а необхідність додаткового найму свідчить, що наявна команда не повністю виконує свої завдання. Пандемія, що змусила людей перейти на віддалену роботу, підвищила попит на інструменти для спільної роботи, що значно сприяло популярності Notion. «Спочатку Notion використовувався дизайнерами та дослідниками як блокнот та архів для досліджень. Він був заповнений планами досліджень, нотатками з користувацькими тестуваннями та документацією. Поступово ми виявили, що такі функції Notion, як архітектура сторінки, зв’язки з базами даних та інтеграція з кількома службами, дуже допомогають в документуванні та передачі інформації. Так ми організували у Notion внутрішню систему управління знаннями», — пише  про свій досвід один з користувачів Medium. Багато бізнесів Лише за перші вісім місяців локдауну кількість користувачів зросла вчетверо. Чарівна паличка для білих комірців У 2021 році компанія здійснила своє перше крупне поглинання — індійський стартап Automate.io . Їхній продукт — інструмент для інтеграції застосунків — дозволив юзерам під'єднати до своїх ворк-плейсів понад сотню сервісів, як-от Gmail, Mailchimp, Salesforce, Google Workspace, Office 365, Dropbox, WordPress, RSS Feed, PayPal.  Це був тільки початок: 2022 року Notion поглинула диджитал-календар Cron, інструмент для управління робочими процесами Flowdash, а на початку 2024 у портфелі з’явився Skiff — стартап, який створює наскрізні зашифровані поштові та хмарні сервіси. Ймовірно, таким чином компанія готувала підґрунтя для найбільш неочікуваного анонсу — розробки поштового сервісу. Тоді ж компанія оголосила  про випуск власного календаря на базі Cron, який мав змогу інтегруватися з інформацією в базах даних. Існує два основні підходи до продуктових стратегій компаній, пояснює Рей Астафічев, CEO Asta Academy, co-founder AstaCorp. Перший — створення нішевого вертикального рішення, орієнтованого на певну цільову аудиторію. Компанія фокусується на цьому сегменті та його потребах, і, за достатнього обсягу ринку, досягає непоганих результатів. Протилежний підхід — створювати горизонтальні рішення з різними функціями для різних аудиторій. Це дозволяє залучати більше користувачів, масштабувати продукт і залишатися конкурентоспроможним завдяки його багатофункціональності. Суперзастосунок У жовтні 2022 року Саймон Ласт одержав листа від друзів з OpenAI, які запропонували компанії ранній доступ до моделі штучного інтелекту GPT (ми розповідали  про це в нашій щомісячній розсилці High Bar Newsletter ). Уже в листопаді розробники запропонували користувачам записатися до листа очікування, а в лютому  — реалізували Notion AI на широкий загал. Нова фіча ще більше посилювала позиції компанії: «штучний інтелект» відповідав за саммарі великих документів, покращення стилю написання та витягував ключові висновки з нотаток.  Восени 2024 року Notion підготувала великий апдейт, хедлайнером якого став власний поштовий сервіс Notion Mail. Ключова особливість — функції налаштування інтерфейсу та листів. «Електронна пошта не змінилася за 20 років. Вона захаращена, хаотична, нею важко керувати. Тож ми її перебудували!», — йдеться  на сайті компанії. Відомо, що інтеграція зі штучним інтелектом дозволить автоматично сортувати, архівувати листи та створювати чернетки.  «Я не думаю, що Notion намагається конкурувати з Google Mail чи іншими поштовими сервісами безпосередньо. Якщо подивитися на більшість нових email-клієнтів — вони всі мають прямі інтеграції з Google. Наприклад, Spark від Readdle напряму інтегрується з Gmail, усуваючи при цьому безліч їхніх проблем. Я підозрюю, що Notion піде схожим шляхом — не змагатися, а переосмислити частину функцій», — розмірковує Рей Астафічев. Водночас підкреслює він, новий застосунок повністю відповідає стратегії компанії — створити all-in-one екосистему для спільної роботи офісних працівників.  У вересні цього року компанія подолала  позначку в 100 мільйонів юзерів. Нині основні конкуренти Notion — це Google  і Microsoft . Серед продуктів останнього — платформа для спільної роботи Loop, яка підозріло схожа на Notion. Серед її особливостей — можливість налаштувати гнучке робоче середовище, «ієрархічні» сторінки, блокова структура, інтеграція з сервісами Microsoft, зокрема Copilot.  Чи може Notion потіснити їх з лідерів? Сам Чжао оцінює  цю мету як романтичну, навіть у контексті 10 років. Утім, це не скасовує прагнення підприємця створити інструмент який підходить для всього, і який організовує не лише роботу, а й особисте життя. «Це відбувається, як правило, знизу вгору: користувачі вперше пробують безкоштовні версії продуктів, звикають до них і потім рекомендують їх своїм менеджерам», — говорить Рей Астафічев. Так, Notion з’явився у McKinsey після того, як один із менеджерів організував у застосунку рецепти піци. Незабаром творці планують реліз Notion 3.0. — і ймовірно, їм буде чим здивувати своїх користувачів.

React має високий поріг входу чи його можна опанувати за декілька тижнів? Це застаріла технологія, яку скоро змінить щось нове, чи найстабільніший інструмент, на якому завʼязані BigTech проєкти? Анастасія Гордєєва , Front-end Team Lead у Wix, поділилася найпоширенішими упередженнями про React та його концепції, помилками при ререндері компонентів, які призводять до складних багів, а також розповіла, чому суперечки «бібліотека це чи фреймворк» — лише снобізм.  Для людей, які тільки починають розвиватися у фронтенд-розробці, є два міфи про React, що суперечать один одному. Перший — що React має високий поріг входу через JSX, декларативний підхід або нову концепцію хуків. З іншого боку React часто називають простим. Зокрема це продається на сумнівних курсах, які обіцяють, що за декілька тижнів можна повністю опанувати цей інструмент. Обидва твердження здаються мені абсолютним міфом. Будь-який інструмент —  React, Vue, Angular або будь-що інше, потребує певних зусиль для засвоєння нових знань та навичок. Не існує альтернативного інструменту, у якому вже на другий день можна стати Pro. Як сильно заглиблюватися в технологію, залежить від задач на проєкті. Наприклад, навчитися робити counter, намалювати кнопочку чи зробити форму — дійсно легко. Щоби продебажити застосунок та розібратися, чому він погано перформить, або додати новий стейт, не зламавши всі інші, потрібні глибокі знання React.   Часто JSX вважають фактором, що ускладнює роботу з React. На початку кар'єри я також читала про цей «недолік», проте пізніше зрозуміла, що це скоріше перевага.  JSX — це не якась нова мова програмування. Це синтаксис, схожий на HTML, з декількома нюансами. Щоби зрозуміти їх, достатньо один раз почитати відповідний розділ у документації, а потім попрактикуватися. Вважаю, що JSX покращує читабельність коду. Коли в ньому є правильний розділ на компоненти, одразу видно, які теги використовуються, яку логіку вони в собі інкапсулюють.  Що важливіше знати — JS чи React? Одні вважають, що краще заглиблюватися у класичний JavaScript, а фреймворки — досить мінливі. Інші — достатньо знати базу JavaScript, а заглиблюватися вже в React. Моя думка: навіщо обирати щось одне? Теоретично на маленькому проєкті, який команда не буде підтримувати надалі, можна викрутитися без глибоких знань, — завжди є GPT, Stack Overflow тощо. Проте, якщо це великий продукт, і наші рішення будуть «стріляти нам в ногу» за три роки, то однозначно потрібні глибокі знання як JavaScript, так і React. «Що таке React?» — одне з найбільш популярних запитань на співбесідах. І якщо ви назвете його фреймворком, вас обовʼязково виправлять: «Ні, це бібліотека». На мій погляд, ці суперечки — скоріше снобізм. Можливо, десь в інтернеті є чіткі критерії та визначення фреймворку та бібліотеки, але навряд ці знання допомагають у житті фронтенд-розробника. Хіба що «підіграти» інтервʼюеру та отримати додаткові бали на співбесіді.  Важливіше розуміти, що дає React «з коробки», а чого не дає порівняно з Vue, Angular та іншими фреймворками, в чому різниця між цими UI-підходами, та чому ми обираємо саме React. Непорозуміння щодо природи Virtual DOM і DOM браузера частіше трапляється серед новачків, які плутають ці два поняття. Насправді ж вони суттєво відрізняються. DOM (Document Object Model) — це стандартна структура, яку використовує браузер для відображення вебсторінки. Кожен елемент сторінки — текст, зображення, кнопки — є частиною DOM. Virtual DOM — це внутрішня структура React, не пов'язана напряму з браузером. Вона допомагає визначати мінімальні зміни, які потрібно зробити в реальному DOM, для покращення продуктивності. Щоби уникнути плутанини, у React-ком'юніті почали обговорювати зміну назви та ту, яка краще відображатиме справжню природу цієї структури. З ререндером компонентів у React повʼязано чимало упереджень. Наведу найпоширеніші з них. Компоненти ререндеряться, коли змінюються їхні props.  Ця тема також часто піднімається на співбесідах: інтервʼюери люблять питати, як це працює насправді. Є чотири правила ререндеру компонента: Initial Render — коли відбувається перший рендер усіх функціональних компонентів. Коли змінюється State у компоненті. Коли змінюється Context, на який підписаний компонент. Ререндер усіх дочірніх компонентів після ререндеру батьківського.  Останній пункт часто плутають із ререндером під час зміни props. Насправді ж незалежно від того, чи змінюються вони чи ні, якщо батьківський компонент ререндерився, те саме роблять і дочірні. Це потрібно для оптимізації процесів в React: замість того, щоби відстежувати зміни властивостей у кожному компоненті, він просто перерендерить всіх.  Ререндер після кожного виклику UpdateState функції Часто розробники очікують, що після кожного виклику setState відбувається повторний рендер компонента. Насправді це не зовсім так. У React є механізм оптимізації, який називається State Update Batching. Цей механізм дозволяє об'єднувати декілька викликів setState в межах одного колбеку, наприклад, під час обробки onclick-івентів або в таймерах, у один ререндер. Отже, навіть якщо ви декілька разів викличете setState у межах одного блоку, React об'єднає ці виклики і виконає лише один ререндер компонента. Це допомагає оптимізувати роботу і запобігає надмірним рендерам. Цю деталь важливо розуміти, щоби уникнути складних для визначення помилок.  Ререндер після зміни значення контексту Часто виникає помилкова думка, що всі дочірні компоненти провайдера контексту в React ререндеряться щоразу, коли змінюється значення контексту. Насправді це не так. Якби це було правдою, не було б сенсу у використанні Context API, оскільки не було б ніякої оптимізації. Ререндер відбувається тільки для компонентів, які є консюмерами контексту (використовують контекст через useContext або інший механізм споживання). Інші компоненти, що не споживають значення контексту, залишаються незмінними. На мій погляд, подібні меседжі можна зустріти про кожну технологію, і це наслідок агресивного маркетингу. Розробники фреймворків так само змагаються за своїх споживачів, як виробники Coca-Cola та Pepsi.  React завжди був одним із найстабільніших фреймворків. Кожна нова версія React залишається backward compatible, порівняно з іншими фреймворками, де великі оновлення змушували переписувати код. Запущений Facebook, на ньому був написаний Instagram та величезна кількість інших великих проєктів. Крім того, на ньому постійно запускаються нові проєкти та не обходиться, наприклад, Next.js. Крім того, ринок переповнений вакансіями для React-розробників, що свідчить про актуальність цієї технології.

У вересні 2024 року відбувся реліз нової версії Swift 6. Богдан Архипчук, iOS Developer у компанії OBRIO з екосистеми Genesis поділився враженнями про ключові оновлення та зміни.  Цього року Apple сфокусувалися на підвищенні Data Race Safety своєї мови, але також не забули про інші фічі — менш глобальні, але важливі для інтуїтивної роботи зі Swift. Головні оновлення, представлені на WWDC:  режим для запобігання race condition у паралельному коді; типізовані throw-методи для детальнішої інформації про помилки та роботи з ними; ітерація Parameter Packs для кращої роботи з загальними параметрами; кастомні самарі LLDB за допомогою @DebugDescription для кращого дебагінгу; Swift Testing для простішого тестування написаного коду. Реліз містить досить багато вагомих змін, тому розглянемо їх детальніше. Режим для запобігання race condition Race condition — це вічна проблема багатьох мов програмування, і Swift не є виключенням. Ці перегони можуть спричинити неочевидну та часом некоректну поведінку коду. Це досить важко виявити та дебажити, якщо не знати, де вони відбуваються. Apple вирішили зробити життя розробників менш стресовим і додали концепцію Async/Await у Swift 5.5. Це дало змогу керувати асинхронними операціями та зменшувати ризик перегонів.  Цього року вони пішли далі, і Swift 6 стає офіційно Data Race Safe. Це означає, що починаючи з цієї версії, Swift видаватиме помилки під час компіляції про потенційні стани race condition. Раніше вони максимум позначалися застереженням, на яке можна було закрити очі. Також завдяки покращенням протоколу Sendable, Swift потенційно має краще розуміти місця, де можуть виникнути такі ситуації, і убезпечує вашу логіку у такий спосіб. Також додана можливість міграції за модулями. Тепер немає потреби переводити весь проєкт одразу, а можна обирати, які фреймворки всередині будуть використовувати даний функціонал, а які — ні. Типізовані throw методи З додаванням асинхронності у Swift 5.5 ми також отримали методи, які можуть викидати помилки у разі невдалого виконання коду. Проте проблема з традиційним throws полягала в тому, що ми завжди могли кидати лише тип, який підпадає під загальний протокол Error. З одного боку, це протокол, який можна додати до будь-якого іншого типу як наслідування, але коли доходить до роботи з Error, єдине, що ми могли зробити — дістати локалізований опис. func parseRecord(from string: String) throws -> Record { // ... } do { let record = await parseRecord(from: “Record Name”) } catch { error.localizedDescription // єдина корисна проперті. } Зі Swift 6, у нас зʼявляється можливість вказати конкретний тип помилки, який ми очікуємо отримати.  Тепер наш код вище може виглядати так:  struct MyCustomError: Error { let description: String let recordName: String } func parseRecord(from string: String) throws(MyCustomError) -> Record { // ... } do { let record = await parseRecord(from: “Record Name”) } catch { error.recordName } Це неймовірно крута фіча, яка дозволить більш точно обробляти помилки, а також навіть будувати додаткову логіку для їхнього хендлінгу. Цікавий факт реалізації: зі Swift 6 всі методи будуть фактично «кидати» щось.  func parseRecord(from string: String) -> Record { // ... } Тепер такий метод — те саме, що: func parseRecord(from string: String) throws(Never) -> Record { // ... } Ітерація Parameter Packs Пакети параметрів, запроваджені у Swift 5.9, дають змогу писати узагальнені функції, які абстрагуються від кількості аргументів. Це усуває необхідність мати перевантажені копії однієї і тієї ж загальної функції для одного аргументу, двох чи трьох тощо. У Swift 6.0 ітерація пакетів робить роботу з пакетами параметрів простішою, ніж будь-коли. Розглянемо коди нижче:  struct Request { let payload: Payload ｝ func handleBatch(_ request1: Request) { // .. ｝ func handleBatch(_ request1: Request, _ request2: Request) { //… } func handleBatch(_ request1: Request, _ request2: Request, _ request3: Request) { // ... ｝ // Для виклику такого потрібен вже новий метод handleBatch ( Request (payload: 123), Request (payload:"TEST"), Request (payload: true) Request (payload: Data((16, 32, 641)) ) Замість того, щоби писати новий метод щоразу, з 5.9 версії зʼявився такий спосіб:  func handleBatch(_ requests: repeat Request) { // ... } handleBatch ( Request (payload: 123), Request (payload:"TEST"), Request (payload: true) Request (payload: Data((16, 32, 641)) ) Але проблема такого виклику у відсутності на той момент можливості зручно працювати з повторюваними загальними змінними, які ми передаємо в метод. У Swift 6 зʼявилася можливість використовувати звичний для всіх for loop: func handleBatch(_ requests: repeat Request) { for request in requests each request { // ... } } Кастомні самарі LLDB за допомогою @DebugDescription Типи, що відповідають CustomDebugStringConvertible, мають властивість debugDescription. Вона повертає рядок, що описує об'єкт. У LLDB команда po  викликає цю обчислювану властивість для об'єкта. На відміну від цього, команда p  використовує форматори зведення типів LLDB для безпосереднього форматування об'єкта за допомогою збережених значень його властивостей.@DebugDescription — це новий макрос у стандартній бібліотеці, який дозволяє вам визначати зведення типів LLDB для ваших власних типів безпосередньо у коді. Він обробляє властивість debugDescription, перетворюючи прості інтерполяції рядків зі збереженими властивостями у зведення типів LLDB. Це дозволяє LLDB використовувати ваше власне форматування навіть при використанні p . Макрос може використовувати наявну відповідність до CustomDebugStringConvertible, або ви можете надати окремий опис інтерполяції рядка лише для використання у команді p LLDB.  Надання окремого рядка опису LLDB може бути корисним, якщо ваша реалізація CustomDebugStringConvertible не відповідає вимогам макросу @DebugDescription, або якщо ви знайомі із синтаксисом рядка опису LLDB і хочете використовувати безпосередньо його. Наприклад: @DebugDescription struct Organization: CustomDebugStringConvertible { var id: String var name: String var manager: Person // ... var debugDescription: String { "#\(id) \(name) [\(manager.name)]" } } В дебазі виглядатиме ось так: (lldb) p myOrg (Organization) myOrg = "`#100 Worldwide Travel [Jonathan Swift]`" Це невелика, але дуже корисна зміна для покращення процесу дебагінгу, який розробники проходять ледь не щодня, намагаючись знайти помилки.  Swift Testing На останок, Apple вирішили зробити автоматизоване тестування ще простішим і створило нову бібліотеку Swift Testing. Вона повністю орієнтована на потреби розробників, які працюють з Swift, і включає описове API, яке дозволяє легко організувати будь-які тести. Бібліотека активно використовує нову технологію макросів, яка дозволяє на рівні компіляції генерувати додаткові методи і одразу використовувати їх в тестах.  Є основний макрос @Test, який дає зрозуміти, що даний метод є тестом, а також макрос #expect, який виконує функцію старого XCTestExpectation.   @Test func helloWorld() { let greeting = "Hello, world!" #expect(greeting == "Hello") // Expectation failed: (greeting → "Hello, world!") == "Hello" } Також можна налаштувати поведінку тестів або наборів тестів за допомогою ознак, вказаних у вашому коді. Ознаки можуть описувати умови виконання тесту, наприклад, на якому пристрої він повинен виконуватися, або обмежувати тест певними версіями операційних систем. Ознаки також можуть допомогти ефективно використовувати безперервну інтеграцію, вказуючи обмеження часу виконання тестів. @Test(.enabled(if: AppFeatures.isCommentingEnabled)) func videoCommenting() async throws { let video = try #require(await videoLibrary.video(named: "A Beach")) #expect(video.comments.contains("So picturesque!")) } Або навіть додати опис та набір базових кейсів, аби не перевикористовувати один і той самий метод декілька разів: @Test("Continents mentioned in videos", arguments: [ "A Beach", "By the Lake", "Camping in the Woods" ]) func mentionedContinents(videoName: String) async throws { let videoLibrary = try await VideoLibrary() let video = try #require(await videoLibrary.video(named: videoName)) #expect(video.mentionedContinents.count <= 3) } У цілому новий фреймворк виглядає цікавим та інтуїтивно зрозумілим, для тих хто хоче почати писати тести, а також дає змогу робити це швидко і лаконічно. Отже, Swift 6 приніс значні покращення та нові можливості, що роблять мову ще більш зручною для розробників. Проте нова версія також вимагає глибшого розуміння асинхронного програмування, оскільки Apple робить великий акцент саме на цьому. Як завжди, при міграції на нову версію можуть виникнути певні складнощі, але вони безумовно варті зусиль, адже це значно підвищить безпеку коду. Детальніше з оновленням можна ознайомитись в документації .  Чи пробували ви користуватись новими фічами? Буду радий, якщо поділитесь своїм досвідом зі мною в LinkedIn .