ІТ дивокрай або хто є хто

Вступ

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

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

Цікавий факт:

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

Частина 1: Керроллівські мотиви та верхівка ієрархії

Той, хто читав про пригоди Аліси у Дивокраї або дивився екранізацію, може мене запитати, чому обрано таку дивну назву? Як Білий Кролик, Блакитна Гусінь, Капелюшник та Чеширський Кіт пов’язані з ІТ-фахівців? Відповідь буде така: «Почекайте трішечки та самі все побачите, бо за креативністю устрій ІТ-компанії нічим не поступаються творчості Керрола, а, може, навіть і випереджає».

При розгляді корпоративної ієрархії пропоную керуватись принципом капусти, тобто йти із зовні до середини, тож, почнемо із верхівки. Майже всі найвищі посади формуються за однією формулою і більшість з вас, ймовірно, чули ці чудернацьки абревіатури: СЕО, СОО, СТО і так далі, але що вони означають? Спосіб їх утворення і містить відповідь на це питання. Для початку розберемо, як формуються абревіатури. Наприклад, Chief *** Officer. Замість зірочок згадується слово, пов’язане з безпосередньою сферою діяльності – Marketing, Executive, Financial тощо. Якщо дослівно перекласти з англійської мови отримуємо таке: Chief – головний, Officer – офіцер => Chief *** Officer – головний офіцер. Перетворимо результат на терміни, прийняті в бізнес-сфері: головний офіцер => вищий керівник => директор. Відповідно, будь-які абревіатури на кшталт Chief***Officer розшифровують як директор з… фінансів, маркетингу або чогось ще. А ось що роблять усі ці люди і в чому між ними різниця варто розглянути детальніше:

1. CEO (Chief Executive Officer або Головний виконавчий директор): Це головна особа в компанії, яка приймає стратегічні рішення та керує всім бізнесом. Він аналізує ситуацію на ринку, встановлює цілі компанії та вирішує, як досягти успіху, веде високорівневі переговори і спілкується з інвесторами та партнерами.
2. COO (Chief Operating Officer або Головний оперативний директор): Це людина, відповідальна за щоденну діяльність компанії. Вона допомагає забезпечити, щоб всі процеси працювали гладко. COO керує командами, контролює роботу і допомагає розв’язувати проблеми.
3. CTO (Chief Тechnical officer або Головний технічний директор): Ця роль зосереджена на технічних аспектах. CTO керує технічними командами, розробляє стратегію розвитку технологій, контролює проєкти та забезпечує, щоб продукти були інноваційними та відповідали вимогам ринку.
4. CIO (Chief Information Officer або Головний інформаційний директор): Ця роль відповідає за інформаційні технології та системи в компанії. CIO забезпечує, щоб комп’ютери, мережі та програмне забезпечення працювали надійно та безпечно.
5. CFO (Chief Financial Officer або Головний фінансовий директор): Він займається фінансами компанії. CFO контролює бюджет, веде облік доходів та витрат, розробляє фінансові стратегії та допомагає збільшити прибуток компанії.
6. CMO (Chief Marketing Officer або Головний директор по маркетингу): CMO визначає і затверджує маркетингову стратегію компанії. Він керує діяльністю всіх маркетингових служб організації.
7. CSO (Chief Security Officer або Головний директор з безпеки): CSO організовує і забезпечує фізичну безпеку, кібербезпеку та інші види безпеки в компанії.
8. CPO (Chief People Officer або Головний директор по людським ресурсам): Відповідає за стратегічне управління персоналом компанії, включаючи підбір, навчання, розвиток та збереження.

Усі вищенаведені посади відносяться до так званого С-level, тобто рівня вищого керівництва, тому, якщо чуєте назву посади з трьох літер та вона починається на «С», то перед вами преславне «начальство». Варто зауважити, що ми розібрали тільки основних представників С-level і хоча цей перелік десь у 2-3 рази довше, але в наших широтах із вірогідністю 90% інших посад ви не побачите. До речі, оскільки в англійській мові літера «С» може звучати, як «К», так і як «С», то мені на думку спала слушна фраза для запам’ятовування: «Хто на К, той і керує!».

