Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Везде ли так?

Всем привет! Вот уже 3 года работаю девелопером на одном месте, первые 1,5 все устраивало — таски, процессы, команда, зарплата. приходилось заниматься кодингом, анализом и общением со стейкхолдерами напрямую(стейкхолдеры — выходцы из суппорт команды, из тестировщиков — люди, которые хорошо знают продукт с бизнес и немного технической точки зрения). задачи и их последовательность выполнения распределял техлид.

в последние 1,5 года поменялись процессы — внедрение православного скрама с церемониями и ролями. появился продукт-оунер на нашей стороне — и большая часть деятельности сводится на разбор задач с ней, проверку за ней описаний требований, на разъяснение технических деталей(с этим много проблем, тк у нее нет технического бэкграунда, нет понимания этих вещей и тогда все равно приходится общаться со стейкхолдерами, тк она не может им донести). очень много косяков в описании, которые не успевают исправляться и по итогу всплывают уже при старте девелопмента. сразу этим занимался техлид, потом переложили на всю команду.

и вот сейчас начинаю чувствовать, что задолбала такая деятельность — сильно ухудшилось качество постановки задач, разбитие на задачи, +нужно объяснять/проверять/исправлять/переделывать, а сделано должно быть уже вчера. это стало отнимать намного больше времени и сил, чем раньше, задачи уже делаю на «лишь бы успеть в спринт», нет того удовольствия от деятельности, отпуск не помогает, есть чувство, что тону в болоте каком-то.

собираюсь сваливать, но беспокоит 1 вопрос, а вдруг почти везде так?пара бывших коллег опровергает опасения, но все же. как понять это на собесе(тк лично мне такой формат работы не подходит)?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Проблема не в том, что ваш product owner нетехнический. Он и не должен быть техническим и вы таких почти нигде не найдёте кроме продуктовых компаний, где продукт — это технология (условной MongoDB, Inc.). Он должен быть доменным экспертом.

Проблема в том, что ваш product owner — это не product owner, а бессмысленное прокси для реальных PO, которые так и остались на стороне заказчика. Настоящий PO полностью владеет и управляет требованиями и ему не нужно куда-то «ходить» и кому-то что-то «доносить». Да, он формирует требования в контексте работы других отделов типа маркетинга, комплаенса и т.д. Но на уровне разработчиков он является единственным источником правды.

Посему совет: ищите не технического PO, а реального PO проекта. Если вас к нему не пускают, тогда уходите с проекта. И, скорее всего, из аутсорсинга, потому что там это повальная проблема. Они называют этих прокси «бизнес аналитик». Идите либо в продукт, либо в аутстаф.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Сейчас это массовая проблема. Называется «эффективный менеджмент». Я думаю что единственным методом борьбы являются массовые растрелы.

Ні, не усюди. Ще і зарплату піднімеш скоріш за все. Вдалих співбесід.

Про ситуацию. Смотри, есть 2 опции в твоей ситуации:
1) обсудить со своим менеджером, попробовать повлиять чтобы что-то изменилось, посмотреть что в итоге с этого получится. Если ничего не получится, то менять компанию.
2) Если вы уже подустали и у нет желания на что-то влиять и менять, начинайте рассылать резюме и смотреть варианты.
3) Если учитывать, что вы уже 3 года на одном месте, врятли будет подъем энтузиазма и какого-то драйва, потому что вы уже привыкли. Даже если получится улучшить ситуацию, через год вам захочется все равно чего-то нового. Так что может сейчас просто неспеша начинайте рассылать резюме и смотреть варианты.
Про скрам, продакт оунера и переход в другую компанию.
Скрам очень удобный, гибкий и полезный фреймворк как не крути, если заимплементирован с учетом особенностей продукта, команды и компании. Продакт оунер хороший полезный человек в команде. Технический или нетехнический ПО нужен, зависит от продукта/домена. Бывают удачные имплементации скрама, бывают менее удачные или в процессе тюнинга еще. Тоже самое и с ПО, бывают очень прокаченные ребята, бывают чуть менее, а бывает что каким бы смышленным ПО не был, он переходит в другой домен, и нужно пол-года минимум чтобы в продукте и сфере разобраться.
Я к чему, что важно: когда вы вибираете компанию, в которую переходить, есть смысл выбирать людей. Какие бы методологии не использовались и как бы роли не назывались, вы же будете работать с людьми. Потому важно выбирать менеджера себе, пообщаться с коллегами, продакт оунером, заказчиком если есть возможность и т.д. Чем больше людей вы узнаете во время собесов, тем больше вероятность что вы подберете себе комфортную команду, с которой сможете работать по любой методологии.

