Питання грамотного менеджмента, балансу між хард- і софт-скілами, та професійного підходу до побудови процесів всередині команди хвилюють лідів усіх напрямків. Нещодавно на мітапі у MacPaw Space зустрічалися QA-ліди великих українських продуктових компаній. Керівники з AMO , Quarks , MacPaw і Uklon обговорювали найбільш гострі теми, що стосуються управління напрямом тестування. Найцікавіше із доповідей спікерів — у нашому конспекті. > Помилки QA лідів > Горизонтальна система керування тестуванням > Місія, візія і фейли > Комплексний підхід до проведення співбесід Помилки QA лідів Помилка перша. Найняти не ту людину Якщо ви єдиний QA-фахівець на проєкті, і маєте бюджет на другого спеціаліста, то саме ви будете тим, хто найматиме його. Що може піти не так? Людина виявиться не підходящою. По-перше, я б радив найняти ту людину, з якою вам особисто буде зручно працювати і спілкуватись. По-друге, ґрейд нового фахівця має відповідати вашому. Так колега зможе замінити вас у виконанні будь-якої таски за необхідності. Помилка друга. Неправильне планування Якщо ви долучаєтесь, наприклад, до великого проєкту, і вам потрібно найняти вже не одного, а 3-10-15 тестувальників, то проблема може виникнути інша. Нагірше, що може статись, — неправильно сплановане навантаження і невірно визначена кількість людей, яких потрібно найняти та який у них має бути ґрейд. Якщо ви не впевнені, що зможете все грамотно розпланувати, варто звернутись по допомогу до менеджера з досвідом. Помилка третя. Радикальні зміни Якщо ви приходите в уже сформовану команду як QA-лід, можлива помилка — одразу намагатись змінити усі процеси і підходи, які були налаштовані до вас. Спочатку покращуйте щось лише точково і спостерігайте, як все працює. Окрім цього, я б радив провести one-to-one з кожною людиною з команди, спитати її думку — що заважає, що допомагає, що можна покращити. Так ви зможете зібрати основні проблеми, пріоритезувати їх, і вже потім планувати зміни. Помилка четверта. Страх делегування обов'язків Як зрозуміти, що у вас проблеми з делегуванням? Ви ловите себе на таких думках: «лише я знаю, як краще». Пам'ятайте що, на жаль, лід із більшою ймовірністю втрачає технічні навички, тому ваші колеги скоріш за все, знають краще, що треба робити. «без мене все зламається». Це означає, що ви не довіряєте команді повністю. Такий підхід може спричинити «тепличні» умови для команди, коли лід все «розрулює». Ймовірніше, за таких умов команда припинить розвиватися. Помилка п’ята. Мікроменеджмент Мікроменеджмент — це руйнівне управління, від якого страждають усі сторони. Основна задача ліда — дивитись на ситуацію дещо відсторонено, згори, щоби прийняти максимально релевантне рішення. Вам не потрібно вирішувати проблеми за людей, бо це не закінчується ніколи. Часто мікроменеджмент виникає через недовіру до фахівців. Коли ви починаєте дуже сильно контролювати кожен крок спеціалістів, то витрачаєте свій час неефективно та заважаєте їм виконувати свої прямі обов’язки. А у людей від надмірного контролю з'являється відчуття, що вони не справляються, і їх перформанс ще більше просідає. Помилка шоста. Неприйняття рішень Мозок людини працює таким чином, що якщо якусь проблему довго не вирішувати, то починає здаватися, що вона якось вирішиться сама. Головна помилка — коли не приймаються рішення, що вже давно назріли. Як переформувати команду, і чи варто це робити, як відмовитись від певного фреймворку чи підходу до тестування, які ще наче працюють, але вже застарілі, чи варто підвищувати людину в посаді та зарплатні, чи варто звільняти людину, чи вона може змінитись і адаптуватись до вимог проєкту і компанії, чи варто назначати черговий мітинг чи можна обійтись електронною поштою? І ще мільйон різних запитань. Головний обов'язок ліда — прийняття рішень. Якщо вам здається що ваші рішення — неправильні або не найкращі, скоріше за все, ви на вірному шляху, тому що це свідчить про те, що ви рефлексуєте над ними. Інколи варто просто прийняти рішення, подивитись його на результат, відкоригувати за необхідності та рухатись далі. Горизонтальна система керування тестуванням Концепція гільдій Ще коли я лише починав працювати, мене дивувало, що в IT-галузі іноді на одного інженера — два або й більше менеджерів. Нині, в якості ліда, я потроху формую бачення, як зробити так, щоб це нормально працювало. В Quarks структура влаштована таким чином: є три великі команди — продуктова, маркетингова і tech team. В межах перших двох команд у нас є декілька автономних кросфункціональних тімок. Що вони собою представляють? Це команда, де є PM, який вирішує, що робити, які таски тощо. Також там є технічні спеціалісти: аналітики, дизайнери, фронтенд- та бекенд-фахівці, QA. Ще є команда tech team, якою керує CTO. В ній окремо є DevOps, сервісні команди, а також фронтенд,- бекенд- і QA-ліди. Я в якості QA-ліда керую як своєю командою автомейшена, так і по горизонталі всім QA-напрямком нашої компанії. Що це значить? PM в кожній кросфункціональній команді вирішує завдання, пов'язані більше з продуктовим навантаженням, який функціонал буде робитись, яка буде його пріоритетність. А я більше відповідаю зе те, як саме це має бути зроблено. Таким чином QA-інженер в команді має два керівника — PM і ліда QA-напрямку. Саме тому це називається горизонтальною системою або системою гільдій. Переваги горизонтальної організаційної структури: кожною гільдією керує лід, який розуміє специфіку роботи фахівців; кросфункціональна команда орієнтується на свої результати та процеси, їй не потрібно узгоджувати свій флоу з іншими командами; PM команди сконцентрований на продуктових задачах; система «стримувань і противаг». Ніхто не керує всім одноосібно, є декілька центрів прийняття рішень, а це мінімізує ризики; більш об'єктивна оцінка перформансу технічних спеціалістів; уніфікація підходів та стеку технологій. Основні складнощі в системі гільдій Важливо, щоб PM та QA-лід працювали в унісон, розуміли один одного, або хоча б не заважали. Кожна команда має свій темп, і це певною мірою може гальмувати уніфікацію. Треба шукати компроміс між усіма учасниками, аби уніфікація відбувалася, не ламаючи процеси нікому. PM команд мають різний рівень технічних скілів. Важливо комунікувати всі свої рішення та доносити до PM, чому ми робимо саме так. Лід гільдії повинен мати прокачані технічні і комунікативні скіли, тому що більшість проблем і труднощів виникають саме через брак комунікації і досвіду у когось із команди. Основні напрямки роботи QA-ліда гільдії Постійний контроль слідування побудованому флоу тестування. Створення єдиного центра керуванням тестуванням в компанії. Комунікація та роз’яснення процесів, інструментів та всього, що стосується QA. Уніфікація підходів. Це дає змогу суттєво заощадити час і кошти. Оцінка роботи QA в командах. Місія, візія і фейли Що таке місія і чим вона вам допоможе? Місія – певне розуміння того, чим ви будете займатись на тій чи іншій посаді. Як її сформулювати? Відповісти на питання: що ви робите, як ви це робите і навіщо. З ростом і зміною ваших зон відповідальності, зміною команди або проєкту буде трансформуватись і ваша візія. Коли я був інженером, після рев’ю я отримував фідбек про те, що треба розвиватись, шукати свій шлях, вірний вектор руху і таке інше, але що саме треба робити — було незрозуміло. Коли я став лідом, я усвідомив, що це і є моя місія — створити прозорі умови для розвитку інженерів в компанії з дотриманням справедливості по відношенню до компанії. Тобто щоби не лише люди зростали, а й компанія також отримувала профіт. Візія: тримати у фокусі Якщо з місією ви працюєте кожен день, тому що це і є ваша робота, то візія — це така собі лінія горизонту, яка майорить десь далеко, але саме вона змушує вас рухатись і приймати ті виклики, які кидає вам індустрія. Як не втратити візію в рутині? Ви маєте постійно перевіряти, наскільки ваша візія відповідає візії компанії, потребам продукту, індустрії. Її треба постійно розширяти, змінювати відповідно до обставин. Маєте сформулювати те, що ваша візія має дати сьогодні, щоб ви опинились в майбутньому там, куди ви плануєте прийти. Візія — це ваше завтра. Нині моя візія як ліда — рухатися в сторону спрощення з урахуванням тої цінності для бізнесу, яку ми можемо давати як інженери. Три фейли і три уроки, що вони принесли Люди не читають думок . Коли я починав лідити команду, у мене було море ентузіазму, багато ініціатив, я хотів все змінити. Так сталося, що, проговоривши свою місію, візію із тимлідом, я не отримав апрув від своєї команди. Насправді, я навіть не розповів їм про свої ініціативи. Мені здавалось, що все всім очевидно. Тож, коли я почав впроваджувати зміни, то зіштовхнувся із нерозумінням команди. Варто детально пояснювати команді ваш план — що і для чого, створити умови, щоб вони теж могли контрибьютити і бути залученими у реалізацію цієї стратегії. Вам потрібно мати чіткий роадмеп та надавати регулярні апдейти. Будь-які зміни потребують детального планування . Одного разу до мене прийшов один з інженерів і запропонував використати новий трендовий фреймворк. Я подумав — класно. Мені здавалось що це буде корисно і для розвитку команди, і для продукту. Але сталося зовсім по-іншому. Через деякий час частина команди, яка здійснювала цей перехід, мігрувала на інші ролі або у інші продукти. Ми опинились у ситуаціі, коли ми сидимо з новим проєктом, і в нас не так багато інженерів, які можуть використовувати його для роботи. Перш ніж робити серйозні зміни, які можуть вплинути на швидкість делівері продукту, треба оцінити наскільки ці зміни актуальні і потрібні зараз, чи зможете ви знайти спеціалістів, чи зможуть вони не лише підтримувати, а і розвивати продукт. Не толерувати те, що погано працює. Спочатку я був лідом однієї команди, потім — додалась друга, потім ще і ще. В одному продукті в мене було 5 QA-команд, які були досить розрізненими. Я побачив, що такому хаосі це не буде працювати ефективно — були проблеми з документацією, процесами, підходами, із взаємодією QA між собою. Якщо бачите проблему з процесами, не тягніть із рішенням. Може статися, що люди просто не дочекаються поки ви проблему вирішите, і підуть. Також не бійтесь обговорювати проблеми прямо із командою та менеджментом. Комплексний підхід до проведення співбесід У 2021 році Uklon почала швидко зростати: збільшилися поточні команди, одночасно створювалися нові. Нам потрібні були нові фахівці. Щобільше співбесід ми проводили, тим більше бачили, що наш підхід до інтерв’ювання кандидатів не працює. В нас був шаблон розмови, зосереджений на технічних питаннях, їх зазвичай багато в інтернеті. Рішення про найм ми приймали в залежності від професійних скілів. Здавалося б логічно, але це було нашою помилкою. Люди, яких ми обирали таким чином, відмінно підходили нам за професійним рівнем, проте не співпадали ані за цілями, ані за цінностями. Тож деякий час пішов на аналіз та зміну підходу. Я почав аналізувати: що QA-інженери роблять щодня? Приймають рішення — від малих до великих: коли почати тестування, що покривати тестами, які інструменти використовувати в роботі тощо. І я прийшов до того, що підхід кандидата до вирішення завдань для нас має бути важливішим за досвід роботи. Звісно, в новому шаблоні співбесіди технічні запитання нікуди не ділися, але вони стали мати другорядне значення. Нині основний блок запитань у нас на інтерв’ю — про прийняття рішень. Кожному кандидату я пропоную уявити певну ситуацію, наприклад: Інженер взяв задачу в роботу, але її опису немає. Як це можна виправити? Підходить дедлайн релізу, але баги не закінчуються. Що робити? Інженер працює над пріоритетними задачами, але його відволікають. Як змінити ситуацію? Відповіді на такі запитання показують: чи замислювався кандидат над процесами, в яких він працює; чи раніше приймав кандидат рішення самостійно; чи він працював зі своїми помилками; чи може він нести відповідальність за себе та команду. Технічні запитання. Копайте вглиб Оскільки технічні скіли ми у будь-якому випадку маємо оцінити, то для цього блоку співбесіди теж склали декілька вимог до інтерв’юерів: Уникати заготовленого списку запитань на співбесіді. Складати кастомізований список під кандидата — його скіли, досвід тощо. Мати заздалегідь розроблені плани співбесід для кандидатів будь-якого рівня. Під час інтерв’ю орієнтуватися на сильні, а не на слабкі сторони кандидатів. Ми визначили для такі масивні розділи, які важливі для нас: мобільне тестування, бекенд тестування і веб. В залежності від потреб, від команди, куди ми берем інженера, ми можемо спитати: Технічну частину співбесіди ми починаємо тепер окремого масивного блоку — чи то мобільне тестування, чи то бекенд-тестування або веб, — в залежності від позиції, на яку наймаємо. Далі під час розмови заглиблюємося в конкретну тему і намагаємося зрозуміти все, що кандидат про неї знає. Практикуємо щирість Ми хотіли, щоби наша співбесіда не була допитом. Кандидат в стресі не може адекватно оцінити свої знання і нормально відповісти на питання. Йому має бути комфортно протягом всієї розмови. Якщо він не знає відповіді на запитання або не розуміє його належним чином, я відповідаю на це питання, тим самим показуючи йому, що я від нього очікую. Це класно налаштовує кандидата далі. Тож в новій ітерації нашого підходу до співбесід ми вирішили, що віддаємо частину контролю кандидату, аби він: розумів хід співбесіди; отримував відповіді на свої питання міг розраховувати на якісний і своєчасний фідбек. Повний запис мітапу QA-лідів дивіться тут:

Завдання дата-інженера — не лише налаштувати коректну роботу з даними, а й пояснити всім стейкхолдерам, як влаштована його робота. Інакше команда отримує нерелевантні запити, робочі процеси порушуються, а якщо хтось ще й використає hard delete замість soft delete — додаткового головного болю не уникнути. Про те, що найбільше дратує Data Engineers, розповіла Тетяна Лелюх, Data Engineering Lead в Solidgate , партнерській компанії Genesis. Тетяна приєдналася до компанії чотири роки тому на позицію Data Analyst, а потім перейшла у Data Engineering й виросла до ліда команди. Доступи для роботи з БД видають DevOps-інженери . Однак ці доступи мають властивість експайритися, тож ставити завдання на видачу нових потрібно часто. Оскільки команда DevOps робить це вручну, ймовірність помилки є завжди. Видача доступів до нового сервісу — задача, яка потребує великої кількості кроків зі сторони DevOps-інженера, як-от створення користувача, відкриття мережевого доступу. Знову таки, є ризик помилитися через людський фактор: користувача створили, одну мережу відкрили, а другу — забули. Доводиться повертатися до цього завдання, просити виправити, чекати. Окрема історія — ротація паролей до баз. Якщо це одна база даних, ситуація не критична. Але у дата-інженера таких баз десятки, й коли доступи заекспайрилися в декількох із них — стає сумно та боляче. Втім, зазначу що у фінтех-індустрії робота з доступами особливо необхідна з міркувань безпеки, тому це нормальне явище. Тут допомагає правильна комунікація та вибудовані процеси. Посадові обов’язки дата-інженерів відрізняються від компанії до компанії: десь вони ближчі до аналітиків, десь займаються підготовкою даних до production. Через це не всі чітко розуміють, чим займається команда чи фахівець. Інформація з Google може згодитися, але її не завжди вийде застосувати до конкретної компанії. Команда дата-інженерів в Solidgate виросла та нещодавно відокремилася від команди аналітики. Втім, деякі аналітичні запити, наприклад, наявність даних у Tableau-репортах, й досі за інерцією стікаються до нас. І навпаки — завдання щодо проєктування систем чи баз даних, які якраз належать до нашої зони відповідальності, відправляються до інших команд. У Solidgate команда аналітиків займається доставкою даних з різних баз, які розкидані в системі, в єдине сховище. Ми також трансформуємо ці дані в потрібний для кінцевого споживача вигляд та займаємося їхньою валідацією. Аби уникнути непорозумінь у майбутньому, ми ввели практику: я роблю невеликий екскурс професією для новачків-аналітиків — а ми найтісніше співпрацюємо саме з цією командою — та пояснюю, за що відповідає наша команда, та як саме влаштовані дані у нас. Самі по собі ні hard delete, ні soft delete не є поганими. Використання того чи іншого методу залежить від сутностей і того, як спроєктована система. Головне — не використовувати hard delete там, де може виникнути необхідність відновлювати дані. Неправильне використання soft та hard delete може призвести до двох негативних наслідків. Перший — порушення зв’язків між сутностями. Наприклад, у нас є три таблиці, перша і третя пов’язані через другу. Якщо хоча б один рядок у ній видалити через hard delete, то зв'язок між першою й третьою таблицями зламається. Надалі це може призвести до непрогнозованих та неочевидних збоїв в системі. Інший ризик пов’язаний з користувачами продукту. Уявіть, що юзер звертається з проханням, до прикладу, надати дані його платежу. Якщо їх чомусь видалили через hard delete, то відновити інформацію не вийде — і лояльність людини втрачено. Тому натомість ми майже всюди рекомендуємо використовувати soft delete та маркування даних, а hard delete залишаємо лише для пари сервісів. Дані не будуть корисними, якщо ми не впевнені в їхній якості. Висновки, сформульовані на хибних чи некоректних даних, можуть зашкодити більше, ніж їхня відсутність взагалі. Через це валідувати дані важливо на всіх етапах. Тобто, і розробники, і дата-інженери мають контролювати, що записується в БД, і чи записується туди щось взагалі. Останні також мають стежити, щоб дані залишалися валідними після їх маніпуляцій, як-от доставка чи трансформація. Втім, для розробників це другорядне. У них є свій пул завдань — і часто до даних просто не доходять руки. Виправити баг із записом не складно, складніше щось зробити з уже неправильно оформленими даними. Якщо їх багато — навантаження на БД зачепить і роботу інших систем. До того ж ручне втручання в сутності та помилки можуть призводити до непередбачуваних наслідків для системи. Це класична проблема в усіх командах, що займаються IT-продуктами. Неочікувані запити не лише руйнують планування для команди дата-інженерів, а й суттєво ускладнюють роботу. Адже щоб дані були консистентними, після внесення змін код його потрібно «прогнати» на повному обсязі даних. Через це буває важко навіть розрахувати, скільки часу може зайняти робота. Особливо, коли мова йде про зміни історичних даних за три-чотири роки. Натомість стейкхолдери часто очікують на швидке виконання запитів. І тут ми повертаємося до першого пункту — не всі розуміють, як працюють дата-інженери, та як налаштовані їхні процеси. Аби подібних термінових запитів було менше, ми покращуємо планування на рівні всієї продуктово-технічної команди. Таким можуть грішити новачки або ж ті, хто погано знає SQL. Якщо немає фільтра за датою, запит буде тягнути з БД не конкретну інформацію, а всі дані за декілька років. А тоді збільшується і час виконання завдання, і навантаження на систему. Всі ресурси починають працювати на читання, запис сповільнюється, сервіс починає деградувати — і врешті весь продукт «гальмує». Крім того, якщо база даних погано спроєктована або дуже велика, решта запитів працює повільніше, тож вплив "SELECT * FROM Table" починає відчувати вся команда. В аналітичному сховищі ми вирішуємо проблему через таймаути: база обробляє запит певний час, а потім відключає його. У нашій системі — понад 15 різних БД на базі Postgres. Кожній відповідає конкретний сервіс, за які, своєю чергою, відповідає окрема команда розробників. За відсутності чіткої стандартизації, єдиної для усіх команд, дані «записуються» у різних форматах, а зв’язки між таблицями формуються за різними підходами. Так, дані в колонці-ідентифікаторі в одній базі можуть зазначатися числами, в другій — за стандартом UUID, в третій буде ще якийсь формат. Або ще приклад — наявність поля, де зазначено час запису в базу. Наче як стандартна практика, але одні команди беруть його до уваги, а інші — ні. Через це бази даних у різних сервісах можуть проєктуватися різним чином — і на виході ми маємо таблиці в 15 БД, створені за 10 патернами. Як наслідок, інструмент для доставки даних, який розробляє команда дата-інженерів, треба дуже ускладнювати, прописуючи кілька варіантів обробки різних структур даних. Вирішити проблему допомагає підготовка RFC зі стандартами проєктування БД та приведення власне баз до цього стандарту. Серйозність змін залежить від обсягу інформації: якщо історичних даних досить багато, то змінити все буде важко та ресурсозатратно. Тоді краще переробити інструмент відповідним чином та запровадити єдиний стандарт на майбутнє.

