196

Для всех / Re: Требования к Заказчику и Исполнителю

« : 23 Марта 2016, 12:32:32 »

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

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

197

Обучение / Re: CBAP или как стать суперменом в Бизнес-аналитике

« : 23 Марта 2016, 12:25:54 »

Имелось  в виду то, что хочется заниматься больше в сфере управления требованиями.

Хотя Requirements Analysis and Design Definition указывается в BABOOK качестве области знания бизнес-аналитика, по их поводу  так же есть разные мнения:
- RA является совершенно самостоятельным видом анализа
- RA является частью системной инженерии
- RA является частью системного анализа (прежде всего в части системных требований)

И BA, и RA, и SA в том или ином виде занимаются 

управлением требованиями и общением с заказчиком, соответственно и всеми вытекающими из этого подзадачами

Если брать деятельность по написанию ТЗ на Вашей текущей работе, то она предполагает управление требованиями и общение с заказчиком.

Если брать 1С Предприятие, то это ERP, и написание ТЗ на ее доработку требует и бизнес анализа (в части определения бизнес-требований) и системного анализа (в части системных требований).  Я понимаю, если бы вы писали ТЗ на доработку к CAD системе или на компьютерные игрушки, но крайне тяжело работать с ERP, не вникая в  бизнес.

Не могу понять, Вам шашечки или ехать? Что Вам мешает заниматься бизнес-анализом в части управления требованиями на Вашем текущем рабочем месте?




   

198

Для всех / Re: Объект обследования

« : 23 Марта 2016, 09:51:01 »

Допустим есть цех 1 и цех 2. Из цеха 1 доставляют изделия в цех 2. Доставляет человек на тележке.
Доставка изделий является бизнес-процессом?

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

Если мы разбираемся с передаточными документами при этой доставке, то будет являться бизнес-процессом.

Бизнес-процесс или не бизнес-процесс - это не какое-то изначальное свойство явления.

Является что-то БП или нет определяется исключительно тем, выгодно или нет нам это что-то как бизнес-процесс рассматривать.
 

Если руководство решило заменить тележку с человеком на конвейер.
Это считается автоматизацией?

Как минимум это изменение.

Вот что нам говорит википедия :

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

Автоматизируются:

    производственные процессы;
    проектирование;
    организация, планирование и управление;
    научные исследования;
    обучение;
    бизнес-процессы;
    и другие сферы человеческой деятельности.

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

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

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

То есть является это изменением БП или не является определяется  целью моделирования  и точкой зрения на это изменение.   

199

Для всех / Re: Требования к Заказчику и Исполнителю

« : 22 Марта 2016, 18:40:19 »

- Согласны ли вы, что каждый договор подобен брачному контракту, в котором главное, что будет иметь каждая из сторон, когда отношения прекратятся?

Стеб и ирония детектед. А между прочим совершенно зря - IT проекты были и остаются одними из самых высокорисковых классов проектов. Не даром, когда говорят про стартап или венчур в 99 % случаях имеют в виду именно IT венчур или стартап.

В России ежегодно вступают в брак чуть более 1 миллиона пар, при этом около 700 тысяч семей подают на развод.

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

Происходит это по одной причине - основные причины неуспеха именно в неправильном распределении ответственности участников проекта.

В этом плане показателен пример Ciber Novasoft - это американская компания, которая осуществила прорыв SAP на российский розничный рынок. В начале 2000 годов менеджментом российских компаний был накоплен богатый опыт похеривания проектов внедрения как SAP, так и других систем. А Ciber в течении 2-3 лет половину российского ритейла умудрился перевести на SAP , но при этом маленький нюанс - половина проектов внедрения (если не больше) завершалась через суд.

Как ни странно, ведя пару-тройку судебных процессов одновременно, Ciber без труда находила себе новых клиентов.

Ларчик открывался просто - при жестких контрактных обязательствах Заказчика и Исполнителя друг перед другом проектные процедуры работали как часы - крайним оставаться никто не хотел...

200