Про ситуацию. Смотри, есть 2 опции

на одной пики точёные

Я перестал беспокоиться из-за процессов, скрама и «скрама» — только поставив себя на место хирурга в emergency на ночной смене — он делает работу какую дадут, а если пациента надо оперировать по абсолютным показателям — то и дедлайн не подвинешь. С такими клиентами в несознанке — дедлайн нередко сам двигается, да и вообще — становится очень-очень коротким, чик чик и в продакшен.

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

внедрение православного скрама

Перестать поддерживать flat hierarchy, пусть сами с этой flat разбираются, стать обычным кодером. Что в тикете написано — то и сделано. If you ask me to do the shit — I will do the shit. Если тикет не полный, с покерфейсом завернуть его на дописывание (у вас как я понял таких тикетов овер 99%).

После прочтения данного поста у меня сложилось впечатление, что автор чуть не разобрался. PO не особо то и нужны технические детали реализации, а важно мы можем это сделать или нет.
PO отвечает за продукт, а не за каждый конкретный код.
И больше похоже, что у кого-то стало больше работы, и этот кого-то, и не доволен ;)

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

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

А вообще я бы предложил вообще засетать тет-а-тет колл с PO и обсудить конфликт (личный/интересов/итд.), и попытаться выработать решение. А не постить тут жалобные посты ;)

И больше похоже, что у кого-то стало больше работы, и этот кого-то, и не доволен ;)

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

А вообще я бы предложил вообще засетать тет-а-тет колл с PO и обсудить конфликт (личный/интересов/итд.)

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

А не постить тут жалобные посты ;)

это не жалобный пост. к сожалению, мне особо не с чем сравнить, это 2ое место работы, но с такими процессами сталкиваюсь впервые. есть осознание, что лично мне такое не подходит, поэтому интересуюсь, как не получить все тоже самое, только в профиль)

PO не особо то и нужны технические детали реализации, а важно мы можем это сделать или нет.

в ЦК не дураки сидят — полетите на Солнце ночью ©

Везде ли так?

Ні, так не кругом. Що добре в скрамі, це те, що у кожного взагалі свої уявлення, як воно має бути. Тому дехто навіть (випадково чи ні) робить добре. Дехто робить не скрам зовсім, але теж добре. Дехто робить погано вцілому для бізнесу, але зручно для розробників. А хтось робить погано взагалі всім. В тебе ситуація ближча до останнього, страждаєш трохи більше середнього. Якщо щось не зміниться в найближчому майбутньому — тікай.

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

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

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

БА по совместительству ПО, но по факту — ни БА, ни ПО

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

Далее произойдет вот что: ПО начнет получать пи***лину от боссов и задумается. Далее, эволюционным путем, все выйдет на нормальные рельсы.

Главное не переживать, это не твой проект, ты вероятно даже бонусов не получаешь. И вряд ли тебя уволят, если не успеешь в спринт.

PS и вообще 3 года уже более, чем достаточно на одном месте. Для формирования новых нейронных связей и расширения нетворкинга пора менять работу.

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

