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

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

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

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

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

Ответственность

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

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

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

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

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

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

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

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

Ирина Попова, Head of Development в Light IT:

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

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

Діма Павлов, Software Tech Lead в Terrasoft:

Окрім технічних знань та навичок, саме «обсяг» відповідальності і відрізняє Junior- та Senioir-спеціалістів. Відповідальність проявляється в тому, що людина максимально ефективно та раціонально використовує наявний ресурс — час. Це стосується багатьох аспектів роботи: активностей, розробки, дизайн-сесій тощо. Наприклад, легковажно прийняте рішення на етапі розробки архітектури може в майбутньому вилитись в сотні годин підтримки реалізованого функціоналу.

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

Андрей Голомоз, Head of Traffic Quality department в Admitad:

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

Павел Свинцицкий, Team Lead в Mobilunity:

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

Инициативность

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

Артем Дурнев, Unity Software Architect в Plarium:

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

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

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

Василий Иванов, СЕО KeepSolid:

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

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

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

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

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

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

Дуже важко дорости до рівня Senior, якщо ви — безініціативний і не маєте сміливості.

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

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

Іван Колодій, СЕО Ukietech та TechLead на проекті TenantCloud:

Ініціативність життєво необхідна, коли ви техлід, тімлід або CTO: вам потрібно підтримувати ритм та високі обороти; впроваджувати нові технології, інструменти, методики; організовувати навчання.

Пам’ятаю, коли я тільки став техлідом на проекті TenantCloud, переді мною стояло питання: залишити все як є і продовжувати розробку на старому стеку або ж переписати практично все з нуля. Це було складне рішення, оскільки потрібно було пояснити стейкхолдерам, що 2-3 місяці не буде нових фіч, і, можливо, буде багато багів :) Зовсім непростий виклик. Однак ми прийняли правильне рішення і переписали все з нуля.

Гибкость

В современном Agile-мире приоритеты часто меняются и надо переключаться между различными задачами. А потому очень важна гибкость в своих реакциях и поведении.

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

Надзвичайно важливим є вміння швидко адаптуватись до змін та інтегруватись в проекти. Я помітила, що Middle-спеціалісти дещо інакше починають роботу над новими для них проектами, ніж Senior. Це стосується в основному різниці в кількості часу, який потрібен для того, щоб перестати панікувати та почати працювати продуктивно. Мені здається, що це в основному пов’язано із широтою поглядів і досвідом, які зазвичай вже є у Senior і яких ще трохи не вистачає на рівні Middle. Поставлене завдання, скоріше за все, буде лякати їх трохи менше — і, відповідно, працювати на повну силу вони почнуть швидше. Це особливо важливо в коротких проектах або MVP, де часу на «розкачку» немає.

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

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

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

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

Внимательность

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

Ирина Попова, Head of Development в Light IT:

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

Андрей Михайлов, CTO, Senior .NET & JavaScript разработчик в Zfort:

Буква «Эс» вместо буквы «Си» в названии класса может привести к дефекту, который обойдется клиенту в 20 миллионов долларов. Пример реальный. Следует соблюдать грамотность в написании даже самых простых слов и фраз.

Честность

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

Тарас Романик, .NET Developer, Tech Lead у Conscensia:

Не знаєш, що сказати, — кажи правду (© моя бабця). Ціна помилки росте експоненціально часу. Тому важливо вміти якнайшвидше визнати власний факап. Мій найлютіший — це помилка при бекапі тисяч файлів, коли 20% бекапу виявилося пошкодженим. Соромно було розповідати, як такий чудовий спеціаліст через тайпо у конфігурації замість реальних файлів назберігав тисячі повідомлень про помилку.

Ціна чесно визнаної помилки — 5 хвилин ганьби, 2 дні для написання фікс-сервісу і кілька місяців роботи самого сервісу. Якби я приховав помилку, її ціною могли б стати судові позови. Якби намагався виправити «непомітно» для замовника, то довелось би овертаймити та порушувати дедлайни по основним завданням.

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

Александр Тарасенко, VAS Team Lead в EVO:

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

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

Еще одна сторона честности — открыто рассказывать о своих сильных сторонах, не скатываясь при этом в хвастовство.

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

Мне кажется, что раз в квартал спрашивая менеджмент: «А когда я получу повышение до тимлида?», человек не делает особого вклада в свою карьеру. Важны действия: подменить тимлида, подстраховать коллегу, сделать что-то, что явно выше ожиданий по проекту. Это действительно ценно, и жаль, что иногда остаётся без должного внимания.

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

Зрелость

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

Андрей Завадский, Engineering Team Lead в Innovecs:

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

Я считаю, что зрелость не зависит от возраста. Она развивается, когда человек, преодолевая какую-то ситуацию, самостоятельно отвечает за свое решение.

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

Критическое самовосприятие дает возможность принимать на себя ответственность или же понимать, что в определённых ситуациях конкретно от тебя ничего не зависит. Чем объективнее человек воспринимает себя, тем менее он уязвим для неконструктивных замечаний в свой адрес. И тем проще ему понимать, какими сильными и слабыми сторонами он располагает. Такой человек дополнительно ищет пути для саморазвития, а не просто принимает себя таким, какой он есть в данный момент времени.

Зрелость — это в том числе и надежность и предсказуемость в хорошем смысле этого слова.

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

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

Что еще почитать о развитии личных навыков:

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

LinkedIn

62 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
Наприклад, буває, що хтось з команди знаходить новий інструмент, який може зробити роботу більш комфортною або цікавою. Але менеджерам може бути не зрозуміло, для чого тратити додатковий час на імплементацію. В результаті інновація відходить в беклог і чекає часів, коли команда буде не завантажена задачами, а таке буває рідко. У цьому випадку лід повинен прийняти рішення про імплементацію і взяти відповідальність на себе. Роль ліда — у всіх проблемах проекту бути щитом для команди.

Згоден. Деколи пропоноване може не тільки зробити роботу комфортнішою і цікавішою, а і скоротити час на розробку і підтримку в майбутньому. Але що робити, якщо менеджмент ліда не перестає бути проти, а коли лід приймає рішення про імплементацію, його потім викликають на коврик? Реальне життя не таке, як у фільмі Coherence, де можна побачити 2 альтернативних розвитки подій і порівняти...

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

Я каждый раз вижу утром в зеркале

Ну себя то мы все любим :) А среди других сотрудников видели? Среди подчиненных? :)))

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

А шо не так?

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

Нічого подібного. Не має значення твої глибокі знання алгоритмів та способів прискорити код, знання фрейморків, блискучий стиль написання коду, якщо ти кодиш все що завгодно, але не те, що потрібно замовнику

Має значення

якщо ти кодиш все

Насяльніка почалу забувати і «забалакувати» суть професії.

Кто вообще такой синьер ? Какие критерии определения этого уровня ? Почему кто то решил что синьер должен общаться с заказчиком или клиентом ? Где унификация этой позиции для той или иной специализации ? Почему сеньер должен кого то учить ? ...... и.т. и т.п....

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

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

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

Типа сами. А если у вас в контракте есть такие регалии — значит в контексте компании вы таковой и есть :)

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

зачем работать на клиента, у которого мало денег?

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

О каких синиорах мы говорим?
В условиях Украины шаги следующие:
1) переучиваемся на программиста из любой несмежной профессии(врач, историк, актер)
2) работаем три года
3) просим лычку сениора
4) profit

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

Я бы выделил Problem Solving скил или некую пробивную силу — способность находить решения задач или проблем, с которыми вы ранее не сталкивались. Львиная доля IT проектов — это разработка ПО под нужды заказчика, который не смог использовать существующий софт. Это значит, что его потребности чем-то отличаются от тех, которые уже решены, а значит команда столкнется с какими-то новыми задачами или их комбинациями. Есть такая аналогия — «ледокол и катерки». Каждый в команде выполняет свою важную роль и время от времени команда будет сталкиваться с проблемами, которые не смогут решить младшие специалисты. Роль синьора — расчищать проектный путь для остальных членов команды.

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

Об этом хотели подробнее в третьей части рассказать :)

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

Три части, следующая будет последней. Там будут примерно такие пункты: ориентация на результат (в том числе problem solving), целостное видение, работа с командой, лидерство, делегирование, people-менеджмент, тайм менеджмент.

Мне иногда кажется, что существует два мира, и из одного в другой так просто не попасть. Один — это там где problem solving, решение задач бизнеса, решение проблем, с которыми вы раньше не сталкивались и всё такое. И другой, в котором требуются программисты с опытом 19 лет в каком-нибудь там amazon marketplace API :)

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

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

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

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

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

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

Умение поддержать разговор с заказчиком — в первой части, где все о коммуникациях: dou.ua/...​oft-skills-for-seniors-1

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

Сарказм это разновидность пассивной агрессии. Чем она лиду поможет?
Другое дело — навык распознания сарказма, плюс понимание отличий сарказма от иронии и просто шуток, которыми иногда пытаются замаскировать невнимательность. Лиду полезно, да.

А «пассивная агрессия» — разновидность оксюморона. [sarcasm]

Согласен. И это не сарказм, так и есть — бездеятельное нападение это оксюморон. Вместо «пассивная» следовало бы использовать «скрытая». Но здесь имеет место быть фразеологизм. Значение которого, по определению, не определяется значением входящих в него слов, взятых по отдельности.

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

Закон Х.Л. Менкена. Кто умеет делать — делает. Кто не умеет — учит. Дополнение Мартина. Кто не может учить — управляет. (к)

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

+1, хотя бывают исключения для так званых superstars.

Есть золотое правило — «Если человек не может обьяснить просто — значит не понимает сути»

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

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

Тобто Ви заперечуєте існування команд, де нема juniors і кожен член — досвідчений спеціаліст, здатний самостійно розбиратися і вирішувати задачі (у межах своєї спеціалізації, звичайно)? ;-)

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

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

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

Неистово плюсую всем вашим комментариям. Более чем в точку. От себя добавлю только что увеличивается требования к дисциплине, практикам GTD, zero-inbox policy, это всё.

9/10 по шкале бесполезности

Можно воспользоваться вышеупомянутым скиллом проактивности и написать, как надо )

Я могу написать об этом и здесь: — «Для продвижения по карьерной лестнице необходимо работать. Много работать.»

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

что повлияло на вашу заниженную оценку?

То что на DOU есть более бесполезные статьи которые и тянут на 10/10.

Ну почему? Для молодежи полезно.

Чем полезно? Тем что для повышения нужно больше работать? Это и без статьи понятно.

Кому-то понятно, кому-то нет. Кто-то не задумывался до этого момента, статья дала повод. Люди разные.

Ті хто не задумувався про це до статті — сама стаття вже нічим не допоможе.

Ахах. Схоже на те, що ви з малеча над тим замислювались ))

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