Не кажется ли Вам, что роль soft skills исскуственно завышена и гипертрофирована?

👍НравитсяПонравилось0
В избранноеВ избранном5
LinkedIn

Лучшие комментарии пропустить

Без надлежащего контекста данные вопросы не имеют смысла.

Если по-простому: чем больше твоя команда, отдел и компания в целом (иначе говоря, твой граф отношений), тем важнее роль софт скиллов в твоей работе.

Отсюда:

нашей маленькой тиме реально смешно

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

Приведу пару примеров более близких для инженеров:
1) Вас в команде 3 человека и вы педалите, скажем, какое-то приложение. Ты хочешь использовать библиотеку А, а коллега — библиотеку B. Вы обсуждаете их плюсы и минусы стоя у кулера с водой и за 10 минут сходитесь на варианте A. Третьему коллеге вообще пофигу. Успех!
2) Вас в команде 50 человек. Из них у половины — 10+ лет опыта в лидерах рынка. Ты захотел использовать библиотеку А. Теперь тебе нужно провести анализ всех альтернативных вариантов; составить сравнительные графики производительности; написать демо; провести презентацию; переубедить всех оппонентов. Половина здесь — софт скиллы. Не умеешь так? Гипертрофированные требования? Значит будешь использовать то, что скажут люди порасторопнее и тихо плакаться в приватных чатиках, пока не уволишься.

Тот же принцип будет работать и в других ситуациях. Чья идея будет взята в работу? Кто поедет на конференцию? Чья команда получит бонусы и повышения? И так далее.

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

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

ТС, да можно называть как угодно: софт скилы, личностные качества, неспециализированные надпрофессиональные навыки — люди хотят работать с другими приятными им людьми.
Так всегда было, и будет при взаимодействии человек-человек.
И в этом желании им невозможно отказать, оно естественно :)
Кто же захочет обратного?

Дать кому-то ярлык «низкие софт скиллы» это такой корпоративный пассивно-агрессивный способ назвать кого-то мудаком.

Имеем естественный отбор с двух сторон:
Крупные структуры выбирают конформистов в силу «инстинкта» самосохранения системы
Индивидуалисты выбирают мелкие конторы, так как там больше свободы
В результате всем лучше

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ну так демократия же ж! Если большинство то значит правЫ.

Демократия устарела. Нужна сапиентократия

Ты хотел сказать скилы популизма и болотологии? ;-)

правят гуманитарии

Правят популисты.
Потому что 90% людей — идиоты. При этом я ничего не имею против гуманитариев как таковых.

Блін, як 10% сказав. В рамочку поставлю собі.

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

У нас в компании любят «гласность» — у всех боссов разного уровня есть блоги, они публикуют всякие видео-отчеты, записи с митингов менеджеров и т.д.
Так вот: выше ПМа вообще никто не разговаривает на «технические» темы! Даже среди ПМов полно тех, кто не знает разницы между Linux и Windows, потому что у них есть только айфончик и макбук.
На всех собраниях все менеджеры говорят только языком денег! Не имеет значение что за технологии на проекте, сколько там синьоров, какая там экспертиза или предметная область. Для аутсорс компании девелоперы — просто «тушки», которые генерируют профит. И цели, которые ставят на этих митингах — так же исключительно денежные! Хвалят менеджеров, чей проект приносит больше бабла, чей меньше — ругают и дают задание сократить издержки. Так же всем дают план по «росту» — потому что расти компания может только экстенсивно, набирая и продавая побольше «тушек». Даже если какая-то команда запилит «убийцу фейсбука» — это не принесет галере много профита — ведь клиенты платят не за софт, а за «жопо-часы»! А вот если на какой проект удалось воткнуть толпу вайтишников и забилить — то это успех! (и никому не важно что это за проект и какие там технологии).
Таким образом все наши технические скилы — они заканчиваются на уровне тим-лида! Все, кто выше, уже говорят на другом языке — сколько бабла можно урвать или сэкономить на каком-то решении? Блокчеин, ИИ, дополненная реальность — для них это просто модные базворды!
Так что на уровне выше инженера — уже только софт-скилы и играют роль! Я видел много архитекторов, которые давно забыли как кодить. Ведь работа архитектора — это языком, а не руками!

выше ПМа вообще никто не разговаривает на «технические» темы!

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

тех проблема которая всю компанию может угробить

Это какая-же такая проблема может быть? Компания сдает в аренду рабочие места. У нее уже даже своих серверов нету. Вся работа идет на ресурсах клиента! Даже если все компы на галере внезапно сгорят — просто купят новые ноуты и через 2 дня все продолжат педалить на клиентов как обычно.
Украинские галеры — это не ИТ компании! Это «рекрутинговые агенства» по подбору персонала в иностранные ИТ компании. Примерно как «брачные агентства», которые продают украинских невест богатым американцам.

для аутсорса не подходит, их редко парит сам продукт

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

Украинские галеры — это не ИТ компании! Это «рекрутинговые агенства» по подбору персонала в иностранные ИТ компании.

Хочу для себя разобраться в терминологии :) Под «галерой» понимается компания, которая работает исключительно по аутстафф модели?

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

Уточню — на некоторых проектах было действительно так, как ты описал, но это 100% не являлось общим правилом.

Это не гласность называется

ХЗ как это сейчас называется. Я-то еще Горбача застал с его перестройкой и гласностью.

Гласность никогда значения не меняла, политика максимально открытой информации. А у вас нда, поди, страниц на 10, о какой гласности речь?

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

А «гласность» — это открытость происходящего внутри компании. У нас это более, чем практикуется, и коллизии даже с жёсткими проектными NDA возникают крайне редко (да и, как правило, то, что подпадает под эти NDA, малоинтересно кому-то вне самой проектной команды)

зачастую запрещает даже свой доход публично говорить...

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

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

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

Нарушение NDA имело бы место, если бы разглашалось само содержание этих процедур.

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

Нарушать NDA — плохо, в отдельных случаях за это может быть и суд, тюрьма. Но это, вроде бы, и так все знают :)

Если речь именно о UBS, то Люксофт сами публично заявляли о сотрудничестве: www.luxoft.com/...​dor-contract-with-luxoft

Поэтому, саму фразу «UBS — клиент Люксофт» вряд ли можно трактовать как нарушение NDA (даже мелкое), так как «разглашённая» информация была до этого опубликована в виде пресс-релиза на официальном сайте.

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

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

Преподнестись где? В «курилке» — да, но любое публичное безосновательное обвинение в нарушении NDA (имею в виду не наш с вами диалог, где мы рассуждаем «было или нет», а от имени официальных лиц компании) — вообще говоря, потенциальный повод для встречного иска за клевету и защиту деловой репутации.

Как известно, имена клиентов часто запрещенно называть вне компании согласно NDA. Иногда это даже курьёзно выглядит. Бывало заводят людей на собеседование в офис, а в коридоре лого клиента и люди выходящие с той зоны, Wi-FI точки доступа в пределах офиса с названиями клиентов и сканируемые даже вне офисa

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

Если в «публичной» зоне офиса (куда могут попасть приходящие на собеседование) и, тем более, в именах WiFi сетей фигурируют названия клиентов, которые такого разрешения не давали — значит, ответственные за информационную безопасность в компании даром едят свой хлеб.

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

кто именно был задействован в них

Обычно это, всё же, решается через non-compete agreements, но, вероятно, какие-то клиенты перестраховываются и даже запрещают разглашать имена / фамилии работавших над их проектом. Лично не сталкивался, но вполне допускаю возможность такого.

Но слышали ли Вы о случаях перекручивания фактов о несоблюдении сотрудниками NDА, а то и очернения каких-то сотрудников такими ярлыками?

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

Как известно, имена клиентов часто запрещенно называть вне компании согласно NDA

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

Сотфскиллы это единственное, чем ПМ (который в 90% случаев не технический) и ХРюши могут манипулировать для отказа в лычке или в поднятии зп. Многие скажут, что можно дрючить и английским или хард скиллами, но тут могут нарваться на посыл нах.. в дальнейшем типа «У меня хреновый английский? Ок, долбитесь сами с клиентом, я буду молчать на митингах», «Проблемы с фреймворком? Что ж ты падла меня уговариваешь его заюзать и говоришь, что других вариантов у нас нет?». Поэтому софт скиллы это всего лишь возможность морально опустить пролетариат не нарвавшись на объектированную контр-реакцию :) . А нижеприведенные примеры, что проект из-за мудака или ненависти на проекте фейлился, лишь доказывает, что ПМов в х... не ставят и как раз им и надо прокачивать все эти скиллз, потому что это их зона ответственности. И если ПМ не может принять решение, то это точно не проблемы софтскиллз девов .

Постараюсь не мешать всё в кучу, но скажу такое:

А всё потому — что софтскиллы нельзя померять линейкой, поэтому можно говорить людям что угодно абстрактное.
Это как в Х-факторе певцов отшивают на конкурсе с комментарием «вы пели, но в вашей песни не было души».

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

Но вот у меня в одной компании странно получалось: каждый месяц стабильно с кем-то ругался, потому что ко мне цеплялись на ровном месте или грубо себя вели. (как оказалось — не только со мной так было).
Получается такой вот серпентарий, один активирует другого. Вечно раздражённые дамы из бухгалтерии, которые любят срываться на крик на случайных людей.

А в нынешней компании вообще ни единой проблемы такого плана, даже мельчайшей.

А у людей бывает и вот такое: jobs.dou.ua/...​es/evoplay/reviews/#32146

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

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

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

А всё потому — что софтскиллы нельзя померять линейкой

та лана у меня полметра!

страшно представить что в hard состоянии )

А почему тест на софт скилы спрашует больше о том как себя вести за столом в ресторане, одеваться и прочее? Это тест насколько ты хороший официант? :-)

Это тест насколько ты умеешь не пялиться на сиськи :)

Детский сад это заставлять хороших технарей заниматься всякой херней, или заявлять, что у них «недостаточно развит эмоциональный интеллект» на мониторингах. А это нормальный ответ уверенного в себе специалиста «оценщикам», все знания о проекте которых (за редким и приятным исключением) это — «наше капасити 120 поинтов в спринт». А эта необходимость просто возникла в результате желания компаний сэкономить на ПМах (боже кого я там только не видел). Кто этого не понимает, тот занимаеться своей работой и ПМа за бесплатно, кто понимает — старается работать с нормальным ПМом или вытягивать соответствующий уровень компенсации, чтобы компенсировать «душевные страдания».

Проверяй, проверяй. Таких проверяльщиков отправляют в далекий путь ибо компаний по 20-30 штук в каждом областном центре, и кроме джунов и молодых мидлов на эту хрень мало кто ведется уже :) Хотя, не было бы проблемы — не было бы темы...

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

Могу и хочу это таки две большие разницы. Особенно «хочу за бесплатно» и «могу за платно». :) Кем признанных — ассоциацией стоматологов США или определенной нишей общества или какой-то индустрией? Чувак, может ты и не плохой дев, но не создавай подтверждение данного псевдо-научного эффекта своими же словами

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

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

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

Самое что интересное — люди работают в сервисном (!) бизнесе. Они то конечно себе могут представлять, что копипастя стековерфлоу и пиля круды они строят новые боинги. Но реальность в том, что платят им за сервис — разработку ПО, чтобы у заказчиков было то, что им нужно без особой головной боли — за это они платят вполне хорошие деньги, тем более по украинским меркам.
Какой-нибудь сантехник тоже может сказать — нах мне с теми клиентами болтать и будет посылать их в жопу, главное мол «прокладку я умею менять». И ясно, чтобы сантехником нужно уметь в трубы и прокладки, просто в следующий раз это хама больше никто не позовет, но он будет свято верить, что больше кроме него в городе никто работать не умеет.