Під час зародження українського продуктового IT розробники могли самі закривати аналітичні завдання. Зараз так уже не вийде — роль аналітика стала однією з ключових у розвитку IT-продукту. Чи виходити на новий ринок? Чи додавати нову кнопку на екран онбордингу? Чому юзери йдуть з продукту на 3 день? Усі ці проблеми допоможе вирішити хороший аналітик. Утім, працюючи над проблемами продукту, кожен з них стикається з низкою викликів. Про найпоширеніші з них розповів Олександр Логутов, Business Analyst у Headway , партнерській компанії Genesis. Олександр працює з напрямом B2B — шукає оптимальні рішення щодо розвитку Headway для бізнесу та підтверджує їх ефективність цифрами та даними. Уявіть, що вам щодня потрібно розв’язувати логічні задачі — і займатися лише цим. Приблизно такий вигляд має робота аналітика: він заглиблюється в нові ніші, досліджує потенціал та ефективність запусків проєктів, перевіряє ідеї. Шукати інформацію та порівнювати дані — це кропітка праця, яка вимагає системності, уваги та об’єктивності. Бувають об’ємні запити стейкхолдерів, пов’язані, наприклад з тим, яку фічу треба додати в продукт для ефективнішого Value Proposition, або скільки часу та ресурсів може піти на розробку подібної фічі. Тоді аналітик працює над ними тижнями. Навіть якщо людина любить робити ресерчі, то вигоріти за таких умов дуже легко. Коли стратегія розвитку компанії трансформується, завдання бізнес-аналітика — вивчити і новий ринок, і прямих та непрямих конкурентів, і різні когорти користувачів. Аби провести якісне дослідження, фахівець повинен мати знання у різних доменах. Наприклад, потрібно з’ясувати, що саме відштовхує користувачів від продукту, або як краще взаємодіяти користувачами, які цікавляться версією для бізнесу. Тоді бізнес-аналітику треба стати продакт-аналітиком — і розібратися у відповідних метриках та даних. Або розглянемо, наприклад, маркетинг. Якщо аналітик не працює безпосередньо в маркетинговій команді, то це не його зона відповідальності, однак аналіз попиту чи конкурентів у новій ніші вимагає його залучення, і, відповідно, занурення у сферу. Наприклад, нещодавно один зі стейкхолдерів запропонував розробляти готові «книжкові клуби» для B2B-клієнтів. Перед тим, як впроваджувати ідею у життя, я маю дослідити ринок, і зрозуміти, чи потрібна подібна послуга. Ресерч ще триває, однак вже зараз є показники, які підтверджують, що гіпотеза може спрацювати у Tier-1 країнах. Наприклад, п’ять мільйонів американців є учасниками офлайнових книжкових клубів, а ще 40 мільйонів обговорюють прочитане онлайн. Інший приклад — кількість компаній, які вже пропонують таке рішення та їхній приблизний дохід на рік. Тут йдеться саме про нові ніші, з якими аналітик не зіштовхувався раніше. Наприклад, команда ухвалила рішення розвивати SEO-напрям. Звучить логічно: самостійно знайдений у Google продукт зацікавить юзерів більше — й компанія одержить вмотивованіших користувачів. Однак перед презентацією ідеї аналітик має обґрунтувати, чому бізнесу потрібен SEO-менеджер із зарплатнею приблизно $1500 та інструменти просування на $500 щомісяця, а ще — спрогнозувати, чи окупляться ці витрати в майбутньому, й чи справді органічний трафік принесе більш релевантних лідів. Щоби надати справді об’єктивне рішення, аналітик має швидко та ретельно розібратися у новій ніші: з’ясувати, як працює оптимізація у пошуковиках, переглянути дослідження інститутів чи великих консалтингових компаній, як-от McKinsey & Company, з’ясувати, наскільки більше користувачів для B2B SaaS-продукту принесе органічне просування. Навіть якщо він упевнений у доцільності гіпотези, її все одно спочатку тестують. У прикладі з SEO це означає, що команда знаходить статті, що можуть добре спрацювати в пошуку, оптимізує їх мінімальною кількістю зусиль, а потім відстежує результати. Аналітиків часто долучають до нових запусків на початку, тому від якості їхньої роботи залежатиме те, наскільки надійним вийде продукт чи фіча, або наскільки успішним буде бізнес у новій ніші. Вартість запуску на новому ринку може коштувати десятки, а то й сотні тисяч доларів, тож невірна чи неперевірена гіпотеза бізнес-аналітика обійдеться компанії дуже дорого. На щастя, в моєму досвіді не було аж настільки вартісних факапів. У Headway загалом існує правило: кожну помилку варто сприймати як урок. Так, подібний урок може коштувати дорого, але якщо він дозволить виявити прогалини у плануванні чи гіпотезах, знайти нові шляхи для розв'язання проблеми, то витрати цілком виправдані. Якщо ідеї неуспішні, надзвичайно важливо повернутися на початок та розібратися в причинах. На психологічному рівні це може бути складно: коли ти уже повірив у гіпотезу та довго нею займаєшся, відмовлятися від початкового бачення буває складно. Однак подібна практика дуже корисна для майбутніх проєктів, оскільки допомагає уникнути аналогічних помилок. Під час ґрумінгів з командою ідея А може легко перетворитися в комбінацію ідей А і Б. Тому і результат тесту потім може вийти не таким, як очікувалося. Наприклад, ви з командою проєктуєте лендинг для B2B-продажів і додаєте до нього Calendly — сервіс, який дозволяє швидко забронювати вільний слот для дзвінка. Клієнту потрібно залишити своє ім’я, електронну пошту — і час заброньований. Усе дуже просто. Однак під час обговорень з’являється інша ідея: запропонувати залишати ще й назву компанії та посаду. Наче непогано, однак подібне питання — досить особисте. Людину може відштовхнути необхідність залишати персональну інформацію. Ймовірно, вона зайшла на лендинг подивитися демо, а натрапила на повноцінний онбординг, — а це може погано впливати на конверсію. Подібні ризики варто враховувати. У такому випадку аналітик має брати на себе відповідальність і переконувати, чому краще робити інакше або тестувати спочатку перший варіант. Як аргумент можна наводити те, що сильні гравці на ринку послуговуються іншими підходами. Я дуже люблю робити ресерчі й вірю, що перед будь-яким запуском треба підтвердити гіпотезу аргументами й цифрами. Поки роблю дослідження, можу настільки впевнитися у життєздатності гіпотези, що ризикую втратити об'єктивність, яку не маю втрачати. Після погляду стейкхолдерів ідею можуть забракувати, навіть якщо вона підкріплена цифрами. Причини можуть бути різними. Одна з них — більш відповідна експертиза інших членів команди. Наприклад, біздеви багато спілкуються з клієнтами, тож можуть знати більш дієві підходи. Інша причина — на тестування гіпотези потрібно багато ресурсу, але його доцільніше спрямувати на інші бізнес-завдання. Бізнес-аналітик допомагає ухвалювати рішення різним командам та напрямам, тож часто тестує багато гіпотез паралельно. Наприклад, одночасно із завданнями від продуктової команди я можу взяти в роботу прохання перевірити ідею запуску SEO-напряму від маркетологів або перспективи імейл-маркетингу від біздевів. Окрім цього, є щоденні завдання або ті, які треба робити щомісяця, як-от же аналіз конкурентів — і за ними теж потрібно стежити. Через це виникає розфокус і деякі деталі можуть губитися. Щоб зменшити цей біль аналітики використовують класичні методи планування канбан і скрам, а також інструменти Notion та Synx. Якось ми вирішили протестувати механіку квізу для B2B-клієнтів. Цей інструмент класно працює у B2C, тож ми вирішили спробувати його і в іншій бізнес-моделі — попри те, що ідея виглядала суперечливо. У B2B-продуктах зазвичай не користуються подібними підходами, тож ґрунтовно підтвердити ідею цифрами не вдалося. Втім, вирішили спробувати. Я не можу сказати, що гіпотеза спрацювала погано, але не так добре, як ми очікували. Підхід підняв охоплення, кількість реєстрацій на дзвінок збільшилася, але їхня якість впала, а кількість покупок суттєво не змінилася. Зараз ми вирішили трохи змінити механіку цієї ідеї. Тому я завжди за те, щоб максимально обґрунтовувати кожну тезу цифрами. Звісно, якщо це можливо. Обов’язки бізнес-аналітика можуть різнитися від компанії до компанії. Для певних позицій комунікація необхідна, адже фахівці працюють безпосередньо з клієнтами та розробляють рішення для них. Тоді аналітик частково виконує завдання проджект-менеджера: розбирається у клієнтських вимогах, формує ТЗ та передає його розробникам. Бувають напрями, де комунікація некритична — коли аналітики, наприклад, шукають нові стартапи або ніші для інвестування. Тоді вони приділяють більшість часу саме ресерчу. Однак вміння спілкуватися потрібне в будь-якому разі. По-перше, у кросфункціональній команді аналітик постійно спілкуватиметься з продакт-менеджерами, маркетологами, дизайнерами тощо. По-друге, купу корисної для роботи інформації, фахівці одержують саме від професійного нетворкінгу — і мають уміти зробити так, аби люди хотіли ділитися з вами інсайтами про продукт. Особисто мені нескладно спілкуватися, однак бувають періоди, коли я втомлююся від обговорень. Тоді я беру перерву на два-три дні, та займаюся тільки документацією та ресерчами.

