👊 Про коммуникацию и софт скиллы
Мои давние друзья знают, что к разговорам про софт скиллы я отношусь скептически. Причина в размытости этого понятия (никто толком не знает, что такое эти самые софт скиллы и что в них входит) и в отсутствии понятной шкалы, которой их можно измерить. С хард скиллами все проще: я могу пройти тест по JavaScript и получить, скажем, 7 из 10, а с софт скиллами так не получится.
Лично я считаю, что почти половина из того, что почему-то называют “софт скиллами”, относится к воспитанию человека, а еще почти половина — к характеру. Например, ответственность. Не знаю, почему ответственность вдруг стала “навыком”, в мои времена ответственность прививали родители и она была частью взросления и воспитания. Или, скажем, “нетоксичность”. Люди “токсично” реагируют на те или иные раздражители и, на мой взгляд, это зона компетенции психологов, но никак не “навык”, который можно развивать.
Но есть “софт скиллы”, которые я считаю полезными. Например, навык презентовать свои мысли и идеи.
Проект — результат работы команды. Чтобы делать проект командой, необходимо, чтобы все понимали, что мы, собственно, делаем. Поэтому, если возникает какая-то идея, ее надо объяснить коллегам. Давайте посмотрим на этот мягкий навык повнимательнее.
Предположим, я придумала архитектуру фронтенд приложения. Я решила, что у меня будет слой данных, который будет синхронизироваться с апи, слой UI, библиотека переиспользуемых компонентов, шина и сервисы, которые обновляют данные. Прекрасно. Теперь мне надо донести свои идеи до коллег, чтобы они поняли, за что отвечает шина, за что отвечают сервисы, какой код должен быть в каждом месте и что именно из этого надо использовать в разных местах UI.
Чтобы донести свою идею, мне необходимо:
Во-первых, определить существенные признаки придуманных мной элементов системы. То есть, с точки зрения формальной логики — выделить понятия.
Во-вторых, определить связи между элементами системы.
Поскольку определение понятия — процесс трудоемкий, проще всего этого сделать, опираясь на плечи атлантов, то есть предшественников. С одной стороны, мы собираем все свои мысли в кучу и формируем понятие, а с другой стороны — само понятие позволяет нам формировать наши идеи, отшлифовать их, так как понятие уже содержит идеи. Процесс обоюдный. Сравните: “нам нужен компонент, через который все части системы смогут обмениваться информацией и получать сообщения, чтобы как-то на них отреагировать, и это будет общий компонент, ну потому что эээээ…. я так вижу” и “нам нужна шина”. Второй тезис гораздо более емкий, он быстрее и точнее позволяет доносить свои идеи до коллег и окружения. Если первое объяснение более расплывчатое и позволяет каждому члену команды понять его в силу своих желаний и возможностей, то второе — гораздо более точное.
Однако для того, чтобы пользоваться идеями предшественников как фундаментом своих собственных идей, необходимо эти идеи предшественников знать. Получается, что для того, чтобы объяснить коллеге Васе, как работает код в твоем пулл реквесте, полезно читать книги о разработке, особенно известных авторов (потому что их идеи известны широкому кругу лиц), а это в нашем комьюнити уже считается хардами.
Вот так и получается, что этот софт скилл — это на самом деле хард скилл. Если у вас сильные харды, то вы легко отделяете одни паттерны и одни понятия от других и сможете ясно и четко объяснить свои идеи коллегам. А если харды слабые, то вы сами видите эту картину как через мутное стеклышко и никому ничего объяснить не сможете.
🔜 Канал в MAX
#softskills
Мои давние друзья знают, что к разговорам про софт скиллы я отношусь скептически. Причина в размытости этого понятия (никто толком не знает, что такое эти самые софт скиллы и что в них входит) и в отсутствии понятной шкалы, которой их можно измерить. С хард скиллами все проще: я могу пройти тест по JavaScript и получить, скажем, 7 из 10, а с софт скиллами так не получится.
Лично я считаю, что почти половина из того, что почему-то называют “софт скиллами”, относится к воспитанию человека, а еще почти половина — к характеру. Например, ответственность. Не знаю, почему ответственность вдруг стала “навыком”, в мои времена ответственность прививали родители и она была частью взросления и воспитания. Или, скажем, “нетоксичность”. Люди “токсично” реагируют на те или иные раздражители и, на мой взгляд, это зона компетенции психологов, но никак не “навык”, который можно развивать.
Но есть “софт скиллы”, которые я считаю полезными. Например, навык презентовать свои мысли и идеи.
Проект — результат работы команды. Чтобы делать проект командой, необходимо, чтобы все понимали, что мы, собственно, делаем. Поэтому, если возникает какая-то идея, ее надо объяснить коллегам. Давайте посмотрим на этот мягкий навык повнимательнее.
Предположим, я придумала архитектуру фронтенд приложения. Я решила, что у меня будет слой данных, который будет синхронизироваться с апи, слой UI, библиотека переиспользуемых компонентов, шина и сервисы, которые обновляют данные. Прекрасно. Теперь мне надо донести свои идеи до коллег, чтобы они поняли, за что отвечает шина, за что отвечают сервисы, какой код должен быть в каждом месте и что именно из этого надо использовать в разных местах UI.
Чтобы донести свою идею, мне необходимо:
Во-первых, определить существенные признаки придуманных мной элементов системы. То есть, с точки зрения формальной логики — выделить понятия.
Во-вторых, определить связи между элементами системы.
Поскольку определение понятия — процесс трудоемкий, проще всего этого сделать, опираясь на плечи атлантов, то есть предшественников. С одной стороны, мы собираем все свои мысли в кучу и формируем понятие, а с другой стороны — само понятие позволяет нам формировать наши идеи, отшлифовать их, так как понятие уже содержит идеи. Процесс обоюдный. Сравните: “нам нужен компонент, через который все части системы смогут обмениваться информацией и получать сообщения, чтобы как-то на них отреагировать, и это будет общий компонент, ну потому что эээээ…. я так вижу” и “нам нужна шина”. Второй тезис гораздо более емкий, он быстрее и точнее позволяет доносить свои идеи до коллег и окружения. Если первое объяснение более расплывчатое и позволяет каждому члену команды понять его в силу своих желаний и возможностей, то второе — гораздо более точное.
Однако для того, чтобы пользоваться идеями предшественников как фундаментом своих собственных идей, необходимо эти идеи предшественников знать. Получается, что для того, чтобы объяснить коллеге Васе, как работает код в твоем пулл реквесте, полезно читать книги о разработке, особенно известных авторов (потому что их идеи известны широкому кругу лиц), а это в нашем комьюнити уже считается хардами.
Вот так и получается, что этот софт скилл — это на самом деле хард скилл. Если у вас сильные харды, то вы легко отделяете одни паттерны и одни понятия от других и сможете ясно и четко объяснить свои идеи коллегам. А если харды слабые, то вы сами видите эту картину как через мутное стеклышко и никому ничего объяснить не сможете.
🔜 Канал в MAX
#softskills