Цікавий факт:

Не зважаючи на те, що більшість світових та українських ІТ-компаній є порядними та чесними до своїх працівників (як і та, в якій я зараз працюю, привіт і велика дяка колегам з 1World Online), деколи можна почути історію про так звані «галери». Тобто компанії мають настільки погане ставлення до співробітників та умови праці, що робочий день там максимально нагадує буденність римських рабів. Саме про такі компанії існує мем, яким я не міг не поділитись (Переклад надпису: Коли хлопець зверху дивиться вниз, він бачить лише лайно. Коли хлопці знизу дивляться вгору, вони бачать лише гівнюків).

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

1. Складний переклад: оскільки назви не всіх посад можливо перекласти на українську або будь-яку іншу мову так, щоб релевантно співвіднести із локальними назвами, виникла загальноприйнята практика залишати все в оригіналі.
2. Спрощення взаємодії: коли мова йде про міжнародну співпрацю, наприклад замовники з США, а компанія-виконавець з Польщі, то їм буде простіше домовитись, якщо обидві сторони керуються загальновизнаними стандартами.
3. Нестандартність: завжди приємно знати, що таке, як в нас, більше не має ніхто, бо це трохи підігріває наше самолюбство і дає змогу відчути себе особливими, і українські ІТ-фахівці не стали винятком. Оцей наш внутрішньогалузевий шифр особливих назв на все: посади, інструменти, робочі процеси й таке інше, неабияк згуртовує  людей навколо спільної таємниці.

Стосовно ж української реалізації, тут є що розказати та над чим поміркувати. Питання в тому, що з всесвітніми стандартами ми все узгодили, а ось із внутрішніми трохи не склалось. Проілюструю це явище на прикладі посади CTO (Chief technical officer або Головний технічний директор):

• У стартапі на 10 осіб CTO зазвичай виконує функції керівника команди, але отримує гарну назву з двох причин: щоб потішити власне его і з розрахунку на те, що в майбутньому він займе цю роль. Пояснюється це тим, що людина відповідає не за конкретну команду, а за розвиток усієї технологічної частини зараз і в майбутньому.
• У компанії на 100 осіб основне завдання CTO – відповідати за виконання технічної частини продуктових планів компанії, розвивати компетенції технічного відділу, синхронізувати підходи різних команд до розробки, сприяти стійкості технічної частини бізнесу.
• У компанії на 1000+ осіб фокус CTO йде на наймання і розвиток керівників, управління технічними лідерами напрямків, і відповідальність за виконання технічних планів.
• У компанії на 10 000+ осіб CTO відповідає за довгострокове технічне бачення компанії та виконання стратегічних планів.

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

Ну, що, шановні читачі, останній приклад нікому не нагадує чарівні зміни Аліси у зрості із відповідною зміною властивостей? А опис C-level посад не викликає спогадів про гру слів на божевільному чаюванні Аліси, Капелюшника, Шаленого Зайця і Сонька? А сама Аліса не нагадує ІТ-фахівців, які попри усі складності все одно продовжують розвиватись та працювати (між іншим, ІТ-галузь посідає друге місце за кількістю сплачених податків минулого року, тож виходить, що вони є непоганою підпорою економічного фронту)? Якщо відповіді позитивні, то ви непогано знайомі із творчістю Керрола та маєте гарну уяву!

Частина 2: Кваліфікація, склад команди та самоусвідомлення

Зрозуміло, що в основну частину працівників будь-якої ІТ-компанії складають аж ніяк не керівники, а звичайні спеціалісти, тому у цій частині мова буде йти саме про них, звичайно, приділяючи особливу увагу напрямку QA. Для початку треба зауважити, що кожний працівник має свій рівень кваліфікації та напрямок діяльності. З кваліфікацією ситуація не проста, але й до С-level їй далеко. Існує 4 основних рівнів кваліфікації: Trainee, Junior, Middle та Senior, пропонує детальніше розглянути кожен з них:

1. Trainee:
   • англійська рівня Intermediate+
   • стек технологій обраної спеціальності: ідеальні знання теорії та мінімальні практичні навички
   • без практичного досвіду або з мінімальним (1-3 місяці)
   • нещодавно завершив профільні курси або профільний навчальний заклад
   • якості: гнучкість, стресостійкість, навченість, комунікабельність, вміння слухати, навички роботи в команді
2. Junior
   • самостійність
   • виконання технічних завдань без контролю ментора
   • відповідальність за власну роботу
   • комерційний досвід від 6 місяців
   • якості: енергійність, цілеспрямованість, раціональне ставлення до критики, стресостійкість, наполегливість, бажання розвитку
3. Middle
   • розуміння вимог бізнесу
   • провідник інформації між бізнесом та технічною частиною
   • цілісне бачення готового продукту, можливість внесення корективів до загального плану розробки ІТ-речей
   • вдосконалення технічних навичок
   • 2-3 роки комерційного досвіду
   • якості: управлінські навички, менторство, стресостійкість, робота в команді, комунікабельність, лідерські завдатки
   • зовнішні атестації
4. Senior
   • повний стек технологій основної спеціалізації та суміжні дисципліни
   • розуміння та комунікація з бізнесовою стороною
   • максимізація якості результату та мінімізація витратних ресурсів
   • висока відповідальність за власні дії та рішення
   • оцінка ступеня розробки програмного забезпечення, ризиків тощо.3-5 + років успішного комерційного досвіду на різних проєктах
   • зовнішні атестації

Виникає питання, а що буде після 5 років, все, кар’єра завершилась? Авжеж, ні, далі вас можуть призначити на посаду керівника команди (Team Leader), далі керівником всього напрямку (Head of ***), а далі ви вже потрапляєте в оту чарівну категорію посад з трьох літер і на «С». Варто зазначити, що вищезазначені рівні кваліфікації зазвичай є посадами працівників, що є дуже зручною практикою: назвав свою посаду і все про тебе ясно. Також треба додати, що строк комерційного досвіду не завжди визначає кваліфікацію, бо ключовим тут є стек технологій та навичок, а не витрачений час.

Цікавий факт:

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

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

1. Project Manager (Керівник проєкту): Це людина, яка відповідає за управління всім проєктом. Вона збирає всі необхідні ресурси, встановлює графік, розподіляє завдання, контролює виконання та забезпечує, щоб проєкт був завершений вчасно та успішно.
2. Business Analyst (Аналітик бізнесу): Ця роль зосереджена на розумінні потреб бізнесу та вимог до проєкту. Аналітик вивчає бізнес-процеси, збирає інформацію, створює вимоги до програмного забезпечення та допомагає визначити, як проєкт буде впливати на компанію.
3. Software Developer (Розробник програмного забезпечення): Це ті, хто створює код і програми. Розробники перетворюють вимоги та дизайн в робочий програмний продукт. Вони можуть бути програмістами, фронтенд або бекенд розробниками, залежно від специфіки проєкту.
4. Quality Assurance Engineer (Інженер з контролю якості): Ця роль забезпечує, що продукт відповідає вимогам і працює належним чином. QA інженери проводять тестування, знаходять та виправляють помилки, переконуються, що програмне забезпечення є надійним і функціональним.
5. UX/UI Designer (Дизайнер користувальницького досвіду/інтерфейсу): Ця роль відповідає за створення зручного та привабливого інтерфейсу для користувачів. Дизайнер працює над зовнішнім виглядом програми, забезпечуючи зручність взаємодії для користувачів.
6. System Administrator (Системний адміністратор): Ця роль відповідає за налаштування та управління інфраструктурою та серверами, необхідними для роботи програмного забезпечення.
7. DevOps Engineer: DevOps інженери забезпечують співпрацю між розробниками (Developers) та адміністраторами (Operations), щоб забезпечити швидке та безпечне постачання програмних змін.