Вы или не работали с пролетариатом, или ... Максимум, что он спросит это «Что случилось?» и всем своим видом покажет, что в вашем мнении и советах не нуждается.
Теперь по теме.
Не надо путать «софтскилз» как инструмент подавления со стороны менеджерья, и софтскилз как инструмент работы. Если ПМ настолько тупой и не обладает авторитетом в команде, что не может настроить коммуникацию , то естественно он будет кричать, что софтскилз Васи и Пети говно, а он ДАртаньян, и они не достойны и при этом они почему-то на проекте и до сих пор работают. Возникает вопрос: так кто слабое звено, и чьи софтскилз надо фиксать? Технаря у которого это 2-3 навык по важности или ПМа у которого в связи с «рынком работника» этот навык найпервейший. Мой посыл был о том, что создание всяких софтскилз матриц имеет целью исключительно создание рычага влияния на девов, и ни о каком развитии речь не идет.

Да я уже понял, что я тут спорил с людьми, которые находятся в абсолютно другой реальности и наши суждения они просто о разном.
В моей реальности все эти сантехники и прочие приходящие сервисные работники очень даже воспитанные, пунктуальные и умеют общаться с людьми. Есть с ними другие минусы — аля ждать пару недель а то и месяц, если проблема не критичная, и обычно они говорят про то, что придут в такой-то день в какое-то время с 8 до 12. Поэтому нужно быть дома все 4 часа в тот день. Но зато они точно придут, не будут до этого 50 раз наяривать по телефону с тупыми вопросами, переносить, забывать, не находить твой дом. И сделают все необходимое. И не будет ощущения, что с каким-то Шариковым имеешь дело.
Хотя многие на форуме свято уверены, что в Украине хороший сервис. И даже лучше чем во всех странах Европы. Но вероятно как и под софт скиллами мы и под словом сервис понимаем разные вещи.

Если ПМ настолько тупой и не обладает авторитетом в команде, что не может настроить коммуникацию , то естественно он будет кричать, что софтскилз Васи и Пети говно, а он ДАртаньян, и они не достойны и при этом они почему-то на проекте и до сих пор работают.

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

Может просто рогоносец ))))))

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

Ага, прям фабрика штамповки флегматиков.

Ты сам заявлял, что все становятся тихими и спокойными

Даже собаки не лаят

Но коты-то хоть мурлыкают?

Все так. Я б всіх цих тренерів звільнив а кількість кадровиків поділив би на 2.

клеймить негативными отметками неугодных узурпировано большими IT-компаниями как искусстный инструмент?

Ставити оцінки як в школі? І чому він искусстный (штучний)? Нюансов а не ньюансов.
Чому комуніті а сообщество ИТ сообщество.

с техническим бекграундом

Технический фон?

что в респонсибилитис

Обязанность, ответственность.

которая часто есть уже в Интернете

Которая часто уже есть в Интернете.

Также слышал некоторые сторис про якобы клейминг ярлыками низких soft skills неугодных

Это 5.

буллинги на нотификейшн периодах

Буллили ли кого-нибудь из вас?

даже могут записать в офисе на носители информации

На папір? ШІ через Telegram намагається виявити неблагонадійних?

о кейсах клейминга конторами бывших неугодных сотрудников по части софт скилзов?

Ні.

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

Що?

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

Виходить звідси що так.

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

Можливо так, а можливо і ні.
Є люди у яких досить нудне сіре життя, а часто з малою долею комунікації з іншими людьми. Походи на конференції — можливість його урізноманітнити і надати інших кольорів. Потім викладаємо фоточки у фейсбук з крутих конференцій, і ти вже інша людина з позиції споглядачів твого профілю. Такий собі само-піар. Там тобі і ознаки великих комунікаційних навичок, і посмішка на не похмурому обличі в не офісному декорі, і, ніби навіть вумний і професійно розвиваєшся раз ходиш на конференції (принаймі так думає більшість айчарів про конфи). Чим не профіт?

Це ще не все.. Ти ще можеш шейрити пости з фотками іншим. Інші на тебе підписані. Машін лірнінг алгорітми фейсбучека тебе всяко промоутять для встановлення нових контактів (але й рекламу для тебе рідного теж промоутять). Люди лайкають тебе.. Ти такий суперський, що проско капець. Навіть сам здивований, що в тебе стільки лайків. Хтось ще комент залишить під фото.. Мовляв, малодчинка.. Супер.. Круто.. (Ну не будуть же писати, що думають інколи справді) І це ж офігітельно ніби.. Комунікація 21ого століття через соц мережі і месенджери наше все ...
І це ще НЕ все. Як відомо, основна і послана з небес неземним талантом робота менеджерів по суті — створення язиком акустичних хвиль в угоду компанії та себе з інформаційним навантаженням, що має включення різних «соусів» під яким така інформація краще виконується підлеглими і ласкає слух клієнтів. Оскільки мітінги з клієнтами не вечниє, а новостная лєнта фейсбучка не бєсконечная, то мордобук — офігений інструмент у незаповнений робчий час доставляти простому люду схожу інформацію але вже часто не в акустичній іпостасі (само-піар і піар компаній в яких вони працюють) і контролю негласному за членами команди (для ідентифікації врагів народу). Там же можна поставити лайки тому кому ти симпатизуєш та й самому понабирати. Треба ж показати, що ти соціальний і взаємодієш з колегами) Тому конференції — це просто офігенна можливість поробити фоточки на яких Вас можливо помітять і може навіть пролайкають круті боси і може запам’ятають. Це інколи можливість, так сказать, кар’єрного продвіженія для декотрих

Soft skills are overrated. Only roasties from HR would shame you for not having their version of soft skills. HR piggies and Project managers are the only evil beings in any company.

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

Фраза «хороший человек не профессия» значит что «быть хорошим человеком» недостаточно. А не то, что быть хорошим человеком не надо. Поэтому ценности какие были такие и остались — нужно быть И профессионалом И нормальным человеком.

но если выбирать или или то кого выберут? ))

В реальной жизни с большой вероятностью обоих пошлют и возьмут третьего :)

А хто наділений, зазвичай, правом визначати хто відноситься до перших, а хто до других чи там третіх? Наскільки відпрацьована методика і скільки часу займає зазвичай?

Реальные кейсы:
— заказчик свернул проект из за конфликта с ведущим программистом (ему показалось что у него испортился attitude и он не захотел продолжать работу с этой командой, команда 5 человек). Фирма потеряла проект. Причина: soft skills лида.
— хороший senior уволился потому что второй чувак на проекте м*дак который нормально ведет себя только перед менеджерами и начальством. Причина: soft skills одного из членов команды. Как альтернатива он мог не увольняться а пойти на другой проект, но это тоже так себе..

галеры штоле? так так и пиши «причина отсутствие у галер какой-либо эспертизы вообще в т.ч. как правильно разводить гребцов» ))

но понятно стрелочник гребец виноват ))

При чем тут «виноват». Просто случается всякое. В том числе и из за недостатка soft skills.

А можливо тому сеніору дали лише додаткову мотивацію перейти в контору через дорогу на зп +500 доларів і він потім був лише радий збігу обставин, що дозволили йому вийти з зони комфорту в пошуку кращих варіантів і можливостей для професійного розвитку?

Это 99% что так. В минусе не сеньор, а контора откуда он ушел. В минусе, потому что держит у себя другого товарища, с плохими софт скиллз.

Це парадоксально але всі отримали, що хотіли (чи чому не опиралися). Кризи породили нові ефективніші рішення

Думаю что «soft skills» это основа, все равно что строить дом, без фундамента... Возможно многие не знают что такое «soft skills» и поэтому не дооценивают этот факт. Для этого есть как минимум Википедия ;) А в целом, сколько было случаев, когда специалист хороши, но как человек ...

Не пали систему. Як же потім айчарам пояснювати керівникам компаній масові і не масові звільнення працівників, небажання співпрацювати з надмірно нахабнілими колегами і малоперспективними стеками технологій (для майбутніх бенефітів) як не низьким «емоційним інтелектом» чи небажанням переключатися на інші стеки і тратити не завжди раціонально час на вивчення чогось нового(попутно забуваючи більше потрібне старе). Ти зламаєш всю систему і внесеш лише хаос в буття звичайних кодерків долі яких вирішують гуманітарії і решта керуючих схожого типу, екзистенціальна сутність роботи яких боротьба зі всякою ентропією серед таких як ти.

Та й наврядчи щось вийшло б навіть якби хтось схотів це. Адже щоб вийшло і воно виглядало переконливо в очах айчарів чи менеджерів, то потрібно придумати і обгрунтувати альтернативні наукові теорії. Слід найняти декількох «британських учених» в області психології праці, опублікувати результати якихось досліджень в якихось авторитетних джерелах. В кінці кінців, створити подібні сторінки у вікіпедії з результатами таких досліджень і викладом теорії.
І лише тоді, можливо, аргументи на кшталт «Я прихильник теорії Z. У мене еволюцією було закладено близько 30-40 років активного періоду для організму. Останні n місяців я провів у Вашій компанії. Компанія чудова. Але з огляду на деякі обставини, мені здалося, що мої знання, навички і поки ще достатньо хороший душевно-психологічний стан було б більш раціонально примінити в деяких інших місцях»

Саркастично, але дякую друже :) Якщо чесно, не знаю це словосполучення буде на нашій рідній ...

Ніякого сарказму) Якщо ваша компанія оплатить таку ініціативу дослідницьку, то можуть ще й назвати ту теорію не Z, а вашим іменем) Буде сторінка в вікіпедії і про теорію імені Вас і про Вас взагалі) Є ще варіант — скинутися багатьом на таке дослідження. Проте, «британські вчені» і публікації в авторитетних джерелах не з дешевого

Среди айчаров и рекрутеров бытует мнение, что хорошие специалисты должны ходить часто на всякого рода тех-конференции, а то и выступать на них. Бывал я на таких конференциях в качестве слушателя. 80% — или малонужное и неинтересно рассказывается, или вообще шлак, или легко доступно в нете (да и записи конференций позже тоже стают доступны).

Варьируется от конференции к конференции, но в целом это еще одно проявление закона Парето, причем даже с еще более смещенными долями. 80% (или даже 90%) там может быть «шлак», но остальные 20% (или 10%) могут в будущем ну ооочень понадобится, причем даже если оно легкодоступно в нете, целенаправленно найти именно это и собрать из разрозненных кусочков цельный концепт самому будет намного сложнее, если ранее об этом уже не слышал от человека, прошедшего этот путь. И естественно то, что входит в 80% для Пети (то есть шлак) вполне может входить в 20% для Васи (то есть быть мегаполезной инфой для когото другого).
Кроме того, конференции — это не только слушание, но еще и нетворкинг, хотя и не все этим пользуются.

Кроме того, конференции — это не только слушание, но еще и нетворкинг, хотя и не все этим пользуются.

Лично я конференции посещаю исключительно ради нетворкинга. Так потом проще на +500 перейти.

Да, рыночная ценность
— совести,
— моральности,
— порядочности,
— доброты,
— честности
слишком высоки.

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

Нет. Но вот степень значимости и то, как их оценивают, меняется от компании к компании.

Я полтора года наблюдаю примерно следующий сюр:

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

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

«Soft skills не нужны», ога, да щаз.
Избавляться от тех, у кого они на высоте, особенно в связке со скоростью работы — это проявление невероятного слабоумия и отваги.

Нет, это — разумный подход к увеличению объема проекта + стабилизации коллектива (никто не выделывается)

никто не выделывается

Выделывается сообразительностью и производительностью?

стабилизации

Для стабильного полета в пике?

Выделывается сообразительностью и производительностью?

Да, разлагает коллектив. Следующие сценарии:
1) Народ начинает на него полагаться, и вообще перестает работать
2) Народ смотрит, что парень пашет, а зарплату ему не повышают
3) Наоборот, ему повышают, а другие — обижаются и валят, потому что выскочке дали денег, а мне после 5 лет работы — нет.
4) Он подгребает под себя архитектуру проекта, так как остальные слишком медленные, чтобы что-то серьезно менять. Потом ему предлагают +500, он уходит, а проект уже никто не может поддерживать, потому что чувак все переписал.

Из почитать:
www.bruceblinn.com/parable.html
neilonsoftware.com/...​/developers/the-rockstar (Danger to project: Extremely High)

Народ начинает на него полагаться, и вообще перестает работать

Фронты, на них нельзя положиться полностью, это невозможно.

выскочке

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

