Зоны ответственности аналитика, архитектора и менеджера проекта.(Прочитано 43681 раз)
div хорошо бы рассмотреть задачу со всех точек зрения :)
div существует такой документ как должностная инструкция, в котором подробно написана зона ответственности конкретной должности.
Например у меня было инженер II категории, инженер I категории и документ в связи с этим раза в 1,5 утолщается, хотя по факту задачи не сильно отличались.
Особо стало интересно когда на собеседовании на мой вопрос в связи с чем открыта вакансия ответили, что как такового аналитика у них нет, эти задачи выполняет архитектор и очень хочет от них отделаться.

Интересно а обратная ситуация бывает? Когда в команде нет архитектора, его задачи приходится выполнять аналитику.

После схемы Д.Бескова о ролях аналитика, мне стало все понятно. Возможно у кого то будут какие либо дополнения, комментарии к этой схеме.

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



хорошо бы рассмотреть задачу со всех точек зрения :)
Я думал, у вас конкретная жизненная ситуация, а у вас сферический конь в вакууме :(

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



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

Должностная инструкция на мой взгляд очень важный и нужный документ. Иначе получится как в http://alex-aka-jj.livejournal.com/66984.html надуй шарик в форме кошечки, а так можно и нужно сослаться на должностную инструкцию.



Опытный ПМ подбирает людей в команду, обращая внимание не на должности, а на конкретные умения и навыки людей.
Это все хорошо, когда ПМ опытный, когда структура в компании проектная и когда комнада 10 человек.
А если структура матричная? А если проект 100 человек и ПМов там 3-5?
Да и просто, чтобы поставить процесс разработки в таком случае нужно понимать/описать - что и кто должен делать.

Соглашусь только с тем, что это описание будет сильно зависеть от:
1. Компании и их сторудников
2. Типов проектов
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Я думал, у вас конкретная жизненная ситуация, а у вас сферический конь в вакууме :(
 Я ни разу не сталкивался с ситуацией, когда должностная инструкция помогла бы выполнить работу. Мне кажется, должностные инструкции являются инструментом формального решения кадровых вопросов в случае отсутствия "согласия при непротивлении сторон". Было бы интересно, если бы кто-то поделился опытом позитивного использования должностных инструкций.
Позитивного опыта нет. Как только захочешь "сослаться" на должностную инструкцию, сразу пытаются "сослать" тебя. ;)



А если структура матричная? А если проект 100 человек и ПМов там 3-5?
У нас матричная структура, проекты по 100 человек. Неопытных ПМов на проект, в котором 100 человек, не ставят (тренируют на проектах с 1-2 чел). Насчет 5 ПМов на проекте не понял... Шутка? ("В военное время полк имеет 3-5 командиров"?)
Признаков использования должностных инструкций, кроме как для решения вышеупомянутых кадровых вопросов, не наблюдал.



Т.е. у вас приходит новый Аналитик и вы ему так и говорите - будете делать все, что ПМ №1 скажет, а если вы еще нужны и на проект ПМу №2, то тоже будете делать, что он скажет, и потом не говорите мне, что у вас 24 часа в сутках только?!
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Т.е. у вас приходит новый Аналитик и вы ему так и говорите - будете делать все, что ПМ №1 скажет, а если вы еще нужны и на проект ПМу №2, то тоже будете делать, что он скажет, и потом не говорите мне, что у вас 24 часа в сутках только?!
А у вас не так?



Когда у меня было в подчинении 3 аналитика, то было так.
Когда было в подчинении 15 человек, то был регламент работы и взаимодействия со смежными отделами.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Т.е. у вас приходит новый Аналитик и вы ему так и говорите - будете делать все, что ПМ №1 скажет, а если вы еще нужны и на проект ПМу №2, то тоже будете делать, что он скажет, и потом не говорите мне, что у вас 24 часа в сутках только?!
Близко, но не совсем так. Время аналитика (40 часов в неделю) делиться между ПМами (например, 10 часов ПМу№1, 30 часов ПМу №2). После этого ПМ №1 говорит аналитику, что тому делать 10 часов, а ПМ №2 - что аналитику делать 30 часов. Если в конкретную неделю на проекте №2 есть работы только на 1 час, а на проекте №1 есть ждущие задачи, то можно с согласия ПМа №2 поработать на проект №1 39 часов.



Приветствую.
Ни для кого не секрет, что существует достаточно большое количество подходов к определению этапов жизненного цикла (ЖЦ) IT проекта. Эти самые ЖЦ описаны в работах Вигерса и других известных авторов, работающих в этой теме, описан свой подход в RUP, есть классификация этапов ЖЦ в BABOK. Названия этапов варьируются, но по смыслу они все примерно говорят об одном и том же.
Мне кажется, что если отнести пункты, приведенные ниже, к более или менее формализованным этапам ЖЦ проекта, это поможет точнее ответить на заданный вопрос.
Давайте попробуем:
1.Обследование предметной области;
Это этап Бизнес Моделирования (Анализа) (Business Analysis).  Это, безусловно, обязанность Бизнес Аналитика
2.Определение требований;
Это этап работы с требованиями (Requirements). Часто его разделяют на этапы "Получения, извлечения" требований(Requirements Elicitation) и "Разработки или управления" требованиями (Requirements Management). Но, как бы там ни было - это работа Аналитика, Бизнес или Аналитика Требований, если таковой выделен в компании (такая ситуация часто возникает в проектах с "импортными" заказчиками со сложной предметной областью. Они предпочитают выделять своих специалитстов в предметной области (SME) в качестве Бизнес Аналитиков, проектной же команде оставляют работу по разработке собственно требований).
3.Обоснование необходимости внедрения, смета затрат, предполагаемый экономический эффект и время окупаемости;
"Обоснование необходимости" - это то, что выполняется на этапе "Предварительного анализа" (Preliminary Analysis), когда проводят анализ проблемы (Problem Analysis), которая, собственно и явилась причиной старта проекта, или возможности (Opportunity), которую хочет реализовать компания, заказывающая проект. Все это является частью более глобального этапа - Бизнес Анализа. Т.е. это тот же этап, что мы упоминали для первого пункта.
"Смета затрат", вот тут нужно быть аккуратными. Бизнес Аналитик обязан разрабатывать планы проведения этапа Бизнес Анализа, оценивать ресурсы, необходимые для его реализации, но... деньги проекта, глобальное планирование ресурсов на все этапы проекта, не только Бизнес Анализа, - это прерогатива Руководителя Проекта. Соотвественно, такие "денежные" показатели как "предполагаемый экономический эффект" и "время окупаемости" - это все-таки зона отвественности человека, стоящего повыше Аналитика. Повторюсь, Аналитик не располагает информацией о всех проектных ресурсах, не решает политических (денежных) вопросов с заказчиком, поэтому - это не его.
4.Разработка ТЗ; подготовка сопроводительной документации;
5.Создание необходимые диаграмм;
Если ТЗ то, в общепринятом смысле содержит требования, то это этап Работы с Требованиями. Разработка диаграмм, строго говоря, не тянет на отдельный, самостоятельный этап, поскольку "диаграммы" являются артефактами, которые разрабатываются для разработки требований - облегчение понимания, обсуждение с заказчиком и т.д. Чаще всего, самостоятельным артефактом (независимым от других артефактов, например от требований), который принимается заказчиком, включается в поставку они не являются. Это всего лишь иллюстрация. Но, сразу оговорюсь, что степень формализации документации требований определяется типом проекта, обсуждается с заказчиком и поэтому очень может быть, что в каком-нибудь Agile проекте диаграммы будут, по договоренности с заказчиком, приняты как необходимый и достаточный документ требований.
6.Разработка шаблонов проектирования;
Это этап Системного Анализа и Проектирования (System Analysis and Design).  Это этап, на котором подключаются две новые роли - Системный Аналитик и Системный Дизайнер. Это люди не от Бизнес Анализа. Это люди от программирования, поскольку речь идет уже о разработке базы для будущей реализации: определение будущих классов, интерфейсов и т.д. Более того, некоторые шаблоны проектирования являются платформенно зависимыми. Что это означает? Это означает, что существуют отдельные шаблоны проектирования для Java, для C++ и т.д.
Не во всех компаниях Системные Аналитики отделены от Бизнес Аналитиков. Не во всех компаниях, где такие роли (должности) выделены (у нас они называются Архитекторы), эти "Архитекторы" занимаются Системынм Анализом и Дизайном. Зачастую они ограничиваются разработкой технических решений по выбору платформы для реализации, проектированием БД, проектированием общей архитектуры (сервера, сетка) и т.д. Обязанности же по проведению Системного Анализа и Дизайна делят между собой Аналитик и разработчики.
7.Разработка тест-кейсов;
Это этап Тестирования, не смотря на то, что собственно тестирование начнется несколько позже - тест кейсы начинают разрабатывать как только аналитик представил требования и это выполняется параллельно с разработкой софтинки.  Это, безусловно, обязанность Тестировщика. Роль Аналитика в этом процессе: провести ревью разработанных тест-кейсов, чтобы убедиться, что тестировщик все правильно понял и тестирует то, что нужно, провести трассировку требований на тест-кейсы, что бы иметь возможность понять степень готовности требования по результатм тестирования.
8.Участие в тестировании и сдаче продукта заказчику;
Этап тестирования проводят Тестеры. Аналитик только наблюдает за процессом. Необходимо знать, все ли требования, вошедшие в Base Line протестированы, какие успешно прошли, какие завернули и т.п. поскольку, при нормальной организации работы с требованиями, все это отражается на статусе требования
9.Участие во внедрении и сопровождении программного продукта.
Аналогично предыдущему

Прошу прощения за "лаконичность".
По поводу должностных инструкций скажу только, что очень часто их составляют люди либо очень далекие от понимания всех этих вещей, либо, наоборот, очень недале### люди. Ну, вы понимаете :)
Поэтому, совершенно нормально, если разработкой тест-кейсов и планированием бюджета всего проекта в какой-то компании занимается Аналитик. Нужно понимать, что это не норма, это - отклонение
« Последнее редактирование: 27 Января 2012, 14:08:18 от alex6565 »
Кто знает, тот делает, кто не знает — тот учит других
(Б.Шоу)



Уважаемый alex6565 Большое спасибо за подробное раскрытие пунктов должностных обязанностей аналитика, однако меня интересовали обязанности для архитектора и менеджера проекта. Не могли бы Вы расписать также для этих должностей?



Не-не-не..., боже меня упаси, раскрывать "пункты должностных обязанностей"! :) В этом сысле я совершенно согласен с коллегой DIV - должностные инструкции в каждой компании свои, и описывают они, чаще всего, конкретные процессы, которые сложились в данной компании. Я лишь постарался донести своё мнением относительно тех активнойстей, которые вы описали.
Что касается ПМ-а и Архитектора, то тут я врядли смогу вам помочь - я имею представления только о тех активностях, которые они выполняют совместно с Аналитиком. Я уверен, что для них тоже существуют свои форумы. Эти вопросы лучше адресовать туда.
Рад был помочь.
Если остались вопросы, касательно работы Аналитика, спрашивайте, чем сможем - поможем :)
Кстати, было бы очень интересно узнать ваше мнение
« Последнее редактирование: 30 Января 2012, 16:51:02 от alex6565 »
Кто знает, тот делает, кто не знает — тот учит других
(Б.Шоу)



Цитата: div
Близко, но не совсем так. Время аналитика (40 часов в неделю) делиться между ПМами (например, 10 часов ПМу№1, 30 часов ПМу №2). После этого ПМ №1 говорит аналитику, что тому делать 10 часов, а ПМ №2 - что аналитику делать 30 часов. Если в конкретную неделю на проекте №2 есть работы только на 1 час, а на проекте №1 есть ждущие задачи, то можно с согласия ПМа №2 поработать на проект №1 39 часов.

Они у Вас кирпичи что ли кладут, аналитики-то? как в свое время говаривал старина Брукс: время выполнения работы одним исполнителем может на порядок (или даже больше) отличаться от времени работы другого исполнителя. Мог бы привести десяток-другой примеров, но думаю, что и у Вас их есть предостаточно.

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



Позволю себе встрять и внести, так сказать, нотку протеста.

Цитата: alex6565
Мне кажется, что если отнести пункты, приведенные ниже, к более или менее формализованным этапам ЖЦ проекта, это поможет точнее ответить на заданный вопрос.

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

Дело в том, что независимо от того, какое деление на этапы ЖЦ ИТ проекта (а, кстати, что называем "ИТ проектом"? разработку софта или что-то иное, например, какой-нибудь инфраструктурный проект?) используется, они [этапы] имеют между собой "мостики", являющиеся продуктами этого этапа. Так вот участие указанных выше персон, выражающееся в некотором содержании их деятельности, в рамках каждого этапа сводится к некоторому участию (частично или полностью) в создании этого продукта или его компонентов.

Поэтому сначала нужно определить этапность с точки зрения таких продуктов [результатов этапа], по возможности выстроив их в дерево или, что проще, в цепочку - это уже довольно близко к ИСР (или WBS), т.е. сферы ответственности ПМ. Но тут в дело вступает зависимость между содержанием проекта и компетентностью ПМа в этом (либо просто масштаб проекта, например, функциональный). И сразу становится необходим архитектор... Впрочем у Брукса и об этом тоже написано... (я, кстати, по его совету прочитал "Человека продавшего Луну" - рекомендую, да и времени займет немного)
Лью воду...




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19