Когда писал НИРы и НИОКРы по госзаказам, меня всегда смущали пункты "Цели" и "Задачи". Потом такое же смущение у меня вызывали похожие пункты в ТЗ на разработку ПО. Вроде разобрался.

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

"Задача – способ достижения цели"

"Отличие цели от задачи состоит в том, что цель описывается качественно, а задача — количественно!"

"Отличие целей от задач заключается в том, что цели могут определяться в качестве некоторой отдаленной перспективы без реального учёта наличных сил и возможностей"

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

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

Но лично мне понравилось различие между целями и задачами в теории деятельности А.Н.Леонтьева: задача - это данная в определенных условиях цель деятельности.

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

Ну получается, что в документах - никаких целей не надо описывать! Всё ж конкретно - чисто по задачам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Угу, я систематически прошу ПМов, которые мне приносят эти 2 списка, либо перегруппировать задачи по целям, если у них отношение 1:N, либо нарисовать диаграмму зависимостей. Не рисуют ) Похоже, это какая-то системная прошивка - "это мы не проходили, это нам не задавали, в PMBOKе и  шаблонах документов этого нет" )

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

Саша, по мне так это некий императив аналитика - если некое множество имеет критерий для различения, надо этот критерий использовать - divide et impera. А уж для "смешивать" для аналитика - страшный грех

Т.е. у тебя аргументация такая - смешивать цели и задачи - небольшая ошибка, т.к. на практике есть какие-то НО. Какие НО? Какой один аспект рассмотрен в книжке?

Если ты согласишься, что неправильно поставленные и не скорректированные цели могут с большой вероятности привести к неуспеху проекта, то как же может быть небольшой ошибкой смешение?

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

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

Про цели и задачи, без "фисолофии" (с) .... пример: Некто желает стать богатым и здоровым ... точка. И некто хочет стать богатым и здоровым ЧТОБЫ <изменить мир/...>. Сказано одно и то же, но в одном случае это может быть интерпретировано как ЦЕЛЬ, в другом как ЗАДАЧА (или подцель ;-)))))?). Дальше можно лишь уточнять, что понимается под "богатый" и "здоровый", и насколько "богатый" и "здоровый". Да, можно говорить об иерархии целей в данном случае, и говорить про outmost цель и т.п. Но важно, что цель - это измеримое состояние или некое новое свойство "суперсистемы", а задача -- это набор действий, активность, that should be done для прямого или косвенного достижения цели. "Разработать ПО для автоматизации БП" -- это задача. Ибо понятно, что разработка ПО не может быть состоянием, это процесс :-). И правда в том, и об этом говорил Сергей на семинаре, что в ряде случаев цели, для которых разрабатывается ПО не очевидны, или может быть и очевидны, но экономический эффект от этого невелик. Но может при использовании этого ПО приобретаются новые свойства?

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

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