Вы абсолютно правы. Это системная ошибка №1. Delivery менеджер - это тактик. Его ключевая цель - выполнить скоуп в срок и бюджет. Его мышление "Как что-то сделать?". PO - это про ценность для бизнеса и рост. Его мышление "Что делать и почему?". Назначить delivery-менеджера на роль PO и ждать от него продуктового мышления. Это провал. И наоборот тоже. Если нужен деливери, а вы нанимаете продакта - тоже ничего хорошего. В статье я как раз и хотела ввести некоторые критерии того, кто на самом деле нужен и в каких условиях. Продуктовая трансформация подразумевает, что надо выстроить процессы, где ключевые роли правильно подобраны под команду. Создать гибридную модель на уровне команды не только можно, но и необходимо. Это и есть ответ на вызовы сложного Enterprise.
Все низковисящие плоды уже сняли, я думаю. Сейчас PO нужен 1) для точечной оптимизации и выжимания эффективности (поэтому важно знание домена и процессов). Лучший способ конкурировать в красном океане - иметь лучшую экономику. А это часто упирается во внутренние продукты процессы и сервисы (тут как раз полезен деливери кстати), 2) для борьбы за лояльность и удержание. В красном океане дешевле удерживать текущих клиентов, чем искать новых. Продуктовая работа смещается с привлечения на удержание и углубление монетизации. Хоронят не профессию, хоронят её неправильную, сказочную интерпретацию. Хоронят миф о «визионере-гении», волшебнике за 200 тыс руб в месяц, который по наитию придумывает новый iPhone. Такой действительно не нужен да и нет таких. Нужен "продакт-инженер": системный, data-driven специалист, который умеет считать деньги, находить точки роста и точечно оптимизировать сложные системы. Такой специалист нужен сейчас как никогда.
Привет! Это очень зависит от компании. В целом есть тренд на оптимизацию с учетом эффективности сотрудников. Что такое эффективность в продуктовых компаниях - это влияние на выручку, прибыль, активную базу.
Исходя из 4 месяцев работы с ChatGPT могу сделать вывод, что промты хорошо работают на синтез информации, введенной вами, например, транскриптов интервью или внутренних документов. Что касается использования открытых источников, то тут всегда нужно "включать мозг" и по возможности дополнять экспертными интервью.
User Avatar — очень двусмысленное понятие. И в разных источниках оно интерпретируется по-разному. Часто аватар является синонимом персоны. Но иногда под аватаром просто понимают изображение пользователя, что близко к системному аватару (картинке). В маркетинге под аватаром понимают персону покупателя (buyer persona). я не советую использовать этот термин в виду его двусмысленности.
добрый день!
мы используем их только внутри компании. При этом они составляются исходя из реальных интервью с пользователями, которые затем интерпретируются.
добрый день!
выводов можно сделать много. я дальше буду писать на эту тему. в одной статье все не уместишь))) можете подписаться на канал, там я заметки тоже публикую t.me/bpmcafe
Я рекомендую применять анкетирование при использовании стандартизованных методик, например, SWOT-анализа.
При правильном проведении мозгового штурма участники должны получить формулировку проблемы, продумать изолированно друг от друга варианты решений и выбрать, на свой взгляд, наиболее подходящие. Когда команда соберется вместе, все предложения будут исследованы, появится возможность видеть все точки зрения и индивидуальные уровни рассмотрения проблемы, таким образом, это способ не только принятия, но и получения информации.
2) Рисую конечно, но в российских условиях, работая в отрасли, понимаю, что скорее для себя, а не для заказчика. ARIS — это не диаграмма, а методология, включающая в себя нотацию epc, которая считается наиболее понятной бизнес-пользователям. На самом деле даже ее многие не понимают. IDEF не использую вообще и никому не советую. UML — нотация для разработки ПО, раньше рисовала в ней, сейчас нет, так как занимаюсь внедрением.
3) иногда решение принимается той же группой, что участвовала в мозговом штурме, но чаще всего отобранные идеи передаются руководству для принятия решения. Все предложения делятся на группы: пригодные, непригодные, спорные, или используется рейтинг. Можно задействовать метод от противного: если идея будет реализована, то что может быть причиной ее провала, каких она требует затрат?
4) практические семинары (еще их называют иногда диагностическими). Есть такое тоже. Обычно провожу их с топ-менеджерами.
5) прототипы не создаю, так как работаю не в сфере разработки. Если и делаю, то в виде пользовательских историй.
1) очень хороший вопрос. Ответ на него неоднозначный. Исходя из опыта моей работы могу сказать, что это зависит от того, где ты работаешь. А я работала на обоих сторонах баррикады — и в разработке ПО, и при его внедрении. Так вот могу отметить, что в разработке обычно всегда используют либо ПО (например, RequisitePro, wiki). На стороне заказчика при внедрении ПО обычно пишут ТЗ. Причиной тому является необходимость согласования этих требований по внутреннему регламенту заказчика, соответственно все заинтересованные лица должны поставить свою визу. Для разъяснений в этом случае используется Outlook. Что интересно, что и в первом и втором случае эти техники, с моей точки зрения, неэффективны из-за частого изменения требований и нежелания вдумчиво читать тонны документации.
Разрабатывая схемы бизнес-процессов для последующей автоматизации я пришла к выводу, что существенно облегчает работу так называемый Social BPM, когда документирование и изменение регламентов и документов идет параллельно со всеми согласованиями и проектированием.
Приведу пример:
Документация процесса происходит с помощью привязки к модели:
Собственно само описание процессов с комментариями заинтересованных лиц и решениями на совещаниях:
вы можете попробовать несколько сайтов, по опыту могу сказать, что мне понравились вот эти:
1) www.englishtips.org — много литературы на английском
2) www.study.com — полезный сайт с материалами и вообще с кучей информации для изучения английского
3) www.livemocha.com — социальная сеть, тут можно найти друга из другой страны.
4) www.lingvotime.com — сервис для поиска преподавателя онлайн
5) www.eslpod.com — тут можно скачать подкасты
сколько людей, столько и мнений. Я не буду с вами спорить. В моей практике я никогда не использовала EPC для описания IT инфраструктуры, для этого есть специальная нотация под названием IT infrastructure. Но вообще мне кажется в данном случае удобнее использовать UML.
У меня к вас встречный вопрос- что вы предлагаете использовать для описания workflow вместо EPC? И для кого неудобна? Для программистов наверно неудобна (нет технической детализации), для заказчиков — то, что надо.
workflow — это не нотация, так называют бизнес-процесс (в дословном переводе с английского означает поток работ /операций). Для того чтобы описать процессы для их последующей автоматизации используют различные нотации.
Я думаю, что существует принципиальное отличие Aris от Visio. Во-первых, многократное использование объектов за счет репозитория. Это как раз экономит много времени, потому что Вы можете каскадно изменять объекты, и эти изменения будут учтены во всех Ваших моделях. Многопользовательский доступ позволяет другим пользователям использовать Ваши объекты, то есть соблюдается целостность на уровне всех бизнес-процессов компании.
Во-вторых, Aris — это не в первую очередь не инструмент моделирования, а методология, поэтому все модели связаны между собой и представляют описание архитектуры всего предприятия, не только бизнес-процессов.
Вы абсолютно правы. Это системная ошибка №1. Delivery менеджер - это тактик. Его ключевая цель - выполнить скоуп в срок и бюджет. Его мышление "Как что-то сделать?".
PO - это про ценность для бизнеса и рост. Его мышление "Что делать и почему?". Назначить delivery-менеджера на роль PO и ждать от него продуктового мышления. Это провал. И наоборот тоже. Если нужен деливери, а вы нанимаете продакта - тоже ничего хорошего. В статье я как раз и хотела ввести некоторые критерии того, кто на самом деле нужен и в каких условиях. Продуктовая трансформация подразумевает, что надо выстроить процессы, где ключевые роли правильно подобраны под команду. Создать гибридную модель на уровне команды не только можно, но и необходимо. Это и есть ответ на вызовы сложного Enterprise.
Все низковисящие плоды уже сняли, я думаю. Сейчас PO нужен 1) для точечной оптимизации и выжимания эффективности (поэтому важно знание домена и процессов). Лучший способ конкурировать в красном океане - иметь лучшую экономику. А это часто упирается во внутренние продукты процессы и сервисы (тут как раз полезен деливери кстати), 2) для борьбы за лояльность и удержание. В красном океане дешевле удерживать текущих клиентов, чем искать новых. Продуктовая работа смещается с привлечения на удержание и углубление монетизации. Хоронят не профессию, хоронят её неправильную, сказочную интерпретацию. Хоронят миф о «визионере-гении», волшебнике за 200 тыс руб в месяц, который по наитию придумывает новый iPhone. Такой действительно не нужен да и нет таких. Нужен "продакт-инженер": системный, data-driven специалист, который умеет считать деньги, находить точки роста и точечно оптимизировать сложные системы. Такой специалист нужен сейчас как никогда.
Привет! Для многих компаний, уровень продуктовой зрелости которых низкий, это все еще тренды
Привет! Это очень зависит от компании. В целом есть тренд на оптимизацию с учетом эффективности сотрудников. Что такое эффективность в продуктовых компаниях - это влияние на выручку, прибыль, активную базу.
Исходя из 4 месяцев работы с ChatGPT могу сделать вывод, что промты хорошо работают на синтез информации, введенной вами, например, транскриптов интервью или внутренних документов. Что касается использования открытых источников, то тут всегда нужно "включать мозг" и по возможности дополнять экспертными интервью.
мы используем их только внутри компании. При этом они составляются исходя из реальных интервью с пользователями, которые затем интерпретируются.
выводов можно сделать много. я дальше буду писать на эту тему. в одной статье все не уместишь))) можете подписаться на канал, там я заметки тоже публикую t.me/bpmcafe
На тему инноваций я не так давно написала статью.
При правильном проведении мозгового штурма участники должны получить формулировку проблемы, продумать изолированно друг от друга варианты решений и выбрать, на свой взгляд, наиболее подходящие. Когда команда соберется вместе, все предложения будут исследованы, появится возможность видеть все точки зрения и индивидуальные уровни рассмотрения проблемы, таким образом, это способ не только принятия, но и получения информации.
3) иногда решение принимается той же группой, что участвовала в мозговом штурме, но чаще всего отобранные идеи передаются руководству для принятия решения. Все предложения делятся на группы: пригодные, непригодные, спорные, или используется рейтинг. Можно задействовать метод от противного: если идея будет реализована, то что может быть причиной ее провала, каких она требует затрат?
4) практические семинары (еще их называют иногда диагностическими). Есть такое тоже. Обычно провожу их с топ-менеджерами.
5) прототипы не создаю, так как работаю не в сфере разработки. Если и делаю, то в виде пользовательских историй.
Разрабатывая схемы бизнес-процессов для последующей автоматизации я пришла к выводу, что существенно облегчает работу так называемый Social BPM, когда документирование и изменение регламентов и документов идет параллельно со всеми согласованиями и проектированием.
Приведу пример:
Документация процесса происходит с помощью привязки к модели:
Собственно само описание процессов с комментариями заинтересованных лиц и решениями на совещаниях:
1) www.englishtips.org — много литературы на английском
2) www.study.com — полезный сайт с материалами и вообще с кучей информации для изучения английского
3) www.livemocha.com — социальная сеть, тут можно найти друга из другой страны.
4) www.lingvotime.com — сервис для поиска преподавателя онлайн
5) www.eslpod.com — тут можно скачать подкасты
У меня к вас встречный вопрос- что вы предлагаете использовать для описания workflow вместо EPC? И для кого неудобна? Для программистов наверно неудобна (нет технической детализации), для заказчиков — то, что надо.
Во-вторых, Aris — это не в первую очередь не инструмент моделирования, а методология, поэтому все модели связаны между собой и представляют описание архитектуры всего предприятия, не только бизнес-процессов.