По итогам презентации на семинаре (http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=334.0) я обещал написать статью про целеполагание. попытка выполнить обещанное наткнулась на то, что тема глубже, чем мне казалось. Последующие обсуждения, раздумья и изучение литературы показали, что я не готов отделаться одним коротким текстом. Чтобы не затягивать и не забыть, что я это обещал. Все добытые, осмысленные и оформленные части статьи я помещаю здесь: http://boatman.h18.ru/
Прошу обсуждать, критиковать, задавать вопросы. Когда-нибудь я напишу о целях все, что можно написать, а пока я только начал и конца не видно.
По делу сейчас опубликовано только введение, его взялся отрецензировать Galogen, за что ему огромное спасибо.

Статьи переехали на сайт boatmanshome.ru

Мне понравилось! Интересно.
Возникли ассоциации с книгой Йордана "Путь камикадзе".

     Статья "Что такое цель" (http://boatman.h18.ru/cgi-bin/page.pl?1goal_000.page) достаточно сумбурно изложена. Много понятий перемешаны и некоторые моменты притянуты за уши. Похвально желание изложить свои собственные мысли, наблюдения и опыт, просто ИМХО иногда надо четко формализовать и разделять ключевые понятия. Это в анализе основа основ.

     Полностью согласен с тем, что после этапа постановки цели, следует этап выбора средств для ее реализации/достижения. Чтобы правильно и корректно сформулировать цель она должна соответствовать определенным критериям (конкретность, измеримость, достижимость и прочее). Но важно четко разделять ЦЕЛЬ и СРЕДСТВА ее достижения. В том же примере поставлена цель - "попить чаю". В качестве средств ее достижения можно предложить - попросить чаю у соседей, купить в кафе чай, медитировать до появления чашки чая и другие. ЦЕЛЬ разбивается на совокупность задач, для достижения каждой из которых выбирается соответствующее средство.
     ИМХО автор просто запутался в своей схеме. Видимо хотел написать про взаимозависимость при решении частных задач, но четко сделать это не получилось. Да и кстати в тексте смешаны понятия ЦЕЛЬ, СРЕДСТВО и ПРОЦЕСС.

З.Ы. Грамотно поставленный вопрос, уже содержит в себе ответ.

     Статья "Что такое цель" (http://boatman.h18.ru/cgi-bin/page.pl?1goal_000.page) достаточно сумбурно изложена. Много понятий перемешаны и некоторые моменты притянуты за уши. Похвально желание изложить свои собственные мысли, наблюдения и опыт, просто ИМХО иногда надо четко формализовать и разделять ключевые понятия. Это в анализе основа основ.

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

Да и кстати в тексте смешаны понятия ЦЕЛЬ, СРЕДСТВО и ПРОЦЕСС.

Не могли бы Вы уточнить, в каком именно фрагменте текста такое смешение происходит (т.е., например, когда автор пишет "процесс", а подразумевает "цель"?

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

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

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

ПРОЦЕСС : это то как с помощью СРЕДСТВ достигается поставленная ЦЕЛЬ.
В нашем случае процесс - мытье кружки, кипячение воды, заваривание чая и т.д.

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

Немного пояснений:
Можно провести аналогию с путешествием. Цель - это самая дальняя точка, которую нужно достигнуть. Например озеро в 50 км. от старта. Эта дорога разбивается на задачи, которые могут решаться как последовательно, так и параллельно, все зависит от конкретных условий. Цель и задачи это статическая карта того, куда и как мне нужно попасть.
Подмечу, что многое зависит и от успешного процесса решения задач и достижения главной цели в конце. Т.е. важен баланс: планирование – действие ( процесс). Думаю что успех зависит на 50% от планирования (постановка цели и разбиение ее на конкретные задачи) и на 50% от конкретных действий т.е. процесса достижения.
Я больше практик, меня интересует конечный результат, то что можно конкретно использовать и то что применимо и дает конкретный эффект. Итогом достижения ЦЕЛИ является некий РЕЗУЛЬТАТ (кстати это понятие совсем не затронуто в статье), который как раз и зависит от качества планирование ( постановка ЦЕЛИ и разбиение на ЗАДАЧИ) и от конкретных действий ( ПРОЦЕСС).
Можно красиво расписать цели и задачи и при этом бездарно действовать (процесс), получим неэффективное растрачивание энергии. А может быть и ситуация наоборот, когда при бездарном планировании, неясно зачем и что делаем, но делаем красиво и по стандартам.

 ИТОГО:
В статье четко обозначить  понятия цель, задачи, средства  и результат. Дать описание каждого из понятий ( например цели – основные, вспомогательные, попутные и прочее).

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


З.Ы. А вообще за форум организаторам большой РЕСПЕКТ!

Сергей, письмо получил. Сделал небольшую рецензию, но смотрю тут отличная дискуссия. Так, что подожду с замечаниями.

В некотором роде согласен с Rocket - нужна точность терминов, желательно употреблять общепринятые смыслы.

Но считаю статья уже хороша тем, что она вызывает дискуссию,  а во-вторых стимулирует автора на совершенство. Лично я учился писать статьи 3 года. Только когда написал 2 главы диссертация - научился писать и статьи (правда по плазмохимии,а не ИТ наукам)

Дальше на Ваши тезисы.
>ЦЕЛЬ:  это то необходимо достигнуть.
Цель это то, что необходимо достигнуть и то, как это необходимо достигнуть - в этом различие наших взглядов. Я в первых абзацах статьи показываю, из чего состоит цель (образ результата, образ средств, стремление достигнуть) и это подкреплено словарными статьями, а не просто моим мнением.

Интересно, а почему Вы включаете в цель средства ее достижения? Вроде как всегда было, что пчелы отдельно и мед отдельно. Это все таки разные понятия. Ведь следуя логике: ЦЕЛЬ + СРЕДСТВА = РЕШЕНИЕ. Т.е. поставленная цель, которая уже включает средства это готовое решение. Таким образом фактически при постановке цели обозначается единственно возможное решение. Расписать почему это плохо?
ИМХО тут идет подмена понятий. Цель это цель, средства это средства, решение это цель + средства. И в статье идет речь (по смыслу) о решениях.

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

Да нигде не вправляют так мозги. Это простая логика и ничего более.


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

1. Предолжил бы использовать определения целей/задач из ГОСТ
2. А почему недостаточно описать интересы/потребности пользователей, зачем нужно обязательно цели писать и декомпозировать?
3. Цели разработчику по сути не нужны. Ему нужны требования, это уже притянуто за уши. Ну из какой, например, цели следует, чтобы формы открывались в течении 2 сек.?

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

2Boatman:
Предложение Bas по использованию представлений ГОСТ может быть небесполезно. В ГОСТ задача определяется как функция или часть функции. Если изобразить иерархию целей в виде графа, то в этом графе цели - это узлы, а задачи - ребра. Причем если трактовать задачи как функции то нижняя по иерархии цель является входом этой функции, а верхняя - выходом.

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

Ну хотя бы привести мне кажется нужно

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

Так ты сам говоришь в статье, что цели вытекают из инетересов. Описываем интересы и все, цели там будут внутри.

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

Так ты сам себе противоречишь. Говоришь, что 2сек. вылезает из интереса, а не из цели, так:
1. Причем тут цели и разработчик
2. Может тогда лучше интересы описывать?

Ну не хочешь писать, не пиши.

Важность интересов заключается в том, что они являются источником остальных требований к системе.

Здрасти, а цели тогда откуда берутся?? Сами вырастают и интересы тут не причём??

Я не вижу, где я себе противоречу. Ты спросил, откуда берется требование про 2 сек, тебе ответили. Но никто не утверждал, что для сбора требований достаточно описать цели. И даже наоборот.

Я имел ввиду то, что абзац "цели нужны Разработчику" - притянут за уши. Они ему не нужны. А если ему они нужны, то значит требования описаны неполно Аналитиком.

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

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

Речь идет не о целях пользователя при создании спецификации требований. Речь идет о целеполагании вообще при любой деятельности.

Ну хорошо, какие можно тогда поставить цели, которые важны программисту?

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

Исходная мысль как я понимаю такова: неверное целеполагание является одной из основных причин краха проектов.

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

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

В данном примере все ясно и достаточно очевидно, я бы сказал даже стереотипно. Хорошо или нет действовать стереотипно - безусловно - это благо, такова сущность человеческого разума. Вопрос почему же при реализации ИТ проектов стереотипность не срабатывает, может ответ в том, что просто не накоплен тот эволюционный опыт, который дает выверенные стереотипные решения, а приходится действовать революционно пока. Ясно, что Сергей высказал здавую мысль, что при революции шаблоны неслишком хороши, более того они вредны, так как имеют лишь кажущуюся подобность (хотя мы кажется имели подобные шаблоны в Грузии и на Украине с их "оранжевыми" революциями)

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

Это вероятно эксенсивный путь ...

Статья начинается с важности целей и важности их "правильности".

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

Какие ещё вопросы волнуют меня в отношении целей:
1. Всегда ли цели персонифицированы, принадлежат субъекту, или могут висеть в воздухе.
2. Какое количество одновременных целей эффективно.
3. Как убедиться, что задавая вопрос ЗАЧЕМ - мы добрались до нужного уровня целей - в какой момент делать остановку.
4. Каков процесс формализации целей.

...
Попить чаю - это вообще-то не цель. Так как ответить на вопрос каков образ результата удается с натяжкой.
надо было писать: утолить жажду попив чаю.

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

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

Есть идея, что процесс инженерного анализа целей (goal reverse engineering) стоит останавливать в момент, когда мы добираемся до базовых ценностей субъекта-носителя целей.

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