По мотивам отзыва Юрия на семинар. http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=336.0
Выношу на обсуждение вопрос: нужна ли отдельная дисциплина "управление целями" или нет.

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

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

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

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

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

---------------------------------------------------------------------

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

Между тем слово цель в литературе возникает в книгах по менеджменту и находится ближе к стратегическому менеджменту и очень редко попадается на глаза начинающим разработчикам и аналитикам.

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

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

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

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

----------------------------------------------------

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

И другой вопрос:
Насколько все, что творится у вас в проектах целесообразно? Все ли участники знакомы с целями проекта? Пишется ли концептуальный документ всегда?

ДА! ДА! ДА!
Это то, о чем я все время думаю.
Особенно интересует "...что делать, если нецелесообразное задание уже принято". Я думаю, что всем не новичкам в этом деле есть что рассказать, а новичкам будет оч интересно узнать.

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

Насчет выноса этой темы в отдельную - думаю попробывать имеет смысл. Тем действительно актуальная. Причем проблема возникает даже в случае формулировки цели. Это всегда оказывается самым сложным, хотя в СА явно указывается главенство цели.
Мои студенты постоянно сталкиваются с проблемой формулировки цели. Например в IDEF0 всегда нужно определить цель и точку зрения. Если второе более или менее прокатывает, то с первым сразу возникает проблема. Для чего мы моделируем эту задачу? Обычный ответ, чтобы автоматизировать процесс, или чтобы понять, как процесс происходит, чтобы построить модель как есть или как должно быть.

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

ОК, про гинесс я понял :-) ... думаю что нужно будет встретиться "группой активистов" UML2.ru и присоединиться желающим поучаствовать ... только место сбора нужно определить  в каком-нить уютном месте удовлетворяющем след. требованиям:
1. Место должно быть тихое, или на худой конец играющую музыку можно было бы попросить сделать тише и эту просьбу бы согласились выполнить :-)
2. Было бы неплохо, если бы там давали Гинесс :-)
3. Это было бы в пределах не более 10 мин. ходьбы от метро в пределах кольцевой линии
4. Ну, я согласен, чтобы меня угостили пинтой Гинесса (на правах шутки :-))

Единственно, я на след. неделе улечу в Иркутск, так что более реально в начале августа провести обсуждение. Можно кстати и обсудить результаты семинара ... и я могу высказать свою т.з. на доклады, и вообще, обсудить "куда бежать дальше".

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

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

Shur, угу, понятие "управления" подразумевает наличие управляющих воздействий на объект управления. Пока тут этого не видно.

И пока я вижу 2 темы:
1. управление целеполаганием - если есть возможность менять цели в процессе, то это уже похоже на УП.
2. управление целесообразностью.

Надо продумать механизмы переопределения целей и трассировки изменений

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

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

- принятие задание (любого размера: персонального или при подписании договора подряда) должно сопровождаться анализом его целесообразности

Ну анализ - это да, но не факт, что результаты этого анализа должны доводиться до заказчика работ.

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

Ты пропустил наиважнейший второй пункт - как убедиться в "правильности", "истинности" целей (что под этим понимать - надо отдельно смотреть). "Целесообразность" - это уже другое. Как ставить правильные цели?

Убедиться в правильности невозможно, по этому за постановку цели кто-то всегда берет ответственность.

Почему? Консалтинг весь не об этом ли?

Перевод книги Разработка и управления требованиями. (с сайта Telelogic.RU)
Глава 5. Разработка требований в области проблем.

Дело совсем не в том, что они не видят решения проблемы.
Дело в том, что они не видят сам проблему.

Гилберт Кит Честертон, писатель, 1874-1936

Вообщем рассматривается такая ситуация: цели как требования. Отсюда и управление.

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

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

Чтобы опять не запутаться давайте точно определим кто есть и где.
1. Субьект ставит цель.
2. Субьект превращается в Заказчика и превращает цель в задачу (задача - это цель, которая поставлена).
3. Появляется Исполнитель, который принимает постановку цели и помогает Заказчику превратить цель в задачу (ТЗ всегда пишет заказчик).

... что содержанием цели являются
- представления о результате
- представления о средствах
- намерения достижения цели

Если не ошибаюсь, это первый раз в форуме, где ты раскрываешь понятие ЦЕЛИ столь же детально, как и на семинаре.

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

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

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

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

Денис, ты говоришь "Почему? Консалтинг весь не об этом ли?". Мое мнение в том, что слово "правильно" вне контекста неприменимо. То, что правильно здесь неправильно там. Что правильно сегодня - неправильно вчера. И так далее. Основным контекстом при определении правильно в случае бизнес-консультирования я считаю поставленные цели, а чтобы не делать оговорки "правильно с точки зрения поставленных целей", мы говорим "целесообразно".

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

В случае целесообразности действий таким контекстом являются цели, в случае "правильности" целей - интересы участников. Интересно, ты мой доклад совсем что-ли не слушал? ) Я же целиком про то, что служит основой для выработки целей и ключевых свойств результата.

Если цели "ставятся" - то они же не просто из кармана вытаскиваются и ставятся, они формулируются на основе чего-то. Ты говоришь - представления о пользе, я говорю - интересы. Цели может ещё не быть, но интересы уже есть. Когда интересы совмещаются с возможностями, возникает намерение и согласуется видение, формулируется (ставится) цель. Далее можно думать о средствах её достижения.

Если цель не служит удовлетворению интересов заинтересованных сторон - то она неправильная.

Дальше на вопрос, почему в цель входят средства я отвечаю: по определению. Таково словарное определение категории цели.

Дай ссылку, ссылку дай. Я читаю Даля, Ожегова, Ефремова, вижу:

1. Место, в к-рое надо попасть при стрельбе или метании.
2. Предмет стремления, то, что надо, желательно осуществить.

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

Давай пойдём от обратного - итак, по твоему разумению "Заработать миллион в этом году" - не цель?