Весь мир — театр (часть 2)

 Весь мир — театр.
 В нём женщины, мужчины — все актёры.
 У них свои есть выходы, уходы,
 И каждый не одну играет роль.

Уильям Шекспир.

Моя основная деятельность разработка на 1С, потому перефразирую строчки Шекспира (да простит он меня) под свою реальность:

 Весь мир — один большой проект.
 В нём аналитики, тимлиды- все в команде.
 У всех свои задачи на квадранте
 И каждый не одну играет роль. 

      Я, конечно, не актёр и не поэт, но хочу разобрать тему ролей в своём "Квадранте" и на живом примере.

Краткая предыстория.

До недавнего времени я была обычным работником компании, который в основном отыгрывал на проекте роли разработчика с примесью архитектора системы, тестировщика и капелькой бизнес-аналитика — прекрасное амплуа машины для убийства Upgrate-разработчика, перешедшее ко мне по наследству от n-ого количества уволившихся коллег. Почему была "обычным работником"? Потому что

пришла задача -> подумала о решении -> сделала

     Никакого абстрагирования от разработки (кто, какие роли отыгрывает, какие процессы происходят внутри команды, а точно ли мне делать именно это и т.п.), лишь действия. Тем не менее система работала: процессы выполнялись, задачи сдавались+- в срок, заказчик получал продукт нашей деятельности, давал обратную связь и т.д. Теперь этот проект на стадии завершения (передача в тех. поддержку) и мои силы перебросили на другой.

     Незадолго до начала обучения в ШСМ меня приставили к другому проекту с целью помочь с разработкой и немного с архитектурой. Поначалу процессы внутри нашей команды казались работающими. Единственное немного срывались сроки (довольно часто встречающаяся проблема).

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

А что по проекту?

  • Разрезы ролей.

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

Disclaimer!

Данный разбор не претендует на истину в последней инстанции. В моём видении некоторые роли имеют небольшой вес, поэтому могут быть упущены.

      На проектные роли можно смотреть сразу в двух разрезах: тип стороны (Исполнитель - Заказчик), и тип деятельности (Управление - Исполнение). В статье я буду описывать только сторону Исполнителя, но сделаю заранее небольшую ремарку, что рассматриваемые роли могут пересекаться и со стороной Заказчика.

  • Список ролей.

      Роли проекта я буду рассматривать, как многоуровневую систему. Например, роль Системного администратора может включать в себя роли Энекейщика, Сетевого администратора, Администратора БД и т.д. Так как в компаниях зачастую определённый пулл ролей назначают на одного человека (и я сейчас говорю НЕ ПРО ДОЛЖНОСТЬ), в своей модели я буду использовать обобщающие роли типа Системного администратора.

      Перейдём же к самому списку ролей. Кто же должен участвовать в ИТ-проекте, чтобы процессы работали как часы?

В порядке живой алфавитной очереди.

Архитектор.

     Человек-голова. Его основная деятельность заключается в формировании архитектуры, оценке имеющихся технических возможностей, формировании взаимосвязей со смежными системами и написанием проектной документацией. Так же он должен уметь отбивать разные дурацкие идеи вроде

давайте ВОТКНЁМ монитов в моциов  чЦто0ьюаказцик смотоел $Монитов,  ,пока смотоит в монитов

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

      Человек-переводчик, главный коммуникатор между заказчиком и командой в части сути проекта. В совершенстве владеет 13 диалектами клиентского языка, отвечает за написание и поддержание в актуальном состоянии требований проекта, проводит интервью с заказчиком, обрабатывает, документирует его и передаёт Исполнителям, участвует как ревьюер в проектировании верхнего уровня и обеспечивает выполнение всех критериев завершения проекта. 

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

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

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

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

У меня был план,гвајик  ерсоци  zov -  Пни ерта  JOUR% D Е FRR[  - 20/5-  ив его поидешкивался

Разработчик.

       Человек-строитель. Надо больше кода богу кода! Он сидит в тёмном углу офиса, заросший свитером, бородой и кофе, разрабатывает код проекта по ТЗ, получает фидбэк от тестировщиков (или тех, кто первым заметил) и бьёт нерадивые баги костылями. Его розовая мечта — собрать проект с первого раза без ошибок.

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

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

Тимлид.

       Человек-бригадир. Можно назвать ведущим разработчиком. Отвечает за распределение задач внутри разработчиков, а также за код, который летит в продакшн. Его девиз: "Не можешь остановить трэш-разработку — возглавь её (и сделай код-ревью)".

Тестировщик.

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

А теперь распределяя роли лёгким движением руки по зонам Управление-Исполнение мы можем понять, кто тварь дрожащая, а кто право имеющий в чьих руках сила и возможность повлиять на процессы внутри команды Исполнителей.

На этом я хочу сделать паузу, поэтому, читатель, можешь сходить размяться и заварить себе чаю :)

А как будешь готов, переходи на Разбор полётов

Полезная работа проделана для всей “отрасли” 1С :slight_smile:

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

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

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

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

Бизнес-аналитик. Разработка требований относится к практике инженерии требований, которая выполняется инженером по требованиям. В ШСМ предлагается именно так рассматривать и называть данную роль, так как аналитики не принимают решений. Документированные требования как рабочий продукт данная роль передает архитектору.

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

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

Александр, спасибо за пост!
Очень подробный разбор, отлично получилось!

Дарья, спасибо за пост!
Замечательный получился) очень рекомендую пост Александра, хорошо отметил, что можно доработать.

Я бы отдельно хотела остановиться на разделении “заказчик-исполнитель”, потому что его пока нет в учебнике ССМ, по факту, такое рассмотрение в явном виде только-только включено в пишущийся учебник собранности.
В целом, рассмотрение отдельно “системы создания/обеспечения”, в которой работают исполнители внутренних проектных ролей, это рассмотрение со стороны “исполнителя”, а со стороны целевой системы и надсистемы – рассмотрение со стороны “заказчика” (внешних ролей). Так рассматриваем рабочие проекты, так же и личные – да, там тоже надо выделять “заказчика” и “исполнителя” (просто часто и заказчиком, и исполнителем будете выступать вы).
Отлично, что вы обратили внимание на такое рассмотрение!

Боже, где был этот пост, когда я шла на должность бизнес-аналитика и не понимала ровным счетом НИЧЕГО! Считаю, что классификация заслуживает отдельной статьи на Википедии. Очень понятно, точно и главное с юмором. Я рукоплещу, как морской котик на шоу перед зрителями. Спасибо большое за пост!