Comments 38
А как решаете вопросы чрезмерного развития навыка? Например, если сотрудник настроен излишне искать компромиссы во вред результату? Если старается максимально избежать конфликта?
Есть ли пример случаев, когда дешевле нанять "переводчика" Для высококлассного спеца, чем обучать его владению софт-скиллами?
Здравствуйте!
Если честно, не совсем понял про чрезмерное развитие навыка. Не сталкивался с таким. Из контекста понял, что речь скорее наоборот недоразвитие переговорных :) есть треннинги по управлению конфликтам и жестким переговорам (это не обязательно про миллиардные контракты). Ну и нужно донести до коллеги, что бояться конфликтов не надо. Следует сделать упор на развитие аргументации и, как писалось выше, на конфликтные переговоры. Отстаивание точки зрения с набором аргументов проще.
Про "переводчиков". Да, такие примеры тоже есть. "Переводчиков" мы называем "интерфейс наружу" :) но это промежуточная мера. Все-таки эффективней для Компании развить высококлассного спеца и затем отпускать его в свободное плавание (но временно к нему можно и иного нужно приставить "интерфейс").
Здравствуйте, Дмитрий. Вы разработчик? Из Вашего ответа, начинающегося со слов "я не понял, что Вы спросили", можно сделать вывод, что анализ Вы предпочитате делать только внешний. А внутренний хромает.
Вполне корректно было бы начать свой ответ со слов "если я Вас правильно понял, то речь идёт о". Заметьте, какая существенная разница при неизменном смысле. Успехов ;)
Попробую предположить, что "чрезмерно" - это тогда, когда коммуникация становится конечной целью, а не средством для решения реальных проблем. В таких ситуациях можно увидеть, как, например, откровенная дичь успешно проходит код-ревью, лишь бы не создавать конфликты
по моему опыту у хороших технических специалистов все вполне хорошо с общением. им не надо тратить кучу времени на болтовню чтобы прикрыть свои слабые навыки
ну а кто критику принимает за личные оскорбления - их мнение не особо важно учитывать
Вот какие такие люди настойчиво, упорно и самозабвенно проталкивают с мощью 500 тонного пресса, что специалист-исполнитель должен уметь в менеджмент и самоменеджмент? Какое делегирование, какая мотивация персонала, какое планирование? Нет у исполнителей таких функций.
Какие продают такие и продавливают. Вроде это давно не новость.
Мне страшно представить ситуацию, когда три исполнителя-программиста начнут друг другу делегировать, а потом мотивировать. Развалом команды забрезжило...
Да и вообще, софт скиллы это же публичные выступления, эмпатия, эмоциональный интеллект и т.п. Чтобы человек смог понять что эта фраза не сарказм и ерничание, а искренний вопрос и не устроил скандал.
Письмо выглядит так как будто человека отчитывают за что то. Это не правильно.
"... Миша, ты почему на урок опоздал? А?..."
Человек не описывает проблему, которая уже есть, а задаёт очевидные вопросы, которые и сам проверить может. Факт свершился! Нужно понять-простить, если можешь, и завести багу с описанием проблемы.
Софт скилы отсутствуют у человека, который задаёт такие вопросы.
Never complain, never explain...
Софт скилы отсутствуют у человека, который задаёт такие вопросы.
Ну так для эффективного взаимодействия нехватка софт-скиллов одного должна компенсироваться избытком их у другого участника взаимодействия. Т.е. это второй должен уметь свести коммуникацию в конструктивное русло. Это, конечно, идиализированно, но без такого баланса ничего не выйдет.
Здравствуйте! Спасибо за комментарий!
Наезда в приведенном примере на самом деле никакого не было. Есть группа сопровождения, которая не всегда имеет доступ к коду (или вообще у нее нет подобной функции и профиль сотрудника не предполагает наличие такой экспертизы) и есть разработчик, который этот код писал. И представитель от саппорта как раз вопрос и задавал автору.
Не хочу опускаться в вопросы документирования, но в данном случае самое быстрое решение - получить ответ от разработчика.
1
1) Рабоатть надо в одном офисе.
2) Если работа не в одном офисе , то на письма отвечать надо развернуто.Навыком удаленной работы на практике владеют 10-20% сотрудников.
3)Существуют мессенджеры в т.ч. войсовые, написание официального письма уже говорит о проблеме с софт скиллами.
По приведенному примеру:
с софтскиллами у обоих проблемы , но не это главноре -нет построенной команды и процессов
, нет слаженного коллектива и тимбилдинга.
Софт скилы это одна из немногих мантр , с помощью которой очень хочется сделать "здоровую команду" руками самой команды. Окей - зачем тогда нужен менежмент?
Эммм, первый сотрудник написал развернутое письмо, второй ему ответил односложно. Он сразу же эскалировал, читай пожаловался руководству. Точно только у второго софт скиллы не развиты?) Уточнить или даже позвонить вариантов не было?
Побуду адвокатом дальше. Сам вопрос "Можешь помочь?" может иметь как минимум два варианта ответа. Так что возможно именно на этот вопрос и ответили то самое "нет". Бывают такие люди у которых только софт скиллы и развиты, ни код посмотреть, ни протестировать сами не могут, ни даже требования перечитать на предмет того, что там было про валидацию, работать только мешают своими "пингами"
Где-то видел фразу в духе "если фундамент вашего приложения построен исключительно на софт скиллах, то и надёжность его будет соответствующая"
Добрый день!
Очень радостно, что приведенный пример вызвал такую бурную дискуссию :) Пожалуйста, поймите, данный пример сугубо показывает, как может рваться шаблон, если хромают коммуникации (и у спрашивающего и у отвечающего).
У нас в компании принято развернуто отвечать на поступающий вопрос. Независимо от кого, кто его задает - человек, "у которого только софт скиллы и развиты, ни код посмотреть, ни протестировать сами не могут, ни даже требования перечитать" или гуру ИТ. И независимо от канала поступления - телефон, почта, мессенджер и т.д.
И этого правила стараемся придерживаться.
Читаю это все и в очередной раз убеждаюсь, что менеджер инженеру не товарищ. А в данном случае еще и субъект, пытающийся слить свою работу на других,
чтобы менеджер мог нормально работать над развитием и над стратегическими задачами, а не решать за своих сотрудников эскалационные вопросы
Ага, точняк. С таким паразитом я бы не стал работать.
Приведен удивительный диалог.
Что мешает переспросить, на какой вопрос был дан ответ?
Что мешает переспросить ответы на остальные вопросы?
Если спрашивающий считает себя сильнее "совтово", то он должен давать пример, как себя вести. Именно такие случаи и дадут возможность другим себя вести корректно по отношению к коллегам.
Будь примером и другие подтянутся.
Здрасствуйте!
Более подробно ответил в комментарии выше для pavelsc.
Ага, если я буду неадекватно отвечать на письма, если я не буду
подпускать к себе никого и отвечать односложно и неразвернуто, меня
просто перестанут спрашивать, у меня будет меньше работы
Мудро.
Вам не приходило в голову, что у тех, у кого развиты софт-скиллы (бр-р, слово-то какое мерзкое) объём переписки растёт, а на содержательную работу просто не остаётся времени?
Здравствуйте! А почему с ростом софт-скиллов должна падать продуктивность (содержательная работа)?
Ну вот вы же пишете – если отвечать по-хамски, то к тебе перестанут обращаться, и освободится время для работы. Понятно, что должен быть какой-то баланс, и хамить не надо. Но опыт показывает, что чем подробнее и вежливее ты отвечаешь, тем больше к тебе обращаются с вопросами и тем меньше времени для собственно работы.
Короче — у вас нет ничего про все те навыки, которые отсутствуют в красивых сказках для разработчиков младшего возраста, но более чем часто встречаются в реальной жизни.
Почему?
Здравствуйте! Интересы у всех разные. В статьей отражён мой опыт и те навыки, которые лично я считаю важными.
Мое мнение, что уважение коллег и видимость заслуг неминуемо приходит при эффективном и качественном исполнении своей работы и не токсичных, корректных коммуникациях.
Надеюсь ответил на ваш вопрос, не разжигая холивар)
Мое мнение, что уважение коллег и видимость заслуг неминуемо приходит при эффективном и качественном исполнении своей работы и не токсичных, корректных коммуникациях.Нетоксичность — это очень серьезное ограничение, нередко нарушаемое на практике.
Я вам завидую по-хорошему, что вам, похоже, повезло видеть жизнь исключительно со светлой стороны. Но в реальности, к сожалению, нередко (я думаю, что в большинстве случаев, но статистики у меня нет) эффективность и качество работы оценивается руководством по умению ее показать, а рабочие коллективы живут по «закону курятника» (если надо — поясню, что это за закон).
А потому ограничивать свое знание оптимистичными статьями, подобными этой, где темные стороны не упомянуты, является опасным.
Столкнулся с такими "лидами" с не развитыми софтами, которые необоснованно гнули свою линию, ,мешая работать, затягивая сроки ревью, не желая объяснять плюсы их решения и минусы моего рабочего решения, без четких задокументированных регламентов к код стайлу и как результат увольнение одним днем, без основания на это.
Как IT-специалисту развивать софт-скиллы, и зачем это вообще нужно