подгребает под себя архитектуру проекта

И архитектуру фронты тоже поменяют только там, где только их власть, а она ограничена.

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

Ну ты спросил — я ответил)
Почему ПМы и ХРы так решают — их мучай)

neilonsoftware.com/...​/developers/the-rockstar (Danger to project: Extremely High)

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

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

Все равно уйдет пару месяцев пока новый все перепишет по-своему)))

Переписывают нубы. Рокстары не страдают хернёй и если код работоспособный — пользуют то, что есть.

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

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

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

Не видел такого. Если код работает — переписывать смысла нет. А разобраться можно с любым кодом.

Более того, чтобы код переписать — нужно 1) покрыть его тестами (причём, достаточно плотно) 2) хорошо знать спецификацию к этому и смежному коду (часто, она недоступна по многим причинам).

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

Вообще если работаешь на проекте плотно года 3-4, то уже можешь переписывать что-то лезть, так как уже будет понимание во что это выльется и ради чего. А если полгодика всего — лучше не лезь.

Дык, смысла переписывать работающее нет. Рокстары продуктивны в том, что выдают таски спринта на гора и быстро двигают проект вперёд. А переписывание существующего — не даёт в этом смысле никакого профита.

П.С. Есть ещё аспект «технического долга» — но это решаемо скашиванием «острых углов» реализации, по мере добавления фич.

А когда сильно поменялись требования к модулю? Что делать, когда код в нем чужой?

А когда сильно поменялись требования к модулю? Что делать, когда код в нем чужой?

Изменять модуль — если требования совсем поменялись. Или добавлять новый модуль (если требования расширились).
Но где тут место переписыванию?

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

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

Вот когда модуль плохо документирован, и попытки понять, как он работает, непродуктивны — тогда и приходит ему переписывание.

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

Что касается самого кода — чтобы в нём разобраться, никакого описания кроме кода и спецификации рокстару не нужно.

В смысле, плохо документирован? Недоступна спецификация?

Какая спецификация? Есть АПИ и можно пытаться читать стандарт и мапить его логику на то, что там в модуле происходит между вложенными стейт-машинами с 20 глобальными переменными состояния. Или есть перловый скрипт, парсящий дампы базы данных и по дороге генерящий словоформы из hunspell. Это так, примеры из жизни.

Есть АПИ и можно пытаться читать стандарт и мапить его логику на то, что там в модуле происходит между вложенными стейт-машинами с 20 глобальными переменными состояния. Или есть перловый скрипт, парсящий дампы базы данных и по дороге генерящий словоформы из hunspell.

Оно ведь выполняет некую функцию? Это и должно быть заспецифицировано. Грубо говоря, что подаётся на вход, что ожидается на выходе.

Если такой спецификации нет — переписывать повода тоже нет, тк. будет лишь хуже.

А чтобы переписать (если сильно руки чешутся) — сперва выяснить требования => заспецифицировать => завизировать у технически-ответственного за продукт => покрыть существующую реализацию тестами => переписать.

Если такой спецификации нет — переписывать повода тоже нет, тк. будет лишь хуже.

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

А чтобы переписать (если сильно руки чешутся) — сперва выяснить требования => заспецифицировать => завизировать у технически-ответственного за продукт => покрыть существующую реализацию тестами => переписать.

А вот если это все делать — понадобится несколько человеко-лет, а человеков есть 1-2 и лет есть 0.5 на имплементацию. Собственно, по этой причине в найденная документация автогенеренная неизвестно когда и из чего, а о тестах никто не слышал.

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

Если новый стандарт, реализации которого нет — придётся реализовывать с нуля. От поддержки старого стандарта и проприетарного протокола отказываться (если так решено) или их поддержку оставлять на старой реализации.

И что тут переписывать?

От поддержки старого стандарта и проприетарного протокола отказываться (если так решено) или их поддержку оставлять на старой реализации.

Новый стандарт расширяет старый. Отказываться от поддержки нельзя.
Переписывать — собственно кусок SDK, обслуживающий звонки (прослойка между радиодровами и MMI).

Стандарт — это спецификация. Соответственно, покрыть реализацию старого стандартa тестами и расширить для поддержки нового стандарта.

Опять-таки, нет повода что-либо полностью переписывать.

Соответственно, покрыть реализацию старого стандартa тестами и расширить для поддержки нового стандарта.

Покрыть стандарт тестами == уступить рынок конкурентам, которые за это время выпустят продукт.
Если старый модуль весь работает на глобальном состоянии звонка-синглтона, а в новом стандарте нужно поддержать несколько звонков (объектов) с разными достаточно независимыми состояниями — как его расширять?

Вот еще вброс по тому, что предстоит сделать:
Есть SDK на С, который управляет платой с двумя портами, подключенной к USB. Его поюзали, чтобы с этой платой общаться. И тут надо поддерживать несколько таких плат в одном приложении. Упс. А в SDK про несколько плат никогда не слышали. Код себе пишет в регистр платы (подразумевая, что она одна). Можно, конечно, перед вызовом любой функции из SDK подставлять глобальный указатель на объект, перенаправляющий команды на правильную USB, но тогда теряем параллелизм, и код начинает пахнуть камасутрой. И его будет очень понятно читать следующему чуваку, пришедшему на проект.

Покрыть стандарт тестами == уступить рынок конкурентам, которые за это время выпустят продукт.

Да, знакомы мне firmware-клепальщики, работающие без тестов.
Всё заканчивается тем, что «софтовики» реализуют нужные фичи виндо-продукта — а «аппаратчикам» нужно ещё 3 месяца, чтобы закончить свои реализации. Потом ещё 3 месяца... итп.

А всё потому, что их там несколько, и после каждого контрибьюта — что-то другое отваливается. Зато без тестов.

Если честно — железо непредсказуемое. То есть, баг в железе можно пару месяцев ловить, и еще пол-столько чинить. И он будет от таймингов зависеть: есть лог — нет бага, нет лога — есть баг) За это стараюсь работу с железом спихнуть на соседа)

Вот когда модуль плохо документирован, и попытки понять, как он работает, непродуктивны — тогда и приходит ему переписывание

Так если не понимаешь как он работает как его можно так переписать, чтобы быть уверенным что он все ещё работает, и после переписывания не вернулись старые баги, какие-то кривые места ради которых добавили непонятные костыли, и не появились новые баги уже от тебя?

А так, что если понятно, что модуль должен делать (а не как он это делает сейчас), и есть АПИ — то его можно написать. Разве это не очевидно?

А если бинокль зламався?

Не видел такого. Если код работает — переписывать смысла нет.

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

Начинай учить Кобол прямо сейчас — сможешь в кабинет СЕО дверь с ноги открывать.

Проблема украинских кодерков в том, что они сильно переоценивают свое место во вселенной.

Так и есть — куча банков до сих пор не переписывают код на Коболе.

Да, я самолично разгребал кобольный код на зоре проф-карьеры. Правда, не для амеро-банка, а для амеро-авиакомпании. Правда, они уже планировали его переписать на «плюсах» (это был конец 90-х).

Но одно дело переписывать старый код на новых технологиях (сейчас, к примеру, повсеместно популярно переписывать «плюсовые» системы на .NET/C#) - это ещё имеет смысл.
Но переписывать на том же самом просто потому, что существующий код непонятен? Это не комильфо.

Но переписывать на том же самом просто потому, что существующий код непонятен? Это не комильфо.

Вот когда пару раз у тебя уйдет по неделе на один фикс или фичу в таком коде — оценишь)

уйдет по неделе на один фикс или фичу в таком коде

У «рокстаров» так не бывает. :)

Это потому что ты сложных проектов не видел :-)

Это потому что ты сложных проектов не видел :-)

Скорее потому, что ты никогда не видел «рокстаров».

нужно взять на его место другого «рокстара»

Ну да, в каждую контору стоит очередь рокстаров, выбирай любого.

Другое дело, что бывают жадные заказчики

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

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

У «рокстара» не может быть заказчиков? Или, может, ты считаешь «рокстарами» старых пердунов, сидящих десятилетиями на одном и том же проекте, за миску жиденькой корпоратвиной юшки?

П.С. «Рокстара», кстати, не так уж сложно заполучить — поскольку они недолго задерживаются на одном проекте (бюджеты ведь не резиновые, даже у банков). Но платить им нужно хорошо, да.

У «рокстара» не может быть заказчиков?

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

миску жиденькой корпоратвиной юшки

Открою тебе небольшой секрет: действительно серьезные деньги никогда не зарабатываются на ставке — даже у Тима Кука ставка составляет жалкие по его меркам три лимона в год. Но поскольку корпоративная юшка в виде бонусов и акций контракторам не доступна, им приходится утешать себя тем, что 150 в час — это реально крутые деньги по сравнению с каким нибудь Ебамом.

бюджеты ведь не резиновые, даже у банков

Я конечно понимаю, что с контракторской колокольни банки — это самая денежная работа для кодерка, но со стороны это смотрится реально смешно.

Во-первых, может только если рокстара интересует кровавый энтерпрайз и не интересуют серьезные деньги

В европпках самые серьёзные деньги в коденье получают именно контракторы. Скажем, потолок штатного синьора 100к/год, в гуглах/амазонах в Мюнхене может 130к, в швейцарском гугле может и 150к (но это абсолютный потолок и таких позиций десяток на всю европпку).

А хочешь зарабатывать больше — придётся контракторствовать. Либо валить в Штаты.

Ага, на улице прям очередь из них стоит :)

Ага, на улице прям очередь из них стоит :)

«Рокстаров»-то? Дашь 150/час в европпках (и 300/час в Штатах) — посбегают к тебе даже с текущих проектов, при первой же возможности.

И набегут такие как ты вместо рокстаров :)
А если серьезно, то у тебя классический случай шизофрении, определение предметов по косвенным признакам. Рокстар не зарплатой выделяется из общей, зп — это лишь косвенное следствие. К тому же можно получать в среднем больше денег и не быть рокстаром (как ты), или быть рокстаром, но «работать» там где мало платят, зато полная свобода решении

Воу-воу, палехче, чего это топик про умение, в том числе, общаться, превращается в перепалку на тему у кого чего длиннее?

Это от предновогоднего мандража?
Я, вот, книжку себе учебную прикупил и нервничал, что не успею >1k страниц за 11 дней уделать, но в мои планы вторглись, что я, в принципе, предвидел. Не моголо все идти гладко, потому что никогда не идет.
И по обоим случаям, что из-за наполеоновских планов, что из-за их отмены, я ж не стал слетать с катушек. Хотя книгу джва года ждал, мать их.

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

который постоянно гонит на Украину и ее жителей

Украинчеги, конечно, мыслители. Да. Достойны лишь похвал. :)

«Для компиляции многоядерность/многопроцессорность не особо полезна.» © 2019 Мокий Парменыч

:)

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

А примеры самокритики в масштабах стран и у Дилана Морана можно найти, и у всяких других известных личностей, которых даже упоминать — моветон.
И туда же фильмы про «тупых американцев», снятые ими же. И фильмы про «тупых англичан».

А если серьезно

Я написал челу, как завлечь на проект «рокстара». А ты вывалил свои фрустрации по поводу того — что считаешь себя «.NET Architect»-ом, а работать приходится за киндергельд.

П.С. А какой смысл «рокстару» работать там, где мало платят? Это такая форма дауншифтинга?

Я написал челу, как завлечь на проект «рокстара».

это не работает, деньги привлекают всех

А ты вывалил свои фрустрации по поводу того — что считаешь себя «.NET Architect»-ом, а работать приходится за киндергельд.

при чем тут вообще я не уловил, как и то кем я себя считаю, да и я давным давно не работаю архитектором

П.С. А какой смысл «рокстару» работать там, где мало платят? Это такая форма дауншифтинга?

приоритеты в жизни, а способности врожденные => кто-то может стремиться к известности например, деньги тоже будут, но не причина для того чтобы ради них париться

это не работает, деньги привлекают всех

Работает. Отобрать «рокстаров» из всех — проблем не составляет.

Если ты сможешь завести проект с рейсом 300 в час, то зачем тебе программировать за деньги? :)