Залежить від багатьох факторів. Навіть в середині компанії команди можуть оперувати по-різному. Якщо все треба на позавчора у всій компанії, а не лише в одній команді, то скоріш за все варто йти і шукати краще місце.
Імхо, дуже ймовірно судячи із описаної проблеми, що в самого ПО не вистачає часу і рук на те, щоб оновити / доописати задачі, бо їй так само можуть дзвонити за 30 хвилин до пленінга і просити створити нову задачку і додати в новий спрінт. А менеджемент просто каже, що цей клієнт дуже важливий для нас і всі його забаганки — закон. (Особисто в мене таке бувало в 99% випадків в попередній компанії)
Або банально мотивації :)
При пошуку радила би уточнювати у hiring manager, як саме ставляться задачі, як вони виглядають і тд. Але навряд хтось відверто скаже, що дедлайни горять, а ПО не розуміє, що тут відбувається) За мій досвід роботи від дева до ПО в кожній компанії і навіть в кожній команді це виглядає по різному (від одного речення в desc і «мені головне, щоб це вирішило проблему, а ви самі вирішуйте, що зробити» до безальтернативного чіткого опису, що і як має вийти на виході.

Скрам тулят где ни попадя. Уже в двух доках (скрамгайд, и ebm guide описано, что ПО максимизирует велью, путем анализа не до конца достигнутого велью и текущего велью. Для этого анализирует рынок и поведение конечных пользователей, а также распоряжается бюджетом, и его мнение в организации уважают беспрекословно.
Отоивсе шо тут многие в топике и в комментах пишут, то это когда пилят feature soup, и каждый спринт — это ведро фичей, где нужно детально разбираться с каждой таской, да...
А в оригинале скрама должна быть гипотеза — как цель спринта, которую ПО хорошо понимает с т.зр. бизнеса. Ну да, знание технологий часто помогает, это точно.
Скраммастеру, видимо, что-то мешает пока-что это донести/научить/дожать. Возможно это и неуместно даже, потому и не делается.
Все что здесь говорят также часто имеет место быть, только оно с задумкой авторов скрамгайда имеет очень мало общего. Это у вас, коллеги, итеративно-инкрементальная разработка. Без цели спринта будет вот так вот. И цель сринта — это не «выполнить все таски по размеру капасити»

Никак ты не поймёшь пока не попробуешь. Даже в рамках одной компании на разных проектах разные подходы. Разве что идти в команду к знакомому, чтоб заранее пройтись по всем вопросам.
В основном везде не так. Везде по разному

На проекті повинен бути BA, тех. лід, продакт овнер, в кінці кінців. Коли я отримую завдання в джирі, а там, грубо кажучи, заповнена лише назва тікету, то не починаю над нею працювати поки не поспілкуюся з лідом; а якщо на початку розгляду з’ясовується що опис складено криво, то переводжу тікет у статус blocked, пишу комент яка саме причина блоку, делегую назад тому хто мені асайнив цю таску.

Що ж до того що досі було все ок, то на моєму поточному проекті теж з часом від девелопера очікують що він вже знає до кого можна звернутися і тікет в джирі описують менш деталізовано; і дійсно, для певного набору нюансів можна коротко написати в слаку потрібним людям і все стане зрозуміло; однак є все ж багато нюансів котрі перетворюють погано описаний тікет на blocked (див. абзац вище).

----

Upd: мене теж задовбало що замість одного-двох зідзвонів на тиждень тепер може бути декілька на день, але стараюся все ж писати більше коментів в тікетах, теґати потрібних людей і зводити потребу в балаканні до звичайної цивілізованої роботи в системі тікетів.

Коли я отримую завдання в джирі, а там, грубо кажучи, заповнена лише назва тікету, то не починаю над нею працювати поки не поспілкуюся з лідом;

Это как раз неправильный подход. Ваш лид/архитект не делает своей работы. У меня так же сейчас, и я понимаю насколько легче всем работать, когда в джире есть полное описание задачи с критериями выполнения и тестированием, описанным ДО НАЧАЛА имплементаци.

Все так; єдине що завдяки зручному плагіну в слаку можна створити таску в джирі на основі слак-повідомлення, таска в джирі тоді міститиме лише назву.

Це з одного боку зручно (сам часом користуюся), бо можна зафіксувати ідею і пізніше при потребі додати всі критерії.

З іншого боку, якщо пройде достатньо багато часу, то можна забути думки з цього приводу і лише назви тікету буде недостатньо щоб відтворити всю картину.

Внесення всіх критеріїв — це окремий кусок роботи, а часом не до кінця зрозуміло чи на це дійсно необхідно витрачати час, оскільки «вітер змінився».

А что, разве скрам работает в аутсорсе?

Причем работает прекрасно! А вот в продукте у нас нифига не работал

не работает канешно. но зато это гавно отлично продаётся.

первые 1,5 все устраивало

Это как раз очень даже нормально и стандартно.

в последние 1,5 года поменялись процессы — внедрение православного скрама

Поздновато,но тоже в пределах нормального.

сразу этим занимался техлид, потом переложили на всю команду
задолбала такая деятельность — сильно ухудшилось качество постановки задач

Это уже ненормально. Позволю себе предположить, что именно вся команда забила на скрам (который по определению есть командной тулзой). Как вариант — очень крутой у вас скрам-мастер, который тянет все на себя, но ему можно аргументированно обЪяснить что он не прав.

а вдруг почти везде так?

Я не знаю как насчет «почти везде» в смысле компаний, но к кандидату которому формат работы со скрамом не подходит, я бы отнесся очень м-м-м аккуратно и недоверчиво :)

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

намного больше времени уходить на митинги/коммуникации/объяснения/вычитывание сторей и исправление косяков в них

Опять, больше времени на митинги-коммуникации — это нормально. Добавьте, что полтора года тому — это начало карантина, переход на онлайн. В онлайне у меня без всякого скрама встречи процентов на 30-40% стали дольше, инфа в онлайне тяжелее доносится :(
Вычитывание сторей и исправление косяков... не знаю что вам сказать :( Когда у меня на проекте появился ± скрам, а не просто 2-недельные спринты, я был щаслив: стало возможно запланировать время на исследование таски, на уточнение требований, в результате мартышкин труд (когда сделали не то, что хотел заказчик) сошел практически на нет, как кстати и овертаймы. Тот же самый спринт ревью дал возможность говорить КО на стороне заказчика: чувак, Тебе легче связаться с командами, которые нас не знают, но знают Тебя, и договориться с ними о деталях. В конце концов, пару раз и отмаз был найден — контрагенты не успели свое сделать. Как на меня, в целом это благо.
Но у вас очевидно все-таки на КО/скрам-мастера проблемы повязаны .. хз, если нереально сменить его\ее или проект — меняйте контору, но не признавайтесь почему :) скрам ИМХО слишком модная методология, чтобы ее не внедряли везде где есть бабластый клиент.

спасибо за мнение, я не имею ничего против скрама, тут проблема в его применении и в процессах

У вас нет нормального scrum
у вас внедрили систему, которую так назвали. А по сути — орг. хаос с перекладываем всего ... на инженеров. к примеру — проблемы с описании задачи, которая уже передана на исполнению инженеру — признак очень негативный
ну про PO вам уже описали

общий принцип такой:
— поспрашивайте про процессы, кто и что дает, как задача движется и так далее
и если явно видите 5-е колесо в телеге, как Ваша липовая PO — делайте выводы

У вас нет нормального scrum

Його ніде нема нормального :)

Його ніде нема нормального :)

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

