Я технический руководитель, мой босс — премьер-министр. В случае несогласия, насколько я должен настаивать на своей точке зрения?

Мы все сталкиваемся с такого рода конфликтами.

Единственное, что вы можете сделать, это ДОКУМЕНТИРОВАТЬ ВСЕ

Нет ничего плохого в том, что босс остается боссом, пока он не попытается свалить свои ошибки на других. Самый эффективный способ оттолкнуть от себя — это сделать следующее.

• Задокументируйте недостатки, которые вы видите в его подходе
• Задокументируйте последствия, которые вы предвидите, приняв его подход
• Представить альтернативный подход
• Продемонстрируйте, как ваш подход смягчит поднятые вами опасения
• Проанализируйте преимущества и недостатки каждого подхода
• Решительно заявите, что благодаря вашему анализу ваш подход будет принят.
• Сохраните всю эту документацию
• Следуйте приказам.

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

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

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

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

Если вы считаете, что их путь будет иметь серьезные негативные последствия для качества вывода, я бы убедился, что вы документируете свои опасения (и связанные с ними последствия) по электронной почте в качестве шага CYA, это не обязательно должно быть конфронтационная вещь или что-то в этом роде - просто отправьте их по электронной почте, пока проблема все еще "обсуждается", например:

Привет [босс/PM], я думал о функции X в Widgetron 3000, которую мы обсуждали, я понимаю, откуда вы пришли, и я согласен, что было бы здорово, если бы мы могли заставить эту функцию работать, но я просто обеспокоен тем, что если использовать Unobtanium, поскольку вы предполагаете, что это может привести к нестабильности конденсатора потока? И мы рискуем создать большие проблемы в будущем. Если бы вместо этого мы использовали Handwavium, разве это не позволило бы нам использовать функцию X без того же риска?

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

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

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

Вернитесь к основным требованиям и посмотрите, можно ли решить проблемы, обработав все эти небольшие специальные запросы и ошибки, и посмотрите на их повторный анализ и переписывание, и сделайте это правильно.

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

После этого сделайте шаг назад и посмотрите, более ли уместны более масштабные изменения, чем повторяющиеся исправления с болтовым креплением.

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

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

Не лгите и не преувеличивайте свою оценку. Будьте максимально точны. Будьте искренним и поддерживающим командным игроком. Ты не говоришь нет. Вы говорите: «Да, определенно, я согласен. Вот как мы это делаем». Затем он знает истинную стоимость, включая технический долг, и может решить, стоит ли оно того, и насколько оно соответствует другим приоритетам.

Эта техника может быть действительно эффективной. Я впервые узнал об этом в контексте воспитания детей, и это работает во всех, казалось бы, безвыходных ситуациях. Подводя итог, спросите себя, что вам нужно, чтобы сказать «да». Ответ почти никогда не бывает ничем, и вы будете удивлены, что другая сторона тоже готова уступить.

Как я понимаю из вашего описания, ваш PM отвечает за требования, а вы отвечаете за их реализацию. Требования всегда должны быть задокументированы, даже в таких быстро меняющихся процессах, как agile/scrum. Если ваш PM запрашивает меньше документации, а не больше, это серьезный красный флаг. PM должен получать требования от заказчика, навязывать вам требования и требовать документального выполнения этих требований (модульные тесты, системные тесты, демонстрации и т. д.). работа. Если ваш PM является вашим функциональным сотрудником, теперь это проблема отдела кадров, и вам следует поговорить со своим представителем отдела кадров. Не преподносите это как жалобу, а как проблему, которую вы хотели бы решить, чтобы все могли вернуться к работе.

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

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

Например, PM хочет функцию X. Вы хотите внести изменения A, B и C. Вы просто говорите:

Чтобы доставить X, нам нужно, чтобы A, B и C были на месте. Мы не можем доставить X, не доставив сначала A, B и C.

Объясните, что A, B и C требуются для X. Если PM хочет X, то PM также получает A, B и C. Не вдавайтесь в слишком много деталей. PM не является техническим специалистом, и от него не ожидается, что он поймет, почему X зависит от A, B и C.

Если X действительно не зависит от A, B и C, не используйте этот подход.

Помните, что никому не нужны сломанные программы, даже продакт-менеджеру.

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

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

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

В конце концов, вы вносите предложения, а PM принимает решения. Надеюсь, ваш уровень ответственности пропорционален вашему уровню полномочий.

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

