Запустив последний тест на проверку, ты откидываешься на спинку стула, чувствуя удовлетворение от проделанной работы. Твои руки создали шедевральный код, но за пределами твоего рабочего пространства мир IT требует чего-то большего. Мир, где умение писать код — это только часть уравнения. Добро пожаловать в эру, где софт-скиллы становятся неотъемлемой частью портфолио каждого разработчика.
В мире IT уже давно не достаточно просто уметь писать код. Софт-скиллы стали тем фундаментом, который помогает общаться с коллегами, находить общий язык с заказчиками и решать сложности в команде. Это мост между тем, что ты кодишь, и людьми вокруг.
Почему теперь просто кодить мало? Раньше всё было проще: писал код и всё. Однако мир меняется. Сегодня только технических знаний явно не хватает. Всё больше внимания уделяется работе в команде, пониманию её целей и способности объяснять свою точку зрения. Эффективные команды стали на вес золота в индустрии. И основа такой эффективности — это не только профессионализм каждого участника, но и его софт-скиллы. Умение слушать и быть услышанным, понимать задачи бизнеса и взаимодействовать с коллегами — всё это стало так же важно, как и чистый код.
Давай разберем, какие же качества могут помочь быть более продуктивным.
Коммуникация
Представь, что ты написал фантастический модуль для программы, но не можешь объяснить своим коллегам или клиенту, как он работает или почему он так важен. Эффективная коммуникация дает возможность не только делиться своими мыслями, но и понимать потребности других. Это ключ к тому, чтобы создавать продукты, которые действительно решают проблемы и соответствуют ожиданиям клиентов.
Более того, хорошая коммуникация сокращает время на устранение недопониманий и конфликтов. Когда все члены команды на одной волне, проекты реализуются быстрее и эффективнее.
Работа в команде
Написание кода — это, безусловно, индивидуальная деятельность, но большие проекты редко создаются в одиночку. Командная работа включает в себя не только обмен знаниями, но и поддержку и взаимопонимание между членами команды. Когда разработчики действительно работают вместе, они могут достичь результатов, которые недостижимы для одного человека.
К тому же, когда в команде возникают трудности или проблемы, коллективное мышление и разнообразие подходов могут помочь найти наилучшее решение. Это создает более сильные и устойчивые продукты.
Решение проблем
В каждом проекте, рано или поздно, возникают проблемы. И искушение обойти их стороной или просто прикрыть временным решением действительно велико. Однако настоящие профессионалы знают, что откладывание или игнорирование проблемы редко делает ее менее значимой. Наоборот, с течением времени мелкие неприятности могут превратиться в серьезные проблемы.
Софт-скиллы позволяют разработчикам подходить к проблемам комплексно, улавливать их корни и искать такие решения, которые будут долгосрочными, а не просто краткосрочными "костылями". Умение видеть перспективное решение и представлять, как оно будет работать в будущем, делает проекты более устойчивыми к изменениям и непредвиденным обстоятельствам. Эффективное решение проблемы сегодня может предотвратить целую гору трудностей завтра.
Критическое мышление и принятие решений
В мире программирования не всегда есть четкий ответ на вопрос. Иногда перед разработчиком стоит несколько путей, и нужно выбрать наилучший. Критическое мышление позволяет анализировать каждый из этих путей, прогнозировать возможные результаты и делать информированный выбор.
Без этого навыка разработчик может топтаться на месте, боясь принять решение. Или, что еще хуже, может поспешно выбрать путь, который в итоге окажется неверным. Софт-скиллы здесь помогают сделать выбор осознанным и продуманным.
Проактивность и инициативность
Ожидание, пока проблемы решатся сами собой или кто-то другой возьмется за их решение, редко оказывается хорошей стратегией. Проактивные разработчики не ждут, они действуют. Они предугадывают возможные трудности и предлагают решения еще до того, как эти проблемы станут критическими.
Инициатива также важна. Это не только про решение проблем, но и про предложение новых идей, улучшение процессов и поиск новых подходов к работе. Такие разработчики часто становятся лидерами и двигателями прогресса в своих командах.
Осознанность
Осознанность — это ключ к пониманию себя как специалиста. Она помогает выявить свои сильные стороны и области, требующие развития. Но не только. Это своего рода компас, указывающий на те профессиональные цели, которые действительно имеют значение для вас.
Когда разработчик понимает, к чему он стремится, поиск работы или проекта становится более осмысленным. Вместо того чтобы просто "плыть по течению", можно направлять свои усилия на поиск той позиции, которая будет соответствовать и личным предпочтениям, и профессиональным амбициям. Эта ясность делает нас более сосредоточенными и продуктивными, позволяя достигать результатов, которые действительно важны.
Эмпатия
Эмпатия — это глубокое понимание чувств и переживаний других людей. Для разработчика это важно, так как технические задачи часто связаны с реальными потребностями и ожиданиями пользователей. Представьте. если разработчик может почувствовать неудобство пользователя перед сложным интерфейсом, он будет более мотивирован улучшить его.
Разработчик, который умеет управлять своими эмоциями, может противостоять давлению и сохранять высокую производительность. А в команде эмпатия помогает улучшить отношения между коллегами. Понимая чувства других, можно легче находить компромиссы, эффективно решать проблемы и избегать конфликтов. Эмпатия делает командную работу более гладкой и плодотворной.
Но никто из нас не рождается сразу осознанным и эмпатичным, умеющим решать конфликты и эффективно коммуницировать. Каждый из нас обладает абсолютно разным набором личностных качеств. Кто-то умеет найти подход к любому человеку, а кому-то общение дается с трудом. Все эти навыки развиваются на протяжении жизни. Вот несколько советов, как можно прокачивать себя.
Тренинги и мастер-классы. Посещение специализированных тренингов и мастер-классов позволяет разработчикам активно развивать свои мягкие навыки. Эти мероприятия обычно ориентированы на практику, что дает возможность применить новые знания в реальных ситуациях. Зачастую можно обратиться к коллегам из HR департамента за советом и помощью, так как для HR специалистов софт скиллы очень важны в работе, и они их постоянно совершенствуют.
Чтение профессиональной литературы. Есть множество книг, посвященных развитию софт-скиллов. Они помогают разработчикам понимать важность этих навыков, а также предоставляют практические рекомендации по их применению в рабочей среде.
Обратная связь от коллег и руководителей. Регулярный запрос обратной связи может помочь разработчику понять, в каких аспектах софт-скиллов ему стоит улучшиться. Конструктивная критика часто становится стимулом для личного и профессионального роста.
Менторство. Работа под руководством опытного ментора может существенно ускорить процесс освоения софт-скиллов у менти. С другой стороны, для самого ментора это также опыт обучения. он учится слушать, находить подход к разным людям и адаптироваться к различным образовательным потребностям. Таким образом, менторство становится взаимовыгодным процессом, который позволяет обеим сторонам расти и развиваться.
Прокаченные софт-скиллы – это то, что отделяет "хорошего" разработчика от "отличного". Да, нужно уметь кодить, но еще важнее уметь общаться с коллегами и понимать, чего хочет заказчик. Это как быть не просто игроком в футболе, но и уметь играть в команде. Если у тебя есть эти навыки, ты не только делаешь свою работу, но и помогаешь всему проекту идти вперед.
Комментарии (19)
JuryPol
10.09.2023 16:49+13Почему теперь просто кодить мало?
А хотите честный ответ? Мало потому, что Айти в некоторых аспектах сейчас глубоко больнО. В эту сферу десяток с лишним лет назад хлынул мутный поток разного рода деятелей, которые увидели здесь благодатную почву для того, чтобы, поездив по ушам верхнему звену руководителей, оседлать все слои, лежащие ниже. И ничего не производя, как и не отвечая ни за что, начать торговать воздухом. При этом полноценно встроившись в пищевую цепочку Айти.
Вы пристально почитайте определения этих ваших софт-скиллов. Это же Эльдорадо!!! Тут можно разворачивать целую индустрию курсов и тренингов, все размыто, субъективно, критерии четкие отсутствуют. Недавно в статье тут же на хабре прочитал про софт-скилл "непрерывное лидерство". Обалдеть...
Господа суетологи, вы бы оставили Айти в покое.
Demiourgos
10.09.2023 16:49+2Господа суетологи, вы бы оставили Айти в покое.
На сайте висит пузомерка зарплат в отрасли. Очевидно, до тех пор, пока этот показатель будет заметно выше среднего по больнице, в айтишечку будет ломиться всякое такое непрерывно прогрессорствующее суетливое лидерство.
dinaveprikova Автор
10.09.2023 16:49Спасибо за комментарии. Очень интересные. Хочу обратить внимание, что наличие прокачанных софт скиллов никак не исключает хард скиллс. Но я часто на интервью встречаю ребят, кто не может объяснить, почему выбрал такое решение, как подходил к выбору, что за продукт или проект был, плывет по течению и не может объяснить, в чем его мотивация, почему работает на текущем проекте, на вопросы отвечает смотрите в резюме, там все написано, и так далее. При этом они наверняка неплохо кодят, но интервьюер не может знать о кандидате то, что сам кандидат знает о себе, только то, что он транслирует интервьюеру. Да и в рабочих ситуациях часто наблюдаю, что порой не хватает личностных качеств для решения каких-то ситуаций. Моя рекомендация - развиваться всесторонне, не только в технологиях и навыках кодинга.
Leetc0deMonkey
10.09.2023 16:49они наверняка неплохо кодят, но интервьюер не может знать о кандидате то, что сам кандидат знает о себе
Это проблемы интервьюера. А рыбак рыбака понимает с полуслова. Язык программиста - код. Я понимаю, вкусные зарплаты манят в айтишечку. Но, имейте совесть, соответствуйте стандартам индустрии программирования, а не лезьте со своим "софтскилловым" уставом в чужой монастырь, просто потому что вам так удобнее.
NurGeo
10.09.2023 16:49"Это проблемы интервьюера.
Совсем нет. Если хотите можем разобрать это.
Вопрос. Почему вы участвуете в интервью на трудоустройство?
LeetcodeMonkey
10.09.2023 16:49Я понимаю, некомпетентность той стороны становится моей проблемой. Но решать её можно по-разному: либо борьбой за повышение компетентности той стороны, либо прогибаться под их некомпетентные хотелки.
И вот, до наступления эпохи набега случайных людей в айти, проблемы поиска специалистов просто не было: в резюме выкладывались навыки и проекты, а интевьюер, тоже специалист, понимал с кем имеет дело. На собесе можно было перекинуться парой слов, просто потому что обе стороны понимали друг друга с полуслова. Сейчас айти с подачи "софтскилловых" продавцов пылесосов превратилось в какую ярмарку тщеславия, где надо уметь продавать себя. Даже работать уметь уже не обязательно, главное уметь продавать себя!
ЗЫ. Забавное как после каждой критики "софтскилловые" наваливают полную панамку в карму. Лицемерные и подлые людишки, непринимающие никакого другого мнения кроме их собственного.
Никогда ещё айти не было таким душным и токсичным как после набега "софтскилловых"!
NurGeo
10.09.2023 16:49Так вопрос был очень простой, но вы не ответили:
Почему вы пришли на интервью на трудоустройство?
Spinoza0
10.09.2023 16:49"Раньше всё было проще: писал код и всё"
Какой временной промежуток имеется ввиду? )
SpiderEkb
10.09.2023 16:49Представь, что ты написал фантастический модуль для программы, но не можешь объяснить своим коллегам или клиенту, как он работает или почему он так важен.
А теперь представь, что ты можешь навешать лапши на уши коллегам и заказчику, но не можешь написать нормальный код...
Общаться с заказчиком вообще не дело разработчика (ну разве что фрилансера или мальчика-на-все-руки в артели "Сукин и Сын"). Для этого в нормальных местах есть специально обученные люди.
Разработчик - он на то и разработчик, что его дело разрабатывать. В первую, вторую и третью очередь. Объяснять заказчику почему он разработал именно так а не иначе вообще бессмысленно. Заказчику это не интересно.
Мир давно уже перешел на стадию разделения труда. Заказчик не должен приходить к разработчику (если у вас это так - у вас серьезные проблемы с организацией производства). Он приходит к специально обученному человеку и выкатывает свои пожелания. Которые потом оформляются виде бизнес-требований, затем уходят к архитекторам где формируется архитектурное решение, потом к аналитикам где формируется ТЗ и вот оно уже попадает к разработчикам.
Максимум софт-скиллов, требуемых от разработчика - умение общаться с себе подобными членами команды и аналитиками. Все. Но это уже после того, что он должен быть профессионалом в своем деле. Мимимшные пустобрехи с софт-скиллами 80lvl но полным отсутствием хардскиллов в разработке напрочь никому не нужны.
NurGeo
10.09.2023 16:49+1Если вы работаете в госсекторе, то возможно вам, вашей команде и само собой вашей организации (это же госсектор, у государства нет конкурента) не грозит опасность.
Но в современном мире коммерции нужно быть гибким, нужно чтобы все люди в компании (не в команде) понимали чего хочет клиент. И хотели ему помочь.
Если ваше дело только код писать, то похоже вы не сможете помочь клиенту. А значит ваша компания в долгосрочной перспективе находится на линии вымирания. Таков сейчас мир.Вопрос в том. Вы хотите быть участником команды которая станет успешной?
Если да, то перечитать статью.
Если нет, то да, дальше пишите код (без сарказма).
Но по секрету скажу, что больше и намного платят спецам из первой группы. Которые не думают что их задача только кодить, а знают что их задача решать проблемы клиента, а значит помогают компании, а значит помогают себе и своему карьерному росту и профессионализму.Статья об этом.
ReDev1L
10.09.2023 16:49+1Чушь, вы даже не понимаете, что есть код который пишут, чтобы другой код работал, а не для клиента. Есть платформенные команды, есть девопсы и другие, которым весь этот бред не интересен, им интересны SLA, DX и премии по итогам SLA и достижения целей. И забивать им голову вот этой чушью, которая лишь оправдывает нахождение в штате человека который не понимает процессы разработки - только лишние расходы для компании которые не дают никакого профита ни для компании, ни для клиента. Зато софт-скилловый HR защищен от уволенения, из-за бурной деятельности по обучению персонала софт-скиллам.
Вы правильно сказали что все в компании должны иметь вижн клиента. Это ответственность CEO, построить правильные процессы, чтобы его/клиента вижн доносился до всех, без испорченного телефона и был доступным для понимания.
Время хороших разработчиков очень дорого, они получают ставку выше чем основатели и директора компаний. По этому не стоит его тратить на митинги, общение с клиентами и тд, для этого есть специально обученные люди. Их время дешевле и они справятся с задачей намного лучше.
Не забывайте про context-switch, это самый большой, не эффективный расход времени. Когда вы 2 часа кодили потом митинг с клиентом на час-два, а потом вам нужно вернуться кодить - разработчик теряет не час-два, а три часа минимум чтобы достичь пиковой продуктивности.
Эта сфера во влиянии логики и денег, вам здесь не дадут инфоцыганить и миссионерить без подкрепленных, логически верных фактов. Факты это не про психологические статьи в интернете и опыт в других сферах. Здесь все иначе и ошибки очень дороги для компаний и их инвесторов.
Upd:
Многие люди думают, что ИТ - токсичен из-за резких высказываний, типа "смотрите резюме" и тд. Но они не задумываются что притворяться экспертом - токсично для ИТ, изображать бурную деятельность - токсично для ИТ, уверенно, софт-скиллово говорить не правильные, бесполезные речи, говорить о том чем не компетентен - токсично для ИТ. Проблема то не в ИТшниках, они делают свою работу, а вы делайте свою и тогда все будет ок.
AirLight
10.09.2023 16:49Я считаю, что основной затык по софтскиллам из-за психологии и надо ходить к психологам.
storoj
Кажется, что в моей практике всё было ровно наоборот.
По-моему, способность видеть корень проблемы и стремление к максимально корректному поведению программы, это исключительно "хард" скилл. "Софт" скилл в 99% использовался для убеждения остальных, что "и так сойдёт".
s207883
Софт-скилл может пригодиться и для защиты правильного, с твоей точки зрения, решения. Иногда команду надо убедить, что твой подход - правильный подход.
JuryPol
Что может быть убедительнее кода? Схемы решения? Предлагаете послушать гуру, которые оперируют понятиями «пропитчить мысль»?
Или образец, к которому нас толкают, это питон Ка с его «Бандерлоги, хорошо ли слышно меня»?
s207883
Есть один код, есть другой код. Мне нравится первый, коллеге - второй. Как убедить коллегу в своей правоте не прибегая к насилию и угрозам?
Nialpe
если оба упёрлись, то никак. у нас, например, для этого есть разработчики (на разных уровнях иерархии) с ролью "техлид", за которыми крайнее для своего уровня решение.
RSM
Что значит - нравится? Цвет более удачный или шрифты посимпатичнее? Если два решения идентичны (что маловероятно иначе в чем тогда спор) то к примеру тот что раньше был закоммичен. В ином случае более корректное, оптимальное и полное решение, и тут уж придется разбираться кто самое слабое звено, но опять же никакие софтскилы не помогут из некорректного решения сделать корректное - но вполне помогут уболтать и пропихнуть некорректное решение в проект. Если же при прочих равных вам принципиально что бы код был отмечен именно вашим авторством, то тогда даже не смотря на наличие прокачанных софтскилов вы как раз и есть не командный игрок :)