1. Вчіть обох аналітиків робити те саме, нехай вчать один одного, зробіть спільну систему мотивації, щоб були в цьому зацікавлені, в спільній роботі, в успіху один одного.
2. Те що компанії викатують список раз на квартал — це то як ви з ними домовились. Тому Ideation портал на якому вони можуть це постійно, on the go робити — це в першу чергу для них користь. І тут вам треба цю ідею їм продати, донести що так краще, в першу чергу для них. І це вже ваша робота, знайти спосіб це робити. Вцілому збирати раз на квартал фічі, не є зручним для замовника (сам таким є). Тому або щось пропустили у відносинах або ще не постарадлис достатньо щоб їм донести ідею що це їм не вигідно.
3. Про пріорітизацію — це не rocket science, або у вас зовсім не ті люди подають вимоги зі сторони замовника (наприклад vendor manager збирає і шле їх, замість того щоб це робили архітектори і products, від замовника, це як приклад) або ж дивно що люди не розуміють що платити за те що не потрібно не дуже корисно для компанії. Тут дуже імовірно що люди які збирають та подають вимоги не вмотивовані зробити це якісно і в успіху/користі своєї ж компанії. Тому треба шукати тих людей, зі сторони замовника кому це потрібно. Ще варіант що «ви» (аналітики та products) погано розумієте замовника, доволі поверхнево і сильно довіряєте тому що вони приносять.
В умовах сказано що типи контрактів міняти не можна, але бажано прояснити чому замовники приносять нові фічі раз в квартал. Немає проблеми з моделлю оплати поквартально, але потреби в останній день кварталу не народжуються. Тож перше проблема: зробити так щоб комунікації відбувались не поквартально а замовники приносили іічі як тільки дізнаються про них.
Автоматично після стає найважливішим питання пріоріттзації, як виявити ті 10%. Для цього є різноманітні інструменти, і дійсно треба вибирати те зо найбільш корисне більшій кількості замовників а також враховувати вартість розробки окремих фіч (читаємо WSJF). Це типові питання продуктової розробки, нічого особливого.
Чи є ideation portal, щоб замовники самі пріорітизували? Дивним трохи є відділення R&D, ваша efficiency криється в тому щоб вони розробили саме те що проситимуть чи буде потрібно замовникам. І якраз для цього потрібен ideation portal та регулярні комунікації з замовниками.
Окреме питання, навіщо дворівнева систематизувати ВА, чому не зробили двох аналітиків котрі роблять те саме, але з різними скопом замовників і вже разом допомагають пріорітизуватитєдиний беклог. Тоді вони перестануть жалітись один на одного, одного розвантажите, інший отримає можливість сам зробити (те що треба і як треба), жалітись перестане.
P.S. може так виявитись, що зміна моделі оплати vs доставки замовнику не тільки вам життя спростить, а і самому замовнику більше користі принесе, і вони будуть більш задоволені. Треба сміливішими бути. Communicate, communicate, communicate.
Поділитеся аналізом по Турції?
Роберте, цілком слушне питання/бажання розуміти чому вибір саме такий. Постукайтесь до мене у Fb, надам інформацію.
Система є модульною, збирається з модулів з необхідними ТТХ, ви посилаєтесь на загальний маркетинговий опис, і він не співпадає з конфігурацією яка нас цікавить. Якщо цікавлять деталі — сконтактуйте мене у Facebook.
Наступний вартує на бойового робота?!
На поплаві якраз про «рушниці» казали, що на них не вартує витрачати кошти, бо там дуже обмежений сценарій використання. І в першу чергу, дрон треба побачити вчасно (якомога раніше). І якраз це питання закривається SKYCtrl. А в залежності від того який дрон — потрібна різна зброя.
Чи вірно розуміти що розмістивши будь яку ERP у цій хмарі вона теж починає відповідати вимогам КСЗІ?
Стоит прояснить, это в нормальном режиме происходит или при появлении срочных задач. Если в нормальном режиме, то в лучшем случае — вам платят за ваше хобби и стоит это осознать и получать удовольствие, в худшем — у вас развивается синдром менеджера, когда даже ночью работа снится.
а чем плох вариант ?
При цьому, є імовірність що цього можна досягти без перепідписання контрактів.