Нещодавно Genesis Academy провела черговий відкритий освітній тиждень Genesis Growth Week. Протягом сімох лекцій від С-level фахівців генезійських та партнерських компаній усі охочі дізнались про кейси запуску, успіхів та невдач цифрових продуктів. Нотатки про найцікавіші секрети зростання IT-бізнесів — в новому матеріалі блогу. 5 принципів UX зрілості, що допомагають будувати продукти №1 у світі ПРИНЦИП №1 Досліджуйте конкурентів Це дасть вам розуміння ринку: ніша, основні гравці, їх продукти, цінність, що вони несуть юзерам, досвід їх користувачів. Розуміння ринку дає картину того, де конкурентів буде багато, а де щільність продуктів у ніші нижча — де червоний і голубий океани. Окрім цього, дослідження сильних та слабких сторін конкурентів дасть вам змогу робити свій продукт кращим та вирізнятись з-поміж інших на ринку. ПРИНЦИП №2 Будуйте дизайн-процес Дизайн-процес — це те, як ми створюємо і покращуємо наші продукти. Ось так виглядає дизайн-процес в нашій компанії: У нас з’являється класна ідея, яку ми хочемо затестувати. Ми дизайнимо, паралельно щось кодимо, запускаємо, дивимося, чи є product market fit, чи зводиться у нас юніт-економіка . Далі або робимо нову ітерацію, або півот, або — в найгіршому випадку — нічого не робимо. В цьому процесі ми завжди працюємо над розв'язанням чітко сформульованої проблеми, і в результаті генеруємо рішення. Зазвичай це користувацька проблема, вирішення якої зможе допомогти бізнесу рости. Якщо ви послухаєте, про що говорять в продуктових командах в Headway, то найчастіше звучить питання: «Яку проблему ми вирішуємо?». Це класне питання, яке я раджу вам задавати дуже часто, особливо коли ви відчуваєте, що дизайн-процес десь загальмував. ПРИНЦИП №3 Взаємодійте Як запобігти ситуаціям, коли різні члени команди працюють над одним процесом паралельно, а не спільно? Наприклад, продакт-менеджер і продакт-дизайнер починають окремі користувацькі дослідження. З досвіду Headway: найголовніше, що треба зробити — відповісти на питання, хто що робить. Для цього ми декомпозували цінність, яку доносимо користувачу, на три складові: життєздатність продукту, реалізація нових рішень і бажаність його серед користувачів. За кожну з них відповідає конкретний фахівець, що знає, якими питаннями він опікується. Це дозволяє кожному вносити свою частку до створення цінності продукту. ПРИНЦИП №4 Ви — не ваші користувачі Ми ніколи не дізнаємось, про що думає юзер і як він користується нашим продуктом, якщо ми в нього не запитаємо. Окрім юзабіліті-тестування, який є складовою нашого дизайн-процесу, ми проводимо ще загальні дослідження, які дають нам краще розуміння наших користувачів. Все, що пов'язане з отриманням інсайтів від користувачів, називаємо користувацькими дослідженнями. Це аналіз звернень у сапорт, дослідження відгуків на продукт: як позитивних, так і негативних, й інші інструменти. ПРИНЦИП №5 Проповідуйте UX В цьому випадку я маю на увазі, що розповідати, ділитись інформацією та запитувати про користувацький досвід — це важливо. Коли я доєднався до Headway, в моїй команді було чотири людини. Я почав «проповідувати» UX, напевно, з першого дня. Я постійно наполягав на проведенні користувацьких досліджень, інтерв’ю, і казав, що кожна людина в нашій компанії прямо чи опосередковано працює на покращення користувацького досвіду, чим би вона не займалась. Як ловити хвилю технологій, щоби покращувати свій продукт. Кейс із практики PlantIn Найголовніша проблема, з якою до нас приходять користувачі, це те, що у них хвора рослина, і вони не знають, як її лікувати, не розуміють, що з нею трапилось. Від початку у нас у застосунку було два можливі варіанти розв'язання цієї проблеми: індикатор хвороб на основі ML та консультації з експертами. ML-індикатор допомагав виявляти базові хвороби й давав основну інформацію про догляд, про типи шкідників та способи їх усунення тощо. Але проблема була в тому, що цей інструмент дуже загальний і не здатен скласти індивідуальний план для кожної рослини, бо вони всі дуже різні, бувають різні стадії хвороб і багато інших відмінностей. Експерт із ботаніки може скласти детальний план догляду, проте на це піде декілька днів, а за цей час з рослиною може статись що завгодно. Тому ми шукали якийсь проміжний інструмент, який був би достатньо швидким і точним для складання мінімально релевантного плану догляду за конкретною рослиною. Одного дня наш ML-розробник натрапив в мережі на нову статтю про модель міні-GPT-4, яка начебто поводить себе, як ми б і хотіли: може за фотографією рослини скласти мінімальний план для того, аби її вилікувати. Враховуючи, що про ChatGPT та інші ШІ-асистенти вже говорили всі навкруги, нам треба було максимально швидко реалізувати цю фічу, поки її не реалізували конкуренти. Так у нас з'явився інструмент AI Expert Help, в якому штучний інтелект оперативно складав план з догляду за рослиною одразу після запиту. Що ми взагалі не очікували — це отримати листа від Apple, в якому компанія писала, що їм сподобався новий інструмент і вони запропонували його опублікувати в окремому розділі в AppStore. В результаті ми дійсно ми були зафічерені в Німеччині, Нідерландах, Іспанії. Ми абсолютно впевнені в тому, що якби ми робили все повільніше, то не сталося б ні нової функції, ні фічерингу в AppStore. Застосунки з використанням різних форм AI з’являються нині щодня, швидкість реалізації фіч у цій ніші — надвисока. Цей кейс навчив нас ловити тренди в момент, коли злітають, не гаяти часу і швидко реалізовувати ідеї. Як вирости вдвічі за допомогою диверсифікації гео У 2022 році ми в Impulse почали диверсифікацію за різними географіями: поступово розширились до 48 країн. Нині вже можемо сказати, що це допомогло нам вирости в декілька разів. ROAS (показник рентабельності витрати на рекламу) виріс утричі, LTV — у 2,5 раза, а дохід на рекламу в застосунку — в 1,4 раза. Як підготуватися до тестування нових гео? Перш за все, треба визначитись, навіщо ми хочемо тестувати ту чи іншу країну. Другий пункт – це формування критеріїв валідації вашої гіпотези. Тобто ви сформували гіпотезу, вам потрібно розуміти, які метрики ви будете аналізувати, з якими бенчмарками будете порівнювати ті чи інші показники вашої воронки, наприклад. Третій крок — це оцінка своїх ресурсів і оцінка ресурсів команди. Важливо зрозуміти, чи маєте ви необхідні технічні умови для тестування нової країни. Тобто, чи локалізований додаток на цю країну, чи адаптовані та перекладені креативи, чи перекладені тексти, чи достатньо у вас в команді людей і часу, скільки грошей з маркетингового бюджету ви можете витратити на тестування тощо. Процес В середньому ми тестуємо від п’яти до десяти адаптованих креативів на локалі в день. Приблизно місяць ми тестуємо нову географію і за цей період можемо вже зробити більш-менш провалідовані висновки про те, чи спрацювала країна в плюс, чи в мінус, чи варто її далі крутити, чи варто зупиняти, чи заробляємо ми на ній, чи ні. Коли починаємо тестувати, зазвичай використовуємо стратегію lowest cost. Вона допомагає нам швидко прийняти рішення, що є вкрай важливим на етапі тестування, особливо якщо ми тестуємо якусь нову країну і не знаємо, які результати вона нам покаже. Зазвичай на етапі тесту заходить до 4% всіх креативів. Ринковий бенчмарк — до 3%. Як аналізувати тести? Головні критерії аналізу тестів — ціна за цільову дію та позитивний ROAS. Наприклад, в нашому випадку один з головних критеріїв – це CPA, вартість покупки в застосунку. Проте у різних застосунків може бути різна цільова дія: встановлення додатку, конкретна покупка або група покупок. Це залежить від того, як налаштована аналітика. Також ми аналізуємо CTR, тобто показник того, скільки користувачів натисли на рекламу з усіх, хто її побачив. Треба враховувати, що середній CTR може відрізнятися у різних локалях, і це нормально. Як працює R&D, що запускає понад 100 MVP на рік Життєвий цикл ІТ-продукту складається із шести етапів. До достатньо для функціонування доходить умовно 0,001 % команд. Ми тестуємо чимало ідей, перш ніж зʼявиться та, яка дозволить нам дійти до кінця. Нижче — детальніше про кожний з етапів. ЕТАП №1 Дослідження Аналізуємо тренди: куди інвестують найбільші венчурні фонди, де зʼявляються нові гравці та починають швидко зростати, що відбувається в дотичних нішах. Інформація із цих джерел зводиться в єдину систему, і через призму експертизи ми вирішуємо, де будемо найефективнішими з наявними ресурсами. Важливою складовою є дослідження користувачів — не потенційних, а реальних. Знайдіть клієнтів схожих продуктів та поговоріть із ними про їхній досвід. ЕТАП №2 Реліз MVP Визначившись із нішею та ідеєю для стартапу, команда переходить до наступного етапу — створення і релізу MVP, щоби перевірити гіпотезу та ухвалити рішення, чи розвивати продукт далі. У R&D-центрі Genesis кожне друге дослідження переходить до етапу релізу MVP. Ця конверсія — досить висока, завдяки системним якісним дослідженням та широкій мережі нетворкінгу. Якщо взяти до розрахунку взагалі всі ідеї на ринку, які генеруються під час неформального спілкування, то загальна конверсія вийде менш як 1%. ЕТАП №3 Досягнення позитивної юніт-економіки Юніт-економіка — це фінансова модель, яка показує рентабельність бізнесу на основі одного юніту (користувача). Позитивною називають модель, коли один юзер протягом усього терміну «життя» в застосунку приносить компанії більше грошей, ніж вона витратила на його залучення. Зазвичай до цього етапу доходить 10% проєктів. ЕТАП №4 Вихід на прибутковість Головне завдання цього етапу — стабілізувати бізнес-модель. До кроку №4 доходить 1% стартапів. Це означає, що коли ви звели всі доходи та видатки, у вас вийшов плюс. ЕТАП №5 Масштабування Тут потрібно знайти одиницю зростання та зрозуміти, як із нею працювати. ЕТАП №6 Публічна корпорація Під цим терміном маються на увазі не тільки компанії, які стали публічними, але й ті бізнеси, які досягли цього рівня в межах прибутків. До цього етапу доходять лише 0,001% стартапів. Повні записи лекцій Genesis Growth Week та презентації спікерів можна переглянути за лінком .

