— Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.
— Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.
— Коллега ставит в известность о новых требованиях к юнит тестам в одностороннем порядке, по надуманным поводам- у вас все юнит тесты и так работали и вообще, у вас опыт юнит тестов больше.
— Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.
Сначала лично обсудить, если доводы одной стороны не приняты другой стороной, то решать через вышестоящих в иерархии. Начальниками за то платят, чтоб это разруливали.
Здравствуйте, Homunculus, Вы писали:
H>Сначала лично обсудить, если доводы одной стороны не приняты другой стороной, то решать через вышестоящих в иерархии. Начальниками за то платят, чтоб это разруливали.
Тогда усложним задачу: коллега лижет начальству или способен заболтать уши новомодной чепухой и начальство будет на его стороне. Что делать?
.
Пессимисты говорят, что хуже быть не может,
а оптимисты всегда уверены, что — может!
Здравствуйте, sharpman, Вы писали: S>Тогда усложним задачу: коллега лижет начальству или способен заболтать уши новомодной чепухой и начальство будет на его стороне. Что делать?
Делать что должно, вести себя достойно и будь что будет.
Здравствуйте, sharpman, Вы писали:
S>Здравствуйте, Homunculus, Вы писали:
Начальниками за то платят, чтоб это разруливали.
S>Тогда усложним задачу: коллега лижет начальству или способен заболтать уши новомодной чепухой и начальство будет на его стороне. Что делать?
Встречный вопрос — а почему вы против "новомодной чепухи"? Иногда это именно то, чего не хватает проекту. Вообще для того, чтобы понять, а нужны ли эти новые фичи, новые тесты, новая "чепуха", надо собрать статистику и доказать свою точку зрения на основе данных, а не в виде "мое слово против твоего" или "раньше работало так". Имплементируем обе фичи или оба теста, делаем бенчмарк, и смотрим, что работает быстрее, легче поддерживать, удобнее релизить и т.д.
А делать выводы на основе "оно последние 5 лет работало, поэтому продолжаем" — не аргумент.
Рабочий пример. В команде был программист, 12 лет в компании, знал определенные библиотеки, поддерживал старые приложения. Начали писать более современный сайт + бэкенд переделывать постепенно, предложили ему поучиться, упирается, мол, я поддерживаю то, что уже работает, это новое мне не надо. Предложили тесты пописать, опять своё — я этот фреймворк не знаю, зачем вы меня туда тянете. Фактически,замкнутое сознание (fixed mindset). В результате из-за нежелания учиться + идти в ногу с командой его уволили, старые приложения переписали, все остались в плюсе, кроме него.
Не всегда стоит настраивать на "my way or highway"...
$>- Коллега ставит в известность о новых требованиях к юнит тестам в одностороннем порядке, по надуманным поводам- у вас все юнит тесты и так работали и вообще, у вас опыт юнит тестов больше.
Поставить заказчика/руководителя перед стоимостной оценкой, что из сделанного вами сломается и за сколько пустой работы надо будет заплатить реальными деньгами, "только чтобы этому модно-молодёжному было хорошо почесать его чувство доминирования".
Менять подходы к собеседованию, о чем тут уже многократно говорилось. Описываемые проблемы взаимодействия в команде типичны для тех мест, куда набирали олимпиадников или вынуждали решать задачки на интервью.
А с конкретными эпизодами-перлами уже нанятых людей — разбираться исходя из обстоятельств, а не сценариев. Идёт ли речь о заказной разработке под одного-двух заказчиков(аутсорц классически) или же решение внутри интернет-компании а-ля амазон/фейсбук/гугл или же данный проект является программным продуктом для b2b-сегмента.
$>Дискас.
Большинство вопросов выглядит как в твой уютненький мирок ворвался какой-то выскочка и без проса и благословения начал предлагать "новшества". Т.е. не видно, чтобы ты хотел обсудить техническую сторону вопроса.
А так обычно обсуждаем с коллегами, пытаемся найти компромисс по подходам. Потом, если что зовём лесника и он выбирает куда нам идти дальше.
M>Рабочий пример. В команде был программист, 12 лет в компании, знал определенные библиотеки, поддерживал старые приложения. Начали писать более современный сайт + бэкенд переделывать постепенно
Рабочий пример. В компании был программист (ваш покорный слуга), поддерживал старые приложения. Пришёл новый начальник, создал "второй ит-отдел" из 4 человек и начал всё переписывать на питон. Я пытался объяснить, что кода много, и он запутанный (писала куча народа, уже давно уволившегося), что всё работает 16-18 часов в сутки, что работа идёт с деньгами, что мелкая ошибка может привести к приличному ущербу... короче, через 8 месяцев начальника уволили т.к. он обещал за полгода всё переписать, но не переписал.
Да, потом пришёл ещё один инноватор ("доделывать дело раз уж начали"), но я уволился т.к. весь этот цирк — довольно нервный (куча инцидентов, и каждый раз приходится доказывать, что виноваты инноваторы, а не я и "мой старый код").
$>- Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.
Поговорить. Возможно я что-то не знаю.
$>- Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.
Поговорить. Возможно я что-то не знаю.
$>- Коллега ставит в что-то не знаюо новых требованиях к юнит тестам в одностороннем порядке, по надуманным поводам- у вас все юнит тесты и так работали и вообще, у вас опыт юнит тестов больше.
Поговорить. Возможно я что-то не знаю.
$>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.
Поговорить. Возможно я что-то не знаю.
$>Что вы будете делать?
Разговаривать. Если нет консенсуса, то привлекать третью сторону (начальника).
Здравствуйте, L.K., Вы писали:
S>>Тогда усложним задачу: коллега лижет начальству или способен заболтать уши новомодной чепухой и начальство будет на его стороне. Что делать?
LK>Если спор не принципиален — выполнять указания начальства. LK>В противном случае — увольняться.
А почему отсутствует вариант — объяснить начальству, что новомодная херота сперва проходит период хайпа, потом период разочарования и только после этого становится применима в производстве?
Объяснить в том контексте, что хайп вокруг новомодных вещей поднимается ради того, чтобы найти дурачков, готовых вложиться своими деньгами и разочароваться.
LK>>Если спор не принципиален — выполнять указания начальства. LK>>В противном случае — увольняться.
A>А почему отсутствует вариант — объяснить начальству, что новомодная херота
Потому что в условии задачи было:
коллега лижет начальству или способен заболтать уши новомодной чепухой и начальство будет на его стороне.
$>- Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.
$>- Коллега саботирует ваш PR,
хз где вы работаете с такими коллегами, у меня за 10 лет(линукс,ядро, небольшие коллективы) такого ни разу не было. бывает с тим-лидом не во всем согласны, т.к. у всех свои предпочтения, но ответственность на нем, и лично я ограничиваюсь изложением своих аргументов. гумантарии-фронтендщики наверное более склонны к конфликтам, чтож пусть страдают.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
ЭФ>Жалкое оправдание своей неспособности переподготавливать кадры. ЭФ>Если был подробный и детальный обучающий курс, не было бы никаких проблем.
это тебя там описывают? иначе почему откуда такая уверенность, что не было бы. встречал таких упёртых-приросших, как описано выше
Здравствуйте, L.K., Вы писали:
LK>>>Если спор не принципиален — выполнять указания начальства. LK>>>В противном случае — увольняться.
A>>А почему отсутствует вариант — объяснить начальству, что новомодная херота
LK>Потому что в условии задачи было:
LK>
коллега лижет начальству или способен заболтать уши новомодной чепухой и начальство будет на его стороне.
Не учитывается вариант, что «начальника» будет на его стороне лишь до того момента, пока не предприняты соответствующие меры — не сказано то, что должно прозвучать?
Это позиция затравленного раба или идиота.
Обсуждать имеет смысл то, каким образом получить должный «managing up».
А>- Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.
Подумал бы насколько это вообще адекватная реакция с моей стороны. Если улучшение действительно что-то улучшает, то подумать что же со мной не так, и почему я начал изображать из себя собаку на сене. Иначе выяснить у оппонента почему он считает это улучшением.
А>- Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.
Выяснить чем этот дизайн лучше того который есть. В вопросе слишком сферическая формулировка. Может ты зашорился, а в диффе у тебя скопился говнокод. Ведь для этого PR и существуют.
А>- Коллега ставит в известность о новых требованиях к юнит тестам в одностороннем порядке, по надуманным поводам- у вас все юнит тесты и так работали и вообще, у вас опыт юнит тестов больше.
Хз что тут вообще можно ответить без конкретики. Нужен арбитраж от человека видящего ситуацию.
А>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.
Узнать у коллеги почему именно так сделал. Или ты боишься вступить с ним в дискуссию потому, что он станет считать тебя тупым, потерять вес? Без конкретного примера сложно говорить в ту или другую сторону.
А>Что вы будете делать? Дискас.
Вот это самое и лучше делать. Вероятно привлечь третью сторону – не обязательно одного человека. Обсудить подходы. Вы же команда, а не стадо обезьян
Здравствуйте, gandjustas, Вы писали:
G>Поговорить. Возможно я что-то не знаю.
Коллега пытался объяснить, но путается в показаниях. Сделал пару докладов по неведомой ###не. Не убедил.
G>Разговаривать. Если нет консенсуса, то привлекать третью сторону (начальника).
Начальник зааппрувил пул-реквесты коллеги.
G>$>Дискас. G>Смысл? Ответ очевиден.
Что делать?