В результате осталось:
— утренние митинги по 15 минут перед началом работы
— спринты, у нас это релизы, куда мы набрасываем таски, которые нужно сделать за месяц-два.

Всё, больше ничего и не нужно, работа идёт как надо.

Проблема не в том, что ваш product owner нетехнический. Он и не должен быть техническим и вы таких почти нигде не найдёте кроме продуктовых компаний, где продукт — это технология (условной MongoDB, Inc.). Он должен быть доменным экспертом.

Проблема в том, что ваш product owner — это не product owner, а бессмысленное прокси для реальных PO, которые так и остались на стороне заказчика. Настоящий PO полностью владеет и управляет требованиями и ему не нужно куда-то «ходить» и кому-то что-то «доносить». Да, он формирует требования в контексте работы других отделов типа маркетинга, комплаенса и т.д. Но на уровне разработчиков он является единственным источником правды.

Посему совет: ищите не технического PO, а реального PO проекта. Если вас к нему не пускают, тогда уходите с проекта. И, скорее всего, из аутсорсинга, потому что там это повальная проблема. Они называют этих прокси «бизнес аналитик». Идите либо в продукт, либо в аутстаф.

. Он и не должен быть техническим

Ніт, повинен. Я багато разів чув цю фразу від менеджменту, але жодного разу це не спрацювало.

и вы таких почти нигде не найдёте кроме продуктовых компаний

Неправда, в усіх *нормальних* проектах у мене були саме технічні. А там де з’являлись «нетехнічні» — одразу починалась бюрократія. Він не повинен бути суперпрограмістом, але технічний бекграунд і розуміння клієнт-серверної архітектури необхідне, щоб він дійсно був корисним. І домен не так часто буває «нетехнічним» як хотілося б. Точніше, в реальності — майже ніколи.

Посему совет: ищите не технического PO, а реального PO проекта.

Шукайте реального РО проекта, але з технічним бекграундом.

Нахуа?
PO говорит о бизнес требованиях, что должно получиться. Как должна работать логика, как считаться проценты, на какой «пакет» переводить пользователей со старого пакета если его дисейблим. Должен ли быть френдли фаер в игре, описать flow возврата денег для пользователя (всё образно).
Это человек который знает что в итоге должно получиться и понимает все процессы в продукте (не с технической стороны, а со стороны пользователя). И к нему обращаешься с вопросами по неочевидным кейсам, а их бывает постоянно.

