​​#теория #мысливслух #капитаночевидность #моемнение #productmanager #продукт #проект

На #митап #аналитикимосквы мы активно обсуждали продукт и проект. Уходили в детали (наша профдеформация), забывая о главном.

А главное с моей точки зрения - это мышление, которое направлено на создание и улучшение продукта для потребителя/пользователя.

Всё очень просто на самом деле - если вы стоите "лицом к лицу" с клиентом, то у вас продуктовый подход. А дальше мышление заставляет вас думать в ключе - "как нанести пользу клиенту?". Это и дизайн мышление, и сбор данных, и общение, и куча других инструментов в помощь. Но ведь можно делать совсем мало - просто смотреть отзывы и читать обратную связь, не только потому что заставили, а потому что "хочу больше информации, чтобы принять правильное решение и нанести пользу".

И мы не проговорили главную вещь - это HADI - циклы.

Hypothesis - гипотеза, предположение о том, что влияет на результат.
Action - действие, реализация гипотезы, проверка.
Data - сбор данных и их анализ.
Insights - правильные выводы на основе данных.

Далее выводы превращаются в гипотезы и цикл начинается заново.

Мы хоть и организаторы митапов, но ещё и их участники, и каждый раз после митапа у нас море гипотез. Мы их озвучиваем, даже начинаем считать результаты, но пока у нас идёт сразу проверка в бою))))

#проект #продукт #моястатья #productmanager #projectmanager

Наконец-то свершилось! Многие просили, чтобы материала было больше! Я сделала свой простенький сайт-блог, что вам с радостью и презентую))

Уже сейчас на сайте вы можете найти несколько статей. Прорекламирую статью про различие продуктового и проектного подхода. Что тут может быть сложного? Часто я слышу от коллег. Всё итак понятно! Всем понятно и все почему-то продолжают спрашивать. Эту тему мы поднимали на митапе Аналитиков Москвы, статья как раз результат моей подготовки к митапу и корректировка информации после митапа.

Я сознательно не пишу что-то короткое в статьях, потому что это короткое и поверхностное вы сможете найти у других и оно быстро читается, и также быстро вылетает из головы. Мне интереснее копаться в вопросе, проблеме и структурно её раскладывать до мелочей, с анализом источников.

Комментарии, запросы на новые темы можете писать здесь или на сайте.
Спасибо вам за обратную связь и внимание))) Распространение информации приветствуется!

http://tashakosinova.ru/2020/02/11/%d1%87%d0%b5%d0%bc-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82-%d0%be%d1%82%d0%bb%d0%b8%d1%87%d0%b0%d0%b5%d1%82%d1%81%d1%8f-%d0%be%d1%82-%d0%bf%d1%80%d0%be%d0%b4%d1%83%d0%ba%d1%82%d0%b0-%d0%b8-project-manage/

Команда считает, что ей не нужен аналитик.

#мысливслух #зачеманалитик #историиизжизни #развитие #чтоделать #мойопыт #ИТаналитик #проект #намненуженаналитик

А ещё можно накинуть - нам не нужна документация, мы итак без неё хорошо жили. Или пусть аналитик документирует то, что уже разработали. Правда что!!! Он же нам не нужен!!!

В каждой подобной фразе отдаётся боль.

Годы идут, но проблемы в отрасли те же самые. На тему "Зачем проекту аналитик?" я уже делала вебинар вместе с Евгением Галактионовым, рекомендую к просмотру, если у вас возникают подобные проблемы с командой, возможно какие-то мысли и инсайты для себя поймаете - https://www.youtube.com/live/sIi1JdB4Iow?feature=share

Но ещё я порассуждаю на эту тему.
Что же делать?

