16

Управление Проектом / Re: Может ли менеджер IT проектов успешно управлять проектом, не зная самого ПО?

« : 02 Августа 2012, 18:59:54 »

Управленец не обязательно должен знать ПО, но он должен хорошо разбираться в процессе "Как именно достигать результата в айти проектах". Его функции грамотно поставить задачу, определить срок ее исполнения и проконтролировать результат.
Конечно, если управленец знает ПО, то ему легче выполнять свою работу.
Если не знает, то это его проблема, пусть находит людей. которые обладают нужными знаниями и на которых он может положиться, при решении вопросов в которых он "0". В любом случае за результат отвечает управленец. Если аналитик "накосячил", то виноват управленец. Варианты его ошибки: выбрал не того человека; поставил не правильную задачу; не правильно оценил сроки и пр.

Александр 3 не разбирался в деталях экономических теорий, был далек от проблем транспортных перевозок, но он разбирался в людях. В случайной встрече с Витте он разглядел его потенциал и предложил работу. А через некоторое время в России была проведена экономическая реформа и другие успешные проекты. По сути Александр 3 это аналогия управленца успешно управляющего проектом, без знания ПО.

17

Сообщество Аналитиков / Re: Ваше образование

« : 09 Июля 2012, 23:03:09 »

Историк-архивист

18

Системный Анализ и Требования / Re: Оформление дополнительных требований к исходному ТЗ

« : 06 Июля 2012, 12:27:17 »

Отдельный документ: Дополнение к ТЗ.

19

Обсуждение статей / Re: Описание бизнес-процессов: стремление к простоте

« : 30 Мая 2012, 19:49:26 »

Спорная статья.
Для начала во Введении ставиться цель: «Одной из важнейших целей формирования графических схем процессов является последующее их использование в регламентирующих документах организации». И уже в выводах предлагается «хорошая» схема из практики жизни авторы которой вообще стремились отказаться «от текстового комментария к схемам процессов. Исполнителям просто печаталась схема формата А3, при чтении которой все сразу становилось понятно: что делать, как, какие документы использовать и т.п»
Заявленная цель и предлагаемый результат не совпадают. Зачем вообще ставить такие цели.

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

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

Общий вывод из статьи у меня получился такой: Нужно рисовать так нам удобнее и как можно проще, т.к. 1) мы не можем объяснить рядовым сотрудникам, как читать наши схемы 2) мы сами плохо разбираемся в нотациях и специализированном ПО 3) рисовать нужно много и 4) у нас нет на это времени.

20

ПО Аналитика / Re: HelpNDoc

« : 03 Апреля 2012, 16:01:32 »

А как вы ее используете?

21

ПО Аналитика / Как подружить RSA версий 8 и 7.5

« : 26 Января 2012, 18:57:20 »

Есть ли на форуме специалисты по IBM Rational® Software Architect?
Подскажите, как можно подружить RSA разных версий при совместной работе.
Сотрудники работают в разных версиях RSA результаты работы доступны через SVN.
Но есть проблема, диаграммы сделанные в RSA версии 8, не видны в RSA версии 7.5.

22

ПО Аналитика / Re: [Посчитаемся] Какие CASE средства с поддержкой UML вы используете?

« : 28 Ноября 2011, 10:02:29 »

IBM Rational® Software Architect v.8 - примерно 50 % работ.
Enterprise Architect v.8 - 40 % работ.
Бизаги - 10 %.

MS Visio - раньше много, сейчас 0%
All Fusion - раньше немного, сейчас совсем ничего.

23

Обучение / Re: Почему аналитику вреден опыт программиста?

« : 27 Октября 2011, 20:43:45 »

1. Наверное дело не наличии "лишних" знаний, а в "навязчивом" желании ими воспользоваться не к месту.
Если при сборе требований аналитик отвлекается и начинает думать о реализации, то это тоже, что бежать в впереди паровоза. Удачи ему и остальной команде проекта!

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

24

Бизнес-анализ и Целеполагание / Re: Анализ функциональных обязанностей

« : 27 Октября 2011, 20:08:44 »

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

Про анкеты. А есть ли вообще в них смысл? На первом этапе наверное вряд ли. В начале их с успехом заменят положения об отделах и должностные инструкции.
Я бы подготовил анкеты только после выявления дублирования функция, чтобы понять какой сакральный смысл в выполнения одного и того разными участниками

25

Примеры / Re: UC. Жизенный цикл заказа

« : 13 Октября 2011, 21:03:47 »

1. Я правильно понимаю, что контролер начинает работать только если есть претензии клиента.
2. Зачем нужно выделять в отдельный кейс Подтверждение сборки?
3. Возможно кейс Формирования недовложения лишний.
4. ...

Как вариант:
1. Клиент - кейсы: поиск "чего хочу"; формирование заказа; получение заказа (внутри которого претензии).
2. Контролер - кейс: контроль исполнения заказов.
3. Оператор - кейс: подготовка заказа.
4. Сотрудник склада - кейсы: подготовка заказа, получение заказа.