Детальніше хотів би зупинитись на тому напрямку, до якого належу сам, і до якого належать більшість наших читачів – Quality Assurance. З одного боку, все досить просто: якість є якість, і нема тут що казати, але ні, світова спільнота ставить питання чіткішої самоідентифікації фахівців, і ось тут починається саме цікаве…

Існує два основні погляди на систему розподілу. Першим розглянемо застарілий — той, що представляють у вигляді кіл Ейлера:

Тобто за цією версією виходить, що тестувальник — людина недалека: іде суто по написаному та просто порівнює, а якщо щось не так, то документує. QC — покращена версія тестувальника, яка може створювати сценарії перевірки, але ні на крок не відходить вимог, а ось QA — це вже мега-спеціаліст, який і вимоги подивиться і підкорегує, і за попередніми двома придивиться і з розробником про «не фіча, а баг» посперечається. Як по мені, відчувається значний перегин: тестувальником можна майже будь-кого «з вулиці» брати, а QA повинен бути на всі руки майстром.

А тепер розглянемо інший погляд, новіший, який був запропонований у ISTQB, і який вважається у спільноті якіснішим:

• Testing (Тестування) – процес, пов’язаний з плануванням, підготовкою та оцінкою програмних продуктів і пов’язаних з ними робочих продуктів для визначення того, чи задовольняють вони визначені вимоги, щоб продемонструвати, що вони придатні для використання за призначенням і виявити дефекти.

• Quality (Якість) – ступінь, до якого компонент, система або процес відповідає визначеним вимогам та/або потребам і очікуванням користувача/клієнта.
• Quality management (Управління якістю) – загальний термін, що охоплює координовані дії та процеси, спрямовані на керування та контроль якості в організації. Це включає стратегічне планування, прийняття рішень, організаційні структури, а також визначення цілей і стандартів якості. Головною метою управління якістю є забезпечення високої якості продуктів або послуг, які відповідають вимогам та очікуванням клієнтів.
• Quality assurance (Забезпечення якості) – частина управління якістю, яка спрямована на надання впевненості, що вимоги до якості будуть виконані. Quality assurance включає встановлення процесів, стандартів та методів, які допомагають гарантувати якість продуктів або послуг на всіх етапах виробництва чи надання. Ці фахівці оцінюють, чи були правильно упроваджені процеси контролю якості.
• Quality control (Контроль якості) – частина управління якістю, що зосереджується на операційних техніках та діяльностях для виконання вимог щодо якості. Quality control переконується, що продукти або послуги відповідають встановленим стандартам та вимогам. Ці фахівці займаються тестуванням, інспекцією, вимірюванням та іншими процедурами для виявлення дефектів або невідповідностей.

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

А тепер спробуємо подивитись на вакансії для початківців на українському ринку праці по нашій галузі: 60% компаній хочуть собі QA, десь 30% хочуть QC, а решта хоче тестувальників, але нюанс в тому, що всі вакансії мають майже той самий опис та посадову інструкцію. То хто ж їм потрібен? Звичайно, як ви вже здогадались, загальноприйнятої правильної відповіді на це питання не існує, тому далі розповім свою ОСОБИСТУ думку стосовно цього питання на прикладі декількох ситуацій:

• Якщо ви будете йти по вже написаним інструкціям та тільки порівнювати очікуваний результат із фактичним та документувати розбіжності, при цьому не маючи права написати свої власні сценарії або піддати сумніву деякі  пункти документації, то ви фахівець із низькою кваліфікацією та зазвичай маєте назву тестувальник (у найпростішому сенсі цього поняття). Відверто кажучи, таких посад вже не існує років 10-15, ці функції просто делегували іншим, кваліфікованішим фахівцям.
• Якщо ви будете йти по сценаріях та документувати розбіжності, але при цьому самі їх створювати та визначати послідовність, та керуватись не тільки вимогами, а й загальноприйнятими стандартами, то ви фахівець середньої кваліфікації та зазвичай маєте назву QC (або тестувальник у найбільш загальновживаному сенсі цього поняття). Такі посади зараз мають середню популярність і зустрічаються у великих компаніях, де є керівник команди, який визначає загальні обов’язки, але особливості виконання залишає на працівника.
• Якщо ж ви й сценарії пишете, і, якщо компанія невелика, самі їх реалізуєте, і вимоги не сприймаєте за абсолютну істину та піддаєте їх критичному мисленню, і, якщо компанія велика і ви маєте підлеглих, ще контролюєте їх активність, то ви фахівець із великою кваліфікацією та зазвичай маєте назву QA (або тестувальник у кращому сенсі цього поняття). Такі посади зараз мають найбільшу популярність, бо ви виходите майже на всі руки майстром та вигідніше платити одному такому фахівцю, ніж двом або трьом, але із нижчою кваліфікацією.

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

Наостанок, хотів би нагадати, що фахівці галузі забезпечення якості також мають багато різних спеціалізацій (крім того, що вони можуть бути Manual, тобто робити все власноруч, Automation, тобто за допомогою скриптів та автоматизації, або General, тобто всього потроху), іноді навіть не одну. І хоча це не зовсім про початківців, а вже про досвідченіших колег, але нехай перелік основних спеціалізацій буде для читачів, як то кажуть, «на виріст»:

1. Функціональність: спеціалісти, що перевіряють різні сценарії використання, переконуючись, що функції програми працюють правильно.
2. Безпека: спеціалісти, які займаються захистом продукту від несанкціонованого доступу та можливих загроз.
3. Продуктивність: спеціалісти, що перевіряють як програмне забезпечення працює при тривалому використанні під навантаженням.
4. Бази даних: спеціалісти, які займаються перевіркою коректністю та ефективністю дії баз даних.
5. Мобільні додатки: спеціалісти, що перевіряють додатки саме на мобільних пристроях, щоб забезпечити їх коректну роботу.
6. Настільні додатки: спеціалісти, що перевіряють додатки саме настільних або desktop додатків.
7. Веб-додатки: спеціалісти, які займаються саме додатками на базі веб-технологій,  впевнюючись в правильному відображенні та працездатності.
8. Сумісність та інтеграція: спеціалісти, що перевіряють, як програмне забезпечення працює на різних операційних системах, браузерах та на різних платформах.
9. Локалізація: спеціалісти, які займаються орієнтацією продукту на різні мови та культури.

Підсумок

У цій статті я розповідав вам, шановні читачі, про особливості устрої компанії в ІТ-галузі. Спочатку ми поговорили про актуальність даної теми («далі програміста діло не піде…»), потім розглянули верхівку корпоративної ієрархії («Хто на «С», той і керує!»), приділили увагу причинам використання  та складностям реалізації такої структури (займаючи одну й ту ж саму посаду, людина може мати різні посадові інструкції в залежності від місця роботи), згадали про рівні кваліфікації та кар’єрний шлях працівників, які зазвичай вважаються назвами посад (Trainee, Junior, Middle, Senior та Team Leader і Head of ***), розглянули основні ролі у команді на проєкті (PM, BA, Dev, QA, UI/UX, Sysadmin, DevOps), приділили багато уваги процесу забезпечення якості, розглянувши два варіанти його організації (кола Ейлера та за ISTQB), піднявши питання самоідентифікації (Tester, QA, QC, QM) та згадавши про основні напрямки майбутнього розвитку (Functional, Security, Performance, Data Bases, Mobile, Web, Desktop, Compatibility and integration, Localization).

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

На завершення, хочу навести одну з найпопулярніших фраз Аліси, яка, з моєї точки зору, є непоганою порадою для всіх початківців у ІТ-сфері: «Чим більше відразу вчишся, тим менше після мучишся!».