концовка унылая, ну вот например, я типа the rock mover, так вот, часть моей философии — что незаменимых нет с одной стороны, и если все делаешь хорошо , так и код и дока должны быть на 5+ (ну или 12+ в зависимости от шкалы)
тут скорее текст был про священных коров, это немного другое

Спасибо за ссылку на Neil on software!

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

опасность the rockstar в том, что он очень сильно ускоряет разработку и может решать проблемы, которые никто, кроме него решить не может.

Умение решить проблему, которую никто кроме него на проекте рeшить не может — это да, очень большая опасность.

Опасность в том, что он становится незаменим.

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

Не совсем понял.

Есть чувак на проекте, с ним релизится десять фич за неделю. Без него будет релизиться пять.

Он уходит.

Что произойдет с проектом? — Он закроется. Потому что замену ему не найдут — а она нужна быстро, найдут, например, двух недосиньоров, тем самым начнут релизить по семь фич в неделю, а итоговый бюджет — увеличится на 40%

незаменимы только говнокодеры, ... а остальные все заменимы

В рамках одного проекта с ограниченными сроками и ограниченным бюджетом — некоторые именно незаменимы.

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

Естественно, а где кто говорил, что это проблема «чувака, выкатывающего фичи»?

Это потенциальная проблема для компании, в которой работает The Rockstar (если они будут оценивать общую скорость разработки и экспертизу команды по среднему, и не подготовят ему замену).

Так зачастую получается на практике

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

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

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

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

Сам факт того что какой-то один чел перформит раз в 10 больше други уже стоит задумать и присмотреться что там такого происходит в команде или с наймом в эту команду.

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

А ты никогда не сталкивался с людьми, которые делают в несколько раз больше, чем другие? (ну не в десять раз, конечно, в два-три раза)

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

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

так там и рокстар не надо вон выше пишут синьора на мороз всё конец проекта ))

Решил ответить на заданные оригинальные вопросы:

1. Слыхали ли вы о кейсах клейминга конторами бывших неугодных сотрудников по части софт скилзов?

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

2. Не считаете ли Вы, что большие компании имея всякие там внутрении тренинг-центры и каких-то там коучей по софт скилзам и подобному им (бывает таким мастерам самим надо коучи), необосновано возвышают свои возможности по определению уровня таких скилзов у сотрудников, завышают свои возможности по их корpектировке и вообще замного на себя берут?

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

3. Не считаете ли Вы, что подобное определение уровня такого рода скилзов, это не что иное как скрытый инструмент влияния и манипулировани (а то и расправы с неугодными бывшими сотрудниками) в такого рода компаниях?

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

4. Бывал я на таких конференциях в качестве слушателя. 80% — или малонужное и неинтересно рассказывается, или вообще шлак, или легко доступно в нете (да и записи конференций позже тоже стают доступны). Не кажется ли Вам, что важность походов на всякого рода конференции часто гипертрофирована?

Нет, не считаю. Опять-таки, курсы английского бывают разные — вы же не записываетесь на первые попавшиеся, и ходите только ради того, что ходить. И на концерты вы не ходите, чтобы просто пойти на концерт — а там пофиг кто играет и что за музыка.
Так и с конференциями — нужно ходить на те, у которых хорошая репутация, где релевантный для твоих интересов контент, и спикеры — заслуженные профессионалы.
Конференции не предназначены для получения практических навыков — они для расширения своего угла зрения, посмотреть-послушать чем живут в других проектах, компаниях. Что у всех на слуху или в фокусе. В конце-концов завести новые знакомства или вообще найти новую работу. А записи в интернете все равно никто не смотрит потом :)

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

А может стоит прочитать само сообщение?

Нет, мне просто хотелось обдумать и озвучить свои мысли на поднятые вопросы. Адресатом ответов может быть кто угодно, кто находит для себя вопросы релевантными. Для этого и существуют форумы :)

В любом случае спасибо :)

Смешно читать про обыденные вещи на каком-то тьмутараканском языке. Так вы за деревьями леса не увидите.

Так и не читайте если не нравится

Топікстартере, Вам можливо здасться дивним але є люди, які вважають, що інші люди які заперечують цінність софт-скілз тренінгів і коучів повинні йти до дупи)
www.facebook.com/...​4779660111&type=3&theater

софт скиллы явно на высоте

Йому видніше він пройшов дуже крутий тренінг і взагалі випускник Lviv Business School. Куди Вам до нього)
p.s.
А взагалі, то це прикро що соціальний ліфт в ІТ зараз працює занадто неперебірливо переміщуючи доверху досить швидко всяке село і бидлоту. Також залишається питання і чому ті хто вчить таким так званим «soft skills» допускають такі публікації своїх студентів зі згадуванням їх курсів

1. Слыхали ли вы о кейсах клейминга конторами бывших неугодных сотрудников по части софт скилзов?

У меня был коллега, который одному опосредованному менеджеру из Индии написал, что он не ресурс, а человек после того, как тот писал о чем то другим манагерам и добавил его в СС. В письме было написано что-то вроде «...наши ресурсы из СС». Менеджер тогда нажаловался уже его непосредственным начальникам, мол, тот товарищ должен прокачать софт-скиллы.

Не считаете ли Вы, что подобное определение уровня такого рода скилзов, это не что иное как скрытый инструмент влияния и манипулировани (а то и расправы с неугодными бывшими сотрудниками) в такого рода компаниях?

Даже не с бывшими — с текущими (на тот момент). Видел пару раз такое плюс доносились разные слухи. Это процветало в основном там, где имело место быть кумовство и/или самодурство начальства.

Не кажется ли Вам, что важность походов на всякого рода конференции часто гипертрофирована?

А вот конференции нужны. Даже не столько ради докладов, сколько ради заведения связей. Да, внезапно это софт-скиллы. С помощью связей проще будет на +500 перейти, распрощавшись при этом с охуевшим насяйника.

Не кажется.

А всякие коучи и т.д. не нужны, необходимые софт скиллы развиваются по мере необходимости с опытом.

Я думаю, що як мінімум один хлопчина підданий пропаганді таких курсів з Вами був би не згоден. Можливо також, що ви відноситеся до категорії людей яких він послав до дупи після чергового такого надихаючого тренінгу
www.facebook.com/...​4779660111&type=3&theater

Я теж можу послати.

А так, я висловив свою особисту думку, сформовану моїм власним досвідом роботи у різних компаніях та спілкуванням з іншими девелоперами.
Якщо для когось це привід мене посилати до дупи — це всього лише ознака відсутності тих самих софт скілів у цієї людини ;)

Ему дали сертификат после окончания тех курсов по «софт скилзам». Теперь он сертифицированый чел с хорошим уровнем «софт скилзом». Хрен подкопаешься. Да и вообще Lviv Business School чел оканчивает. Туда не каждого берут)) Так что не гоните на него)

Ой, извините, не признал, каюсь. Раз у него есть сертификат, все мои претензии снимаются, чел крутой. А я, пожалуй, пойду «до дупи» — где мне, черни без сертификата, и место :’(

где купить сертификат по софт-скиллзам, с регистрацией в базе, недорого

Не кажется. Софт-скиллы это ж не абстрактная хрень. Это вполне конкретные навыки.
— нормально общаться (и это не о пресловутом смолл-толке)
— правильно реагировать на конструктивную критику
— быть открытым к другим мнениям и решениям
— понимать потребности окружающих (в том числе ХР, лидов, менеджеров)
— правильно вести себя в конфликтных ситуациях (отстаивать свое мнение, но не портя отношений, и знать когда стоит сдаться)
и т.д.
т.е. все, что нужно для того, чтобы работать в рамках проекта на более, чем 1 человека

То есть, лиды не должны уметь работать с сотрудниками, у которых все или некоторые из этих качеств не соответствуют политике компании?
А нафига тогда лиды?

А лидов нет, все по аджайлу работают )))

Эджайл это не только Скрам ;-) Если Скрам вообще эджайл.

www.youtube.com/watch?v=A7×5BU7oFY8

Поистине, сон не есть не сон, а не сон не есть сон, итак, не про сон сказать, что это сон — всё равно, что про сон сказать, что это не сон. Говоря коротко, про не сон — сон или сон — про не сон

Ты с первой частью не согласен или со второй?

Наверное, если отсутствуют все, то не должны. Они ж все-таки лиды в IT, а не санитары в психушке. Чем больше отсутствующих или плохо развитых, тем эта работа более затратная, нервная и неэффективная. Мне кажется, вы путаете лида с психологом.

Мне кажется, сумма скиллов более-менее постоянна — человек во что-то вкладывается, а на что-то забивает.
Если при приеме на работу требовать от программистов софтскиллов — они будут хуже среднего программировать.
Если при приеме на работу от программиста требовать хорошо программировать — у него будут софт скиллы хуже среднего.
Если требовать и то и другое — никогда не застаффишься, либо быстро будут переходить на +50% к конкурентам, потому что им такие тоже нужны, и софтскиллы позволяют.

т.е. по-вашему развитие человека не возможно в принципе? Возможна только перекачка скиллов из одного места в другое? Типа пошел в зал, сразу IQ просел. Засел за учебу, сразу стал неадекватом? Товарищ Платон с вами бы не согласился.
Не так. Время на развитие у человека ограничено, это да. Но у развития есть гистерезис. Если ты когда-то что-то прокачал, то даже если не поддерживать эти скиллы, все равно они не уйдут в ноль. Что-то останется. И если захочешь восстановить, сделаешь это быстрее.
Так что неправда ваша. Можно и нужно развиваться в нескольких направлениях.

Ресурсы человека ограничены. Тот кто везде — тот нигде. Поэтому многие решают качать несколько своих основных скилов и за счет их конкурировать, и под них искать работу.

Ресурсы человека ограничены. Тот кто везде — тот нигде.

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

Платон-не Платон, но поговорка Jack of all trades — master of nothing не на пустом месте возникла. А значит, развитие — это почти всегда tradeoff.

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

А почему бы девелоперу не помыть полы в офисе и не начистить лиду ботинки? Ему же зарплату платят :-D

А почему сразу не отсосать?

Каждый уважающий себя программист в Австралии должен уметь отсосать яд змеи у укушенного товарища.

На ДОУ с утюга зашел? История и иерархия сообщений не видна?
Не проблема, разжевываю. Лиду платят зарплату для того, чтобы руководить командой, а не за то, чтобы быть производить реабилитацию и интеграцию в общество людей с незрелой или поломанной психикой. Поэтому если мы заставляем лида брать на себя эти обязанности мотивируя тем, что ему деньги платят, то логичным продолжением этой мысли будет также поручать непрофильную работу и другим членам команды. Например — девелоперу помыть полы. Ему же тоже деньги платят.

Сарказм, понимаешь. Понимать когда люди серьезно, а когда — нет, это тоже софт-скилл.

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

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

Дедушка, покажи где черпаку устав почитать

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

Софтскиллы поперли)

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

И в чем же заключается «руководство командой»?

Если в контракте в обязанностях работника записано «и выполнять другие требования начальства, не противоречащие законодательству», то помыть полы в офисе и начистить лиду ботинки вполне себе подпадает под это.

лидам платят обычно только «на вырост» по крайней мере в Родине 146% так

Перевожу с корпоративного на человеческий

правильно реагировать на конструктивную критику

Позиция «ты начальник, я дурак» редко когда бывает проигрышной

быть открытым к другим мнениям и решениям

А свое затолкать поглубже к себе в жопу

понимать потребности окружающих (в том числе ХР, лидов, менеджеров)

Ну то есть — не искать, где теплее, с энтузиазмом воспринимать всякую дичь нововведения и не заикаться о повышении

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

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

Вообще-то правильные советы. Нелояльные сотрудники обычно первые в очереди на сокращении.

Посттравматический синдром от постоянного общения с менеджером-мудаком? Сочувствую. Меняй работу. Но мне теперь придется обратно переводить с социопатического на человеческий.

правильно реагировать на конструктивную критику

Конструктивная критика бывает не только от менеджера. И даже в большинстве своем — не от менеджера. Имеется в виду — не агриться на QA, который нашел багу в твоей фиче. Не агриться на коллегу, который нашел проблему во время код-ревью.

