Ролі в ІТ і їх обов'язки | Бізнес Майстерня

Ролі в ІТ і їх обов'язки

Ролі в ІТ і їх обов'язки

механізм

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

Групи ролей

Ролі в ІТ можна розділити за кількома зрізами:

  • за активністю;
  • за відповідальністю;
  • за завантаженістю.

Поділ за активністю:

  • виробники;
  • управлінці;
  • перевіряючі.

Поділ за відповідальністю:

  • без відповідальності
  • з відповідальністю за якість
  • з фінансовою відповідальністю

Поділ за призначенням:

  • наймані на позицію;
  • виховувані в колективі.

Опис ролей

Назви ролей будуть використовуватись американські, звідки, по-суті, вони родом. Велика частина назв запозичена з англомовної спільноти.

Developer.

Характеристики:

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

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

сходи

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

Дана роль часто сегментується з розділенням відповідальності:

  • Back-end developer - розробник програмно-апаратної частини комплексного ПЗ;
  • Front-end developer - розробник клієнтської сторони призначеного для користувача інтерфейсу до програмно-апаратної частини.

Так само, роль сегментується по платформах, під які ведеться розробка, наприклад:

  • Web;
  • Mobile;
  • Server-Side;

і так далі. А для більш зручної роботи рекомендуємо користуватись ось цими розширеннями для VS-code:

User Experience Designer (UX)

Характеристики:

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

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

Помилково цю роль плутають, а часом і поєднують з роллю UI Designer (див. нижче). UX vs UI Designer відрізняються не тільки предметною областю, а й специфікою мислення. UX Designer більше про аналітику і систематизацію, ніж про ергономіку і естетику.

User Interface Designer (UI)

Характеристики:

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

Ця роль розробляє візуальну частину призначеного для користувача інтерфейсу. Основними цілями роботи UI дизайнера є: интуїтивність сприйняття, простота, юзабільність і естетика інтерфейсу ПЗ.

Quality Assurance (QA)

Характеристики:

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

QA займається тестуванням всього, як би дивно це не звучало.

Системний підхід фахівця QA дозволяє тестувати як програмний код, так і продуманість карт користувацького досвіду.

команда

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

Human Resource (HR)

Характеристики:

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

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

Обов'язки HR часто замішані з наступною роллю, яка на більшості ринків праці трактується так, як хочеться керівництву компанії.

Team Leader

Характеристики:

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

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

Це важливо розуміти:

  1. Team Leader завжди вирощується в середовищі, це єдиний спосіб заробити авторитет в групі людей; немає авторитету, ніхто не буде слухати Team Leader, процеси йтимуть своїм шляхом;
  2. Можна процес вирощування прискорити, найнявши одного з досвідчених Team Leader, але в колектив він повинен потрапити спершу як рядовий фахівець, заробити авторитет, тільки потім перейти на цільову позицію;
  3. Роль більше не про управління командою, не про виробництво, а про рішення проблем в роботі команди, налагодження комунікації всередині команди, вибудовування комфортних умов виробництва;
  4. Team Leader зобов'язаний володіти аналітичними навичками та системним поглядом; просто робити, щоб всім було "добре" мало, основне завдання - постійне вимірювання внутрішніх метрик команди, як соціальних, так і виробничих, зміна процесів для підвищення результативності.

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

Tech Leader

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

Особливостей всіх ролей, в назві яких є слово Leader, є те, що всі вони вирощуються в колективі (див. вище).

Але дану роль ми вирішили виділити, так як, на практиці, її найчастіше плутають з роллю Team Leader.

Tech Leader так само вирощується в колективі, команді потрібен авторитет, щоб впевнено доносити свої думки і рішення з технічних питань.

Tech Leader торкається таких аспектів роботи команди:

  1. Відповідальний вибір стороннього ПЗ для проекту;
  2. Рекомендація по вибору конкретного алгоритму або архітектурного рішення при виробництві ПЗ;
  3. Визначення технічних особливостей в процесах виробництва.

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

код

Scrum Master

З появою термінів Scrum, Agile, KanBan, гнучкі методології, і інші теоретичні знання, які вкрай не приносять користі без практики/досвіду, до команд розробки стали прикріплювати роль Scram Master.

Характеристики:

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

Чому ми вирішили описати дану роль? Так склалося, що цю роль часто плутають з Project Manager.

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

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

Project Manager (PjM)

Характеристики:

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

Ця роль класичного управлінця процесами. Робота над проектом починається з Project Manager`а, ведеться (ставляться завдання), контролюється (контроль якості та ефективності), і здається теж ним. У більшості компаній Project Manager управляє проектним фондом. Про грамотний розрахунок по digital-проекту читайте в цій статті. Коли швидкість реалізації швидше планованих термінів проекту, проектний фонд утилізується не повністю, залишається частина грошей, які за результатом успішної здачі проекту розподіляється на премії учасників. Розподілом також займається Project Manager.

Фото: flickr.com
Обробка: Vinci
назад
далі