Functional Analyst @Materialise10 лет практического опыта в продуктовых компаниях. Из них 8 лет в качестве бизнес-консультанта и функционального аналитика. Участвовала в более чем в https://deveducation.com/ 40 проектах различных отраслей. Соблазна пойти в другую компанию у меня не было. Этим я обязан атмосфере в команде, корпоративной культуре и рабочем процессе, который никогда не бывает рутинным. Спектр задач настолько широк и разнообразен, что редко можно вспомнить схожие между собой дни.
Четыре продакт оунера бэклог приоритизировали-приоритизировали…
Во-первых, возникает проблема одинаковых значений. Следовательно, в такой системе нет ответа на вопрос «какая ОДНА задача сейчас самая важная». То есть, вообще говоря, имея число от 1 до 5 можно сделать беклог только длиной в пять задач — дальше начнутся неоднозначности с приоритетом. Потому что agile «заточен» под изменения, значит изменение пример бэклога продукта ожидается.
Зачем нам Бизнес Анализ? Нам скоуп нужен!
В конце концов, во время этого open space я не предлагала полностью отказаться от процесса оценки, скорее не оценивать пользовательские истории или что-то меньшее, чем эпик. Рефакторинг Обычно оценка в Story Points помогает ответить на вопрос о приоритетах в таких случаях. Идея A/B теста с наименьшей оценкой выигрывает.
Основные роли в команде разработчиков
- И в принципе европейский подход, он такой, он тоже про изобретательство, про какие-то хаки, но он более линейный, он более такой бизнес-ориентированный и не такой crazy предпринимательский, как в Америке.
- Просматриваем ошибки в логах и заводим задачки на исправление дефектов.
- Менеджер продукта не привязан к какой-либо определенной модели, методологии или фреймворку.
- Поэтому я регулярно слежу за всеми этими сервисами и пытаюсь понять, как они взаимодействуют с аудиторией.
Если нет необходимости концентрироваться на самой важной задаче — нет такого ажиотажа вокруг приоритетов, это ни на что особо не влияет. Во-вторых, как бы это ни было смешно, большинство инструментов поддержки процесса (трекеров) этого не позволяют, даже многие «заточенные под agile». На самом деле, каждый программист подтвердит — с точки зрения разработки приоритет-значение реализовать куда легче, чем приоритет-отношение. Кроме того, список, как мы знаем, имеет тендецию меняться. Не только вследствие радикальных изменений, но и с эволюцией проекта.
Чем занимается и какие показатели у сервиса Rusprofile
Scrum/SAFe — имеющие ничего общего с Agile, созданные для чисто комерческих целей и зарабатывания на всем движении гибких методологий. Или компания считает свои команды разработчиков такими тупыми что они не могут освоить 10 страниц гайда и им нужны скрам мастера для этого? А полюбился и прижился скрам еще за то, что там есть estimation-ы, которые не работают, но на которые так уповают еще одни дармоеды, ценители хлыста и пряника. Зачастую в подобных темах в комментах безнадега и жесткая критика. От же скрам паршивый, не дает разрабатывать…Ретроспектива только тогда ретро если после нее есть изменения. Эти изменения должны быть маленькими, конкретными, приносящими очевидную пользу и выполнимыми.
Вторая особенность, когда самая важная задача будет сделана — у нас все равно будет самая важная задача, и она опять будет самая верхняя в беклоге (прямо как в очереди FIFO, если вы понимаете, о чем я). Во-первых, не держим слишком много задач «открытыми». Чем больше задач «in progress» и чем больше их среднее время нахождения в этом состоянии — тем сильнее потери от изменений.
Любые игры строятся на базе развитого комьюнити с организованными встречами, совместными праздниками. Даже если продакт сам не участвует в продажах, важно присутствовать в сейлз-процессе, видеть вопросы, которые задают перспективные клиенты. Клиентские вопросы подскажут, какой набор фичей нужен для улучшения продукта. User testing, фактически, делают параллельно с user interview, наблюдая как пользователь взаимодействует с приложением или системой, где возникают сложности. Когда реальный пользователь садится за продукт, всплывает огромное количество багов, неочевидных раньше.
Если посмотреть на идею продукта как на способ сделать какую-то работу, то эту работу пользователь давно решает каким-то способом, пусть даже не самым оптимальным. Если у людей возникает реальная проблема или задача, они находят способ, как ее решить. Чаще всего Business Analyst растет в Product Owner. Сильных специалистов можно встретить в Outsource и Outstaff компаниях, где есть больше практики взаимодействия с разными клиентами. В продуктовых компаниях часто нет бизнес-аналитика или эту роль выполняет человек на другой должности.
Дизайнер может не знать всех технических или бизнес аспектов продукта. Чтобы дизайн получился хорошим, нужны знания и экспертиза всей команды. Есть мнение, что чем выше уровень технической команды, тем меньше потребность в роли QA в процессе разработки ПО.
А еще — системное мышление, коучинг, навыки планирования, управления конфликтами и умение давать обратную связь. Ветка координации в структуре IT-команды — это люди, которые помогают разработчикам двигаться в одном направлении, делить между собой задачи так, чтобы командная работа была максимально эффективной. Этот специалист проверяет продукт на наличие багов (ошибок), тестирует User Scenario, помогает обеспечивать соответствие продукта техзаданию и безотказную работу на различных устройствах. Это может показаться странным, но в списке автора одним из ключевых навыков коммуникации является умение слушать. Это, возможно, нечестно, так как основывается на личном стиле общения автора, а именно, манере слишком много болтать. Но все равно владельцам продукта не помешает напоминание о том, что нужно уметь слушать.
Как и в предыдущий раз, скрестили пальцы, смотрели логи и ждали результатов. Во время тестирования были выявлены и решены незначительные дефекты, но в итоге сайт показал довольно неплохие результаты. Как оказалось, пользователи — это самые лучшие тестировщики продукта, каждый из них уникальный и по-разному пользуется приложением. На стабилизацию и фикс критических дефектов ушло не так много времени, около недели.
Работ и контекстов может быть много, и сложность в работе продакта — это понять, какие конкретно фичи войдут продукт на первом этапе и как достигнуть наибольших результатов, не растрачивая ресурсы. Шаблон value proposition canvas помогает четко увидеть ценность продукта и понять, что делать. Основная обязанность продакта — не генерация «фичей», а решение проблем (болей) пользователя. Продукт, который не решает проблему — бесполезный. Более того, одного неправильного решения достаточно, чтобы оттолкнуть от проекта большую часть ЦА. Technical-роли в команде проекта предполагают правильный выбор архитектуры, технологий и инструментов — все для того, чтобы продукт соответствовал заявленным целям с технической стороны.
Или самородок на второй день, или стог сена за месяц. Это то же самое, что сказать «они все абсолютно неважные» — никакой разницы не будет. «Важная» в данном случае используется как средство мотивации коллектива, а вовсе не как приоритизация беклога.
• При каждой возможности, уменьшайте количество шагов или количество времени, необходимого новому пользователю получить ценность от вашего продукта (time to value). • Эффективно решайте проблемы клиентов и, по возможности, увеличивайте ценность для них за счет решения новых проблем (super apps). В 2016 году Apple добавила подписки, которые до этого были доступны только журналам. И быстро стали популярными — компании начали массово переходить на новую бизнес-модель.
Commenti recenti