быть открытым к другим мнениям и решениям
А свое затолкать поглубже к себе в жопу

Ну это только если это приносит удовольствие. Имелось в виду регулярно снимать корону и понимать, что предложенное тобой решение тоже может иметь недостатки. И, возможно, вот-тот неоперившийся миддл дело говорит и стоит его выслушать. А если он неправ, не смешать его с гавном, а объяснить в чем его решение проигрывает.

понимать потребности окружающих (в том числе ХР, лидов, менеджеров)
Ну то есть — не искать, где теплее, с энтузиазмом воспринимать всякую дичь нововведения и не заикаться о повышении

Это значит, к примеру, понимать, что работа девелопера не состоит на 100% из кодинга. Нужно еще обсуждать решения, делать ревью кода, комментировать код, покрывать его нормальными тестами, интервьюировать кандидатов, коачить интернов, объяснять коллегам как все-таки работает твой говнокод.. И, да, иногда делать вещи, вообще не связанные с кодингом — пройти какой-нибудь ХР-ский тренинг по софт-скиллам.

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

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

пройти какой-нибудь ХР-ский тренинг по софт-скиллам.

Тут я просто блеванул... Как человек потративший недавно 3 часа (а по факту и остаток дня) на бесполезный но обязательный трейнинг типа по софт-скилам и корпоративным ценностям...

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

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

Перевожу с корпоративного на человеческий

Вот тут аж слезу выбило... Тут все так.

Правда-матка.
Якщо ще ніхто не видав чи опублікував неформальний статут працівника ІТ-компаній, то це треба помістити на першій сторінці такого статуту в майбутньому

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

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

Жил был один менеджер по продажам. Пошёл устраиваться на работу. Долго ли коротко ли резюме рассылал, а как-то пришёл в одну контору на собеседование с генеральным директором. И шло у них собеседование шесть часов. Уже и директор взмок, и менеджер три раза воды просил. А всё никак не могут договориться.

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

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

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

из-за проблем с коммуникацией

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

«Дело было не в бабине..
Долбо*б сидел а кабине»
Просто из-за того, что не принято показывать пальцем на виновного, говорят «проблемы в коммуникации» :-)
Если говорить более откровенно, то проекты валятся из-за менеджеров-идиотов (или преследующих иные цели)

Если виновного тяжело найти, то его обычно назначают. И это точно не менеджер.

Не всегда. Если проект достаточно большой, то виноватым назначат как раз кого-то из менеджеров. Обычно самого низшего звена. Но не обязательно. Оно ж, даже, совсем неубедительно, в проекте на 100 человек, обвинить во всем одного разработчика. Банально никто не поверит.

Ну значит десятерых назначат. Я говорил больше про малые проекты, не больше 15 человек в команде. А софтскильный менеджер всегда отбрехается — скажет, вот, программист накосячил.

А софтскильный менеджер всегда отбрехается — скажет, вот, программист накосячил.

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

интересно, а как это работает? ведь по логике толпа должна наброситься на сознавшегося: «ах, это из-за тебя проект завалился/я денег недополучил?»

Или из-за смены ситуации на рынке (от кризиса 2008 до появления конкурентов, которые успели первыми)

Не все, но бывает либо кризис, либо неполнота знаний о том, кто быстрее тебя прибежит к кормушке.

Аутсорс модель предполагает наличие разных способов предотвратить протухание команды. Потому что 80% работы «обезьянок» можно выполнить средствами клиентов. Но им интересно гонять деньги туда-сюда.
Вот поэтому придумывают разные утренники и политинформацию.
Как только Вы окажетесь в какой-то продуктовой европейской/американской/etc компании, с Вас будут собирать совсем другие метрики, нежели число душевных разговоров в неделю. Да и «Олимп» окажется чуть-чуть пониже. Где-то на уровне инженера-конструктора или оператора ЧПУ.

Не кажется ли Вам, что роль soft skills исскуственно завышена

Нет, не кажется.

Также слышал некоторые сторис про якобы клейминг...

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

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

При чем здесь софт-скиллы вааще !?
Мое ИМХО, хорошая практика такова, что вернувшись с конференции, деву неплохо бы рассказать коллегам чего интересного он там услышал.

...не что иное как скрытый инструмент влияния и манипулировани (а то и расправы...)

Для «расправы» надо софт-скиллы за уши притягивать!?

как такие деятели рассказывают технарям (не зная ньюансов их сферы деательности) как жить (коммуницировать правильно...)

ИМХО саме тут собака порылась :( Но у Вас действительно не самый удобный язык и стиль :) , с обилием клеймингов и респонсибилитис :)) Какими бы недоразвитыми Вам не казались «всякого рода гуманитарии», как бы высоко Вы не ставили технарей на лестнице эволюции, те и другие — вопщем-то люди, общаться им надо по-человечески, а не на Перле :), а человеческие языки кстате почему-то отнесены к гуманитарным наукам :)

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

Говорит ли странный абстрактный ник на ДОУ о проблеме с софт-скиллами?

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

А тебе-то что? Тебя Дима зовут, это понятно. А вот топикпастер — какой-то ittruthsearcher. Это с софт-скиллами что-то не то?

або просто хитрого & лінивого

Ей ей.. Не паліть систему. Вони потім будуть керувати технарями на різних супер-менеджерських посадах зарахунок самоствердження в царині soft skills істино вірячи, що їх екзистенціальне покликання в цьому житті — це боротьба з усілякими проявами ентропії серед технарів і інших простих трудяг на яких можна їздити подаючи їм потрібну інформацію під різними соусами

Я же говорю, программисты вы же умные ребята, есть usb keylogger, они позволят вам просматривать почтовую и instant messaging переписку хрюш с прожект менеджерами, про аудио жучки из raspebrry zero под столом уже писал. Что еще, если есть физический доступ к телефону хрюши можно установить spy app который позволит мониторить хрюш и их гадкие планы по вашему уничтожению. Опять же, в мирное время программист тихо сидит и работает но когда хрюши и социопаты прожект менеджеры объявляют негласную войну на уничтожение ботаников, то нужно принимать активные мероприятия для защиты карьеры и дальнейшего пропитания программиста.

дальнейшего пропитания программиста.

— жирно :D

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

Проболтался на корпоративе?

ТС, да можно называть как угодно: софт скилы, личностные качества, неспециализированные надпрофессиональные навыки — люди хотят работать с другими приятными им людьми.
Так всегда было, и будет при взаимодействии человек-человек.
И в этом желании им невозможно отказать, оно естественно :)
Кто же захочет обратного?

Так оно и есть, чтобы лучше понять психологию хрюш и проджект менеджеров нужно услышать какие гадости они говорят когда обсуждают программистов. Deep dark web и тамошние хакеры предлагают следующее решение. Поставить в офисе жучки, которые будут прослушивать разговоры хрюш с прожект менеджерами. Например как жвачку налепить под столом хрюши. Можно использовать Bluetooth или WiFi raspberry zero. Важно записывать на носитель который будет спрятан в нескольких метрах от самого жучка.

Все хотят приятных и компетентных коллег. Но между неприятным-компитентным и приятным-некомпетентным я выберу первого.

Извините, я на другой коммент отвечал.

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

Не кажется ли Вам, что роль soft skills искусственно завышена и гипертрофирована, а право клеймить негативными отметками неугодных узурпировано большими IT-компаниями как искусстный инструмент?

Нет, не кажется.

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

Ну бывают случаи, когда общаться и что то доказывать не имеет смысла. По причине того что тебя не понимают. Это как объяснять устройство атомного реактора индейцу (который искренне верит, что его копье, украшенное синтаксическим сахаром это дар богов). Понадобятся десятки лет обучения и не факт что будет какой-то результат :)

За то что просрал ответственный матч чемпионата в настольный хоккей и команда оказалась на втором месте?

Ну, не всем дано бухать на рабочем месте, некоторым ещё и работать надо

Начальник заходит в слесарку в 16.30. Смотрит, а слесарь станок обмахивает.
Н: Уважаемый, а почему вы не работаете? Ведь есть еще пол-часа.
С: Ну, пока станок обмахну, верстак уберу, инструмент по местам поставлю, руки помою, переоденусь. Как раз и будет пять часов.
Н: А вот я ровно в пять часов домой начинаю собираться!
С: А хули тебе собираться, еbало закрыл и пошел.

вот за насяльника щас абыдна была ((

который сидит и делает свою работу, но не проявляет энтузиазма в племенных танцах?

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

Є варіант, що він ТОБІ не може цього пояснити, бо він знає, що треба робити, а ти вимагаєш магії — при тому що сам не навчився навіть в унітаз водограєм поцілити

він ТОБІ не може цього пояснити

Це все одно проблема інженера.

Була в мене році десь у 2000-му чи 2001-му одна історія, коли в суботу двоє мудаків — один наш замовник, другий наш програміст — приперлися на роботу, знайшли один одного в месенджері, і дохоліварилися на тему «мйутекс чи критична секція» до того, що замовник вимагав звільнити програміста.

Я, звичайно, душевні рани зализав, двох цапків розвів в комунікації, і після того вони жили дового і щасливо. Та й досі живуть.

і дохоліварилися на тему «мйутекс чи критична секція» до того, що замовник вимагав звільнити програміста.

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

линуксоед штоле?

Насправді ні, хоча система працювала тоді під Windows, Solaris, AIX та Linux.

Суть не в тому — в суперечці між двома мудаками операція відбувалася тільки тоді, коли адміністратор міняв щось в переліку юзерів системи. Але їм важливо було, що швидше.

если бы софт скиллов не существовало, их стоило бы придумать © noname манагер

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

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

И чтобы держать на работе полных бездарей, особенно в первом лице

Понятие «софт-скилл» — это такая попытка корпоративного мира оценить и измерить то, являешься ли ты норм чуваком. Корпоративщина очень любит всё измерять и документировать, и если есть какой-то фактор, с которым она не может этого сделать — ей некомфортно. Поэтому и было придумано искусственное псевдо-понятие «soft skills» — ещё одна колонка в Excel. Однако, если ты просто обычный и адекватный человек, на тебя наверняка не навесят лычку «low soft skills» и не обрежут повышение зарплаты и не уволят. Тут можно не переживать.
Если же вы работаете в месте, где культ «софт-скиллов» активно форсится и этому уделяется чрезмерное внимание, и это реально влияет на карьерный рост и рост дохода даже обычных адекватных людей — валите из этой говноконторы побыстрее, скорее всего там все е*анулись.

Без надлежащего контекста данные вопросы не имеют смысла.

Если по-простому: чем больше твоя команда, отдел и компания в целом (иначе говоря, твой граф отношений), тем важнее роль софт скиллов в твоей работе.

Отсюда:

нашей маленькой тиме реально смешно

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

Приведу пару примеров более близких для инженеров:
1) Вас в команде 3 человека и вы педалите, скажем, какое-то приложение. Ты хочешь использовать библиотеку А, а коллега — библиотеку B. Вы обсуждаете их плюсы и минусы стоя у кулера с водой и за 10 минут сходитесь на варианте A. Третьему коллеге вообще пофигу. Успех!
2) Вас в команде 50 человек. Из них у половины — 10+ лет опыта в лидерах рынка. Ты захотел использовать библиотеку А. Теперь тебе нужно провести анализ всех альтернативных вариантов; составить сравнительные графики производительности; написать демо; провести презентацию; переубедить всех оппонентов. Половина здесь — софт скиллы. Не умеешь так? Гипертрофированные требования? Значит будешь использовать то, что скажут люди порасторопнее и тихо плакаться в приватных чатиках, пока не уволишься.

Тот же принцип будет работать и в других ситуациях. Чья идея будет взята в работу? Кто поедет на конференцию? Чья команда получит бонусы и повышения? И так далее.

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

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

Вас в команде 50 человек.

Иерархическая структура не катит?
Кто-то в состоянии управлять командой из 50 человек?

Иерархическая структура не катит?

