#мирвокруг #аналитик #материалы #бизнесанализ #системныйанализ #рекомендую #теория

Произошел очень забавный случай, я случайно пересеклась с девушкой, которая выступала на конференции Analyst days в 2018 году.

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

Я часто этот доклад ставлю в пример того, как аналитики бегут решать проблему, не до конца разобравшись в проблеме. Я сама этим грешу и мозг привыкает так работать. Перепрыгивать через бизнес, проблемы, и сразу бегом писать ТЗ на мобильное приложение, думая что знаешь, что нужно заказчику.

Я нашла ссылку выступления Ольги и решила с вами поделиться.

https://analystdays.ru/ru/talk/58370

#мирвокруг #вопросответ #skills #аналитик #моемнение #требования

Хороший ко мне прилетел вопрос:

В вакансиях есть строчка - знание и умение работать в Kafka. Действительно ли это нужно аналитику?

Ответ мой следующий: по такому требованию можно предположить, что компания аналитика использует как разнорабочего. Это неплохо и нехорошо, это вот так в компании. И скорее всего зрелость этой компании в плане АйТи средняя. А вот учить кафку и идти или нет, это уже ваш выбор. Имхо, зачем спутывать понятия, каждый должен заниматься своим делом. Для настройки Кафки есть DevOps, у них это получится лучше. Так сказать, зачем топором забивать гвоздь, есть же молоток))

Я не знаю Kafka, но в своё время трогала руками MQ message broker от компании IBM. Времена изменились, появились микросервисы, биг дата и новые инструменты. Изучить что-то новое, при понимание, что это, и зачем, я считаю мне не составит труда.

Моё мнение, что важнее понимание, что это такое, зачем и для чего. Я всегда за фундамент. И считаю, что аналитику важнее понимать так сказать матчасть, что такое очередь, как она работает, как устроена, что там может быть и зачем подобный механизм нужен, как работает в среде микросервисов. Есть теория обслуживания и построения систем массового обслуживания. Мне её читали в институте, очень увлекательно и очень нравилось)))
Вот мне её вполне как фундамента хватало, чтобы изучить механизм работы брокера.

Ещё есть такой момент, что работодатель часто летает в облаках, и думает, что сейчас я найду универсала и он будет уметь всё, или просто пишет набор требований не понимая, кто им нужен и кто действительно такой аналитик (продакт или прожект, да кто угодно, нужное подчеркнуть). Но универсалов очень мало. Даааааа, мы тоже страдали большим набором требований, спустя какое-то время пришло осознание, что проще взять человека с базой и фундаментальными знаниями и научить тому, что нужно, готового специалиста со знанием нюансов, нужных именно твоей среде работы, может и не быть.

Так что ещё одно предположение, что вакансия сырая и возможно работодатель не совсем знает, кто есть на рынке. А возможно у них был хороший специалист, который закрывал все дыры, и ушёл, и теперь все хотят такого же.

#мысливслух #аналитик #аутсорсинг #мирвокруг

Аналитика на аутсорсинге.

Я была на разных проектах и со стороны аутсорсинга и со стороны заказчика. И понимаю особенности работы с двух сторон. И решила с вами поделиться.

Аналитика на аутсорсинге это хорошо или плохо?

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

Если со стороны заказчика нет человека, который бы грамотно валидировал и принимал задачи, то что пишет Аналитик, то может получится очень нехорошо. Следов не найти, а аналитик заложит бомбу замедленного действия, и когда она сработает покажет время.

Чтобы такого не было, аналитику четко нужно ставить задачу и давать шаблоны артефактов.

Плюс работы на аутсорсинге для аналитика - тебе дают время. Не всегда, но часто расчет с заказчиком это Time&Material. Поэтому делай и сдавай. Но конечно не всё так радужно, заказчик может быть недоволен, например тем, что ты не приходишь во время на работу или приходишь не в то время, или долго делаешь задачи, не то и не так.

Грамотная оценка задач. Это конечно легко написать, но сложно сделать, главное практиковаться. Я редко где встречаю практику оценок задач аналитика, сложно, непонятно, много рисков, подводных камней. Но главное начать оценивать и трекать время. Идеальный вариант это артефакт + средняя оценка по его выполнению. И знаете у меня это сработало, даже пару раз))) Когда я выполняла описание по артефактам и когда мне сдавали проект также по артефактам. И уже можно понять, что нужно или не нужно заказчику и в каком виде.

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

#аналитикимосквы #аналитик #randomcoffee

Мне понравился Random coffee на базе сообщества участников, кто прошел курс Go practice для продактов и вот теперь эта возможность есть и у Аналитиков!
Спасибо Анне, администратору чата "Аналитики Москвы" @moscoa за возможность поболтать с аналитиками на разные темы. Кому интересно неформальное общение с коллегами из других компаний, добавляйтесь через бота @Rc_moscoa_bot

Как только нас будет 50 мы запустим рандом))

А теперь работа с возражениями:

"Это тиндер какой-то" - а чё бы нет, если у вас такие цели))) цели можно менять и посмотреть как оно у коллеги в другой компании, какие есть боли и т.п.

"Меня будут хантить" - если вдруг появится HR в сообществе, что в этом плохого? Он вас обучит, тому как ищет людей и как нужно себя вести на собеседование, а вы ему расскажите об аналитике. Для тех кто боится, что его будут нахтить, скажу, что это круто когда тебя оценили и хантят, и с другой стороны вы всегда можете сказать нет.

P.s.
И да, чтобы делать выводы нужно сначала попробовать) мой опыт был со знаком плюс!

#капитаночевидность #аналитик #системныйанализ #бизнесанализ
#инструменты #userstory #usecase

Вернёмся к #теория
Избитая всеми тема, какой подход лучше выбрать в фиксирование требований User Story или Use Cases.

Мало того, что многие не различают эти понятия, так ещё и не думают, а что лучше? Такое впечатление, что User Story это некая мода, поэтому не поддается анализу и логике их применение.

Ещё возникает постоянно вопрос, а какого чёрта вы не делаете микс? Почему на многих проектах забывают про существование Use Cases? Ой, мол как сложно. Надо думать. Я лучше буду херачить в своей песочнице...

В России постоянно всё из крайности в крайность. Но водку пьём, то торты едим. Точнее, то ТЗ на 100 страниц по ГОСТу канцелярским языком пишем, то на полстраницы User Story. Ни то, ни другое не даёт картины проекта. А ещё есть и противники UML. Я наоборот топлю за проектирование и описание функционала, как многослойного "торта" по диаграммам разного уровня детализации. Чтобы всегда можно было вернуться на тот уровень, который необходим.

"У нас нет времени" - вот что я постоянно слышу. Живя в Москве всю жизнь, могу сказать, что его никогда нет и оно есть всегда))) Опять же имхо, есть вещи без которых проект не сдвинуть, ну либо херак-херак и в продакшн. Тогда уже и о развитии сложно говорить и об системном анализе. Какие выводы делать по user story?

Тем кому тема близка и кто ломает голову, что лучше, посмотрите выступление с конференции, ссылка ниже.

Именно отсюда я знала о User Story 2.0, как раз когда появляется прослойка Use Cases и на них мапятся User Story. Вот так применяешь и то и другое и даже не знаешь, что это уже 2.0)))) Все когда-нибудь приходят к такой схеме работы с требованиями.

https://analystdays.ru/ru/talk/71737

#custdev #мысливслух #инструменты #аналитик #productmanager

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

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

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

Я считаю что такое поведение накладывает отпечаток в том числе и на стиль работы. Всё таки работа-дом хоть и могут существовать отдельно друг от друга, но профдеформация, также как и досуг вне работы друг на друга влияют.

Мне на самом деле очень жаль, что про кастдев как про инструмент аналитика не говорят. Либо говорят с позиции, а так ли это? Действительно ли аналитику нужен кастдев? Хотя по сути искусство правильно задавать вопросы, очень нужно, чтобы заказчик:
👉1. Дошел до своей проблемы сам
👉2. Дошёл до решения этой проблемы также сам.

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

Другие мои заметки про Customer Development можно почитать по #custdev

#мирвокруг #гарантированнаядоставка #системныйаналитик #системныйанализ #аналитик #шса

Гарантированная доставка.

Что ж теперь я официально могу сказать, что являюсь преподавателем "Школы системного анализа и проектирования" и веду курс по основам проектирования интеграций информационных систем. Так что ввожу новый хештег #интеграция и буду писать интересные вопросы по этой популярной теме. И надеюсь, многим будет интересна эта тема, так как интеграция это не только маппинг данных, хотя менеджмент часто видит интеграцию, как что-то простое, решаемое одной таблицей маппинга.

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

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

Зачем же это всё нужно? И для каких данных?
Приведу супер пример.

Мои знакомые однокурсники из авиационного института работают в авиационной отрасли. Да, есть ещё такие люди. И вот, как-то их отправили в Австралию тестировать приложение. Это приложение обеспечивает диспетчеров информацией по самолёту. То есть один диспетчер передаёт другому самолет. Диспетчер ведёт этот самолёт по определённой зоне. Например, над Москвой есть зоны аэропорта и есть круг, по которому крутятся самолёты. И вот, чтобы из одной зоны и коридора, перевести самолёт в другую зону и коридор, нужно передать данные от одного диспетчера другому. При такой передачи идёт искажение данных и конечно возможно не все данные будут переданы сразу.
Такая НЕ передача данных увеличивает вероятность аварии, например самолёты окажутся в одном коридоре. И диспетчер не поймёт все нюансы местонахождения самолёта и неправильно будет принимать решение.

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

Что тут важно помнить аналитику. Что стоит проанализировать бизнес критичность данных при передачи от одной системы в другую, и обсудить с архитектором или главным разработчиком для каких данных и в каком варианте стоит сделать механизм гарантированной доставки. Даже если разработчик будет махать рукой в ответ и говорить "Вася отвали, Я уже всё продумал". И ты в ответ "Петя прости, у меня работа такая задавать неудобные вопросы".
По опыту могу сказать, что у нас механизм гарантированной доставки включался при отправке данных по проведённому платежу. Клиент расстроится если за его штраф гибдд не получит информацию об оплате.

#управлениеизменениями #графикизменений #теория #мойопыт #мысливслух #аналитик #бизнесаналитик #системныйаналитик

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

График внедрения изменений прикладываю в комментариях. 👇

Тут как и со многими теориями я действовала по наитию, а потом уже увидела теорию и подтвердила сама себе, что всё правильно.

✅ Шаг 1. Прежде всего понять, что изменения нужны. Как и с многим в нашей жизни, нужно просто это проговорить. Лучше записать и показать факты, метрики.
✅ Шаг 2. Все будут сопротивляться. Все, Все да не все. Своих тех кто тоже за изменения и понимает, что давно пора такие тоже всегда есть. Нужно заручиться их поддержкой.
✅ Шаг 3. Дальше идём по графику и главное иметь больше поддержки и добавлять всё новых и новых в свои ряды. Когда ты адекватно оперируешь фактами, найти светлые головы не трудно, трудно попробовать удержать оптимизм и довести дело до конца, копая и копая. И сразу работая по-другому хотя бы в какой-то части. Как только изменение будет крутым, может пойти лавина и всё рядом.

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

Обычно идёт противочерие: ты внедряй, да, да, да иди, но я тебе инструмент не дам, копай землю руками, я посмотрю, начнёт получатся, вот тогда, может быть.... Лопату тебе куплю.

✅ Шаг 4. Всё рушится в точке, когда уже никто не верит, все устали, и просто хотят махнуть рукой. Мол, ну ладно, итак жили, к черту эти изменения. Это самый сложный период. Моральный дух падает все устали, вот тогда первые шаги могут уже давать свои плоды и график можно переломить и погнать вверх.

Цикл внедрения изменений зависит от масштаба. Что-то что делать нужно годами, тут я только в своей личной жизни внедряю))) В компании беру что-то сроком максимум полгода.

Удавалось ли мне всё внедрять? Нет конечно. Но были ли успехи? Однозначно. Трудно, тяжело, но очень интересно, а как же будет потом после изменений то. Ради этого интереса часто дожимала. Но если мои интересы противоречили интересам руководителей или менеджерам, исход понятен. Я чаще всего шла выше, эскалация меня убирала))) или просто делали условия невыносимыми, чтобы я сама ушла. А я уже столько сил потеряла в этом внедрении, что уже не могла дальше работать. Что-то было оправдано, что-то нет, но опыт есть опыт и понимание того, что вставая на тропу изменений, нужно беречь прежде всего свои силы, потому что моральный настрой надо поддерживать. Плюс можно брать для начала небольшие, посильные вещи. Маленькие победы это много энергии и уверенность в себе.
Из позиции, что я реально могу сделать сам в этих условиях, минимально? И дальше новый вопрос - а действительно ли моё текущее состояние мне позволяет это сделать?
Ну и конечно вопрос - а это правда нужно, или я просто сошла с ума?

Быть Чегеварой интересно, но опасно, он плохо кончил))))
А ничего не менять, это не жить, как по мне)))) Остаётся выбор в виде гармонии, к этому и стремлюсь, не всегда конечно получается. 😜

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

Будучи сама аналитиком, ещё и с такой сильной профдеформация, что анализирую всё вокруг, и вставая в роль тренера, докладчика, ментора понимаю, как аналитики бесят)))

У меня есть такая фраза "что если аналитик мне выносит мозг на собеседование, надо срочно брать!"

Был у меня такой момент, в допандемийное время, что было 2 собеседования, мама лежала в реанимации, а мне на собеседованиях один человек за другим выносили мозг. Я думала, что я на нервах ку-ку, и что сразу приняла решение брать в отдел ребят, но спустя годы понимаю, что отличное было решение)))

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

