136

Системный Анализ и Требования / Re: Как выявить способности к аналитической деятельности

« : 02 Августа 2007, 17:32:42 »

А кто оценивает программиста? Кто оценивает тестировщика?

Правильно ли я Вас понял, что Вы не считате, что роль оценщика аналитика существенна для результата оценки? Или что "оценщик" аналитика может быть выбран тем же способом, что и "оценщик" программиста и тестировщика?

137

Системный Анализ и Требования / Re: Как выявить способности к аналитической деятельности

« : 02 Августа 2007, 16:41:23 »

Вопрос: кто должен оценивать аналитика? В какой позиции, роли должен находиться тот, кто должен оценивать аналитика?
1. С одной стороны, результаты работы аналитика оцениваются разработчиками (архитектор, программисты), которые должны использовать его результаты в своей работе.
2. С другой стороны последние посты данной темы подразумевают оценку аналитка, аналитками же. Зачем? Для коллективной анлитической работы? Интересно, что проблемы коллективной аналитической работы (не коллективной разработки в целом!)  до сих пор не обсуждались.
3. Или подразумевается оценка аналитка со стороны лидера проекта, который стоит и над разработчками и аналитиками?

138

Системный Анализ и Требования / Re: Как выявить способности к аналитической деятельности

« : 21 Июля 2007, 23:22:20 »

Предложение:
Прочитать потенциальным аналитикам лекцию о наиболее ярких (с Вашей точки зрения) примерах применения аналитических способностей  в жизни (не обязательно в сфере автоматизации, можно вплоть до рассказов о Шерлоке Холмсе ). После этого провести индивидуальные собеседования - опишите потенциальному аналитику ситуацию, в которой Вы находитесь  и предложите ему сформулировать свои представления о том, что такое аналитическая работа:
 Типа "Нужно выполнить аналитическую работу, но  можем ли мы поручить её Вам зависит от того, как Вы вообще представляете себе аналитическую работу. Каковы Ваши впечатления о материале, услышанном на лекции.".
Потенциальный аналитик в беседе должен продемонстрировать способность поддерживать разговор об анализе как на примерах из лекции, так и на собственных примерах (прочитанных или из жизни). Лекция должна помочь ему вспомнить свой материал по ассоциации с услышанным на лекции.
Интересно было бы подобрать материал в лекции, который иллюстрировал бы выявление причинно-следственных связей, а также ситуации введения по результатам анализа принципиально новых понятий, сущностей. В беседе постараться навести разговор на обсуждение аналогичных ситуаций.
Специалистов творческих специальностей, таких, как артистов или художников мастера подбирают фактически "под себя". Поэтому если Вы будете наставником этих аналитиков, наверное, элемент субъективного подхода - Вашей личной оценки, будет оправдан - тесты всего не скажут.

139

Бизнес-анализ и Целеполагание / Re: Следует ли выносить "управление целями" в отдельную дисциплину?

« : 21 Июля 2007, 19:03:23 »

2 Денис:
Если Вы предполагаете акцентировать внимание Boatman на проблемах связанных с этапом выработки (генезиса) цели, то мне кажется Boatman артикулированно сформулировал свою позицию по этому вопросу в тезисе:

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

Т.е. взаимопонимание (c Boatman) по проблеме генезиса (и терминологического определения) целей представляется более вероятным, если окажется, что проблема генезиса целей связана с внутренней логикой превращения цели в задачу, которую выcтраивает Boatman. Не видно проблемы генезиса целей и в тех примерах из практики, которые приведены им в предыдущих постах. Т.е. едва ли Ваши расхождения в понимании целей носят терминологический характер. Решение проблем генезиса целей Заказчика и проблем постановки задач на основании целей, скорее всего - разные практики, которые исходят из разных представлений (в том числе о целях). Даже  одни и те же примеры ("заработать миллион") с точки зрения этих практик будут, скорее всего, видеться по разному...

