Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

«Не так важливо, яке завдання, як підхід і ставлення до його виконання». Що визначає сеньйора

Бородате слово Senior викликає жваві суперечки і є джерелом жартів, та все ж майже всі хочуть мати цей префікс. Мовляв, це справа честі.

У статті я спробую розкласти цю личку на елементарні частинки з різних вимірів: з погляду компанії і спеціаліста, ринку та конкретної професійної кар’єри, віку і навичок, технічних умінь і soft skills.

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

Одразу скажу, що там, де сеньйор, там і сеньйорита, а двічі писати всюди мені ліньки :)

Різниця між Junior, Middle та Senior з погляду завдань

Це питання не зовсім про те, для кого завдання. Це означало б перевести фокус з різниці між тайтлами на різницю між завданнями. Можна будь-кого навчити точити олівці, але кому саме призначене завдання заточити олівець — для сеньйора, мідла чи джуна? Важко сказати. Різниця радше в тому, як завдання виконують, наскільки автономно і як розв’язують супутні проблеми в процесі, якщо його дати трьом інженерам різних рівнів.

Щоб не прив’язуватись до складних матерій, скажімо, є завдання на канбан-дошці — приготувати вареники для 5 осіб, бо стейкхолдери дуже хочуть вареників з вишнями. А плита — одна на кілька команд. Тут є і спільні ресурси, які треба зарезервувати (плита), і складний нелінійний процес, і необхідність спланувати якісні та кількісні показники результату (розмір кінцевих порцій, вигляд і смак). Є і дедлайн, бо стейкхолдери голодні.

Ілюстрації Уляни Патоки

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

Мідл щось готував, але не ліпив вареники, а просто варив пельмені з магазину. Він думає, що цих знань досить і приготувати вареники для великої кількості людей не складніше, ніж зварити собі на вечерю пельмені. Мідл блочить себе й команду на незначних проблемах, які через це перетворюються на великі. Наприклад, каже щось на зразок «Дайте мені чітку інструкцію по пунктах, як треба готувати вареники та acceptance criteria», «Я ці вареники за 5 хвилин нароблю», «Ліпити вареники довго й нудно, це проти принципу code reuse, створімо краще робота (фреймворк) для ліплення вареників».

Мідл буде старатись ліпити кожен вареник ідеально, вкладаючи у страву всю душу й нестримну жагу застосування знань і best practices. Як писав Мартін Фаулер про мікросервісну архітектуру вареників, намагатиметься впровадити 12-факторні вареники або зачепиться за цікаву оптимізацію їхньої форми. Поки всі думають, що вареники потроху ліпляться, спробує таки створити фреймворк для цього процесу. Основний результат без зовнішнього контролю — багато рухів наче в правильному напрямку, але робота не робиться. Треба постійно перевіряти, чи спеціаліст витрачає час продуктивно й ефективно.

Мідлу варто часом нагадувати (тут доречне слово «скеровувати», to guide), що треба робити вареники зі слів бабусі, записаних на клаптику паперу, а не переписувати рецепт, поки стейкхолдери мруть з голоду. Що не потрібно писати фреймворки й роботів для умовних 50 вареників. Що наліпити 50 штук абияк, але вчасно — краще, ніж лише 5, які б вони не були ідеальні. Про резервування плити й качалки (shared resources) взагалі не йдеться, як і про оцінювання завдання загалом. Резервування інструментів чи планування часу та розміру майбутніх порцій повністю на відповідальності, наприклад, PM’а.

Загалом мідл зробить так, як треба, переробить, якщо треба, але його не можна залишати із завданням наодинці. Необхідна зовнішня координація.

Сеньйор побачить завдання з виготовлення 5 порцій, зразу оцінюватиме все загалом (top-down) і з кінця (from the deadline). Він уточнить розмір порцій, щоб збагнути обсяг роботи. З’ясує, чи це на раз, чи треба буде готувати вареники регулярно, бо тоді певна автоматизація матиме сенс. Спитає і про плиту і про виключне право на неї, бо знає, що вона буде вкрай необхідна, і ця критична залежність від плити — потенційний ризик. Оцінить завдання загалом і те, чи здатен зробити все вчасно. Якщо ні — скаже, скільки зможе зробити. Напевне, попросить час на оцінювання процесу. Якщо візьме це завдання, піде сам домовлятись за плиту наперед або наголосить, що PM має потурбуватись про це.

Якщо плита недоступна чи зламана або не така, як треба, порушить цю проблему, можливо, навіть завчасно. Якщо немає рецепта — знайде, а що може додумає сам. Попросить час на експериментальне приготування. Ліпитиме вареники власноруч, бо розуміє, що часу на створення роботів і штучний інтелект немає. Всередині процесу сеньйор вже точно знатиме, чи встигає все завершити, і повідомить, якщо ні або якщо виникли проблеми, котрі він не може вирішити самостійно без загрози зриву завдання.

Джун і мідл потребують активної уваги, часто є part of the problem, not part of a solution. Сеньйору не треба зовнішня координація, бо він сам драйвить процес і стає part of the solution. Зазвичай йому потрібна допомога зовні, тільки щоб «пробивати стіни», як-от залучити іншу команду, переламати бюрократію через коліно, пришвидшити відповідь від людини, яка на іншому континенті колупається в носі, поки тут усе горить. Сеньйор не потребує значного контролю від менеджерів, він їм навіть допомагає, але потребує і очікує також допомоги і того підходу, що нині називають servant leadership. І це логічно, бо він розбирається в проблемі глибше, детальніше і краще, ніж будь-який менеджер.

Тут не так важливо, яке завдання, як підхід і ставлення до його виконання, до планування, використання свого і чужого часу.

Що визначає сеньйора

Hard skills vs soft skills

Корисність технічних навичок, або як їх називають hard skills, спеціаліста визначають лише щодо конкретного проєкту чи навіть конкретного завдання.

Пов’язувати будь-які погони вище Middle/Junior тільки з hard skills, тобто технічною експертизою інженера, — короткозорий підхід. Так здебільшого вважають мідли та джуніори. Але таке сприйняття може бути у будь-кого: і сеньйор-інженера, і архітектора, і менеджера, і CTO. Технічні навички — звісно, необхідна складова, але цього недостатньо, щоб бути професіоналом своєї справи.

Senior, Principal, Lead, Architect — всі ці звання вимагають не просто кодити швидше, знати більше фреймворків чи мов і парадигм програмування, а вміти оцінювати й планувати час і ресурси наперед — свої та команди. Що вищий ранг, то більше прогнози мають відповідати реальному стану справ на проєкті й більше малопомітних нюансів враховувати. Володіння конкретною предметною галуззю теж важить багато. Скажімо, знання внутрішніх процесів електронних платежів чи GDPR — це виходить за межі суто технічних інженерних навичок, хоч і не належать до софт скілс.

Хтось може заперечити, що планувати — то справа не розробника, а PM’а, але я відповім, що кожен Senior має бути трошки PM’ом. Планування — спільна відповідальність.

Дехто зауважить, що спілкуватись із замовником його мовою — це робота Product Owner чи Business Analyst або іншого спеціалізованого менеджера. А я відповім, що кожен Senior має бути трохи PO, трохи BA. Спілкування та розуміння — спільна відповідальність.

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

Тому для сеньйора hard skills відходять на другий план, на перший план виходять soft skills. І що сеньйорніший сеньйор (Architect, Principal, Lead etc), то важливіші «м’які навички».

Це особливо очевидно, коли уявити 15 пихатих архітектів із 300 років загального досвіду, які збираються одного дня з топами обговорювати трансформацію компанії. Саме софт скіли, а не спільна вечірка опісля, не дають таким зустрічам перетворитись на беззмістовний базар з потоками матюків.

Володіння завданням

Принцип task ownership тісно пов’язаний з тим, що називають proactiveness. Суть володіння завданням — у відповідальності за драйв його прогресу і доведення до завершення. Для тих, хто знає Inversion of Control, це певною мірою інверсія відповідальності. Девіз тут: Can I do something from my side to make it faster, available, ordered, reserved, unblocked?

Сеньйор не покладається на інших людей, щоб вони надали ресурси, і не перекладає на інших відповідальність за затримки, вирішення блокерів. Це розділяє і власник завдання. У найпростішому випадку він має активно відстежувати процес, вимагати й нагадувати, цікавитись прогресом, можливо, допомогти з реалізацією у межах власних можливостей, а не просто чекати, доки необхідне дадуть. У важких випадках це може бути бізнес-поїздка інженера за океан, щоб швидко розв’язати проблему на місці face-to-face з інженером іншої команди, замовником тощо.

Якщо приземлити це до прикладу з варениками, то резервація плити як зовнішнього необхідного сеньйору ресурсу має бути турботою PM’а, бо це спільні ресурси кількох команд. Реальним прикладом може стати UAT-оточення чи якась спільна «залізяка». Щоб зварити вареники, потрібно отримати виключне право на користування плитою на певний час. Але сеньйор як власник завдання розуміє, що навіть якщо резервування плити — відповідальність когось іншого, то неготові вареники і голодні стейкхолдери — це саме його відповідальність і провал саме його завдання. Він активно буде комунікувати й допомагати розв’язати проблему: вимагати й нагадувати про ті ресурси як PM’у, так і людям, що за них відповідальні. Такий сеньйор легко дасть менеджеру по шиї завчасно (образно, звісно) або самостійно «підніме» питання нагору. У разі, якщо критична проблема доступу до плити довго не вирішується і його вареники під ризиком.

Різновиди сеньйорів

Слово Senior — беззмістовне без контексту, коли відірване від язика, з якого злітає, і коли безвідносне до людини, стосовно якої вживається. Ця личка перевантажена настільки, що можна сперечатись на рівному місці й не розуміти одне одного.

Позичимо трохи ідей із сеньйор-психології, бо це несправжня наука, тому можна робити все, що хочеться, й будувати які завгодно теорії☺

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

По-друге, є власний ідеал чи вектор професіоналізму, може, навіть кілька. Назвемо його Ідеал-Сеньйор. Тут просто — це те, як ви уявляєте справжнє сеньйорство. Порівнюючи себе з колегами, Марком Цукербергом, хакером на цікавій годині CCC чи рок-зіркою на GitHub, чи навіть з хвацькою тьотьою Мотьою, власницею генделика за рогом.

Я-Сеньйор та Ідеал-Сеньйор — результати нашого виховання та навчання, прочитаних книжок, переглянутих роликів у інтернеті, конференцій, спілкування з класними (а може, й ні) спеціалістами. Ці поняття несуть баласт минулого досвіду роботи, досягнень та невдач. Щось у собі можна змінити, а те, що бере коріння в глибокому дитинстві чи темпераменті — ні. Бо це така глибока частина, яка робить нас нами.

Є ще ЯвРезюме-Сеньйор — тобто те, як ви себе описали в резюме.

Люди люблять прикрашати, прибріхувати та відверто брехати в резюме. Що відрізняє справді сеньйора від решти — мінімальна різниця між реальним і написаним. Грубо кажучи, якщо у вас в резюме — Ansible, Terraform чи Infrastructure as a Code, то для сеньйора це означає, що він безпосередньо писав і підтримував той код не один місяць, а не просто робив у власній уяві terraform apply всередині написаного іншою командою автоматичного пайплайну, що магічно запустився, коли він виконав git push, навіть не з консолі, а зі зручної IDE.

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

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

Є ще такі різновиди: Вакансія-Сеньйор, Інтерв’ю-Сеньйор, Позиція-Сеньйор, Щабель-Сеньйор і Зарплата-Сеньйор.

Вакансія-Сеньйор — це просто: введіть власну професію у LinkedIn чи візьміть у HR’а профіль своєї вакансії і порівняйте, чи підходите ви на позицію, на якій уже працюєте. Такий підхід відкрив, на моїй пам’яті, не одну пару невинних очей.

Soft skills здорового порівняння себе з вимогами до своєї роботи — гарний привід для самовдосконалення та подальшого зростання, адже дозу натхнення і розширення свідомості від опису деяких вакансій важко порівняти з будь-якими наркотиками. Шкода, що рідко хто взагалі вдумливо читає ті натхненні тексти.

Інтерв’ю-Сеньйор — це та міфічна людина, яка відстрілює патерни «банди чотирьох», напам’ять знає java-файл класу Object, розкаже все про дюжину методів сортування, вміє рахувати кількість тенісних м’ячів в автобусах, здатна маркером створити з нуля HA-архітектуру багаторівневої системи на білій дошці за 15 хвилин, розказати про багатопотоковість, компілятори чи бази даних краще за її творців. При цьому, звісно, не виступить і крапля поту на чолі; спеціаліст випромінює впевненість, оптимізм та жагу до нових складних завдань саме у вашій компанії! Як елементарні частинки у колайдерах, такі Інтерв’ю-Сеньйори існують лише в колайдерах — тобто на інтерв’ю. Є, звісно, окремі генії, які живуть з енциклопедією в голові, але більшість з нас мають неідеальну пам’ять, та ще й купу турбот у житті, крім бінарних дерев чи тонкостей сортування. Коли це вже 250 разів написано, розжовано й гуглиться за 5 хвилин.

Проблема виникає в ситуаціях, коли вас оцінює людина, яка не може абсолютно збагнути ваші тонкі внутрішні Я-Сеньйор та Ідеал-Сеньйор з ваших слів чи з Резюме-Сеньйора.

Вміти бути Інтерв’ю-Сеньйором і є, до речі, важливим софт скілом. Це вміння продати себе. Не просто свої навички і вміння, а ще й себе як людину, як професіонала, якому можна довірити завдання. Тому сеньйор — це й трошки сейлз, трошки перемовник. Мати підвішений язик, поважати правила гри, знати професійний, та й просто етикет — частина цього процесу.

Позиція-Сеньйор — тут сказати особливо нічого. Так написано у контракті. Єдине додам, що мені (і не тільки) глибоко байдуже, чи написана та личка десь у двох екземплярах. Але є люди, яким це принципово, принаймні в певний період кар’єрного зростання. Це нормально, тут немає нічого поганого.

Щабель-Сеньйор має значення, коли ми зростаємо в певній компанії. Отримати підвищення — завжди чудове досягнення. Оплески, привітання, брендова футболка, більша довіра та відповідальність, часто з надбавкою до компенсації — це приємно. І в тому й суть — це інструмент мотивації, який чомусь мало використовують у тій IT-Україні, яку я знаю. Не буду узагальнювати, бо мав справу лише з аутсорсом.

Можу суб’єктивно порівняти з Німеччиною.

У німецькій компанії 15 і більше інженерних ступенів, якими можна дертись хоч усе життя. Часом ви можете змінювати напрями з технічного на управлінський, хоча нерідко вони паралельні. В Україні достатньо дивна, як на мене, бідна й одноманітна трирівнева кар’єрна градація. Далі вважають нормальним зростання в менеджери (мабуть, це пов’язано з гомогенністю галузі, де всі інженери — більше чи менше взаємозамінні гайки-ресурси).

Щабель-Сеньйор, як і будь-який щабель, — це інструмент мотивації, штучного створення цілком реальних кар’єрних перспектив, інструмент визнання, побудови лояльності, надання більших повноважень і відповідальності тощо. В західних компаніях, які часом старші за найстарших працівників — це потужний мотиваційний фактор.

Уявіть CEO Siemens, який знає про засновників у кращому разі з Вікіпедії, але після 7 років управління такою махиною — це ж довше, ніж навчання в університеті — стає уже незамінним. Хоч, б’юсь об заклад, він і досі час від часу дізнається щось нове про коника, якого осідлав. Або уявіть працівника, який працює у конкретному відділі техзабезпечення банку не один десяток років, здійснив не одну міграцію критичного модуля і досить агресивно ставиться до всіх ваших «контейнерів», «кубернетісів» і «клаудів». Такі люди та їхні знання справді неймовірно цінні. І компанії створюють умови для визнання їх серед інших співробітників. Наголошую, ці умови — штучно створені, але бенефіт від прогресу в кар’єрі цілком реальний. Цікаво дізнатись, чи є приклади з українських реалій. Напишіть у коментарях!

Будь-який щабель, як і власне Щабель-Сеньор, може не відповідати своєму рівню за технічними навичками, та й навичками взагалі. Принцип Пітера — саме про щаблі. І зіставити Щабель-Сеньйора та власне людину можна лише за досить довгого періоду роботи з нею в конкретній команді або за детального розбору минулих проєктів.

Як сеньйор ви маєте бути трохи кар’єристом і трохи знавцем office politics, мусите мати хоч дрібку професійних амбіцій. Просто тому, що у середовищі, де всі сеньйори, ніхто особливо не сеньйор ☺ А такий соціальний еквілібріум довго не існує.

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

