Конференция DSE Fest — технично и понятно про data science для разработчиков. Смотри детали на сайте
×Закрыть

Без каких софт скиллов не дорасти до Senior- и Lead-позиций: всё о коммуникациях

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

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

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

Коммуникабельность

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

Эллина Азадова, Senior QA Engineer в DataArt:

«В моей практике было много случаев, когда люди с более развитыми софт скиллами быстрее продвигались по карьерной лестнице. Важно уметь себя преподнести. В человеке может быть огромный потенциал, прекрасные способности к определенному типу работы, но их невозможно рассмотреть, если он будет старательно прятаться. В результате появляются обиды, люди меняют работу или даже общее направление деятельности. Специалист при этом думает: „Мне не дают реализоваться!“

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

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

Ян Гулай, Senior JavaScript Developer в Brightgrove:

«Будьте хорошим собеседником. Согласитесь, не всем хочется работать со скучным роботом. Для этого повышайте свой общий уровень эрудиции, тренируйте разговорный английский. К примеру, с заказчиками можно разговаривать не только о работе и проектах: я болтаю с ними о путешествиях, истории стран, компьютерных играх, автомобилях. Было интересно узнать побольше о жизни „по ту сторону океана“, выборах в США.

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

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

Ольга Когут, BI Developer & Team Lead у Conscensia:

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


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

Арсений Оганов, Lead Solutions Architect в Netcracker:

«Качественное и конструктивное общение зарабатывает вам „плюс в карму“ как человеку и специалисту. А это позволяет в критической ситуации на проекте, когда надо быстро что-то сделать, просто прийти к разработчикам и сказать: „Сделай вот это“ — и не объяснять почему, так как они уже вам доверяют.

Лучшее, что я могу посоветовать — хорошие книги о воспитании детей. Да-да, именно о воспитании детей: там представлены лучшие практики по коммуникациям. Почитайте, к примеру, Гиппенрейтер».

Семен Котляренко, Head of Web Department KeepSolid:

«Без умения коммуницировать ты не сможешь добиваться многих личных и рабочих целей. Вспомнил один недавний кейс: мы разрабатываем новую архитектуру API для одного из продуктов. Есть очереди сообщений, и я предположил, что и другим продуктам будет важно получать эти сообщения, поэтому нужен удобный и безопасный язык общения. Когда я поговорил с разработчиками из других отделов, оказалось, что для них эта проблема не менее актуальна. Мы ее решили с помощью совершенно другого набора инструментов, чем я планировал изначально. Если бы я не коммуницировал с другими отделами, наша система получилась бы не product-friendly для пользователей».

Умение донести свои мысли

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

Павло Годиш, Competency Manager в ELEKS:

«Правильно побудована комунікація дозволяє поглянути на ситуації та речі під іншим кутом, дізнатись, як люди сприймають ту саму інформацію і особливо — дізнатись чого, на їхню думку, від них очікують. Досить поширена помилка — очікувати, що люди з якими ми спілкуємось по роботі, розуміють все самі або ж розуміють це так само, як і ви. Коли потрібно завершити завдання чи проект, важливо, аби всі в команді розуміли, що саме потрібно зробити і як. Не шкодуйте часу на прояснення деталей: це дозволить виконати роботу якісніше і швидше».

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

Елена Белкина, QA Engineer & Internal SoftSkill Trainer в CoreValue:

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

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

После этого новичок или не обращается за помощью, чтобы не дискредитировать себя, боясь показать свою некомпетентность. Либо обращается, но от него отмахиваются фразами типа „Ну, а что тут может быть неясно?!“. Только после неудачной реализации поставленной задачи человек узнаёт о том, какими были санкции. Ничего из этого кейса, кроме ощущения тотальной несправедливости, такой „подопечный“ не вынесет».

Помимо непосредственно информации, важно подобрать правильный тон общения, интонацию, уровень формальности.

Анна Каплун, Senior Test Engineer в Intellias:

«Приходилось ли вам передавать знания новым членам команды? Делать презентацию продукта заказчику? Уточнять какие-то детали в требованиях? Участвовать в тимбилдингах с людьми из разных команд, говорящими на разных языках? Объяснить свою мысль бывает сложно вне зависимости от собеседника и языка, не говоря уже о трудностях-волнениях, сопряжённых с публичными выступлениями. А выбрать правильный тон (то, что называют „register“ в английском) и того труднее: кто-то не приемлет панибратства, а кого-то коробит обилие формальностей. Это тонкая грань, которую очень важно нащупать, особенно в устной речи».

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

Арсений Оганов, Lead Solutions Architect в Netcracker:

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

Ораторское искусство

Для Senior-специалиста важны навыки публичного выступления. К примеру, для внутренних митингов или презентаций продукта заказчикам.

Артур Мироненко, iOS Tech Lead в UPTech:

«Ораторское искусство пригодится не только для участия в конференциях в качестве спикера, а и для презентации клиенту результатов работы. Банальный пример — процесс демок, когда нужно, грубо говоря, отчитываться продакт оунеру о проделанной за неделю работе. Отличный способ прокачать навыки публичного выступления — участвовать во встречах Toastmasters. Ищите возможности выступать перед публикой и просто тренироваться. Проводите в вашей команде внутренние Tech Talks на актуальные темы. Это отличный шанс научиться выступать: непринужденная атмосфера и знакомая публика — соответственно, меньше переживаний».

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

Людмила Федчук, Lead QA Engineer в Wargaming:

«Для того, чтобы красиво говорить, мало прочитать книгу. Важно прочувствовать свои слабые стороны, осознать проблему, поработать над ошибками, избавиться от слов-паразитов (ну, как бы, эээ и тому подобные). У нас был тренинг, на котором надо было выйти перед коллегами и сделать небольшую презентацию на заданную тему. Задача коллег состояла в том, чтоб указать тебе на твои наиболее часто употребляемые слова-паразиты, а твоя задача — заменить их каким-то смешным словом типа „мяу“, „кукареку“. Было мега-сложно и очень смешно, но помогло осознать свои недостатки и поработать над их исправлением».

Конструктивные переговоры

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

Константин Захаров, Solution Architect в EPAM:

«Когда выходишь за пределы middle-level engineer, требования к навыкам коммуникации становятся выше. Теперь вам уже приходится встречаться с более влиятельными участниками процесса, например, с C-level менеджментом (CEO, CTO, CIO, CSO, CFO etc). Во время таких переговоров ставки достаточно высоки, и шанса на ошибку нет. Заранее готовьтесь к таким важным встречам, постоянно совершенствуйте Business English и соблюдайте политкорректность. Не забывайте о невербальной коммуникации — то, как мы выглядим, жестикулируем и какие позы занимаем во время общения».

Владимир Гарбар, Team Lead в HYS Enterprise:

«Вы отвечаете не только за результат, но и за людей и ресурсы, доступные вам. Даже если вы просто разработчик, то как минимум отвечаете за собственное здоровье и возможность эффективно работать дальше — после конца спринта, релиза и любой другой важной даты. Пример даже искать не надо, все через это проходят. Кто хоть раз соглашался с неподъемным объемом работы? А потом овертаймил, жертвовал качеством и тестами и в результате получал молчание со стороны заказчика. Жертвование качеством работы в угоду срокам говорит о неумении договариваться.

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

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

Иван Ушаков, Practice Lead QA в Digicode:

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

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

Діана Пекеліс, Senior QA Engineer в DataArt:

«Мені доводилось працювати із замовником, у якого було декілька офшорних команд, тож я можу із впевненістю сказати, що у комунікаціях із людьми з різних культур важливим є не тільки зміст сказаного чи написаного, але і форма. Наприклад „так“ та „звісно“, які ми часто чули від одних із вендорів нашого замовника, далеко не завжди означали саме це. Щоб порозумітись, ми документували всі рішення, які були прийняті під час розмов і обговорень, і надсилали їх на пошту після завершення зустрічі.

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

