Speaker A
Всім привіт. Вітаємо вас на марафоні IT-технологій від компанії EPAM. Мене звуть Єгор Божок. Я один з організаторів цього проекту.
Вступна сесія марафону IT-технологій від EPAM про вимоги до ПЗ у Scrum та можливості навчання в EPAM Campus.
Key Takeaways
- EPAM пропонує безкоштовні навчальні програми для різних категорій учасників.
- Марафон охоплює повний цикл розробки ПЗ від бізнес-аналізу до імплементації.
- Учасники можуть обирати рівень залучення відповідно до своїх знань та можливостей.
- Практика та домашні завдання допомагають краще засвоїти матеріал і отримати фідбек.
- Програма підтримується активною комунікацією через YouTube та Telegram.
What the video covers
- Вітання учасників марафону IT-технологій від EPAM та перевірка зв’язку.
- Огляд компанії EPAM, її історії, масштабів та ролі в українському IT-ринку.
- Представлення EPAM Campus — безкоштовних навчальних програм для студентів, викладачів, ветеранів та інших аудиторій.
- Опис основних напрямів навчання: бізнес-аналіз, Java, .NET, фронтенд, DevOps, тестування тощо.
- Організаційна інформація про формат марафону, розклад воркшопів, платформи та Telegram-канал для комунікації.
- Пояснення структури програми: від бізнес-аналізу до імплементації, з можливістю вибору рівня участі.
- Наголос на практичній складовій та домашніх завданнях з фідбеком у Telegram.
- Інформація про дипломи за різні рівні участі та призи для найкращих проєктів.
- Підкреслення важливості бажання та часу для успішного проходження марафону.
- Загальний огляд майбутніх тем, включно з використанням штучного інтелекту для написання User Story.
Chapters
- 00:00Вітання та вступна інформація про марафон
- 06:40Історія та масштаби компанії EPAM
- 12:40EPAM Campus і цільові аудиторії навчальних програм
- 18:20Основні напрямки навчання та кар’єрні можливості
- 25:40Організаційні деталі марафону та формат проведення
- 39:00Структура програми та рівні участі
- 57:00Практична складова, домашні завдання та комунікація
- 69:00Використання штучного інтелекту у бізнес-аналізі та User Story
Full Transcript — Download SRT & Markdown
Speaker A
Я пропоную для початку зрозуміти, чи нас видно та чутно. Мені здається, така якась невелика ехо.
Speaker A
Тому, ласка, зараз давайте перевіримо зв'язок. Напишіть, будь ласка, в чаті, з якого ви міста, щоб ми зрозуміли, що все в нас добре, яка в нас взагалі географія наших учасників. Поки що не бачу ще чатику.
Speaker A
Давайте почекаємо трошки, щоб ми впевнились, що все добре і будемо потроху починати. Так. Одну хвилиночку.
Speaker A
В нас може бути невелика затримка, оскільки це там є стрімінгова платформа. Тому давайте, давайте почекаємо і будемо потроху починати.
Speaker A
Бачу, що в нас вже більше півтори, ой, півтори, 500 учасників на подію. І тоді пропоную, напевно, потроху починати.
Speaker A
Для початку давайте ми розкажемо вам загалом про програму, так, що ми будемо робити, які в нас є степи основні і, по можливості, надамо відповідь на ті питання, які у вас можуть бути в ході цієї програми.
Speaker A
Отож бо, спочатку ми, звісно, трохи розкажемо про компанію EPAM, про ті можливості, які є зараз у нас для молоді і потім пройдемо більш до організаційних питань саме стосовно цього проекту, бо можливо хтось зараз взагалі долучився з Ютубу до нас і взагалі не зовсім
Speaker A
розуміє, що тут буде відбуватись і трошки дамо там контексту. Ну і потім вже перейдемо до нашої такої першої зустрічі. Познайомимось напрямом бізнес-аналізу. Ну і відповідно відповімо на ваші питання і після того ще й дамо вам ваше перше домашнє
Speaker A
завдання в рамках цього проекту. Тому давайте потроху починати. Єдине, я чомусь, відверто скажу, так і не бачу чатику, тому зараз, певно, ще з телефону це відкрию.
Speaker A
Ну, давайте тоді стосовно компанії, так, яка організовує цей проект. Це компанія EPAM. Ми є найбільшою в Україні IT-компанією, яка має дуже велику історію як глобальна компанія, так, бо ми були засновані в 1993 році.
Speaker A
Зараз у нас понад 62 тисячі співробітників більш ніж у 55 країнах світу і якщо говорити про компанію саме українську, то компанія була заснована саме ось в Україні, філія відкрита в 2005 році.
Speaker A
В тому році компанії виповнювалося 20 років. І це така дуже значна дата була для нас, і ми святкували всією компанією, і на даний момент в нас в українській саме локації більше 9,5 тис. співробітників, що доволі крутий результат, так і
Speaker A
компанія продовжує розвиватись та будувати український IT-ринок. Якщо говорити про компанію, то дуже важливо згадати про такий підбренд компанії, який називається EPAM Campus, який організовує цю подію, який надає можливість молоді, свічерам побудувати свою кар'єру в IT,
Speaker A
надає безкоштовні навчальні програми, за якими і до яких можна долучитись і побудувати свою кар'єру разом з компанією EPAM.
Speaker A
А взагалі в нас є декілька таких цільових аудиторій, для яких ми робимо різні проекти, ініціативи.
Speaker A
А в першу чергу це є, звісно, студенти, випускники коледжів та університетів, які мають можливість долучитись до навчальних програм і потім побудувати свою кар'єру разом з компанією.
Speaker A
А це, звісно, є викладачі, тому що ми дуже тісно співпрацюємо з університетами, а для того, щоб якомога більше підтримувати українську IT-освіту і відповідно збільшувати ось таку конкурентоспроможність наших кандидатів, так, на IT-ринку.
Speaker A
А відповідно, це, звісно, свічери, так, бо IT — це той напрям, де ви можете розвиватись незалежно від вашого віку.
Speaker A
А і, відповідно, це там випускники шкіл для того, щоб випускники більш усвідомлено обрали навчальні заклади і будували свою кар'єру. І вже як кілька років поспіль це, звісно, для нас є ветерани, тому що ми маємо
Speaker A
навчальні програми IT для ветеранів і відповідно це той напрям, який ми продовжуємо підтримувати і надавати також можливості в освіті.
Speaker A
Е, для перекваліфікації, для тих, хто того хоче. А загалом, ще раз повторюсь, всі навчальні програми від EPAM Campus є безкоштовними. Перший та другий етапи є в такому self-paced форматі. Відповідно вже там спеціалізація та fundamentals — це
Speaker A
вже такі більш поглиблені навчальні програми, там може бути груповий менторинг, це можуть бути окремі зустрічі, лекції, там в залежності від формату за дуже великою кількістю напрямків. Загалом, якщо говорити про основні напрями, за якими ви можете
Speaker A
побудувати свою кар'єру, так, в EPAMі, то це, напевно, майже всі напрями, які в нас в тому числі покриті в рамках марафону. Це і бізнес-аналіз, це і Java, це .NET, це фронтенд, звісно, DevOps, тестувальники, як мануальні, так
Speaker A
і автоматизовані. За цими напрямами ви можете долучитись на різні програми, ну і потім після цього вже долучитись до компанії і побудувати свою кар'єру. Тому, якщо ви зараз бажаєте долучитись до якоїсь ініціативи, то це
Speaker A
на це вас завжди буде можливість. Так, тепер давайте перейдемо до організаційної інформації саме стосовно програми.
Speaker A
По-перше, ви вже бачили, що в нас наступні два тижні буде. Будуть відбуватись воркшопи. На що хочу звернути вашу увагу на те, що завтрашня лекція через певні
Speaker A
причини буде... Ой, так, секунду, секунду. А там вона буде в нас о 16:00 і так, ми про це напишемо на 1 годину пізніше. Після того в нас всі зустрічі, якщо не буде форс-мажору, будуть проходити о 17:00.
Speaker A
Стосовно взагалі цього проекту, так, що ми будемо робити, яка основна наша ціль?
Speaker A
Першочергово це показати і надати можливість спробувати різні напрями і зрозуміти повний цикл розробки застосунку від ідеї до реалізації.
Speaker A
Відповідно, ми почнемо з вами з дизайну, з бізнес-аналізу, точніше, спочатку з бізнес-аналізу, потім там дизайн, архітектура,
Speaker A
бекенд, фронтенд і відповідно ось повний цикл ми з вами пройдемо в рамках цього проекту.
Speaker A
Одразу скажу і зроблю на це акцент, що програма побудована таким чином, що ви зможете
Speaker A
обрати, на якому рівні ви хочете проходити цей проект. Ви можете просто прослухати воркшопи і потім скласти фінальний тест, отримати там диплом про завершення. Відповідно, якщо у вас немає технічного бекграунду, відповідно, та інформація, яку ми будемо давати на
Speaker A
зустрічах, вам буде більш ніж достатньо. Ну і відповідно, є ще там два рівні: один — це треба ще розгорнути застосунок,
Speaker A
а третій рівень — ще імплементувати певний функціонал.
Speaker A
Тому не переймайтесь, якщо ви думаєте, що у вас щось не вийде, у вас все вийде.
Speaker A
Головне від вас — це бажання, час, ну і відповідно брати той напрям, в якому вам було б більш комфортно працювати.
Speaker A
Ну і дуже важлива частина — це практика в реальних напрямах, так, що це будуть не суто якісь теоретичні зустрічі, а ще й з практичною складовою, яка допоможе вам зрозуміти, в якому напрямку ви захочете розвиватись в подальшому. І це дуже важливо. І
Speaker A
після більшості зустрічей у вас будуть ще домашні завдання, після яких ми будемо давати узагальнений фідбек в Telegram-каналі. Про Telegram-канал ще скажемо окремо.
Speaker A
Так, ну і відповідно, буде можливість відтворити та допрацювати застосунок, знову ж таки, в залежності від рівня, на якому ви будете долучатись в марафон, так. Ну і після того ви вже будете отримувати диплом про завершення. Ну і звісно,
Speaker A
будуть певні призи для тих, хто надасть свої фінальні проекти, ми оберемо найкращих і також подаруємо призи від EPAM Campus.
Speaker A
Стосовно основних платформ та дат, які у нас загалом є. Та відповідно, від сьогоднішнього дня у нас будуть проходити з вами воркшопи кожен день о 17:00, це загальний час, який в нас там встановлено, не рахуючи якихось екстрених кейсів, так?
Speaker A
Одразу відповідаючи, будуть в нас записи на зустрічі, так, записи будуть, ви зможете це все переглянути, передивитись, проте дуже радимо не затягувати, тому що в нас буде кожен день додаткова зустріч і відповідно потім це вас може зайняти значно більше
Speaker A
часу. А по платформах так само в нас всі зустрічі будуть відбуватись на Ютубі, а де шукати всі анонси — це в Телеграмі, так, там будуть домашні і відповідно всі файли, лінки і тому подібне там будуть знаходитись.
Speaker A
І ще окремо в нас буде м-м з вами по заверш...
Speaker A
Я думаю, тут більш-менш все зрозуміло. Ну і а якщо ви випадково пропустили і ще не долучились до саме нашого каналу Подія, а де будуть всі анонси. Будь ласка, відскануйте QR-код і зареєструйтесь там, підпишіться.
Speaker A
А проте звертаю вашу увагу, якщо ви підключились зараз з Ютубу і, відповідно, просто підпишетесь в Telegram-канал, так, ви будете отримувати всю інформацію, проте для того, щоб отримати диплом, дипломи ми будемо видавати саме за тими реєстраціями, які ми отримували на
Speaker A
тренінг-порталі. Тому обов'язково не забудьте ще зареєструватись там. Ну, і що ще хотілось би сказати? Окрім того, що в нас будуть воркшопи, то після завершення воркшопів на наступний день в вас вже буде можливість пройти фінальний пройти фінальний тест.
Speaker A
вас, як бачите, доволі там довгий період часу буде, ви обираєте там зручний для вас час і можете там пройти з 30-го, так, ну, і до 4.11.
Speaker A
А після того ми передивимось і проаналізуємо ваші там проекти, подивимось на ваші результати по тестам і після того в нас буде вже там з вами фінальна зустріч, де ми покажемо декілька проектів, ті, які нам сподобались найбільше, ну, і,
Speaker A
відповідно, після того будемо там намагатись зробити це якомога скоріше, так, це видавати вам дипломи про завершення, щоб ви отримали і пройшли.
Speaker A
А тому ну, десь там до 18.11, приблизно, проте будемо намагатись зробити це максимально швидко, щоб ви отримали свої там дипломи, змогли їх там підвантажити на той самий там а-а, і тому а, подібні там платформи, які ви використовуєте, які допоможуть вам
Speaker A
з пошуком роботи. Ну, і зараз ми давайте з вами, а, подивимось, які в нас основні вимоги для отримання ось цього диплому про завершення. Це один як, а, з прикладів з минулих а років.
Speaker A
А, на перший рівень вам треба, а, пройти фінальний тест. Він буде складатись всього там з 20 тьох п'ятьох, а, запитань приблизно. Можемо зробити там невеликі зміни, подивимось, а, в залежності від м-м, а, від того, який обсяг матеріалу буде
Speaker A
покритий в продовж, а, марафону. Тривалість приблизно, а, 60 хвилин. Може тривалість буде трохи меншою. Це ми ще, а, надамо вам цю інформацію трохи окремо. А, також хочу звернути вашу увагу на тому, що не, на другому рівні, а, вже треба буде пройти тест і ще
Speaker A
розгорнути застосунок. Знову ж таки, ми дамо вам повністю бекенд, ми дамо вам повністю фронтенд, ми покажемо, як то все зробити. А, проте вам треба буде розгорнути застосунок, і це більш так на DevOps частинку, так? І вже третій рівень, м-м, відповідно, це ви а,
Speaker A
проходите тест, а, так, і повинні розгорнути застосунок і імплементувати ту фічу, про яку ми будемо говорити в продовж марафону і розбрати, а, там спочатку там про вимоги і про бізнес-аналіз. Ну, і відповідно, потім і бекенд, і фронтенд.
Speaker A
А, на що тут хочу звернути вашу увагу? Що ви можете використовувати будь-які мови програмування. Тобто, якщо ви вже маєте певний досвід, і я читав, а, що в нас були там досвідчені там розробники, ви можете використовувати якісь інші тули, так?
Speaker A
Використовувати інші мови програмування. А проте в такому випадку обсяг роботи у вас буде більший, так? Тому що там якусь частину вам треба буде приносити і робити там якусь, наприклад, іншу архітектуру. А проте ми не говоримо, що конкретно вам
Speaker A
там робити. Ми даємо свій там приклад, так, який ви можете взяти як за основу і використати ті мови програмування, які будемо використовувати ми.
Speaker A
Так, це буде там а-фронт і буде на беці це буде там .NET. Ну, і знову ж таки клауди ми будемо певні використовувати, ви можете там якісь інші. А проте тут вирішувати вам.
Speaker A
А з іншого боку ми все одно будемо від вас вимагати, щоб той проект, наприклад, який ми будемо дивитись, щоб він відповідав тій тематиці марафону, яка в нас є.
Speaker A
Чому це важливо? Тому що ми розуміємо, що у вас можуть бути свої якісь пет-проекти і ну і відповідно вони не будуть стосуватись марафону, а ми все ж таки хотіли б, щоб ви в рамках цього марафону спробували ось пройти цей
Speaker A
шлях повністю, тому дуже будемо робити акцент на тому, щоб сам продукт, який ви зробите, він відповідав тематиці.
Speaker A
А проте тули ви можете використовувати інші мови програмування, можете використовувати інші клауди, можете використовувати інші, бо це буде там залежати від вас.
Speaker A
Ну, і відповідно за цими рівнями залежності, який у вас буде рівень, від цього буде залежати кількість годин в дипломі. Відповідно, перший рівень диплому це 40 годин, другий це буде приблизно а 70 годин і відповідно третій рівень це на 140 годин, тому що це доволі велика
Speaker A
робота. Ось. Проте, якщо у вас буде щось не виходити, так, тобто у будь-якому випадку ставтесь до цього, як до такого дуже неймовірно крутого експірієнсу, щоб спробувати бекенд, спробувати фронтенд, щось вийде, щось не вийде, так? У будь-якому випадку ви зможете пройти ось
Speaker A
цей фінальний тест, отримати хоча б за певну частину. Проте ось цей такий комплексний досвід для вас, як на мене, це буде неймовірно круто в для розуміння. Можливо, для когось це взагалі може стати такою базою для майбутньої там дипломної роботи, тому що
Speaker A
знову ж таки, ну, це там вже все ж таки там рівень, ну, там бакалавра в університеті, так? Тому використовуйте цю можливість, а ми зі свого боку будемо вам допомагати. І, до речі, бачу, що в нас майже вже тисяча
Speaker A
людей на трансляції, це прям дуже приємно бачити, і думаю, для нашої команди це також буде дуже приємно.
Speaker A
Ну, що, і на цьому етапі я, напевно, хотів би прийти, показати взагалі, що ми будемо з вами розробляти. Відверто скажу, хочу навіть з вами разом пройти реєстрацію, щоб ви це спробували, і це буде живе демо, тому, якщо у вас будуть якісь
Speaker A
там Так, якщо в нас будуть з вами якісь трабли, то то не так а складно. Так.
Speaker A
Будемо розробляти ось такий сайт. Ще раз повторююсь, ми з вами пошаримо там і дизайн, і пошаримо з вами і бекенд, і фронтенд, і покажемо навіть, як це розгорнути.
Speaker A
А, та, проте м-м все одно буде частина, яку вам треба буде доопрацювати. Давайте подивимось і спробуємо. Ну, зареєструватись ми не можемо, так, от точніше зайти, бо в мене поки що немає акаунту. Я хотів би, щоб ми з вами створили це зараз раз сом,
Speaker A
create account. Так давайте створимо якусь пошту. Так. І давайте повторимо. Так. І давайте спробуємо зайти. Я трошки пізніше, а-а, так, давайте ми навіть збе- збережемо, так, щоб воно Так.
Speaker A
Секундочку. Так. Давайте зараз повільно там подивимось. Ми шарити вам напряму лінку там не будемо.
Speaker A
Так. Якісь там дати. Ну, давайте на сьогодні після події підемо підемо, ну, щоб так Ну наприклад там кількість гостей.
Speaker A
Дай Боже, щоб воно все працювало. А-а, так. Ну, і ось ми там бачимо там реєстрацію.
Speaker A
Так, main page. Так. А чому воно зараз Ще раз, секундочку. Чому воно не збереглось? Ну, давайте ще разок.
Speaker A
Так. Ну, live демо, як live демо, знаєте. Так. Давайте ще раз три, book table.
Speaker A
Ага. Все наприклад confirm. Окей. В нас є а-а лінка, так, це ми можемо пошарити там для наших учасників. А ну, це ми там дуже подивимось і вони могли б А ну, зараз чи буде це, секунду.
Speaker A
А ну, я не бачу, чи воно відображається. А ні, воно с- зараз, секундочку, я перешарю а-а екранчик.
Speaker A
Бо я відкрив а-а лінку, яка м-м Так. Секунду. Надіслати. А це е-е після того, як ми з- скопіювали ось лінку для гостя, я можу тут наприклад написати [зітхання] а-а не знаю, хай це буде Дмитро якийсь.
Speaker A
Ну, і Дмитро може там собі зробити, умовно кажучи, якийсь там pre-order їжі, що він хо- там поїсти, щоб вже прийти.
Speaker A
Так. Приордер. Ось. Ну, і відповідно Зараз секунду. Так секунду. Ага. А я не показав, так?
Speaker A
Добре. Давайте зараз ще раз. А-а, так, я ще раз зараз скопіюю лінку на приордер, бо воно не відобразилось.
Speaker A
А-а. Так. Окей. Давайте ще раз тоді. Я сподіваюсь, зараз видно. Так, зараз видно. Все супер. Ну, і гість може обрати ще до того, як він приходить, він може там заброньовати, які конкретно страви він там хоче там для себе
Speaker A
замовити. І так можна зробити там на кожного учасника. А-а так. Е-е кріейт. Так. Все. Гест ліміт. Ну, так, тому що е-е, я вже один я згенерував самостійно, і відповідно це вже там е-е, більш ніж той.
Speaker A
А-а добре. Так, е-е, я хотів би зараз відкрити коментарі, бо в мене чомусь так і не працюють е-е, коментарі.
Speaker A
Я хотів би зараз, певно, там чотири хвилинки повідповідати на питання, якщо є саме організаційні, і після того будемо переходити до м-м зустрічі.
Speaker A
Так, дайте мені хвилинку, бо чомусь чат, певно, такої кількості не витримує в тому. Так, Якщо є питання, будь ласка, давайте ось прям зараз, будь ласка, пишіть, тому що я ось зараз відкрив і зараз буду тоді а-а та відповідати.
Speaker A
Так. Е-е рівні документів це будуть рівні в е-е дипломі, тобто диплом у вас може бути на різну кількість годин, а-а відповідно, це буде впливати на це. Якщо вам це треба буде, наприклад, для університету, а-а то, відповідно, більше годин, більше кредитів можна а-а
Speaker A
буде закрити. А-а куди саме реєструвати, щоб у подальшому отримати сертифікат? Добре, зараз ми а-а давайте, коли почну, почнеться лекція стосовно а-а бій-частини, я надам ще посилання на а-а реєстрацію, тому якщо ви будете там чи то в записі хтось
Speaker A
дивитись, е-е зможете зареєструватись в будь-який а-а зручний час і, відповідно, е-е допройти. О! А тут мені допомагають. Все дуже дуже круто. А-а так, які мови програмування будуть найкращі для цього курсу? А-а дивіться, стосовно мов програмування, ще раз повторюсь, по
Speaker A
мовам програмування а-а ми вже там пошаримо і на бекенді це буде дотнет і фронт, фронтенд, забув, а-а ангуляр чи React, а проте воно буде пошарити, і ви можете використати той проект, який ми будемо давати, або якщо ні, то ви можете
Speaker A
використовувати будь-яку мову програмування, хоч той самий Python. Проте чому ми все ж таки радимо там звертати увагу і вчити, наприклад, Java, вчити .NET, тому що більше позицій по цим напрямам саме е-е саме в е-е в нашій компанії, тому дуже рекомендуємо
Speaker A
на це звертати вашу увагу. Так, а-а дизайн теж е-е по за чи можна свій? А-а дизайн можете змінювати, це буде в нас окрема зустріч з дизайнерами, вони будуть дуже е-е задоволені, навіть якщо ви просто в домашньому завданні зробите редизайн, а-а і, я думаю, це
Speaker A
буде для вас також дуже е-е гарний експірієнс, так? Тобто ми даємо вам такий як конструктор, а вже ви можете там щось використовувати, змінювати, ви можете взагалі змінити дизайн, якщо вам наш не сподобається.
Speaker A
Тому як як захочете. А-а використовувати е-е виконувати свої проекти, на якій платформі будемо виконувати? Не зовсім зрозумію цього питання.
Speaker A
Ви не будете переходити по рівням, ви просто, в залежності від того, який проект ви виконаєте, так, яку кількість з цих пунктів, від цього буде залежати, що конкретно ви отримаєте. Е-е зараз можете там не перейматись стосовно цього, потім, по завершенню, вам а-а у вас буде
Speaker A
окремий пост, де буде вся інформація стосовно того, а-а які кроки вам треба буде виконати. Вам треба буде пройти тест і просто дати там лінку на репозиторій, дати лінку на а-а розгорнутий застосунок, ми зайдемо, подивимось, яка а-а фіча у вас була
Speaker A
реалізована. Ви навіть фічу можете обрати якусь іншу, якщо у вас буде на то бажання. Тому за це не переймайтесь і ми це все розпишемо.
Speaker A
Ось так, тому головне, щоб у вас ось цей додатковий функціонал, він був там покритий і бекенд частини і фронтенд, щоб воно було задеплоєно в тому числі.
Speaker A
А Чи можна робити десктопний застосунок? Можна, без питань. Як враховувати які надаються після цього?
Speaker A
Враховують компанії сертифікати після цього курсу. А Знаєте як враховують? А, так. Ви повинні розуміти, що а коли ви вчитесь, ви в першу чергу повинні вчитись для певних знання, так, і певних вміння, які ви отримуєте. А, тому в першу чергу, як на мене, все ж таки
Speaker A
для більшості це більше про експіріенс, так? А дуже цікавий, стислий, крутий, який, про який можна розповісти і відповідно презентувати. Знову ж таки, якщо ви зробите це як проект, то це можна там додати собі до портфоліо.
Speaker A
Тобто я б дивився в цьому ракурсі, що ви про це зможете скомунікувати і правильно презентувати свої результати.
Speaker A
Так а добре. Так, дивлюсь, дивлюсь, питань дуже багато. Куди здавати ДЗ? Все буде в телеграм каналі. Тобто по завершенню кожної зустрічі, коли буде домашнє завдання, буде опис домашнього завдання, буде дедлайн по домашньому і буде форма в Microsoft, ну, Microsoft Forms,
Speaker A
куди ви будете давати лінку на домашнє завдання. А так. А, приклад використання AI буде який саме?
Speaker A
AI е в рамках кожного напряму кожен експерт буде покривати цю тему в своєму, ну, в своєму виступі. Тому так, це буде, чекайте виступів експертів.
Speaker A
Так. Е, то нічого, що я на Linux. А, ні, нічого, що ви на Linux. Чи можна, е, працювати в команді? А, дивіться, в нас по замовчуванню, а, все ж таки індивідуальні проекти. Ще раз повторюсь, ми шаримо, а, бекенд, фронтенд. Можливо,
Speaker A
на наступні рани будемо розглядати якусь, а, можливість командних проектів, бо бачимо дуже велику зацікавленість в цьому а питанні. Проте, на даний момент, а, ми а, ще не маємо такої можливості. Ще раз повторюсь, ми даємо вам все, тому е,
Speaker A
спробуйте, так, бо все ж таки ви спробуєте різне і це дуже і дуже круто.
Speaker A
А, так, супер. А, яка версія, а, Java улюблена? Е, знаєте, остання і найулюбленіша, певно, буде, тому що воно все одно розвивається. На початку може здаватись щось незручним, а потім в перспективі, а, все одно переходиш і вчиш е, те нове, яке є, так? І IT - це все ж
Speaker A
таки а перейти, перейти в той напрям, де треба постійно вчитись вдосконалюватись вчити інструменти штучного інтелекту. А, потім може з'явиться ще щось нове, тому це треба робити, так.
Speaker A
А, так, про AI відповів, як Так, так, так. Е, Так, чи буде тестове ТЗ по функціоналу?
Speaker A
Так, буде конкретно фічу, я знову ж таки, ще раз повторюсь, в нас буде певна фіча, яку ми будемо допрацьовувати впродовж всього марафону. А, проте, ви можете взяти якусь іншу фічу, в такому випадку, ви, коли будете складати, е, ось, фінальний тест, після фінального
Speaker A
тесту у вас буде лінка на, е, на репозиторій, а, лінка на, а, проект, щоб я міг зайти там, перевірити і, е, е, подивитись і окремо ви зможете розписати функціонал, який ви допрацювали. Якщо це буде якийсь інший функціонал, це окей, ви можете навіть повністю
Speaker A
переробити цей застосунок, ну, знову ж таки, в тематиці марафону, тому варіантів, е, на завершення дуже багато.
Speaker A
М-м так м-м. Дуже, дуже багато питань. А, офер е стосовно оферу, а, ну, звісно, ви можете його отримати, та, це головне, а, прийти, пройти навчальні можливості від EPAM Campusу і потім долучатись до компанії, тому, а, від вас тільки, е,
Speaker A
бажання, час, ще раз повторюсь. А, а, без питань, ви можете, е, робити, ще раз повторюсь, на будь-якій мові програмування, дуже багато схожих питань.
Speaker A
Так е м-м чи складно буде? А, буде залежати від вашого рівня, від бу, буде залежати від того, який, а, ви для себе рівень, а, оберете. Якщо просто прослухати і скласти тест, а, як на мене, це не складно, будь-який с, впорається навіть
Speaker A
перший, другий курс для загального розуміння, взагалі, як то воно, а, відбувається, які етапи є, тому таке.
Speaker A
А так, а, добре. Так, дизайн в Фігмі. А Фігмі, так, в компанії використовують в нас саме Фігму для роботи UI/UX дизайнери.
Speaker A
Так, сьогодні буде, так, сьогодні буде вже ДЗ, тут мої колеги вже дуже чекають, щоб я передавав слово, а тому, напевно, я буду зараз потроху завершувати і, напевно, переход, я буду відповідати в чаті на ваші питання, тому що в нас не так багато часу там залишилось.
Speaker A
І що, хотілось би, напевно, передати слово нашим неймовірним спікерам сьогодні. Їх сьогодні буде трохи більше, аніж ми анонсували, тому що за кожним напрямом, який в нас буде представлений, стоїть певна команда. І взагалі, напевно, перш, ніж ми почнемо, хочу,
Speaker A
напевно, подякувати кожному з цих експертів за те, що долучились до цього проекту, взагалі до створення цього застосунку, бо це команда працювала вже там більш, ніж як там два місяці, так, для того, щоб надати всю інформацію, щоб ви не робили
Speaker A
це з нуля. Тому кожному з експертів дякую, окрема дяка всій аудиторії за те, що ви долучились до цього проекту і і бажаю вам успіхів, так, в подальшому. І презентую нашу, нашого першого спікера на сьогодні, це Марина.
Speaker A
Марина, я тебе додаю до ефіру. Привіт, привіт. Клас, дякую. Всім привіт. Рада доєднатися у вас.
Speaker A
Давайте трошки познайомимося. Єгор вже представив мене. Як ви розумієте, я є бізнес-аналітиком компанії ЕРАМ і, власне, я сьогодні тут, щоб із вами розібратися з тим, що взагалі таке той бізнес-аналіз і навіщо він потрібен.
Speaker A
Єгор, можу попросити тебе вивести Так. презентацію? Так, презентацію вивів і, до речі, нагадай мені, скільки ти вже, як який це в нас з тобою марафон?
Speaker A
Це мій третій марафон. Третій марафон, так. Так. І насправді кожен марафон, він не схожий на інший.
Speaker A
Якщо тут є якісь люди, які брали участь в попередніх марафонах, я впевнена, що ви знайдете для себе щось цікаве навіть в цьому.
Speaker A
Це цікавий досвід, кожен раз ми намагаємося зробити щось нове для того, щоб вам було цікаво, щоб ви отримували саме щось цінне да?
Speaker A
Щоб ви навчалися кожен рік чомусь. Тому я дуже рада допомагати вам в цьому. Добре, тоді передаю тобі слово, мікрофон і поїхали.
Speaker A
Клас. Тож, як ви вже знаєте, як ви вже бачили, ми сьогодні з вами проговоримо про поговоримо про вимоги до програмного забезпечення і трошечки розглянемо детальніше формування вимог саме в скрамі.
Speaker A
Крім цього, ми, звісно, розберемося, по-перше, що взагалі таке бізнес-аналіз, хто є такий бізнес-аналітик. Як я згадала, розглянемо детальніше методологію і зупинимося окремо на скрамі, поговоримо про нього і далі будемо вже рухатися до нашого продукту, над котрим ви будете
Speaker A
працювати. Це той продукт, який пошарив з вами Єгор, Green Tasty додаток. Поговоримо про те, як, власне, ми формували вимоги до цього продукту, як ми їх пріоритезували і як ми зрозуміли все ж таки, з чого ми почнемо працювати в цьому році, що ми візьмемо
Speaker A
за основу для того, щоб вам показати. Зупинимось детальніше на користувацьких історіях і на останок розглянемо ваше перше домашнє завдання, ну і звісно повідповідаємо на всі ваші запитання, тож давайте починати.
Speaker A
Я рада представити свою команду. Єгор подякував всій команді, яка працювала над цим марафоном, а я власне в свою чергу хочу представити нашу таку затишну команду бізнес-аналітиків, яка втілювала вимоги до продукту Green Tasty в життя.
Speaker A
Це власне я, мене ви бачите, я є бізнес-аналітиком в компанії ЕРАМ, співпрацюю з компанією вже о, якщо не помиляюсь, четвертий рік.
Speaker A
І крім мене в моїй чудовій команді було ще дві Анастасії, також чудові дівчатка, початківці в бізнес-аналізі. Я дуже вдячна кожній з них і власне з однією з Анастасій ви будете мати нагоду поспілкуватись також сьогодні.
Speaker A
Тому побачимось з Анастасією трошки пізніше. Тож тепер ви знаєте, хто по цей бік екрану, а я в свою чергу дуже рада буду познайомитись трошечки з вами.
Speaker A
Я пропоную вам відсканувати QR-код, який ви бачите зараз на екрані і долучатися до Mentimeter, для того, щоб ми трошечки з вами один одного краще пізнали.
Speaker A
Залишу поки що цей цей слайд, щоб всі могли відсканувати. Сподіваюсь, що все виходить. Тож, хто відсканував, можете, будь ласка, поділитися інформацією про себе, в якій сфері ви працюєте можливо, ви навчаєтесь, на кого ви навчаєтесь. Дуже цінно дізнатися, хто ви
Speaker A
є. Клас, я бачу, що в нас дуже багато QA інженерів. Супер. IT, IT, IT, UX-дизайнери. О, для вас наступна лекція.
Speaker A
Інженери. Системний аналіз, клас, колеги, вітаю. Логістика. Інженери QA бізнес-аналітик. Дуже рада бачити колег в цьому списку. Привіт.
Speaker A
Full stack, супер. Навчається, хтось навчається. Вау, клас. Я бачу, що дуже багато у нас сьогодні зібралося людей, які або навчаються IT-технологіям, або вже є частинкою, да, IT-команд.
Speaker A
Дуже круто. Можливо, тоді якісь терміни, які ми будемо використовувати, будуть вам вже знайомі. Круто.
Speaker A
Окей, давайте тоді рухатися далі. Для того, щоб, власне, тим, хто ще незнайомий з бізнес-аналізом, трошки так простими словами пояснити, в чому ж його суть, давайте перенесемось в звичайні такі буденні ситуації і просто уявіть собі таку ситуацію, що команда будівельників будує ресторан.
Speaker A
Але при цьому хтось забув згадати про те, що потрібно побудувати кухню в цьому ресторані. І власне, ми маємо ресторан без кухні.
Speaker A
Да, тобто без власне серця цього закладу. І в результаті ми маємо з вами що? Ми маємо з вами приміщення з класним інтер'єром, з барною стійкою, з класною розстановкою столиків.
Speaker A
Але при цьому немає головного, немає власне того місця, де готується їжа. Так? І ми не можемо сказати, що над цим проектом працювала погана команда будівельників, тому що ну, інтер'єр дуже класний, все чудово, комунікації чудові. Але при цьому хтось
Speaker A
про щось просто забув. Так? І як вигадаєте, чому навіть маючи дуже класну команду спеціалістів в своїй області, інколи команда, вона будує ну, неправильні якісь речі. Чому власне те, що побудовано, воно не відповідає очікуванням?
Speaker A
Поділіться, будь ласка, вашими думками, що ви про це думаєте. Поверніться до відсканованого відсканованого QR-коду, хто закрив, може відсканувати заново. Новий QR на екранчику.
Speaker A
Різне бачення, немає чіткого плану, погана комунікація. Людський фактор, так? Ніхто від цього, на не застрахований.
Speaker A
Wrong requirement. Я бачу тут бізнес-аналітика який [сміх] який відповідає. Непорозуміння, немає бекенду. Ну, без бекенду, звісно, ми нікуди.
Speaker A
Занадто захоплюється створенням. Це дуже класний, до речі, коментар. Тут вже про бажання завжди, мабуть, досягнути якогось ідеалу, да?
Speaker A
Да погоджуюсь. Plan requirements. Хтось обіжався. Бува таке, не дійшли згоди. No plan, no clarity.
Speaker A
Немає чіткого плану. Да, в цілому я погоджуюсь з усіма коментарями. Їм не вистачає бізнес-аналітика. Да.
Speaker A
[сміх] Абсолютно згодна. Bad management. Некоректне ТЗ. Окей, так, дуже дякую. Класні відповіді, всі вони абсолютно коректні і всі вони мають місце бути.
Speaker A
Тож, чому все ж таки, да, очікування інколи не співпадають з реальністю? А-а, проблема, вона взагалі не в команді.
Speaker A
Кожен член цієї команди може бути класним спеціалістом, да? При цьому, якщо команда не має чітких вимог, що саме вона може зробити, або ці вимоги, вони якось якісь хаотичні, вони не пріоритезовані, таким чином команда не розуміє, з чого ж нам
Speaker A
треба все ж таки почати. Перше, нам треба фундамент, да, збудувати, якщо ми кажемо про якесь будівництво.
Speaker A
То, поки у нас немає фундаменту, да, у нас, в принципі, немає сенсу проводити якісь там електричні мережі, правильно?
Speaker A
Тому дійсно проблема лежить в нечітких і непріоритезованих вимогах. І у зв'язку з вимогами є достатньо багато підводних каменів в розробці.
Speaker A
Давайте ми вже будемо рухатись ось від розробку, розробки програмного забезпечення. І які ж все-таки є такі найбільш поширені підводні камені, які стосуються вимог? Ну, по-перше, це ситуація коли кожен член команди просто зрозуміє вимоги трошки по-різному, да? І власне,
Speaker A
начебто ми працюємо над одним і тим самим але кожен в своїй інтерпретації. Умовно кажучи, давайте відійдемо, да, щоб на таких буденних прикладах. Ви зайшли в кав'ярню і ви просто захотіли кави. Якщо ви замовите просто каву, можливо, ви очікуєте, що вам зроблять
Speaker A
капучино, яке ви обожнюєте, але бариста вам запропонував американо. Чи будете ви задоволені? Ні. Але просто ви по-різному один одного зрозуміли так?
Speaker A
Другий підводний камінь про те, що вимога наче сформульована, але ми не маємо критерій, як перевірити, що ця вимога, вона є виконаною. Тобто кожна вимога, вона має містити в собі перелік певних критеріїв, виконуючи котрі, ми можемо зі стовідсотковою впевненістю казати, що ми
Speaker A
досягли даної вимоги. Знову ж таки, кажучи там про те саме капучино, ми знаємо, що капучино має бути кава, молоко і пінка, так? І от коли всі ці компоненти є ще в правильній пропорції, все, наша вимога, вона не А третій підводний камінь про те, що
Speaker A
інколи ми хочемо зробити занадто багато, от просто одномоментно, в один період часу. І, на жаль, маючи таку ситуацію, команда розробників, вона просто перевантажена і в результаті ми маємо таку ситуацію, коли ми завершуємо просто ні з чим.
Speaker A
Ми не маємо жодної фічі, яка би була повністю виконана і повністю працювала саме так, як це було заплановано.
Speaker A
Ну, і останній підводний камінь якраз про пріоритети, коли нам не зрозуміло, що ж все ж таки дає найбільшу цінність замовнику. В цьому випадку ми не знаємо просто, на чому сконцентруватися і що взяти в роботу першим, другим чи третім.
Speaker A
І власне хто ж, да, стоїть за лаштунками того, щоб и команда не спіткнулася з тими підводними каменями, про які ми тільки що проговорили. А це, власне, і є бізнес-аналітик. Тобто, по факту, бізнес-аналітик - це та людина, яка допомагає висловити потреби бізнесу
Speaker A
саме таким чином, щоб и команда змогла задовольнити ці потреби. І в широкому розумінні практика бізнесу бізнес-аналізу, вона зводиться до того, щоб и провадити зміни в організацію шляхом визначення потреб і пропозиції рішення, яке надасть цінність даному бізнесу, враховуючи, звісно,
Speaker A
певний контекст, певні обмеження, які є в даного бізнесу. І це те, бізнес-аналітик, він робить яким шляхом?
Speaker A
Спочатку ми повинні зрозуміти потреби бізнесу. Ми потріб- ми маємо визначити вимоги даного бізнесу і потім вже ми маємо запропонувати певне рішення, яке задовольнить дані вимоги в першу чергу і також принесе цінність нашим клієнтам.
Speaker A
Тобто можна думати про бізнес-аналітика як про такий місток між бізнесом і між командною командою розробки.
Speaker A
От. І на попередньому слайді ви бачили таке поняття, як стейкхолдери. А так от, хто такі, власне, стейкхолдери? Це поняття дуже часто використовується в роботі бізнес-аналітика, тож давайте з вами розберемося, хто це такі. Стейкхолдери - це група осіб, або, можливо, там одна
Speaker A
особа, яка зацікавлена в результаті проекту або має на нього вплив. І власне серед стейкхолдерів можуть бути ті, хто є спонсором цього проекту, хто платить безпосередньо, да, вони вони зацікавлені в проекті, тому що вони витрачають на нього свої кошти.
Speaker A
Це можуть бути користувачі. А це можуть бути навіть інші системи, на яких буде наш продукт мати вплив.
Speaker A
А або це можуть бути, наприклад, такі люди які впливають на прийняття рішень в цьому а продукті або проекті.
Speaker A
І бізнес-аналітик в своїй роботі він має враховувати інтереси абсолютно всіх груп стейкхолдерів. Для того, щоб бути впевненими, що всі реквайрменти, тобто всі вимоги, вони виявлені, що ми врахували абсолютно всі можливі зацікавлені сторони.
Speaker A
Власне, ось в цьому і є також частина роботи бізнес-аналітика. Давайте тепер трошки так підсумуємо.
Speaker A
І спробуємо виокремити такі основні етапи бізнес-аналізу, да? Як нам з фрази від клієнта: "Я хочу" все ж таки перейти в конкретну дію.
Speaker A
Процес бізнес-аналізу, знову ж таки, дуже спрощено, виглядає наступним чином. Спочатку бізнес-аналітик збирає формулює аналізує документує вимоги.
Speaker A
Далі, серед цих вимог ми намагаємося виокремити саме ті, які приносять найбільшу цінність бізнесу. Яким шляхом ми відфільтровуємо, да, ці вимоги, для того, щоб зрозуміти, а що ж дійсно нам потрібно для того, щоб задовольнити першочергову бізнес-потребу.
Speaker A
І надалі ми починаємо вже підфільтровані вимоги пріоритизувати. Для того, щоб зрозуміти, а з чого ми власне починаємо, да?
Speaker A
І, умовно кажучи, для тих, хто взагалі незнайомий з бізнес-аналізом, можна представити собі таку мапу, де ми маємо точку А, точку Б. І от бізнес-аналітик намагається зрозуміти, а що ж нам потрібно мінімально для того, щоб дібратися з точки А в
Speaker A
точку Б. Що є нашими першочерговими вимогами для подолання цього шляху? З чого нам потрібно почати?
Speaker A
Ось цим власне і займається бізнес-аналітик. Е-е і хочу ще зауважити, що ось ці етапи бізнес-аналізу, вони можуть мати місце в той чи інший період розробки програмного забезпечення, в залежності від обраної методології даного проекту.
Speaker A
Тож давайте трошки поговоримо про методології, щоб ви також мали уявлення, як відрізняється робота бізнес-аналітика в залежності від методології.
Speaker A
І, по-перше, давайте проговоримо, що таке методології. Методології - це система принципів, за якими власне і розробляється програмне забезпечення.
Speaker A
І в такому, дуже широкому, знову ж таки, розумінні, можна поділити методології на дві групи. Перша група - це традиційні методології, і друга група - це Agile.
Speaker A
І яскравим представником традиційних методологій є Waterfall. Тобто, водоспадна методологія, так? Тут можна вже з назви, я думаю, трошки здогадатися, в чому є суть.
Speaker A
В, працюючи з даною методологією, ми не переходимо на наступний етап розробки програмного забезпечення, допоки ми не завершимо попередній.
Speaker A
Тобто, наприклад, поки ми не завершимо фазу аналізу, ми не рухаємося до фази дизайну. Допоки ми не завершимо з фазою дизайну, ми не переходимо на, власне, фазу імплементації.
Speaker A
І, враховуючи те, що тут у нас поетапна робота, основну частину роботи з реквайрементами, з їх збором, з їх документацією, підтвердженням реквайрементів з замовником, бізнес-аналітик робить саме на етапі аналізу.
Speaker A
І коли цей етап завершений, бізнес-аналітик безпосередньо він присутній на проекті, але при цьому роботи з вимогами вона вже дуже мінімалі- мінімізована і внесення змін в ті вимоги, які були узгоджені на початку, воно вкрай мінімальне і вкрай формалізоване.
Speaker A
Тобто дуже складно щось змінити в тих вимогах, які були сформульовані з самого початку. І на противагу цій моделі ми маємо адаптивні моделі, так?
Speaker A
Знову ж таки назва дуже багато про себе говорить, можна одразу зрозуміти, що працюючи за Agile'ом, ми, власне, завжди відкриті до будь-яких змін, ми гнучкі, ми можемо змінювати якісь вимоги в ході розробки.
Speaker A
І, власне, в цьому суть Agile'у. І от яскравим якраз представником сімейства Agile є Scrum.
Speaker A
Scrum - це такий поетапний, ітеративний фреймворк розробки програмного забезпечення, який базується на принципах і цінностях Agile'у.
Speaker A
І робота за Скрамом передбачає собою роботу так званими спринтами, ітераціями. Протягом кожного такого спринта команда працює над певною частинкою готового продукту.
Speaker A
І в кінці спринту ми маємо вже робочу частинку, яку ми можемо показати нашому клієнту і отримати від нього фідбек, на основі якого ми можемо вже внести певні корективи в наш сформований план дій.
Speaker A
Тобто ми постійно готові до того, щоб вносити певні зміни. При цьому, звісно ж, у нас є якісь пріоритети, які формуються продукт овнером. Продукт овнер, він визначає, що ми перше беремо в роботу, в залежності від того, що це носить найбільшу
Speaker A
цінність бізнесу. І власне більша частина проектів наразі вона вона підтримує роботу за Скрамом або за якоюсь іншою методологією, але більшість з них це якраз методології з сімейства Agile.
Speaker A
Тому я трошки детальніше зупинилася саме на даній методології. [прочищення горла] І так як ми проговорили про такі достатньо різні підходи до розробки, може виникнути методологічне питання, а що ж, власне, треба обирати для того чи іншого проекту, да?
Speaker A
Як я вже сказала, більшість проектів наразі обирають для себе Скрам. Чому так? І коли він взагалі підходить?
Speaker A
Скрам добре підходить тим проектам, в котрих передбачено, що результат клієнту має бути представлений частинками, тобто певними інкрементами. Коли клієнт хоче отримувати постійний результат і вносити певні корективи.
Speaker A
Е-е, також скрам дуже гарно підходить в тому випадку, коли ми розуміємо, що вимоги, вони не чітко сформульовані, тобто вимоги до повного, да, продукту, до повного, м-м, додатку, наприклад, не чітко сформульовані з самого початку і ми розуміємо, що вони
Speaker A
можуть змінюватися, в цьому випадку скрам також дуже гарний кандидат. І ще скрам дуже гарно задовольняє таку потребу в тому, щоби швидко отримати живий фідбек від користувачів.
Speaker A
Власне, так, як ми в ко- в кінці кожного спринта маємо робочу частинку продукту, то ми можемо, в принципі, дуже легко зарелізити якісь зміни і отримувати в real time живий фідбек від користувачів, який буде вже впливати на наші пріоритети. Ми можемо постійно змінювати
Speaker A
свій план. Натомість скрам не підходить в тому випадку, коли ризики змін дуже високі і у нас немає потреби до експериментів.
Speaker A
Це можуть бути якісь, е-е, проекти наприклад military tech, або health care проекти, да, де ми не можемо ризикувати, де нам потрібно продумувати, продумати всі реквайрменти наперед.
Speaker A
В такому випадку треба розглянути більш детально саме традиційну методологію. Ось так, трошки поговорили з вами про бізнес-аналіз, про методології і, власне, давайте рухатись до більш такої, можливо, вже практичної частинки.
Speaker A
Будемо тепер говорити про наш продукт Green Tasty, який Єгор вам показав. Поговоримо вже на прикладі нього про реквайрменти, так як ми розібралися з тим, що з ними працює бізнес-аналітик, будемо тепер предметно говорити, а що ж, власне, бізнес-аналітик робить, да, для
Speaker A
того щоб сформувати ці вимоги до продукту. Тож сам application ви побачили вже і, власне, це web application для мережі ресторанів, яка складається з трьох закладів.
Speaker A
Тобто, у нас є три ресторани, які мають додаток, в межах котрого можна подивитися меню кожного ресторану, можна подивитися рейтинги та user фідбеки про кожний ресторан.
Speaker A
Можна зарезервувати собі столик в конкретному ресторані і сформувати собі передзамовлення для того, щоб зекономити час і коли ви вже прийшли, власне, в ресторан, ви би не чекали півгодини на ваше замовлення, а ваше замовлення вже було би готове.
Speaker A
[сопіння] І, власне, це вже ті ті фічі, які у нас є в додатку. Коли ми почали працювати над даним проектом, ми зрозуміли, що ми хочемо сфокусуватися на якійсь такій новій новій фічі, яка би, з одного боку, збільшила задоволення користувачів, да, від
Speaker A
використання нашого додатку. З іншого боку, ця фіча, було би класно, щоб вона також покращувала ефективність і планування бізнесу.
Speaker A
Тобто, ось такий у нас є контекст, та, у нас є готовий, у нас вже був певний продукт з певними фічами, при цьому ми хотіли подумати, що ж саме в цьому продукті може виявитися цінним для того, щоб задовольнити обидві сторони, і юзерів, і
Speaker A
при цьому бізнес також. І давайте тепер розбиратися з тим, як же бізнес-аналітик власне починає працювати над продуктом, які етапи він має, ну, от так, предметно, да, пройти для того, щоб дійти до фінального результату і мати всі вимоги сформульовані і бути
Speaker A
впевненим, що саме ті вимоги, вони принесуть цінність нашому бізнесу. По-перше, так як я сказала про те, що це вже наявний application, ми, як бізнес-аналітики, починаючи працювати з цим наявним додатком, ми спочатку маємо зрозуміти контекст, та, ми маємо проаналізувати,
Speaker A
а як вже на разі функціонує даний ресторан, як користувачі використовують наш додаток, які їх головні такі, м, болі, да, в цьому користувацькому досвіді, для того, щоб зрозуміти, що, власне, нам потрібно покращити, да, з чим нам працювати.
Speaker A
І, власне, про те, як нам може штучний інтелект допомогти в аналізі вже наявної системи.
Speaker A
Насправді, саме в цьому випадку штучний інтелект це дуже класний помічник для бізнес-аналітика, тому що на першому етапі, коли ви працюєте з наявним якимось продуктом, який, можливо, будувався там 5-10 років, просто сісти там прочитати якусь наявну документацію, цього буває недостатньо.
Speaker A
По-перше, документація може бути не зовсім актуальний стан речей задокументований, тому інколи нам потрібно брати до уваги не лише документацію, а ще й, власне, кодову базу.
Speaker A
І ось тут, власне, на етапі, да, для бізнес-аналітика штучний інтелект викори- використовується дуже активно і це є потужним інструментом.
Speaker A
Тобто, найперший етап, до якого ми, як бізнес-аналітики, працюючи над даним продуктом приступили це власне аналіз нашої наявної системи.
Speaker A
А-а, які у нас були цілі даного етапу? По-перше ми хотіли зрозуміти контекст, ми хотіли отримати список таких найголовніших акторів, найголовніших груп юзерів нашого додатку.
Speaker A
Потім ми хотіли зрозуміти, а які є, можливо, правила, а які є, можливо, обмеження в нашому додатку, які залежності.
Speaker A
І для цього дуже класно мати діаграму, на якій у нас буде відображений прям такий user journey, да тобто така юзер, скажем так, подорож, да, в межах нашого додатку.
Speaker A
І також на цьому етапі дуже цінно, щоби штучний інтелект допоміг нам підсвітити, можливо якісь е-е гепи, тобто упущення, які в системі.
Speaker A
Можливо, якісь протиріччя, якщо вони є. В цьому також штучний інтелект може дуже класно допомогти.
Speaker A
Е-е я, на жаль, не змогла би, да, пошарити вам повного е-е промту. Це дуже така його скорочена версія, для того, щоб ви зрозуміли просто головну ідею.
Speaker A
Е-е але що варто зрозуміти? В своєму промті ви маєте надати штучному інтелекту настільки багато документації, наскільки багато, можливо, різних артефактів, які вже наявні, для того, щоб він на основі них зміг допомогти вам провести аналіз системи.
Speaker A
І, власне, в вашому промті ви надає- ви надаєте, наприклад, ці артефакти, е-е складені якісь там е-е файли додаєте і просите м-м сформулювати контекст, також показати головних е-е юзерів, їх групи, власне, підкреслити якісь там лімітейшени системи, залежності і так
Speaker A
далі. І маючи вже такий аналіз, який штучний інтелект вам допоможе підготувати, ви можете вже спускатися на дані в якихось деталях, да? Ви, звісно, маєте проаналізувати ті відповіді, які надає вам штучний інтелект і валідувати вже їх з бізнесом, да? Якщо
Speaker A
вам штучний інтелект підказує, що є там якісь протиріччя, це гарний поінт, який можна взяти на обговорення з бізнесом.
Speaker A
Тож, знову ж таки, повертаємось до додатку да? Коли ми проаналізували вже наявну систему, ми зрозуміли, які є user flow в даній системі, ми зрозуміли, який контекст даної системи, ми можемо рухатися далі.
Speaker A
І для того, щоб знову ж таки, зрозуміти, а яку ж фічу нам потрібно зробити для того, щоб покращити цей користувацький досвід, дуже класною методикою бізнес-аналізу є аналіз конкурентів. Власне, цю методику ми використали і під час роботи над нашим продуктом.
Speaker A
Головна ціль цієї методики в чому? Перед тим, як вибрати якусь стратегію продукту, перед тим, як визначити, куди ми будемо з нашим продуктом рухатися, перед тим, як обрати фічу конкретну, яку ми будемо імплементувати, нам потрібно розуміти, а яка взагалі
Speaker A
ситуація на ринку, да? Що тут відбувається? Тобто, на етапі аналізу конкурентів ми хочемо зрозуміти ринок, ми хочемо зрозуміти, як інші наявні продукти вирішують потреби користувачів і що користувачі в свою чергу очікують при використанні подібних продуктів.
Speaker A
З іншого боку, ми хочемо визначити, а які саме у нашого продукту є ну, такі можливі точки росту, да?
Speaker A
Власне, як ми можемо це зробити? Ми можемо спробувати віднайти якісь незакриті потреби користувачів, які може закрити наш продукт потенційно.
Speaker A
Ну, і, звісно, аналіз конкурентів допомагає нам зменшити ризики, пов'язані з тими рішеннями, які ми будемо приймати.
Speaker A
І власне аналізуючи конкурентів, е-е одна з методик - це SWOT-аналіз. Власне, що таке SWOT-аналіз? Це методика, в межах котрої ми намагаємося виокремити сильні сторони нашого продукту, слабкі сторони нашого продукту, можливі потенційні е-е точки росту, да, так звані можливості, і навпаки загрози.
Speaker A
І, провівши такий SWOT-аналіз для конкурентів нашого application Green Taste, ми зрозуміли, що у нас є достатньо багато, насправді, сильних сторін, да?
Speaker A
Ми дозволяємо користувачам і меню переглянути, і одразу резервацію створити. Е-е також, в принципі, наш продукт, він підтримує декілька ролей. В нашому продукті підтримується роль як користувача, який хоче відвідати, да, заклад. З іншого боку, у нас в системі також є і офіціанти, які
Speaker A
підтверджують або, навпаки, е-е деклайнують бронювання з тих чи інших причин. Вони також формують замовлення в нашій системі. Тобто, достатньо багатостороння система.
Speaker A
Е-е, з потенційних зон росту, враховуючи те, що ми маємо на разі на ринку, ми зрозуміли, що насправді є над чим працювати і однією з таких зон росту це було якраз поліпшення можливості планування, наприклад, закупок в кухні, да?
Speaker A
Е-е, з іншого боку, якщо казати про користувацький досвід, е-е, буде корисно також можливість замовити доставку або, можливо, там замовити їжу на виніс.
Speaker A
І власне ми почали думати в цьому напрямку, да, коли ми маємо сформований список наших потенційних, е-е, зон росту, наші opportunities, ми почали далі думати якраз е-е, в цей бік.
Speaker A
Знову ж таки, повертаючись до використання штучного інтелекту. Для аналізу конкурентів штучний інтелект також може бути гарним помічником для бізнес-аналітика.
Speaker A
Оскільки штучний інтелект може дуже класно допомогти знайти певні альтернативи на ринку. Е-е, він може допомогти якраз, е-е, визначити ось ті потенційні точки росту, враховуючи м-м, можливо, user feedback-и, да, які юзери залишають.
Speaker A
Можливо, шляхом порівняння інших, м-м, суміжних якихось додатків, ми можемо зрозуміти, а що все ж таки в попиті, да, в чому дійсно, е-е, бачать цінність користувачі.
Speaker A
Ну, і, звісно, для того, щоб е-е, сформувати такі фінальні рішення, штучний інтелект класно може допомогти структурувати всі оці знайдені цікаві факти в достатньо зрозумілий і достатньо такий зручний формат.
Speaker A
Тож знову ж таки дуже класний помічник на етапі аналізу конкурентів, яким ми користувалися, але звісно треба розуміти, що всі оці файндінги, тобто всі оці знахідки, бізнес-аналітик має валідувати з бізнесом безпосередньо.
Speaker A
Ну і власне, давайте рухатись далі. Да, ми з вами пройшли етап, коли ми зрозуміли контекст певний.
Speaker A
І далі бізнес-аналітик готовий рухатись до наступного етапу, до етапу формулювання вимог. І тут давайте спочатку розберемося, що взагалі є ці вимоги, так?
Speaker A
Власне вимога - це є певна умова, якій має відповідати система для того, щоб задовольнити умови контракту, для того, щоб задовольнити потреби користувачів з іншого боку.
Speaker A
І важливе нагадування, я на початку казала, ми маємо мати не лише сформульовану вимогу, але ми маємо і мати список певних таких критеріїв, за якими ми можемо впевнитись в тому, що ми досягли даної вимоги.
Speaker A
Е-е і власне вимоги, вони бувають різних типів. Це така піраміда вимог, скажімо так. І бізнес-аналітик в своїй роботі він рухається від найвищого рівня до найнижчих.
Speaker A
На найвищому рівні у нас стоять бізнес-вимоги. Такі вимоги відповідають на питання, а що власне потрібно бізнесу, чого бізнес хоче досягти.
Speaker A
Зазвичай такі вимоги, вони є вимірюваними. Вони достатньо часто містять в собі конкретні показники, конкретні цифри.
Speaker A
Наприклад, давайте візьмемо наступне. Маємо якісь просто додатково оголошень, да? І вимога бізнесу може звучати наступним чином.
Speaker A
Ми хочемо збільшити кількість продажів на 20% протягом наступних шести місяців. Тобто достатньо чітка бізнес-вимога, вона є вимірюваною, вона базується на певних показниках і власне, тут у нас головним показником є кількість продажів да?
Speaker A
Далі, коли ми маємо сформульовану бізнес-вимогу, ми можемо спускатися на рівень нижче. Це, власне, системні вимоги.
Speaker A
Або вимоги до нашого solution, да? І такі вимоги, вони відповідають на питання, а що наша система має робити?
Speaker A
І, знову ж таки, повертаючись до нашого прикладу, якщо ми хочемо збільшити кількість продажів, уявімо також площадку для оголошень, і наприклад придбати щось може лише зареєстрований користувач. Власне, в цьому випадку системна вимога може бути наступною.
Speaker A
Система має давати можливість незареєстрованому користувачеві користувачеві оформити замовлення. Оце вже буде системна вимога. Далі, коли ми системні вимоги, ми починаємо думати над нефункціональними вимогами.
Speaker A
Це так звані вимоги до якості. Вони відповідають на питання, а як наша система має працювати?
Speaker A
Таким достатньо простим прикладом цієї вимоги може бути перелік браузерів, які підтримує наш додаток, так? Чи ми підтримуємо там тільки Google Chrome, чи ми підтримуємо інші браузери.
Speaker A
Е-е, ось такий приклад. І також є ще так звані перехідні вимоги. Е-е, ці вимоги, вони тимчасові і вони потрібні на період, поки ми переходимо з попереднього якогось, е-е, рішення або попереднього нашого стейту до нового.
Speaker A
Наприклад, якщо ми будуємо з вами абсолютно новий додаток, да? Нам потрібно подумати, а як же нам перенести попередніх користувачів, які вже мали акаунти в старому додатку, в наш новий.
Speaker A
Ось це буде вже перехідна вимога. І повертаємось до нашого продукту Green Tasty да? Думаємо про найвищу ланку, про бізнес-вимоги.
Speaker A
І власне яку бізнес-проблему ми вирішуємо? Е-е бізнес-проблема наступна. Коли у нас, наприклад, є декілька гостей, е-е, в одному бронюванню, коли вони намагаються створити собі передзамовлення, вони комунікують з тією людиною, яка, власне, створила бронювання, для того, щоб ось ця людина
Speaker A
вона внесла перед замовленням кожного свого гостя. І все це воно призводить [прочищення горла] до певних проблем, да, які страви можуть бути упущені, можливо наш користувач просто не помітив якісь апдейти в повідомленні. Ну, власне таким чином гість, який приходить до
Speaker A
ресторану він розчарований, да, тому що він очікував, що його передзамовлення буде при буде вже стояти на столі, але його немає так?
Speaker A
І для того, щоб вирішити ось цю проблему ми зрозуміли, що ми хочемо втілити таку фічу, як групове передзамовлення. Тобто це можливість створити передзамовлення для кожного гостя в межах одного бронювання.
Speaker A
Чому ця фіча, вона є цінною для бізнесу? По-перше ми зменшуємо confusion юзерів відвідувачів нашого ресторану.
Speaker A
По-друге ми також робимо наш сервіс більш швидким, да, тобто гості приходять, передзамовлення вже на столі і власне таким чином в них формується достатньо класний experience відвідування нашого ресторану.
Speaker A
З іншого боку нашим офіціантам легше працювати, тому що нам не потрібно вже витрачати час на те, щоб підійти спочатку, визначитися з списком страв.
Speaker A
Офіціанти вже наперед знають, які страви куди треба винести, на на якийсь стіл. І також ми покращуємо планування таким чином. ми знаємо, як краще закуповувати продукти.
Speaker A
Ми знаємо, скільки потрібно цих продуктів, тому що ми маємо вже сформовані групові передзамовлення. І коли ми з вами вже маємо сформовані бізнес-вимоги, ми маємо спускатися, згадуємо, на рівень вимог до системи, solution requirement-и.
Speaker A
В даному випадку, для того, щоб сформувати вимоги до рішення, ми використовували таку техніку, як брейнштормінг, з усіма стейкхолдерами, з усіма тими людьми, які були залучені в даний проект, ми просто провели сесію брейнштормінгу, коли ми разом починаємо формувати певні ідеї
Speaker A
до вимог, які мають бути реалізовані в нашому застосунку. Головна ідея техніки брейнштормінгу полягає в тому, що по-перше, ми заохочуємо висловлювання будь-яких ідей, ми не критикуємо жодні ідеї, ми просто їх занотовуємо і далі ми вже з цим списком ідей працюємо в подальшому.
Speaker A
Ми починаємо там далі пріоритезувати, обговорювати цей список, але дуже класна техніка, коли нам потрібно зібрати ідеї від великої кількості людей.
Speaker A
Тож, в результаті такого брейнштормінгу з тими стейкхолдерами, які працювали над цим проектом, ми мали певний список вимог до нашого продукту, які ми взяли до уваги, над якими ми почали далі вже працювати. Серед таких ідей були наступні. Це якраз додати, власне, ось
Speaker A
цю опцію групового замовлення для кожного столика, дозволити кожному члену цієї групи обрати страви з меню ресторану, підрахувати загальну суму стола автоматично і дозволити також членам групи редагувати свої передзамовлення, якщо ну, людина змінила свою думку і вона зрозуміла, що вона хоче не салат, а там
Speaker A
страва з м'ясом, умовно кажучи. Власне, ось так ми маємо з вами такий доволі великий список реквайрментів, з якими ми далі, як бізнес-аналітики, починаємо вже працювати.
Speaker A
Почина- починаємо їх деталізувати, формалізувати і, власне, перед тим, як почати працювати з цими ідеями, нам треба їх десь спочатку зберегти, да, щоб нічого не загубити.
Speaker A
І все це зберігається в так званому продакт беклозі. Продакт беклог - це пріоритизований список всіх задач або ідей.
Speaker A
І тут давайте, для того, щоб просто дуже легко зрозуміти, що це що таке той беклог, для того для тих, хто не знайомий, да, з IT, уявіть собі просто нотатки в вашому телефоні або, можливо, ви юзаєте якісь додатки десктопні,
Speaker A
де ви просто нотуєте собі список задач на день, на тиждень, на місяць. І ви ж якимось чином, мабуть, ці задачі їх пріоритизуєте, да, для себе. Тобто, щось у вас важливіше, щось менш важливе і ви таким чином розташовуєте ось цей список
Speaker A
задач. Те саме ми робимо і в беклозі. Ми маємо абсолютно всі наші задачі, при цьому ми тримаємо їх в порядку в порядку нашого пріоритету, для того, щоб зрозуміти, над чим ми починаємо працювати в першу чергу.
Speaker A
І власне, от маючи всі оці реквайрменти, які ми сформулювали для нашого додатку, ми переносимо це все в беклог, з яким ми з яким ми далі будемо вже більш детально працювати.
Speaker A
Е-е, ось так. Далі я передам слово Анастасії і з нею вже ви продовжите далі занурюватися в наступні етапи бізнес-аналізу.
Speaker A
Настя. Е, привіт. Надіюся, всім добре мене чути і видно. А, отже, наступні півгодини ми будемо рухатися далі. Хочу ще раз подякувати Марині за такий е, цікавий, розлогий а, вступ, щоб зрозуміти, що таке е, бізнес-вимоги, як працює бізнес-аналітик.
Speaker A
А, далі ми поговоримо про те, що ви бачите на своїх екранах, це пріоритизація. Отже, як визначити, що робити першим, коли в нас уже є цей беклог, проговорені реквайрменти.
Speaker A
Е-м, в першу чергу хочу відмітити, що є різні підходи і методики до пріоритизації, але ми саме поговоримо е, про те, з чим працювала команда на цьому проекті.
Speaker A
Отже, ми будемо говорити е, як ми оцінювали вимоги за двома критеріями. Е, перший критерій це яку цінність несе ця вимога для бізнесу, а наступний а, яка вартість реалізації того його чи тої чи іншої вимоги. Чим вища цінність і чим
Speaker A
нижча а, вартість реалізації, тим привабливіша е, ця вимога, щоб використати її в першу чергу.
Speaker A
Отже, а, м, перший приклад, що в нас є, це reservation link, invitation link. Це саме е-е це посилання, пов'язане з бронюванням, через яке власник резервування, цієї сесії резервування, може запросити інших гостей до свого групового замовлення. Отже, це нам несе
Speaker A
велику цінність і вартість реалізації середня. А-а, беручи до уваги, що це була ідея покращення, а вона в нас в пріоритеті і ми робимо її першою.
Speaker A
А-а, наступне в нас є перегляд меню гостями. Отже, не буде сенсу це все робити, якщо гість, долучившись до замовлення, не може переглянути меню і обрати собі страву. Тому це несе так само велику цінність для нас і середню затратність. Отже, ми додаємо
Speaker A
його в одну з перших черг. А-а, наступне в нас є а-а можливість для власника бачити оновлення замовлень гостей в реальному часі.
Speaker A
А-а, це є середня цінність, а-а середня цінність для нашого а-а бізнес- користувача [сопіння] і середня затратність. Отже, а-а воно вписується чудово в нашу картину, але ми повинні взяти до уваги, що а-а е-е ця функція важлива, але її пріоритет
Speaker A
залежить від загальної цінності тих вимог. А-а, тому ми бачимо наступно, автоматичний підрахунок загальної загальної суми столику замовлення. Це в нас є quick win. Що це означає? Це означає, що його відносно просто реалізувати і він несе нам середню цінність, але так як його просто
Speaker A
реалізувати, ми додамо в наш список пріоритетів. А-а, останнє, що ви бачите, це підтвердження чи відмова офіціантом замовлення кожного гостя. Вона має високу вартість реалізації та середньої цінності, тому ми пропонуємо відкласти цю функцію на пізніший етап. Важливо звернути уваги при пріоритизації ваших
Speaker A
вимог, що ви не вибираєте, яка при який пріоритет вам цікавіший чи більш подобається. Ви в першу чергу звертаєте на те увагу, яку цінність несе та чи інша вимога.
Speaker A
Звичайно, така оцінка є попередньою. У реальному проекті ми маємо все узгоджувати з продакт овнером і командою, враховувати залежності, технічні обмеження, перевіряти, чи справді наші припущення відповідають потребам користувачів і т.д. Але в таких випадках також ви можете скористатися допомогою чи інструментом, як штучний
Speaker A
інтелект. Так, штучний інтелект допоможе вам порівняти цінність і затратність певних вимог, оцінити, що буде для вас квіквіном, розділити такі основні функції і ті, які можна використовувати для майбутнього покращення. Але ж в першу чергу треба розуміти, що ви не можете надати весь контекст яю, і
Speaker A
він не може достовірно самостійно визначити ці показники. Це інструмент допомоги. Він може запропонувати попередній аналіз, але ви і команда маєте узгодити, перевірити ці припущення, перевірити ці пріоритети, щоб рухатися далі.
Speaker A
Отже, AI інструмент, але все визначаєте ви і команда. Далі, наступне, з чим на що ми звернемо уваги, коли у ви вже визначилися з пріоритетами, наступний крок вам треба визначитися, скільки функціональностей вам насправді потрібно для першого запуску? Тут нас з'являється таке
Speaker A
поняття, як MVP. Тобто, уявляємо, що вам для вашого користувача потрібно розробити засіб пересування з однієї точки точка А в точку Б.
Speaker A
Тобто, і ви робите першу версію, ви її запускаєте, перевіряєте і з кожною версією ви її можете покращувати до свого ідеального продукту. Як, на прикладі від самоката до автомобіля.
Speaker A
Отже, що ж таке MVP? Це ця перша версія продукту, яка включає найбільш потрібні функції, щоб запустити ваш продукт.
Speaker A
А, основні елементи, щоб MVP працював, це чітко визначити проблему. Тобто, ваше MVP повинно покривати реальну проблему користувача. Функції, які входять в MVP, це 100% функції, які нам потрібні, так, без якого воно не запрацює.
Speaker A
А, важливість MVP це не просто демо-версія, це версія з залученням користувача. Тобто, це мінімальний набір можливостей, який дозволить користувачам спробувати це і надати фідбек, надати зворотній зв'язок, щоб вам зрозуміти, на чому сфокусуватися і що покращити в наступній версії.
Speaker A
[хекання] А, отже, взагалі, навіщо нам MVP? А, перш за все, в нас є такі основні три три причини, це перевірити наші припущення на реальних користувачах.
Speaker A
Наступне це виявити проблеми на ранньому етапі і зменшити ризики створити продукт, який не відповідає потребам користувача чи не покриває їхні потреби.
Speaker A
І третій, не менш важливий, це швидше запустити продукт, зібрати зворотній зв'язок і поступово покращити його.
Speaker A
Тобто, не очікувати і не витрачати час на ідеальний продукт, який в кінці запустити і не і, можливо, він не піде, а крок за кроком покращувати і давати реальні результати.
Speaker A
Отже, ми визначили, які функції входять в першу версію продукту, нашого MVP. Але наступний крок, це треба пояснити команді, що саме реалізувати, як має працювати кожна функція. Для цього в нас з'являються user story або користувацькі історії, такі короткі описи потреб
Speaker A
користувача, які допомагають перетворити ідею на конкретні вимоги для команд. Отже, а коли ми пишемо user story, е, ми ставимо перед собою три питання: хто наш користувач?
Speaker A
А, яка це особа, яка це роль? As a who. Е, наступне питання. Чого він хоче? Яку мету чи функцію йому потрібно?
Speaker A
І наступне питання: для чого? Яку вигоду, яка причина цієї функції? [хекання] А також це таке коротке речення, так? Але навіть дуже чітко і гарно сформована user story не відповідає на усі питання команди. Там, наприклад, що станеться, якщо посилання прострочене, або що
Speaker A
станеться, якщо юзери, е, вводять своє ім'я, чи обов'язково він має вводити ім'я? В таких випадках, щоб додати деталі до нашої user story, в нас з'являється acceptance criteria.
Speaker A
Тобто, е, критерії приймання, які описують, як система має поводитися за тих умов, за яких ми вважаємо, що функція є виконаною.
Speaker A
А-а, для опису acceptance criteria використовується дуже часто Gherkin формат, але їх існує більше. Отже, що таке цей Gherkin формат? Це коли в нас є given, when, then and end. Given ми даємо передумови, when ми вказуємо, яка дія відбувається,
Speaker A
then це є результат і end це у нас продовження, якщо, звісно, воно нам потрібне.
Speaker A
А-а, отже, user story, вони є надзвичайно важливі для команди зрозуміти функціонал. І щоб написати хорошу user story, а-а, потрібно користуватися INVEST criteria, таким своєрідним чек-лістом, щоб перевірити, що ваша user story відповідає усім вимогам. Отже, в першу чергу, ваша user
Speaker A
story повинна бути незалежною, тобто такою, незалежною від інших історій і розробка її а-а, не повинна блокувати інші задачі. Також negotiable.
Speaker A
Negotiable, а-а, гнучка для обговорення, тобто а-а, user story не є детальною специфікацією, вона задає потребу, команда може уточнювати, обговорювати, вносити зміни.
Speaker A
Ну, і найважливіше, така INVEST, а-а, з INVEST це valuable. Наша історія має нести цінність користувачу або бізнесу.
Speaker A
Якщо незрозуміло, для чого ця історія, вона не має сенсу. А наступне estimable, тобто команда повинна мати достатньо інформації, щоб оцінити обсяги роботи на тої чи іншої історії.
Speaker A
Якщо ці обсяги роботи важко оцінити, треба звернути увагу, можливо, цю історію потрібно декомпозувати на менші історії.
Speaker A
[сопіння] Ну, і от алогічно і наступне small, історія має бути достатньо маленькою, щоб бути виконаною протягом одного спринта.
Speaker A
І testable, тестованою. Мають існувати чіткі критерії, чіткі acceptance criteria, які надають змогу команді перевірити, що історія реалізована правильно.
Speaker A
Також давайте будемо рухатися далі до рекомендацій щодо написання user story. Що в першу чергу починайте user story з персони. Чітко визначайте, хто ваш користувач. Це не просто юзер, це там новий відвідувач, адміністратор, частий покупець, менеджер магазину чи тому
Speaker A
подібне. Далі фокусуйтеся на самій цінності історії, а не на функцію, яку вона виконує. Робіть їх маленькими, е-е звертайте увагу на те, щоб їх можна було протестувати, щоб команда була впевнена, що за тими критеріями в неї виконаною. Ще раз звернемося до того, великі історії
Speaker A
розділяйте, декомпозивуйте на менші. Додавайте acceptance criteria, які допомагають команді зрозуміти чіткість історії і виміряти її якість і використовувати критерій INVEST для того, щоб ваші історії працювали.
Speaker A
На ваших екранах ви зараз бачите приклад поганих і хороших історій. Отже, погані це As a user, I want notification. Як користувач, я хочу нотифікації. Який користувач? Які нотифікації? І немає основного, для чого? Так, немає цінності.
Speaker A
Наступна, As a user, I want search functionality. Який юзер? Який functionality? Для чого? Також звернемо увагу на приклад хорошої User Story.
Speaker A
As a frequent traveler traveler using the banking app. Як людина, яка часто подорожує і використовує банківські додатки.
Speaker A
I want to receive instant push notification for transaction over 100 dollars. Я хочу, що я хочу? Я хочу отримувати миттєві сповіщення за будь-які а перекази, транзакції більше 100 доларів.
Speaker A
І value для чого? Щоб я швидко міг виключити потенційне шахрайство за кордоном. А тут я ще додала acceptance criteria, але на них ми сьогодні фокусуватися не будемо.
Speaker A
Будемо рухатися далі. І наступний наш крок, про який ми говоримо, це те, що згадувалося сьогодні дуже часто, штучний інтелект. ШІ для написання User Story.
Speaker A
А коли використовуєтеся штучним інтелектом, надавайте йому контекст. Так, без контексту немає сенсу йому працювати над вашими User Story, а ми допомагати точніше вам працювати над вашими User Story.
Speaker A
Будьте специфічні щодо формату, що ви хочете, щоб він включав там acceptance criteria, описи, edge cases.
Speaker A
А який формат acceptance criteria ви бажаєте, який розмір вашої історії. А перевірити вашу User Story відповідно INVEST criteria, під задачі. А короткий опис і тому подібне.
Speaker A
А також результат, який вам видає штучний інтелект, сприймайте як чернетку. Це не є User Story.
Speaker A
В тій самій розмові, в тому самому діалозі спробуйте вдосконалювати, додавати деталі. Аналізуйте і валідуйте. А штучний інтелект, як вже сьогодні згадувалося, це чудовий інструмент у багатьох сферах і для бізнес-аналітика, але вся відповідальність за контекст і розуміння лежить на бізнес-аналітику.
Speaker A
Е-е, окей. А-а, оскільки ми вже проговорили з вами, як виглядає user story, за композицією, де ви спочатку вказуєте роль, далі, а-а, функцію, дію і тоді, для чого. Ми спробуємо, а-а, перейти до наступного слайду, на якому ви побачите нашу user story і ми е-е, яка
Speaker A
називається ініціація групу е-е груп, групового передзамовлення. Отже, ви замовили собі столик за допомогою нашого додатку і ви хочете створити, цю сесію групового передзамовлення і запросити своїх а-а, друзів, компаньйонів долучитися.
Speaker A
Вам потрібно сформувати user story. В першу чергу, вам потрібно визначитися з роллю. Отже, тут роль в нас, а-а, власник цієї сесії передзамовлення.
Speaker A
Отже, тут важливо вказати: as a reservation owner. Власник резервації. Далі, наступний крок, що я хочу. Я хочу ініціювати групове, сесію групового передзамовлення, поділитися унікальним, лінком, унікальним посиланням зі своїми друзями.
Speaker A
М-м, це ми спробуємо сформувати наступне англійською: I want. А-а, I want to easily initiate group pre-order session and share unique link with companions.
Speaker A
Наступне, для чого? So that. Ну, для того, щоб вони могли самостійно а вибрати страви і мені не доводилося вручну саме їх питати і самому вносити.
Speaker A
Отже, для чого? А so that. Угу. Could you click? Так, so that they can select their own dishes and I do not have to manually input order for them.
Speaker A
Отже, це є сформована коротко user story. А на наступному слайді ви побачите, що ми в розробці user story додавали передумови і acceptance criteria, щоб команда мала чітке уявлення, як оцінити цю user story і зрозуміти, за яких умов вона вважатиметься виконаною.
Speaker A
А з Хочу тут відмітити, що саме на цьому проекті user story ми писали у такому free format, не використовували Gherkin.
Speaker A
It's up to you, це залежить від вас, від вашої команди, обирати, в якому форматі вам зручно.
Speaker A
Отже, це була user story зі зв'язана з власником оцього групового передзамовлення, який [сопіння] ділиться з своїми гостями лінком, посиланням, за яким вони можуть перейти і зробити замовлення.
Speaker A
Тому а прошу звернути вашу увагу а на наступну user story, яка з'явиться на вашому екрані.
Speaker A
Це user story вже гостя, гостя, який доєднується за цим лінком. А у вас тут є текст а з тим же форматом user story, з яким ми говорили. Спочатку роль, as a guest.
Speaker A
Далі для чого? А що ми хочемо? А I want to see the full restaurant menu, я хочу бачити повне ресторанне меню.
Speaker A
І а-а м-м так хвилиночку так тут а-а user story, я, як гість, без акаунту, без облікового запису.
Speaker A
І я хочу відкрити цей лінк, з яким зі мною поділилися, а далі причина, для чого, so that, для того, щоб я міг, негайно зробити якесь меню, почати замовляти без реєстрації.
Speaker A
Так, тут ми можемо також показати, які в нас були передумови, acceptance criteria. Ще раз звертаю вашу увагу на формат, as a, коли в нас є роль, хто наш user, далі для чого, I want to, і користь, причина, so that, для того.
Speaker A
Отже, а-а, надіюся, вже ми багато всього прослухали і прийшов час для вас спробувати так, себе в такій ролі бізнес-аналітика.
Speaker A
Отже, що в нас тут є на екрані? В нас на екрані є user story, guest viewing reservation menu.
Speaker A
Отже, тут, а-а, роль користувача, як гостя, без акаунта, без облікового запису, е-е, без облікового а-а, акаунту так.
Speaker A
А що далі ми маємо сказати, що я хочу зробити, я хочу переглядати ресторанне меню і наступне вказати причину, для чого, so that.
Speaker A
А пригадуємо, ми дотепер користувалися Mentimeter-ом, так? А ви можете знову взяти ваші телефони, відсканувати QR-код і спробувати самостійно написати невеличку user story, де у вас є роль as a guest, далі ви вказуєте, що ви хочете, I want to
Speaker A
і наступна частинка для чого, so that. Я думаю, що ми вам дамо хвилинку-дві трошки замовкнемо щось надрукувати і подивимось на результат.
Speaker A
Окей. [хекання] Чудово. Я бачу у наших user story є ще додаткові питання, є роль as a guest, як українець, as a guest, а є що я хочу, I want і навіть причина для чого.
Speaker A
Так, в нас тут є одна user story, яка просто прекрасно виділяється в контексті нашої реальності.
Speaker A
Як користувач цієї бібліотеки, я хочу зайти в систему і побачити список по жанрам для того, щоб. Так, чудовий формат, у вас є роль, що я хочу і для чого.
Speaker A
Як незареєстрований. Чудово. Угу, дякуємо вам за ваші відповіді. Давайте ще переглянемо. Ам. Це чудово, що всі, ніхто не забув роль.
Speaker A
Це вже у всіх сторі, які я детекнула, є I want частинка. І яку ж користь нам приносить це I want?
Speaker A
Show that. Я а надіюся, а Марина і Ігор теж погодяться, що well done. Чудово виконано.
Speaker A
Угу. Окей. Ам. А хочу а переламати трошки інтригу. Ось тут ви бачите наш результат user story. As a guest I want to see the full restaurant menu, so that I know what options are available and can decide what to choose. Як гість, хочу бачити
Speaker A
повне ресторанне меню, для того, щоб знати, які в мене є опції, що доступний і міг вирішити, що обрати.
Speaker A
Ам, отже, user story це така ам теж значна частина в ам в цьому містку між а [сопіння] клієнтом, користувачем, бізнес-аналітиком і командою розробників.
Speaker A
Тому а Марина має для вас домашнє завдання, де ви зможете покращити ам ці навички. Марина.
Speaker A
Так, бачу. Всім привіт ще раз. Да, я тут. Тож, давайте переходити вже до завершення.
Speaker A
Ви з Анастасією розглянули user story, власне на функціональність генерації лінки, на можливість гостю зайти за даною лінкою і побачити деталі резервації, плюс сказати своє ім'я для того, щоб и е-е, user, який ініціював це бронювання, зрозумів, власне, хто з його гостей що
Speaker A
по собі передзамовив. І остання story, яку ви писали разом, це була можливість переглянути меню, так? Але коли наш гість зробив е-е передзамовлення, ми маємо якимось чином відобразити всі передзамовлення всіх гостей для того юзера, який, власне, створив бронювання, для того, щоб и він
Speaker A
разом зі своїм пріордером сабмітнув груповий пріордер і його отримав офіціант. Тому власне ми пропонуємо вам вдома подумати і задокументувати саме цю user story.
Speaker A
І також хочу наголосити вашу увагу на тому, що саме над цією функціональністю ви будете працювати і надалі по всім іншим напрямкам.
Speaker A
Тобто, саме для функціональності ось цього консолідованого е-е перегляду юзером групового передзамовлення ви будете далі працювати в плані дизайну, в плані імплементації.
Speaker A
Тому наразі я все ж таки дуже хочу, щоб ви детально продумали, що ви хочете включити у вашу фічу.
Speaker A
А можливо, ви хочете додати щось таке, до чого ми самостійно навіть і не прийшли. Можливо, ви хочете розширити цю функціональність якимось якимось чином. Тому наразі саме ось на цьому першому етапі продумаєте ті вимоги до цієї функціональності, які ви далі
Speaker A
будете самостійно реалізовувати в ході роботи над е-е вашим додатком, да, над вашою новою фічею.
Speaker A
Тому вашим домашнім завданням буде створити user story з acceptance критеріями обов'язково, тому що інакше ви ніяк не зрозумієте, що ця вимога є виконаною.
Speaker A
Ви можете записати user story е-е в будь-якому зручному для вас додатку. Це можуть бути Google документи.
Speaker A
Але, якщо ви використовуєте Google документи, не забудьте, будь ласка, відкрити доступ до документу, для того, щоб можна було потім перевірити.
Speaker A
Е-е якщо у вас це є, не знаю, якісь е-е можливо там до цієї story передумови певні assumptions, все це додавайте в user story, тому що надалі ви будете з нею, можна сказати, працювати протягом всього нашого марафону.
Speaker A
Ось так. Тож ваше перше домашнє завдання. І на цьому давайте будемо вже завершувати. Пропоную кожному з вас або просто тому, хто хоче поділитися що було цікавого що ви дізнались нового протягом нашої лекції що запам'ятали найбільше давайте подивимось перевіримо так так скажімо що наша з
Speaker A
вами зустріч вона пройшла недаремно да що щось все ж таки чомусь ми навчилися більше про роботу бізнес-аналітика окей багато англійських слів цей коментар мені подобається і я хочу тут прокоментувати що насправді бізнес для бізнес-аналітика рівень англійської дуже важливий тому що
Speaker A
бізнес-аналітик згадуємо да це та людина яка комунікує з бізнесом дуже часто замовники можуть бути з різних країн і власне для бізнес-аналітика як мінімум потрібний рівень B2 а пер інтермедіат якщо хтось планує розвиватися в напрямку бізнес-аналізу дуже раджу працювати
Speaker A
вчити англійську окей захочу стати бізнес-аналітиком клас я рада наші ряди поповнюються користувацька історія супер бачите тепер зможете в домашці знання використати сторін акцептенс критерія how to use AI клас я рада дуже багато від- відповідей що таке MVP та SWOT клас бачите ви навіть
Speaker A
абревіатури вже використовуєте яке ДЗ ДЗ на ми коли попередньому слайді було, я думаю, що зараз Єгор ще прокоментує.
Speaker A
Буде продубльовано в телеграм-каналі. Що я повинен робити? Не сьогодні відпочивати, а взагалі зробити домашнє завдання і прийти на наступні лекції.
Speaker A
Окей. Так, дуже вам дякую за відповіді, дякую за ваш час. Буду передавати слово Єгору, тому що я думаю, що в нас достатньо багато ще є запитань. Давайте пройдемося по ним.
Speaker A
Єгор. Так, так. Я по-перше дякую вам за виступ. Та і відповідно дуже приємно, що ми стартанули. Я думаю, ми зможемо частково повідповідати питань на питання, проте давайте так подивимось на те, що було в чаті. В мене, до речі, було одне питання, я собі
Speaker A
його зберіг з чатику, хотів так щоб ви там порадили, так? Питання стосовно а не було AI Tool Leaf або порівнянню типу з конкурентами, що ви б порадили там, мені воно сподобалось, я з пам'яті більше.
Speaker A
Окей, да, я бачила це питання. Щось на кшталт який інструмент ви можете порадити для аналізу конкурентів, інструмент штучного інтелекту.
Speaker A
Насправді ви можете використовувати будь-який інструмент, можете почати з звичайного чату GPT, можете рухатись далі, там перейти на Claude. Можна взагалі будувати агенти, яким ви будете задавати певний контекст, можете використовувати для цього Copilot, GitHub GitHub Copilot.
Speaker A
Інструментів маса. Мабуть, найголовніше, що я тут підкреслюю що почати варто не зовсім з інструменту, а почати варто з класного промпта. Треба зібрати достатньо велику кількість контексту для того, щоб штучний інтелект зміг все це проаналізувати.
Speaker A
Плюс потрібно чітко ставити задачі штучному інтелекту. Потрібно, можливо, дати приклад того аутпуту, який ви хочете отримати. Якщо ви хочете отримати таблицю з вашими перевагами, недоліками, opportunities та загрозами, ви маєте чітко вказати в вашому промпті, що ви очікуєте результат саме такий. Тобто, я
Speaker A
відповім так, що, можливо, почати треба саме не з класного інструменту, а з вміння складати дуже якісні промпти і надавати необхідну кількість контексту.
Speaker A
Так. І також тут можна експериментувати моделями і з температурою. В принципі, для генерації, наприклад, ідей, якщо ми кажемо, там дуже класно буде підняти температуру там, не знаю, майже на одиницю, тому що температура, вона відповідає за креативність відповідей моделі. Коли ми генеруємо
Speaker A
ідеї, креативність нам знадобиться, да? Якщо ми базуємося тут на аналізі, тут можна температуру зменшувати, там тут не потрібна креативність, нам треба достовірний аналіз явних фактів. Тому грайтеся з моделями, грайтеся з налаштуваннями.
Speaker A
Добре. Давай так намагатись більш стисло відповідати. Було питання, де можна буде задати питання поза межами ефіру. Є телеграм-канал, там є у вас чат, чат відкритий, відповідно, якщо у вас питання до якогось ну, по якомусь блоку там і задавайте питання, тобто під
Speaker A
постом чи під домашньою про бій частину, там можете писати, ми також будемо там відповідати на питання.
Speaker A
Стосовно домашніх багато повторилось питань, ще раз повторюємо, в телеграм-каналі буде після завершення цієї зустрічі інформація стосовно домашнього, де можна знайти презентацію, лінка на запис і куди відправляти домашнє завдання з дедлайном, тому можете чекати.
Speaker A
Стосовно репозиторію, репозиторію напряму ми давати вам не будемо, коли буде частинка по архітектурі і devops частина, тобто це буде середа-четвер, вам буде наданий zip-архів з інструкцією по розгортанню, ось так.
Speaker A
Мм. Так, так. Зараз, так. Тепер а я дивлюсь а ще є це на YouTube.
Speaker A
Так. Про запис вже відповів. Давайте питання до по бій частині, чи є до експертів питання?
Speaker A
Бо я бачу багато де аналітики беруть інформацію, не знаю. А в залежності від того, ну, Марин, можеш Про яку інформацію?
Speaker A
Та, ну, цікаво, яка інформація? Ну, якщо треба зрозуміти бізнес-процеси, то треба шукати власне продукт-оунерів, да, спілкуватися з закупними юзерів. Все залежить від того, яка інформація треба.
Speaker A
Знову ж таки питання user story треба саме щодо ресторану писати чи а завгодно В домашці по ресторану, а в житті пишіть будь-яке.
Speaker A
Так, дедлайн домашнього знову ж таки ця інформація буде в пості. А так Так, ну, відверто я поки а у Я бачу ще одне питання, а де бізнес-аналітики беруть контекст, файли, дані про бізнес?
Speaker A
А Власне, коли ви приєднуєтесь на проект, якщо це існуючий проект, імовірніше за все, там є певна документація. А якщо це наявний застосунок, є кодова база даного застосунку, яку також можна використовувати для того, щоб штучний інтелект зміг на базуючись на даній кодовій кодовій базі,
Speaker A
також підхайлайтити вам певні ролі, певні обмеження, які є в системі. Тобто працюємо з усією наявною інформацією, документацією на проекті.
Speaker A
А та а Там ще є а питання чи можна приклад того, що саме BI надає щі для того, щоб згенерувати user story?
Speaker A
В нашій презентації в нас є приклад промпту який можна надати, ну, який ми використовували. Можете його брати собі за основу, від чого відштовхуватися.
Speaker A
Е-е. Так, е-е мова англійська або е-е або українська, так, Марин? Е-е будь-яка, ну. Взагалі, в правильному житті, працюючи бізнес-аналітиком, скоріш за все буде англійська. Наразі ви можете прописати user story українською, це не проблема для нас.
Speaker A
Так, було тут якесь е-е питання, е-е ви казали, що ми маємо написати user stories, з якою маємо працювати протягом всього марафону, але ми не бачили е-е проект. Е-е Марин, можеш ось це прокоментувати?
Speaker A
Ну. Е-е можу, да. Для того, щоб написати user story для нової функціональності, вам не потрібно бачити проект. Ви формуєте вимоги для нової фічі, над якою ви будете працювати.
Speaker A
Так, тобто тут е-е основна задача, знов-таки, якщо ви будете робити саме е-е ту фічу, яка буде в рамках там тут тут питання ще ще яку фічу ви берете. Якщо ви берете е-е ту, яку е-е ми е-е там пропонуємо, так,
Speaker A
відповідно, в такому випадку ви там її пропрацьовуєте. І якщо ви будете брати якусь фічу іншу, е-е то відповідно Так, не не так. Якщо ви берете нашу е-е фічу, то в такому випадку, у будь-якому випадку, ми там пошаримо той самий
Speaker A
дизайн, наприклад, так, і і тому подібне. І і і домашки е-е вони будуть там допомагати е-е реалізувати е-е ось той е-е функціонал. Якщо ви берете там своє, то тоді ви взагалі там з нуля. І на цьому етапі вам головне
Speaker A
просто спробувати. А-а, так, коли чекати пост? Як тільки завершимо зустрічі, коли ми це все погодимо.
Speaker A
Так. Бачу цікаве питання про обов'язки ПМ-а, а Project Manager-а. Не розглядали роль Project Manager-а сьогодні на лекції, але в цілому роль Project Manager-а потрібна для того, щоб відповідати за дедлайни, за ресурси проекту в тому м-м, ну, в тому вигляді, в якому вони
Speaker A
погоджені замовником. В той час бізнес-аналітик, він працює з реквайрментами, тому тут достатньо різні обов'язки. Інколи вони можуть перетинатися, наприклад, коли ми кажемо там про певні ризики, про їхній аналіз.
Speaker A
Але роль ПМ-а, да, це робота з ресурсами. І з дедлайнами. М-м. Так, добре. Можливо, ще а-а, є якесь питання, яке подобається?
Speaker A
А-а, так, чи можна Я бачу питання про м-м сорси в Телеграмі, презентація або лінк на сайт. Думаю, що це має бути, так, Ігор?
Speaker A
Ще раз? Е-е, сорси, презентації. Знову ж таки, все, все буде в Телеграмі. Ну, як тільки завершимо зустріч, тоді воно все й буде.
Speaker A
Ну, плюс-мінус там 20 хвилин. І ще цікаве бачила, по факту User Story це творча ідея бізнес-аналітика.
Speaker A
Не погоджуюся. Тут ми говорили всю лекцію, в принципі, про те, що user story це кінцевий артефакт, який ми отримуємо після того, як ми проаналізували вимоги, після того, як ми узгодили бізнес-вимоги з бізнесом, тому user story це документальне відображення
Speaker A
вимоги. Так, це творча ідея. Так, добре. Так, я думаю, що ми можемо на цьому вже завершувати. Давайте ще раз повторимо там основну інформацію, так?
Speaker A
Зараз після завершення, впродовж там до 30 хвилин, ви отримаєте пост, де будуть буде папка з презентаціями, які ви зможете переглянути, подивитись.
Speaker A
Там будуть всі дедлайни, там буде вся інформація по виступу. По-друге, там буде окремо описане домашнє завдання, дедлайн до до домашнього завдання, посилання, куди ви можете надати своє домашнє завдання. Тобто, там буде вся ця інформація.
Speaker A
Ну, і відповідно, вже там завтра будемо чекати вас на наступній зустрічі, там буде фокус саме на дизайн-частині.
Speaker A
Ось так. Тому, я думаю, що можемо вже потроху на сьогодні завершувати на зустріч. Марина, ще раз дякую тобі за твій час, залученість.
Speaker A
Дякую за те, що долучились до сьогоднішньої зустрічі там нашій аудиторії, і будемо чекати вас на дизайн-частині завтра.
Speaker A
Дякую. Дякую всім. Успіху на наступних лекціях і з домашнім завданням. Так. Всім па-па.
Topics:EPAMмарафон IT-технологійбізнес-аналізScrumнавчальні програмиEPAM Campusрозробка ПЗIT-освітадомашні завданняштучний інтелект