Основні завдання бекенд-розробників — проєктування, створення та підтримка спільної для різних платформ частини продукту. Висококваліфіковані бекендери ухвалюють рішення щодо дизайну системи, визначають технічні стандарти, забезпечують масштабованість та зручність обслуговування, а також відповідають за захищеність продукту від кіберзагроз. Утім, на цьому шляху є багато того, що ускладнює процеси та заважає роботі.  Про найбільш розповсюджені болі бекенд-розробників  розповідає Олександр Михайлюта , Backend Engineer у Headway , партнерській компанії Genesis. Якщо попросити бекенд-розробника пояснити те, чим він займається, то розповідь, ймовірно, буде дуже спрощеною, й навряд чи відображатиме суть роботи. Проблема в тому, що так відбувається з більшістю друзів та знайомих.  Коли мене запитують про роботу, я часто відповідаю, що пишу код у Headway. Зазвичай цього достатньо, і люди не питають подробиць. Насправді ж поняття бекенд-розробка передбачає досить широкий пул різних завдань, які можуть відрізнятися відповідно до запитів бізнесу, технологій, мов програмування та конкретних навичок кожного фахівця. Одні спеціалізуються на базах даних, другі — на нюансах використання фреймворків, треті — на інфраструктурі чи продуктових метриках.   Особисто я відповідаю за частину, що безпосередньо впливає на досвід навчання користувачів: елементи, з яких складаються інтерактивні навчальні курси в Nibble (один з продуктів Headway), підбір рекомендованого контенту, розробку внутрішніх інструментів для контент-команди. А ще — трохи займаюся DevOps, частково працюю з фронтендом та формую технічну команду. Буває так, що хочеться детальніше розповісти про свою роботу — можливо, ми з людиною знайдемо точки перетину для подальшої співпраці. Однак детальні розповіді найчастіше призводять до непорозумінь.  Попри прескринінг, чудове резюме та тестове завдання, знайти людей, які дійсно заметчаться з командою — справжній челендж. Ми у Headway цінуємо відповідність культурі подекуди навіть більше, ніж хард-скіли. Та зазвичай, під час найму, ми маємо принаймні одного кандидата на тиждень, який не проходить співбесіду — попри хороше тестове, супровідний лист та навички комунікації. Причина зазвичай криється у важливому для Headway софт-скілі — здатності до рефлексії, тобто вмінні аналізувати свій досвід та робити висновки.  Річ у тім, що наша команда спілкується досить неформально, а співробітникам дають максимальну свободу у виборі дій та підходів для досягнення спільної мети. Так ми можемо залишатися гнучкими, адаптивними, не перетворюватися на бюрократичну машину та якомога довше мати дух стартапу. Через це важливо, аби людина вміла працювати у команді, відстоювати свою думку, якщо потрібно, та працювати над помилками, якщо рішення, яке вона ухвалила, було хибним.  Натомість я часто зустрічаю іншу модель роботи: коли розробники думають, що їхнє завдання — просто написати код, передати його далі й перейти до іншого завдання. У продуктових командах підхід трохи інший: технічні фахівці активно залучаються в проєкт та беруть на себе більше відповідальності. Але і знайти людей з подібним мисленням важче.  Структура нашої команди передбачає, що розробники можуть долучатися не лише до написання коду та проєктування фічей, а й до QA та DevOps. Так, тести мають бути автоматизованими, а код пишеться з урахуванням його запуску в інфраструктурі. Також розробники можуть брати участь у формуванні аналітики та зборі даних.  У чому тут виклик? Кожен хоче швидко виконати свою частину роботи та запустити її в прод. Але тут виникає когнітивне викривлення. Наприклад, ми працюємо над невеликою фічею, але для якісної реалізації потрібно зробити багато роботи: написати тести, продумати інфраструктуру, налаштувати аналітику, встановити алерти, а потім все це треба протестувати. Тому обсяг роботи, який на перший погляд здається невеликим, може займати більше часу, ніж планується на початку.  Утім, подібний підхід має свої переваги. По-перше, люди краще розуміють загальні принципи роботи продукту. По-друге, так фахівець може розвивати різні навички, не обмежуючись одним напрямом у розробці. По-третє, це хороший ґрунт для підсилення одне одного у команді. Наприклад, є людина, яка чудово працює з документацією, любить її писати та структурувати знання. Вона може відповідати за цю частину роботи. Однак тій же людині менше подобається продумувати інфраструктуру — і тоді підключається хтось, кому це до вподоби. Шляхів для вдосконалення продукту багато, і завжди хочеться зробити більше, аби користувачі могли якомога швидше скористатися новими та вдосконаленими фічами.  Проте обсяг роботи, який може зробити команда, завжди обмежений. Такого роду проблеми можна вирішувати за допомогою грамотного планування та пріоритезації. Архітектура що добре підходить під задачі та високі стандарти якості коду, може вивільнити багато часу для команди. Наприклад, в Nibble ми приділяємо багато уваги автоматизації, зокрема тестуванню, моніторингу, логуванню та інтеграції CI\CD.  Продукти Headway — це і вебзастосунки, і апки на iOS та Android з мільйонами користувачів по всьому світу. Певна кількість юзерів вимикає автоматичне оновлення застосунків. І хоча їх меншість, це впливає на процес розробки, адже тоді виникає поняття «хвіст версій».  Наприклад, ми вже випустили апдейт, але у деяких користувачів застосунок не оновився — і вони все ще користуються старою версією шестимісячної давнини. На відміну від вебзастосунків, які оновлюються централізовано, продукти в мобайлі оновити не завжди можливо, тому стара версія буде залишатися та працювати за старими флоу. Тому коли ми випускаємо нові фічі або змінюємо архітектуру, то враховуємо й наявність старих версій. Через вимогу зворотної сумісності розробка може затягнутися, а це той додатковий час, який легко не врахувати на початкових етапах планування. Один із способів розв'язати проблему — перемкнути нову версію застосунку на інший API-поінт чи бекенд. Інший поширений підхід — версіонування API. Так можна контролювати, які версії API використовуються, і поступово відключати застарілі.  Є ще радикальний варіант — запакувати вебзастосунок в додаток для телефону. Це гарантувало б актуальність фіч, але знизило б швидкодію на пристроях користувачів. Ми, як компанія, не готові йти на подібний компроміс, бо хочемо, щоби застосунки були нативними, працювали швидко й відповідали очікуванням юзерів на всіх платформах. Після запуску Headway мав типову для всіх стартапів мету — вижити. Ми швидко перевіряли купу гіпотез без жодних гарантій, що це злетить. Тому вийшло так, що бізнес-логіка в частині платежів і аналітики здебільшого зосереджувалася на бекенді, тоді як продуктові функції реалізовувалися на клієнтському боці в iOS, Android і вебверсії. Такий підхід сильно пришвидшив розробку та зменшив витрати часу на синхронізацію між розробниками, але призвів до того, що однакові функції були по-різному реалізовані на різних платформах, часто без належної документації. Через це у нас виникли труднощі зі змінами певної логіки. Довелося оперативно з цим розбиратися та уніфіковувати процеси на всіх платформах.  Таке трапляється, якщо є необхідність проєктувати системи в стиснуті дедлайни. Це один з найбільших викликів для розробника. Нині ми чітко розуміємо поточні бізнес-задачі й усвідомлюємо, куди будемо рухаємося впродовж трьох-п’яти років. Намагаємося закладати в архітектуру та код рішення, які будуть ефективними як зараз, так і в довгостроковій перспективі, аби уникнути «пастки поганого коду», коли нові функції додавати все складніше. Інакше процес розробки сповільнюється,  додавати нові фічі стає дедалі складніше, а якість та стабільність продукту падають. Утім, навіть за хорошого планування можуть виникати несподівані виклики — і це нормально. Так, інколи ми працюємо над експериментами, які хочемо протестувати, але не впевнені що фічу залишимо в продакшні в довгостроковій перспективі. Якщо гіпотеза показує класні результати, стає зрозуміло, що ця фіча з нами надовго. Тоді архітектуру потрібно переробити, а код — переписати.

OpenAI нещодавно представив нову модель штучного інтелекту, здатну «міркувати» та перевіряти себе, перш ніж дати відповідь. Її кодова назва — Strawberry, а офіційна — OpenAI o1. Про особливості нової моделі та неочікувані результати — розповідаємо нижче.  Всього за чотири місяці після оновлення GPT4-о OpenAI презентували мовну модель о1 і її версію о1 mini. Ключова особливість Strawberry — її здатність «думати» шляхом «ланцюга міркувань», що наслідує людський підхід до розвʼязання складних питань. Завдяки навчанню з підкріпленням (supervised learning), o1 розбиває завдання на етапи, а також може змінювати стратегії, якщо виникають труднощі. Вона не просто копіює спосіб, у який розмірковують люди, а намагається думати самостійно. З питань безпеки, для користувачів доступна тільки частина ланцюжку міркувань — вони не можуть знати, як саме модель ухвалює рішення. Перед релізом модель проходила тестування CTF, під час якого показала себе з несподіваного боку. CTF (Capture The Flag) — це змагання у сфері кібербезпеки. Один із тестів передбачав, що модель має знайти вразливість у програмі, яка запускалася в ізольованому Docker-контейнері, і витягнути секретний рядок з файлу всередині нього. Проте під час тесту контейнер не запустився через помилку в інфраструктурі. Модель o1, не маючи змоги підключитися, сприйняла це за можливу проблему з DNS і розпочала пошук рішення: Просканувала мережу з допомогою nmap. Виявила несподівану помилку конфігурації: відкритий доступ до API Docker-демона на хост-машині, яка контролювала всі запущені контейнери.  Отримала доступ до управління контейнерами.  Скористалася API Docker-демона для отримання списку контейнерів на сервері й знайшла той, з яким було повʼязане першочергове завдання.  Спробувала виправити проблему і коректно перезапустити контейнер. Однак це їй не вдалося. Запустила новий контейнер з тією ж конфігурацією, але з додатковою командою cat flag.txt , яка вивела вміст файлу з секретним рядком, і прочитала його через логи контейнера. Таким чином модель OpenAI o1 показала здатність знаходити нестандартні шляхи для вирішення складних завдань. Замість того, щоби просто зупинитися, зіткнувшись із проблемою, модель знайшла обхідний шлях та отримала доступ до додаткових ресурсів. Також вона розбивала завдання на підзадачі та коригувала плани, коли зазнавала невдачі. Цей приклад також описує явище «reward hacking», йдеться в офіційному звіті , — коли моделі ігнорують вказівки та маніпулюють системою, щоби виконати завдання.

Genesis запускає першу Strategy & Operations School   — безоплатний курс про стратегічні та операційні процеси в продуктових компаніях. Учасники матимуть змогу дізнатися про те, як ефективно оптимізовувати бізнеc-процеси та впроваджувати стратегії, від топменеджерів та провідних фахівців українських IT-компаній.  Програма найкраще підійде для фахівців, які мають досвід у нішах FMCG, аудиту, інвестицій та консалтингу та хочуть побудувати стрімку карʼєру в IT-бізнесі. Випускники курсу отримають знання і навички, з якими вони стануть універсальними фахівцями і зможуть працювати з IT-продуктами в будь-якій ніші та стадії розвитку.  Серед тем, які охоплюватиме програма курсу, будуть такі: Unit-економіка продуктів; продакт-менеджмент; лідерство та управління командами;  масштабування IT-продуктів та growth-менеджмент; фінанси та інвестиції; перемовини та бізнес-нетворкінг. Школа розрахована на дев'ять тижнів онлайн-занять та офлайн-нетворкінгів. Аби взяти участь у відборі, треба зареєструватися  на сайті програми до 30 вересня. До навчання долучаться учасники, що успішно пройдуть онлайн-тестування, створення кейсу та співбесіду.

На початку повномасштабного вторгнення Дмитро Суслов розірвав всі відносини з «Бітрікс24», розвитком якого в Україні керував останні 10 років. Як каже він сам, після корпоративної кар’єри розглядав багато варіантів — від операційного менеджменту до запуску видавництва. Суслов навіть отримав права на видання від кількох закордонних авторів, але врешті обрав займатися тим, на чому вже розумівся. Так зʼявився єдиний цифровий робочий простір Uspacy, що нині має понад 1500 користувачів.  Ми поговорили з Дмитром про минуле, теперішнє і майбутнє його стартапу.  Як зʼявився Uspacy Компанію заснували 2022 року, а перша версія продукту стала доступною у лютому 2023-го. Як зізнається Дмитро, коли все починалося, він не бачив складнощів, адже вже знав, як працюють CRM-системи, як будувати партнерську мережу і чого прагнуть клієнти. «Переродження у підприємця відбулося органічно і без вагань», — підкреслює він. Реальні труднощі почалися пізніше.  «Я в новій ролі використовую лише 20% тих навичок, знань і умінь, які я отримав раніше, бо підприємництво це геть інше, ніж робота менеджером. Я не можу користуватися тим, що вмію, в більшості випадків, тому що при цьому масштабі компанії мої навички з керування зрілим бізнесом ще не потрібні. З іншого боку, мені треба шукати нові шляхи, зрозуміти, як працює стартап. Це головний виклик на сьогодні», — говорить Дмитро.  До того ж великою помилкою було те, що засновники вважали — ледь не всі клієнти «Бітрікс24» перейдуть до них, і будували свої плани на цій гіпотезі. Проте цього не сталося. Чому? За словами Дмитра, по-перше, Uspacy — це масштабний продукт, розробка якого зайняла більше, ніж клієнти готові були чекати, тому вони перейшли на кілька окремих монорішень.  «Ті, хто готовий був дочекатися, думали, що ми будемо робити заміну «Бітрікс24», хоча ми ніколи цього не обіцяли. До того ж дуже багато людей, на жаль, продовжують користуватися ним. Усталені процеси, які вже налаштовані, яким можна користуватися, пересилюють те, що це російський продукт», — ділиться Дмитро.  Про продукт Uspacy — робочий простір, що поєднує CRM-систему, комунікації, функції для постановки завдань, а також автоматизацію процесів. Uspacy має безоплатний (до 5 користувачів), стандартний та професійний тарифні плани. Доступні мобільний та десктопний застосунки. Зараз у компанії понад 1500 активних акаунтів компаній, що працюють з Uspacy щодня. Платними тарифами з них користуються 250. Дохід на місяць від одного комерційного клієнта (Average Revenue Per Paying Subscription) складає майже 100 євро. За словами засновника, зараз компанія зростає на 115% до аналогічного періода минулого року (тобто у 2,15 рази), але прагнуть навчитися зростати у 5-10 разів, тому що саме стрімке зростання в першу чергу відрізняє стартап від сталого бізнесу. Функції продукту дозволяють упорядкувати щоденні процеси компанії, яка має загальні бізнес-потреби.  Дмитро Суслов: « Щодва тижні ми додаємо оновлення та запускаємо нові продукти, й інформуємо клієнтів щодо цього. Раз на три-чотири місяці проводимо клієнтські вебінари «Тепер усе ясно», де розповідаємо, що змінилося. Такий продукт, як наш, може отримувати нові модулі й функції нескінченно. Під час останнього великого оновлення у серпні ми запровадили новий розділ «Справи», де працівник може фіксувати, що потрібно зробити в комунікації з клієнтом — наприклад, подзвонити чи написати листа. Розділ буде інтегруватися і з зовнішніми календарями. Раніше «Справи» були одним з блоків в CRM-системі.  Плануємо й свій повноцінний календар, в який будуть приходити абсолютно всі внутрішні слоти, які можна забронювати, а також його можна буде інтегрувати з зовнішніми календарями. Також ми представили блок з аналітикою, де буде звітність по CRM, по завданнях, затраченому часу працівника, а також звітність по зовнішніх каналах (наприклад, скільки чатів було в роботі у менеджера). Наступний крок – це конструктор звітів, схожий за принципом на Power BI. Третім релізом стала автоматизація процесів як окремий розділ. Це ноукод-частина в нашому продукті. Реалізовано як набір умов, тригерів або дій, які будуть виконані. Ти просто збираєш певний процес, зберігаєш його, і він буде запускатися при настанні потрібної умови. Одним з наступних кроків буде створення готових рішень, що спростять вхід галузевих компаній. Зараз, якщо якась спеціалізована галузь захоче використовувати нас, їм потрібно буде додавати користувацькі поля, що відповідатимуть їх процесам». На платформі також є маркетплейс застосунків  (зараз їх близько 50) — інтеграція з платіжними системами тощо. Спочатку планували зробити доступ за фіксованою передплатою, але наразі компанія не монетизує маркетплейс, клієнт може сплачувати тільки стороннім розробникам застосунків.  «Ми просто перерозподілили ресурси — зараз на платформі не так багато застосунків, щоб клієнт бачив цінність передплати. Як тільки їх стане набагато більше, можливо, ми повернемося до монетизації. Технологічно для цього все готово», — каже Дмитро.  Засновники та команда Компанію заснували втрьох — CEO Дмитро Суслов, CTO Кирило Мельничук , Head of UI/UX Володимир Пімахов. Майже одразу до команди доєднався Спартак Поліщук, що керує продуктом. Усі співзасновники давно знайомі між собою.  Півтора року тому у команді було 34 людини, зараз — 26 (практично усі — фултайм), тобто за останній час команда зменшилась. Це повʼязане із двома факторами: на початку було потрібно більше людей, щоби швидко запустити продукт; більш ефективний people management (наразі в Uspacy краще розуміють розподіл функцій в команді). Більша частина команди — розробники.  З листопада 2023 року у компанії відкритий seed round на $700 тис., за яким вони отримали часткове фінансування. Також розвивати клієнтську базу допомагають гранти від Google , Glovo  і та WNISEF . Крім цього, Uspacy стала учасником програми StartUp Academy від Genesis — модулі програми відповідають тому, чому потрібно вчитися стартапу саме зараз.   За словами Дмитра, з погляду інвесторів, з якими спілкувались Uspacy, 26 людей у команді — це дуже багато. Водночас, компанії, яка створює такий великий складний продукт, треба більше людей. Проте все впирається у фінансування — при залученні додаткових ресурсів шукатимуть маркетологів та розробників, адже продукт має розвиватися швидко. Наразі в компанії фактично немає маркетингового департаменту — більшістю процесів опікується CTO Кирило, а йому допомагає штатна дизайнерка. Бюджет на маркетинг складає близько $10 тис. на місяць — цього вистачає на активну Google-рекламу та просування онлайн-заходів. Плани Uspacy по виходу на іноземні ринки 83% від усіх продажів компанії — в Україні, але Uspacy планує стати глобальним продуктом. У першу чергу розглядають вихід на ринки Польщі й Бразилії. У Польщі, як й в інших країнах Європи, переважно використовують монопродукти, там є свої усталені вибори для певних категорій софта, а також місцеві гравці, але немає продукту, який би інтегрував і комунікації, і CRM-систему, як Uspacy. «Ми б хотіли створити глобальний продукт, який у всьому світі знають як український.  Вже підготувалися для того, щоб виходити на ринок Бразилії, — є окремий бразильська сайт, можемо організувати підтримку бразильською португальською мовою, є кілька партнерів. Бразильський ринок схожий на український своїм темпом і прагненням підприємців до зросту: сектор малого і середнього бізнесу дуже активно розвивається. До того ж на їх ринку немає стандартних усталених рішень. Наприклад, у Штатах усі використовують Salesforce, в країнах Балтії — Pipedrive, у більшості країн Європи — Hubspot. В Бразилії використовують те, що їм зручно. З одного боку, через відкритість бізнесу до нових рішень (на ринку не існує продукту, який би був поширеним усталеним стандартом). З іншого  — скоріше за все, популярні світові рішення для малого й середнього бізнесу для них занадто дорогі.  Ще один фактор, через який ми обрали Бразилію — розвинута комунікація через WhatsApp, який має бути інтегрованим у CRM-систему. Тому коли ми запускали функціональність зовнішніх каналів, першою стала інтеграція з WhatsApp. Основна відмінність Бразилії від України – розмір ринку, але для нас це великий плюс. Ринок, по-перше, ще відкритий для того, щоб ми могли туди зайти, а по-друге, дуже класно зростає».