✅ 1.Хочется бежать из такой команды. И отчасти вы будете правы. Во-первых, если команда не работала никогда с аналитиком, а вот его наняли и вы такой красивый пришли и вот сейчас как заживём по-другому! То нет. Люди очень не любят перемены и изменения. С изменениями нужно работать и не всегда опыта, компетенций, да и вообще полномочий хватает аналитику. И часто не задача аналитика заниматься внедрением изменений внутренних процессов, хотя ему её могут поставить, и потом сказать, но ты же не справился.
✅2.Во вторых, не соглашаетесь писать требования после разработки продукта. Восстановить требования можно, но часто руководство воспринимает аналитика, как технического писателя, который "подтирает за командой" или администратора проекта. "Поздно пить боржоми, если почки уже отказали." Смысл работы аналитика теряется, и это первый шаг к выгоранию, делать не свои обязанности. А как быть? Аналитик должен опережать разработку, иначе выгода от его наличия на проекте теряется. Аналитик нужен для минимизации риска переделок на финише, и приближения результата к той проблеме и к тому эффекту, что хочет заказчик. Берите задачи с опережением спирта хотя бы на 0.5 спринта, а лучше на целый спринт вперёд, чтобы на планирование или груминге можно было получить от команды глубокие вопросы и более чёткую оценку по реализации задачи.
✅3."Нам не нужна документация, мы итак же без неё хорошо жили." Рост сложности проекта неизбежен, и вопрос с артефактами появится. Аналитик не технический писатель и он проектирует решение. Документация ради документации никому не нужна, кроме ситуаций с политическими играми в защите проекта. А спроектированные решения, костяк артефактов, и описание требований - это, то что необходимо для выравнивания контекста при общение с заказчиком и командой. Все должны быть в одной плоскости общения, чтобы исследовать проблему, спроектировать решение и приблизить проект к успеху.
✅4.Плюс - если ваша команда на удаленке - вам нужны артефакты, диаграммы, и вики проекта, для постоянного выравнивания общего контекста и коммуникации команды. Команда на удаленке часто получает проблему в коммуникации. Какие артефакты вам нужны и в каком объёме и на каком уровне детальности - решает команда и всё зависит от уровня компетенции участников, критичности и сложности проекта. Про артефакты, примерный их набор можно посмотреть в вебинаре "Пирамида артефактов" - https://www.youtube.com/live/Ua19ythnFvE?feature=share
✅5.Если уж давать, советы, то следующий совет - абстрагироваться от наездов команды и делать своё дело, желательно при этом подкрепляя всю свою деятельность поддержкой руководства (иначе работать с изменениями бесполезно). Всё таки вас зачем-то взяли на проект и поставили задачи? Чаще всего разговоры бесполезны, лучше показать результат своей работы. Вы же новый человек и уважение ещё нужно заслужить делами. Команда может молчать. Я как-то столкнулась с тем, что я зафиксировала решение несколькими диаграммами, спросила команду "Ну как? Что вам было полезно?" Все промолчали, а потом на ретро после спринта в самое хорошее за спринт записали мои диаграммы. Я была удивлена, и сделала вывод, что за молчанием может скрываться, что угодно, не стоит себя раскачивать фантазией.

Проект не нужен заказчику.

#мысливслух #мойопыт #менторство #проект #чтоделать #рассуждения #ненужнозаказчику

Уже года 4, я провожу оценку аналитиков в виде игры по сбору требований. Игра у меня родилась из большого количества собеседований, доклада Ольги Азимбаевой (можно почитать и посмотреть тут https://t.me/start_in_IT/233 ) и моего опыта.
Я имитирую типичного заказчика, погружаю аналитика в его обычную среду "сбора требований и общения с заказчиком". Цель выявить основные Паттерны поведения аналитика, посмотреть какие вопросы он задаёт заказчику, как собирает требования, какие требования, на что обращает внимание, насколько идёт за заказчиком и тем решением, которое ему приносит заказчик.

Прогон этой игры дал мне многое, рекомендую аналитикам пробовать себя ставить на место заказчика. Когда приходит профессионал на такую игру, ой как сложно становится, отражать и давать ответы на неочевидные вопросы, при этом кажется, что я жду всё продумала! Но нет. И когда ты заказчик и не может дать ответы на некоторые вопросы, тоже включается синдром самозванца. И в таком состоянии человек может агрессировать, защищаться или говорить бред.

И вот в очередной раз, играя в такую игру менти мне задала вопрос, а как быть, если ты понимаешь уже на старте, что решение не решает проблем заказчика и ему это всё не нужно, и компания просто качает из него деньги?

Очень сложный вопрос. У меня нет однозначного ответа. Тут скорее, как в личной жизни, когда ты видишь, что в отношениях идёт обман, и один паразитирует за счёт другого. Что делать? Часто говорить бесполезно. Да и кто ты такой, чтобы это говорить? Этот опыт нужно получить.

Тут ещё и этика подключается, и политика. Особенно, если ты по ту сторону баррикад и твоя компания продаёт заведомо не нужный продукт, который поставят на полку, а кто-то построит себе очередную дачу или купит машину.

Чем меньше опыта, тем меньше ты видишь эти игры. И как говорится, крепче спишь. С другой стороны, решение принято, исходя из чего, мы чаще всего не знаем, оно могло быть просто политическим, и путь развития идёт, хоть и криво, странно. На этом заведомо провальном проекте, тоже можно научиться, и часто даже большему. Многих product manager так и отбирают на собеседованиях, по умению справляться с провалами.

И нужно понимать, что ты делаешь и для чего. На старте или в момент growth haking, команда изначально делает, то что могут выкинуть. И просто проверяет гипотезы. Грамотный менеджер должен понимать, что специалист не может постоянно делать то, что будет выкинуто или положено в стол. И нужно проводить ротацию команды growth haking.

Вспомнила ещё книгу "Русская модель управления" ( https://t.me/start_in_IT/176 ), когда я вижу какие-то очень странные, по-моему мнению движения, реализации, я начинаю спрашивать "почему так?" Вспоминаю книгу и отвечаю, аааа вот почему.

В такой ситуации, кто-то переживает, а кто-то просто рутинно работает и не обращает внимание на вопрос "зачем всё это нужно?" Я просто делаю своё дело. Нет тут правильных ответов. Главное вернуть себе управление собой, своими целями и сделать вывод для себя, даже если он будет звучать как "я просто зарабатываю тут деньги и стараюсь не включаться глубоко в происходящее". И это тоже нормально.

Всегда есть выбор, даже если кажется, что его нет)