Різниця у soft skills між рівнями Junior, Middle та Senior

Всім привіт! Мене звати Оксана. Я керую командою аналітики в українській продуктовій компанії Jooble. В аналітиці я вже дев’ять років і за цей час мені доводилося працювати зі спеціалістами всіх рівнів від Intern/Trainee до C-level в багатьох напрямках та сферах.

Я багато часу проводжу в робочому нетворкінгу і досить часто отримую такі питання:

  • А що мені вивчити, щоб від Trainee перейти до Junior? Киньте посилання.
  • Скільки часу треба чекати, щоб стати Middle?
  • Тимлід каже, що я Middle. Як йому довести, що п’ять років досвіду — це вже Senior?
  • Працюю найдовше в команді, а керівником зробили зовсім нову людину! Хоча в неї менше досвіду в професії! Що за дурне рішення, я ж довше працюю аналітиком!

Ці питання крутяться навколо кількості років досвіду фахівця та його рівня сеньйорності.

Та чи завжди кількість років = певний рівень сеньйорності? Я впевнена, що ні, й час відходити від цих стереотипів.

Я, звичайно, розумію, чому люди хочуть отримувати вищі рівні — це напряму впливає на їхній дохід. А ще є цей момент, коли змінюєш в LinkedIn Middle на Senior в заголовку — 10 хвилин гордості за себе.

Загалом, підвищення позиції — це безкоштовна для компанії мотивація спеціаліста. До прикладу, якщо людина займає роль тимліда, а далі їй змінять позицію на Head of без зміни у зарплаті, то я впевнена, що сама зміна назви позиції дасть людині буст в мотивації! Тому визначати зростання за допомогою назв рівнів або позицій — непогана практика. Це ачівки, що підкреслюють результат власної роботи, яким можна пишатися.

Я маю понад п’ять років досвіду в менеджменті й в цій статті хотіла б поділитися власним, випрацьованим за цей час баченням трьох звичних нам в IT етапів розвитку професіоналів — Junior /Middle / Senior.

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

Чотири вершники сеньйорності

Я для себе виділяю чотири основних критерії для визначення рівня спеціаліста:

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

Як ви можете помітити, про хард скіли тут лише один пункт, але він є і це 25%, що немало.

Проте почнемо з цікавішого.

№ 1. Відповідальність

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

Від Junior я очікую відповідальності на рівні його конкретної задачі

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

Наведу кілька прикладів з реального досвіду, де рівень відповідальності не був на Junior-рівні.

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

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

Але навіть на Junior-рівні людина має нести відповідальність за якість своєї роботи та ставити питання, коли має сумніви у власній спроможності її виконати. Перевіряти свої здогадки та псувати інструменти, якими користуються інші колеги — досить безвідповідально.

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

Наведу також приклади, де повністю проглядається потрібний рівень відповідальності.

  • Junior-спеціаліст насетапив зі своїм ментором 30 хвилин сінки кожні два дні, щоб показувати прогрес у важкій та новій для нього задачі та ставити питання, як тільки вони з’являються. Таким чином він виконав навіть мідловську задачу і до того ж вчасно. Це стало можливим, тому що людина вчасно зорієнтувалася, що їй потрібна допомога, і організувала цю допомогу!
  • Або ж був кейс, коли людина прийшла до мене на зустріч і сказала, що не дуже впевнена у власній реалізації, розповіла, як вона перевірила свій варіант, і запитала, чи нічого не упустила. Виявилося, що спеціаліст все врахував, але така обережність в тому випадку була не зайвою, тому що зміна впливала на дані для роботи багатьох команд.

Відповідальності на Middle-рівні

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

Коли до мене приходить мідл і каже: ой задача погано описана, чи можемо ми її не робити в такому випадку? Я відразу розумію, що відповідальність не на мідл-рівні.

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

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

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

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

Senior — це вже рівень відповідальності на рівні компанії

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

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

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

Негативним прикладом була ситуація, коли людині я довірила ресерч нової системи візуалізації. Ми домовилися про критерії, яким вона має відповідати.

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

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

Підсумовуючи, спеціаліст рівня

  • Junior бере відповідальність на рівні задачі;
  • Middle — на рівні команди;
  • Senior — на рівні компанії.

Хочу тут додати поради, які мені допомогли розвивати цю компетенцію в собі та прокачувати її в інших спеціалістах:

  1. Змиріться з тим, що той, хто щось робить — той буде помилятися. Помилок не уникнути, вас будуть за них сварити або не будуть, але готуйтеся морально. Я все ще засмучуюсь, коли щось не виходить, але період від «я поганий спеціаліст і все зламала, навіщо я це взагалі взяла» до «а як вирішити ситуацію, в якій ми опинилися» скоротився в рази.
  2. Беріть проєкти «на виріст», завжди страшно брати щось більше ніж до цього, але інакше розвитку не буде. Пам’ятайте правило: цікаво vs страшно має бути 50 на 50.
  3. Будьте чесними з собою та колегами: коли не справляєтесь, залишайте для себе можливість повідомити, що потрібна допомога. Тільки робіть це щойно ситуація стала погіршуватися, адже ваше зайве геройство може коштувати компанії грошей.

З відповідальністю зрозуміло, це дуже складно, але дуже потрібно.

№ 2. Рівень абстракції проблем, з якими працює спеціаліст

Тут все простіше.

Junior працює з конкретно локалізованою проблемою і з її описом уже на рівні дій

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

До прикладу, це задачі типу: додай фільтр в дешборд, заміни рядок коду на іншу умову тощо.

Middle — це рівень абстракції «ми маємо проблему і вона десь тут»

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

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

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

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

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

У мене був кейс, коли я прийшла в команду і мені СМО сказав: «Оксана, зроби щось з продуктивністю команди аналітики, щось вона дуже повільно працює».

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

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

Кілька порад тут:

  1. Вивчайте компанію, в якій працюєте, та вчіться розуміти бізнес. Компанія — це не дизайн, не аналітика і не код. Це інвестиції та їх окупності, тож потрібно знайомитися з іншими командами та їхніми задачами і складати максимально повну картинку. Я люблю «напрошуватися» на мітинги інших команд, щоб розуміти їхній контекст та розширювати своє розуміння того, як працює компанія.
  2. В рамках компанії змінюйте команди або напрямки. Це додасть експертизи. В моїх командах я практикую перехід аналітиків між департаментами, рік в Aquisition, рік в B2B, потім участь в Продукті.
  3. Не бійтеся спілкуватися з C-рівнем або з лідерами напрямків. Ставте питання, прояснюйте незрозуміле. Люди зазвичай відкриті та готові допомогти розібратися людині в бізнес-контексті, адже це забустить її спроможність розв’язувати складні задачі. Я люблю збирати питання і потім запрошувати спеціаліста на зустріч, де намагаюся з’ясувати на них відповіді.

№ 3. Калібр ініціативи відповідно до впливу на бізнес

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

Ініціатива на рівні Junior — це пропозиції відносно невеликих покращень в рамках своєї конкретної роботи

Тобто людина пропонує те, що зробить її життя на роботі легшим. Це вже дуже круто.

Колись дуже давно я працювала в компанії, де моя робота здебільшого складалася з щоденного заповнення певних звітів. Це було не цікаво і рутинно. Я запропонувала ідею, яка після реалізації вивільнила 30% мого часу. Звичайно, +30% часу джуна — це не game changer для компанії, але ця оптимізація була на рівні доступного мені горизонту.

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

Middle-спеціаліст має пропонувати ідеї, які повпливають не лише на його роботу

Це може бути також оптимізація, але яка вивільнить 30% часу всієї команди. Коли людина вже має досвід та розуміння бізнесу, насправді таких ідей можна запропонувати не мало. Тут важливо не полінитися та ескалювати їх.

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

Senior має пропонувати такі зміни, які впливають на роботу багатьох команд

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

Ніхто не просив цю людину займатися таким ресерчем, але він побачив можливість і запропонував її використати. Це змінило підхід до експериментів для 100+ людей в компанії! Важливо, що на рівні сініор я очікую якісно пропрацьовану ідею, не лише підсвітку проблеми.

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

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

Як розвивати ініціативність

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

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

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

№ 4. Коротко — про технічні навички

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

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

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

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

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

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

Щоб ви ще сюди порадили додати? Чи використовуєте схожі підходи? Досить неоднозначна тема, буде цікаво почитати думки.

Усі статті, обговорення, новини для початківців — в одному місці. Підписуйтеся на телеграм-канал!

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

Найкращі коментарі пропустити

в епоху ШІ ми маємо швидко відходити від оцінки людей за hard skills, тому що їх замінити найпростіше

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

Джун: не може спитати у колег, що йому незрозуміло, англійська б2 (ай мувед таск 666 ту ін прогресом, но озер апдейтс), в презентаціях ліпить локальні меми, носить худі. Показати кастомеру соромно.
Мідл: може спитати у колег, що не зрозуміло, англійська б2( ай хев а блокер, енд вейтінг фор ріплай фром ххх, мінвайл еддінг юніт тестс), не вставляє меми в презентації, носить худі, але має сорочку. Показати кастомеру не соромно, але краще щоб не говорив.
Синьор: може спитати у кастомера, що йому незрозуміло, англійська б2 (може пожартувати з кастомером, і його жарт зрозуміють), в презентації вставляє комікси хскд, носить худі, але має два піджака. Показати кастомеру не соромно, може говорити.

В статті старший спеціаліст (Senior) виглядає як вже потолок розвитку, а як же Principal, Team Lead, Architect, etc. Все ж таки рівень це дуже відносно і сильно залежить від проекту, компанії, рівня доходу, відповідальності і т.д.

Все те саме, але одним абзацом:
1) Junior — той, кого щойно найняли та готуються продати замовнику як Senior’a
2) Middle — той, кого не змогли продати замовнику як Senior’a
3) Senior — той, кого змогли продати замовнику як Senior’a

Як на мені, junior, middle та senior це градація заробітної платні у межах однієї компанії. А спроба це пояснити це сова на глобус. Хто як має мислити.. Маячня.

Мені здається, в епоху ШІ ми маємо швидко відходити від оцінки людей за hard skills, тому що їх замінити найпростіше

Навпаки, мовні моделі заміняють добре soft skils, допоможуть тобі написати листа, зможуть писати коментарі, закривати задачі, трекати час, ... Узяти всю комунікацію запросто. А от фіксити баги, де потрібно знання усього проекту, аж ніяк.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Усе, що я вам скажу, друзі, про «софт скіли» в розрізі примітивної градації J/M/S: якщо озирнутися довкола, то позитивно-налаштована, соціально-активна, супер-комунікабельна та сильно-впевнена у собі некомпететність править цим світом...

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

Чудова стаття, додаю в обране! Також з роками дійшов до розуміння, що сеньйорність — це ПЕРЕДУСІМ про твою роль на проєкті, а не про те, що ти там якийсь сертифікат отримав. Тобто технічно — так, ти можеш бути сеньйором, без питань, але в команді ти поводишся як мідл чи навіть джун:
— ти не береш відповідальність за роботу команди (а часто навіть і за свою),
— ти вдаєш, що тебе не існує, коли бачиш, що іншим потрібна допомога (заздрю таким людям насравді, самому б так хотілося)
— ти ігноруєш дедлайни (а часто навіть і не усвідовлюєш, що вони існують)
— ти не розумієш пріоритетів для бізнесу, а робиш те, що хочеш робити більше в цю конкретну мить («цей рефакторинг дуже важливий, тому я працюю над ним останні кілька спринтів»)
— ти не проявляєш ініціативи, не шукаєш «покращень», нічого не пропонуєш
— ти не зацікавлений у тому, щоб ходити на мітинги, передусім «скрам-церемонії» («дайте мені роботу, я її робитиму, нащо мені витрачати час на ваші мітинги? ви хочете, щоб я на мітинги ходив, чи роботу робив? хай хтось сам все прогрумить, навіщо ці процеси заради процесів?»),
— ти не задаєш питання точково «правильним» людям, а закопуєшся в задачі, поки не зрозумієш, що сам вже не викопаєшся (і від того ще більше впадаєш у депресняк, бо «як це так, я ж сеньйор? боже, яка ганьба»)
— ти не намагаєшся вникнути у суміжні сфери продукту і комунікувати з іншими командами.

Також дуже дякую авторці за правильну градацію: у своїх резюме я ніколи не пишу «личку» на тому чи іншому місці роботи, бо вважаю, що в Україні вони дуже викривлені і саме поняття «сеньйора» в нас доволі скурвилось. Мене вбіса харить, коли я у кожного другого бачу приставку «сеньйор», тоді, коли у компаніях типу Гугла навіть не кожен наш «принципал» зможе влаштуватись на вакансію сеньйора там. Тому авторка дуже чітко описала різницю і розклала все за поличками. Єдине, що я б хотів трохи уточнити тут — що компанії ж бувають різні: маленькі, середні і великі. І, якщо десь у великій компанії людина приймає рішення на користь всієї компанії, а не лише своєї команди, то це, мабуть, все ж ближче до принципала. Я б підкоригував так: сеньйор — це той, хто виходить за межі лише своєї локальної команди, коли думає над вирішенням проблеми.

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

сеньйор — це той, хто виходить за межі лише своєї локальної команди.

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

зокрема агілє скрум це якраз «чисто сіньорський фреймворк» який вводить однакові правила взаємодії виконуючі які дозволяє працювати кільком сіньорам на однім проекті «як один сам»

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

ну так то і є якраз теоретична історія аби «дизайнер» міг довести свій «дизайн» до реальної реалізації то він би тіко так і робив

враховує складність реалізації свого дизайну для команди розробки

а не навпаки ))

це ви всьо дно що пишете «маємо 2 мідлів один вміє читати код з екрана другий вміє писати код на екран шукаємо 3-го хто вміє код з екрану записувати на диск і запускати»

Скрум это приблуда для переноса ответсвенности с менеджера на команду.
Так-то большинство работало бы в вотерфоле.

Коли десь в мережі бідкаються і розповідають про важку дорогу «через гори» десь в Таїланді, Грузії, Туреччині, на балканах, жаліються на «трудності вожденія» вночі, або у великому місті десь за межами України, і т.п., то ніколи не цікавлюсь «скільки років» за кермом, а завжди питаю — скільки сотен тисяч км проїхали по світу? ))

Серед моїх знайомих аналітиків на Python можуть писати й ті, хто його навіть не знає майже

От тому ми всє умрьом

або навпаки — виживемо :) Якщо інша система може написати невеличку оптимізацію і аналітик може її перевикористати, навіщо йому вчити мову програмування для вирішення однієї задачі 3-4 місяці? Він може інвестувати свій час в щось потрібніше йому для вирішення більшої кількості поточних задач.

Це просто стан душі. Та self-fulfilling prophecy. Після 20 років розробки все ще як юніор. Багато чого цікаво, знаю лише що, за великим рахунком, нічого не знаю. Але роки звісно згодом візьмуть своє, ще нікому не вдалося обдурити час.

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

Мид — как получится, сейнор — за свой код, приниципал — за проект.

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

Я в США. Но вам виднее.
Нигде где я работал джуны не несут ответсвенности.
«ой, я забыл кнопку нажать, все настроил но не нажал сейв. И 10 клубов получили падение распознания на 20%» — вчера в волмарте. СЕ-3(мидл, следующий уровень сенйор).

Нигде где я работал джуны не несут ответсвенности.

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

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

Еще раз. Везде, где я работал(а работал я как фрилансер в 200+ организациях, в отлчии от большинства) джун просто говорит «ну так получилося».

Не помню откуда диалог
— есть китайская поговорка: «из 20 ошибок ребёнка не замечайте 19»
— у нас есть итальянская погооворка: «Один проёб — два зуба на***»
Если человек живёт в парадигме «ну так получилось» — надо уволнять
Отвественность должна быть.

Junior бере відповідальність на рівні задачі;
Middle — на рівні команди;
Senior — на рівні компанії.

Тоді мабуть:
— Lead — на рівні холдингу
— Principal — на рівні індустрії
— Chief — на рівні планети

IMHO, авторці треба «очікувалку» закатати трошки.

— Chief — на рівні планети

Why not?

Он були (місцями є) різні герцоги і графи :) Тільки розтягнути лінійку.

а хто на Вашу думку такий сеньйор? Пропрацював 5-ть років і з них лише красив кнопки в Джанго?

У вас між «фарбувати кнопку» та «відповідати за життя компанії» — вакуум?
Синьйор працює десь на рівні сторі (тобто може побалакати з іншою стороною фронт/бек/дизайнер/аналітик) та тримає в голові вірогідність змін/масштабування.

Сенйор — это человек который понимает прежде всего чего в этой стори на спринте делать нельзя и ПОЧЕМУ. Мидл — понимает чего нельзя, но еще не понимает почему, не успел.
Код сенйора легко изменить с новыми(на самом деле только с наиболее вероятными) требованиям. Код мидла — полностью рефакторить. Код джуна — выкидывать.
Потому, собственно, основные стори рефакторинга уходят сенйорам, и только совсем очевидно прописанные задачи — джунам.

лише красив кнопки в Джанго?

но дєлав єто с уваженієм

Джун — не знає як треба робити таску
Мідл — знає як треба робити таску
Помідор — знає як НЕ ТРЕБА робити таску

Насправді, тільки джун бере відповідальність на рівні задачі, мідл бере відповідальність — на рівні задачі, а от вже сіньор — відповідальність на рівні задачі.

"

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

"

з такими сіньорами і бухгалтерії не треба

Хлопцы я по-другому сформирую, если студент со 122-ой могут взять на сеньора, если знаний достаточно, но практического опыта или опыта работы в офисе нет вообще?

Хлопцы я по-другому сформирую, если студент со 122-ой могут взять на сеньора, если знаний достаточно, но практического опыта или опыта работы в офисе нет вообще?

Лично моё мнение: нет.
Джун максимум.

Даже если 3 курс, есть инженерное мышление и хорошая база знаний?

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

Даже если 3 курс, есть инженерное мышление и хорошая база знаний?

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

если студент со 122-ой могут взять на сеньора, если знаний достаточно, но практического опыта или опыта работы в офисе нет вообще?

Нет. Потому что всё равно надо проверять практику, насколько способен привыкнуть к реальной работе, не сорваться, не уйти в безумие любого вида (от шизофрении до растаманства и высокой философии вместо работы), и прочая и прочая и прочая. Все мы действуем на 99% на привычках и шаблонах, и адаптация к этим привычкам и шаблонам из любого состояния это вопрос времени, месяцы и годы.

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

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

студент со 122-ой

Ооо.. знову зʼявився цей кадр зі своєю

122-ой
Ооо.. знову зʼявився цей кадр зі своєю

а чем вам 122я не нравится? я сам там учусь и всем советую! ©

я от, наприклад, 123 закінчував. Але не пишу про це у кожному своєму коменті

я от, наприклад, 123 закінчував. Але не пишу про це у кожному своєму коменті

А он пишет. У каждого свой стиль.

Тому що мало хто за межами твого навчального закладу знає що таке 122. Але по рівню пафосу відчуваю, що заклад — КПІ.

Тому що мало хто за межами твого навчального закладу знає що таке 122.

ну, учитывая что а) на доу в основном «програмисты» и б) Спеціальність 122 — Комп’ютерні науки — это код из общего кодификатора, то где-то 80% на ДОУ — знаю что это за специальность

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

код из общего кодификатора,

А можна лінк на цей кодифікатор? Бо щось подібне пригадується тільки про наукові спеціальності, і там формат зовсім інший:
zakon.rada.gov.ua/laws/show/z1133-11

А можна лінк на цей кодифікатор? Бо щось подібне пригадується тільки про наукові спеціальності, і там формат зовсім інший:
zakon.rada.gov.ua/laws/show/z1133-11

ну, к примеру вот
vstup.osvita.ua/...​ec/1-40-1/0-0-1970-0-0-0

Нет. Кроме знаний надо опыт.
У меня тут под боком студент 4го курса который типа кодит типа с 10 лет.
Фигня это.
Либо детские ляпы либо оверинжениринг лютый. средины — не видит.

По-перше, нікому нічого не потрібно доводити, окрім себе. Якщо твій керівник не бачить, що ти Middle або вже Senior, то ти переходишь до іншого керівника, який це бачить. Можливо, в іншу компанію. Доводити комусь щось це марна трата часу і недоотримана ЗП. Насильно очі людині ти не розкриєш, а час і гроші втратиш.
По-друге, відповіді на питання скільки часу треба чекати щоб стати Middle не існує. Це не так працює як картоплю варити або макарони. Ти з огляду на свій досвід або розумієш що ти Middle або ні. Читаєш опис вакансії на Middle, і якщо розумієш що хоч половину ти точно вмієш а решту швидко опануєш за потреби, то можешь вважати себе мідлом. Не будьте перфекціоністами та ждунами, почніть робити хоч якось для початку і рухатися малими кроками, та буде вам щастя.
Всім перемоги!

Все те саме, але одним абзацом:
1) Junior — той, кого щойно найняли та готуються продати замовнику як Senior’a
2) Middle — той, кого не змогли продати замовнику як Senior’a
3) Senior — той, кого змогли продати замовнику як Senior’a

Java evangelist — той, що розказує про віртуальні потоки в джаві

виходячи з того що java virtual machine де запускається будь яка java то то є усе virtual навіть якщо там є потоки які відповідно так само «віртуальні»

просто у пана євангеліста була фейлова стаття «Тестуємо віртуальні потоки в Java 21», тому вирішив підколоти

в епоху ШІ ми маємо швидко відходити від оцінки людей за hard skills, тому що їх замінити найпростіше

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

Так чатжпт і все буде гуд. Ну максимум ще трішечки. Ну от вже скоро.

Так чатжпт і все буде гуд. Ну максимум ще трішечки. Ну от вже скоро.

«А зачем писать программы? всё ж можно из интернета скачать!»
В первый раз я такое услышал когда собеседовал потенциального разработчика, в 1999 году примерно :) (ну может в 2001, но звучит не так феерично)

В моїй особистий шкалі ці терміни зміщені на один рівень. Тобто те що тут описано як Senior — у мене Principal (ну і частина моєї роботи як СТО в продукті). Відповідно Middle тут — фактично Senior у мене і таке інше.
Тобто спрощена градація:
Junior отримує детальну задачу на розробку і його результат треба перевіряти
Middle отримує задачу на розробку і перевіряти його реалізацію можна якщо є відомі ризики
Senior отримує бізнес проблему у відомому домені та трансформує її у задачі на розробку для інших
Principal отримує чи знаходить бізнес проблему у невідомому домені та шукає рішення
Architect має бачення продукту в цілому та «розгорнутим у часі» і формулює послідовність бізнес проблем, які треба вирішувати, щоб робити це максимально ефективно з точки зору як бізнесу, так і процесу розробки.

Дякую! Як для мене, хто світчиться в аналітику з купою менеджерського досвіду, але з зародками технічних скілів, дуже підтримуюче. Так я зразу й на мідла можу собі помріяти увійти)

Як на мені, junior, middle та senior це градація заробітної платні у межах однієї компанії. А спроба це пояснити це сова на глобус. Хто як має мислити.. Маячня.

Мені здається, в епоху ШІ ми маємо швидко відходити від оцінки людей за hard skills, тому що їх замінити найпростіше

Навпаки, мовні моделі заміняють добре soft skils, допоможуть тобі написати листа, зможуть писати коментарі, закривати задачі, трекати час, ... Узяти всю комунікацію запросто. А от фіксити баги, де потрібно знання усього проекту, аж ніяк.

закривати задачі, трекати час

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

Дуже цікава стаття!
Оксана, дякую що підготували і опублікували.

Загалом, підвищення позиції — це безкоштовна для компанії мотивація спеціаліста. До прикладу, якщо людина займає роль тимліда, а далі їй змінять позицію на Head of без зміни у зарплаті, то я впевнена, що сама зміна назви позиції дасть людині буст в мотивації!

Далі можна не читати — тяжко зрозуміти що треба мати у черепі що дійти до такої геніальної ідеї.

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

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

Повышение роли без повышения зарплаты — однозначная причина для смены работы.

Далі можна не читати — тяжко зрозуміти що треба мати у черепі що дійти до такої геніальної ідеї.

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

Типу методи не матеріальної мотивації чому вчать. Та цьому якраз не вчать. Бо присвоювати звання весільних генералів нічого, навпаки вважається демотивуючим фактором як і премії в розмірі 0.05% від зарплатні. Пластмасові оскари чи грамоти, якими HR-и часто нагороджують один одну теж не завжди дають. Десь на корпоративі прокате, а просто на роботі — народ швидко збагне, що їм системно підсовують фуфел. Ті самі військові медалі та ордени часто мають матеріальне вираження. Там більше рекомендують різні : PDP, відвідування конференцій, тренінги, тімбілдінги і таке інше (насправді це теж про гроші, та не такі великі як скажімо у ви підвищити зарплатню). Ще хвалити, дякувати і тому подібне — ніби і що тут такого ? А на ділі може бути доволі важливим.

Далі можна не читати — тяжко зрозуміти що треба мати у черепі що дійти до такої геніальної ідеї.

Треба ще одну статтю про софт скіли на основі цього речення)

Далі можна не читати — тяжко зрозуміти що треба мати у черепі що дійти до такої геніальної ідеї.

Це схоже на варіацію популярної останній рік стратегії «Quiet cutting» en.wikipedia.org/wiki/Quiet_cutting

Може бути гірше чим описала пані Оксана

The ‘Quiet Cutting’ Trend Is A Controversial Leadership Strategy, New Study Shows www.forbes.com/...​dy-shows/?sh=2f3ea7951db9

Зважаючи на позицію автора це може бути своєрідним сарказмом. Не думаю, що Оксана може дозволити собі direct messages в стилі ***го IT

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

Що до різниці hard skills між middle та, senior спеціалістами, як на мене, трошки незрозуміло написано.

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

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

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

З цим не згоден від слова «взагалі». «Бути лідером напрямку» чи «обирати найкращі для бізнесу рішення» — це взагалі не про технічні скіли, а про product ownership, business analysis & project management. З мого досвіду, головна різниця між middle та senior в тому, що після того, як senior завершив завдання, тобто задовольнив acceptance criteria, технічний борг на проекті, зазвичай, не збільшується, а часто, навпаки, зменьшується. Тобто, senior, крім того, що здатний виконати технічне завдання будь-якого рівня, ще й здатний зробити це так, щоб не погіршити (а часто ще й покращити) технічний стан проекта в цілому. Саме тому на кожному проекті потрібен щонайменш один спеціаліст рівня senior. Якщо його чи її немає, завжди залишається ризик швидкого зростання технічного боргу до рівня, коли подальший розвиток проекту стає вже неможливим або геть нерентабельним.
Це якщо казати про суто технічні компетенції.
Всі інші аспекти, як на мене, можна формулювати геть по-різному. Все залежить від умов і потреб конкретної організації. Хоча, ні, розуміння необхідного рівня технічної компетенції також залежить від організації. Те, що я тут написав, — це моє поточне розуміння цієї проблеми, яке витікає з мого особистого досвіду. :) Проте, це погляд саме з точки зору технічного спеціаліста саме на технічні скіли.

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

З цим не згоден від слова «взагалі». «Бути лідером напрямку» чи «обирати найкращі для бізнесу рішення» — це взагалі не про технічні скіли, а про product ownership, business analysis & project management. З мого досвіду, головна різниця між middle та senior в тому, що після того, як senior завершив завдання, тобто задовольнив acceptance criteria, технічний борг на проекті, зазвичай, не збільшується, а часто, навпаки, зменьшується.

Ви про те саме пишите, це зветься экспертиза

Експерти́за (від лат. expertus — досвідчений, знавець) — розгляд, дослідження експертом-фахівцем якихось справ, питань, що потребують спеціальних знань

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

— Доброго дня, я експерт з розпізнання птахів.
— Дійсно? Чудово!!! В мене якраз до вас питання. Що ви можете сказати про тих двох на сусідньому дереві?
— Так.
— Що так?
— Це птахи.
:-)

Це я відповів на

Ви про те саме пишите, це зветься экспертиза

Це не просто так жарт заради жарту.

Ну тобто коли хтось зменшує технічний борг, як показник структурної якості ПЗ — то це типу погано для бізнесу ? Жодним чином не краще ніж якась конкуруюча компанія спеціалісти якої навпаки додають технічний борг ?
P.S. Я той не злопам’ятний — просто злий та пам’ять в мене хороша.

Я ніде не писав, що це погано для бізнесу. Просто розробник ПЗ і бізнес-аналітик — це дві суттєво РІЗНІ кваліфікації. Це звісно не виключає можливості того, що одна й та сама людина може володіти обома. Але, коли ми розмовляємо сам про hard skills, cаме розробника ПЗ, бізнес аналіз, так само як і менеджмент, тут ні до чого. Якось так.

А де у статті йшлось про hard skills взагалі ? Коротше я задовбався писати, що ми ніфіга не вірно перекладаємо американські армійські терміни. Тому усіх вони бентежать. Ви усі ці Hard та Soft швидше за усе знаєте зі школи, максимум з ініверу чи строкової служби. Окрім, можливо риторики та навичок ведення бізнесу — що вони лідерством називають. Як там писала людина з Tesla : "Якщо замінити слово демократія на слово — партія все це я вже багато разів чув".https://dou.ua/lenta/interviews/tesla-data-architect/
А про такі речи — що треба вітатись та знайомитись, представлятись один одному, ввічливо та поважно обходитись, давати здачи якщо требе бьють і тому подібне — не знаю як вас, а мене точно вчили батьки в дитячому садочку потім школі тощо. Щоправда те, що вчили і те що я навчився це далеко не одне і те саме.

А де у статті йшлось про hard skills взагалі ?
№ 4. Коротко — про технічні навички

головне в людині — це співчуття

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

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

Джун: не може спитати у колег, що йому незрозуміло, англійська б2 (ай мувед таск 666 ту ін прогресом, но озер апдейтс), в презентаціях ліпить локальні меми, носить худі. Показати кастомеру соромно.
Мідл: може спитати у колег, що не зрозуміло, англійська б2( ай хев а блокер, енд вейтінг фор ріплай фром ххх, мінвайл еддінг юніт тестс), не вставляє меми в презентації, носить худі, але має сорочку. Показати кастомеру не соромно, але краще щоб не говорив.
Синьор: може спитати у кастомера, що йому незрозуміло, англійська б2 (може пожартувати з кастомером, і його жарт зрозуміють), в презентації вставляє комікси хскд, носить худі, але має два піджака. Показати кастомеру не соромно, може говорити.

і його жарт зрозуміють

і думає, що його жарт зрозуміють

Та бачим, бачим, що синьор

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

У вас синьоры выполняют работу ПМа ? Если небыло дейта инженера (а правильно сказать дейта архитектура) кто бы разбирался, то у вас небыли и тру синьора в компании, что само по себе делает пример странным а статью ставит под сомнение.

> і проконтролював переїзд в рамках поставлених ним же дедлайнів.
Вы серьезно это ?!

ну и это

Senior створює задачі для себе або ж навіть для своїх колег Junior/Middle-рівня.

Senior решает задачи. Если чувак создает себе задачи то в первую очередь будет вопрос — «какого х он делает тут?». Вы опять что то путаете.

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

С чего бы это? Зачем им повторять ваши религиозные загоны про разделение ролей именно так, как вас учила какая-то очередная библия?

Выделение ролей типа «дейта архитектор» полезно только начиная с определённого уровня сложности. До этого их роль вполне может выполнять кто-то достаточно компетентный, чтобы обойти основные грабли.

Ах да, вы подписываетесь «Sr. Principal Data Engineer», не просто senior, а Principal! Ну тогда понятно, надо же оправдать титулование... (хорошо, если я ошибся с оценкой причин, но пока не вижу аргументов к этому)

Senior решает задачи. Если чувак создает себе задачи то в первую очередь будет вопрос — «какого х он делает тут?». Вы опять что то путаете.

Это вы «путаете».
Senior решает задачи, поставленные кем-то сверху (заказчик, PM, PO), но он вполне может ставить задачи тем, кто пониже уровнем — и обычно и ставит. А ещё он в состоянии заранее определить хотя бы в краткосрочном прицеле задачи на будущее, от новых фич до фикса долга, поставить и сформулировать их, и в рамках того, что позволяет бюджет и структура — решать выделение времени на них. Если компания нормальная (которыми являются дай бог чтобы 5% от всех) — у него есть на это официально объявленный резерв, если не совсем (ну может 1/3 от всех) — это умудряются провести в рамках бюджета других задач.

PS: Посмотрел я на вашу GoodRX... вероятно, задача выполняется даже очень полезная (слышал я про #@анутость медицины США), но такой шизоидной защиты от робота я давно не видел. Оно точно такое нужно?

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

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

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

По мнению автора, сеньор должен уметь брать на себя ответственность на уровне всей компании. Такого сеньора и берем за эталон, не так ли?

, а уж околотехнические презентации для клиента создает лучше меня.

Ой, не надо такое делать..... Там такие чудеса и знамения получаются, такая ересь....

Не преувеличивайте.
Даете тезисы, просите расписать на деловом языке по пунктам. Если мало, просите долить воды.
Клиент в восторге: вместо сухих малопонятных технических описаний получает красивую презентацию с до боли знакомыми, восторженными описаниями и business value.

Даете тезисы, просите расписать на деловом языке по пунктам. Если мало, просите долить воды.

И если бы я не пробовал так делать — то я бы не говорил :)
Хотя «план по пунктам» иногда получается неплохой.

Технічними навичками є не лише написання коду, ті ж презентації та написання листів або навіть комунікація також можуть входити до їх числа.
А на рахунок керівників, то в них дійсно як написав Олексій, можуть бути інші задачі, а вони самі можуть бути на різних рівнях як спеціалісти. Все залежить від очікувань від конкретної ролі. Я зустрічала керівників і junior рівня, так як від них очікували дуже монотонну перевірку роботи своїх підлеглих цього level було достатньо.

Забули сказати, що відповідальність менеджера в усьому описаному — остаточна і вирішальна. За що відповідає ШІ, в якого навіть суб’єктності немає?

У многих менеджеров ответственности не более.

Смотря как переводить responsibilities. Прямой перевод — как обязанности, однако это полит корректное название полномочий. Менеджер по сути — должностное лицо наделенное некоторым уровнем власти, т.е. возможности принудительно навязать свою волю. По существу это и есть все его обязанности иначе это не руководитель, потому что или вообще не имеет подчиненных или сам делает за них всю работу (т.е. херовый руководитель). Поэтому преславутая фраза «more responcibilities» на деле означает — больше полномочий, powers. Другое дело конечно кто и как руководит, кто жестко — а кто мягко. С жесткими типа Стива Джобса подчиненные не любят работать (но работают), с мягкими (хоть и строгими) типа Ли Яккоки — очень многие любят.

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

Тут не надо путать ибо мы по кругу ходим. Что такое ответственность ru.wikipedia.org/wiki/Ответственность

Отве́тственность — отношения зависимости человека от чего-то

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

що відповідальність менеджера в усьому описаному — остаточна і вирішальна

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

Тут не надо путать ибо мы по кругу ходим.

тема моего диплома «Управління результативністю менеджерів IT компаній», я более-менее понимаю о чем идёт речь :)

Да я не против что все и все понимают. Тут вопрос терминологии и правильного перевода с английского, по контексту. Если переводить «привлечь к ответственности» на английский то выйдет вовсе не «bring to responsibility», а «bring to justice». Потому что к полномочиям не приводят когда наказывают, к полномочиям приводят когда вводят в должность — например инаугурация президента. А то что в статье про джуниоров написано responsible — надо переводить как исполнительный или надежный тоесть заслуживавший доверия. Имеется в виду качество сотрудника — исполнять приказы и распоряжения руководителя точно и вовремя или же своевременно и обоснованно докладывать о невозможности их выполнить в виду объективных причин. По красноармейски если тебе чего-то не понятно, застрял, клавиатура сломалась и т.п. — подойди к тимлиду или там квочеру кто главный. Если дали работу — то делай эту работу, а не иди играть в пин понг, лялякать с девочками на кухне и т.п. Как бы просто однако понятно на самом деле не так уже и многим, в том числе мне в свое время. И за что кстати дембелей очень любят на гражданке, особенно сержантов быстро их повышают и т.д., в армии эти истины объясняют непосредственно понятным способом для тех кто туда попал — орут и дают по шее, наряды и т.д. т.е. привлекают к ответственности. В ИТ такое не катит, но есть другие методы типа заставить петь песенку и т.п.

менеджери: залишимося ми і АІ. програмістів на помийку.
програмісти: залишимося ми і АІ. менеджерів на помийку.

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

Про «всей конторой», кажется, никто не говорил.
А вот выполнять хотя бы часть задач, которые возложены на Technical Lead (не путать с Team Lead), ему по плечу и в местах, не убитых бюрократией, обычно это и происходит. К сожалению, сейчас это фактически везде только в малых фирмах. В больших оргструктура давит на то, что хоть ты зовёшься Lead хоть Principal, всё равно крутишься винтиком.

А вот работа Team Lead требует уже других качеств — и совмещение их не всегда удобно и возможно. Но до определённой степени — особенно, если сотрудники заранее готовы к использованию не-грубых подходов — вполне допустимо.

а уж околотехнические презентации для клиента создает лучше меня.

Регулярно путая все факты, так что от того AI остаётся только подготовка варианта красивой картинки. Это если я правильно понял, что вы назвали «АИ» (по-русски «ИИ», так что прошу уточнения).

Есть мнение, что целесообразно использовать мощь искусственного интеллекта именно в этом направлении.

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

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

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

«Мені здається, в епоху ШІ ми маємо швидко відходити від оцінки людей за hard skills, тому що їх замінити найпростіше»

Але ще ніхто не замінив)))

Загалом інформація в статті може нашкодити Junior та Middle якщо вони всерйоз сприймуть написане.
Senior спеціаліст просто посміхнеться з чергової спроби маніпуляції і підміни понять в стилі типового менеджменту.

Заміна уже відбувається :) компанії відмовляються від людей, що створюють контент в блогах або ж дві людини заміняють однією, так як частину роботи можна робити за допомогою ШІ. Вимоги до хардів також змінюються поступово, до прикладу від аналітиків я можу очікувати уже не такий високий рівень python, але дуже високий рівень логічного мислення або ж орієнтації на досягнення компанії.

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

Від Junior я очікую відповідальності на рівні його конкретної задачі
Це означає, що людина відповідальна за задачу і не очікує, що хтось її страхує, перевіряє чи робить паралельно.

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

Оксано, я би вас звільнив, якщо б я був роботодавцем.
(але я безробітний, тому це лише особисті фантазії)

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

есть разница между «не страховать джуна» и «джун не ожидает, что его страхуют», знаете ли

I don’t understand you and I’m not sorry about it

I don’t understand you and I’m not sorry about it

I’m not surprised. What can you expect from a javascript developer? :)
“I do not understand and I’m happy with that” — their typical motto.

ой вей самовбивця у чаті

ой вей самовбивця у чаті

нам будет тебя не хватать.
шутка.

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

????

Джун і трейні це як маленькі кошенята, яким в 90% треба допомога і страховка. Щоб джун приносив реальну користь компанії потрібно багато терпіння, допомоги ітд.. От тоді він за рік-півтора стане мідлом і вже зможе самостійно (з мінімальною страховкою) робити завдання середньої складності

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

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

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

Вибачте нас, будь ласка, що ми читаємо статті до кінця. Більше так не будемо.

Дякую за зворотній зв’язок!
Думаю, багато хто хвилюється що їх рано чи пізно щось або хтось замінить, але тут найкраще не заперечувати таку можливість, а адаптуватися :))

А про менеджерів люто плюсую. Такі ситуації супер негативно впливають на компанію та на людей в ній.

В статті старший спеціаліст (Senior) виглядає як вже потолок розвитку, а як же Principal, Team Lead, Architect, etc. Все ж таки рівень це дуже відносно і сильно залежить від проекту, компанії, рівня доходу, відповідальності і т.д.

Це просто (при всій повазі) стеля компетенції авторки, так вона і описує...

Пояснила вище свій підхід до рівнів.

Я спеціально не йшла на більш детальні рівні, щоб показати межу між левелами і не заплутати. Думала додати лише trainee + expert.
Тому що керівники або архітектори можуть бути на всіх описаних мною рівнях від junior до senior. То є назва посади, що я не прирівнюю до рівня професіоналізму. І від керівника купи людей або архітектора можна почути : нам так сказали, ми й зробили :)

Зрозуміло, тобто це Ваші абстрактні рівні без прив’язки до конкретних посад. Тому що якщо Architect гірший в компанії по компетенціям за звичайного Senior, то щось не так з наймом і процесами в такій компанії.

hard skills, тому що їх замінити найпростіше

Эти пассажи мы слышим уже лет 30 лет.
Только раньше это звучало «не нужны нам дорогие и хорошие инженеры, при необходимости мы быстро зааутсортим компетенции у ААА»
Теперь вместо ААА пишется ИИ.

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

Когнітивний дисонанс uk.wikipedia.org/...​wiki/Когнітивний_дисонанс виникає через невідповідність контекста.
Стаття по факту на базі західних, здебільшого американских дослідів якось так причесана, позаяк в нас не дуже з власними дослідами та доктори та кандидати типу януковича та ківи. Якщо перекласти це усе на аутсафінговий бізнес, вийде не те і не туди. Якісь розмови про «рішення на рівні компанії» до яких батраків з країн третього світу іноземці і близько не підпустять. А як полізеш куди не треба — миттєво вимагатимуть у менеджера заміни, не всі звісно, але в більшій кількості компаній клієнтів — так воно і буде, та взагалі буде відношення або снобське або пряме презирство. Так в цілому завжди ставляться до батраків усюди, тут нічого нового. Якось слухають може лише тих із ким працюють дуже давно, а це в ІТ велика рідкість.
Тут треба справді дивитись на бізнес як метод заробляння грошей — в чому він ? Правильно «Deploy massive teams, and make them billable» dou.ua/forums/topic/38287.
Тобто треба дивитись, що для цього треба і як цього досягти ? З України фактично нічого не зробиш, треба їздити закордон або у відрядження постійно, або їхати на релокейт. Чудово і презентаційно виглядати та говорити, відповідно одягатись і т.д. і т.п. коротше бути добрим продажником в тому числі технічним консультантом (пояснювати молодшим як оформити резюме, проходити співбесіди тощо). Власне — релокейт за кордон це і є найбільший буст для кар’єри в аутстафінгу якщо подивитись за прикладами. Переважна кількість вищих керівників галер — або за кордоном прямо зараз, або довго там були і їх повернули «ставити процеси».
Другий варіант — йти в інші більш складніші бізнес моделі, а це вже напряму йде до американских термінів які на загал означають — підприємливість.

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

Так це так швидше рецензія на типовий комент я би так сказав. Дуже поважний мною fellow з минулого місця роботи рекомендував усім книгу Джона Сомнеса, що після 17 років в С++ програмуванні став консультантом. Книга так і зветься — Soft Skils www.amazon.com/...​pers-manual/dp/1617292397
Коли я її прочитав в мене теж виник когнітивний дисонанс з багатьох питань. Аналізуючи багато з того, що там написано не накладуться на аутстафінговий бізнес в цілому. З тими же кадровими питаннями у мене певним чином було величезне запитання — як так? Чому — колхоз, комомол або принципи мафії ? (я працював в 4 конторах і усякого побачів і почув, особливо в перших двох)
А усе просто це одна з тих штук як Late-night talk show які без адаптації на наш контекст, не приживаються, а адаптувати доволі складно. Та якщо проаналізувати, що там написано адаптувати звісно можна. Про що книга — а вона про те, що завжди думайте за бізнес, тобто за гроші. Коли ви йдете на роботу в найм це такий самий бізнес як і відкриття власної компанії. Тоді стає ясно, що увесь так званий Emotional intelligence і т.п. це навіть не шахи — це гра в шашки причому в Чапаєва, просто торгівля на базарі. Чого вони хочуть — та просто бабла та влади вони хочуть мало не поголовно, та і усе, ще щоб було спокійно та ніхто не тріпав нерви, а друге не можливо бо перше породжує конкуренцію. Якщо є ресурс за нього завжди буде боротьба. І уся адаптація зводиться до того, що усе крутиться навколо грошей і торгівлі. І якщо ти багатий і відомий веди себе як : Ілон Маск, Періс Хілтон, Дональд Трамп тощо, це насправді лише реклама — а поганої реклами не буває, головне монетизувати відомість та витівки в гроші, наприклад робити різні заяви з метою коливання курсу акції, на чому можна заробити через партнерів на біржі. Або під якусь скандальну голу вечірку рекламувати трусики відомого бренду, бо вони з’являться по усій жовтій пресі і на них подивляться, на відміну від дорогих банерів. Так що як не дивно, але скажімо цей автор dou.ua/users/vkozhaev/articles яки би ядовито з поверхні не виглядали його тексти, дає набагато більш адаптовані під наш ринок кар’єрні поради. Про витівки, як відомо з реклами на пострадянському просторі більше за усе зайшов Леня Голубков, улюблений персонаж DOU, з чого треба робити відповідні висновки, наприклад Голобородько це калька з Лені Голубкова.

Я не писала що ще дріб’язок і включила їх у свій список. Без них як і без трьох інших неможливо досягти певного рівня.
До прикладу, дуже багато світчерів на сьогодні маю три не хардові компетенції на високому рівні, але саме харди змушують їх починати шлях з початку і мати title — junior або ж trainee.

в епоху ШІ ми маємо швидко відходити від оцінки людей за hard skills, тому що їх замінити найпростіше

Ага, аякже. Потім не жалійтеся на якість програмних продуктів.

Номер 1. Відповідальність. А де ще три? Щось зі структурою тексту не так

Класна стаття, дякую авторці!)

Стаття не про soft skills, а про рівні компетенції.
Також можу порекомендувати ознайомитися з різницею між Competence vs. Competency www.indeed.com/...​/competence-vs-competency

А в чому радянський термін компетенція відрізняється від американского армійського терміну терміну Soft Skils ?

Професійна компетенція — вміння використати знання, навички, досвід в конкретно даних умовах, досягнувши при цьому максимально позитивного результату.
uk.wikipedia.org/wiki/Компетенція

The word «skill» highlights the practical function. The term alone has a broad meaning, and describes a particular ability to complete tasks ranging from easier ones like learning how to kick a ball to harder ones like learning to be creative. In this specific instance, the word «skill» has to be interpreted as the ability to master hardly controlled actions.
en.wikipedia.org/wiki/Soft_skills

Так в украинскому і не тільки ІТ однозначного загального розуміння обох термінів нема зовсім. Напевно це в дечому показує наш загальний рівень компетентності, тому і застрягли в аутсафінгу та тримісячних курсах frontend, найпростіших бізнес моделях аля базар, там де можна обійтись найнижчими рівнями компетентності (звісно не усі та переважно).

Тим що радянський підхід — сім разів відміряй, один — відріж, а американський — fake it till make it.

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