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

I>>Для справки: коммуникация — взаимодействие с другими сотрудниками, коллегами.
IT>Ты это определил по-другому, а именно (повторяю ещё раз) — "его задача донести до менеджмента, объяснить, отстоять свою позицию".

Мы разбираем кейс, когда некто запрещает топик-стартеру делать рефакторинг.
Соответсвенно, топик стартер утверждает, что менеджер должен сам всё понять, а если не понял — некомпетентный идиот.

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

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

Вот новый сотрудник наткнулся на паскудство в коде и продолжать задачу не может, тк. решение вне его зоны ответственности(работа ведь поделена).
Как ему быть? Что конкретно ему надо делать?

Ну что, ты уже нашел ответ?

IT>Теперь ты пытаешься заменить это определение на очевидные вещи. Засунуть сюда ежедневное общение с коллегами, сетку-базу-итд. Не надо этого делать. Давай обсудим твоё понимание

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

> необходимости доносить все свои задачи до менеджента, объяснять и отстаивать свою позицию. Начинай.

Где ты увидел у меня "доносить все свои задачи" ? На секундночку — ссылкой, а то у меня ощущение что мы имеем дело с твоими иллюзиями.

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

I>>Для справки: коммуникация — взаимодействие с другими сотрудниками, коллегами.
IT>Ты это определил по-другому, а именно (повторяю ещё раз) — "его задача донести до менеджмента, объяснить, отстоять свою позицию".

Мы разбираем кейс, когда некто запрещает топик-стартеру делать рефакторинг: "И навсегда забыть про рефакторинг, потому что он "не увеличивает business value""
Соответсвенно, далее топик стартер утверждает, что менеджер должен сам всё понять, а если не понял — некомпетентный идиот.

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

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

Вот новый сотрудник наткнулся на паскудство в коде и продолжать задачу не может, тк. решение вне его зоны ответственности(работа ведь поделена).
Как ему быть? Что конкретно ему надо делать?

Ну что, ты уже нашел ответ?

IT>Теперь ты пытаешься заменить это определение на очевидные вещи. Засунуть сюда ежедневное общение с коллегами, сетку-базу-итд. Не надо этого делать. Давай обсудим твоё понимание

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

> необходимости доносить все свои задачи до менеджента, объяснять и отстаивать свою позицию. Начинай.

Где ты увидел у меня "доносить все свои задачи" ? На секундночку — ссылкой, а то у меня ощущение что мы имеем дело с твоими иллюзиями.