В моей ситуации это был младший разработчик, который постоянно задавал вопросы и оспаривал решения, которые я принимал в отношении проекта.

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

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

Что я сделал, так это четко определил его роли и обязанности и начал относиться к нему не как к приятелю, а как к менеджеру Дева. Когда он сейчас начинает бросать мне вызов, я позволяю ему зайти так далеко, а потом говорю что-то вроде: «Решать это не твоя ответственность».

Хотя у вас совсем другая ситуация, мой ответ для вас таков:

Вы не можете решать какие-либо технические вопросы, пока есть нерешенные личные проблемы.

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

Как только вы уберете это с пути, вы можете начать заниматься техническими вопросами. Вот несколько советов:

1. Я И ВЫ, а не Я VS Вы : В споре не должно быть проигравших, должно быть только 2 победителя. Если вы начнете с позиции и цели, что вы оба должны победить, спора действительно не будет, и проект/задача будут успешными.
2. Разбирайтесь с одной проблемой за раз : скажите: «Я хотел бы встретиться с вами, чтобы обсудить ____», а затем придерживайтесь ее... не поднимайте другие вопросы. Если он спросит вас о других проблемных областях, просто скажите что-то вроде: «Я пока не готов это обсуждать».
3. Стремитесь к победе : не гонитесь за большим слоном в комнате. Работайте над более мелкими проблемами и создайте шаблон, с которым вы сможете работать вместе, прежде чем решать какие-либо из основных проблем.
4. Будьте готовы : «Вы попросили меня реализовать эту функцию таким образом, и я просто хочу показать вам, что я составил смету расходов, и на ее реализацию, вероятно, уйдет XXX часов. Теперь у меня есть несколько других идей, которые могли бы достичь цель, но может быть проще и дешевле реализовать».
5. Послушайте его : если вы сосредоточитесь только на том, что собираетесь сказать дальше, или играете со своим телефоном... для него будет очевидно, что вы его не слушаете. Представьте, что вы оба стоите на противоположных берегах реки, а между вами парит в воздухе предмет, которого вы никогда раньше не видели. Вы никогда не сможете увидеть его сторону, потому что вы не можете пересечь реку, так что у вас есть своя точка зрения, а у него своя . Но вы можете послушать, как он описывает то, что видит; и вы также можете изучить объект, прогуливаясь вверх и вниз по течению, чтобы получить другой вид с вашей стороны. Нет ничего плохого в том, чтобы иметь разные мнения, но, слушая, вы можете начать ценить его точку зрения.
6. Делайте перерывы : на ваших встречах, если что-то не решено и ситуация накаляется... попросите сделать перерыв. Давление, когда один из вас расстроен, только усугубит ситуацию.
7. Не сосредотачивайтесь на негативе : если вы сосредоточитесь на миллионе причин, по которым его идея не сработает, он почувствует себя подорванным и бесполезным. Если вы начнете с похвалы за то, что вам нравится в его идее, он будет более восприимчив к компромиссу. Вместо того, чтобы говорить что-то вроде «Я не буду работать, потому что...», превратите это в вопрос... «Да, я думаю, это может сработать, но как насчет ____?»
8. Примите тот факт, что у вас может не быть всей информации : могут быть вещи, которые знает менеджер проекта, но не может вам объяснить. Причины могут варьироваться от конфиденциальности до непонимания с его стороны (и это доходит до стыда). В какой-то момент вам придется принять его решение.
9. Прощение : Есть поговорка: Непрощение — это яд, который ВЫ проглатываете и надеетесь, что другой человек умрет от него. Моя жена вспоминала вещи 15-летней давности; но семинар по вопросам брака, на который мы ходили, сказал, что прошлые обиды должны пройти. Если что-то обидело вас более 30 дней назад, постарайтесь отпустить это.

Мое предложение очень простое:

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

2) Послушайте ответ менеджера проекта. Если вы чувствуете, что он что-то неправильно понял, поясните это.

3) Добавьте крайние случаи в реализацию, если руководитель проекта все еще хочет, чтобы они были в приложении.

4) Прекратите обсуждение этого вопроса, если не появится новая или актуальная информация.

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

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

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

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

Обязателен к прочтению, думаю, что ваш босс один из них: https://en.wikipedia.org/wiki/Psychopathy_in_the_workplace

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

Если вы не можете заставить начальство увидеть ситуацию и исправить ее, вы должны исправить ее сами, найдя новую работу.