Здесь я подразумевал структуру, когда над одной код базой, скажем Android клиентом, работает сразу 50 человек. Их обычно разбивают на функциональные кросс-платформенные команды по 5-10 человек. На станд-апы ты ходишь с своей маленькой командой, но вопросы архитектуры приложения, графа зависимостей и прочие platform-wide вещи обсуждаешь с этими 50-ю.
Такая структура невероятно распространена. Facebook, Spotify, AirBnB, you name it.

Кто-то в состоянии управлять командой из 50 человек?

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

Ща у спотифая копируют идеи гильдий и чаптеров, чтобы не

обсуждаешь с этими 50-ю.

а чуть поменьше

Ща у спотифая копируют идеи гильдий и чаптеров, чтобы не
обсуждаешь с этими 50-ю.
а чуть поменьше

Fair enough. Но и scope обсуждаемых вопросов тоже сужается. Порешать внутри чаптера какую зависимость затащить, или какую структуру проекта использовать все равно не дадут — всё, что торчит наружу модуля будет эскалироваться на уровень всё тех же 50-и.

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

на уровне 50 проще либо диктатура, либо референдум

Мне кажется ты воспринимаешь «обсуждение на уровне 50-ти человек» как буквальный разговор 50-ти человек, каждого со своим мнением. В реальности, обмен мнением будет происходить между 3-5 людьми с периодическими вопросами «из зала». Но эти вопросы могут развернуть дискуссию на 180 градусов: «а вы уверены, что библиотека А совместима с Бубунту 123?».

Даже если кто-то решит топнуть ногой и сказать «будет вот так!» — возможность высказаться и опротестовать есть у всех.

В реальности, обмен мнением будет происходить между 3-5 людьми с периодическими вопросами «из зала». Но эти вопросы могут развернуть дискуссию на 180 градусов: «а вы уверены, что библиотека А совместима с Бубунту 123?».

В моем опыте подобные обсуждения всё-таки не вносятся на 50 человек. Но вполне вероятна ситуация когда одна команда попробовала что-то новое, осталась довольна результатом, и вот пришло время показать и рассказать другим командам. И вот тут в первую очередь от софт скилов зависит пойдёт ли эта инновация дальше или все будет похерено и останется как прежде. А главное — как будет оценена твоя работа. Потому что оценка она тоже субъективная и сильно зависит от общего впечатления, в том числе от презентации.

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

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

решается, но надо быть очень упорным

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

Да нормально всё обсуждается в режиме open mic на регулярном созвоне или через issue с RFC прямо в репозитории.
Понятно, что активное участие в обсуждение будет принимать всего несколько человек, но высказаться или задать вопросы может каждый. Или банально палец вверх/вниз поставить.

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

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

Угу.. и бонус идет твоему тех и этих руководителю, как тому кто драйвил это направление.

Может, в эльфиях эти магические бонусы и существуют

На повышение или на +500 без смены работы пойдет твой руководитель.
Как, вы и мороженное с пироженным тоже за меня есть будете ©

Здесь когда надоедает — идешь на +(30-50)% со сменой позиции.
+500 — это для джунов.
Поэтому нет смысла подсиживать руководителя, оставь эту работу его начальству.
Ну и, кагбэ, если на них без смены работы ходит научрук — то зачем тебе такая бессменная работа.

Здесь когда надоедает — идешь на +(30-50)% со сменой позиции

Не более пары раз подряд, пока не упрешься в стеклянный потолок.

Да, а потом +500 уже можно отдать начальнику)

То есть, нет людей, которые могут провести анализ импакта на код, который делает команда? Нужно каждого разработчика проекта садить слушать все презентации?

Нет, с таблицами вообще напрямую не работал, только с дампами.
С 10М строк кода в одном бинаре работал.

Это — большой старый проект (Хромиум).
Обычно все не настолько запущено.

Считать ли хромиум одним большим проектом, или большой кучей маленьких, не связанных с друг другом? :) Там же половина кода, если не больше, это всякие bundled опенсорс-библиотеки

Там 2 больших куска: блинк (отрисовка текста и картинок в графический контекст) и собственно хромиум (загрузка и парсинг ХТМЛ, рендеринг графического контекста на экран, энкапсуляция страниц в отдельные процессы). J8 еще есть — движок жабоскрипта. Опенсорса другого не помню.

я работал в подобном проекту, только было около 200 человек — это была куча команд по 5-10 человек

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

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

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

Ршкогай надоел, сириусли.
Вот тебе шутеечка чтобы веслее было — «Ты б с ним взял да попцански все перетер и рассказал бы че да как, выпили бы вотки с селедкой и все было бы ок, он бы уважал тебя, чисто по человечески и был как брат для тебя, но у тебя нету софт скилов и ты просто жалуешься на форуме» :-)

Твой комментарий переполнен обидой на несправедливую реальность. Она и правда зачастую несправедлива. Се ля ви.

Там нет обиды, просто факты — программирование да, политика нет, а вот у тебя все такое же ограниченный взгляд на мир ;-)

А що таке «справедливість»? У кожного вона своя. Що для одного погано, для іншого — добре. Чим нижче ти опускаєшся по рівнях абстракції будови нашого світу, тим краще розумієш, чому ті чи інші речі трапляються. В тому числі і спричинені «непередбачуваним» людським фактором.
Так що я категорично не згоден з твердженням, що життя несправедливе.

Так що я категорично не згоден з твердженням, що життя несправедливе

То есть вы утверждаете что жизнь справедлива?

А що таке «справедливість»?

Ты так и не осилил дальше черно-белого взгляда. Увы, убогость не лечится, но не смертельна.

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

справедливо — это когда сильный побеждает слабого, а не наоборот. справедливо — это когда все имеют равные условия — (и таковы имеют, только многие просирают свои и их берут другие — и это справедливо)

Ну расскажи про равные условия у слепого, безногого и тупого.

у них равны со всеми остальными условия по умолчанию, если им начинаешь помогать — то получаются неравные. то что кто-то не может видеть или слышать — почему-то так случилось как правило, даже если врожденно (вопросы к родителям)

просто надо отбросить весь социализм в головах которым подменяют справедливость.

почему-то так случилось

Тогда уже говори про «неравные условия» так как умолчание не происходит, и стартер паки разные

Так про условия. Это стартер пак, он один для всех и для мага, и для хилера, и для ассасина, и для танка...и

слепого, безногого и тупого.

Аналогично можно говорить, что у всех программистов в украине зарплаты одинаковые и равны средней по индустрии

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

а чем люди с лучшими условиями виноваты перед остальными

А кто сказал, что они виноваты? я лишь утверждал что равных условий не бывает, потому что они отличаются с самого рождения. Но человек хочет верить — пусть верит :)

Я не хочу тратить силы на политику, и корпоративный булщит, я хочу программировать

Понятное желание.

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

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

Заниматься болотологией и политикой нафиг всралось, я инженер, а не говорящая голова.

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

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

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

Логика общению не мешает, я не вижу противоречий, либо я не понял тебя.

Хм.. а вот тут выше кто-то пишет

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

Нет, это просто твоя эмоциональная окраска.

Это здесь причем? Я нормально спросил, как должен мотивировать программмист и зачем это в роли программиста? Ты же мешаешь другой тред сюда.

мотивировать свои решения/предложения == объяснять == убеждать в их правильности. А не «вдохоновлять» и служить «музой»

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

убеждать в их правильности

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

Так же, я не вижу равенства между «обьяснять», «убеждать», «мотивировать» это все таки разные слова и у них немного разное значение.

Так же, я не вижу равенства между «обьяснять», «убеждать», «мотивировать» это все таки разные слова и у них немного разное значение.

вот видишь значит софт скилы у тебя ещё маленькие ))

а вот настоящий насяльника с развинутыми софтскилами видит! даже если ему для этого придётся найти других исполнителей которые с тупизной согласятся ))

Вас в команде 50 человек. Из них у половины — 10+ лет опыта в лидерах рынка. Ты захотел использовать библиотеку А

Если библиотеку А захотел использовать только «ты», и продавил ее за счет софт-скилов, то я видел такие проекты, где набор компонентов определяют самые разговорчивые. Держитесь там в общем.
Если это нормальная библиотека А, то на нее обратят внимание минимум человек 10 из 25, имеющих опыт 10+. Возможно, после того, как ты отправишь в канал сообщение «крутая либа». Поэтому не будет картины «один переубеждает 24».
Если же этот товарищ от рождения склонен получать кайф от переубеждения, то ему с радостью нужно найти новый проект и отправить туда с наилучшими рекомендациями.

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

Любой пример можно маргинализировать и превратить в чучело. Можно пойти дальше и сказать, что один «балабол» может «продавить» BolgenOS на сервере вместо Ubuntu. И осуждающе покачать головой.

Но в реальности, мы все прекрасно понимаем, что в больших и опытных командах такая комедия не пройдёт.

В моём примере № 2 я написал «половина здесь — софт-скиллы», что подразумевает, что их одних недостаточно. И конкретные пункты: «анализ производительности, написание демо» — это подчёркивают.

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

в больших и опытных командах такая комедия не пройдёт

Легко. У нас в большой компании был чувак, который софт-скиллами получил титул принципал девелопера, автоматически с титулом получил право решающего голоса. А потом каждый раз когда команда была несогласна с его решениями, он создавал митинг на час-два, где убеждал команду принять его решение. Если по окончании митинга команда была несогласна, он объявлял вопрос нерешенным и создавал ещё митинг, где просто повторял свои предыдущие аргументы. При необходимости создавались ещё митинги. Команда всегда сдавалась первой.

Какая связь всего этого с софт скиллами? Человек занимается полной дичью уровня e****.it и настраивает против себя команду. Офигенная демонстрация софт скиллов.

Есть подозрение, что

чувак, который софт-скиллами получил титул принципал девелопера

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

В итоге приходим что в общей массе с софт скилами все довольно приемлемо ± и их роль преувеличена ?

В итоге приходим что в общей массе с софт скилами все довольно приемлемо ± и их роль преувеличена ?

Где приемлемо и кем преувеличена? :)
Как вообще можно ответить на этот вопрос?
ТС вроде как вообще слился после создания топика.

Я говорю, что все зависит. От размера команды, твоей роли, твоих целей и т.д.

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

Как вообще можно ответить на этот вопрос?

Никак ) В этом весь смысл топика ))
Для тех кому это важно пишет, что это важно, кому не важно пишет что не важно...

под софт скиллы сюда приплели какие-то подковерные игры и коррупцию, которыми человек выбил себе должность

 А это что, хард скиллы? Или не скиллы? Естественно, это — софт скиллы, то есть, умение эффективно общаться с людьми.

и настраивает против себя команду.

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

под софт скиллы сюда приплели какие-то подковерные игры и коррупцию

Потому что софт скиллы — это и есть синоним подковерных игр.

Потому что софт скиллы — это и есть синоним подковерных игр

На самом деле нет, но во многом из-за распространенности этого заблуждения софт скиллы воспринимаются как нечто плохое.

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

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

Может быть выслуга лет и заслуга в смежных облостях, итд.

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

а если бы ему попался в команде кто-то с кредо «никогда не сдавайся»? Больше бы решения не принимались, наверное, никогда

И команду бы разогнали как непродуктивную

Кто-нибудь из них бы крепко поругался с другим и нажаловался менеджеру на некоммуникабельность.

Зачем ругаться, если просто не согласен?

то на нее обратят внимание минимум человек 10 из 25, имеющих опыт 10+. Возможно, после того, как ты отправишь в канал сообщение «крутая либа». Поэтому не будет картины «один переубеждает 24».

Представь себе 10 из 25 человек переодически отправляют в канал сообщение «крутая либа».
Точно внимание обратят? А если это делают 25 из 50? даже если они делают это каждый раз в пол-года то это получается в среднем одна «крутая либа» в неделю. Точно обратят?

Обычно большая часть комманды такие чатики на 50 человек первым делом вообще мютит, и никогда не открывает, чтобы не отвлекали от работы.

Ну и «крутая либа» — понятие очень растяжимое. Может быть чето аля «считалки таймзон» с 0 зависимостей — сам ее себе прикрутил, всем пофигу. А может быть «а давайте спринг-бут заменим»,

Так отож. Я скажу в общий чатик «крутая либа» и все умные меня сразу поймут и поддержат это влажная мечта человека никогда не предлагавшего что либо, даже команде из 5 не джуниоров.

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

Я вот так-то с колеегой делали POC, писали ± и потом на отдельном митинге с тем кто аппрувал решения мы изясняли почему нам надо ЭТО, а не другое.

Так же для рефакторинга собирались чисто инжинерами и обсуждали что не так и что лушче как сделать, что блочит, как сделать так чтобы не писать 5 лет снова и не переписывать все с нуля, опосля я накатал письмо — вынес главные поинты и решение для них, и подход как рефачить спринт бай спринт.

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

Для этого не нужны никакие особые скилы — просто внятно обьяснить проблемы и решение этих проблем, (адекватный)манагер сам доведет дело до ума ибо у него гораздо больше горизонт виденья, вот так вот просто на самом деле. Тут больше за рабочие процесы.

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

Это собственно за что мне в общей массе америкосы(те которые повстречались) нравятся — let’s get the feature done ориентированные.

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

Чувак, но ведь это же и есть те самые софт скилы. Ты вот не первый раз пишешь пример того как сам их использовал.
— Написать толковую понятную и по делу доку — это софтскил.
— Организовать митинг и конструктивно её обсудить с правильными людьми- это софтскил
— Написать сраное самари после митинга — тоже софт скил (вот это кстати вообще далеко не каждому дается) PS: Кстати, Меня этом почему-то на трейнинге научили. Ходите на правильные трейнинги ;)
Да это может быть не то, что проверяют какие-то там девочки ейчары (Хотя рекрутеры когда нанимаю людей они именно про такое и стараются вопросы задавать, ну если там они притендуют на то что бы оценить твои качества коминдной работы и все такое) и это не совсем то, что абстрактный коуч расскажет тебе на абстрактном трейнинге (потому что для развития разных скилов нужны в том числе и разные подходы). Если тебя пилят по какому-то другому поводу — это скорее говорит не о том что софт скилы не нужны а о том, что у вас не правильно идентифицировали что вообще надо то. Так бывает. У меня по-моему тоже так. Я вот такую бредятину под соусом софт скилов тут выслушал совсем недавно...

Для этого не нужны никакие особые скилы

Нужны, нужны, другое дело что у тебя они есть «из коробки» на достаточном уровне для твоей работы, и то что нормально развитый взрослый человек (в ИТ не все такие) их как правило имеет. Ну и да, для разных работ в разных инваерментах они могут разные понадобиться кстати, у менеджера они другие, у предпродажние третьи.

Ок, спасибо за хорошее разъяснение. Я отступаю.

просто внятно обьяснить проблемы и решение этих проблем

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

Ээ, тут скоуп вопроса резко другой, меняем коней на ходу)) Как по мне, софт-скиллы — это умение в средне-нормальной обстановке объяснить проблему и решение.
А по сабжу — если выше директора никого нет — то лучший рецепт валить подальше)) а если есть кто-то повыше дира — можно ему и внятно объяснить траблу, с вещдоками в виде сколько было зря потрачено времени и ресурсов, например. Софт скиллами невозможно «вылечить» проблему, если руководство кривое и косое (но иногда можно удачно отредиректить проблему туда, где ее могут порешать). А вот отсутствием софт скиллов можно насоздавать кучу проблем и при наличии более-менее адекватного руководства и тимы.

А давай свое определение софтскиллов в студию) А то мы вообще о разных понятиях говорим, кмк.

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

На этом разнообразие закончилось?

Разнообразию человеческого дури предела нет.

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

Угу, agree) справедливости ради, вокруг темы софтскиллов и правда развели кучу булшита и всякой воды)) но да, погуглить 5-6 дефинишнов и сформировать понимание термина — не запредельно сложное упражнение))

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

я правда не вполне догоняю зачем она их (чатики) сперва создаёт а потом начинаются стоны «не пишите туда пишите в личку!» ))

Даже в стартапчиках на 100 человек такие порядки в полный рост.

Даже в семьях на 2 рыла такие порядки в полный рост. И распад в 67% случаев в течение года.
А 100 человек уже не стартап, а полноценная боевая единица со своей дедовщиной.

Это просто метод отсева тех, кто говорит «тут написано все плохо, я не хочу в этом разбираться и мне проще заново переделать».

это потому что их самих чисто физиологически чисто статистически намного больше чисто числом ))

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

Может, полезность скиллов зависит от общества? Сунь прокачанного неиндивидуалиста в это общество — под каким забором он закончит?

Индивидуализм не мешает командной работе. А недоверие и посаженные софт скилы — да, мешают, тут согласен.

На самом деле не из-за этого. А из-за неумения вести конфликты. В ТОМ ЧИСЛЕ из-за дурацкой системы образования, которая не учит, но дрессирует бесприкословному подчинению дебилам.

Конфликт сам по себе не проблема. Это способ РЕШИТЬ проблему. Но это ж надо уметь делать. А у нас как: сначала прячем проблемы под ковёр и спускаем собак на тех, кто не согласен. А потом ищем козла отпущения (а ну, кто тут со слабыми софт-скиллами?) и валим на него все проблемы. Разумеется, шанса их решить без потерь уже нет.

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

Вуаля, Вы просто раскрыли для себя основу капитализма. Аж с самого Гообса и Локка. Только при чем тут образование, коль оно — функция от общественного строя?

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

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

У программистов «просажена» разве что экстравертность. И она совсем не синоним софт скиллов (а иногда и их противоположность)

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

Экстраверты все должны быть паиньками?

Когда человек тупо норовит просто так самоутвердиться за чужой счет, то это не экстраверт, это мyдaк с признаками нарциссизма.
Ну а тот чел вообще тупо по списку имел диагноз нарциссического расстройства.
Например, он абсолютно всерьез доказывал своей матери в телефонном разговоре: «Мама, я не такой, как все!».

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

Схоже підростаюче покоління таки проникнулося ідеєю софт скілзів, тренінгів по ним і коучам dou.ua/...​rums/topic/29145/#1736204

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

да, так и есть, одна из причин по которой ливнул с прошлой компании в том что большие компании стали тянуть в себя гуманитариев-леваков, даже в Украине

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

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

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

Кастомеру абсолютно пофигу было ибо команда перформила боле мнее во время и проект выполнял поставленные задачи

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

Это был стартап и основаня команда были люди до 25 лет. Кастомер, он же бенефециар проекта. Но это не меняет сути —

софт скилы это очень субьективное понятие и зависит от команды

Хотя можешь искать оправданий в легаси и ламерах сколько хочешь.

habr.com/...​y/regionsoft/blog/479746

Любопытная табличка на вражеском сайте, Рэмбо составлял наверное)

Дать кому-то ярлык «низкие софт скиллы» это такой корпоративный пассивно-агрессивный способ назвать кого-то мудаком.

пассивно-агрессивный способ назвать кого-то мудаком

так поступают только мудаки

не-мудаки называют мудаками напрямую?

их потом увольняют за агресивность.

зато они берут ответственность за свои слова

никакой ответственности, никакой агрессивности и вообще ничего не делать (если делать, то будут ошибки и феейлы) и тебя не уволят

Главное — перед этим ухитриться наняться.

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

это такой корпоративный пассивно-агрессивный способ назвать кого-то мудаком

Здравствуй, Татьяныч

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

Если будешь искать конформистов — получишь среднячок. Если надо ниндзей — умей маневрировать. Зато есть шанс получить результат в разы дешевле и быстрее.

А то что в данном контексте называется «умение маневрировать» это не софт скилы, не?
Ну допустим, у тебя 3 ниндзя девелопера, ниндзя-дизайнер, ниндзя-техлид, ниндзя-сейл, ниндзя-продакт, ниндзя-тестер. Как им всем вместе работать и проявлять свои ниндзя-хард-скиллы, чтобы совместно достигать целей, поставленных ниндзя-сео?

Лиду нужны софт скиллы чтобы остальные ниндзи не подрались. Если он выполняет роль тим лида. Если он — чисто тех лид, то ПМу прийдется быть тим лидом и это все настраивать.

Рембо тебе посоветовал заткнуться, когда ты в очередной раз по телефону в опенспейсе орал?

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

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

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

В итоге можно попасть в тиму где мудаков 75%, которые будут считать что мудак именно вы, ведь вы не такой как они, а четких критериев\метрик нету.

Да и кому они вперлись эти метрики и критерии, если эти мудаки стабильно релизят в срок и что-то более менее рабочее.

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

так как большинство работников фопы и им дела нету до культуры компании

Ну так пусть оформят их по КЗОТ )))))

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

а какая тогда разница между «софт скилами» и «кальчурал фит» ? (:

Не знаю, для меня это все в категории булщит. Тараканов в голове я обсуждаю со своим пихологом. (:

Простыня текста? Нет, спасибо. :-)

Такие гамнюки используя те же связи могут такое сделать

Какое, такое? Добавить в ЧС Епама? Очень страшно.

кулаком в морду лучший ответ и пойти через дорогу на +500

Во-первых, это минимум административка (а, если перестараться, то и уголовка).
Во-вторых, это прямая дорога не «через дорогу на +500», а в чёрный список.

Про последний рассказывают много легенд и страшилок. Насколько я слышал, в реальности никто не страдает маразмом, добавляя туда людей за любые мелочи типа «нахамил менеджеру», но вот драки / воровство офисного имущества (не ручек и скрепок, понятное дело) / увлечение «веществами» и запойный алкоголизм — дают неиллюзорные шансы туда попасть.

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

Вообще, задайте себе вопрос, чего вы хотите? Вы хотите работать с идиотами? Вы хотите сканадлить и отвоевывать свою точку зрения или решение?Хотите отомстить им потому что они вас сильно задели? Вы хотите справедливости во все румах офиса?

Разберитесь чего вы хотите и ответ скорее всего сам придет.

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

Имеем естественный отбор с двух сторон:
Крупные структуры выбирают конформистов в силу «инстинкта» самосохранения системы
Индивидуалисты выбирают мелкие конторы, так как там больше свободы
В результате всем лучше

Интересное наблюдение

Мне кажется, что проблема не в роли понятия soft skills, а в его трактовке. Зачастую говоря про софт скилы идет сравнение по шкале «общительность» — вот и у вас тут:

Хотя в реале люди довольно адекватные, нормальные и умные, а то и жизнерадостные весельчаки.

Но софт сколы это не про общительность.
Софт скилс — это персональные, человеческие скиллы — как человек работает сам с собой и с другими.
Как проверить завышена роль или нет?
Нужно честно ответить себе на вопрос — работа в вашей команде действительно имеет высокую эффективность/слаженность/надежность/комфорт и т.д? Часто ли возникают конфликты? А когда возникают эффективно ли они разрешаются? Много ли места для улучшения?
Если ответ на эти вопросы да — то роль софт скилс не завышена — потому что именно они помогают решать подобного рода проблемы.

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

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

Тогда что имеется в виду под «софт скиллами»?

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

Soft skills are a combination of people skills, social skills, communication skills, character or personality traits, attitudes, career attributes,[1] social intelligence and emotional intelligence quotients, among others, that enable people to navigate their environment, work well with others, perform well, and achieve their goals with complementing hard skills.

Я для себя это определяю как набор навыков эффективной работы самостоятельно и при взаимодействии с другими.

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

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

взаимодействии с другими

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

Так посадите его писать отдельный модуль под ТЗ и АПИ. Не будет КТ и тесной коммуникации. Потом походу ему нахамят, когда модуль не заработает по контракту, и успокоится.

Ну вот, ты сам доказываешь что толковых метрих\критериев нету. А значит это сплошной субьективизм. Этот рашн-гай может отлично вписаться в тиму таких же рашкованов и вместе по понятиям контрибутить более мнее в срок и прогнозируемо. И вот тут уже появляются метрики и критерии — время, деньги...И бизнессу на самом деле глубоко покую на эти скилы если они приносят прибыль и выполняют поставленную задачу.

Ну у меня сосед, у которого такое временами проявлялось. Пару раз обломался, и стал поспокойнее. Теперь прислушивается.

В результате прокачают скиллы оба)
Идея в том, что рашнгай может раньше был самым крутым на конторе, и поведение было правильным. Сейчас, если он не самый крутой — поменяет поведение, когда набьет шишек в технических аспектах. А если остался самым крутым — такой стиль экономит кучу времени, спасая от того, что всякие трейни объясняют ему по пол-часа очевиднейшие вещи. В таких случаях перебивать надо.

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

