Форум Сообщества Аналитиков

×


Просмотр сообщений

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


Сообщения - Shur

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »
151
Я имел ввиду, что мы в цели можем включать не только верхоуровневые цели, но и подцели, которые могут быть уже задачами. Не вижу ничего в этом страшного, если все верхнеуровневые цели определены.

ИМХО важно не только формировать цели списочным образом, но и указывать как они между собой взаимосвязаны, в частности, если одни подчинены другим. До сих пор как-то механизмы такой увязки не обсуждались, обычно увязка получалась через функциональную декомпозицию (типа у головной функции есть цель, а у подфункции - подцели и иерархия целей-задач увзывается через структуру функций). Но Якобсон (в книге Aspect oriented programming) указал, что так можно поступать не всегда: есть цели которые могут реализоваться функциями, уже подчиненными другим целям. Т.е. важен не только список целей и задач, но и как они взимосвязаны.

152
Много-много сказано о целях здесь и на семинаре. Забавная вещь: слово "цель" - не русское. Оно пришло к нам из польского языка. Соответственно, во время интервенции поляков. Смутное время. Лжецари, самозванцы, Сусанин.
То есть цели-то не наши, а смутьянов. Может поэтому столько путаницы с этими целями?
До XVII века люди на русской земле жили без целей! Понимаете? - Ни задач, ни целей. Их, видимо, заменяли вопросы куда и за чем (например, в баню или за мёдом) и ответы на них. Вот так.
Может стоит попробовать, а то конца и края не видно многословию по поводу целей  ;)

Раньше целей у людей быть не могло, потому что считалось, что все сущее создано и подчинено Богу. Признание человека, как самостоятельного субъекта (имеющего собственные цели) началось в массовых масштабах в период Нового Времени (фактически эпоха Реформации и буржуазных революций). До этого даже притязания на то, что человек имеет право выстраивать отношения с Богом  не прибегая к посредничеству церкви (первыми были лоллардисты, кажется в 11 или 13 в.) рассматривалось как ересь и преследовалось. Поэтому, откуда было взяться у человека целям, кроме тех которые были поставлены перед ним Богом (как задачи)?
Поэтому раньше целей не было (точнее, они не осознавались как таковые) не только у русских, но и у других народов.
Само понятие деятельности (Activity) и смыслы в него вкладываемые также является продуктом Нового времени и неотделимо от понятия "цель" (см. http://bse.chemport.ru/deyatelnost.shtml).

153
Хотел этот вопрос еще поднять на семинаре, но забыл ....

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

Ну и еще, в общем, задача - это детализация цели.

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

154
Верной дорогой идете, товарищи :).

Правда, согласно ГОСТ 34.003-90 "Термины и определения" комплекса стандартов на автоматизированные системы пункту 1.4 "Задача автомтизированной системы - функция или часть функции АС, представляющая собой формализованную совокупность автоматических действие, выполнение которых приводит к результату заданного вида"

Т.е. в ГОСТе "задача" - это вообще "функция"!


155
Для "затравки" опредления ИС и ПО:
В ГОСТ 34.003-99 "Термины и определения" есть следующие термины:
1.1 Автоматизированная система (АС) - система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализаующая информационную технологию выполнения установленных функций
2.7 Программное обеспечение автоматизированной системы; программное обеспечение АС - совокупность программ на носителях данных и программных документов, предназначенных для отладки, функционирования и проверки работоспособности АС.

156
….Когда я пишу цель и не указываю уровни - это значит, что речь идет о цели любого уровня….
…..И уровень - это атрибут цели, который позволет их различать, но не делает ПРИНЦИПИАЛЬНО РАЗНЫМИ с точки зрения моих интересов.

А с точки зрения моих интересов делает. Мы с Вами находимся в разных проблемных ситуациях. Спасибо, что Вы, наконец ,ответили на мой главный вопрос. Мы «говорим о разном». Наверное, остальные наши разногласия обсуждать не имеет смысла, потому что, с моей точки зрения, они все завязаны на этот главный вопрос. Успехов Вам в рещении Ваших задач (и достижении Ваших целей :)).

157
Есть два варианта: или цели есть в недрах заказчика (как группы лиц) и я их извлекаю. Или цели рождаются в заказчике с моей помощью. Называйте, как хотите, мне в моем проекте нужны образ результата, представление о средствах и критерии достижения. Ни доказательства существования целей ни опровержение существования не принесет мне пользы.
А вообще вопрос, скорее, философский и не имеет четкого ответа вне контекста.
Но как именно Вы хотите эти цели получить? Зависят ли способы выявления/получения целей от их уровня и в чем именно эти способы заключаются. Не совсем понял Ваше утверждение «Называйте как хотите…». Если Вы имели в виду что все мои вопросы о различении уровней целей (конец моего предыдущего и позапрошлого поста) Вы будете продолжать игнорировать, то давайте свернем нашу дискуссию. Без четкого различения понятий, смыслов понятия «цель» в разных контектсах, мы даже не сможем достаточно точно понимать друг друга.

Предлагаю не уводить проблему в сторону глобализации. Вот старт проекта и условия договора, которые гласят: если будут предоставленные технические средства согласно ТЗ, вы получите 100k$ если независимый аудит признает повышение капитализации, вы получаете сверху еще 50k$, если будет измерено повышение качества продукции, вы получаете сверху еще 100k$, если проект закончится раньше указанного срока на два месяца, вы получаете сверху еще 50k$. Как достижение одной из этих целей поддерживает достижение других - никак. Возможно есть цель более высокого уровня, на которую работают все 4 перечисленных, но она уже не ставится перед этим проектом, тогда мы говорим, что этот проект имеет 4 цели, более глобальная цель не принадлежит этому проекту.

В приведенном примере фигурирует сразу несколько показателей претендующих на название «цели», причем целей разных заинтересованных лиц. Реконструируя ситуацию, представляется логичным предположить, что:
1. разработчик заинтересован в получении денег по всем указанным позициям (100+50+100+50).
2. Заказчик заинтересован в получении технических средств по требованями, указанным в ТЗ (от требований тянутся связи вверх к высокоуровневым целям Заказчика). Плюс повышение капитализации, качества продукции, срочность.
Если пытаться вычислить «родительскую/высокоуовневую цель», у  перечисленных критериев, то у каждого из участников такие «родительские цели» могут быть разными. Это важно.
Разработчик максимизирует свои критерии с помощью задач, критериями решений которых являются показатели (п.2) Заказчика. Т.е. с точки зрения Разработчика критерии Заказчика подчинены критериям Разработчки.
Полагаю, мы, прежде всего, обсуждаем ситуацию с точки зрения разработчика?
Тогда вопрос: накладывает ли объем денежных средств, доступных средств разработки и человеческих ресурсов ограничения на одновременное достижение заявленных критериев Разработчика (п.1)?
Как правило накладывает. И возникают варианты, типа делать БД на Oracle и получить бонус за рост капитализации компании после принятия системы на баланс или использовать что подешевле и сэкономить на затратах на разработку (хотя такие вещи, как правило, ограничваются в ТЗ, какая-то возможность маневра всегда есть). Также возникает вопрос рисков, связанных с субъективностью аудита, кривыми руками пользователей, не позволяющим повысить качество продукции. Тогда возникает вариант - может быть сделать, что похуже, но побыстрее и получить бонус за срочность?
Т.е. многообразие целевых показателй в условиях ограниченности ресурсов может создавать сложные связи между этими показателями. И достижение (недостижение) одних показателей может быть обусловлено достижением других.
Возможно, Вы подразумевали, что показатели Разработчика не обязательно являются достижимыми? И на основании того, что они являются неким «идеалом» их можно называть целями?
Когда я писал в своем посте о невозможности работы по нескольким критериям сразу, на что Вы и возражали примером с проектом, я имел в виде именно ситуацию, когда мы ВЫНУЖДЕНЫ выбирать (если мы действительно хотим ДОСТИГНУТЬ ЦЕЛИ), какой критерий мы будем максимизировать в первую очередь (и сможем ли вообще). Именно это я пытался обосновать в данном примере.


К несчастью одна из областей моих интересов в целеполагании - это рекомендации по выживанию в бесцельных проектах. И я не принимаю утверждений, что этого быть не должно. Это есть. Это обсуждалось много раз и это не афишируется опытными людьми.
Вот пример обсуждения
http://sql.ru/forum/actualthread.aspx?tid=269043&hl=%ef%f0%ee%e4%e0%e2%e5%f6
В такой проект лучше не попадать, но для этого надо знать признаки такой ситуации.
Менеджер по продажам тоже мог бы более четко балансировать интересы, чтобы внедренцы не страдали.
В жизни приходится идти на компромиссы, но я категорически неприемлю утверждение о том, что «бесцельные проекты» должны быть нормой жизни. А без построения идеальной модели «целевого» проекта, Вы отличить целевой от бесцельного не сможете. К сожалению, у отечественной практики (не только в области автоматизации) есть очень давняя традиция выдавать низкоуровневые показатели за высокоуровневые целевые. Именно поэтому я с подозрением отношусь к Вашим систематическим попыткам обсуждать проблему целей на примерах с использованием того, что я отншу к ключевым показателям эффективности, имеющим весьма опосредованное отношение к тому, что относится к целям в смысле БСЭ, ссылку на которую вы любезно привели в Вашем посте.



Я теряю нить. Во первых, что конкретно я отрицаю?
Отрицал я :). Я пытался пояснить логику своего отрицания Вашего утверждения.


Давайте пример: я (директор) с Вами (директором) заключили договор между нашими организациями. Мало того, что в договоре записаны цели Вашей и моей организации, там записаны наши общие цели (двух организаций) в рамках договора. От того, что я или Вы уволитесь, договор силы не потеряет и должен продолжать исполняться. Это я называю групповыми целями. То, что каждый раз каждую работу делает кто-то конкретный, который мотивирован по своему - это правильно, но абсолютно не важно с точки зрения договорных отношений. И это работает и вопрос только в уровнях детализации в одном случае мы говорим о целях организаций, в другом о том, как конкретно и кем они будут достигаться.
Что именно вы назваете «групповыми целями» я понимаю, вопрос: стоит ли это назвать «целями»? Если группу вообще не спрашивали, что они хотят, когда этот договор заключали, то с какой стати «цель из договора» называется групповой целью? Договор директора подписывали, вот их цели в договоре в лучшем случае и зафиксированы. А попытка приписывания подчиненным целей их начальников распространенный прием авторитарных сообществ.

 

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

Давайте тогда более четко. Определение объективации в студию. И как этот процесс связан с реальными проектами?
См. первый абзац в моем предыдущем сообщении, это оно и есть.


Исполнение договора, как примера групповой цели - более, чем объективно. Я каждый раз убеждаюсь в этом, подписывая акты и проверяя приход оплаты за этапы. И никому нет дела до моего толкования цели. Правда, тут гигантское поле для толкования записанного, но во первых это к юристам, во вторых все равно для меня объективные цели скорее существуют, чем нет.
Ага! А у Вас всё-таки есть свое собственное толкование групповой цели Вашей организации! Тогда в какой мере эта цель групповая? Был такой анекдот в советсвое время: у человека справшивали, как он относится к  политике партии правительства и последним решениям начальства. Он на все вопросы отвечал: «Я целиком одобряю и поддерживаю политику партии и правительства, начальств и пр.». «Но, позвольте, у Вас есть, в конце концов, собственное мнение хоть по какому нибудь вопоросу?» «Да, есть, но я его не одобряю и не поддерживаю».


Не вижу смысла открывать америку в определении категории "цель".
Вот определения на выбор
http://slovari.yandex.ru/search.xml?text=%D1%86%D0%B5%D0%BB%D1%8C
Здесь прямо упоминается существование групповых целей
http://slovari.yandex.ru/dict/gl_social/article/18/180_37.HTM?text=%D1%86%D0%B5%D0%BB%D1%8C
http://slovari.yandex.ru/dict/gl_social/article/180/180_374.HTM?text=%D1%86%D0%B5%D0%BB%D1%8C
Системный анализ рассматривает цель, как принадлежность многих сложных систем, в том числе и социальных.
По приведенным Вами ссылкам такое многообразие определений понятия, что просто непонятно, как еще люди понимают друг друга. Я не предлагал добавлять новые опредления понятия цели, а предлагал, использовать, по возможности, другие термины (вместо «цель»), уже существующие в тех ситуациях, когда эти термины позволяет более точно и однозначно описать смысл того, что требуется автору. В частности, если для Вас различение целей по уровням незначимо (во всяком случае, в Ваших постах Вы не указываете уровни, когда пишете «цель»), так и скажите, я уже третий пост подряд задаю Вам это вопрос.
 

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

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


158
Цели существуют объективно вне зависимости от нашего знания о них. Они могут быть не формализованы, они могут скрываться.

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


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

Ваш пример как раз хорошо иллюстрирует суть моего утверждения, приведенного Выше. Недостаточно провозгласить возможность одновремнной работы по двум критериям. Необходимо доказать такую возможность. Например, договориться о некоторых фундаментальных свойствах рассматриваемого бизнеса, который мы смотрим, а потом уже  выводить из них возможность «погони за двумя зайцами». Причем я предполагаю, что для разных видов бизнесов, разных ситуаций, Заказчиков возможны разные ситации: когда указанные Вами критерии могут максимизироваться одновремнно, а когда они противоречат друг другу. Причем критерии, которые Вы сформулировали, я бы не относил к высокоуровневым целям – это типичные KPI, за которыми, на самом деле (если они совпадают) стоит одна цель самого высокого уровня.  Обратите внимание, мы опять упираемся в проблему различения целей по уровням,. Если мы все-таки сначал решим задачу различения по уровням, проще будет обсуждать тему двух целей.  К сожалению, Вы никак не отнеслись к моему утверждению/предположению о том, что ответ на этот вопрос зависит именно от различения уровней целей.

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

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

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

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

Я как раз утверждаю, что если это «почему» является знанием в области деятельности  Заказчика, то аналитик перестает быть аналитиком. Сожалею, что Вы никак не отнеслись к этому моему утверждению по его сути. Возможно, аналитик формулирует известные Заказчику знания в новой форме, но нужно различать, где форма, а где содержание. И если Вы привносите новые содержательные знания в деятельность Заказчика, то Вы должны брать ответственность за это уже как предприниматель.


 
Возможно только некоторое приближение к фиксации целей.
Обратите внимание – я писал об объективации а не просто фиксации, а это совсем разные действия.

Групповые цели - это объективная реальность. Договора, фиксирующие цели, заключаются от имени организаций. Такие цели переживают отдельных людей на конкретных постах и продолжают реализовываться вне зависимости от персоналий. Механизм работы групповых целей - это совсем другой вопрос.
Объективной она станет только после того, как Вы её объективируете и объективной оставаться только для людей, которые будут разделять Вашу точку зрения на цель. Фиксация и объективация – это очень разные действия, не все что зафиксировано объективно существует, в том числе (увы!) и в договорах. Насчет переживания целями их авторов снова возвращаемся к вопросу об уровнях целей – как можно говорить о том что цель человека быть счастливым перживает его самого? Я понимаю, что стремление жить хорошо – заразительно, но применительно к материям высокого уровня я бы согласился, что деятельность организации может продолжаться, если продолжают жить идеи, а это опять-таки не совсем то же самое, что цели.

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


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

Хотел бы сразу уточнить – всё, что  я написал ниже относится к тому, что, как мне представляется, Вы называете «высокоуровневыми целями», т.е. самими верхними, главными.

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

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

Тезис:
У проекта не может быть много целей.  В ситуации нескольких равнозначимых целей мы имеем дело фактически с несколькими равноправными проектами. У одной цели не может быть нескольких авторов.  Это особенно характерно для авторитарной модели российского бизнеса. Групповые цели – феномен религиозных сект и авторитарных обществ. Есть и компании такие… Термин даже есть для обозначения того, как сделать так, чтобы цели начальника стали целями подчиненных - «индоктринация».
Картина которую я описал звучит, категорично, но по жизни если удается докопаться до фундамента логики деятельности Заказчика, то все именно так.  Представляется методически правильным исходить из такой схемы. Тогда ситуации неполноты информации (когда не удается «докопаться» до авторов)  и то, что можно было бы назвать моделями с «групповыми целями» являются некими паллиативами и их всегда приходится рассматривать с учетом того, что «главный автор» целей проекта всё-таки может проявиться в ходе его реализации.


Про 200%, придуманных аналитиком: тут неявная подмена понятий: заказчик (для меня) - это не один человек, каждый представитель заказчика все знать не будет никогда.

В данном случае суть наших разногласий не связана с количеством персоналий, которых мы отождествляем с Зазказчиком. Можно «снимать инфомацию» при бизнес-анализе и с рядовых сотрудников Заказчика.  Принципиально важно, что любое утверждение, которое аналитик называет «Цели Заказчика» или «Требования Заказчика» - это именно то что хотел бы получить один из людей, которых мы относим к категории Заказчика и он это явно признает и подтверждает. И что аналитик не выдает собственные фантазии (под предлогом того, что Заказчик чего-то «не знает») за цели Заказчика (или любого из людей, относящихся к категории «Заказчик» по данному проекту).


Согласно BABOK аналитик помогает: формализует, измеряет, обосновывает. На основе предоставленных материалов ЛПР принимает решение и несет ответственность.
Да, да и еще раз да! Но при условии, что Заказчик согласен, что то, что «формализовал, измерил и обосновал» аналитик,  сам Заказчик призначет в качестве собственных целей и задач. Нормальный Заказчик никогда не примет измышления аналитика за некие сакральные знания, которые он должен принять уже только потому, что они высказаны человеком, выполняющим обязанности «аналитика». Да еще если ему потом нужно нести ответственность за то, что будет делаться в соответствии с писаниями аналитиков.


А по поводу vision и категоричности опять не могу согласиться. Vision должна являться частью бизнес-плана (в иделале) и цели, поставленные в vision должны отличаться не туманностью, а высокоуровневостью, при этом принцип SMART никто не отменяет.
Я, честно говоря, не уверен, бывают ли вообще «низкоуровневые цели». По крайней мере опять нужно уточнять терминологию.  Чем хороша vision, что она может формулироваться в виде представления об идеальном согласованном действии нескольких действующих лиц и претендует на то, что эта картина будет объективна, т.е. все авторы vision согласны в единстве её понимания. А цели могут оставаться сугубо индивидуальными и даже не объективируемыми (цель - «счастье» Заказчика, но надо опять уточнять в данном случае смысл понятия «цель»).
[/quote]

Про KPI - долгий разговор. Для одних система KPI - это слепок их желаний, для других измеренные показатели - руководство к действию по устранению отклонений (генератор целей).
 

Я не предполагал всесторонне обсуждать KPI. Я предлагаю использовать его в качестве эквивиалента понятия «низкоуровневой, (объективированной)  цели».
Мне кажется наше обсуждение шло вокруг двух утверждений/вопросов:
1.   Нужна ли объективация целей и как это должно достигаться?
2.   могут ли существовать «групповые цели». Зависит ли ответ на этот вопрос от «уровня цели» (т.е. я полагал для «низкооуровневых» может быть и да, а для высокоуровневых – нет).
2.1   от ответа на это вопрос зависит, важна ли трассировка целей к конкретным авторам целей и зачем это нужно.
2.2   Как терминологически различать низкоровневые и высокоуровневые цели.

160
...Ошибки можно классифицировать по разному, но тут есть два момента: во первых заказчик никогда сам ничего не формулирует и не знает, но это не значит, что его цели не поставлены;

Трудно с этим согласиться. Про цели можно сказать, что они поставлены, только если они вербализированы (вынуты из заказчика и сформулированы словами). Словесные фомулировки могут быть осмысленными если они соответствуют мыслям/знаниям Заказчика. Если у Заказчика нет знания (он "не знает") то никакие цели поставлены быть не могут. Любые словесные упражнения на тему целей Закзачика в отсутствие понимания своих целей Заказчиком как раз и являются часто причиной катастрофических последствий, о которых Вы хорошо написали в разделе 01

Цели  Закзачика - это цели его деятельности. Если он ничего не знает про дело которое он делает, он скоро разорится или будет уволен (или его бизнес чужд логике, а хаос автомтизировать - гиблое дело).

во вторых задача аналитика вынуть из заказчика то, что он не знает;

Если аналитик ухитряется "выжать" из Заказчика цели на 300% это означает, что 200% текста про цели Заказчика придумано аналитиком. Надо честно сказать, что в данном случае эти 200% - это измышления самого аналитика. Важно, что это не цели Заказчика , а цели аналитика, которые он зачем-то навязывает Заказчику (и он даже может с ними соглашаться). Если не отделять свои мысли от мыслей Заказчика очень трудно будет проследить методически, как именно желания Заказчика обретают формализованный вид.

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

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

Если цель организации ставит аналитик и его касается всё, значит он не аналитик, а предприниматель. Стоит ли тогда удивляться, если таким аналитикам трудно найти общий язык с ключевыми руководителями организации, которые позицию предпринимателтя занимают официально? Полагаю, что истинная точка зрения на роль аналитика должна разделяться и предпринимателями и аналитиками, а за последний тезис в цитированном фрагменете можно от Заказчика и в глаз поолучить :).


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

