Весь мир — театр. В нём женщины, мужчины — все актёры. У них свои есть выходы, уходы, И каждый не одну играет роль. Уильям Шекспир.
Моя основная деятельность — разработка на 1С, потому перефразирую строчки Шекспира (да простит он меня) под свою реальность:
Весь мир — один большой проект. В нём аналитики, тимлиды- все в команде. У всех свои задачи на квадранте И каждый не одну играет роль.
Я, конечно, не актёр и не поэт, но хочу разобрать тему ролей в своём "Квадранте" и на живом примере.
Краткая предыстория.
До недавнего времени я была обычным работником компании, который в основном отыгрывал на проекте роли разработчика с примесью архитектора системы, тестировщика и капелькой бизнес-аналитика — прекрасное амплуа машины для убийства Upgrate-разработчика, перешедшее ко мне по наследству от n-ого количества уволившихся коллег. Почему была "обычным работником"? Потому что
пришла задача -> подумала о решении -> сделала
Никакого абстрагирования от разработки (кто, какие роли отыгрывает, какие процессы происходят внутри команды, а точно ли мне делать именно это и т.п.), лишь действия. Тем не менее система работала: процессы выполнялись, задачи сдавались+- в срок, заказчик получал продукт нашей деятельности, давал обратную связь и т.д. Теперь этот проект на стадии завершения (передача в тех. поддержку) и мои силы перебросили на другой.
Незадолго до начала обучения в ШСМ меня приставили к другому проекту с целью помочь с разработкой и немного с архитектурой. Поначалу процессы внутри нашей команды казались работающими. Единственное — немного срывались сроки (довольно часто встречающаяся проблема).
Но по мере приближения дня показа в воздухе стал ощущаться стойкий аромат хаоса и неразберихи. По итогу оказалось, что не все знали/понимали, какая роль на них возложена в данном проекте, из-за чего образовывались дырки в процессах, что приводило к упущению важных моментов.
А что по проекту?
- Разрезы ролей.
Перебесившись от происходящего, я начала задумываться: в какой момент, что, почему пошло не так. И для начала решила выписать роли, которые должны быть в проекте, чтобы процессы внутри команды работали как часы: ровно, четко и спокойно.
Disclaimer!
Данный разбор не претендует на истину в последней инстанции. В моём видении некоторые роли имеют небольшой вес, поэтому могут быть упущены.
На проектные роли можно смотреть сразу в двух разрезах: тип стороны (Исполнитель - Заказчик), и тип деятельности (Управление - Исполнение). В статье я буду описывать только сторону Исполнителя, но сделаю заранее небольшую ремарку, что рассматриваемые роли могут пересекаться и со стороной Заказчика.
- Список ролей.
Роли проекта я буду рассматривать, как многоуровневую систему. Например, роль Системного администратора может включать в себя роли Энекейщика, Сетевого администратора, Администратора БД и т.д. Так как в компаниях зачастую определённый пулл ролей назначают на одного человека (и я сейчас говорю НЕ ПРО ДОЛЖНОСТЬ), в своей модели я буду использовать обобщающие роли типа Системного администратора.
Перейдём же к самому списку ролей. Кто же должен участвовать в ИТ-проекте, чтобы процессы работали как часы?
В порядке живой алфавитной очереди.
Архитектор.
Человек-голова. Его основная деятельность заключается в формировании архитектуры, оценке имеющихся технических возможностей, формировании взаимосвязей со смежными системами и написанием проектной документацией. Так же он должен уметь отбивать разные дурацкие идеи вроде
Бизнес-аналитик.
Человек-переводчик, главный коммуникатор между заказчиком и командой в части сути проекта. В совершенстве владеет 13 диалектами клиентского языка, отвечает за написание и поддержание в актуальном состоянии требований проекта, проводит интервью с заказчиком, обрабатывает, документирует его и передаёт Исполнителям, участвует как ревьюер в проектировании верхнего уровня и обеспечивает выполнение всех критериев завершения проекта.
Куратор проекта.
Человек-Царь-батюшка. Он курирует проект, обеспечивает общий контроль и поддержку проекта финансовыми, материальными, человеческими и другими ресурсами. Куратор проекта отвечает за достижение проектом конечных целей и реализацию выгод для организации.
Менеджер проекта.
Человек-планер. Как по мне — это самая организационная составляющая команды. Он отвечает за достижение целей проекта в рамках бюджета и сроков, организацию работы и контроль процессов проектной команды, согласование проектной деятельности с заказчиком, управление рисками и т.д. Его девиз:
Разработчик.
Человек-строитель. Надо больше кода богу кода! Он сидит в тёмном углу офиса, заросший свитером, бородой и кофе, разрабатывает код проекта по ТЗ, получает фидбэк от тестировщиков (или тех, кто первым заметил) и бьёт нерадивые баги костылями. Его розовая мечта — собрать проект с первого раза без ошибок.
Системный администратор.
Человек-паук (не тот, что в комиксах). Дед, который постоянно ворчит, что все, кто разворачивал до него систему — жопорукие кривомозги. Отвечает за ту часть архитектуры, которая относится к физическому распределению систем по серверам, организует взаимодействия систем, выявляет проблемы на боевой и тестовой средах, ломает четвёртую стену и прокладывает VPN даже там, где не ступал ни один бит информации.
Тимлид.
Человек-бригадир. Можно назвать ведущим разработчиком. Отвечает за распределение задач внутри разработчиков, а также за код, который летит в продакшн. Его девиз: "Не можешь остановить трэш-разработку — возглавь её (и сделай код-ревью)".
Тестировщик.
Человек-муравьед. Вынюхивает все баги, пишет тест-планы на основании требований, проводит функциональное тестирование системы. В начале рабочего дня молится своим богам, чтобы от заказчика не было ни одного репорта об ошибках.
А теперь распределяя роли лёгким движением руки по зонам Управление-Исполнение мы можем понять, кто тварь дрожащая, а кто право имеющий в чьих руках сила и возможность повлиять на процессы внутри команды Исполнителей.
На этом я хочу сделать паузу, поэтому, читатель, можешь сходить размяться и заварить себе чаю :)
А как будешь готов, переходи на Разбор полётов