Командная игра

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

Сергей Козырев, Mobile Team Lead в Lohika:

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

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

Александр Крачун, Full Stack Developer & Team Lead в Adtelligent:

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

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

Стоит сказать, что получение фидбэка — это также и дополнительная мотивация. Рекомендую прочесть „Мифический человеко-месяц, или как создаются программные системы“ Фредерика Брукса и „Человеческий фактор: успешные проекты и команды“ Тома Демарко и Тимоти Листера».

Менторство

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

Артур Мироненко, iOS Tech Lead в UPTech:

«Важно уметь менторить и учить: каждому Senior-разработчику придется это делать. К примеру, в UPTech я был первым iOS-разработчиком и менторил всех, кто приходил потом — сейчас в нашей команде уже 8 человек. Чтобы менторить других, нужно и самому не стоять на месте, постоянно получать новые знания. Мне очень помог курс Learning how to learn. В нем дельные советы не по тому, как учить, а как учиться и хорошо воспринимать информацию.

Как мне кажется, Senior должен не брать всю власть в коллективе в свои руки, а помогать команде, вдохновлять и учить ее. Самый простой способ научиться этому — отвечать на вопросы на форумах типа Quora, Reddit, Stack Overflow. Это тренирует умение объяснять, а в процессе вы еще лучше понимаете собственный ответ».

Артем Петров, Web department Team Lead в Appus Studio:

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

Эмпатия и эмоциональный интеллект

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

Елена Белкина, QA Engineer & Internal SoftSkill Trainer в CoreValue:

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

Эмпатия — это принятие разнообразия нашего мира. Лучше развивать этот навык с детства, у взрослых людей процесс идёт куда медленнее. Самое элементарное упражнение на развитие эмпатии: просто общайтесь с самыми разными людьми на повседневные темы и не выносите оценочные суждения о собеседнике. Чтобы понимать, что испытывает другой человек, как он видит мир, достаточно принять саму вероятность множественных взглядов на одни и те же вещи — необязательно эти взгляды разделять».

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

Константин Захаров, Solution Architect в EPAM:

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

Что ещё почитать о коммуникациях

См. также:
— Без каких софт скиллов не дорасти до Senior- и Lead-позиций: о личностных качествах
— Без каких софт скиллов не дорасти до Senior- и Lead-позиций: о профессионализме и менеджменте.

LinkedIn

57 комментариев

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

*Serious Mode On*

+100500 к умению формулировать мысли в устном и письменном виде.

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

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

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

*Serious Mode Off*

Прекрасная подборочка «умных бизнес-фраз» для митингов: twitter.com/...​status/976490644544860160

...когда я попаду в ад, это будет выглядеть так: я падаю в котел с кипящей водой, вокруг меня огонь, демоны, крики страдающий людей. Я думаю: «Хмм, а все не так уж плохо». И тут к котлу подходят тысячи HR менеджеры и говорят: «Well, tell me about yourself».

#немоё

Lets setup a meeting at Gradusnik and I’ll tell you (and show) everything you need.

Привет из легендарного треда Харьковфорума

Нужно оставаться Человеком, любить то, что ты делаешь и тянуться к знаниям, и людям) Все остальное красивые слова.

Абсолютно согласен, но достаточно ли этого?

Если можешь вписать коммент на доу который лайкнет 100+ сырников, то с софт скиллами всем просто замечательно)

Не совсем согласен. Умение общаться виртуально и в живую немного разные вещи

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

+ в жизни ты можешь заикаться, а в комментах перлы выдавать на 100 лайков, но толку?

Наверное чувство юмора тоже одна из составляющих софт скиллов.

один хороший знакомый мне как-то сказал «шутить нужно с умными людьми»

Бестолковые шуток не понимают)

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

что за понятие «эмоциональный интеллект»?

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

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

