Я уже 10 лет в айти, и как человек "по ту сторону забора", в которую эйчары пытаются заглянуть, поделюсь своими мыслями.
Софт-скиллы, в моем понимании, это способность человека установить контакт с коллегами. Характер - это про другое.
Софт-скиллы: - могу доступным языком объяснить Имя_1, что его задача поставлена некорректна, задам уточняющие вопросы, приведу пример описания задачи, которое поможет мне максимально эффективно добиться цели; - буду контролировать свои эмоции и не кричать на Имя_2, из-за того что меня расстроило, что мой кактус засох; - сообщу словами через рот коллегам о своих опасениях, недопониманиях и пр.
Характер же формируется десятилетиями. Первая ссылка в гугле по запросу "что такое характер" выдает: Психологи выделяют три группы характеристик, которые в совокупности и составляют характер человека: отношение человека к самому себе, отношение человека к окружающим, отношение человека к своей работе и деятельности.
Софт-скиллам можно научиться, характер можно только воспитать в себе самому.
В статье читаем: "Во время собеседований я всегда обращаю внимание на софт-скиллы, или, как пишут в книжках, на мягкие навыки. ... К ним относят, например, коммуникативные навыки, критическое мышление, ответственность, настойчивость, целеустремлённость, амбициозность, лидерство, умение эффективно разрешать конфликтные ситуации и так далее."
А теперь давайте разберем типичную ситуацию. У нас компания N, которой нужен миддл-разработчик на Y-языке программирования. У него будет тимлид и 3 коллеги в команде.
Если мы применим то, какие качества якобы ищут в софт-скиллах, то получится, что мы ищем следующего человека: - он будет подвергать сомнению любое бизнес-требование (критическое мышление); - он будет настаивать на своем решении задачи, даже если тимлид ему будет говорить пойти по-другому пути (настойчивость); - он будет пытаться выслужиться перед руководителем, чтобы заменить сеньора, а потом и тимлида (амбициозность); - он станет теневым лидером группы, бросая вызовы тимлиду (лидерство).
Это экстраполяция на самый крайний случай, но на ней видна одна важная вещь: человек, обладающий такими качествами, не станет хорошим линейным исполнителем задач.
Все перечисленные качества подходят для руководящей позиции, но точно не для подчиненных, для которых не планируется повышение в должности В ОБОЗРИМОМ БУДУЩЕМ. Если ваши ряды уже укомплектованы хорошими специалистами, зачем обещать сеньору, что через год он станет тим лидом, если вы не планируете менять тим лида?
Ну и конечно же "В итоге мы взяли её на трёхмесячную стажировку, она успешно её прошла и меньше чем за год поднялась до уровня мидл." - просто смеюсь в голос. Мидл за год? Это из той же серии, что сеньор в 20 лет.
Есть вещи, которые недостаточно прочитать в книгах. Есть нюансы, которые нужно прощупать, и не один раз. Руками, через консоль, через отсутствие документации, через много часов поисков клада и осознания глубинных процессов вашей X-технологии.
При запросе доступа к информации мы передаем какие именно данные хотим получить, например если это только название и ИНН, то в окошке подтверждения, которое увидит пользователь, будут только эти поля, и если после одобрения мы попытаемся получить какие-то еще, ЕСИА вернет ошибку о том, что недостаточно прав на просмотр.
Если сервису понадобится расширить область доступа к другим данным юр.лица, то пользователю снова отобразится окошко с подтверждением где будет новый перечень прав.
Но это происходит только один раз при авторизации, т.е к примеру пользователь первый раз зашел на сервис и решил авторизоваться через госуслуги, ему отобразились окошки с разрешением на каждую организацию, после чего он попал в свой личный кабинет. И все остальные разы, когда он будет авторизовываться, уже не понадобится запрашивать разрешение от ЕСИА, потому что мы уже получили список его организаций. И до тех пор, пока не изменится сервис (понадобятся новые поля организаций), либо у пользователя не появится новая организация, окошка подтверждения не будет.
Да, в документации есть такой запрос, но он не решал поставленную нами задачу. Этот запрос нужен, как написано в документации - "Для получения информации об организациях, в которые включен пользователь". И он возвращает данные об организации даже если сам этот пользоваль не является владельцем организации. Мы могли бы использовать его и сделать на своей стороне фильтр по chief или admin, но в целом этот запрос нам не подходит, так как возвращает ограниченный набор полей об организации, а клиенту было важно в будущем расширить возвращаемые значения, вплоть до всех возможных, что есть в таблице, а запрос /rs/prns/{prn_oid}/roles не предоставляет такой возможности.
Я уже 10 лет в айти, и как человек "по ту сторону забора", в которую эйчары пытаются заглянуть, поделюсь своими мыслями.
Софт-скиллы, в моем понимании, это способность человека установить контакт с коллегами.
Характер - это про другое.
Софт-скиллы:
- могу доступным языком объяснить Имя_1, что его задача поставлена некорректна, задам уточняющие вопросы, приведу пример описания задачи, которое поможет мне максимально эффективно добиться цели;
- буду контролировать свои эмоции и не кричать на Имя_2, из-за того что меня расстроило, что мой кактус засох;
- сообщу словами через рот коллегам о своих опасениях, недопониманиях и пр.
Характер же формируется десятилетиями. Первая ссылка в гугле по запросу "что такое характер" выдает:
Психологи выделяют три группы характеристик, которые в совокупности и составляют характер человека: отношение человека к самому себе, отношение человека к окружающим, отношение человека к своей работе и деятельности.
Софт-скиллам можно научиться, характер можно только воспитать в себе самому.
В статье читаем:
"Во время собеседований я всегда обращаю внимание на софт-скиллы, или, как пишут в книжках, на мягкие навыки. ... К ним относят, например, коммуникативные навыки, критическое мышление, ответственность, настойчивость, целеустремлённость, амбициозность, лидерство, умение эффективно разрешать конфликтные ситуации и так далее."
А теперь давайте разберем типичную ситуацию.
У нас компания N, которой нужен миддл-разработчик на Y-языке программирования. У него будет тимлид и 3 коллеги в команде.
Если мы применим то, какие качества якобы ищут в софт-скиллах, то получится, что мы ищем следующего человека:
- он будет подвергать сомнению любое бизнес-требование (критическое мышление);
- он будет настаивать на своем решении задачи, даже если тимлид ему будет говорить пойти по-другому пути (настойчивость);
- он будет пытаться выслужиться перед руководителем, чтобы заменить сеньора, а потом и тимлида (амбициозность);
- он станет теневым лидером группы, бросая вызовы тимлиду (лидерство).
Это экстраполяция на самый крайний случай, но на ней видна одна важная вещь: человек, обладающий такими качествами, не станет хорошим линейным исполнителем задач.
Все перечисленные качества подходят для руководящей позиции, но точно не для подчиненных, для которых не планируется повышение в должности В ОБОЗРИМОМ БУДУЩЕМ. Если ваши ряды уже укомплектованы хорошими специалистами, зачем обещать сеньору, что через год он станет тим лидом, если вы не планируете менять тим лида?
Ну и конечно же "В итоге мы взяли её на трёхмесячную стажировку, она успешно её прошла и меньше чем за год поднялась до уровня мидл." - просто смеюсь в голос.
Мидл за год?
Это из той же серии, что сеньор в 20 лет.
Есть вещи, которые недостаточно прочитать в книгах. Есть нюансы, которые нужно прощупать, и не один раз. Руками, через консоль, через отсутствие документации, через много часов поисков клада и осознания глубинных процессов вашей X-технологии.
При запросе доступа к информации мы передаем какие именно данные хотим получить, например если это только название и ИНН, то в окошке подтверждения, которое увидит пользователь, будут только эти поля, и если после одобрения мы попытаемся получить какие-то еще, ЕСИА вернет ошибку о том, что недостаточно прав на просмотр.
Если сервису понадобится расширить область доступа к другим данным юр.лица, то пользователю снова отобразится окошко с подтверждением где будет новый перечень прав.
Но это происходит только один раз при авторизации, т.е к примеру пользователь первый раз зашел на сервис и решил авторизоваться через госуслуги, ему отобразились окошки с разрешением на каждую организацию, после чего он попал в свой личный кабинет. И все остальные разы, когда он будет авторизовываться, уже не понадобится запрашивать разрешение от ЕСИА, потому что мы уже получили список его организаций.
И до тех пор, пока не изменится сервис (понадобятся новые поля организаций), либо у пользователя не появится новая организация, окошка подтверждения не будет.
Да, в документации есть такой запрос, но он не решал поставленную нами задачу. Этот запрос нужен, как написано в документации - "Для получения информации об организациях, в которые включен пользователь". И он возвращает данные об организации даже если сам этот пользоваль не является владельцем организации.
Мы могли бы использовать его и сделать на своей стороне фильтр по chief или admin, но в целом этот запрос нам не подходит, так как возвращает ограниченный набор полей об организации, а клиенту было важно в будущем расширить возвращаемые значения, вплоть до всех возможных, что есть в таблице, а запрос /rs/prns/{prn_oid}/roles не предоставляет такой возможности.