ПО Аналитика / Re: Техническая сторона интеграции EA и TFS Лаборатории Касперского

« : 22 Марта 2016, 14:00:56 »

Ирина, спасибо большое!
Ясность наступила практически полная

201

Для всех / Re: Требования к Заказчику и Исполнителю

« : 22 Марта 2016, 13:23:52 »

- Какие требования к Заказчику?

Я бы конкретизировал этот вопрос. Он распадается на два:
1) Требования к Заказчику в проектных процедурах
2) Квалификационные требования к представителю заказчика

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

А вот, чтобы проблема решилась, то необходимо грамотно организовать проект. На вопрос как это сделать отвечает специальная наука - управление проектами (она конечно связана с анализом, но прямого отношения к нему не имеет). Опыт успешного управления зафиксирован в специальном своде -   https://ru.wikipedia.org/wiki/%D0%A1%D0%B2%D0%BE%D0%B4_%D0%B7%D0%BD%D0%B0%D0%BD%D0%B8%D0%B9_%D0%BF%D0%BE_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8E_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8

В этом своде достаточно подробно описаны различные варианты проектных процедур, и роли каждого участника процесса.

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

Для начала надо понять, как вообще называется эта должность, прежде чем начинать предьявлять к ней требования.

В коммерческих структурах она зачастую так и называется - руководитель проекта внедрения. Если таких РП в организации много, обычно их распределяют по подразделениям. Довольно удачное название для этой должности в X5:

IT бизнес-партнер

Обязанности:

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

 

Требования:

    высшее техническое образование;
    руководящий опыт работы;
    опыт внедрения и доработки ИТ систем для крупных торговых или логистических компаний (WMS, TMS, SAP);
    высокие коммуникативные и аналитические навыки, опыт проведения коммуникаций с бизнесом на высоком уровне;
    English - Intermediate.

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

В описании конкретно этой вакансии очень много скрыто во фразе опыт внедрения и доработки ИТ систем

Там собственно и живут требования к РП, и к аналитику.

Но могут выделить их и отдельно.

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

Но если проект организован грамотно, то функции и квалификационные требования примерно те же.

202

Для всех / Re: Разработки

« : 22 Марта 2016, 11:35:01 »

Годами работаю по госконтрактам. Ни разу такого не видел.

Госконтракты совершенно отдельная тема. По госконтрактам ВСЕ проектные риски устраняются за счет государства, к сожалению...

Чтобы это понять, надо поучаствовать хотя бы в одном проекте по PmBOOK - с уставом, с проектными процедурами, прописанными в Уставе

Для госконтрактов появился ГОСТ Р 54869, но никто не спешит его использовать.

www.dkp31.ru/sites/default/files/doc/gost_r_54869-2011_proektnyy_menedzhment_tarebovaniya_k_upravleniyu_proektom_.pdf

203

Для всех / Re: Разработки

« : 22 Марта 2016, 11:27:09 »

... только в самом начале пути, учусь и изучаю мастерство заказчика.

Замечательно. Как минимум уровень осознанной некомпетентности достигнут

Ну и навыки фасилитататора  детектед

204

ПО Аналитика / Re: Техническая сторона интеграции EA и TFS Лаборатории Касперского

« : 22 Марта 2016, 11:10:20 »

Ирина, большое спасибо за ответ!

Начинает кое-что прояснятся. Но хотелось бы чуть больше технических деталей.

Каким образом аналитик определяет, какие именно элементы пойдут в TFS в качестве требований?

Он помечает каждый элемент индивидуально внутри самого EA в атрибуте таблицы T_object?
Кроме типа UseCase обьекты каких еще типов могут экспортироваться?

Или организована специальная передаточная таблица и интерфейс к ней средствами самого EA или в каком-то промежуточном ПО?

205

Для всех / Re: Разработки

« : 21 Марта 2016, 17:37:09 »

Она позиционировала себя как заказчик. Заказчику и не надо.

Это почему это не надо? Очень даже надо!
Неужели никто из коллег не хлебнул лиха от неграмотного, но очень самоуверенного заказчика?

Типовая ситуация на проекте - спонсор нанимает не особо подкованного, но очень самоуверенного РП. У закачика все с радостью   "делегируют" ответственность этому РП, он уверенно подписывает таймшиты и промежуточные акты, а на стадии демонстрации макетов бизнес-пользователи делают круглые глаза. А потом не менее круглые глаза делаются при повторном прочтении "согласованного"  ТЗ.

В итоге ругань, разборки, поиск виноватых....

Поэтому грамотный исполнитель в договоре четко фиксирует факт наличия со стороны заказчика РП,  квалификационные требования к нему и риски их несоблюдения. И это конечно не всегда спасает.

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

206

Для всех / Re: Объект обследования

« : 21 Марта 2016, 16:14:49 »

Если брать разделы ТЗ по гостам 19 и 34 систем, то объект автоматизации - это именно физический или организационный объект.  А что такое объект исследования и обследования не регламентируется

207

ПО Аналитика / Техническая сторона интеграции EA и TFS Лаборатории Касперского

« : 21 Марта 2016, 12:22:00 »

Навеяло обсуждением в топике про Управление изменениями требований

Да, примерно так. К тому же далеко не все в ЛК используют для разработки требований EA, кому-то достаточно Notepad, а кто-то пишет их прямо в TFS. Но в конечном итоге под учет все ставится в TFS-е.Нет, конечно же нет. TFS поддерживает весь цикл разработки - от привязки Change Request'ов и багов к коммитам в исходники, и до сборки билдов.

Судя по вышесказанному, то любые требования , зафиксированные ДО TFS носят предварительный характер, и они фиксируются именно в TFS (а следовательно формальный учет изменений тоже возможен только в TFS).

Соответственно разработка требований в EA носит такой же предварительный характер.

Что же тогда поступает в TFS в качестве входной информации?

Это жесткий список формализованных требований (набор записей из T_object типа requirement) или просто картинка, на которую разработчик может глянуть (ссылка на пакет или диаграмму, а может и вообще текстовый документf с постановкой)?

Понимаю, что несколько забегаю вперед, и получить ответы можно будет на конференции 30 марта, но зачастую ответы на такие вопросы вызывают еще больше вопросов

208

ПО Аналитика / Re: Управление изменениями требований

« : 21 Марта 2016, 11:47:08 »

Humbert,

обратите, пожалуйста, внимание, в контексте чего ведется обсуждение.

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

209

ПО Аналитика / Re: Управление изменениями требований

« : 20 Марта 2016, 00:43:24 »

Может им просто попробовать Cradle и станет легче? Хотя они столько уже вложили в свою интеграцию, что врядли смогут перестроиться.

Касперский компания не проектная, а продуктовая, отличается примерно как завод от стройки. Могу предположить, что репозиторий кода и управление его движением у них основное. Я Cradle изучил еще недостаточно, но насколько я понял репозитория у него нет, даже такого куцего, как у EA. Так же не заметил в Cradle следов для организации  межпроектного взаимодействия (впрочем как и у ЕА).

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

Так что с уровня моих знаний об этих продуктах выбор EA вполне обоснован.


 

210

ПО Аналитика / Re: Управление изменениями требований

« : 18 Марта 2016, 20:28:30 »

Вот, кстати, Humbert недавно проводил независимое сравнение 3SL Cradle  и Sparx EA, о котором будут рассказывать в Касперском.
Было бы интересно, если у него нашлось время поделиться мнением, применительно к той задаче, которую описала в начале Елена.

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

Прошу прощения, но я бы сделал окончательные выводы именно после знакомства с технологиями Касперского на вышеуказанной конференции. Сравнение для себя я сделал, но все таки оно не вполне корректно - если 3SL Cradle в качестве демо дает целостные проекты , то вот с рабочими проектами EA я еще не сталкивался, а на демопроекте EA выглядит как UML - рисовалка. Как раз хотел глянуть и послушать Сурину, чтобы оценить технологию в целом.