Возможно имеешь ввиду какого-то тех.лида, не product owner’а.

Колись я теж вірив в таких єдинорогів, вже ні.

У нас зараз головний ПО — з тех. бекграундом, і це просто земля і небо в порівнянні з гуманітаріями. До нього можна просто прийти і спитати: а чому не зробити «отак»? І він скаже: точно, давай так, гарна ідея.

А не збере мітинг на 2 години з усіма техлідами і командами на наступному тижні.

Бо він розуміє не тільки для чого це, але і в загальних рисах ЯК це все взагалі функціонує.

А розмазана відповідальність за рішення веде тільки до бюрократії та тупому форвардінгу імейлів/меседжів.

Так нет же никакой размазанной ответственности.
PO — главный на проекте. Он рулит тем куда проект движется и какой результат будет в итоге.
То что не во всех конторах так — это уже дрогой вопрос, это не PO, а как сказали — прокси.

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

PO — главный на проекте. Он рулит тем куда проект движется и какой результат будет в итоге.

вот тут и начинаются проблемы (описанные комментом выше)
Когда нетехнический рулит технарями, немедицинский медиками и тп.
Это не про управление, а про «кэрувать людями»

Сколько проектов зафакаплено такими керивныками без знаний.

PO рулит стратегически, в плане какие фичи делаем, их приоритеты и какая бизнес-логика нужна. А непосредственно людьми он может и не рулить и не понимать тонкостей организации тех.процесса. Там уже project manager или тим.лид по тактическим моментам.

Ключевая задача PO — отвечать на вопрос «что делаем», а как делаем (с технической стороны) — в общем случае не к нему вопрос.

У нас зараз головний ПО — з тех. бекграундом, і це просто земля і небо в порівнянні з гуманітаріями. До нього можна просто прийти і спитати: а чому не зробити «отак»? І він скаже: точно, давай так, гарна ідея.

Что такое «отак»? Деталь реализации или user story? Если второе, то это можно обсуждать с любым «нетехническим» PO, но доменным экспертом.
Если это первое и вы обсуждаете с PO outer join vs inner join, то вы просто грузите его своей ответственностью. Тот факт, что он может и рад с вами это обсуждать конечно удобен для вас, но вовсе не значит, что это хорошо и так должно быть всюду.

Я не исключаю, что у вас реально очень технический проект по своей природе и что ваши PO должны знать условный outer join vs inner join в рамках работы с требованиями. Тогда это часть их бизнес домена и их компетенции.
Но я также не исключаю факта, что вы просто грузите часть работы EMа/техлида на PO и он это тянет. Могу только порадоваться за вас, это примерно как реальный full stack dev, удобный и выгодный.

который знает

который нихуа не знает и просит заэстимировать 20 сторей за 1 час на внезапном митинге

Этими стори-эстимациями и внутренней кухней project manager должен, конечно, заниматься.
Но если аутсорс, то PO часто вообще нет, есть ТЗ + свой опыт + как сердце подскажет сделать.

А вообще I feel your pain )

не аутсорс
повергаю ПО в панику требованием давать внятную агенду на митинги, иначе я скипаю

Не нужно путать роль Engineering Manager (в аутсорсинге Project Manager/Team Lead) и Product Owner. Первый должен быть техническим, так как руководит техническим персоналом и проектом; второй должен быть ровно настолько техническим, насколько того требует его бизнес домен. Например, почти всем PO сейчас нужно иметь общее представление о хранении и передаче данных ввиду GDPR. Если это PO в фитехе, то сюда прилетает ещё пачка околотехнических регуляций. Но иметь «технический бекграунд» для PO — это совершенно необоснованное требование (опять же, если его продукт не технология в чистом виде).

Чисто теоретично я з Вами згоден. Але в реальності я жодного разу не бачив ефективного ПО, який або не виріс з технаря в самому проекті, або просто має технічний бекграунд. Решта були просто шлаком.

Зараз у нас, наприклад, на стороні клієнта взяли вже третього «нетехнічного» ПО (двоє попередніх за рік-півтора вже пішли) на допомогу основному, який трохи намагається відійти в сторону.

І це, на мою думку, вже третій фейл, бо їх рішення і «дизайни» все одно відкидаються і усі йдуть до старого ПО, який тепер ще проводить рев’ю епіків від нового.

Ефективний ПО повинен бути людиною на стику між бізнесом та технарями. Але не тим, хто не розуміє ні того ні другого, а тим, хто розуміє обидві частини.

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

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

Разница наверное в проектах на которых нам приходилось работать и составах команд.

Цілком можливо

собственники или лица приближённые к ним

В моєму негативному досвіді більше найманих ПО зі сторони, тому, звичайно, він не відноситься до усіх випадків.

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

прекрасно, и кто должен быть тем драйвером-переводчиком с бизнес-языка ПО на язык технических реквайрментов?
Всё равно же нужен технически грамотный человек, понимающий бизнес-домен, т.е. тот человек, который сформулирует задание техническим языком, а не «прикрутите зелёную кнопку»

тех.лид, тим.лид, бизнес-аналитик, архитектор — в разных компаниях по разному.

прекрасно, и кто должен быть тем драйвером-переводчиком с бизнес-языка ПО на язык технических реквайрментов?

Программист. Это задача программиста — перевести с человеческого языка в код.

задача программиста — перевести с человеческого языка в код.

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

Осталось дело за малым — перевести с языка «эффективного менеджера» на человеческий, и далее по вашему алгоритму

Проблема в том, что ваш product owner — это не product owner, а бессмысленное прокси для реальных PO, которые так и остались на стороне заказчика. Настоящий PO полностью владеет и управляет требованиями и ему не нужно куда-то «ходить» и кому-то что-то «доносить». Да, он формирует требования в контексте работы других отделов типа маркетинга, комплаенса и т.д. Но на уровне разработчиков он является единственным источником правды.

Таке ж саме спостереження. Просто делівері всучив і тімці, і замовнику стажера, щоб з неї щось зліпили (або нІ).

Я бізнес аналітик в аутсорсі (так зване безтолкове проксі). Щодо персони РО, то абсолютно підтримую TechnoBarbarian:
1) якщо власник продукту не може прийняти рішення, а йде до когось по рішення — це не власник (навіть якщо в нього позиція РО).
2) якщо власник продукту технічний (не через домен продукту, а тому що виріс в продукті), то це і добре і погано, бо він вже не кодить і втрачає кваліфікацію, і його поради можуть шкодити реалізації + він тратить час не на свою роботу (як вже десь згадувалось)
3) а от якщо власник продукту не знає, як має продукт заробляти гроші, то це вже біда... і те що він може сам написати всю архітектуру і код, не допоможе продукту вижити.

Тому, як вже підмічено, у вас або проксі РО (але він тоді має приймати хоч частину рішень без уточнень з РО), або БА, який має зібрати всі питання\пропозиції в команди (зрозумівши його), устаканити бізнес рішення із замовником і вернутись з вимогами по реалізації. І от бізнес аналітик, може бути більш технічним, якщо цього потребує команда (іноді виділяють окрему роль як системний аналітик). І от основна задача аналітика зрозуміти що хоче бізнес (наприклад в лиці РО, або інших стейкхолдерів), в якому форматі команді зручно отримувати задачі і сформулювати бізнес вимоги у форматі зручному для команди.

Оскільки, замовники дуже часто англомовні, тому першим важливим елементо для розуміння бізнесу є англійська, тому в певний час, прийшло дуже багато людей, які знають англійську... і це допомагає у роботі з Клієнтом, але ускладнює роботу з командою. Для того і придумують всякі фреймворки, якими можуть користуватись і розуміти обидві сторони. Але якщо вимоги неякісно зібрані, то це недуже допоможе.

Якщо у вас є проблеми з вимогами, чи вам доводиться напряму комунікувати з стейкхолдерами і то не через те, що вони хочуть особисто вас похвалити, то це не якісна робота бізнес аналітика.
Поки команда робить продукт, то БА має підчищати всі невизначеності і спрощувати життя команди, а не навпаки.

З мого власного досвіду, я не є (принаймні не вважаю себе) з технічним бекграундом, але завжди вникаю в проблематику, щоб при спілкуванні з стейкхолдерами підібрати правильні слова і отримати результат від комунікації.

Клиенты сейчас массово нанимаеют продакт овнерами нетехнических девочек со знанием языков. И когда мы продавили кастомера, показав полную несостоятельность одной из таких, и она типа «сама ушла», через 3 мес взяли вторую такую же. С опытом управления коммандой веб-разработчиков, поставили управлять разработкой embedded team. Может это корона так влияет на заказчиков?

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

