Post by Andrii Pavlov

Product Manager at Projector Institute | Building tech, operational and AI-first infrastructure | Tutor and Mentor

Продовжую серію про системне мислення в продукті. Минулого разу – бачення пересічення двох систем. Цього разу – інженерія на прикладі Ч.4 серії "Як знайти відсутню сутність – і як вона стала точкою перетину всього продукту Projector Institute". Сьогодні про те як та сама сутність tutor допомагає збагачувати систему даними та новими користувачами, щоразу коли хтось записується на менторську сесію. Проста реалізація vs. правильна реалізація Щоби виконати запит бізнесу "хочемо мати всі дані з наших продуктів" можна було рухатися звичайним шляхом – фіча as is: Отримати список із mentorship-платформи про кожен запис на сесію. Технічно – 2 години роботи. Виглядає як рішення. Щось збираємо. Але що ми отримали б? Набір даних відокремлених від екосистеми: "Віктор Я. записався на менторську сесію до Віктора Ю." Це текст. Не зв'язок. Система знає що сесія була – але не знає хто ці обидва Віктори в екосистемі Projector. Вони існують як рядок тексту, а не як сутність. Правильний варіант – кожна сесія ментора стає частиною графу знань його як персони. Якщо такої персони немає – вона створюється, і дві системи обмінюються ідентифікаторами. Таким чином всі подальші дії прив'язуються до конкретних профілів. Щоби це відбулося потрібно: а) наповнити тюторів вже існуючими менторами і обмінятись ідентифікаторами. б) засетапити те саме щоб відбувалося автоматично при появі нових менторів у mentorship (повага та лаври Valerii Zinchenko за сетап передачі даних з Mentorship). Projector відіграє роль приймача даних. Як спроектована логіка: Бекенд Projector отримує сигнал з mentorship: нова менторська сесія + набір даних по тютору (id в mentorship CMS, email, ПІБ) та по менті (email, ПІБ, запит). Бекенд перевіряє чи є в системі такий тютор і такий студент. Якщо когось немає – система їх створює: - створюється тютор, якщо його не було - створюється студент (користувач), якщо його теж не було Система тепер знає між ким утворити зв'язок менторської сесії – і дозаписує ці дані. І що ми маємо? а) нові користувачі-студенти (і з origin що вони приведені з Mentorship platform) – привіт, маркетингові можливості б) нові персони тюторів – без жодного ручного внесення в) профіль тютора збагачується контекстом менторських сесій г) профіль студента – теж І наступного разу, коли цей тютор або студент матимуть БУДЬ-ЯКУ активність у Projector – все доповнюватиметься в ці профілі. У тютора: викладання на курсах, групи, статті в блозі, івенти, амбасадорство. У студента: реєстрації на курс, оплати, навчання, інші менторські сесії. Таким чином ми отримали тунель де одразу стають доступні цілий ряд знань. student → менторська сесія → tutor. І цей tutor вже пов'язаний із курсами, групами, іншими студентами, іншими сутностями. Наочна різниця між "кинути дані у базу" і "вписати дані в сутність". Це як різниця між логом який треба ще розплутувати і AI-ready стабільними і доступними знаннями. #productthinking #systemdesign #edtech #dataarchitecture #projector #dataengineering

Post content