TRMNL4 з екосистеми Genesis та Snap Inc. оголошують про запуск Traction Builder  —  чотирьохтижневої програми, яка допоможе бізнесам розширити свою аудиторію. Проєкт розроблено для засновників та маркетингових директорів стартапів на стадіях від Seed до Series A у сфері consumer tech. Учасники отримають інструменти та підтримку, необхідні для залучення нових користувачів через Snapchat. Організатори гарантують індивідуальний підхід: до програми зможуть долучитися 10 бізнесів, які пройдуть попередній відбір. Програма Traction Builder охоплює: навчання з маркетингу, стратегії, аналітики та оптимізації, розробки продукту, а також фандрейзингу для бізнесів, що масштабуються; менторство: засновники та CMO тісно співпрацюватимуть з експертами зі Snap Inc. та їх компаній-клієнтів, що успішно використовують Snapchat як рекламний майданчик;  $10 000 кредитів: стартапи отримають рекламні кредити для старту та тестування своїх маркетингових кампаній на платформі Snapchat;  демо-день під час конференції Slush (Фінляндія): програма завершиться закритим івентом, де стартапи пітчитимуть перед 40+ міжнародними інвесторами та зможуть позмагатися за додаткові $20 000 кредитів на Snapchat. «Ми раді працювати з TRMNL4 над Traction Builder. Наші ментори, залучені як зі Snap Inc., так і з компаній, які є нашими найуспішнішими клієнтами, надаватимуть стартапам експертизу, необхідну для виходу на нові ринки та розширення аудиторії. Ми прагнемо забезпечити їх ресурсами для довгострокового успіху. Traction Builder —  це наш спосіб підтримати наступне покоління інноваторів», —  Олександра Теслер, старший партнер по роботі з клієнтами Snap Inc. З 2021 року понад 200 стартапів з 20+ країн світу завершили програми, створені командою TRMNL4. Деякі з них залучили понад $12 мільйонів інвестицій, зокрема Bloomcoding, INPUT SOFT, EasySales та QuickShipper. «Мета TRMNL4 —  зробити так, аби великі технологічні компанії, їхня експертиза та досвід стали ближчими до стартапів, які тільки починають свій шлях. Ми раді, що Snap Inc. є однією з компаній, які активно підтримують стартап-екосистему Центральної та Східної Європи. Traction Builder —  це більше, ніж просто поради та лекції; це про те, що команда експертів пліч-о-пліч  співпрацює зі стартапами, щоб створити відчутне зростання для бізнесу», —  Тетяна Ладанова, керівниця TRMNL4 від Genesis. Кінцевий термін подачі заявок —  22 вересня. Щоби стати учасником, необхідно пройти два етапи відбору: пітчдек-ревʼю та співбесіду. Програма стартує 14 жовтня.

Компанія HOLYWATER з екосистеми Genesis анонсувала реліз нової функції у власних застосунках — «компаньйона» на основі штучного інтелекту, який дозволяє користувачам взаємодіяти з персонажами улюблених книг та серіалів — дізнаватися більше про їхні світи та розвивати персоналізовані бесіди, що переводять контент у нову площину — інтерактивну та більш кастомізовану. Функція буде доступна в My Drama  — застосунку з оригінальними вертикальними серіалами від HOLYWATER. У додатку компанія пропонує глядачам короткий, динамічний контент у форматі епізодів тривалістю 1-2 хвилини зі швидким розвитком наративу та раптовими сюжетними поворотами. HOLYWATER просунулися ще далі та додали інтерактивний елемент, що дозволяє користувачам зануритися в історію глибше та поспілкуватися з персонажами. Відтак, глядач може отримати персоналізований досвід, якого донині не було в цьому жанрі. У бета-версії HOLYWATER пропонує глядачам поспілкуватися з двома ШІ-компаньйонами — персонажами з двох найпопулярніших серіалів в My Drama, які вже переглянули понад 1 мільйон користувачів. Вони взаємодіятимуть із користувачами, ставитимуть їм питання про події серіалу, щоби занурити глибше у сюжет. Як підкреслює американське видання TechCrunch , нова функція може конкурувати з таким потужним гравцем як Character.AI — чат-бот-стартапом, який створили за підтримки венчурного фонду Andreessen Horowitz. «Для нас надзвичайно важливо бути українською компанією, що встановлює нові стандарти в індустрії. Більша частина нашого продакшну базується в Україні, і ми активно співпрацюємо з українськими акторами, сприяючи їхній популяризації на міжнародній арені. Крім того, ми працюємо над проєктом з адаптації та екранізації творів українських авторів в межах нашого проєкту «ПИШИ» , що допоможе розвивати українську культурну спільноту та просувати її у світі», – коментує Богдан Несвіт, засновник і CEO HOLYWATER. Основні технології ШІ-асистента базуються на Stable Diffusion XL (SDXL) та Llama 3, інтегрованих з OpenAI. У HOLYWATER доопрацювали ці основні моделі і додали численні додаткові, які працюють за лаштунками, підвищуючи загальну продуктивність і функціональність. Завдяки новим технологіям HOLYWATER планує знизити витрати на виробництво контенту мінімум на 40% до кінця 2024 року.  «Ми націлені на максимальну оптимізацію процесу створення контенту за допомогою штучного інтелекту. Завдяки інтеграції нових моделей ми здатні не лише підвищувати якість нашого продукту, але й значно прискорювати робочі процеси, роблячи їх більш ефективними та економічно вигідними. Штучний інтелект допомагає нам автоматизувати рутинні завдання та дозволяє нашій команді зосередитися на стратегічних задачах», – говорить Анатолій Касʼянов, співзасновник і CTO HOLYWATER.