2Boatman
Не является ли различное понимание контекста Заказчиком и Исполнителем причиной проблем при постановке задач? Только ли в отстутствии должной настойчивости Исполнителя проблемы обеспечения должной целесообразности проектов? Вы нарисовали наглядную схему взаимодействия Заказчика и Исполнителя. Может быть Заказчик рисует совсем другую картинку, которая и является причиной проблем при постановке задач?

140

Бизнес-анализ и Целеполагание / Re: Следует ли выносить "управление целями" в отдельную дисциплину?

« : 21 Июля 2007, 18:15:09 »

Заметил ошибку в своем последнем посте Там, где написано "ТЗ всегда пишет заказчик" надо читать "ТЗ всегда пишет исполнитель".

Эх, жаль, что Вы так изменили свое утверждение. Не встречал толкового ТЗ, написанного без фактического соавторства с реальным Заказчиком.

141

Бизнес-анализ и Целеполагание / Re: Следует ли выносить "управление целями" в отдельную дисциплину?

« : 20 Июля 2007, 22:59:29 »

Теперь встречный вопрос. С какой целью делалось уточнение? Что оспаривается, что хочется добавить?

1. В предыдущем посте утверждалось, что "целью разработчика является постановка измеримых, реалистичных, непротиворечивых и т.д. целей, поддерживающих значимые надцели". Мне было непонятно, как можно ставить цели (о чем утверждалось в следующем предложении), не  отвечая за их содержание.
Ваш  последний пост устраняет это противоречие. В целом предложенная в последнем посте схема взаимодействия Заказчика и Исполнителя возражений не вызывает. И очень выразительно получилось .
Интересно было бы копнуть  глубже: почему всё-таки возникают проблемы с целесообразностью процессов? Мне казалось (возможно я ошибаюсь), по результатам нашего предыдущего обсуждения, что Вы основное внимание в Ваших постах сосредотачиваете на третьем этапе (из трех перечисленных в Вашем посте). Если нет, то, как Вы считаете, какой из трех перечисленных Вами этапов является, с Вашей точки зрения, наиболее сложным, проблемным?

2. Обоснованность включения "представлений о средствах" в определение цели оспоримо, но представляется важным помимо "намерений достижения цели" рассматривать "реалистичность цели", в смысле не вводит ли Заказчик Исполнителя в заблуждение относительно своих целей.
Представления о "результате+средствах+намерений" могут в этом смысле рассматриваться как достаточные критерии того, что то, что декларируется в качестве цели, является таковым хотя бы "в первом приближении". Но может быть можно исходить из более слабых (необходимых, а не достаточных требований)? Может быть имеет смысл разделять уровни цели:
1. цель на уровне идеальных представлений, цель-мечта, безотносительно к реалистичным способам и средствам её достижения
2. цель, выдержавшая проверку на реалистичность. Цель для которой есть "конструктивные аргументы" в пользу её достижимости (имеются представления о средствах, в том числе).

142

Бизнес-анализ и Целеполагание / Re: Следует ли выносить "управление целями" в отдельную дисциплину?

« : 20 Июля 2007, 18:54:24 »

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

Пожалуйста, не могли бы Вы уточнить: зоной ответственности разработчика не (всегда) является содержание именно цели (или надцели)?

143

Бизнес-анализ и Целеполагание / Re: Следует ли выносить "управление целями" в отдельную дисциплину?

« : 20 Июля 2007, 10:02:26 »

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

"Верификация, проверка, отслеживание" позволят диагностировать проблемную ситуацию с целями. Но позволят ли они её изменить? Употребленный в названии темы термин "управление" предполагает активные действия по изменению целей (Заказчика?). Какие средства есть в арсенале Исполнителя для изменения этих целей ?

144

Бизнес-анализ и Целеполагание / Re: Следует ли выносить "управление целями" в отдельную дисциплину?

« : 19 Июля 2007, 19:47:21 »

2Boatman: правильно ли я понимаю последний вопрос вашего поста - необходимо выяснить, насколько то, что делается в проектах, соответствует заявленным целям проектов?
Если я правильно понимаю вопрос:
1. То "виноваты" ли в несоответствии проектов целям сами цели? Нужно ли для решения этих проблем "управлять целями"?
2. Или лучше в этом случае как-то по другому управлять проектами, чтобы они таки соответствовали заявленным целям (были целесообразны)? Но тогда стоит ли относить проблемы соответствия проекта целям  к проблемам "управления целями"? Может быть это относится к уже оформившейся дисциплине "управление проектами"?

145

Системный Анализ и Требования / Re: Голосование - "Концепция системы и варианты использования" 12 июля

« : 18 Июля 2007, 10:16:52 »

Если на семинаре были озвучены различные точки зрения на некоторые вопросы, то по всем ли этим проблемным вопросам в результате обсуждения можно считать консенсус достигнутым?
По идее именно такие проблемы, которые обозначаются в ходе обсуждения, представляют даже большую ценность чем просто оценки степени совпадения ожиданий участников семинара и докладчиков и/или оценки качества представления материала. Проблемы, выявленные на семнаре, если они касаются общих интересов оппонентов, могли бы стать темой для дальнейшего (интересного обоим сторонам) обсуждения. Было бы здорово, если бы семинары не только (не сколько) "закрывали вопросы", сколько ставили новые.

Может быть кто-нибудь сможет зафиксировать в данной теме: в чем именно заключались различные точки зрения (причем очень важно - как различные участники формулируют точку зрения оппонента, потому что люди могут видеть всё очень по разному)?

146

Бизнес-анализ и Целеполагание / Re: Отличие задач от целей

« : 16 Июля 2007, 13:18:50 »

Всем привет.
Цель и задача: качество и количество, внутреннее и внешнее, субъективное и объективное.
Но в разговоре про различие целей и задач есть еще один момент. По теории:

• система состоит из элементов;
• каждый элемент системы подчиняется общей цели;
• каждый элемент системы оказывает влияние на все другие элементы системы.

Общая цель системы не только определяет вектор развития, но и объединяет элементы в системе. Эффективная специализация элементов системы превращается в их взаимозависимость. И система в рамках своей общей цели сама должна порождать утилитарные задачи для поддержания своей целостности, поддержки своим несамостоятельным элементам.
IMHO, если электронная система собирается существовать минуты 2-3, то разница между ее целями и задачами не успеет возникнуть. При длинном времени, цель объединяет элементы в систему и определяет вектор ее развития, вырабатывает задачи.
Если система вдруг достигнет своей цели (ну, так получилось), будет достигнут минимум энтропии с внешней средой, такая система прекратит свое существование, распадется. Выполнение задач является частным событием в жизни системы. Вслед за одной задачей, возникает другая ... вперед к светлому будущему.

Вы излагаете очень ценный взгляд на цели в рамках деятельности по системной интеграции. Т.е. фактически процесс создания/разработки элементов системы в данном тезисе не рассматривается. Система собирается из элементов и содержание функционирования системы в данном тезисе сводится к взаимодействию элементов. Это фактически квинтессенция подхода к созданию систем из готовых элементов, т.е. системной интеграции.

1. Насчет того, что система порождает цели - такое утверждение ИМХО справдливо, если Вы полагаете под системой не только программно-технический комплекс (компьютер), но и людей которые используют его в соответствии со своими целями (цели порождают люди).  Очень часто под системой подразумевают всё-таки именно компьютер и при таком прочтении, конечно, утверждать возможность постановки цели самой системой несколько странно. Но такое терминологическое различие использования понятие "система" приходится иметь в виду. В том числе при обсуждениях в данном форуме .

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

147

Бизнес-анализ и Целеполагание / Re: Отличие задач от целей

« : 16 Июля 2007, 12:36:40 »

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

Фактически такое толкование допускает любая уже существующая IDEF0 диаграмма. Проблема если у нас одна подцель (задача) соответствует нескольким целям. В BPwin такое нарисовать можно только разместив все цели и подцели на одной диаграмме. Жалко, что в этом случае нет возможности "упаковать" подцель "внутрь" обоих целей, как это можно сделать для "обычной" иерархической структуры задач (с непересекающимися ветвями иерархии).

148

