Форум Сообщества Аналитиков
Дисциплины => Бизнес-анализ и Целеполагание => Тема начата: Алексей Ширшов от 13 Июля 2007, 15:04:22
-
Когда писал НИРы и НИОКРы по госзаказам, меня всегда смущали пункты "Цели" и "Задачи". Потом такое же смущение у меня вызывали похожие пункты в ТЗ на разработку ПО. Вроде разобрался.
Пара цитат из услышанного на просторах Рунета:
"Вообще говоря, слова "задачи" и "цели" могут быть и синонимами и тогда путать их можно сколько душе угодно. Иногда цель - это некоторое обобщенное понятие, а задачи - детализация цели... Честно говоря, я не очень понимаю, как клиент может путать задачи и цели... Обычно клиент говорит - мне надо то-то и то-то, а уже задача менеджера разложить его хотения по целям, задачам и другим полочкам..."
"Задача – способ достижения цели"
"Отличие цели от задачи состоит в том, что цель описывается качественно, а задача — количественно!"
"Отличие целей от задач заключается в том, что цели могут определяться в качестве некоторой отдаленной перспективы без реального учёта наличных сил и возможностей"
Из книги Майкла Мескона "Основы менеджмента": "Цели выражают стремление работать в определенном направлении в отличие от задач, которые представляют собой количественно измеряемые рубежи".
А если ещё вспомнить ключевые показатели эффективности и карты сбалансированных показателей, то следующее определение будет вполне легитимным: задача - это цель, переведённая в цифры.
Но лично мне понравилось различие между целями и задачами в теории деятельности А.Н.Леонтьева: задача - это данная в определенных условиях цель деятельности.
То есть задача - это конкретная цель, цель в конкретной ситуации. Конкретную ситуацию можно пощупать, измерить, взвесить. Однако жизнь и состоит из ситуаций. А цели - это задачи вне ситуаций. Абстракция. Кроме абстрактных целей, есть много того конкретного, что позволяет нам действовать одинаково в ряде ситуаций. Это принципы. Стоял на этом и буду стоять. Вера, убеждения, стремления, намерения.
Ну получается, что в документах - никаких целей не надо описывать! Всё ж конкретно - чисто по задачам.
-
Верной дорогой идете, товарищи :).
Правда, согласно ГОСТ 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. Точнее, это невозможно сделать без дублирования Задачи внутри каждого ящика. Можно пытаться отображать связь между ними только оставив все "ящики" на одном уровне, но это неудобно, особенно, когда задач достаточно много.
-
Если изображать Цели и Задачи "ящиками деятельностей" IDEF0, мы не можем сделать так, чтобы Задача была вложена одновременно и в "ящик" Цель1 и в "ящик" Цель2.
Задача - блок функциональный, а цель - это управление, как такой подход?
-
Задача - блок функциональный, а цель - это управление, как такой подход?
Пожалуй, описанную мной проблему увязывания нескольких целей с одной задачей (функциональным блоком) , такой подход решает.
Но тогда получается, что управление в данном случае - это один из входов в систему. Если достижение цели должно являться результатом работы системы, то по идее цель должна как-то соотноситься с результатом работы системы, т.е. с её выходом. Может быть целевой показатель - это всё-таки выход, а не вход системы? Управление, как правило, не сводится просто к указанию цели, это скорее реакция на рассогласование имеющихся результатов с целевыми. Например, представляется достаточно странным указывать в качестве управления (цели) "достижение заданной доли рынка такого-то вида услуг" и даже "подготовка налоговой отчетности".
ИМХО в этом смысле IDEF0 вообще не приспособлен для указания целей и, возможно, не стоит грузить "старичка" задачами для которых он изначально не предназначался.
Возможно, удобнее для этих целей использовать диаграмму Use cases. Если подразумевать под UC некий набор задач, которые могут быть использованы в качестве средства для достижения цели, то увязав их с конкретными действующими лицами мы неявно увязываем их (UC и задачи) с целями эти лиц. И если проблемы проекта связаны именно с логикой увязки действующих лиц (и их целей) с задачами, то такая картинка может быть полезна для обсуждения с другими и даже для собственного понимания :).
-
Всем привет.
Цель и задача: качество и количество, внутреннее и внешнее, субъективное и объективное.
Но в разговоре про различие целей и задач есть еще один момент. По теории:
- система состоит из элементов;
- каждый элемент системы подчиняется общей цели;
- каждый элемент системы оказывает влияние на все другие элементы системы.
Общая цель системы не только определяет вектор развития, но и объединяет элементы в системе. Эффективная специализация элементов системы превращается в их взаимозависимость. И система в рамках своей общей цели сама должна порождать утилитарные задачи для поддержания своей целостности, поддержки своим несамостоятельным элементам.
IMHO, если электронная система собирается существовать минуты 2-3, то разница между ее целями и задачами не успеет возникнуть. При длинном времени, цель объединяет элементы в систему и определяет вектор ее развития, вырабатывает задачи.
Если система вдруг достигнет своей цели (ну, так получилось), будет достигнут минимум энтропии с внешней средой, такая система прекратит свое существование, распадется. Выполнение задач является частным событием в жизни системы. Вслед за одной задачей, возникает другая ... вперед к светлому будущему.
-
Если достижение цели должно являться результатом работы системы, то по идее цель должна как-то соотноситься с результатом работы системы, т.е. с её выходом. Может быть целевой показатель - это всё-таки выход, а не вход системы?
Абсолютно правы - бес попутал :-)
А вообще моделирование цели можно производить разными путями. Лучше вероятно для этого использовать не UC, а диаграммы классов со стереотипом "goal" (в розе мишень со стрелочкой). В результате можно попытаться реализовать структурную модель:
цель - качественная и количесвенная
цель - атрибуты (формул-ка цели, критерии достижения, факторы риска. ограничения и т.п.)
цель - операции (даже не знаю что придумать)
Далее можно сделать связь - цель - решается в ходе - задача - имеет - вариант решения - формализируется в виде - вариант использования - состоит из - ....
-
На мой взгляд, если стоит задача "загрузить" IDEF целями, то самое логичное представить цели ресурсами на выходе процесса. Тогда функция на диаграмме - это процесс достижения цели, входы - достигнутые подцели, механизмы - средства. Управление - критерии достижения. Так можно учесть тот факт, что многие подцели поддерживают достижение многих целей. Да и другие факты можно учесть... Прошу критиковать такой вариант.
Фактически такое толкование допускает любая уже существующая IDEF0 диаграмма. Проблема если у нас одна подцель (задача) соответствует нескольким целям. В BPwin такое нарисовать можно только разместив все цели и подцели на одной диаграмме. Жалко, что в этом случае нет возможности "упаковать" подцель "внутрь" обоих целей, как это можно сделать для "обычной" иерархической структуры задач (с непересекающимися ветвями иерархии).
-
Всем привет.
Цель и задача: качество и количество, внутреннее и внешнее, субъективное и объективное.
Но в разговоре про различие целей и задач есть еще один момент. По теории:
- система состоит из элементов;
- каждый элемент системы подчиняется общей цели;
- каждый элемент системы оказывает влияние на все другие элементы системы.
Общая цель системы не только определяет вектор развития, но и объединяет элементы в системе. Эффективная специализация элементов системы превращается в их взаимозависимость. И система в рамках своей общей цели сама должна порождать утилитарные задачи для поддержания своей целостности, поддержки своим несамостоятельным элементам.
IMHO, если электронная система собирается существовать минуты 2-3, то разница между ее целями и задачами не успеет возникнуть. При длинном времени, цель объединяет элементы в систему и определяет вектор ее развития, вырабатывает задачи.
Если система вдруг достигнет своей цели (ну, так получилось), будет достигнут минимум энтропии с внешней средой, такая система прекратит свое существование, распадется. Выполнение задач является частным событием в жизни системы. Вслед за одной задачей, возникает другая ... вперед к светлому будущему.
Вы излагаете очень ценный взгляд на цели в рамках деятельности по системной интеграции. Т.е. фактически процесс создания/разработки элементов системы в данном тезисе не рассматривается. Система собирается из элементов и содержание функционирования системы в данном тезисе сводится к взаимодействию элементов. Это фактически квинтессенция подхода к созданию систем из готовых элементов, т.е. системной интеграции.
1. Насчет того, что система порождает цели - такое утверждение ИМХО справдливо, если Вы полагаете под системой не только программно-технический комплекс (компьютер), но и людей которые используют его в соответствии со своими целями (цели порождают люди). Очень часто под системой подразумевают всё-таки именно компьютер и при таком прочтении, конечно, утверждать возможность постановки цели самой системой несколько странно. Но такое терминологическое различие использования понятие "система" приходится иметь в виду. В том числе при обсуждениях в данном форуме :).
2. Насчет проблем функционирования системы: насколько я понял, в своем тезисе вы рассматривали проблему рассогласования целей системы в целом и задач отдельных элементов системы. Но важны не только проблемы рассогласования как таковые (в частности, временные лаги целеполагания и получения результата), а проблемы, с которыми сталкиваются при попытке эти рассогласовани устранить. Для больших систем при попытке уточнить задачи под новые цели, задачи начинают конфликтовать между собой и большая часть работы связана именно с устранением этих конфликтов (возможно, доработкой элементов системы). Иногда для устранения этих конфликтов приходится пересматривать и первоначально сформулированные цели....