Но есть, ещё одна особенность, аналитик хочет контролировать и понимать решения и реализацию, которую в итоге выбрали. Желание понятно, ты тут выстраиваешь отношения с заказчиком, и чувствуешь ответственность, чтобы действительно команда сделала все возможное и приняла правильное решение. Но по факту от 80 до 90% сделано, то что сделано и грустно от этой безысходности. И почему так? Все разводят руками, исторически сложилось мол и всё.

На одном из проектов я так грустила, что только 30% продукта мы сделали, и отдали заказчику, и потом на ходу ещё подкручивали велосипед. А потом перешла в другую компанию и поняла насколько наши 30% оказывается были крутые))) Всё познаётся в сравнение. При этом многие аналитики перфекционалисты, идеалисты и иногда возникает у меня такое ощущение, что аналитик видит айти технологию, и не видит в ней изъяна. То есть если это айти, то не должно быть минусов. Но даже от приёма лекарств всегда идёт побочка, одно лечим, другое калечим. Так и тут, решая проблемы заказчика мы ему создаём новые.

Мне очень понравилась аналогия одного из основателей skyeng, что мол все к нему приходили и постоянно говорили о проблемах. И в таком состоянии кажется, что крах, всё плохо. А по сути эти проблемы они как дырки на дне корабля, но корабль плывёт. И ты эти дыры закрываешь. Сразу же появляются новые. В этом и состоит жизнь и развитие)) Главное, чтобы корабль плыл!

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

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

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

Почему аналитики плохо пишут use cases?

Очень часто на курсах по интеграции в ШСА, да и не только, на менторстве тоже, и на собеседованиях встречается общая проблема по use cases. Аналитики плохо пишут сценарии вариантов использования.

👉1.Во первых, есть аналитики, кто не делает различий между use cases и user story. Вместо того, чтобы спрашивать аналитиков различие между Soap и Rest, на собеседование, лучше спросить различие между use cases и user story.
👉2.Во вторых, сценарии, как техника, используются на разных уровнях абстракции и не только аналитиками, но и тестировщиками, проектировщиками интерфейсов, продактами, да всеми)) Удобно.
👉3.Действительно, на системном или на уровне проектирования взаимодействия систем, мало кто из аналитиков грамотно может описать use cases. Это уже уровень архитектора, проектировщика, разработчика. Но он часто необходим на проектах, особенно если речь едет об интеграции.
👉4.Часто идёт ещё и смешение понятий функция и сценарий использования. Хотя use case вполне можно считать спецификацией функции.
👉5.Ну и плюс очень часто мы стараемся оперировать каноничным подходом, который был у Коберна (по крайней мере я всех к нему отправляю). И ещё пытаемся смаппить use cases и user story, я об этом писала, аж в 2020 году, что есть такое понятие как use cases 2.0 - https://t.me/start_in_IT/257

В самой технике сценариев, нет ничего сложного. Вот тебе основной, happy, поток, вот тебе расширения, где есть альтернативы и обработки исключений. Сюда же ещё и циклы включают. И получается, что есть канон, и есть реальность. И как сценарий эволюционировал мало кто знает, да и просто нет времени, надо делать работу)))

В итоге мы получаем высокоуровневые, часто до конца не проработанные сценарии. Их бы ещё детализировать и ещё докручивать и докручивать.

Выводы у меня следующие:
✅1.Высокоуровневые, на уровне бизнеса и взаимодействия пользователь - система, аналитики вполне отлично справляются.
✅2.Если аналитик не имеет базы, фундамента, плохо пишет алгоритмы, блок-схемы, то и сценарии также идут плохо. Везде в основе теория графов, сети Петри.
✅3.Сюда же я отнесу абстрактное мышление, это прям бич. Переключаться с одного уровня на другой самая большая проблема. Сложно понять где мы находимся, и где наши границы и рамки описания сценариев.
✅4.Сценарии на уровне взаимодействия модулей, систем требует знаний словаря данных, модели данных, что кому передаёт, как, в каком формате, по каким протоколам, синхронно, асинхронно, или файлами, или голубиной почтой.
✅5.Плюс сценарий не панацея и часто его нужно дополнять описанием алгоритмов, функций, а это математика. И я опять возвращаюсь к базовым, фундаментальным знаниям.
✅6.И ещё сюда добавлю обзор архитектурных решений. Потому что нужно хотя бы на пальцах понимать, как выстроено решение, к которому мы пишем уже на системном уровне требования, а точнее проектируем на языке требований, функций, что объединяет в себе целый комплекс знаний.

Итого: круг замыкается снова на том, что системный анализ инженерия, и даже в таком простом, с первого взгляда, инструменте, как use cases, собирает целый комплекс знаний.

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

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

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

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

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

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

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

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

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

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

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

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