Вот за идиотов щас обидно было ((

Вы, в данный момент, демонстрируете не лучшие свои качества:)

про сарказм слышали?

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

#trollface

Главный софтскилл современного вайти причём не только отечественно это умение политически грамотно обойти и технически нивелировать полную техническую безграмотность «синьора и выше выросшего по карьерной лестнице на софт скиллам» (к) (тм)

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

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

Причем тут сеньйор? Разве не лид/менеджер должен этим заниматься?

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

Фидбек через 1-2-3-6 месяцев абсолютно бесполезен. Если человек напортачил и в чем-то неправ и ваша цель ему помочь — надо говорить сразу. А не через полгода на 1-to-1 когда он пришел за райзом зп: «А помнишь ты когда-то на митинг опоздал...». Тут уже какая-то манипуляция на всех этих наших галерах.

Я разочаровываюсь куда катится ИТ.

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

в вопросе журналиста фигурировала формулировка, какие коммуникативные навыки нужны senior, чтобы вырасти в лида :)

смайлик в конце — некорректен, видимо как и

журналиста

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

Без каких софт скиллов не дорасти до Senior-позиций

vs

какие коммуникативные навыки нужны senior, чтобы вырасти в лида

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

Без каких софт скиллов не дорасти до Senior-позиций

Это заголовок статьи, и где здесь лид? Любой адекватный человек поймет заголовок: Middle -> Senior.

Я сначала еще на этапе черновика написала заголовок

Без каких софт скиллов не дорасти до Senior- и Lead-позиций

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

Update: дополнили заголовок, чтобы не путать читателей

Update: дополнили заголовок, чтобы не путать читателей

прямо в воздухе прямо веет лизанием тех или иных задниц

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

которые уже вменяются senior-у как чуть ли не основной вид его деятельности.

«Так ведь других нет!» (к) (тм)

а если лида номинально нет? кому еще подмешивать? скрам тим, шаред респонсибилитиес, как сейчас модно

Да ты прав, я немного подзабыл про чудеса гибких методологий разработки, ведь любой тестер или менеджер теперь легко полезет смотреть логи на инстансы, дебажить QA/Dev-env и пилить фичи вместо девелопера, пока сеньйор будет чесать языком и эмпатировать.

Я разочаровываюсь куда катится ИТ.

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

Теперь в KeepSolid начинают клонировать Васю, ибо Вася — это эталон работника, который работает работу в государственные праздники:

Семен Котляренко, Head of Web Department KeepSolid:

www.linkedin.com/in/vasiliyivanov

Найдите хоть одно отличие на фото, ну кроме того, что в статье фото круглое, а в линкедине квадратное.

Раз это статья доу автора — то мы требуем подробного объяснения, сего странного феномена братьев близнецов Семёна и Василия. Валентина, объясните пожалуйста ситуацию, вас ввели в заблуждение, если да то кто? Или вы пытаетесь ввести нас в заблуждение?

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

Редакция ДОУ уже разбирается с этой проблемой.

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

Я вот даже не знаю, смеятся или плакать %) Но нотка госстандарта с фото на фоне пыльных жалюзей прослеживпется четко.

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

внесите разнообразие — опишите свое видение

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

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

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

Cопротивление не бесполезно! Ничего не делая — шанса на изменение нет, а что-то делая, он, шанс — может появится.

уж лучше руководствуйтесь другой цитатой — «Истина рождается в диалоге»

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

Возможно так кажется из-за того, что это только первая часть статьи, посвященная именно коммуникации.

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

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

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

Заказчика почти никогда не интересует техническая сложность починки или реализации. Только потенциальная прибыль или убыток от наличия или отсутствия фичи, деленная на стоимость починки/реализации, которую ему должны озвучить ДО начала работ. Абсолютная сложность для него — понятие из другого мира «технических специалистов». Он оперирует только относительной сложностью.
То, что Вы описали — это типичный сценарий «на галерах», где есть разными ухищрениями заарканеный аккаунт, из которого вытряхивают деньги, пост фактум объясняя цифры в инвойсе.
Имхо

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

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

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

Подписаться на комментарии