Здравствуйте, AlbertNovinskiy, Вы писали:

AN>- На старте проекта — я проектировал все решение. Но через 8 месяцев — мои обязанности сильно сузились и БА с менеджером сейчас рассказывают команде, что делать

А как надо?

"бизнес-аналитик" звучит как калька с английского. Но какой эпохи?

Я в США проработал почти 35 лет, и не помню (склероз?) такой должности в команде.

Архитектор — понятно. Менеджер проекта — тоже.
Последние много лет был Technical Product Owner — специалист в прикладной области.
Он отвечал за то, какие функции надо добавить, за контакт с заказчиком, и т.д.
Архитектор выбирал архитектуру, frameworks (как это будет по-русски? )
Если фундаментальных изменений не требуется — архитектор может отдыхать.

А у вас не так?

Здравствуйте, AlbertNovinskiy, Вы писали:

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

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

AN>Стало быть надо действовать в том же духе — убеждать менеджера в обратном, а лучше его лид-менеджера?

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

Убеждать менеджера в том, что ты нужен, затея чаще всего провальная, такое убеждение скорее всего даст обратный эффект. Лучше узнай его мнение на этот счет напрямую, это гораздо эффективнее. Если видишь серьезные сомнения — вали оттуда нафиг, в такой атмосфере через какое-то время ты и сам начнешь сомневаться нужен ли ты. Я повидал менеджеров вплоть до CEO, которые не понимают зачем нужна архитектура и дисциплина в процессах подготовки требований и разработки. Все они либо приходили на готовый нормальный продукт с отлаженными процессами, который выдерживал много лет пробелы в управлении, либо имели полный и неуправляемый фарш вместо продукта, но считали причиной этого что угодно (неправильный стек, тупые программисты), но не собственные кадровые решения.

K>>>это война.

МПИ>>крысиные бега тогда уж

K>да какие там бега
K>за такие фокусы сразу на мороз выкидывают
K>чтобы не выкинули нужно хорошие корни пустить в фирме-работодателе

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

а на работе ты сегодня полезен, а завтра фирма на грани разорения и тебя сокращают независимо от вклада или компетентности

Здравствуйте, AlbertNovinskiy, Вы писали:

AN>Работаю в аутсорс-компании 2 года на позиции архитектора приложений.
. ...
AN>в) Как вести себя, когда тебя намерянно игнорируют и не считаются с мнением — я не знаю. Саботировать я не привык и не делал так раньше, но по факту для меня работы почти не остается, когда весь дизайн системы на себя забирает аналитик

AN>Можно на них как-то повлиять?

AN>Как себя вести?

По субъективному опыту предложу 3 шага:

1. Поставить себя на место аналитика/менеджера. Тут нужна фантазия, конечно
Я сам часто исполнял роль архитектора, и сталкивался с ситуацией, что мой тех. начальник (aka CTO) принимает решения, пользуясь административным ресурсом. Я пытаюсь объективно донести до него недостатки его решения, он выслушивает. Но в итоге продвигает своё решение с аргументом "ну и что...".
Сначала меня это дико раздражало, но попытки настаивать на своём приводили только к тому, что меня просто реже приглашали на созвоны с заказчиком (может это и плюс? )

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

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

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

3. Обязательно подстелить соломку. Тут главное — спокойствие.
Говорить про проблемы надо, но без эмоций, иначе тебя обязательно назовут "токсичным". Желательно письменно, чтобы видели вышестоящие менеджеры.
Как по мне, идеальное начало письма: "В данном рещении я вижу следующие риски:", а дальше чисто техническая информация.

Например, СТО хочет перенести настройки прав доступа из хардкода в таблицы БД. Я озвучиваю риски, что из-за человеческого фактора на прод может попасть непротестированная конфигурация безопасности, что приведет к утечкам. Фичу всё равно сделают, но если из-за ошибки оператора все подряд увидят финансовые данные, я покажу письмо со словами "а я говорил!"


Буду рад, еслм что-то пригодится

Здравствуйте, AlbertNovinskiy, Вы писали:

Pzz>>Кто у вас имеет право ставить задачи кому? Или у вас любой желающий может закинуть в систему задачку, и она станет обязательной для исполнения?

AN>Я могу ставить задачи разработчикам, технические (типа рефакторинг, логи, коннект к новому ресурсу итд). До прихода БА — все делал я, не сказать что по учебнику, но как-то работали.
AN>БА по идее заведует всем беклогом/планированием спринтов/юзер-сторями. Чего я добиваюсь — это чтобы он хотя бы согласовывал со мной эти задачи, прежде чем пускать их в работу команде.

Ну ОК. Вот ты подкидываешь задач разработчикам. БА тоже, судя по всему, подкидывает. А кто решает, в каком порядке делать эти задачи?

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

Pzz>>Ну, если система успешно строится в обход тебя, ты действительно не нужен этой команде
Pzz>>Ключевое слово тут — "успещно".

AN>Эта тенденция наметилась только последний месяц. Пока выводов никто не делает. Но когда дело дойдет сугубо до технической части — без архитектора они не справятся.

А в чём заключается твоя задача, как архитектора?

Pzz>>Но зарплату-то платят?

AN>Зарплату платят, но работать тошно, когда тебя игнорят, в проекте который я же и создавал с нуля.

Ну, это капитализьм. Он такой. Отчуждает результаты труда.

Здравствуйте, SDiez, Вы писали:

SD>Я понял, что будь на его месте, я вел бы себя точно так же. Нет никакого желания нести личную ответственность за решения другого человека, пусть даже весьма опытного.

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

SD>3. Обязательно подстелить соломку. Тут главное — спокойствие.
SD>Говорить про проблемы надо, но без эмоций, иначе тебя обязательно назовут "токсичным". Желательно письменно, чтобы видели вышестоящие менеджеры.
SD>Как по мне, идеальное начало письма: "В данном рещении я вижу следующие риски:", а дальше чисто техническая информация.

И в общем и целом, выигрывает не компетенция и экспертиза, а умение правильно и вовремя говорить на корпоративном языке

SD>Например, СТО хочет перенести настройки прав доступа из хардкода в таблицы БД. Я озвучиваю риски, что из-за человеческого фактора на прод может попасть непротестированная конфигурация безопасности, что приведет к утечкам. Фичу всё равно сделают, но если из-за ошибки оператора все подряд увидят финансовые данные, я покажу письмо со словами "а я говорил!"

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

Здравствуйте, AlbertNovinskiy, Вы писали:

AN>Как себя вести?

Да уже пофиг как. Похоже тебя почти уволили.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, SDiez, Вы писали:

SD>>Я понял, что будь на его месте, я вел бы себя точно так же. Нет никакого желания нести личную ответственность за решения другого человека, пусть даже весьма опытного.

Pzz>Это, кстати, незывается "неумение делегировать". Человек, не умеющий делегировать, вынужден тащить всё на себе, и рано или поздно упрётся в предел своих возможностей.

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

SD>>Например, СТО хочет перенести настройки прав доступа из хардкода в таблицы БД. Я озвучиваю риски, что из-за человеческого фактора на прод может попасть непротестированная конфигурация безопасности, что приведет к утечкам. Фичу всё равно сделают, но если из-за ошибки оператора все подряд увидят финансовые данные, я покажу письмо со словами "а я говорил!"

Pzz>Причём заметим, судя по описанию, CTO правильно хочет. И риски тоже очевидны. Если бы я был на месте CTO, я предпочёл бы услышать не доклад об очевидных рисках, явно сделанный для прикрытия собственной задницы, а предложение о том, как технически подстраховаться от этих рисков.

Ну естественно, я предлагал альтернативы, но безуспешно

Здравствуйте, VladFein, Вы писали:

VF>"бизнес-аналитик" звучит как калька с английского. Но какой эпохи?

Никуда они не делись

VF>Я в США проработал почти 35 лет, и не помню (склероз?) такой должности в команде.

А в компании?

VF>Последние много лет был Technical Product Owner — специалист в прикладной области.

А как насчет Business Product Owner'а? Или просто Product Owner'а?

VF>Он отвечал за то, какие функции надо добавить, за контакт с заказчиком, и т.д.

Если у вас не на 146% технологический продукт и/или компания не из нескольких человек, то выделенное у него и осуществляется через разного рода "бизнес-аналитиков," другое дело, что бизнес-аналитик, ставящий задачи разработчикам напрямую — это сюр какой-то, конечно

Здравствуйте, AlbertNovinskiy, Вы писали:

AN>а) Пойти к лид-менеджеру (начальнику) моего прямого менеджера
AN>и рассказать про потенциальные риски проекту, которые несет такой подход, при создании системы в обход архитектора. Про разделение обязательств.
AN>Не уверен что он как-то повлияет на ситуацию, но я хотя бы обозначу проблему

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

AN>б) Я могу погорить с менеджерами на стороне заказчика.

не красиво и чревато

Здравствуйте, AlbertNovinskiy, Вы писали:

AN>Работаю в аутсорс-компании 2 года на позиции архитектора приложений.
AN>Успешно закончил проект с одной командой, и год работаю в другой.
AN>До последнего времени, большинство задач для команды создавал
AN>я сам, либо согласовывали с прошлым аналитиком, который ушел. Систему проектировал я, с нуля.


Если аналитик это на самом деле это то типа технического лида то все встает на свои места и все как бы нормально.
Предполагаю твои знания были очень важны в прошедшие 2 года начала разработки твоей новой системы. Теперь систему могут продолжать вести другие люди, команда? Не совсем понятно это другие системы или таже самая. Если та же самая то в этом нет ничего странного или плохого. Такая и работа архитектора. Сделал архитектуру одной системы, изобретай и делай следующую. На то ты и архитектор. Если хочешь сам задачи создавать, делегировать и проверять результаты — переходи в лиды. Они это делают. Кстати лид бывает не прямо все до конца понимает. Если ему надо что-то тонкое где-то понять он спрашивает у архитектора. Я надеюсь когда они к тебе приходили ты им же все рассказывал что и как и отвечал на вопросы а не говорил ооо!... да ту тут надо сначала FR/NFR. Если по факту они и сами справляются без тебя значит все нормально и так. И требовать от лида согласовывать прямо все задачи с архитектором как то не очень. Получается ты как бы хочешь быть лидом лида. Кстати прошлый аналитик может и был с тобой в отличных отношениях именно до поры до времени а не потому что он какой-то лучше чем новый.