Іншими словами, в Німеччині наступний тайтл дадуть дуже не скоро, за плідну роботу й очевидні досягнення або як зростання в кар’єрі. В Україні це як університетський диплом, заздалегідь очікуване людиною визнання, що вона щось вивчила і щось може зробити чи пропрацювала в певній вузькій галузі 4-5 років.

Загалом у Німеччині нормально перейти в іншу компанію, і в личці не буде більше ні слова Senior чи особливого тайтла. Наприклад, із Senior Software Developer перейти на Software Developer і заробляти навіть більше. Не можу сказати те саме про Україну, хоча минуло багато часу, тому можу помилятись.

В обох країнах покладатись на слово Senior в резюме — досить необачно.

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

Це особливо має бути зрозуміло в нинішню кризу і особливо тим, хто пережив кризу 2008-го. Ще й в Україні, де звільнити чи знизити зарплату будь-якого супер-пупер-сеньйортяжа, який би він не був неоціненний учора — раз плюнути, через відсутність механізмів соціального захисту, про який я писав у попередній статті про податки. У Німеччині з цим трохи краще, але соціальні механізми не здатні контролювати погоду: вони пом’якшують і розтягують біль від економічних процесів у періоди кризи, але не скасовують їх.

Певною мірою ми маємо змогу вибирати: піти в недофінансований цікавий стартап чи в забезпечену грошима нуднувату велику компанію. Трапляються забезпечені стартапи й недофінансовані нудні великі компанії. Але це вибір у невеликих межах.

Зарплата залежить і від вміння вести перемовини й того, чи маєте ви дефіцитні навички для конкретної позиції. Але чи здатні ви побачити й використати сильну позицію в процесі salary negotiations — теж залежить від вас.

Тут варто лише зазначити: не майте жодного сумніву, що HR-відділ будь-якої середньої чи великої компанії має незрівнянно більше досвіду в зарплатних перемовинах та обізнаний з ринком набагато краще за будь-якого окремого інженера.

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

Огляд підходів до визначення сеньйорів

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

Ковтун єдиний згадав концепцію T-shaped та підкреслив надмірний фокус середнього українського фахівця на технічних навичках, з чим я повністю згоден. Не зовсім погоджуюся з його фільтром «про 8 років досвіду» і фільтром «за 30», але певен, автор і не мав на увазі застосовувати ці критерії сліпо, а радше орієнтовно.

Кагановський, своєю чергою, зазначив дещо важливе: Senior досить легко переходить в іншу галузь і водночас швидко відновлює продуктивність. Я б сказав, що це не просто через досвід, а саме через софт скіли. Коли у мене був би вибір найняти сеньйора з суміжної галузі, чи джуна/мідла з потрібної — я схилявся б до першого варіанта. Звісно, такий сеньйор справді має демонструвати бажання і потенціал до переходу, та й інтерв’ю в нього було б зовсім не з простих.

Він також навів приклад «сеньйорів», що претендують на високу зарплату, коли не здатні пояснити щось базове, і цей досвід я з ним поділяю. У світі DevOps модно бути YAML-програмістом і не вміти порахувати IP-мережі чи пояснити SSL. А у світі розробки немало спеціалістів, які запросто напишуть контролер у наявному коді, але не здатні перемножити дві матриці чи створити з нуля структуру проєкту.

Загалом не згоден про більшу зрілість західних розробників. Мій досвід свідчить, що це не так. Хоч увага до софт скілів на Заході — це частина професійного зростання з самого початку, це не дає їм перевагу в тому, що вкладається у слово «зрілість». Проте софт скіли — таки велика частина цього поняття. Саме люди з прокачаними «м’якими навичками» обганяють простих технічних пролетарів у кар’єрі.

Також Кагановський єдиний, хто згадав work-life balance. Професіонал, що себе цінує, завжди дбає про це і працює для того, щоб жити, а не навпаки. Senior’у не вийде нахрапом нав’язати нічні зміни чи овертайми і при цьому не втратити його назавжди. Не всі компанії це розуміють.

Неприємно читати базарні коментарі про СТО, але приємно, що є розумні відгуки. Створилося враження, що в Україні до кінця не визріло розуміння, що за створіння цей сеньйор, навіщо він і що з ним робити, не тільки серед сеньйорів, а й серед управлінців. Проте ми рухаємося в правильному, на мій погляд, напрямку.

У тій статті також згадували про менторство. Думки в коментарях розділились, але здатність бути ментором і здатність бути в ролі ситуативного trainee — це окремий важливий софт скіл. Тут мова не про onboarding і не про джуніорів. Це радше навичка вчитися у всіх і навчати всіх — те, що ще називають knowledge sharing.

Очікування і реальність

Senior = Soft skills, помножені на T-shaped individual

Думаю, загалом люди як на Заході, так і в Україні, не поділяють чи не усвідомлюють цю формулу, а «гарячий» ринок дає певне хибне враження, що личка в резюме щось означає. Title does not entitle.

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

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

Хтось інтуїтивно відчуває це й професійно працює джуніором у 20, комусь і в 40 доводиться пояснювати певні речі. Що, скажімо, сексизм — це непрофесійно у професійному житті. Або що треба активно проговорювати проблеми, а не приховувати їх. Тут варто сказати, що лікувати той же сексизм в особистому світогляді чи виховувати дорослих людей — теж непрофесійно, бо не треба лізти в особисте або намагатись перевиховати уже сформовану особистість, якщо у вас не дуже близькі стосунки. Дарма я зачепився за сексизм як приклад, тому поставлю тут крапку.

Є ще чудове слово — «поміркованість». Мабуть, це я і вкладаю в слово «зрілість». Якщо мідл ще має бажання поекспериментувати з новими речами прямо на проєкті, бо десь в інтернеті цікаве написали, то Senior — поміркований інженер, який знайде баланс між новим підходом і підтримкою наявного в робочому стані. Ця поміркованість — стандартний modus operandi. Сеньйор теж багато експериментує, але при цьому не кидає свою компанію під автобус.

Тому технічна експертиза тут відходить дещо на другий план.

Для мене основні критерії Senior — це наявність софт скілів. Серед іншого неназваного і забутого:

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

Якщо відштовхуватись від понять soft values чи синергія, то Senior — абсолютно чітко має додавати soft values в команду, а не створювати нові командні, процесні чи корпоративні проблеми.

Як оцінювати і визначати Seniors: власний досвід

Інколи на етапі скринінгу резюме бувають випадки, коли класним кандидатам відмовляють через неякісні резюме. Кілька тижнів тому переглядав теку з такими і натрапив на абсолютно паршиво відформатоване резюме чудового олдскульного хакера із 30-річним досвідом. Підготовка резюме — теж важливо. Часом відмови відверто суб’єктивні. Це, на жаль, реальність, на яку доросла людина має зважати.

Якщо дійшло до співбесід, то відбір може закінчитися, якщо йдеться про клінічні варіанти брехні. Зазвичай я даю людині змогу самій сказати, в чому вона сильна, а тоді ставлю з цієї сфери питання. Брехня тут, на жаль, трапляється частіше, ніж хотілося б. Я з усмішкою ввічливо запитую далі, навіть підбадьорюю, але вже знаю, що цього кандидата побачу востаннє в житті. Єдине, що врятує орла — це зворотне питання, що я думаю про його відповідь. Такі, на жаль, рідко задають.

З боку DevOps чи Infrastructure часто трапляється, що кандидати, які знають AWS чи GCP (навіть з не одним сертифікатом), не можуть відповісти на базові речі типу обрахунку IP-адрес. Або мережеві інженери-сеньйори, які ніколи не робили фейловер роутера чи не знають, що таке spine-leaf, RSTP, LACP чи MC-LAG. Це якийсь феномен епохи хмарних технологій.

Щодо hard skills, то цього року мав цікаву співбесіду з кандидатом на Lead Infrastructure Engineer, убивцею процесів:

  • Can you explain what is OOM killer and how it works?
  • I can, I was killing processes 9 years, you need to use kill command

Стосовно розробки, пригадую, якось я писав тестове завдання для друга на Android-позицію, бо він не знав, як порахувати суму елементів матриці по діагоналі. Довелось усе розжувати. Він щиро здивувався, що на роботі йому треба знати таку математику, і тут певною мірою мав слушність. Це до слова про західних інженерів — він німець.

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

Розчаровує, коли сліпо транслюють best practices чи hype: клауд краще, ніж онсайт, контейнери краще за віртуалки, копіпейст — це зло, YAML кращий за JSON, а JSON кращий за XML, а ось Фаулер сказав, що мікросервіси... тощо.

Сумно, коли Seniorи-погані-танцюристи приходять на проєкт і наступного дня починають жалітись, що все зроблено не так, усе паршиво і що їм не створили умови для плідної роботи.

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

Розчаровують і PM’и, які не можуть визначити реальний час та ідеальний, не враховують фінансові витрати у плануваннях чи ставляться до людей як до бездушних ресурсів. Засмучує стабільна тенденція приписувати досягнення команди з 20 лобастих інженерів собі, а ще пошук крайніх. Я не професійний PM, але певне уявлення маю, бо мушу.

Як привабити і втримати сильного фахівця в компанії

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

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

Loyalty is a two-way street, мені подобається думати про себе і компанію як про рівних незалежних агентів. І саме на основі конкретної лояльності компанії як машини до мене як гвинтика я будую свою лояльність до неї. І з часом природно починаю почуватися її частиною. Хоча треба завжди мати на увазі, що ці відносини в більшості аспектів асиметричні, і асиметрія тут не на користь працівника.

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

Часто кажуть, що люди приходять в компанію, а йдуть від менеджерів, але я не згоден. Йти з болем треба і від хороших менеджерів, якщо вони на пару з вами працюють у поганій компанії, і від поганих менеджерів, навіть якщо вони — в хорошій.

Лояльність — тема цікава, сподіваюсь топи українських компаній напишуть, how they understand and execute this concept from their side ;)

Отже, хто такий Senior

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

На моїй пам’яті було всіляке. І якщо звернутись до бородатого жарту, то серед іншого мене не дивують ані 23-річні сеньйори (у мене був класний молодий британець на одному з проєктів), ані 60-річні джуніори (класний старий канадець, який на пенсії вивчив iOS на іншому проєкті). Хоча це винятки, тому 23-річні сеньйори все одно мають викликати підозру.

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

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

Ще наприкінці статті автор згадує дві системи спортивної самооцінки, і раджу взяти це на озброєння. Так вийшло, що саме «повсякденна» в мене змалку в порядку і з дитинства вектор був правильний. Може, саме тому мені завжди було начхати, яка в мене личка, як мене хтось називає, в кого яка особиста думка про мою роботу, якщо я сам знаю, що більше зробити не міг. «Змагальна», думаю, — це трохи перебільшення. Для спорту, мабуть, підходить, але для командних інженерних проєктів може бути шкідливо. Раджу «освоїти» «повсякденну» самооцінку усім, але вибір за вами.


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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось6
До обраногоВ обраному26
LinkedIn

Схожі статті




98 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
Хтось може заперечити, що планувати — то справа не розробника, а PM’а, але я відповім, що кожен Senior має бути трошки PM’ом. Планування — спільна відповідальність.

Дехто зауважить, що спілкуватись із замовником його мовою — це робота Product Owner чи Business Analyst або іншого спеціалізованого менеджера. А я відповім, що кожен Senior має бути трохи PO, трохи BA. Спілкування та розуміння — спільна відповідальність.

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

Sorry for comment not in Ukrainian. Writing from family PC where Windows decided a couple of months ago that keyboard layouts are not an essential part of functionality LOL ))

Had mixed feelings about hard vs soft skills. I remember times when I referenced to soft skills as more important, maybe just masking my own gaps in some engineering aspects. And I saw such kind of comments below. But I believe that people who left such comments are missing an important detail. And this detail is that equation looks like this: hard * soft, effectively concluding that if any of them (hard or soft) equals zero, overall result equals zero as well. What I’m actually trying to say is that IMHO it is an essential exercise in personal growth to estimate and reassess own level of hard and soft skills. And regarding indicators... if you do believe that author is telling BS regarding importance of soft skills, you better improve these. And vice versa, if you 100% sure that “soft skills rulezzz!” I suggest you spending some time doing coding/problem solving exercises.

Long story short: listen to your thoughts regarding what you do not agree with. That might be your best area for development in the nearest future.

Про нуль чудове доповнення, краще не сказати, дякую

Нет сил как теперь хочется вареников навернуть!

Сам тепер думаю, що ж його робить :) Доведеться себе побалувати :D

Немає сіньйорної настки (в більшості випадків). Часто джун може зробити певну таску не гірше, а то і краще за сіньора.
Об’єктивно, між ними різниця в зарплаті. Якщо ти отримуєш зарплату сіньйора — ти сіньйор )

Зрозуміти таску — теж завдання, яке може бути важчим. Якщо прив’язатися до статті — не всі стейкхолдери будуть їсти манти чи галушки, як результат роботи джуна з готування вареників :)

Классная статья, спасибо :)

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

Згоден.

А мені якраз було цікаво, які софт скіли хочуть українські компанії. Розкажете?

А тут дуже цікаво, бо в мене в червні були співбесіди на різні проекти. Майже нічого не питали по софт скілам, тільки хард скіли.

Тут у вас в статье терминологическая неувязочка нарисовалась.

Корисність технічних навичок, або як їх називають hard skills, спеціаліста визначають лише щодо конкретного проєкту чи навіть конкретного завдання.

Увы но нет. Problem solving skill — хардскилл, не поверите, но именно он описывает то насколько вы хороший инженер для каких — то абстрактных, отвлечённых задач в вакууме. Этот перк очень полезен и он как раз таки тренируется в процессе работы, и он полезен во всём о чём вы дальше пишете.


Пов’язувати будь-які погони вище Middle/Junior тільки з hard skills, тобто технічною експертизою інженера, — короткозорий підхід. Так здебільшого вважають мідли та джуніори. Але таке сприйняття може бути у будь-кого: і сеньйор-інженера, і архітектора, і менеджера, і CTO. Технічні навички — звісно, необхідна складова, але цього недостатньо, щоб бути професіоналом своєї справи.

Пассаж очень обтекаемый но не очень смыслоёмкий.


Senior, Principal, Lead, Architect — всі ці звання вимагають не просто кодити швидше, знати більше фреймворків чи мов і парадигм програмування, а вміти оцінювати й планувати час і ресурси наперед — свої та команди.

Увы, бухгалтерия и составление сметы это точно такой же техскил как и скажем, написание крудов на спринге. Берем нормальное распределение, моделируем им каждую составляющую, всё складываем, и дальше начинаем курочить техзадание так чтобы шанс сорвать срок был < 0.05.


знати більше фреймворків чи мов і парадигм програмування

некоторые парадигмы программирования приучают и развивают навыки к более менее чёткому и строгому построению модели проекта хотя бы в голове. Это очень сильно влияет на предыдущий скил.


Хтось може заперечити, що планувати — то справа не розробника, а PM’а, але я відповім, що кожен Senior має бути трошки PM’ом. Планування — спільна відповідальність.

PM не может напланировать ничего кроме воздушного замка, потому что он не знает технической стороны вопроса(роль не подразумевает), реальный замок планирует синьор-помидор или главный архитектор.

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

Про остальное пожалуй промолчу, потому что очень много всего.

Я не зовсім розумію, де ви знайшли про бухгалтерію

Контекст статті — IT, hard skills зі статті — технічні інженерні навички, для іншої професії звісно вони можуть бути не інженерними.

Problem solving skills — досить нечітке поняття, не згоден, що це хард-скіл абсолютно, але можна сперечатись в залежності від того, що ви в нього вкладаєте. Те що він має бути — ну це я думав, очевидно

это работа с людьми таким образом чтобы они делали что надо

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

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

Наші уявлення про софт-скіли не збігаются, але дякую за відгук все ж

Я не зовсім розумію, де ви знайшли про бухгалтерію

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

Problem solving skills

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

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

 Люди это не ресурсы, но вы торгуете их временные ресурсы на средcтва, так вот цена по которой вы их продаете/покупаете и есть софтскилл.

Вміння працювати з такими людьми певний час — далеко від

Почему же, при подстановке такой образ := не травил команду и делал свое дело до тех пор пока необходим всё становится на место.

Я зовсім не тільки про вартість проекту мав на увазі

вашем новоязе

Я не коментую на базарі

Щасти вам, дякую за втрачений час

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

Дякую за приємні слова! Soft-skills — справді must-have на мій погляд. І розуміння це прийшло досить недавно насправді — всього кілька років тому, на 15-ому році проф-роботи, і то тому що працював з людьми, які важливість їх підкреслили мені неодноразово. Відтоді я працюю з людьми, а комп’ютери викроистовую в цій роботі, а раніше було навпаки :)

Якщо ще й візаві поводиться професійно й ви розумієте один одного й відмови й проблеми без слів — то взагалі вести справи перетворюється на суцільне задоволення для обох

Гарного вечора і успіху!

Почав писати цей текст як коментар до статті,

Добрий вийшов комент до тої статті :)

Цікаво, techrocks.ru перекладуть?
вони зазвичай цікаві статті з доу публікують у себе. звісно з посиланням на оригінал.

Це був не стільки коментар, як внесок в статтю, просто вийшло справді забагато, а стаття вийшла взагалі довжелезна, талант мабуть до довгих текстів

Дякую за відгук

Не дразните айтишников варениками!
Им и так их не хватает)))

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

А весь словоблуд про софтскілки це лише бонус до технічного рівня, а не основа.

мідли так і вважають :)

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

Ну я зрозумів)) Всі хто з тобою не згідні то мідли)))
Давай я придумаю цікавіший світ і всі хто не згодні зі мною то джуни))) Як тобі такий лакмусовий папірець?)))
Так як технічний рівень джуна зазвичай придатний лише для фарбування огорожі, то вони часто намагються побудувати собі уявний світ де хард скіли не головне і де вони є солюшн архітекторами завдяки своїм софт скілам))) Це спосіб мислення джуна)))

Ну я зрозумів)) Всі хто з тобою не згідні то мідли)))

не зрозуміли і тут

Давай я придумаю цікавіший світ і всі хто не згодні зі мною то джуни

о, це цікаво!
давайте — придумайте критерії по яких вийде що хто не згоден з вами — джуни

зможете? ;)
я думаю що навряд чи.
бо термін «словоблуд» вживають зазвичай люди з дуже обмеженною фантазією.

ви звісно не такий, і не базікало — зможете!

давайте, цікаво!

Складнувато з джунами)))
Не згода зі мною потребує ще додаткових критерів оцінки? Тобто ти не помітив тут ситуацію з двом опціями ТАК чи НІ?))))
Джуни словоблуди вішають собі лички завдяки маленьким канторам)))

Не згода зі мною потребує ще додаткових критерів оцінки?

то світ буде чи ні?

ніхто вас за язика не тягнгув з

Давай я придумаю цікавіший світ

давайте!

Джуни словоблуди вішають собі лички завдяки маленьким канторам)))

тобто сіньори бувають тільки у великих конторах? ;)
де повно просто політики виживання, знайомств с керівництвом, а роботу є кому робити.
і звісно собі її записати.

давайте цікавий світ, а не реальний

Чувак, я бачу ти взагалі не розумієш що я пишу, вступати в дискусію на тему чому земля квадратна, бо вітер дує на північ і трава зелена, не буду. Переосмисли мною написане для початку))
Щодо того хто такий сіньйор, буде показово спочатку зрозуміти як таку позицію визначають у великих компаніях які працюють з серйозними проектами. Після цього все стане на свої місця. А в канторках де пишуть сайти на коліні можливо дійсно головне не головою працювати а язиком ляпати)))) Людина яка прцювала у своєму житті хоч раз над складним та серйонзним проектом ніколи в житті не скаже, що софт скіл головніший за хардскіл)))

тобто — світу цікавого що обіцяли — не зможете створити :)

Людина яка працювала у своєму житті хоч раз над складним та серйонзним проектом ніколи в житті не скаже, що софт скіл головніший за хардскіл)))

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

людина що працювала у великих та складних проектах знає що такє «peopleware»
того може не знати фрілансер що робить все сам.
та мідл :)

Після цього все стане на свої місця.

статті на тему — хто такий сіньор — лакмусовий папірець :)

мідли в них читають наприклад:

що софт скіл головніший за хардскіл)))

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

Шкода часу для відповіді на цей словоблуд. Джуну якому дали личку в канторці не здатен осягнути базових понять))) Ти хоч раз пробував попасти на серйозний проект у потужну фірму? Ото ж бо й воно))) Спробуй))) Після цього розплачешся і перестанеш писати опуси про софтскіли)))

Джуну якому дали личку в канторці не здатен осягнути базових понять)))

базове поняття що у цій статті, що в інших, то

досвідчний, реальний мідл + софт скіл = сіньор.

але так, ви того не помітили.

Ти хоч раз пробував попасти на серйозний проект у потужну фірму?

Сперва добейся?
ох вже ці демагоги :)

і перестанеш писати опуси про софтскіли)))

ви навіть не знаєте що це пишеться роками у інтернетах, та й англомовних теж?

серьйозний ви дядько!

Після цього розплачешся

тобто ви не тільки базікало, демагог, та ще й телепат :D
ну то як завжди, зазвичай такий комплект.

світ цікавий — де?

Я думаю, ви не вловили суть, яку я намагався донести

Софт-скіли — не заміна технічних вмінь, це необхідний додаток

T-shaped oзначає глибоку спеціалізацію хоча б в одній області.
Раджу почитати про цю концепцію

Залишу вашу думку про мене на вашій совісті :)

Дякую за відгук

@oleksiy.khilkevich

Раджу почати зі статті Юрія Савки

Виправте будь ласка посилання на статтю — dou.ua/...​assessment-of-programmer%5D/

Інколи на етапі скринінгу резюме бувають випадки, коли класним кандидатам відмовляють через неякісні резюме. Кілька тижнів тому переглядав теку з такими і натрапив на абсолютно паршиво відформатоване резюме чудового олдскульного хакера із 30-річним досвідом. Підготовка резюме — теж важливо. Часом відмови відверто суб’єктивні. Це, на жаль, реальність, на яку доросла людина має зважати.

ИМХО вся статья ооочень субьективная, особенно глядя на такие посылы...

А что не так? Может инженер на форматирование даже не обратит внимание, но я так понимаю в данном случае резюме отсеяли еще на этапе просмотра HR/рекрутерами.

Ну как бы HR/рекрутер не будет работать с проектом, задачами, они возьмут нарботу очередного «красивого», «оформленного», с которым прийдется мирится «проекту», это и есть «не так», причина такого оформелния может быть масса, от банального неумения оформить «красиво», до «субьективного красиво», то есть кто то — кто имеет власть принимать решения, принимает их вот так, а потом проект и команда эти решения разгребает. Говорю это как человек которые уже даже не 10 раз с подобным подходом стокнулся, а грабли все теже — самодуры решают кому и что как делать, хотя по фактку жить с этими решениями людям, к котормым самодуры имеют отдаленное отношение и понимание.

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

Меня не удивляет. меня в очередной раз расстраивает и злит.

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

Обьясните мне, как HR может знать — что нужно инженеру, если только инженер не учавствет в найме — ему то в итоге работать ?

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

Что с этим делать? Вариантов несколько:
1. Инженер составляет подробное описание вакансии с теми скиллами которые нужны и дает четкую установку рекрутером что если по скиллам (желательно указать приоритет скиллов) в резюме человек подходит, то это резюме сразу передавать на рассмотрение и инженеру не обращая внимание на форматировани и фотку кандидата с пивом на пляже.
2. Инженер договаривается с рекрутерами о том что вообще все резюме которые приходят на данную вакансию оправляются ему напрямую (стоит учесть что в этом случае процесс ревью может знять очень много времени инженера — чтобы этого избежать как раз и нужен этап ревью резюме самими рекрутерами)
3. Если проблема с отсеиванием хороших спецов хроническая и происходит в компании или на проекте постоянно, инженер поднимает вопрос со своим менеджером и через него запускает пересмотр процесса найма, предлагая варианты которые сделают его более эффективным.

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

Как по мне — это таки повод, назвать субьективной и с большим кол-вом современных штампов, как то — важность и первоочередность софт. скилов, опрятность резюме... Это как я уже писал — приводит к ошибкам на проекте, отсутствии хорошей тех. эксперитзы, да и откуда ей взяться, если я должен отслеживать и развивать софт. скиллы, управленческие навыки, вместо тех. скиллов ? Ваше описение найма, это почти идеальный вариант, который как мы знаем нереален в условиях не только местного IT рынка, но и во многих других странах. На данный момент мне пришло 3 предложения о работе, банально одни и те же ошибки, самая распостраненная:
— Cloud providers: AWS, GC, Azure.
— Programming languages: bash, python, powershell.
Спрашиваешь — так с чем же прийдется работать, или у вас реально крутой проект и мультиклауд ? Ответ — на тех. собеседовании вам все расскажут. Это не бред ? Имхо бред — до тех. собеса мне надо понимать надо оно мне или нет, Azure у меня нигде в профиле нет, я не работаю с MS стеком, а мне предлагают пройти пару бесед с HR и PM, а если они решат что все ОК, допускают до тех. собеса, при этом внятно не могут сказать с чем работать и над чем....
О чем это говорит мне — о том, что в компании бардак, нет вертикали управления, нет обратной связи, HR ответственный за найм, не понимает кого ей искать, описание вакансии ей составили непонятно кто, как и почему. Почему то, мне кажется что и описанные в статье практики, это из той же области. 8 страниц резюме, криво написанного, это или криво было составленно требование к вакансии, или же накидали что то такое — что человек клюнул, а следом его послали. Опять же — это дикий субьектиівный подход. Не так уж и много технарей, которые будут уровня, озвученного, автором в статье. Даже если криво и правша написал левой рукой карандошом, это не повод выкинуть, так как по преподнесенной информации накладывается вывод — что вакансия не из разряда «ищем php джуна на минималках», думается, что, искали серьезного человека, а так ли он реально нужен был ?

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

первоочередность софт. скилов

Покажите, пожалуйста, где в статье утверждается первоочередность софт скиллов. Я в статье вижу что и тех. скиллы, и софт скиллы — это must have для синьора. Я не понимаю почему вы пытаетесь переложить проблемы HR отдела на автора статьи.

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

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

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

Покажите, пожалуйста, где в статье утверждается первоочередность софт скиллов. Я в статье вижу что и тех. скиллы, и софт скиллы — это must have для синьора. Я не понимаю почему вы пытаетесь переложить проблемы HR отдела на автора статьи.
Для мене основні критерії Senior — це наявність софт скілів. Серед іншого неназваного і забутого:

Основной критерий — это как по мне и есть синоним первоочередност, тут не говорится про два основных критерия, или три... Просто автор статьи таким подходом старается убить двух зайце3в — нанять топ технаря и топ менеджера в одном лице, на позицию синьер.
Я не пытаюсь переложить пробемы HR на автора статьи, автор статьи делает, как по мне и это не только мое мнение — очень спорные завления. Отсюда и наш с вами диалог. Выкидываение резюме, личные требования к тех. спецу, которые больше идут уже не синьер уровню, а лиду или менеджеру проекту. Мы начали с вами с одного пунтка (резюме), подключили второй пункт (первоочередность софт. скиллов). Оба пункта не лучшим образом характеризуют статью и подход автора, я уже говорил почему. HR в данной ситуации уже второстепенное, если только автор не HR, а он судя по всему управляющий (Шеф — как он сам себя обозначил), что опять же подтверждает мое виденье — управленцу, в найме нельзя давать вожжи в руки, потом проект будет стрдать, команда мучится и потом на dou появятся статьи про токсичных людей.

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

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

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

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

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

Нет не злюсь — после такой просьбы диалог заканчивается, либо «могу ли я получить ваш контакт и передать тех. лиду проекта, он с вами свяжется и расскажет подробнее». За эту неделю — как я уже говорил поступило три предложения, одно на 100% получение контактов на Джинне, вели диалог пока я не дал свои контакты, сейчас профиль HR неактивен уже, как результат и компания и HR в бан идут, это уже не первый десяток раз, когда тратишь время, а тебе болт. На линкедин предложение — третьи сутки жду ответ на запрос, который HR одной компании сама инициировала, что с ней делать ? До этого та же ситуация — запрос, беседа и 2 недели молчания, хотя все эти люди «онлайн» или «были онлайн», уже после нашего общения. КОгда это 1 раз, да — может что то случилось, когда это система — это показатель уровня и HR и компании. которая не ведет контроль за работой HR и рекрутеров в целом.

PS Мы с вами сьехали в диалоге от «моментов» в статье, на косяки HR.

Основна нитка твоїх міркувань — «якщо класний техспец, то на решту закриють очі»

Це не так зовсім, і в першу чергу, тому що компанія, яка не вчора створена, і не гаражний кіоск-одноденка, шукає людей не просто бойскаута-спеціалістів, а ще й які підходять менеджеру, підходять в команду

Весь процес найму — суб’єктивний від початку до кінця, і інтерв’ю взагалі — це не виключно тест твоїх технічних вмінь, а ще й СУБ’ЄКТИВНЕ оцінювання тебе як potential fit. Такі люди — суб’єктивні створіння вони.

Воно може бути трошки й об’єктивне, коли кілька відгуків зважують, але все одно відносно найму в конкретний проект. Тобто це все одно не універсальна об’єктивна оцінка.

Можеш скільки завгодно писати, що це несправедливо, суб’єктивно, ідіотьськи, шкодить команді, яка реджектить «класних» спеців, що вони — самодури. Це приблизно так само, як погасити сонце, закривши долонями очі.

Так, можливо, в гарні часи, коли на вакансію — 0.1 кандидитів, будуть брати й перебирати всіх, а в інші часи — будуть відсіювати без емоцій зі швидкістю кандидат в секунду. І тоді все грає роль — якість, охайність, відсутність дірок в роботі, диплом, навіть кавер-леттер, навіть те, як ти сів на сілець і як привітався

Знову ж таки, навіть у гарні часи — конкуренція на деякі позиції висока.
Навіть у гарні часи — є компаніїї, для яких твої софт-скіли важливіші за кількість твоїх років на Scala. І чим більш відома компанія, тим туди більше хочуть, і тим більше це грає проти тебе, якщо ти про це не потурбуєшся

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

Нет, основа моих мыслей в том, что софт. скилы — не должны быть № 1, так же как и принятие решений одним человеком. Если же софт будет № 1 и принятие решений идет отдним челвеком. то для чего тогда эти самые софт скиллы ? Кто в итоге будет нести ответсвенность за кривой найм ? За факапы ? Я выше привел пример субьективного решения не в мелкой компании -а в ТОП-5, когда решения принял один человек, потому что у него, по его вине был косяк в найме. Как итоге команда не получила того — кого по мнению большинства стоило взять. Именно субьективное оценивание приводит и приводило часто густо к ситуациям которые тут описывали и на «уютном».

Навіть у гарні часи — є компаніїї, для яких твої софт-скіли важливіші за кількість твоїх років на Scala.

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

І чим більш відома компанія, тим туди більше хочуть, і тим більше це грає проти тебе, якщо ти про це не потурбуєшся

И тем больше субьективных, безконтрольных решений. Одна из причин ухода из такой компании. Никакие софт. скллы не помогут, когда сверху мышление идет в личных интересах, а не интересах проекта.

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

Я так и не думаю, я думаю хорошего технаря возьмут те — кому он нужен. Прведу пример одного собеседования, компания искала сисадмина, хорошего на топ позицию. Но проводить собеседование таких людей — еще нужно уметь. На собеседовании задают человеку вопрос — «как вы сделаете релоад apache2 на продакшине, после изменений», ответ «kill -SIGHUP PID», ну спец был с юмором, человек проводивший интервью озадачился и начал не дискуссию, а спор — что это не корректно. Как думаете какое решение приняли по отношению к этму кандидату ? Имхо если не умеешь собеседовать такого уровня людей — лучше не берись, так как обгадится можешь. Так это не в однодневку, это опять же ТОП украинского IT.

Возможно, то резюме — с которого началась наша дискуссия, была из разряда такой же шутки, для тех «кто в теме». Челвоек из рассказа выше в итоге ушел от идеи искать работу по местному, а устроился удаленно в крупную компанию, где подобный юмор «оценили». Потому как подобные овтеты, они реально показывают уровень знаний и коммуникаций. То — что кто то не смог оценить — это показывает уровень интервьюера.
Этот же человек таким же образом пошулти на другом собеседовании про RAID-5, но увы — то же не заценили и отвернули его.

основа моих мыслей в том, что софт. скилы — не должны быть № 1

основа моєї статті — що мають бути № 1 при наявній технічній експертизі

якщо ви не згодні — я вас не переконаю, але життя переконає :)

Тут знаєте, є два способи вчитись — на власних гулях, і прислухаючись до інших

Я не сумніваюсь, що кар’єру можна побудувати й класно працювати все життя без таких матерій, але без софт-скілів у вас завжди буде скляна стеля, і багато дверей для вас будуть або просто закриті, або ви їх не помітите взагалі

основа моєї статті — що мають бути № 1 при наявній технічній експертизі

При таком обьяснении согласен, но не понял его из статьи.

це і є Mr. T-shaped
я в принципі сам познайомився з цим поняттям десь рік тому, а враження від попередньої статті і дискусій тут — що вона не дуже відома, можливо тут можна було більше написати

але вона і відображає якраз глибоку техекспертизу

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

а багато людей насправді мають софт-скіли — це здебільшого просто common-sense (ввічливість, тактовність, реалістичність міркувань ітд) але не усвідомлюють цього, або не ставлять їм в заслугу власний добробут, але вони дуже багато важать

Имхо все равно останусь при своем, так как умение общаться — это must have и не только для IT. Умение решать задачи, это то — чему учишсья много лет, всю жизнь и это называется опыт. Если с детства не научили общаться — в старшем возрасте уже сложно научить. Но середину я для себя не нашел, уж очень много раз сталкивался с ситуауиями когда недостаток хард. скиллов приводил к ситуации когда люди просто в бешенство приходили, потому как им приходилось решать свои проблемы, проблемы некомпетентных людей, срыв отпусков, выходных и планов. Лиди, которые годами работают на проекте и всем наплевать на их «софт» и «хард», просто всем влом что либо менять, а тянуть проект приходится другим и люди ломаются, выгорают, уходят. Происходит текучка кадров и прочие сопутствующие вещи и ситуации. Думаю что это одна из причин — по которой в большие компании сложно попасть на работу, так как на рааботу принимают тех — кого можно и с кем лего беседовать, их берут на работу в расчете на то — что они подтянут знания на месте, но этого не происходит. Та же фигня с софт — сложно вести диалог про решения человека, который не работал в команде или не умеет работать сообща. Итог- две стороны одной медали, а где та истина и как ее научится выделять — это еще та задачка и проблема.

Подивіться з такого боку: навіть з цієї розмови видно ясно, що ви намагаєтесь аргументувати своє, і намагаєтесь зрозуміти аргументи проти, а не просто спускаєте все на базар. Це і є саме те, бо люди які можуть вести дискусію там де не погоджуються — мають потенціал в багатьох напрямках, а не просто кліпати таски з джири з 9 до 5 (сподіваюсь не до 10)

Це каже мені, що навіть якщо ви не ставите цей скіл собі в заслугу, він для вас і на вас працює, і я певен вже дуже довго і довго працюватиме

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

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

Суть моєї думки — професіонал це людина, яка в може і те, і інше, може без задоволення, але МОЖЕ.

общатся с людьми и решать проблемы проекта

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

Якщо ви плануєте наступні 20 років бути лише інженером — може й ок, але якщо ні — ви самі до цього повернетесь, коли вже вивчите все, що було цікаво, і наступний hype не зачіпатиме струну вашого серця так сильно як колись ;)

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

тут якраз моє нерозуміння IT-ринку України. після seniora не йдуть в people-менеджери, це абсолютно паралельні світи, але інших варіантів в Україні нема просто. Тут не про PM і не про інших тіпа-менеджерів, які насправді такі самі пролетарі, тільки не технічного профілю.

Консалтинг в Україні відсутній, через відсутність внутрішнього ринку IT

Можете спробувати консалтинг, але для цього доведеться сісти на трактор.

Основна причина мого переїзду в Німеччину — це тому, що коли я досяг своїх тоді бажаних 3500к на місяць, я за кілька місяців зрозумів, що далі ще 40 років життя, і в Україні з тим часом небагато зробиш без — саме так — згаданої удачі і кум-сват-брат

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

зара всеодно поганий час і взагалі навіть в хороший час такий переїзд вдарить по бюджету і сім’ї, мовний і культурний стрес.
Бюджет пізніше тільки відновиться й можна буде говорити про «більше», це недовгий шлях, вимірюється в роках

і я теж розумію складність переїзду з сім’єю

Я можу тільки сказати — що бенефіт тут якщо і є, то негарантований, і нематеріальний, він не вимірюється в грошах.

я десь тільки через років 5 зрівняв свою кишеню з минулою київською і набагато пізніше вийшов у плюс загалом, але в мене специфічна ситуація, я неодружений, і не планую тут житло, мені багато чого не треба. Я думаю, якби в мене була тоді сім’я, я б теж повернувся, може навіть і не їхав би. Але коли б діти стали більш самостійні, я б всеодно шукав би нових горизонтів, вже для них в першу чергу.

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

PS Мы с вами сьехали в диалоге от «моментов» в статье, на косяки HR.

Не съехали, я каждый пост начинаю с попыток понять что же не так в статье.

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

Для меня это звучало как то, что автор просматривал папку с резюме которые уже были отсеяны кем-то (вероятно HRами) до него. При этом сам автор согласен что не стоило его так просто отсеивать.

Мое ИМХО начет синьоров и статей по ним — тех. скиллы это must have в любом случае поэтому нет смысла постоянно упоминать об этом в статьях, все и так это понимают.
Но кроме этого становятся важны и софт скиллы. Я не раз наблюдала ситуации когда у хороших специалистов появлялись хорошие идеи которые они хотели бы внедрить в продукт, но эти идеи заворачивались потому что у специалистов не хватало навыков для того чтобы донести их до стейкхолдеров. В результате получаем демотивированных специалистов и стейкхолдеров которые вероятно считают что они только время потеряли.

демотивированных специалистов

добре, якщо тільки демотивованих, я спостерігав істерики від 35 річних і грюкання дверима на загальних мітингах, бо «контейнери — це майбутнє, а ви тут ніхто не розумієте». Це ще й може бути удар по team-morale, якщо цей хлоп — неформальний лідер

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

это просто некорректное поведение

це і є відсутність софт-скіллів, тільки розказана по іншому

Не съехали, я каждый пост начинаю с попыток понять что же не так в статье.

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

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

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

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

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

Так как наличие софт. скиллов сводится к тому, что кто то умеет хорошо «лизать» и твои софт. скиллы своядятся на нет.

Такое конечно бывает, но если сплошь и рядом — вам стоит пересмотреть как вы выбираете компании в которых работаете. Есть хорошие компании с налаженными процессами и замечательным коллективом (да, даже в аутсорсе).

С таким управлением сложно «донести», да и на сколько это вообще входит в задачи технаря — «доносить» ?

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

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

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

Такое конечно бывает, но если сплошь и рядом — вам стоит пересмотреть как вы выбираете компании в которых работаете. Есть хорошие компании с налаженными процессами и замечательным коллективом (да, даже в аутсорсе).

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

Разговоры с менеджерами, менеджерами менеджеров, даже с тех. директором и даже доходило до ген. директора компании в решении проблем, итог: «а воз и ныне там». Кричать или говорить так, что бы тебя сылшали, заканчивается «Дима, хватит барагозить, ты какой то нервный, мож тебе пару дней отпуска ?» То есть не идет разговор ни вверх — ни в низ. Или — чего ты нервничаешь, у нас Канбан подход, делаем когда и как получится, так же и релизим, или «твоя задача перевзети в AWS, а дальше не твоя забота», при этом через 2 года после переезда «Нам нужно сократить расходы на инфраструктуру, посмотри что можно обрезать не в ущерб стабильности» и на вопрос и на реплику «блин — я же говорил 2 года назад», «Дима поздно уже говорить, надо сократить расходы».
КОгда сталикваешься с таким бардаком и в мелких конторах, и в стартапах, и в крупном аутсорсе, и в продуктовых компаниях — это сильно напрягает и начинаешь искать причины, я не такой, или как то вокруг много людей которые делают работу на «от...сь» или что не так ?!
Так что тут нет обиды, злится да — могу, но и со злостью уже учусь совладать и включить превентивно мозг, а не эмоции.

Тут знаєш, частково ти сковирнув велику банку гамна

Бо я описуючи софтскіли, маю на увазі білу сторону, скажем так, чесну гру.

Але братерство, жополизство, підстави, ходіння по головах і трупах й решта красот office politics — це теж скіли і для когось коник.

Тут теж не варто злитися на таке- це просто реальність яка є, від такого треба йти, але не завжди можливо. Іноді доводиться грати й програвати

я не такой, или как то вокруг много людей которые делают работу на «от...сь»

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

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

Звісно суб’єктивна, може тому й анекдоти про сенйьорів ходять, бо об’єктивних критеріїв просто нема, вам не здається?

Ви впустите першого волоцюгу з вулиці до себе в квартиру помити вам вікна без вашої присутності? Так само і люди, які наймають, ставляться до людей, які присилають невідформатоване резюме.

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

Людина яка безвідповідально ставиться навіть до свого резюме, яке буде перед сотнями очей — так само безвідповідально й працюватиме, яка б вона супер-досвічена на папері не була.

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

Тут не суб’єктивне конкретне моє чи ваше грає, а те, що більшості це просто не подобається, і далі в скіли не дивляться. Професія вимагає від професійних людей професійного ставлення впершу чергу до себе й свого CV, і щоб воно працювало для вас, а не проти вас

Ну вот нес соглашусь, опять же из личного опыта. Вся суть вашего поста:

Професія вимагає від професійних людей професійного ставлення впершу чергу до себе й свого CV, і щоб воно працювало для вас, а не проти вас

Почему в современном IT — очень много изобретают «велосипедов» ? Почему нет стандартизации ? Как раз по этой причине, вы смотрите на красоту, а не на возможноти — красиво, значит берем, не расиво — пшел нах. Вот тут и все, точка. Как итог — вы возьмете на работу того, кто умеет быть красивым, а то как он решает задачи — это уже след. вопрос. Не вам потом разгребать дерьмо после горе спецов, не вам потом фиксить ночами проблемы, потому что больше некому. Как итог — люди уходят со скандалами. Из личного — мне HR предложила вакансию, мы побеседовали, она попросила CV — я отправил, ей не понравилось, я просил прямо " а как надо ?«, она обьяснила как надо — диалог пошел дальше. Дальше — CV красиво — мне как человеку, которых за 15 лет поменял меньше компаний чем пальцев на руках, сложно ловить «тренд» и хотелки HR, те проекты с которыми я работаю, на этапе рассмотрения — подсказали что им нужно и как они видят свои тербвоания, в итоге я им дал это, хотя первый и второй вариант отливались сильно. Ну просто у меня нет желания тратить 10$ на платный сервис, или 100$ на спеца по CV. Если контора в адеквате, уплавление в адеквате — довгоримся, если нет — то высер выше, «мы тупо отбросили, плохо отформатированно и т.д»...

Ви праві, я вас розумію

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

Охайного досить зазвичай, випадок про який я розказав — це 8 сторінок невіформатованого трешу, в якому ніхто не буде розбиратись на скрінігу, коли в черзі ще десяток просто нормальних для читання (не супер-гарних!)

І кандидату не розкажуть про причину відмови, але так світ працює на жаль

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

Я не хочу, щоб моє резюме створювало мені проблеми, і вам того не бажаю

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

вы смотрите на красоту, а не на возможноти —

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

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

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

в придачу

це 8 сторінок невіформатованого трешу

8 Страниц инфы, как я понимаю — в которой рассказывается об опыте и умениях человека !
Вы каждые день такие резюме видите ? Я нет. Тут же просто из проф. любопытства пообщаться стоило бы. Как правило такие люди сильно замкнуты, это их проф. дефформация. Если у вас позиция подразумевала знания, что на них как вы сами написали отозвался чудесный олдскулл хакер, блин — я бы просто пообщался, посмотреть на такого человека, узнать что он за личность. Не интересно ? В моем опыте таких 1 был, реаьно один. дороги разошлись, связь не поддерживаем уже, но самоучка которрый на нашем общем проекте напедалил такие штуки крутые для проекта, что было чему поучится, пофиг на его «особенности»... Имхо это факап управленца. Реальный факап. Никто из нас не обязан делать как вам удобно, это однобоко, а вот подстроить друг друга, это уже взаимный подход. Так было во всяком случае у меня, человек поднял мой левел, бекенда левел за одно и на проекте себя прокачал. Денег заработали все, бонусы получили и разошлись. Но тот опыт — это нечто было. Это меня и расстраивает, что вы просто выкинули в корзину то, что потециально могло дать профит команде, проекту.

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

Вы то, как я понял, фактически — прочитали. Но дальше просто не уделили этому человеку чутка времени, просто потому что «не опрятно». Субьективно ? ДА, для проекта хорошо или плохо ? Уже не узнаем. Потому что субективное менение победило. Хотя фактически мог быть профит.

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

Я не вважаю його реджект факапом, бо в 45 років шукати роботу з таким папірцем — хай комусь іншому буде

І ви можливо думаєте що це щось свідоме — ні, абосолютно ні. Це працює підсвідомо, так само як люди не хочуть спілкуватись з немитими людьми на вулиці.

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

Маленька незначна перевага зробила свою справу, про це й мова

Ай, від вас подяку чути краще за просто приємно! Прошу!

Подумал может нормальная статья , но прочитал вот это :

Що наліпити 50 штук абияк, але вчасно — краще, ніж лише 5, які б вони не були ідеальні.

Эх , дальше читать смысла не увидел :/

заказчику так скажешь когда будешь фичу в другой спринт переносить

Я не работаю с снг

А при чем тут СНГ? Врядли тут многие работают на этот рынок.
Есть понятие business needs, есть сроки и коммитменты, есть бюджет (и он чаще всего не резиновый). Перфекционизм — это здорово, но только до тех пор пока он не выходит за рамки вышеперечисленного.

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

В плане качества есть понятие good enough. Business needs это фичи, которые нужны пользователям, сделанные досточно качественно чтобы ими можно было пользоваться без опасений за стабильность системы и сохранность данных, и они не вызывали у пользователей особых претензий по юзабилити.

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

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

p.s. Упоминание [софта для] авиации и банков улыбнуло :)

Извините, но не прочитал весь Ваш ответ, я понимаю Ваше мнение, оно довольно распространенное.

не прочитал весь Ваш ответ

Яснопонятно :) Если бы мое мнение было распостраненным, мы бы сейчас об этом не разговаривали...

Business needs как раз это качество , а сроки , коммитменты, бюджеты имеют значение только если продукт качественный...

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

а вот красивая ножка из красного дерева для стула в стиле барокко — бесполезна.

А если проблемы со сроками это проблемы с компетенцией тех кто их назначил

The average across all companies is 189% of the original cost estimate.
The average overrun is 222% of the original time estimate.
The success rate was only 16.2%, while challenged projects accounted for 52.7%, and impaired (cancelled) for 31.1%
TheStandishGroupReport ©

вы наверное только в этих 16.2% проектов участвовали

Ну думаю заусенцы на незашкуренной табуретке заставят Вас встать и подождать пока ножку в стиле барокко все таки прикрутят , тогда и посидите нормально наконец )) Да мне везёт на проекты видимо, один раз когда заказчик установил контрактом срок 4 мес , я сказал что через 1.5 года все будет, мне рассказывали про бизнес нидз и все такое как же так можно... , в итоге через полтора ударили мы в ладоши и подписали выполнение контракта ;)

подождать пока ножку в стиле барокко все таки прикрутят

а ее обычно не прикрутят.
в 31.1% проект «стул в стиле барокко» вообще закроют
в 52.7% — будет табуретка. но, наверное зашкуренная и покрытая лаком.

речь же была о

Що наліпити 50 штук абияк, але вчасно — краще, ніж лише 5
Да мне везёт на проекты видимо,

думаю вряд ли.
потому что приведенные цифры описывают явление под названием
«кризис программного обеспечения» (1968 год)

но да:
«и вы говорите»

вас фундаментальные и нерешенные проблемы разработки ПО не коснулись.

в итоге через полтора ударили мы в ладоши и подписали выполнение контракта ;)

чаще бывает — некроменеджмент
это когда контракт подписывается по сроку — 4 месяца.
а потом еще год допиливается.

но все да, рапортуют что все было сделано в оговоренный срок.

В принципе согласен

Це був приклад задачі з жорстким дедлайном, приклад з життя — MVP для стартапа, де якість важить набагато менше за час виходу на ринок

Выход на рынок с чем? )))

www.agilealliance.org/...​ers with the least effort.

Суть MVP — швидко вийти на ринок, завоювати перших клієнтів і їх фідбек втілити в подальших ітераціях

На новому ринку — першість з MVP означає бути лідером ринку, затримка гарної ідеї в розробці — рівна смерті й здачі першості на ринку конкурентам

N26 — онлайн банк, яскравий приклад. Ідею в Україні втілили monobank і sportbank. Про який з двох ви більше чули?

Теперь буду знать современное звучание фразы «Рога и Копыта» )). Спасибо, что предупредили насчёт Монобанка ... тут согласен в Украине таких как Вы называете MVP компаний много))

Дуже цікава, змістовна та корисна стаття. Допомагає виробити відповідні орієнтири для професіонального зростання.

Дякую за відгук, і необмеженого професійного успіху!

забыли упомянуть умение играть в настольный теннис и настольный футбол

Катать шары в бильярде может проканать вместо футбола?

А також вміння вибирати смачні сири

вау, про сири чув, але статтю не бачив, коменти — просто фейерверк :D

Святе діло

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

А інших «лідерів», які були привітні раз на рік на корпоративі, навіть не намагаючись спитати як вас звуть і хто ви такий — ненавиділи й просто не сприймали як людей

Це трохи не про сінйорів звісно, але суть приблизно та ж

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