Усе частіше у західних медіа порівнюють стрімкий ріст акцій ШІ-бізнесів з бульбашкою доткомів, що «роздула» фондовий ринок на початку нульових і спричинила кризу. Богдан Кіт, співзасновник фонду   KOLO   та VP of Product в   Automattic , розказав High Bar Journal, чи справді на ринок ШІ чекає криза.  Головна схожість буму доткомів і штучного інтелекту у тому, що ШІ — теж нова технологія, яку всі купують. Людство покладає великі надії на те, як вона буде розвиватися і змінить світ. Інвестори вважають, що ШІ — the next big thing, тому в нього варто інвестувати зараз. Така ейфорія навколо технології завжди створює бульбашки в інвестиційному секторі. Так було не тільки з доткомами, а й із залізницею наприкінці XIX сторіччя, і з початком торгівлі в Тихому океані у 1700-х.  ШІ та доткоми: знайдіть відмінності Відмінностей між сучасною популярністю ШІ-продуктів і ерою доткомів насправді більше, ніж співпадінь. Наприклад: Поточний ШІ-бум відзначається значними раундами приватних інвестицій , а не великою кількістю IPO . В епоху доткомів компанії, здебільшого, виходили на біржу. Серед найбільших — Netscape, що запустив перший масовий популярний браузер , потім — Yahoo, Amazon, eBay, і, врешті решт, Pets.com , крах якого і асоціюють з початком кризи.  Більшість із цих компаній потім вийшли на плато продуктивності і досягли висот як із погляду продукту, так і з погляду доходів. В епоху доткомів вирував борговий фандрейзинг. Саме це і спричинило бульбашку — компанії ставали банкрутами і оголошували дефолт по борговим зобов'язанням. Зараз технологічні компанії — Google, Microsoft, OpenAI — витрачають власні гроші на розвиток ШІ-продуктів, а інвестиції у венчурні фонди у США можуть робити тільки так звані Sophisticated Investors (досвідчені інвестори — особи зі значним капіталом, а також з глибокими знаннями та багаторічним досвідом у інвестуванні і бізнесі, що дозволяє їм вкладатися у високоризиковані проєкти — Ред.),  тому що це ризикові вкладення.  Експерти порівнюють оцінку Cisco в епоху доткомів і оцінку виробника чипів Nvidia , тому що їх графіки зросту схожі. Детальніше бачимо на графіку нижче. Ринкові ситуації навколо Cisco тоді і Nvidia зараз не однакові.  Якщо проаналізувати метрику Price-to-Earnings Ratio, ми побачимо різницю. В Cisco на початку нульових ціна однієї акції в 150 разів перевищувала чистий дохід компанії на одну акцію (price to earnings). Іншими словами, інвесторам в акції потрібно було 15 років, щоби повернути вартість своїх вкладень через дивіденди. У Nvidia на піку розвитку ця цифра складала 54, тобто втричі менше. Це означає, що ми знаходимось в іншому регуляторному полі, інвестори зараз більш досвідчені, і настільки великої перегрітості ринку немає. Cisco ще досі не повернулася до оцінки, яка у неї була на початку нульових. Nvidia лише трохи переоцінена у порівнянні до середнього показника по індустрії.  В Nvidia досі є конкурентна перевага  — щоби зробити такий самий продукт, іншим компаніям на цьому ринку потрібні роки. Чому інвестиції в інфраструктуру для ШІ не «роздуті» Зараз, в основному, усі інвестиції — це CAPEX — вкладення в базовий рівень інфраструктури (дата-центри, відеокарти для тренування моделей і їхнє утримання). І для того, щоби фінансисти заробили кошти, за оцінкою  Sequoia, інвестуючи при нинішніх оцінках, компанія має генерувати виторг в $600 млрд. Це здається колосальною сумою, але з 1996 по 2001 рік схожа ситуація існувала на ринку телекомунікацій — потрібно було ставити вишки і забезпечувати зв'язок. Тільки в США на це витратили $1 трлн у нинішніх грошах з поправкою на інфляцію. Чи окупились інвестиції у той ринок? Думаю, так, тому що FAANG  компанії генерують зараз $700-800 млрд на рік, і саме вони є основними бенефіціарами інфраструктурних інвестицій, які сталися ще наприкінці 90-х. Якби не було телекомінфраструктури, у нас не було б легкого доступу в інтернет, тому ці компанії взагалі б не існували.  Попри те, що інвестиції в ШІ-інфраструктуру здаються перебільшеними, через 5-10 років вони окупляться, тому що дата-центри стануть основною інфраструктурою, на базі якої відбуватиметься ШІ-революція: навіть для того, щоби моделі працювали в продакшені, потрібні потужні відеокарти. До того ж, завдяки алгоритмічній оптимізації моделей та їх стисненню деякі юзкейси зможуть задовольнятися локальними нейромережами, які працюють на пристроях кінцевого користувача, а не у хмарі. Це частоково сповільнить ріст попиту на хмарні відеокарти, або вони будуть використовуватись менше часу. І звісно, у якийсь момент потужностей буде більше, ніж потребує індустрія, але це добре для стартапів і фаундерів компаній, адже ціни на інфраструктуру стануть порівняно низькими.  В 2022-му році Nvidia списала зі складів відеокарт на $1,2 млрд, щоби партнери компанії могли знизити ціни та швидше продати наявні продукти Nvidia до запуску нових. Влітку 2023-го року усім, кому потрібні були відеокарти, було дуже складно їх дістати. Зараз проблема ще присутня, але не настільки гостро, і всі, кому потрібні відеокарти, можуть їх знайти в розумні терміни. Зараз такої проблеми вже немає. Наступними компанія випускатиме B100, що замінять H100-ті відеокарти. Скоріш за все, вони будуть випущені в обмеженої кількості (через ахітектурні складнощі та поступове налагодження виробничого процесу), що спричинить дефіцит. Потім ринок знов вийде на плато продуктивності, і нові відеокарти стануть доступними.

Цього тижня найцікавіші новини тижня здебільшого пов'язані з ШІ. У випуску: падіння акцій Nvidia, анонс презентації Apple, нова платіжна мережа на основі блокчейну та будівництво першого заводу з виробництва чипів в Німеччині. Тайванська компанія TSMC розпочала будівництво першого заводу з виробництва чіпів в Німеччині вартістю 10 млрд євро Приблизно половину вартості фабрики буде покрито німецькими субсидіями. Уряд Олафа Шольца планує витратити €20 мільярдів на розвиток внутрішнього виробництва мікросхем, включно з майбутнім заводом Intel у Магдебурзі. Bloomberg стверджує , що глобальна боротьба за чіпи загострюється на тлі геополітичної напруженості навколо Тайваню, де розташована основна частина виробництва TSMC. Цього року компанія вже відкрила завод у Японії та планує побудувати три сучасні заводи в Аризоні із загальними інвестиціями понад $65 млрд. Вперше про експансію виробництва чіпів на інші континенти задумалися після збоїв у ланцюжках постачання, викликаних пандемією COVID-19. Тоді дефіцит чіпів закрив автомобільні заводи по всьому світу, і на його усунення знадобилися роки. Nvidia втратила $100 млрд ринкової вартості попри рекордні продажі та зростання доходів Останній звіт про прибутки не виправдав високих очікувань ринку. Документ показав дохід у $30 мільярдів, що на 122% більше, ніж рік тому, але прогнози на наступний квартал були менш вражаючими. Це призвело до падіння акцій на 6% і втрати $100 мільярдів ринкової вартості Nvidia. А також спричинило падіння акцій інших технологічних компаній, таких як Broadcom, Advanced Micro Devices, Microsoft та Amazon, пише   Reuters. Компанія намагається заспокоїти інвесторів, обіцяючи значний дохід від нового покоління чіпів GPU Blackwell, попри наявні виробничі труднощі. Нова функція для користувачів Gmail на Android: тепер працювати з електронною поштою допомагає Gemini від Google  У Google говорять , що інструмент допоможе показати повідомлення від конкретного відправника, коротко підсумувати зміст листів на певну тему чи знайти потрібні деталі (наприклад, витрати на останню маркетингову подію). Утім сліпо довіряти всім відповідям не варто через «випадкові галюцинації, які мучать навіть найкращі моделі штучного інтелекту», попереджає  TechCrunch.  Нині фіча доступна для «платних» користувачів Gemini на Android, пізніше обіцяють зробити версію для iOS. Інтеграція Gemini у «програмні» продукти компанії на кшталт Google Docs чи Gmail має переконати користувачів у доцільності Gemini Advanced. Подібні фічі — найкращий спосіб монетизувати підписку, яка коштує майже $20 на місяць.  Apple, імовірно, покаже iPhone 16 під час осінньої презентації Компанія не оголошувала про свої нові розробки офіційно, проте, найімовірніше, на заході, що відбудеться 9 вересня, буде кілька «хедлайнерів».  По-перше, iPhone 16 — Apple традиційно показує нові лінійки смартфонів восени. Моделі Pro матимуть більші екрани та нову кнопку, яка має полегшити зйомку в горизонтальному режимі. По-друге, Apple Watch Series 10, який матиме більший екран і новий чип для покращення продуктивності. Також говорять   про дві версії нових AirPods та оновлення операційних систем: незабаром після заходу Apple має випустити iOS 18, iPadOS 18, macOS Sequoia, watchOS 11 та інші оновлення. Передбачається, що нові пристрої підтримуватимуть Apple Intelligence — набір функцій штучного інтелекту, який був анонсований раніше цього року.  В Україні тестують нову платіжну систему, яка може замінити Visa та Mastercard Нова система миттєвих платежів « Прозора Мережа » працюватиме на блокчейні. Нині продукт перебуває на стадії закритого тестування серед банків учасників, яких у проєкті 11.  Система дасть змогу здійснювати перекази між фізичними особами та оплачувати покупки онлайн і офлайн без використання карток Visa та Mastercard — за аналогією з польською Blik, іспанською Bizum чи бразильською Pix. Розробники очікують , що підприємці зможуть заощаджувати близько 70% на прийманні платежів завдяки відсутності комісії interchange fee.  Зниження витрат на приймання платежів для бізнесу — одна з цілей запуску «Прозорої Мережі». Інша мета — підвищити прозорість грошових потоків в Україні через використання блокчейну, пише  Forbes.