Бизнес-анализ и Целеполагание / Re: Отличие задач от целей

« : 15 Июля 2007, 17:31:29 »

Задача - блок функциональный, а цель - это управление, как такой подход?

Пожалуй, описанную мной проблему увязывания нескольких целей с одной задачей (функциональным блоком) , такой подход решает.
Но тогда получается, что управление в данном случае - это один из входов в систему. Если достижение цели должно являться результатом работы системы, то по идее цель должна как-то соотноситься с результатом работы системы, т.е. с её выходом. Может быть целевой показатель - это всё-таки выход, а не вход системы? Управление, как правило, не сводится просто к указанию цели, это скорее реакция на рассогласование имеющихся результатов с целевыми. Например, представляется достаточно странным указывать в качестве управления (цели) "достижение заданной доли рынка такого-то вида услуг" и даже "подготовка налоговой отчетности".
ИМХО в этом смысле IDEF0 вообще не приспособлен для указания целей и, возможно, не стоит грузить "старичка" задачами для которых он изначально не предназначался.
Возможно, удобнее для этих целей использовать диаграмму Use cases. Если подразумевать под UC некий набор задач, которые могут быть использованы в качестве средства для достижения цели, то увязав их с конкретными действующими лицами мы неявно увязываем их (UC и задачи) с целями эти лиц. И если проблемы проекта связаны именно с логикой увязки действующих лиц (и их целей) с задачами, то такая картинка может быть полезна для обсуждения с другими и   даже для собственного понимания .

149

Бизнес-анализ и Целеполагание / Re: Отличие задач от целей

« : 14 Июля 2007, 17:32:14 »

А чем Вам IDEF0 в этом случае не средство указания взаимосвязи целей?
Если мы уже пришли к выводу , что цель=задача=функция ?

Проблемы применения IDEF0 для описание взаимосвязей задач и целей не связаны с терминологией. Это другая проблема. Например, у нас есть Цель1 и Цель2. Каждая их них может достигаться решением некоей Задачи. Если изображать Цели и Задачи "ящиками деятельностей" IDEF0, мы не можем сделать так, чтобы Задача была вложена одновременно и в "ящик" Цель1 и в "ящик" Цель2. Точнее, это невозможно сделать без дублирования Задачи внутри каждого ящика. Можно пытаться отображать  связь между ними только оставив все "ящики" на одном уровне, но это неудобно, особенно, когда задач достаточно много.

150

Бизнес-анализ и Целеполагание / Re: Отличие задач от целей

« : 13 Июля 2007, 18:03:07 »

Да, конечно, ничего страшного в смешении целей и задач нет. Я в другой ветке говорил, что вообще можно слово "цели" убрать из лексикона. Тем более оно вызывает столько трудностей: декомпозиция, управление целями (?!) etc.
Просто, когда понимаешь: каждое слово стоит n рублей, - начинаешь относится более внимательно к словам, а особенно таким громким, как цель. Хотя, внимательно относиться нужно к любым словам, а не только высокооплачиваемым.

Не различая цели и задачи Вы рискуете стать объектом манипуляции. Т.е. если речь идет о Ваших целях и Вы не различаете, когда Вы делаете что-то в соответствии с задачами, которые Вам поручили, а когда Вы делаете в соответствии с целями, которые Вы себе положили, Вы можете считать, что Вы делате то что, хотите Вы, а на самом деле - то, что хотят другие. Если исключить из лексикона понятие "цель" о понятии "деятельность", на котором построена теория Леонтьева, которая Вам понравилась также можете забыть, как и о теории, впрочем, тоже.
 Т.е. в каком-то смысле о собственном Я, со своими стремлениями и желаниями, существующем отдельно от окружающего мира можно будет забыть... Разве Вы готовы целиком вверить свою жизнь Божественному провидению? Или Вы всё-таки предполагаете что-то делать в соответствии со своими желаниями и намерениями? Если всё-таки предполагаете действовать самостоятельно, чтобы объясняться с другими людьми, Вам всё-таки придется использовать понятные другими термины и понятия для описания Ваших намерений, включая и "цели".