Comments 18
Хорошая статья.
Наверное, в идеальной компании(для разработчика!) оно так и должно все быть.
Но из практики:
Восприятие критики === Делай как я сказал и не спорь
Умение слушать === И не задавай по второму кругу эти вопросы, делай как я сказал!
Логическое мышление === Думай и понимай что интересно шефу, а не тебе
Открытость новому === Нам нужно подпатчить тут код на 10летней джаве и 15 летнем mysql, это будет хорошим опытом!
Адаптируемость === А завтра перейдешь на проект с php 5.12
Поиск и анализ информации === Да, деталей в тикете нет, но ты почитай там эпик и остальные таски...
Командная работа === Понимаешь, нельзя писать такое в код ревью, люди обижаются
Управление эмоциями === ты же профессионал, и не такое видал!
========= тут начинается миддл, хотя мне кажется, что мы уже и курс сеньора прошли и переходим в менеджмент =======
Самостоятельность === мог бы помочь ребятам и проактивно посмотреть, не заканчивается ли место в базе в продакшене
Нацеленность на результат === Нашему продукту очень надо репортовать что мы доставили фичу на прод, пофиг как
Ответственность за результат === Ну а если не доставим - то только из-за твоих глупых вопросов
Инициацивность === А как ты сам думаешь, что мы от тебя хотим в следующий квартал?
Управление собственным развитием === Хаскель это, конечно, хорошо... Но может со всем коллективом выучите Paradox? Надо учится на исторических примерах
Критическое мышление === Надо было головой думать, понятно, что ты ни разу не видел 1С, но завтра же аванс!
Тайм-менеджмент === так, я в спринт вам еще две очень срочные задачи добавил, напрямую от вице-президента
Рефлексия === Ну ладно плакать. Ну да, нам еще два драйвера надо в 2.х версию ядра портировать, но ты будешь уникальным специалистом после этого!
Системное мышление === Знаешь ли ты, почему соты у пчел шестиугольные?
Убеждение и аргументация === Давай для простоты предположим, что я всегда прав. Да ты и не знаешь всех обстоятельств. И поверь, там сверху это всё не просто так затеяли.
Управление стрессом === коньяк вон там на полке
Креативность === надо бы записать ролик про нашу компанию, придумаешь что до завтра?
Письменное общение === Я тебе в чате три раза написал, а ты не отвечаешь, как можно работать и не смотреть в чат???
Обратная связь === Отзывы на нашу передачу пишем мы сами, поэтому не волнуйтесь, ваше мнение нам известно.
Планирование и целеполагание === Я думал за три года в компании ты сможешь понять нашу миссию и предназначение.
======= (переходим в высший менеджмент) сеньор-помидор ========
Наставничество === помнишь всё то, чему мы тебя учили? Пора научить и других!
Выработка и принятие решений === всегда помни: IS THIS GOOD FOR THE COMPANY?
Многозадачность === у тебя в спринте в два раза больше чем у Васи, ты же теперь сеньор. Автоматизируй!
Клиентоориентированность === Всегда говори, что делаешь это ради удобства клиента, а не компании
Планирование === А в отпуск пойдешь в марте, у нас там вроде никаких дедлайнов
Проектное мышление === Проект заберем - а там уже по месту будем думать как и что, будет день - будет пища!
Эмоциональный интеллект === И вот такие комменты на хабре не пиши! Какие такие? Вот этот вот!
Постановка задач сотрудникам === Ты видел, что Петя уходит ровно в пять? Ему что, делать нечего на работе?
Ваш токсичный сотрудник Алексей
ps. Девелоперам: помните, что в долгосрочной перспективе компания которая успешно кормит ваши мозги экономит больше и производит больше чем та, которая кормит ваш кошелек.
pps. Критикуя предлагай - считаю, что есть только один объективный критерий - если человек make things done - его надо брать. Если у него всё "тянется" - не надо брать. Все остальные критерии вторичны и не могут гарантировать при их наличии, что всё сложится хорошо. Иначе говоря - предложите на собеседовании написать мини-проект по вашей теме. А задачи про кольцо оставьте любителям головоломок. Это ничем не лучше найма людей, скажем, по размеру ноги, а просто покажет вам любителей решать головоломки(я из таких).
ppps: никогда не задумывался, что фиксированная разница в радиусах дает фиксированную разницу в длине окружности...
Это вы написали не про софт скилз, а "как тяжело быть джуниором". Это джуниоров кидают с проекта на проект, с задачи на задачу - без возможности проникнуться проблемой, порефлексировать, спланировать работу на пару недель вперёд.
Чем сеньёрнее, тем больше ожиданий от окружающих насчёт "понять проблему и объяснить коллегам и начальству", "придумать решение и объяснить коллегам и начальству", "написать дизайн-документ, чтобы зафиксировать решение где-то кроме своей головы", "напомнить коллегам и начальству, что вот есть дизайн-документ, там все ответы", "иметь яйца побыть совестью команды, когда кто-то начинает рассказывать, что дедлайн уже через 2 дня, поэтому код ревью и юнит-тесты временно нужно отменить", и т.д.
Софт скиллз - это про то, как надо себя вести, чтобы не оказываться в ситуациях вроде всех тех, которые вы предложили в своих "токсичных" примерах.
Это, конечно, была ирония, переходящая в сарказм. Но в каждой шутке есть доля шутки. Я в один из перфоманс ревью поставил себе типа below expectations, потому что знал, что можно и лучше.
Начальник переправил на above expectations, сказав что такого рода рефлексия привлекает негативное внимание к команде, вплоть до желания поставить такого сотрудника на Personal Improvement Plan.
Поэтому суть всего этого - обычный маркетинг, продать себя, свой отдел, свое направление подороже.
Есть люди, которые любят это. А есть те, кто любят технику именно за ее "бездушность и правильность". А есть такие, кто просто работу работает(и это не значит, что он ее плохо работает, просто увлечения у него совсем другие). А мы им этот маркетинг и здравый смысл впариваем.
А теперь вы пишете про перформанс ревью в большой компании и снова не про софт скиллз. Я понимаю о чём вы, только это не про софт скиллз всё, а про неадекватные попытки их измерять.
ИМХО, софт скиллз - это как качество кода: у всех есть какие-то соображения насчёт хорошего и плохого кода, но вот взять кодовую базу и сказать, что качество у неё 4.92 из 10 - это всегда глупость.
Ну почему же. Перфоманс ревью - это как раз часть развития софт скиллз, те же - правильный фидбек, наставничество, правильное целеполагание и разумная оценка прошедшего периода.
Я, правда, с автором не согласен немного про "с оценкой хард скиллов вроде все разобрались" - может, конечно, и разобрались.. Но порой так не скажешь - софт скиллы не дают сказать.
Статью надо просто заменить на ваш камент - самая суть и никакого доширака на ушах и «развивашек» :)
;(
Ты чуво наделал? У меня вьетнамские флешбеки от моей первой работы в it... именно так все и было;(
Огонь, у тебя вся боль от плохого тимлида и руководства написана очень ёмко, если ты не против, я бы утащил это для примера в будущие доклады про soft skills.
По поводу "make things done" соглашусь, это хороший критерий, когда нет времени на проработку всего остального. Но если есть время на декомпозицию человека относительно всех гибких навыков, то стоит попробовать, результат окажется лучше и более предсказуемый. Так же, как с большими задачами, можно просто сесть за неё, а можно разбить на подзадачи.
Утащить можно, отчего не утащить.
Я бы не назвал это всё плохим тимлидством или руководством. Скорее "как у всех".
Насчет декомпозиций - это все хорошо, но где брать столько людей, чтобы еще их софтскиллы перебирать? Может в FAANG столько и идет хороших кандидатов, но в компании "второго" мира как то "так".
Отличная статья. В помощь всем, кто собеседует людей и оценивает их софт скиллы. Хочется чуть больше прикладных вещей и советов в следующей статье
Весьма интересно, спасибо.
А можно ссылку на статью python разработчика который пришел со списком из 22 вопросов?
30 сек в гугле: https://habr.com/ru/post/428283/
Для доработки системы можно ещё внедрять бальную оценку каждого навыка, от 1 до 5, где 1 - требует развития и не проявляется, а 5 - является ролевой моделью.
Такая бальная система позволяет добавить «количественные» показатели, которые можно использовать по-разному: сравнивать кандидатов/сотрудников между собой, калибровать оценки в группе или использовать для измерения прогресса в индивидуальном плане развития.
Хорошо помогает снизить субъективность оценки «на глазок».
Как оценить Soft Skills на собеседовании и помочь разработчику их развить