Про то что "подлежит" - не спорю, но ничто не мешает везде в тексте ТЗ указавать, какому именно доблестному представителю бизнеса принадлежат формализованные цели. Единомыслие сотрудников организации (единая для всех цель) - опасная иллюзия. Ограничиваться выработкой vision применительно к органиазции по идее более правильно, vision ИМХО не так категорична, как цель.  И интересы - это скорее источник цели чем нечто, что "вплетается" в него, когда цели уже золотыми буквами оттиснены на бумаге.

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

Показатели эффективности KPI (это не метод) - это уже результат формализации, т.е. это уже объективированный слепок "порожденных желаний", но не метод их порождения.

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


161
To Boatman:
Согласен, что тема очень наболевшая, понравилось, как прочувствованно написан раздел 0.1 :)

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

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

Несмотря на то, что словосочетания "цели проекта" и даже "цели бизнеса" употребляются достаточно часто, как термины эти слововочетания некорректны, потому что неясно, какому именно субъекту данная цель принадлежит (кто эту цель "положил" при целеполагании).  Источниками целей, если вообще эти источники доступны для вербального рассмотрения/обсуждения являются желания и стремления конкретного человека, поэтому говорить о "применении целеполагания" ("...достаточно часто осознанное целеполагание вообще не применяется...") в этом случае все равно, что пытаться формулировать способы и методы логического порождения желаний.

Главное мое предложение:
Может быть стоит рассматривать проблемы с целями в контексте соотнесения слабо вербализованных целей (интересов) Заказчика и ключевых показателей эффективности KPI/КПЭ (это по п.1)?

В англоязычной литературе в последнее время заметно, что их стараются артикулированно отличать. В частности, у Якобсона в Aspect oriented programming рассматриваются отдельно интересы (concerns) и отдельно targets (цели), последние он фактически рассматривает как атрибуты системы. Т.е. возможно, для решения проблем с целями придется более аккуратно разложить само понятие "цель".
Насчет п.2 (ошибки аналитиков) ИМХО  продуктивное обсуждения возможно только применительно к конкретным областям предметной области Заказчиков.

Может быть не стоит называть проблемы с целями "проблемами целеполагания" - ИМХО это сужает предмет обсуждения и суть проблемы и даже выводит задачи её решения за пределы компетенции бизнес-аналитика.

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

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




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

163
2Irr

В описании стандарта BPMN сказано, что целью его разработки является обобщение существующих практик описания бизнес-процессов, поэтому, по идее, на уровне стандарта всё-что разрешают IDEF0 и IDEF3 в BPMN должно подерживаться (нотация, наверное, может отличаться). Еще BPMN должен хорошо дружить с XML, потому что, как поясняют в стандарте, его также затачивали для BPEL4WS (Business Process Execution Language for Web Services), но это более узкая задача (которая, правда, как бы его потом не угробила, когда до стандарта доберутся производители ПО этот стандарт использующий).

IDEF хорош тем, что под него есть среды для работы с диаграммами с автоматическим контролем синтаксиса диграмм (BPwin не даст нарисовать неправильные стрелочки :). А для BPMN пока кроме Visio не видел ничего, но там синтаксис не контролируется. Есть есть что лучше для BPMN, буду признателен за информацию...

164
2Boatmаn - прочитал ваш пост уже после того, как отправил свой. По сути, я с Вами согласен:
1. Первое значение - "дорожка", "напрваление"
2. Второе "область, раздел".

Дальше - ставим на голлосование :). Если ни один из вариантов не получит большинства - используем англоязычные "партишн" и "свимлэйн" (такая же история, кажется получилась с SOAP - там голосовали, как изменить расшифровку аббревиатуры, не договорилсь, с тех пор SOAP - это просто СОАП :).

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

Вот как раз для описанных Вами ситуаций (группировка сущностей, а не последовательностей действий - ведь речь в первом посте шла о диаграмме деятельности) применение термина "дорожка" звучит как-то не очень уместно. Причем с учетом того, что:
1. стандартом UML предусмотрены partitions, а не swimlanes и учитывая, что
2. partitions могут перескаться (перпендиклярно друг другу)

Придется всё-таки выбирать -
1. либо "дорожка" и, подразумеваемая для неё последовательность действий
2. либо "область"

В силу приведенных выше причин "Область (зона)" представляется более адекватным термином для этого графического объекта в силу возможного иерархического устройства partitions и их возможного наложения/пересечения. А термин "направления (работ?)" оставить для ситуаций, когда необходимо подчеркнуть напрвленный, последовательный характер действия, которые этому направлению/области соответствуют.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »