Чи можна зробити в питанні про вищий навчальний заклад можливість вводити текстом, якщо заклад не із вже підготовленого списку (так само як і для поточної компанії)?
Я бізнес аналітик в аутсорсі (так зване безтолкове проксі). Щодо персони РО, то абсолютно підтримую TechnoBarbarian:
1) якщо власник продукту не може прийняти рішення, а йде до когось по рішення — це не власник (навіть якщо в нього позиція РО).
2) якщо власник продукту технічний (не через домен продукту, а тому що виріс в продукті), то це і добре і погано, бо він вже не кодить і втрачає кваліфікацію, і його поради можуть шкодити реалізації + він тратить час не на свою роботу (як вже десь згадувалось)
3) а от якщо власник продукту не знає, як має продукт заробляти гроші, то це вже біда... і те що він може сам написати всю архітектуру і код, не допоможе продукту вижити.
Тому, як вже підмічено, у вас або проксі РО (але він тоді має приймати хоч частину рішень без уточнень з РО), або БА, який має зібрати всі питання\пропозиції в команди (зрозумівши його), устаканити бізнес рішення із замовником і вернутись з вимогами по реалізації. І от бізнес аналітик, може бути більш технічним, якщо цього потребує команда (іноді виділяють окрему роль як системний аналітик). І от основна задача аналітика зрозуміти що хоче бізнес (наприклад в лиці РО, або інших стейкхолдерів), в якому форматі команді зручно отримувати задачі і сформулювати бізнес вимоги у форматі зручному для команди.
Оскільки, замовники дуже часто англомовні, тому першим важливим елементо для розуміння бізнесу є англійська, тому в певний час, прийшло дуже багато людей, які знають англійську... і це допомагає у роботі з Клієнтом, але ускладнює роботу з командою. Для того і придумують всякі фреймворки, якими можуть користуватись і розуміти обидві сторони. Але якщо вимоги неякісно зібрані, то це недуже допоможе.
Якщо у вас є проблеми з вимогами, чи вам доводиться напряму комунікувати з стейкхолдерами і то не через те, що вони хочуть особисто вас похвалити, то це не якісна робота бізнес аналітика.
Поки команда робить продукт, то БА має підчищати всі невизначеності і спрощувати життя команди, а не навпаки.
З мого власного досвіду, я не є (принаймні не вважаю себе) з технічним бекграундом, але завжди вникаю в проблематику, щоб при спілкуванні з стейкхолдерами підібрати правильні слова і отримати результат від комунікації.
можна було б зробити запис презентації, поставити проектор, колонки, а самим сісти віддалено працювати у навушниках)
як на мене, могли б вже не самі тримати таблички, а на дрони підвішити чи на сігвеї поставити...
гарна історія)))
суть не в наявності/відсутності посади хепіменеджера, а у відношенні компанії до працівників та її бажанні завоювати їх лояльність до себе.
Компанія погано відноситься до працівників, тоді мабуть там буде «правильний» менеджер, який любить коли всі перепрацьовують по +8 год без оплати за це.
якщо компанія поважає своїх працівників, то вона старається організувати каву, фрукти, обіди, навчання.
Ну і рівень вище, це коли компанія хоче задовольнити більшість потреб працівинків, тоді появляється хепіменеджер, з якого можна потім і спитати: «чому люди почали звільнятись?», якщо раптом кава в кавомашині закінчиться)))
Як на мене, то для працівника в ситуації коли є вибір між:
— 800 уявних з хепіменеджером + розвиток + хорошу атмосферу + дружній колектив + кофорт + плюшки + івенти...
— 1000 уявних з менеджером який починає день зі слів «хто з вас муд**ів сьогодні мусор виносить?»
Є два варіанти:
1) коли мені для життя потрібно 500 уявних, мабуть я виберу хепіменеджера
2) коли мені для життя потрібно 1000+ уявних, мабуть я буду виносити мусор у і шукатиму на сайтах роботи як мінімум таку ж оплату, але з надією на кращі умови/відношення і т.д.
UX→BA→Customer
В даному випадку більше варіантів для скорочення ланцюга: User→QA→Dev→UI→UX→BA→Customer
І в залежності яку «ланку» ми скоротимо, іншому доведеться виконувати його обов’язки.
В моєму випадку дуже часто бувало:
User→BA→Dev→BA→BA→BA→Customer
але я не претендую на роль дизайнера (через відсутніх профільних знань), а тестування не покриває весь функціонал (через відсутність часу для повноцінного тесту).
Але оскільки графічний інтерфейс у описаних варіантах для Клієнта не несе ніякої цінності (для внутрішнього використання), а UX вимірюється в часі затраченому на операцію в розрізі цільного бізнес-процесу (причому процес потребує значно більшої оптимізації чим інтерфейс), то для цих задач достатньо (і можливо більш цінною буде) роль BA.
Також, в зворотньому:
«приходить клієнт і каже, в мене є магазин, він не продає через сайт вообщє» — цитата від друга дизайнера, з яким ми почали «сперечатись» через коменти в статті)
то тут я теж можу поробити дослідження, застосувати методики, ...., але більш цінним буде навички і досвід UX/UI.
Хочеться зробити порівнялю табличку із чотирьох стовчиків:
— скарга
— іт сфера (+/-)
— інші сфери (+/-)
— коментар (деякі скарги варті більшого)
Але оскільки за це нема ніких плюшок (хіба «льщів» в коментах наловлю) і не доплатять))), то залишу вас «біситись з жиру» в тому ж «іт-лайні» в яке ви самі залізли)))))
невелика розбіжність між інфографікою та описом
в описі:
в інфографіці: