Comments 5
Я благодарен тем, кто плюсует мои материалы,
- Во первых потому, что хочется и дальше делиться тем опытом, который сам находил по граблям
- Во вторых, есть вариант поправить свою карму, тогда больше людей смогут воспользоваться тем о чем я пишу.
Если у вас есть какие то вопросы, связанные с трансформационными процессами продуктов, спрашивайте. Возможно ответы на ваши вопросы будут темами следующих текстов или пишите в комментариях я отвечу там.
Еще раз спасибо
Исходя из своего опыта по данной теме есть вопрос:
Что делать, если в компании начинается сопротивление или грызня по поводу видения путей трансформации среди разработчиков. Это стало особенно актуально в последние годы, когда на рынке произошла нехватка специалистов и они этим пользуются, заставляя считаться с их мнением. Например, между отделами есть конфликт на почве основных свойств архитектуры нового продукта. Все встали в позу и не идут на компромисс. Трансформация встала.
Привет. Все верно, это самая распространенная задача. Конечно нет тут зеленой пилюли, которая бы подошла для всех ситуаций. Однако вот, что можно попробовать.
1 - как я писал, стоит иметь роль - главный менеджер трансформации, немного забегая вперед, я собирался дальше написать текст когда нет специалиста, которому можно поручить эту роль, так вот при наличии человека на этой роли, со всеми характеристиками, которые я описал - ситуации жесткого противостояния быть не должно, в силу авторитета человека на роли менеджера трансформации.
2 - Если мы говорим о том, что два подразделения не договорились об одной архитектуре, то у меня вопрос, какие два подразделения имеют равноценное влияние на выработку архитектуры продукта?
3 - При дефиците кадров, о котором явно написано, все равно смена работы - это большая головная боль для каждого, и вряд ли стороны, готовы пойти на принцип и потерять место. Тут может сработать тезис, что обе конфликтующий команды в одной лодке и если они не договорятся , то рано или поздно им придется всем активно воспользоваться спасательным жилетом индивидуального пользования на большой воде.
4 - Вариант пригласить стороннего человека на роль ментора трансформации, при чем желательно на весь процесс. Если нет возможности или желание, приглашать такого специалиста, то назначить встречу двух конфликтующих сторон и пригласить на эту встречу грамотного модератора, который должен обеспечить принятие единого решения.
Вот это лишь несколько вариантов, для более качественного разбора ситуации мне нужны подробности. Если интересно можно пообщаться напрямую.
Спасибо за ответ!
1 - согласен, авторитет тут бы помог, но увы, таковых не оказалось
2 - есть две почти самостоятельные части продукта которые разрабатываются двумя подразделениями (одно проектируется для работы на "железе", другое - системный софт). И есть взаимодействие между этими частями, которое сильно влияет на реализацию и той и другой части.
3 - такого исхода больше опасается руководство
4 - да, согласен, сторонний человек тут мог бы помочь, но есть опасение, что его тоже не воспримут как авторитета
День добрый.
1 - по моему опыту в компании так или иначе авторитет всегда есть, если это не технический авторитет то точно есть управленческий, и если не авторитет, то человек мнение которого важно. Можно обратиться к нему , но тут важно чтобы он не принял чью то сторону а смотрел на компанию в целом, это не просто.
2 - тут нужны детали, по моему мнению это очень опасная ситуация с точки зрения бизнеса компании. Стоит подумать как трансформировать систему для того чтобы убрать этот риск
3 - это уже известный риск, и нужно просто приписать варианты минимизации этого риска.
4 - Ну это смотря какой человек, тут важно не как его воспримут, а то что будет достигнута договоренность, Вот в чем роль этого привлекаемого специалиста.
Есть способы как принять решение при противоборствующих сторонах
Трансформация или чемодан без ручки (часть 6). Первые грабли, как обойти их и не получить при этом в лоб