Як тільки в команді з’являється нетехнічний працівник з реальними повноваженнями — з досвіду, це завжди проблема. Він розуміє що не розуміє що тут відбувається (а ще гірше — навіть цього не розуміє) і починає робити видимість активної діяльності та своєї «корисності»: організовувати купу нікому не потрібних мітингів для «розподілення» відповідальності, вигадувати купу нетехнічних проблем, які терміново треба вирішити за рахунок ускладнення процесів та покладення на себе контролю над ними, бігати між розробниками/лідами і питати в кожного по одному незрозумілому терміну і «як би вони вирішили цю проблему», а потім намагається скомпілювати це в «своє» рішення, яке зазвичай виглядає безглуздо. Як казав один знайомий: гірше дурня може бути тільки дурень з ініціативою.

Якщо менеджмент адекватний і в цьому призначенні немає політичної складової, можна спробувати донести проблему. Але невідомо, як далеко це зайшло. І якщо це протеже когось із менеджмента, за якого поручились, то це може ще надовго затягнутись, або взагалі не вирішитись ніколи без зовнішнього аудиту та перетряхування цього болота.

Він розуміє що не розуміє що тут відбувається (а ще гірше — навіть цього не розуміє) і починає робити видимість активної діяльності та своєї «корисності»: організовувати купу нікому не потрібних мітингів для «розподілення» відповідальності, вигадувати купу нетехнічних проблем, які терміново треба вирішити за рахунок ускладнення процесів та покладення на себе контролю над ними, бігати між розробниками/лідами і питати в кожного по одному незрозумілому терміну і «як би вони вирішили цю проблему», а потім намагається скомпілювати це в «своє» рішення, яке зазвичай виглядає безглуздо. Як казав один знайомий: гірше дурня може бути тільки дурень з ініціативою.

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

Про ненависть не писав, але так, навіть це було :)

