Школа
Переговоры

Как защищать свои решения перед командой, как отстаивать их перед руководителем?

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

Расскажите, как защищать свои решения перед командой, как отстаивать их перед руководителем? Главный вопрос — как не портить отношения?

Разработчики хотят брать решения, которые проще в реализации, а я хочу, чтобы было удобнее пользователю. Каждый участник проекта хочет продвинуть своё решение.

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

Александр Васильев
16 авг 2019
👁 10746   🗩1
Переговоры

Как защищать свои решения перед командой, как отстаивать их перед руководителем?

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

Расскажите, как защищать свои решения перед командой, как отстаивать их перед руководителем? Главный вопрос — как не портить отношения?

Разработчики хотят брать решения, которые проще в реализации, а я хочу, чтобы было удобнее пользователю. Каждый участник проекта хочет продвинуть своё решение.

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

Александр Васильев
16 авг 2019
👁 10746   🗩1
Илья Синельников
Предприниматель, стартапер, преподаватель
Полезно
 24
24
Непонятно
  
Войдите в Бюросферу, чтобы голосовать

Александр!

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

Да и вообще, что это за проект, внутри которого коллеги не спорят друг с другом :‑)

Итак, что делать, когда стороны не могут договориться?

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

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

Я бы посоветовал метод мягкой силы и компетенции.

Мне ужасно нравится знаменитый девиз руководителя программы «Аполлон» Юджина Кранца для всех своих сотрудников, который позже стал девизом ЦУПа НАСА: tough and competent.

Competent

Прежде всего, вы должны быть уверены в своём решении. Будьте готовы подкрепить своё мнение данными и примерами. Аргумент «я дизайнер, я лучше знаю» не прокатит.

Tough

С другой стороны, вы должны быть готовы отстаивать своё решение и не идти на компромисс, если это ухудшит продукт. Потому что, как вы сами и написали, это ваша ответственность.

Остаётся вопрос, как не испортить отношения с коллегами.

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

И помните:

Никто не может наделить вас авторитетом —
авторитет можно только заработать самому
Взаимоотношения с клиентом
Полезно
 24
24
Непонятно
  
Войдите в Бюросферу, чтобы голосовать
Отправить
Поделиться
Поделиться
Запинить
Твитнуть

Комментарии

С программистами лучше дружить :‑)

Постарайтесь обсудить решение с разработчиками заранее: возможно, есть какие‑то ограничения. В противном случае вы потратите время на разработку решения, которое будет отвергнуто, например, из‑за того, что у компании нет ресурсов на его внедрение. Кроме того, разработчики тоже могут предложить полезную идею. Даже если предложат дурную идею, попробуйте обсудить с ними: почему? Возможно, даже удастся придумать ещё лучшее решение.

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

Рекомендуем другие советы