успешных

Критерии успешного плиз.

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

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

Тогда приводи уже в противовес дрим-тим, которые все из себя няши, коммуницируют на ура, а вот с принятием решений и таки работой туго

На няш они не тянут)

Так это просто нормы приличия. В корпорациях софт-скилами считают больше умение в крысиные бега

для подсидеть как раз софт-скиллы нужны) плюс ненавязчивый фингерпойнтинг и вот это вот все

«Праведный Гнев» вполне работает и внутри, если конечно «корпоративная культура» это позволяет.
Аналогично очень далеко не всегда этот паттерн работает для внешних

Прям голос Джексона в голове звучал, когда читал это.

а значит оценка уровней софтскилов зачастую идет тупо субьективно.

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

Что за взаимодействие и зачем оно для выполнения обязанностей?

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

Основная масса текстов на тему софтскилов это сплошная вода и абстракционизм.

Есть достаточно и не таких текстов.

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

А вот здесь — неумение правильно разбить работу и настроить коммуникацию. Если сотрудник плохо коммуницирует — выдайте ему отдельный модуль, пропишите АПИ, и сделайте оценку сроков за него. И нефиг его коммуницировать — пускай код пишет!

И нефиг его коммуницировать — пускай код пишет!

Мне кажется, вот в этом и лежит наше с вами разночтение.
Важность софт-скиллов в современной работе именно потому и выросла, потому что все реже человек выполняет какую-то работу целиком самостоятельно независимо от других.
Даже для написания АПИшки часто нужно взаимодействовать с другими людьми — другими программистами, менеджером/продакт оунером, тестерами, бизнес-аналитиком, архитектором и т.д. Нужно, чтобы это взаимодействие было эффективным, вопросы и проблемы разрешались, все эти цепочки взаимодействия не простаивали блокируемыми из-за неналаженной или халатной работы.
Нужно уметь спланировать выполнение, определить риски, уметь коммуницировать возникающие по ходу исполнения проблемы или незапланированные события.

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

Даже для написания АПИшки часто нужно взаимодействовать с другими людьми — другими программистами, менеджером/продакт оунером, тестерами, бизнес-аналитиком, архитектором и т.д.

У Вас техлида нету, который понимает архитектуру, может разбить задачу на модули, прописать АПИ, и следить, чтобы проект в кашу не превратился? Если каждый программист начнет писать как вздумается, быстро получится www.laputan.org/mud

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

Ээээ
Если проблема на уровне АПИ модуля — это дело того, кто АПИ писал. Если общую архитектуру проекта и разбивку на модули делал лид — то это точно лида проблема.
Если проблема ВНУТРИ модуля — то чувак, который этот модуль пишет, сам ее и порешает. Не знает, как — подойдет и спросит. Или завтычет, и ты его спросишь, когда увидишь, что сильно долго новости читает.

У Вас техлида нету, который понимает архитектуру, может разбить задачу на модули, прописать АПИ, и следить, чтобы проект в кашу не превратился?

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

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

Это уже больше респонсибилити менджера.

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

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

А может дело таки в морде?

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

Вода водой, и скатился к пирамидам.

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

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

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

А на самом деле как?

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

Ой ну Торвальдс вообще отличный пример о том как можно слать накуй и тыкать фак на видео и при этом быть успешным.
Как я и не раз писал — софт скилы весьма субьективная штука.

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

Да мена с половины работ увольняли за такое. Только вот из команд при этом друзья остались)
dou.ua/...​rums/topic/29145/#1735201

Тут уже вопрос — ходить на рынок искать следующего, или и такой сойдет.
Вообще, если эффективность работы на проекте нужна, и проект нестандартный — тогда нужна и нестандартная структура команд. А если такие задачи уже 10 раз решали — ну тогда уже и структура устоялась.
Книжицу все-таки рекомендую по этому делу epdf.pub/...​software-development.html

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

Как видишь — все субьективно.

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

Хамить... Для кого как, я как-то на заводе матами общался(орал) и меня уважали потом, и считали что у меня хорошие софт скилы.

Как видишь — все субьективно.

:-)

Так быть

клевыми

это и вся суть софт скилов? :-)

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

выдайте ему отдельный модуль, пропишите АПИ, и сделайте оценку сроков за него.

А может за него и сопли подтереть?

И нефиг его коммуницировать — пускай код пишет!

Хз, может в галерном бизнесе тушка, которая только и умеет, что кодить по спеке за мелкий прайс, для чего то сгодится, но в наших реалиях если человек не умеет делать все вышеперечисленное — то это джун, а если не способен всему этому научиться — то его профпригодность определяется как «третий сорт — не брак».

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

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

У вас там что на проекте, между высокоуровней архитектурой и кодить по спеке нет никаких промежуточных уровней?

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

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

Если сотрудник плохо коммуницирует — выдайте ему отдельный модуль, пропишите АПИ, и сделайте оценку сроков за него

Но зачем? Это разве что для очень ценных сотрудников будет делаться

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

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

Там где технические требования становятся более требовательными хорошие парни часто не прходят. Те кто и хороший парень и хороший кодер попадаются довольно реже и стоят обычно поболье среднего. А чтобы еще такой парень еще и готов был лидить или манагерить так еще реже и дороже.

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

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

Напрмер — две карйности буквально в этом посте — фанги и остальные самодруы с хлыстами

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

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

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

Мне недавно в линкедине попалась вакансия украинская, где требовался дотнетчик со всеми обычными требованиями, типа 3-5 лет опыта работы, шарп, скл и т.д., но среди прочего было WPF. Я ради шутки написал в комментариях, «а без WPF нельзя?» — и мне рекрутер сказал — «нет, хотят только с WPF.».
Это и есть тот подход про хард скилы. Хотя у меня 10+ лет разнопланового опыта в дотнете, все остальное в списке я знаю-умею, но с WPF и правда никогда ничего не делал. Но я через неделю могу начать на нем писать как минимум на уровне мидла.
А вот научиться проводить четкие и эффективные по плану, структуре, времени и подаче митинг или презентацию, как это умеют другие, мне до сих пор сложно, сколько не стараюсь.

Так никто не говорит что НЕ БЫВАЕТ хороших парней с офигенными скилами.
Просто есть вот кандидат А, хороший и скилы достаточны. и есть кандидат Б, редко улыбается и не ходит на корпоративы, скилы ТАКИЕ ЖЕ.
Очевидно, что кандидатов вида А тупо меньше и они стоят ДОРОЖЕ.
Ну как минимум потому, что надо развивать две ветки,а очков навыков и времени в сутках — одинаково.
Что ведет к тому, что при сложных задачах такие кандидаты хотят 1млн+ в год и компания не может себе позволить держать их больше 1го(а иногда и 1го не может). Проще держать отдельного чувака с зарплатой 80к, который может ладить с кандидатом Б.

правильно коммуницировать

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

Я как-то работал на заводе и вот там эти «правильно» и «уметь», приобретали совсем иные формы нежели в IT, а результат и качество определяется так же само — денгами, количеством и качеством приозведенного товара.

Поэтому это все еще субьективизм и абстракционизм намертво прибитый к контексту, без оного — вода водой.

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

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

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

Может, их эффективнее заменить прямой коммуникацией между разработчиками?

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

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

Я не то, чтобы топлю за стендапы — если команда считает, что они не несут пользы, то они не несут пользы. Мы же тут не полезность стендапов обсуждаем, я их просто привел как один из типов митингов. Затягивать и проводить неэффективные митинги можно не только на стендапах :)

Мы обсуждаем необходимость софтскиллов.
Софтскиллы важнее хардскиллов в окружении, которое требует софтскиллы.
Если в конторе каждый день проводятся партсобрания, и ты не умеешь на них красиво выступать — тебя понизят, уволят и еще раз понизят за несоответствие корпоративной культуре.
Если в другой конторе инженеры сидят в комнате и кодят, а митинги только лид посещает — то уволить могут за количество или качество работы, а не за неумение говорить красиво.
Соответственно, в гадюшнике хорошо приживаются рептилии, а в R&D — инженеры.

P.S. При найме или удержании сотрудников выбор или/или. Универсалов на всех не хватит.

Софтскиллы важнее хардскиллов в окружении, которое требует софтскиллы.

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

Если в конторе каждый день проводятся партсобрания, и ты не умеешь на них красиво выступать

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

а не за неумение говорить красиво.

Важно не красиво говорить, а эффективно говорить — структурировано, четко, понятно другим.

Соответственно, в гадюшнике хорошо приживаются рептилии, а в R&D — инженеры.

Еще раз — мое убеждение, что инженерам тоже нужны софт скиллы. Потому что они не работают каждый сам по себе независимо от других.

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

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

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

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

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

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

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

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

Да нет у всей команды целей.
У одного цель — побыстрее свалить к жене и детям и быть еще живым после работы.
У другого — побыстрее скопить на квартиру.
У лида — получить повышение, или чтобы не трогали.

А ну тогда да, похер на все лишь бы зп платили и доллар не падал :)

Ну поживешь несколько лет с целью достичь процветания конторы, тебя пару раз уволят — оценишь)

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

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

У нас сейчас — хороший work-life balance. Нет гонки по проекту, можно кодить в свое удовольствие. Можно не кодить, но это скучнее.

Ну если ты свято веришь в корпоративные ценности и готов перформить во имя великой цели — «изменить мир и заработать бабла акционерам», то это конечно действительно круто и хорошие софт скиллз, дооооо :-)))

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

А зачем тогда эти графики во всех жирах, если они ничего не показывают?

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

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

У тебе какая-то не здоровая любовь к болотологии типа «калче фит» и «софт скилз», уверовал в «корпоративные ценности», «великую цель — изменить мир и заработать бабла акционерам» ? :-)

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

А почему работа ненавистная?Она может быть нейтральной, может нравится проект но не нравится тима, может наоборот, там куча параметров.

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

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

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

Митинги вообще зло. Но они неизбежное зло. Вопрос в том, что их тоже нужно уметь готовить и в них участвовать — и это как раз те самые софт скилз.

Но они неизбежное зло.

А вот тут — зависит от гибкости мышления и преданности традициям.

Тоесть — все субьективно и относительно команды. В итоге —

субьективизм и абстракционизм намертво прибитый к контексту, без оного — вода водой.

другим она нужна когда их пригласят на митинг с заказчиком

а зачем тянуть всех инженеров к заказчику? зоопарк, что ли?

Чтобы инженеры были в курсе проекта

Нафига? Есть лиды, они должны быть в курсе и рассказывать за чаем интересные новости остальным. А отрывать от работы инженеров — это не ценить ни их время, ни свои деньги.

бо большинство лидов хочет быть на высоком уровне и не вдаваться в детали

Поднятые Вами вопросы абсолютно реальны и имеют место быть.Отвечу пародоксально.Проблемы что Вы описали это внутренний защитный механизм от быстрой технологической смены жизненных процессов.Например Вы специалист,прошли огонь,воду и медные трубы.Вы знаете многое и умеете и... можете изменить жизненную среду через свои умения,через новые проекты.И тут Вы вылетаете из системы.Вы пытаетесь зайти в «систему» с другой стороны(через другую фирму-новый проект), а у Вас препятствия в виде HR-очек,"софт скилов и т.д".Это барьер, для Вас.Его выстроила система что бы сдержать Ваше проникновение по ее изменению.Вас не взяли(выгнали).Взяли вайтишника.Система расширяется колличественно но не качественно.Это сдерживающий фактор.Надо просто принять это либо стать главой-генерирующим фактором(Гугл,Фейсбук,Микрософт и т.д).,только тогда Вы сможете влиять на внутренние процессы.Остается только принять данность,пробовать зайти с другой стороны(если система Вам позволит))).

Подписаться на комментарии