Роли в ИТ

РОЛИ В ИТ

https://t.me/WangoffIT/2380

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

Знаю, в гугле может быть написано не так и подробнее. Хорошо, если вы до него доберетесь. Но по факту – описал то, как видится сейчас. По крайней мере, мне. Где не прав – давайте, соберите мысли в кулачок и отпишите в коментах.

Лайк, шер, репост.

ЧАСТЬ 1

Разработчик 

Пишет код. Внутренне тестирует. Не пишет ФТ и ТЗ. Периодически проклинает тех, кто ставил задачу.

Техлид/Тех.Архитектор 

Придумывает архитектуру, иногда пишет код, знает весь стек и мудр не по годам. Декомпозирует ФТ в ТЗ и ЧТЗ. Общается с теми кто пишет ФТ, сисадминами и менеджером проекта. Контролирует своих разработчиков.

Системный администратор

Отвечает за то, чтобы сервера работали, пинги ходили, 1С, Битрикс, SAP и прочее – было развернуто на нужных серверах и версиях SQL/PosgerSQL. Пользователи могли залогиниться. AD работало. VPN коннектил. Хороший сисадмин общается с обычным человеком один раз. Если на проекте все хорошо – вы о нем не вспомните.

Системный аналитик 

Выясняет, что на самом деле хочет бизнес и превращает в требования к системе. Моделирует. Пишет протоколы. Рисует схемы. 

Бизнес-аналитик

Находит способы получить бизнес-ценность. Анализирует данные и процессы. Предлагает: если сделать вот так, то получим рост/снижение на вот столько. Не обязан уметь в код. Желательно, если умеет в BI и запросы.

Консультант

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

Тимлид/Функц.Архитектор

Руководит аналитиками. Является основным заказчиком ТА. Отвечает за то, что ФТ правильные, они реализованы и протестированы. Понимает язык бизнеса. Пишет или проверяет ФТ.

Тестировщик/QA 

Тестирует руками. Тестирует скриптами. Другими тестировщиками.

Релиз-менеджер 

Отвечает за то, чтобы после релиза не упал прод, а пользователи получили вменяемое описание изменений

Менеджер проекта 

Главный злодей. Либо со стороны бизнес-заказчика, либо со стороны ИТ-команды. Отвечает за Качество, Сроки, Бюджет, счастье заказчика, счастье пользователей (по остаточному принципу). Эскалирует о проблемах Директору проекта, куратору, гендиру и т.д. 

Технический менеджер 

Иногда. Менеджер проекта, который отвечает за содержание. Но сверху его контролирует Руководитель проекта. В основном отвечает за содержание и настройку работы команды.

Product owner 

Отвечает за то, что и как мы будем делать с системой, чтобы это было полезно бизнесу. Обычно живет на стороне заказчика. Не должен уметь в ИТ. Должен быть вменяем и готов погружаться. Приоритизирует задачи, объясняет остальному бизнесу, когда и что будет сделано и почему

Devrel 

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

Delivery manager 

Почти Project manager, но нет. Чуть меньше админ, чуть больше технарь. Предлагает бизнесу современные ИТ-решения их проблем. Отвечает за то, чтобы бизнес получил то, что нужно. А не как обычно.

Account Manager

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

Solution Architect 

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

Бизнес-архитектор/ Enterprise Architect

Знает, как устроен ИТ-ландшафт компании и как ходят данные. Может ответить на вопросы: что есть мастер-система по Договорам, как дружит CRM и WMS. Как правило, зануда.

Ресурс-менеджер 

Отвечает за то, чтобы его сотрудники развивались и раскрывали потанцевал. Может называть Начальником отдела, руководителем группы и бог знает как еще. Не HR. Может так же заниматься поиском ресурсов под проекты компании

Product manager 

Отвечает за то, что продукт, который получается на выходе – кому-то нужен. Питчит идеи, ресерчит рынок, придумывает направление развития продукта, держит беклог. В проектах – отвечает за не-делание ненужного и делание нужного, обычно ФА или менеджер проекта.

Стейкходлер 

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

Спонсор проекта

Тот, кто дает деньги. Обычно – CEO, CFO или кто-то из других C-2 менеджеров. Желает не погружаться в детали и получить ответ на вопросы: сколько стоит, что нам это даст, что будет если не делать. В случае, когда работы выполняет ИТ на подряде, спонсор – это топ-менеджер подрядной компании.

Куратор проекта

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

Sales manager 

Продает проекты за много денег большим компаниям. Переговаривает переговоры. Много пьет. Может ничего не знать про ИТ. Знает много тех, кто знает про ИТ. Дружит со всеми. Не верит в слово НЕТ. Очень гибок. Обладает широким кругом знакомств

Функциональный заказчик

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

Head of PMO/Руководитель проектного офиса

Руководит менеджерами проектов. Отвечает за то, чтобы можно было отследить ход более одного проекта по схожим метрикам. Фанат PMBoK

Бизнес-заказчик 

Любой, кто не является частью ИТ-команды. Для общения с ним обычно требуется переводчик в лице менеджера, архитектора, тимлида, аккаунта

Методолог

Придумывает методику. Никто не знает, что это. Но он знает. Знает все нормативные акты. Знает, почему просто списать расходы на такси на 26 счет – невазможна. Много говорит. Либо мало, что еще хуже.

Технический эксперт

Знает, почему система тормозит. Хороший эксперт – знает, как это исправить. 

DevOps 

Отвечает за то, чтобы все, что сделала разработка – магическим образом автоматически собиралось и доезжало в рабочую базу. А по дороге мониторило число ошибок и сколько нужно потратить на исправление кода, написанного не по стандарту. Получает много денег, никто не знает за что. Но это очень важно. Особенно важно становится, когда система сложнее чем учетная система для магазина приколов.

Кого не хватает?