дураков с инициативой — вон на рынке скока :( и проектами перебирают :)) Опять-таки, по идее скрам должен был бы защищать от этого явления, но нам-то не сложно все довести до маразма :(

Як тільки в команді з’являється нетехнічний працівник з реальними повноваженнями — з досвіду, це завжди проблема.

Й проблеми зазвичай пропорцiйнi повноваженням.

в последние 1,5 года поменялись процессы — внедрение православного скрама с церемониями и ролями. появился продукт-оунер на нашей стороне — и большая часть деятельности сводится на разбор задач с ней, проверку за ней описаний требований, на разъяснение технических деталей

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

Пока программисты унижали других программистов на интервью и после — в отрасль незаметно прокрались гуманитарии, в большом количестве.

Чем больше проект превращается в КВН, тем меньше места техническим аспектам и в целом работа теряет вкус.

У нас в auth0 продакт-менеджери пишуть епік, а тімліди призначають серед сіньйорів+тімлідів хто буде фіча-овнером. Тоді вже фіча-оунери розбивають епік на підзадачі, які потрапляють у беклог. На наступному грумінгу-плануванні роблять із беклогу спрінт. Коуч-скраммайстер (нетехнічна особа) при цьому просто веде мітинг, ставить естімейти і клацає кнопки в джирі.

Коли береш таску, просто зідзвонюєшся з фіча-оунером, якщо раптом щось не ясно і виясняєте все. Особливо це корисно, бо фіча овнери вчаться писати кращі описи. Іноді сам створюєш сабтаски, бо у нас просять на кожен пуллреквест мати тікет.

Коуч-скраммайстер (нетехнічна особа) при цьому просто веде мітинг, ставить естімейти і клацає кнопки в джирі.

Дуже корисна людина, відразу помітно

Ми з лондонцями працюємо в досить адекватному Скрамі (я якраз його адепт і не вважаю зайвим чи обтяжливим). В нашій тімці PM з’явився недавно і наразі лондонська тімлідка введення його в курс справи повністю взяла на себе, відгородивши нас від того, що ви описуєте. В нас взагалі в команді за наявності дев‘яти інженерів цілком синергетичне тривладдя (лід дев у Львові, тобто я, лід дев у Лондоні і ще вона як тімлід) і запровадження продакта нам зовсім не заважає, поки що навіть допомагає, оскільки він десь запрезентує, десь з бізнесом поспілкується, десь з продуктовим департаментом по стратегії, а деталізуємо задачі все одно ми.

Але є нюанс — він в Лондоні, він в темі фінтех домену (був відсутній з причини РошГаШана, що символізує навіть генетичну спорідненість із ним) і в структурі замовника. У вашому ж випадку це типовий аутсорсинг у ненависній мені формі — керівництво вибило оплачувану (а може й ні!) позицію продакта і закинуло туди непідготовлену людину. Страждають всі — ви, вона (їй отак теж мало кайфу, повірте), інтереси замовника. Добре лише аутсорсеру — лавеха мутиться вже і зараз (а може й ні), а в перспективі на вашому горбі вийде підготувати ще одного продакта (а може й ні) і взагалі, і для вашого домену.

Зрештою, це і не Скрам, коли вона вже ПО, але ви маєте їй пояснити, що й до чого у вашому беклозі. Це якийсь недосекретар проєкту, який намагається адаптуватися до існуючого процесу і може колись потім почати в нього щось вносити.

А что то ее любит (до после и возможно во время)

Классическая проблема роста компании

Разумеется, везде по-разному. А то что ты описываешь — обыкновенная бюрократия. Которая ставит РИТУАЛ во главу угла. А что такое ритуал? Действия, которые «надо» делать, но никто уже не помнит, кому и зачем это надо, и соответственно нет более человека, который отменит или изменит их по мере надобности.

Скрам хорош только очень малому числу проектов, с высокой степенью самодостаточности. То есть когда по итогу получается продукт именно IT, а никак не IT как составная часть другого продукта и/или сервиса.

Ты правильно собираешься сваливать. Потому что в бюрократии виноват всегда тот, кто отказывается не замечать дерьма. Соответственно, продолжая там работать, ты зарабатываешь себе плохую карму. Делай ровно наоборот: работай на показушность, активно участвуй в ритуалах (в том числе неформальных), а когда соберёшься валить — просто скажи что у тебя там родственник работает и по блату ты получил хорошее место, где можно меньше работать, а про зарплату ты обещал не распространяться (чтобы другим не захотелось столько же).

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

Есть люди, и их больше половины популяции, для которых бюрократия — зона комфорта. Просто ты не из них. Не из тех, кто реальные проблемы пытается лечить наркотиком ритуалов.

Тільки стартап, там максимум Jira.

Морально (лол) — готуватись до пошуку нової
Коли приготувались (cv, тех співбесіда, bs for hr) — поговоріть з овнерами і TL про ситуацію
Якщо їм не сильно промили мізки, то може ситуацію ще можна виправити

Сміливо шукай нову компанію, ймовірно знайдеш те що подобається, якщо є фінансова подушка то випробувальний період працює для обох сторін.

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

В аутсорсі галері вигідно продати замовнику безліч дармоїдів типу скрам мастер і т д, тому там дуже ймовірно попасти на такий треш.

В аутстафі простіше з цим.

В аутсорсе — вполне реально. В аутстаффе — вряд ли, так как нет заказчика и «нас».

В аутстафе будет скрам мастер буржуйка.
Тупая как валянок но своя

В стартапах такого может не быть — там говнокодят на скорость.

В стартапах может быть всё. И в тех немногих, которые выстрелят, говнокодят с пониманием дела.

Подозреваю, что скоро такое будет везде... на моём опыте уже 4 компании с такими «процессами». По началу во всех 4-х было все хорошо, но со временем внедрялись дейлики... колли... запрет общаться с заказчиком... добавлялись не нужные люди (скрам мастера что-то там) куча лишних звонков которые отнимают 2-3 часа твоей жизни в день и отвлекают от решения технических задач.

апрет общаться с заказчиком

ого, никогда такого не встречал. наоборот всегда поощрялось

Оф. причина для оправдания:
— заказчик уведет команду

реальная причина, которая чаще всего стоит за таким поведением:
— заказчику продали не совсем то, что есть на самом деле
к примеру ему продали как 5 помидоров, а в реальности 1 помидор, пару мидлов и пучек джунов ...

Так, не везде, но если у тебя так, то надо сваливать однозначно, или менять продукт оунера

На корпоративн напиться и отправить в декрет

Кого, продакт овнера? а если он сильнее , или скажем ТС сильнее напьется? я п не рисковал :))

Підписатись на коментарі