Форум Сообщества Аналитиков
Дисциплины => Бизнес-анализ и Целеполагание => Тема начата: boatman от 10 Августа 2007, 00:52:35
-
По итогам презентации на семинаре (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. Хорошо бы дать возможность комментировать прямо по тексту - используя механизм вики или блога.
-
С ходом дискуссии проблематика все больше размывается и тема становится пугающе большой.
Чтобы не тонуть в материале предлагаю тезисы соотносить с рамками контекстов. ИМХО можно рассматривать высказывания применительно к трем вложенным рамкам, ограничивающим контексты: Культура (наиболее общий контекст, в котором обсуждаются наиболее общие термины и понятия), рамка деятельности (с конкретизируемыми/измеримыми резцльтатми/показателеми), рамка бизнеса (допускает обсуждение в экономических показателях), рамка автоматизации.
Насколько я понял, Вы предполагали рассматривать формирование иерархи подцелей и задач в рамках автоматизации деятельности? И что можно логическими средствами установить внутреннюю непротиворечивость заявляемых Заказчиком целей на основе анализа этих целей и располагаемых средств (и ресурсов) для достижения этх целей путем их автоматизации.
И что в рассматриваемом подходе важно избежать при анализа выхода за рамки автоматизации (в более широкие рамки - бизнеса и культуры) для установления непротиворечивости целей?
-
Я благодарю господина Boatman за написанную статью. Поднятая тема о целеполагании заставила меня освежить в памяти много разных материалов; и покопаться среди своих "тараканов".
Цель является сущностью, организующей любую деятельность за счет выстраивания целей и связанных с ними действий в иерархическую структуру
Мне кажется, что при рассмотрении темы смешиваются две совершенно разные проблемы. А их надо бы рассматривать раздельно.
С одной стороны, есть проблема субъекта, работающего над проектом. Это вопрос о правильности постановки целей самим разработчиком (или командой проекта). И если рассматривать теоретические установки только в этой части, то у меня тут очень мало возражений. Цель, средства, результат - система организации работы над проектом должна быть хорошо проработана.
С другой стороны, есть объект, пользователь (заказчик). Проектируя компьютерную систему, мы, на самом деле, не знаем целей пользователей, их потребностей, мотивов, установок, стереотипов, ценностей, ... Мы не формируем цели пользователя, мы пытаемся их выявить для построения программы. Мы используем ту или иную специфическую методику, а сказать точнее, язык, для описания предполагаемых действий пользователя. В этом-то и состоит вопрос, а можем ли мы, в принципе, точно и полно выявить истинные цели пользователя?
чтобы разобраться в сложной деятельности надо вытащить на свет ее каркас - иерархию целей
Эта фраза порождает во мне внутреннее противоречие. С точки зрения меня, как компьютерного инженера, все верно. Правильный процесс разработки действительно должен базироваться на четких требованиях к системе.
Но мне, как дипломированному психологу, понятно и другое:
- Человек не является константой, его цели, мотивы, интересы постоянно(!) меняются. Не только меняются, но и переструктурируются.
- В иерархии целей человека, всегда найдутся надцели, находящиеся вовне. Вне компьютера, вне данной фирмы, вне рассматриваемой нами предметной области. И именно этой надцелью может определяться поведение и заказчика, и пользователя.
При конструировании новой деятельности следует учитывать баланс интересов.
Разнообразие интересов (и целей) существует и у отдельного человека(!). Это тоже надо учитывать.- И последнее. А откуда вообще берется априори принимаемое утверждение, что человек обязательно действует целенаправленно. С чего это Вы так уверены, что заказчик (у которого получаем требования) или пользователь (при работе за компьютером), что-то планируют в своей деятельности? А как же спонтанность, интуитивность, как же эмоции ..?
Здесь я был краток. При желании можно рассмотреть указанные тезисы подробно, со ссылками на источники.
-
С одной стороны, есть проблема субъекта, работающего над проектом. Это вопрос о правильности постановки целей самим разработчиком (или командой проекта). И если рассматривать теоретические установки только в этой части, то у меня тут очень мало возражений. Цель, средства, результат - система организации работы над проектом должна быть хорошо проработана.
ИМХО важно учитывать, что цели есть как у субъекта-разработчика, так и у субъекта-заказчика и не стоит сводить заказчика исключительно к объекту воздействия разработчика. Т.к. заказчик субъектен, и скорее даже "субъекктивен", то его "тараканы", интуиция и пр., о чем Вы пишете ниже, способно преподнести немало сюрпризов разработчику при реализации проектов. ОБъект тем и отличается от субъекта, что субъект осознанно воздействует на объект, а объект- нет.
С другой стороны, есть объект, пользователь (заказчик). Проектируя компьютерную систему, мы, на самом деле, не знаем целей пользователей, их потребностей, мотивов, установок, стереотипов, ценностей, ... Мы не формируем цели пользователя, мы пытаемся их выявить для построения программы. Мы используем ту или иную специфическую методику, а сказать точнее, язык, для описания предполагаемых действий пользователя. В этом-то и состоит вопрос, а можем ли мы, в принципе, точно и полно выявить истинные цели пользователя?
Возможно, вы имели в виду, что мы не значем цели пользователя "до проектирования системы" ? Потому что проектирование без цели Заказчика ИМХО представить себе достаточно трудно (ну только если проектируем для себя, и то, для целей проектирования важно представлять себя как пользователя рефлексивно - в третьем лице).
Эта фраза порождает во мне внутреннее противоречие. С точки зрения меня, как компьютерного инженера, все верно. Правильный процесс разработки действительно должен базироваться на четких требованиях к системе.
Но мне, как дипломированному психологу, понятно и другое:
- Человек не является константой, его цели, мотивы, интересы постоянно(!) меняются. Не только меняются, но и переструктурируются.
- В иерархии целей человека, всегда найдутся надцели, находящиеся вовне. Вне компьютера, вне данной фирмы, вне рассматриваемой нами предметной области. И именно этой надцелью может определяться поведение и заказчика, и пользователя.
- Разнообразие интересов (и целей) существует и у отдельного человека(!). Это тоже надо учитывать.
- И последнее. А откуда вообще берется априори принимаемое утверждение, что человек обязательно действует целенаправленно. С чего это Вы так уверены, что заказчик (у которого получаем требования) или пользователь (при работе за компьютером), что-то планируют в своей деятельности? А как же спонтанность, интуитивность, как же эмоции ..?
Здесь я был краток. При желании можно рассмотреть указанные тезисы подробно, со ссылками на источники.
Люди тысячи строят корабли, более сотни лет делают сталь и машины, десятки лет самолеты и компьютеры. Все эти практки связаны с сознательной деятельностью человека. Причем, например, для создания технических достижений их творцы часто десятилетиями шли к одной цели (есть много мемуаров и автобиографий, а плодами их трудов мы пользуемся и теперь). Конечно, можно обсуждать конкретные практики, конкретных субъектов и способы установления (верификации) их целей. Но подвергать сомнению возможность целенаправленной деятельности несколько странно. Ведь вряд ли Вы согласитесь, что когда Вы набирали этот пост Вы не дейстовали осознанно и даже не имели в виду достижение никакой цели этим действием?
-
2 tolldo - отличное и важное замечание про субъект и объект. +1
Думаю тут стоит отметить еще один нюанс, который в дискуссии не был четко обозначен ( спасибо tolldo за пост, натолкнул на хорошую мысль).
Основной задачей при проектировании ПО является автоматизация существующих БИЗНЕС-ПРОЦЕССОВ (БП) предприятия или организации. Вопрос не в том, насколько полно и точно мы выявляем цели, потребности, мотивы и установки пользователей, а в том насколько точно и полно разрабатываемое ПО маппируется на существующие БП. Т.е. насколько полно разрабатываемое ПО автоматизирует БП (функции, задачи и операции). Пользователь является связующим элементом между БИЗНЕС-ПРОЦЕССОМ (любым) и ПО.
К примеру, у нас есть некая организация, которая занимается торговлей канцелярскими товарами со склада. Необходима разработка, ПО которое позволяет автоматизировать БИЗНЕС-ПРОЦЕССЫ закупки товара, отслеживания товара на складе, продажи товаров, управления отношением с клиентом и прочего. И уже в рамках этих конкретных процессов нужно выявлять конкретные цели и задачи конкретных пользователей.
Скажу свою мысль проще: Невозможно разработать ПО, без знания и использования в качестве ориентира, существующих БИЗНЕС-ПРОЦЕССОВ организации.
Иначе получаются какие то "сферические" пользователи в вакууме. Которые хотят непонятно что и непонятно как.
2 Galogen - тоже очень верно подмечено
В данном примере все ясно и достаточно очевидно, я бы сказал даже стереотипно. Хорошо или нет действовать стереотипно - безусловно - это благо, такова сущность человеческого разума. Вопрос почему же при реализации ИТ проектов стереотипность не срабатывает, может ответ в том, что просто не накоплен тот эволюционный опыт, который дает выверенные стереотипные решения, а приходится действовать революционно пока. Ясно, что Сергей высказал здравую мысль, что при революции шаблоны не слишком хороши, более того они вредны, так как имеют лишь кажущуюся подобность (хотя мы кажется имели подобные шаблоны в Грузии и на Украине с их "оранжевыми" революциями)
Еще предложение-вопрос, а не следует ли к целям подходить не с позиции системности, т.е. сверху - вниз, а наоборот снизу-вверх, т.е. от интересов пользователей к ролевым задачам и дальше к целям? С уже последующим нисходящим преобразованиям в виде требований на реализацию?
Идеальный вариант: На предприятии имеется "полная и адекватная" модель БИЗНЕС-ПРОЦЕССОВ предприятия. Соответственно, когда начинается проектная деятельность по внедрению ПО, разработчик в лице Системного аналитика используя формализованную модель БП Заказчика пишет требования к ПО и согласовывает их с Заказчиком ( итерационный процесс).
В таком варианте особенных проблем и трудностей нет.
Типичный вариант: Описание БП отсутствует как таковое вообще. Заказчик сам до конца не знает, что и как у него работает. В этом варианте и начинаются все описанные в дискуссии проблемы по выявлению целей и задач. Как раз именно таких проектов в ИТ сфере по разработке ПО большинство. Когда Заказчик со своей стороны не знает что и как у него работает ( в большей или меньшей степени), соответственно и не может четко сформулировать требования к ПО. Разработчик же, тем более не знает как работает Заказчик, какие у него есть БП и что собственно от него хочет Заказчик.
ИМХО. При постановке целей и задач Разработчику строго обязательно необходимо использовать в качестве базы - БП Заказчика и идти сверху – вниз.
Хм . . . тогда вопрос в том есть ли какие методы (применяемые и работающие) для выявления требований Заказчика в "типичном варианте"?
-
Необходима разработка, ПО которое позволяет автоматизировать БИЗНЕС-ПРОЦЕССЫ закупки товара, отслеживания товара на складе, продажи товаров, управления отношением с клиентом и прочего. И уже в рамках этих конкретных процессов нужно выявлять конкретные цели и задачи конкретных пользователей.
Скажу свою мысль проще: Невозможно разработать ПО, без знания и использования в качестве ориентира, существующих БИЗНЕС-ПРОЦЕССОВ организации.
Правильно ли я Вас понимаю: первичны бизнес-процессы, цели вторичны? Т.е. в жизни сначала появляется бизнес-процесс, и для порождения этого бизнес-процесса его создателям/пользователям цели не нужны?
Типичный вариант: Описание БП отсутствует как таковое вообще. Заказчик сам до конца не знает, что и как у него работает. В этом варианте и начинаются все описанные в дискуссии проблемы по выявлению целей и задач. Как раз именно таких проектов в ИТ сфере по разработке ПО большинство. Когда Заказчик со своей стороны не знает что и как у него работает ( в большей или меньшей степени), соответственно и не может четко сформулировать требования к ПО. Разработчик же, тем более не знает как работает Заказчик, какие у него есть БП и что собственно от него хочет Заказчик.
Т.е. наличие описания бизнес-процесса уже гарантирует возможность укзания цели Заказчика ("чего хочет Заказчик")?
-
Правильно ли я Вас понимаю: первичны бизнес-процессы, цели вторичны? Т.е. в жизни сначала появляется бизнес-процесс, и для порождения этого бизнес-процесса его создателям/пользователям цели не нужны?
Если речь идет о целях пользователей то Вы понимаете правильно. Цели пользователей вторичны по отношению к БИЗНЕС-ПРОЦЕССАМ.
Т.е. наличие описания бизнес-процесса уже гарантирует возможность указания цели Заказчика ("чего хочет Заказчик")?
Да безусловно.
Я просто не понимаю как можно говорить о выявлении целей пользователей в отрыве от БИЗНЕС-ПРОЦЕССОВ (БП).
Есть компания, у нее деятельность, которая состоит из БП, и которые в конечном итоге приносят ей прибыль. Любой БП можно декомпозировать сверху - вниз до самого нижнего (требуемого) уровня, до уровня конкретных задач конкретных пользователей. Например БИЗНЕС-ПРОЦЕСС "Закупка товара" можно декомпозировать до уровня конкретных задач, когда работнику необходимо сделать: 1. Найти контрагента. 2. Выяснить условия поставок. 3. Провести предварительные переговоры. и т.д. Это задачи со стороны пользователя!
Со стороны же реализации в ПО этих конкретных задач, конкретного пользователя нужно выполнить уже другие задачи, например: 1. Подключится к БД 2. Обновиться БД. и прочее
Один и тот же процесс например отправки емайл письма по разному реализуется в различном ПО. Просто хочу сказать что не нужно все мешать в одной корзине.
С одной стороны, (стороны Заказчика) имеются БИЗНЕС-ПРОЦЕССЫ которые декомпозируются до уровня конкретных задач, конкретных пользователей (работников). Сами БП есть и будут независимо от ПО.
С другой стороны, (стороны Разработчика) имеются потребности Заказчика в автоматизации части своих БП. И задача Разработчика состоит в понимании протекания БП Заказчика, выяснения требований Заказчика в части автоматизации БП (какие именно БП, какие задачи) и маппировании их на конкретное ПО. И вот тут Самое Главное !!!
Вопрос в там как конкретные задачи конкретных пользователей Заказчика выявить, формализовать в виде конкретных требований, и затем уже реализовать в разрабатываемом ПО.
-
Один и тот же процесс например отправки емайл письма по разному реализуется в различном ПО. Просто хочу сказать что не нужно все мешать в одной корзине.
Кто (заказчик или разработчик) будут решать каким именно ПО будет реализоваться данный процесс? На основании чего он будет принимать это решение?
Или, если я Вас правильно понял, поскольку описание процессво в терминах бизнеса принципиально отличаются от описания соответствующих им процессов (задач) автоматизированной системы ("не смешиваются"), то каким именно ПО будет реализован бизнес-процесс Закзачика, самому Заказчику не важно?
Вопрос в там как конкретные задачи конкретных пользователей Заказчика выявить, формализовать в виде конкретных требований, и затем уже реализовать в разрабатываемом ПО.
А в самом деле - как выявить? Какие вопросы нужно задать, например?
-
Основной задачей при проектировании ПО является автоматизация существующих БИЗНЕС-ПРОЦЕССОВ (БП) предприятия или организации. Вопрос не в том, насколько полно и точно мы выявляем цели, потребности, мотивы и установки пользователей, а в том насколько точно и полно разрабатываемое ПО маппируется на существующие БП. Т.е. насколько полно разрабатываемое ПО автоматизирует БП (функции, задачи и операции). Пользователь является связующим элементом между БИЗНЕС-ПРОЦЕССОМ (любым) и ПО.
А вот это большая и типичная ошибка всех автоматизаторов. Описали БП и все. Получили кучу ненужной макулатуры. Да БП важны никто не спорит и их надо учитывать при выявлении цели, но все-таки цели отдельно, а потом уже БП если надо.
-
Внесу еще большую сумятицу. После семинара про Agile, я нарисовал картинку про движении к цели в случае как предлагает Сергей и в случае как учит Agile.
-
Кто (заказчик или разработчик) будут решать каким именно ПО будет реализоваться данный процесс? На основании чего он будет принимать это решение?
Или, если я Вас правильно понял, поскольку описание процессов в терминах бизнеса принципиально отличаются от описания соответствующих им процессов (задач) автоматизированной системы ("не смешиваются"), то каким именно ПО будет реализован бизнес-процесс Заказчика, самому Заказчику не важно?
Как показывает практика, зачастую такие решения принимаются: - Шеф сказал так, значит так. И Баста !
В идеале конечно необходим набор требований со стороны Заказчика. Ну а далее с помощью этого набора требований осуществляется выбор ПО, уполномоченным на это должностным лицом. :)
А в самом деле - как выявить? Какие вопросы нужно задать, например?
В этом и заключается профессионализм и мастерство разработчиков ПО.
Насколько я знаю существуют как методологии так и стандарты. В этом вопросе следует ориентироваться на западные методологии, т.к. сами прекрасно понимаете что у нас как таковой теоретической и опытной базы нет в стране. Навскидку вспомню методологию RUP, и наши ГОСТы 19 и 34 серии. Есть еще забугорный стандарт на описание ТЗ к ПО, но сейчас его названия не помню.
Оффтоп: Мне просто интересен вопрос использования и применимости существующих методик и стандартов, на всех этапах работы Заказчик - Разработчик. Наверно пожалуй на начала необходимо расписать или выложить готовый схему процесса разработки ПО.
-
А вот это большая и типичная ошибка всех автоматизаторов. Описали БП и все. Получили кучу ненужной макулатуры. Да БП важны никто не спорит и их надо учитывать при выявлении цели, но все-таки цели отдельно, а потом уже БП если надо.
Я не автоматизатор. Я работаю с другой стороны "барикад".
БП важны: 1. Заказчику для четкого понимания происходящих в его компании/предприятии процессов. Т.е. что, где, когда и как происходит. Чем больше компания - тем важнее иметь описание БП.
2. В процессе выявления требований Заказчика к разрабатываемому ПО.
Мне вот все интересно: о каких таких целях утверждает bas ?
Есть компания, в ней есть должности - бухгалтера, директора, продавца и прочих. Эти должности имеют свои должностные инструкции - кто что делать должен и за что отвечает. Должности и инструкции не появляются на пустом месте. Они не абстрактны. Они появляются в силу необходимости реализации БИЗНЕС-ПРОЦЕССОВ.
-
2Rocket:
Вы к сожалению, ушли от ответа на оба мои вопроса :). Несмотря на их кажущуюся тривиальность, в жизни ответ на них полчается не всегда просто.
Если решения по тому - какое ПО, принимает ШеФ, то важно Шеф - кто? Разработчик или Заказчик?
Жаль, что по второму вопросу вы сразу адресовали меня обширному материалу по западным методологиям. К сожалению, готовых вопросов, которыми можно выяснить задачи Заказчика, там нет.
Необходимость описания БП никто из участников данного обсуждения не оспаривает. Утверждается, что эти БП выполняются с опредленной целью, некоторое приближение к которой (по идее) реализуется результатом выполнения БП.
Необходимость включения ожидаемых результатов в описание БП Вы не оспариваете?
-
Могу ответить точнее.
Вы к сожалению, ушли от ответа на оба мои вопроса . Несмотря на их кажущуюся тривиальность, в жизни ответ на них полчается не всегда просто.
Если решения по тому - какое ПО, принимает ШеФ, то важно Шеф - кто? Разработчик или Заказчик?
Решение по выбору ПО принимает ШеФ - Заказчик. Кто платит деньги, тот и танцует. Вроде всегда было именно так.
Жаль, что по второму вопросу вы сразу адресовали меня обширному материалу по западным методологиям. К сожалению, готовых вопросов, которыми можно выяснить задачи Заказчика, там нет.
Я согласен, это сложный вопрос. Не так все просто как хотелось бы. В теории просто, а в жизни имеется большое количество "подводных камней", и существующая методология хоть как то помогает их обходить.
Непонятная формулировка.
Утверждается, что эти БП выполняются с опредленной целью, некоторое приближение к которой (по идее) реализуется результатом выполнения БП.
Необходимость включения ожидаемых результатов в описание БП Вы не оспариваете?
Изначально БП возникают в процессе создания организации или предприятия. Для обеспечения протекания этих БП нужны определенные работники, которые выполняют фиксированный перечень должностных задач. Например есть БП - "Закупки" который состоит из следующих стадий:
1. Определение потребности в материале
2. Выбор поставщиков:
2.1 Подготовка списка возможных поставщиков.
2.2 Отправка запроса в соответствии с заявкой на материал.
2.3 Выбор поставщиков.
3. Обработка заказов
4. Контроль выполнения условий договора
5. Поступление материала
6. Оприходование материала
7. Контроль счетов
В этом примере БП "Закупка" декомпозирован на конкретные задачи (функции или подпроцессы) "1-7", и для примера задача "2. Выбор поставщиков" разложена вниз на более мелкие задачи. "2.1, 2.2, 2.3". Далее возможна декомпозия на еще более мелкие задачи, вплоть до примитивных задач - взять ручку, взять бумагу и т.д.
Просто хочу донести мысль, что любой БП в компании может быть разложен на ряд совсем простых задач, автоматизация которых и позволит в сумме автоматизировать весь БП, или ту его часть которую требовал Заказчик.
-
...
Основной задачей при проектировании ПО является автоматизация существующих БИЗНЕС-ПРОЦЕССОВ (БП) предприятия или организации.
Да что вы говорите )
Я вот сходу могу назвать следующие нечёткие классы ПО:
* Заказное ПО
* Встраиваемое ПО
* Публичные массовые веб-системы
* Персональное коробочное ПО
* Корпоративное коробочное ПО
* Игры
* «Одноразовые» приложения
* Системные приложения
И бизнес-процессы как таковые нужны только для 2-3 из них.
Кроме того, тема, затронутая Boatman, более широкая, чем проекты по автоматизации, целеполагание нужно и в несвязанных с IT-проектами - например, развитие бизнеса.
Вопрос не в том, насколько полно и точно мы выявляем цели, потребности, мотивы и установки пользователей, а в том насколько точно и полно разрабатываемое ПО маппируется на существующие БП. Т.е. насколько полно разрабатываемое ПО автоматизирует БП (функции, задачи и операции).
Это классическая проблема с асфальтированием дорог, по которым ходят коровы. ПО должно не автоматизировать процессы, а помогать решать бизнес-задачи. Вот эти самые бизнес-задачи и формулируются в ходе целеполагания.
К примеру, у нас есть некая организация, которая занимается торговлей канцелярскими товарами со склада. Необходима разработка, ПО которое позволяет автоматизировать БИЗНЕС-ПРОЦЕССЫ закупки товара, отслеживания товара на складе, продажи товаров, управления отношением с клиентом и прочего. И уже в рамках этих конкретных процессов нужно выявлять конкретные цели и задачи конкретных пользователей.
Вы про фазу ПРОЕКТИРОВАНИЯ систем и цели ПОЛЬЗОВАТЕЛЕЙ в рамках целевых бизнес-процессов, мы же - про фазу ИНИЦИАЦИИ и цели ЗАИНТЕРЕСОВАННЫХ ЛИЦ (прежде всего, Заказчика, но не только). Такое ощущение, что вы презентацию Boatman не смотрели.
Хм . . . тогда вопрос в том есть ли какие методы (применяемые и работающие) для выявления требований Заказчика в "типичном варианте"?
Эта тема уже раскрывалась мной (http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=65.0).
-
Могу ответить точнее.Решение по выбору ПО принимает ШеФ - Заказчик. Кто платит деньги, тот и танцует. Вроде всегда было именно так.
Важно тогда понять, из каких именно сооображений он принимает решение по выбору конкретного ПО? Если предлагаемые ПО различны, то значит они обладают какими-то различными характеристками. И Шеф будет решать, что именно даст его бизнесу внедрение того или иного ПО. Для оценки он будет пользоваться какими-то критериями, по которым он оценивает успешность своей деятельности. Эти критерии, собственно, и характеризуют цели бизнеса либо являются следствием главных критериев учпешности бизнеса. Нет целей - нет критериев.
Изначально БП возникают в процессе создания организации или предприятия. Для обеспечения протекания этих БП нужны определенные работники, которые выполняют фиксированный перечень должностных задач. Например есть БП - "Закупки" который состоит из следующих стадий:
1. Определение потребности в материале
2. Выбор поставщиков:
2.1 Подготовка списка возможных поставщиков.
2.2 Отправка запроса в соответствии с заявкой на материал.
2.3 Выбор поставщиков.
3. Обработка заказов
4. Контроль выполнения условий договора
5. Поступление материала
6. Оприходование материала
7. Контроль счетов
В этом примере БП "Закупка" декомпозирован на конкретные задачи (функции или подпроцессы) "1-7", и для примера задача "2. Выбор поставщиков" разложена вниз на более мелкие задачи. "2.1, 2.2, 2.3". Далее возможна декомпозия на еще более мелкие задачи, вплоть до примитивных задач - взять ручку, взять бумагу и т.д.
Просто хочу донести мысль, что любой БП в компании может быть разложен на ряд совсем простых задач, автоматизация которых и позволит в сумме автоматизировать весь БП, или ту его часть которую требовал Заказчик.
Насчет разложимости БП по задачам я думаю, никто врзражать не будет.
Вопрос в том, можете ли Вы указать, в каких именно показателях Вы определяет потребности в материалах, какими показателями характеризуется результат обработки, какие именно показатели необходимо должны быть результатом выполнения перечисленных Вами задач 1-7?
Ведь названия задач не раскрывают точно, что именно требуется получить в результате их выполнения.
-
Оффтоп: Мне просто интересен вопрос использования и применимости существующих методик и стандартов, на всех этапах работы Заказчик - Разработчик. Наверно пожалуй на начала необходимо расписать или выложить готовый схему процесса разработки ПО.
Вы не поверите, но схема организации процесса разработки ИС также освещалась мной (http://web.archive.org/web/20060621200237/beskov.ru/2006/01/31/obzor-protsessa-razrabotki-is/). Ну и, само собой, в RUP/MSF и книжках по автоматизации - Калянов и проч.
-
Да что вы говорите )
Я вот сходу могу назвать следующие нечёткие классы ПО:
* Заказное ПО
* Встраиваемое ПО
* Публичные массовые веб-системы
* Персональное коробочное ПО
* Корпоративное коробочное ПО
* Игры
* «Одноразовые» приложения
* Системные приложения
И бизнес-процессы как таковые нужны только для 2-3 из них.
С последней фразы я плакаль :)
Оказывается это БП нужны для ПО,а не наооборот. Т.е. в принципе ПО существует само по себе, в отрыве от окружающей действительности. Бугога :))))
Зачем читать то что не написано? Зачем искать черную кошку там где ее нет?
Я написал:
Основной задачей при проектировании ПО является автоматизация существующих БИЗНЕС-ПРОЦЕССОВ (БП) предприятия или организации..
Насколько известно ПО по назначению разделяется на: системное, прикладное и инструментальное.
Речь идет в дисскусии идет о разработке прикладного ПО по требованиям Заказчика. При чем приведенная Вами "классификация" непонятно. Можно конечно долго фантазировать и выдумать собственные типы классификации ПО. Но . . .
Второй раз повторюсь, что я не разработчик, поэтому ЛИЧНО для меня вопрос методологии проектирования ПО до конца не изучен.
-
Насчет разложимости БП по задачам я думаю, никто возражать не будет.
Вопрос в том, можете ли Вы указать, в каких именно показателях Вы определяет потребности в материалах, какими показателями характеризуется результат обработки, какие именно показатели необходимо должны быть результатом выполнения перечисленных Вами задач 1-7?
Ведь названия задач не раскрывают точно, что именно требуется получить в результате их выполнения.
Тут не нужно изобретать велосипед. Такие вопросы выясняются в процессе либо интервьюирования сотрудников организации Заказчика. Либо в письменной форме предоставляются Заказчиком Разработчику.
-
С последней фразы я плакаль :)
Оказывается это БП нужны для ПО, а не наооборот. Т.е. в принципе ПО существует само по себе, в отрыве от окружающей действительности. Бугога :))))
Я имел в виду - бизнес-процессы как объект изучения и моделирования.
Зачем читать то что не написано? Зачем искать черную кошку там где ее нет?
Я написал:
Насколько известно ПО по назначению разделяется на: системное, прикладное и инструментальное.
Речь идет в дисскусии идет о разработке прикладного ПО по требованиям Заказчика. При чем приведенная Вами "классификация" непонятно. Можно конечно долго фантазировать и выдумать собственные типы классификации ПО. Но . . .
Хорошо, простой вопрос - World of Warcraft - это какое ПО по назначению? Заказчик у него есть?
И здесь не идёт речь от требованиях заказчика к ПО, этому посвящен отдельный раздел форума. Здесь речь о целеполагании.
Второй раз повторюсь, что я не разработчик, поэтому ЛИЧНО для меня вопрос методологии проектирования ПО до конца не изучен.
Проектирование, например, по RUP - одна из 9 дисциплин. Проектирование ПО происходит на основании Требований, Требования появляются на основе целевого Бизнес- и сценарного Моделирования, им предшествует Постановка целей. Вы упорно про Проектирование (которое не отсюда), а нам щас интереснее Постановка целей %)
-
Я имел в виду - бизнес-процессы как объект изучения и моделирования.
Хорошо, простой вопрос - World of Warcraft - это какое ПО по назначению? Заказчик у него есть?
World of Warcraft относится к классу прикладного ПО: к мультимедия - компьютерные игры. Заказчик - одно из подразделений компании Blizzard Entertainment. Скорее всего департамент маркетинга совместно с дирекцией.
Разработчик - тоже один из внутренних департаментов, и тоже скорее всего не один.
За ссылки спасибо.
-
Тут не нужно изобретать велосипед. Такие вопросы выясняются в процессе либо интервьюирования сотрудников организации Заказчика. Либо в письменной форме предоставляются Заказчиком Разработчику.
Вы упорно избегаете отвечать на заданные вопросы. Вопрос был не когда или во процессе чего описываются результаты, а нужно, или не нужно описывать результаты при описании БП (если уж мы их делаем). И какие результаты должны быть получены при решении перечисленных Вами задач. И Вы на эти вопросы так и не ответили.
А насчет выяснения при интервьюировании....При том что мы обсуждаем достаточно простой пример, почему Вы думаете, что другие Заказчика также не уклоняются от конкретного ответа на эти вопросы в реальных проектах?
-
World of Warcraft относится к классу прикладного ПО: к мультимедия - компьютерные игры. Заказчик - одно из подразделений компании Blizzard Entertainment. Скорее всего департамент маркетинга совместно с дирекцией.
Разработчик - тоже один из внутренних департаментов, и тоже скорее всего не один.
Итак, разработка прикладного ПО на основании требований Заказчика. Какие СУЩЕСТВУЮЩИЕ БИЗНЕС-ПРОЦЕССЫ автоматизируются при создании такого ПО?
На мой взгляд, было бы уместнее, если бы вы говорили про проектирование ИС/АС, а не ПО.
-
2 Shur Если я упорно избегаю отвечать на заданные вопросы, может быть это потому, что эти вопросы неверно формулируются? И поэтому так же неверно понимаются? А совсем не из-за вредности.
При описании БП конечно же нужно описывать результаты процесса. Описываются результаты на входе процесса и результаты на выходе. Т.к. результаты выхода одного процесса, являются входами другого/других процессов.
Знаете есть отличная поговорка: Какой вопрос - таков ответ?
Может быть это происходит от неумения спрашивать?
-
Если я упорно избегаю отвечать на заданные вопросы, может быть это потому, что эти вопросы неверно формулируются?
Пожалуйста, не моглу бы Вы сформулировать, что именно неверно в моем вопросе насчет показателей (результатов) для описанных Вами задач?
-
Итак, разработка прикладного ПО на основании требований Заказчика. Какие СУЩЕСТВУЮЩИЕ БИЗНЕС-ПРОЦЕССЫ автоматизируются при создании такого ПО?
На мой взгляд, было бы уместнее, если бы вы говорили про проектирование ИС/АС, а не ПО.
В данном примере идет речь о производстве товара. А в дискуссии ранее, речь шла об распространенной ситуации, когда предприятие приглашает к себе Разработчика для внедрения/разработки требуемого ПО или ИС.
ИМХО сейчас термин ИС равноценен термину АС и термину АИС. Поэтому думаю, что использование терминов ИС и ПО зависят от конкретных частных случаев.
-
В данном примере идет речь о производстве товара. А в дискуссии ранее, речь шла об распространенной ситуации, когда предприятие приглашает к себе Разработчика для внедрения/разработки требуемого ПО или ИС.
И там и там - производство цифрового продукта. Заказчик и разработчик игры тоже могут не в одной организации находиться. Разработчик может заниматься внедрением? Ок, так и в случае MMORPG разработчик постоянно занят доработками и развёртыванием версий ПО (игры).
ИМХО сейчас термин ИС равноценен термину АС и термину АИС. Поэтому думаю, что использование терминов ИС и ПО зависят от конкретных частных случаев.
Различение этих терминов произведено вот здесь (http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=332.0).
-
ИМХО сейчас термин ИС равноценен термину АС и термину АИС. Поэтому думаю, что использование терминов ИС и ПО зависят от конкретных частных случаев.
Думаю нельзя ставить знак равенство между понятиями ИС и АС(АИС), тем более как мне, кажется, АС и АИС у Вас в первую очередь связывается с ПО. Но ИС - это далеко не только ПО, ПО лишь часть ИС. Автоматизации БП может происходить и без использования ПО. Возьмите хотя бы такой процесс как оформление покупки.
Так или иначе, думаю не нужно спорить по поводу классификации и понятий. Либо не в этом разделе:-)
-
Я имел в виду этот вопрос:
Необходимость описания БП никто из участников данного обсуждения не оспаривает. Утверждается, что эти БП выполняются с определенной целью, некоторое приближение к которой (по идее) реализуется результатом выполнения БП.
Необходимость включения ожидаемых результатов в описание БП Вы не оспариваете?
Перечитав все Ваши вопросы, попробую ответить в одном посте.
Главной целью любого бизнеса является максимизация получаемой прибыли. Вряд ли когда было по другому.
Выбор показателей для оценки бизнеса следующий. Во первых, существует набор типовых показателей стандартных для любого бизнеса (рентабельность, оборачиваемость, ликвидность и структура капитала). Во вторых, есть показатели характерные для конкретных типов Бизнеса (не могу вспомнить ???)
Вопрос по поводу оценки эффективности внедрения разработанного ПО тоже очень интересен. Насколько знаю, напрямую оценить экономический эффект возможно лишь в частных случаях. В общем случае его рассчитать не возможно (компания имеет несколько бизнес направлений например, а ИС/ПО внедрялось только в одной части на каком то из направлений). В таком случае можно косвенно судить об эффективности. Тут больше зависит от собственника Бизнеса, от его видения ситуации и способностей и навыков. И думаю, что его оценка скорее всего будет качественная.
Есть Цель бизнеса которую ставит собственник на этапе создания бизнеса.(Извиняюсь за тавтологию, но без нее никак). Из Целей Бизнеса в соответствии со стартовыми условиями организовываются БИЗНЕС-ПРОЦЕССЫ. Из этих БИЗНЕС-ПРОЦЕССОВ вытекают цели и задачи простых работников.
Как показывает Жизнь, сколько бы ни пытались найти "волшебные таблЭтки" в виде формализованных описательных или расчетных моделей, все никак не могут найти. Лично я сторонник подхода, когда ставка делается на людей, а не формальные методы. Хотя конечно от них никуда. Но как говорил товарищ Сталин: Кадры решают Все! И я с ним полностью согласен.
З.Ы. Спасибо за то, что натолкнули на некоторые собственные пробелы в знаниях и интересную пищу для развития и размышлений.
-
2 Shur
Люди тысячи строят корабли, более сотни лет делают сталь и машины, десятки лет самолеты и компьютеры. Все эти практики связаны с сознательной деятельностью человека...Но подвергать сомнению возможность целенаправленной деятельности несколько странно.
А я и не подвергаю сомнению возможность целенаправленной деятельности человека. Я сомневаюсь лишь в том, что человек ВСЕГДА действует осознанно и целенаправленно. Читайте внимательнее.
А откуда вообще берется априори принимаемое утверждение, что человек обязательно действует целенаправленно?
Теория деятельности, элементы которой упоминались выше, говорит о том, что человек МОЖЕТ действовать целенаправленно (в отличие от всяких букашек и зверушек). Но из этого не следует обратное. Нельзя утверждать, что ВСЁ поведение человека целенаправленно. Ну сами подумайте, вот я сейчас чихнул - это было целенаправленно или нет?
-
2 boatman
Выдирание предложений из контекста приводит к их некорректному пониманию.
Как показывает практика, зачастую такие решения принимаются: - Шеф сказал так, значит так. И Баста !
А если так невозможно, слишком дорого и т.д.?
Например диалог Заказчика и Исполнителя
З: Я хочу такую всю из себя мегасистему, сколько она стоит?
И: Нет проблем, она стоит $ХХ'000'000 и будет внедряться 5 лет. При этом вы должны (следует километровый перечень требований к обеспечению внедрения)
З: Падает в обморок.
И: Бежит за стаканом воды.
З: Приходит в себя и слабым голосом говорит - но весь мой бизнес столько и близко не стоит.
И: Давайте посмотрим, для решения каких задач она Вам нужна, возможно мы найдем более дешевое решение.
Далее следует конструктивный диалог...
Я ответил на вопрос об окончательном принятии решения по поводу выбора того или иного программного продукта.
Вот и давайте разберемся, на основании чего конструируются БП?
На основе Бизнес-проекта или "голой" бизнес-идеи.
Мой любимый ответ на мой любимый вопрос. Загвоздка, только, в том, что непонятен критерий максимизации: как считаем максимум прибыли, как пиковую, как среднюю за период, за какой период, а что, если бизнес за всю жизнь несколько раз меняет владельца? Как, вообще считать прибыль: по бухгалтерскому балансу или с учетом реальной капитализации компании? А как рассчитать реальную капитализацию? А как быть с заявленной миссией организации? А если организация некоммерческая: государственный институт, благотворительный фонд, и т.п.?
Во первых, Вы невнимательно прочитали предыдущие сообщения в которых было указано, что существуют "стандартные" (наиболее распространенные) финансовые показатели деятельности предприятия, такие как коэффициенты ликвидности, показатели структуры капитала, коэффициенты рентабельности, коэффициенты деловой активности. На основе расчета которых можно судить о степени успешности бизнеса. И конечно же безусловно, что данный перечень является далеко не полным и не претендует на обязательность. Т.к. набор показателей варьируется в зависимости от вида бизнеса и конкретных условий.
Во вторых, очень логично считать максимум прибыли за финансовый год, не так ли? Можно конечно его высчитывать за каждую неделю, а можно и по дням ;D. И конечно же, весьма логично периодичность расчета финансовых показателей увязывать с временными характеристиками своего бизнеса.
В третьих, если организация некоммерческая - вопрос отпадает сам собой. ;)
Эти показатели интересуют, в первую очередь, инвесторов и налоговую инспекцию. Но это не единственные заинтересованные стороны, а значит, на цели будет влиять и что-то еще.
Непонятный вопрос, уточните какие именно цели Вы имеете в виду? О каких заинтересованных сторонах идет речь?
-
Теория деятельности, элементы которой упоминались выше, говорит о том, что человек МОЖЕТ действовать целенаправленно (в отличие от всяких букашек и зверушек). Но из этого не следует обратное. Нельзя утверждать, что ВСЁ поведение человека целенаправленно. Ну сами подумайте, вот я сейчас чихнул - это было целенаправленно или нет?
Ваш последний вопрос (о том, как установить целенаправленность действия) действительно интересен и важен. В практике автоматизации деятельности, правда, вопрос о целенаправленности физиологических отправлений Заказчика (и Исполнителя), как правило, менее актуален, чем оценка целенаправленности его действий, которые сам субъект этих действий квалифицирует как осознанные и предлагает так же квалифицировать их другим.
Как установить, что то, что Заказчик системы декларирует в качестве цели внедрения системы, которую он заказывает Исполнителю, соответствует истине?
2 Shur
А я и не подвергаю сомнению возможность целенаправленной деятельности человека. Я сомневаюсь лишь в том, что человек ВСЕГДА действует осознанно и целенаправленно. Читайте внимательнее.
В предыдущем цитируемом фрагменте Вы затронули проблему, которая представляется действительно очень важной, распознавания целенправленной деятельности от действий, которые целенавправленными действиями не являются.
Не менее важным представляется понять, как можно осуществлять целенаправленную деятельность при (всегда?) постоянно меняющихся целях, о чем Вы писали в посте, которому был адресован цитированный Вами мой ответ. Или Вы всё-таки полагаете, что такие изменения целей не всегда могут быть значимы? Пожалуйста, не могли бы Вы уточнить?
-
Согласен, рамки важны. Изначально и презентация и статья адресовалась
- начинающему разработчику
- начинающему аналитику
- начинающему руководителю проектов
И я думаю, что рамки установим такими: культура деятельности, связанной с автоматизацией деятельности (каламбур, однако :) ).
Я имел в виду несколько рамок, применительно к перечисленным Вами специализациям можно предложенные мной рамки переименовать как
«рамка контекста деятельности разработчика» (я её назвал «рамка автоматизация деятельности»)
«рамка деятельности аналитика» (рамка бизнеса)
«рамка деятельности по управлению проектами» - рамка деятельности, "перпендикулярная" деятельности в предыдущих контекстах.
Принципиально важно, что рамок несколько. Для каждого тезиса хорошо бы сразу говорить, какому контексту он соответствует, примерно так, как Вы сделали в следующем цитируемом фрагменте. Это позволяет рассматривать проблему как взаимодействие заинтересованных лиц, причем эти лица могут смотреть на проблему каждый из своего конкретном контекста.
К тому же каждая специализация часто вкладывает свой смысл в термины и понятия.
Не совсем так. Типичны такие проблемы, связанные с автоматизацией деятельности:
- отсутствие критического взгляда молодых разработчиков на ставящиеся задачи и отсутствие критического взгляда на целесообразность собственных действий (это культура разработки)
Првильно ли я понял - это всё в рамке разработки?
- отсутствие инструмента верификации и упорядочивания материалов обследования заказчика (это культура системного и бизнес-анализа)
Стоит ли относить это к бизнес-анализу (даже в плане «только» культуры бизнес-анализа)? Ведь речь идет о контроле результатов работы бизнес-аналитика. Если приобретение культуры бизнес-анализа предполагает, что данное лицо фактически должно уметь проводить бизнес-анализ, то это обесценит разделение труда между бизнес-анализом и разработкой.
Может быть, как раз, ценным было бы вооружить разработчика специфическими представлениями, общими для разработчика и бизнес-аналитика (так сказать, пересечение множеств необходимых знаний разработки и бизнес анализа)? В частности, например, Ваше утверждение об избегании колец в иерархии целей, если его удастся развернуто обосновать, могло бы ИМХО претендовать на инструмент из пересечения компетенций бизнес-аналитика и разработчика
- отсутствие критического взгляда заказчика на собственные цели и цели, которые он ставит перед проектом автоматизации (это культура управления)
Это также всё предполагается, что можно раскрыть, детализировать в рамке разработки? Или в рамке управления проектами?
И все эти проблемы - это во-первых отсутствие культуры целеполагания, во-вторых - отсутствие навыков целеполагания. Именно в таком ракурсе хотелось бы излагать материал.
Навыки невозможно выработать без практики. Поскольку Вы предполагает воздействовать на потенциальную аудиторию словом, наверное, имеет смысл ограничиться формализацией знаний, которые представляют именно теоретическую ценность (но для практического применения)?
-
Сергей, коллеги.
Я вообще дипломированный научный сотрудник:-) Немного понимаю в научных изысканиях.
С чего они часто начинаются? Да точно также как и многие ИТ проекты. С проблемы. Проблема может быть разная: неудовлетворенность объяснений наблюдаемых явлений, нестыковка теоретических построения и экспериментальных данных, ошибки в интерпретации результатов, ошибки в проведени наблюдений (читай экспериментов), отсутствие вообще какой-то базы.
Часто исследование начинается с наблюдения. Все античные философы выстраивали свои суждения на наблюдении. Наблюдение могучий фактор изыскания. Наблюдая мы сравниваем, сравнивая делаем выводы, делая выводы нахом закономерности, находя закономерности ищем причины их возникновения, понимая причины строим теорию, получив теорию имеем предсказательный инструмент, сделав прогнозы проверяем их через наблюдения, круг замкнулся: в данном месте теория либо принимается либо отвергается.
Поскольку в нашем случае мы (вернее Сергей) проводит как раз такое научное изыскания, причиной которого явилась неудовлетворенность, то может начать с эмпирики. Т.е. собрать наблюдения, привести примеры, попытаться увидеть закономерности, а тогда возможно выкристаллизуется решение.
Чем страдает на мой взгляд статья - отсутствие реальных примеров и их констурктивный анализ. Потому рассуждения кажутся немного оторванными.
Какие примеры тут привести - сказать сложно. Ну может вот такой. года 4 назад, ко мне начинающему вообщем только преподавать информационные науки, пришли два человека. Как оказалось это были менеджеры одного из предприятий. Они обратились ко мне с вопросом переконфигурировать для них конфигурацию Торговля и склад. По их мнению это можно было сделать ну не больше, чем за месяц. Я тогда абсолютно ничего не понимал о проектировании, хотя опыт разработки имел. Я спросил для чего им это вообще нужно и почему их не устраивает исходная конфигурации. В ходе беседы интуитивно видно я вытянул из них кучу информации и в конце концов мы докопались до сути задачи. Мне удалось показать им, что такая задача не может быть достигнута за месяц простым переконфигурированием базовой конфигурацией, а есть серьезный ИТ-проект с серьезным бюджетом, с солидными человека-часами. Мне повезло переправить их к нужной конторе. Контора тогда только начинала делать свой бизнес, и это проект оказался самым крупным и серьезным за их тогдашнюю историю. Как я знаю проект развивался больше года, если не два. От этой истории от компании, которая выполняла проект я получил премию в виде политра пива, а от компании для которой проект делался ящик пива и бутылку коньяка.
Достигли ли те люди своей цели - безусловно! Достгал ли ИТ-компания цели? не могу знать, на тот момент целей компани вообще не существовала. Какую цель я преследовал в этом деле? Никакую - ко мне обратились, я затратил около 5 часов на беседу и получил через примерно год компенсацию в виде пива :-).
Другой пример. Год назад ко мне пришли два человека опять же и просили разработать для них систему для кадрового агентства. Цели для чего это нужно заказчик не сформулировал - вернее он был удивлен, а зачем ее формулировать и козе понятно, что все сейчас все переводят на компьютер. Поговорив с ними полчаса я стал активно их отговаривать (при этом как вы понимаете я активно отказывался от заработка :), сказал, что я думаю, что они не очень представляют себе свои потребности в системе, неясен процесс учета клиентов и выдачи вакансий, неизвестна частота обращений и трудоемкость работ. Я им предложил простое Excel решение. НО народ моим доводам не внял. В результате я стал делать проект, причем они просили сделать хотя бы первую рабочую версию через 2 недели, т.к. они начинают работать. Через 3 недели после нашей встречи, мне позвонили и отказались от почти готового проекта (проект был сделан процентов на 90), при этом они заплатили неустойку в размере половина стоимости, не взяли даже полуготовый проект. А чрез месяцев 4 вообще прекратили существовать. Когда они обратились ко мне, у меня вообще были сомнения в жизнеспособности их бизнеса, я даже полагал, что это только прикрытие - правда а зачем народ тратился на ИС?
-
2 Boatman
На основе Бизнес-проекта или "голой" бизнес-идеи.
А бизнес-проект не включает в себя постановку цели?
Безусловно бизнес-проект включает в себя постановку цели. В этом никто не сомневается ))).
Во первых, Вы невнимательно прочитали предыдущие сообщения в которых было указано, что существуют "стандартные" (наиболее распространенные) финансовые показатели деятельности предприятия, такие как коэффициенты ликвидности, показатели структуры капитала, коэффициенты рентабельности, коэффициенты деловой активности. На основе расчета которых можно судить о степени успешности бизнеса.
Вот я и добавляю к приведенному факту только один момент: эти показатели служат для информирования инвесторов о степени успешности бизнеса и отвечают на вопросы инвесторов. А точка зрения инвестора - это всего лишь одна из точек зрения на бизнес.
Во вторых, очень логично считать максимум прибыли за финансовый год, не так ли?
Давайте посмотрим. В этом финансовом году выжимаем максимум прибыли, а в конце года еще и продаем все активы (ну, чтобы прибыль увеличить еще больше). Годится?
Или так: в этом году получаем сверхприбыль, но гробим репутацию безвозвратно и в конце года закрываем бизнес.
Или еще вот так вот: отказываемся инвестировать деньги в маркетинг и развитие продуктов, так как прибыль от этих инвестиций ожидается только в следующем финансовом году, а в этом придется выйти с минимально допустимой нормой прибыли.
Вот я и спрашиваю, Вас максимум за который год интересует: за первый, за последний, усредненный по годам. А может, Вас интересует капитализация компании для продажи, а прибыль вообще не нужна?
Рекомендую ознакомиться с литературой по финансовому анализу, чтобы мы не обсуждали и не спорили об очевидных вещах. В сети полно информации на данную тему.
Хм ... интересно, а каким образом в Вашей компании оценивают эффективность бизнеса? Может, применяются новейшие "ноу-хау" типа оценки бизнеса по количеству нанятых работников, или длине ног секретарши директора, или цвету обоев в офисе, или количеству машин на автостоянке? ;D Почему приходится объяснять совершенно очевидные вещи? ??? И даже их доказывать? ???
К чему приведены частные примеры содержания "а вдруг, а кабы" ?
Главная цель бизнеса - получение максимальной прибыли. Так было всегда и так есть. Соответственно для измерения успешности достижения цели используют финансовые показатели. Так как их существует большое количество ( более 100), то с целью снижения трудоемкости оценки и легкости восприятия и анализа используют более-менее устоявшийся набор финансовых показателей.
Хотите Вы того или нет, нравится Вам или нет, но во всем мире предприятия для оценки своего бизнеса используют финансовые показатели, а не что то другое. И конечно же при необходимости детального анализа используют любые другие требуемые показатели.
Непонятный вопрос, уточните какие именно цели Вы имеете в виду? О каких заинтересованных сторонах идет речь?
Цели всех участников процесса. Для примера можно привести такое деление: рядовые сотрудники организации, рядовые менеджеры, менеджеры среднего звена, топ-менеджеры, инвесторы, клиенты организации, поставщики организации, налоговые органы, органы государственного регулирования, правозащитные организации, пресса, конкуренты... Это не все, но достаточно. Все они имеют свои требования и ожидания, связанные с конкретной организацией. По этому я и говорю, что те показатели, что Вы приводите касаются только двух-трех заинтересованных сторон из пары десятков. Если попытаться перечислить все показатели и как-то увязать их получится система сбалансированных показателей, которая есть отражение целей и интересов разных субъектов на каждом уровне иерархии и не может быть стандартной никогда - она внедряется под конкретный бизнес и подлежит регулярному пересмотру.
Вы говорите о многопараметрической математической модели. В которой учитываются цели, интересы, параметры, требования и ожидания. Мне не хочется снова объяснять "простые истины". Зачем Вам такая модель? Насколько она будет адекватна? Какова ее применимость? Каковы рамки ее применимости? Каковы ее ограничения? Рекомендую ознакомится с литературой по математическому моделированию, хотя бы для того, чтобы понимать сложности описания и практического применения таких мат.моделей.
З.Ы. Если Вам не ясны какие то вопросы, просто попросите других их объяснить, или сами поищите ответ. Зачем утверждать абсурдные вещи с видом истины в последней инстанции? Лично я за конструктивную дискуссию (уверен, что не только я), поэтому давайте ее продолжать, не скатываясь к спорам об очевидных вещах.
-
2 Boatman
Вы уходите от ответа. Я продолжаю стоять на том, что максимизация прибыли – не раскрываемый критерий в общем случае, а значит, на роль универсальной цели не годится.
Давайте уточним. Насколько я понимаю Вы в корне несогласны с формулировокой главной цели бизнеса: "Цель любого бизнеса в получении максимальной прибыли" ? Обоснуйте свою точку зрения. Предложите "правильную" на Ваш взгляд главную цель бизнеса.
Хорошо, если Вы считаете, что дискуссия об универсальной цели зашла в тупик, можно ее прекратить. Я остаюсь при своем мнении, что максимизация прибыли не является ни формализуемым, ни единственным критерием построения бизнеса. Вы считаете наоборот. На этом можно остаться при своих мнениях.
А где аргументы и доводы? В разумном споре должны приводится аргументы в поддержку декларируемых тезисов. Будьте добры приведите свои аргументы в пользу защиты своей точки зрения. Голые утверждения - "это так, а вот это так", сами по себе ничего значат. Необходимы обоснования и аргументация утверждаемых постулатов - " это так, потому что 1. ... 2. ... 3. ..., а это вот так, потому что 1. ... 2. ... 3. ..."
Если Вы утверждаете, что главная цель бизнеса должна быть формализуемой, тогда поясните:
Что вы понимаете под формализацией главной цели бизнеса?
Какая методология применяется для этого ?
Приведите конкретные примеры формализованных главных целей бизнеса.
Следуя Вашим утверждениям, мы можем сказать, что все существующие предприниматели и бизнесмены поставили себе "неправильные" цели? Получается, что эти "практики" заблуждается в своих целях?
В большинстве бизнес-планов вообще отсутствует формализованное описание главной цели бизнеса, и это не мешает им успешно реализовываться. С другой стороны, есть примеры бизнес-планов написанных согласно всем " правилам", но тем не менее так и оставшимся только бизнес-планами.
-
В качестве справки.
Максимизация прибыли - типичная оптимизационная задача. В теории оптимизации выделяют два типа задач:
безусловные - когда решение ищется на всем пространстве состояний целевой функции - данная задача есть истинно оптимальная, ибо она позволяет найти глобальный минимум или максимум. Однако такие задачи малореальны, тем более в столь сложной области как человеческие отношения, а бизнес и есть часть такого отношения.
условные - или задачи с ограничениями. В этом случа оптимальным будет решения при заданных ограничениях.
Удовлетворительное решение задачи оптимизации находят не для слишком большого количества критериев, потому многокритериальную целевую функцию стараются свести к однокритериальной. Методы могут быть самые разные: аддитивная, мултипликативная свертка и т.п.
Задача оптимизации - есть частный случай общей задачи принятия решения, которая в свою очередь подразделяется на три группы:
задачи оптимизации (множество альтернатив известно, принцип выбора (функция выбора) известна)
задачи выбора (множество альтернатив однозначно известно, принцип выбора не формализован)
ну и собственно общая задача принятия решения (множество альтернатив может дополняться в ходе решения, принцип выбора не формализован)
Т.е. последние задачи и есть фактически наши с вами задачи.
Далее насчет целеполагания. А так ли важно для ИТ-исполнителя знать досконально все цели? Разве принцип Парето отменяли?
Я думаю Сергей это прекрасно понимает. Осмелюсь предположить, что поиск истинных причин инициализации проекта важны для отдаленных последствий. С другой стороны и заказчик и исполнитель - партнеры в бизнесе, или скорее игроки в бизнесе. Если говорить грубо - заказчик желает получить нечто, что решает его проблемы, при этом он может полагать, что знает как их решать - например через внедрение некой ИС, которую он говтов заказать у исполнителя; исполнитель же желает получить а) доход; б) репутацию; с) anything else. И я думаю, что только репутация, т.е. совесть, сдерживает исполнителя от впаривания чего-то. С другой стороны, исполнитель хочет иметь гарантии в будущем, что его не кинут, потому ему нужны первопричины желания проекта со стороны заказчика. Может даже заказчик не кинет, но из-за неверного учета целей и задач самого заказчика - проект может обернуться проблемой в будущем. Обратите внимание не сразу - а именно в будущем.
Мне кажется такая ситуация уже маловероятна. Все-таки пресса работает, ИТ как наука растет, проекты обкатываются и стандартизируются.
Вопрос можно? Сергей, скажи, пожалуйста, а зачем важно знать истинную цель заказчика, или понимать, что цель заказчика неверна?
-
Разделение специализаций как раз и происходит при отделении специфических целей, требующих применения специфических средств.
Еще раз: целеполагание - это общее для всех, значит, конкретные рамки остаются за рамками рассмотрения (опять каламбур :) ).
Формулирование "специфических целей" уже не входит в целеполагание (раз целеполгание - это только общее, неспецифическое для всех)?
-
Следуя Вашим утверждениям, мы можем сказать, что все существующие предприниматели и бизнесмены поставили себе "неправильные" цели? Получается, что эти "практики" заблуждается в своих целях?
А кто сказал, что они ставили целью именно максимизацю прибыли?
Вот примеры постановки целей компании в качестве моих аргументов
- http://www.sermet.ru/index.php?idpage=128
- http://www.sl-cement.ru/rus/about_plant/mission/
- http://www.felix.ru/flx_mission
Обратите внимание на то, что в заявленных целях никогда не делается ставка на один единственный показатель. Финансовые показатели стоят в одном ряду с многими другими. По сути цели компании формируются для удовлетворения интересов всех заинтересованных сторон. В простейшем случае хотя бы "максимизация прибыли при удовлетворении спроса клиента", если учитывать только две стороны: клиент и компания. Но даже в такой упрощенной модели при стратегическом планировании учитываются все аспекты деятельности компании: как сегодняшние достижения, так и развитие, создающее основу будущих достижений. Следовательно ставятся цели по получению достаточной для выживания прибыли и развитию для получения будущей прибыли.
Если сказать коротко, то прибыль - это пища компании, которая обеспечивает ей выживание и может создать жировой запас на случай тяжелых испытаний и не более того. Но сказать, что цель жизни компании - максимизация прибыли, все равно, что сказать, что цель жизни человека - максимизация съеденного и отложенного в жировом слое. Во всяком случае - это цель не всех людей. Так же, как не все компании имеют такие примитивные цели, как максимизация прибыли.
Для того, чтобы привести еще аргументы по этому вопросу и в ответ на Выши отсылки к финансовому анализу позволю себе отослать Вас к литературе по стратегическому управлению. Так же можно посмотреть методики сбалансированных показателей.
По сути цели компании формируются для удовлетворения интересов всех заинтересованных сторон.
С данным утверждением не согласен категорически. Это все к тому же вопросу о теории и практики. В Ваших словах звучит теория, не основанная на практике. Интересно, Вы предлагаете согласовывать интересы компании со всеми сотрудниками? вахтерами? Налоговой? Еще кем то? Интересно ...
Бизнес создается владельцем для удовлетворения своих собственных целей и интересов. Для достижения этих целей нанимаеется персонал, который работает по рабочему договору в соответствии с трудовым кодексом РФ. По Вашему владелец бизнеса должен согласовывать свои цели и цели своего бизнеса с наемным персоналом? Мда.... Ноу коментс...
Вы верно заметили, что для стратегического планирования необходимо учитывать большое количество показателей компании. НО!
ССП является лишь одним из многих инструментов для стратегического планирования. Если внимательно посмотреть то, этот инструмент применяется большими по масштабам компаниями, т.к. другими средствами и методами это не возможно сделать, в силу размеров компании, большого количества направлений деятельности, разнородной структуры и др.
В Ваших утверждениях совсем нет разницы между такими терминами как показатели для стратегического планирования и основными финансовыми показателями. Мда . . .
Аналогия максимизации прибыли с жиром - вообще "мимо кассы" ???
З.Ы. Оффтопик удален модератором. Участники форума не нуждаются в оценке своих действийв данной теме
З.Ы.Ы. Любые сходства с настоящими Заказчиками и Разработчиками - вымышленные ;D
-
Вообще, я бы не стал дискутировать вокруг понятия максимизация прибыли. Почему, да потому,ч то это не аналог увеличения прибыли. Я могу максимизировать прибыль, но она будет скажем меньше чем в прошлом году. Какой тут жир...
Насчет считать ли максимизацию прибыли основной задачей бизнеса - мне судить трудно. Тут флаг в руки представителям с экономическим образованием. Но что-то помнится из курса К.Макса Капитал, что основной целью капитала - создание прибавочной стоимости - наверное это не прибыль в полном ее понимании.
Далее подтверждает мысль о деньгах и история развития капитала и крупных компаний. В журнале "Бизнес-журнал" была статья о геномодифицированной сое и других растениях. Цель была понятна - приспособить эту самую сою к действию пестицида определенного. При этом представитель компании (не помню, на М точно) высказал, что наша цель зарабатывать как можно больше денег любыми возможными путями, а цель общества контролировать процесс зарабатывания и создания тех ограничений, которые полезны обществу. Т.е. прослеживается мысль, что у капитала нет совести, у капитала есть одна функция - умножаться, любыми способами и возможностями. Это как мы видим очень схоже с понятием выживаемости вида.
С другой стороны в том же журнале я читал и другие статьи, в которых говорится о других приоритетах, например увеличения капитализации. Может это и связано с отложенной прибылью...
Инвестиции - ведь это тоже путь отдаленного получения прибыли...
-
Мне, кажется, дискуссию о целях бизнеса имеет смысл перенести в самостоятельную тему, скажем Главная цель бизнеса. И уж там приводить доводы и контраргументы. Иначе эта дискуссия камуфлирует основную тему дискуссии здесь, что на мой взгляд не совсем хорошо.
-
Добавлена заметка с отчетом с открытого семинара московского чаптера PMI, а так же с дополнительно аргументацией, зечем нам целеполагание, родившейся на основе общения с участниками семинара.
- менеджмент вынужден искать сверхприбыль для владельца, но он обязательно заинтересован в уменьшении ответственности перед владельцем, перенося риски на работников (мотивация, влекущая экономию на зарплате)...;
Казалось бы, при чём здесь Agile? ;)
-
Сергей, в качестве рекомендации. Мне, кажется, статья по целеполаганию страдает проблемой цитируемости и указанием авторитетных источников. Создается такое впечатление, что проблемой целеполагания никто никогда не занимался и никаких серьезных выводов и результатов по этому вопросу не получено.
Иногда это хорошо, но в данном контексте выглядит немного странно. Поскольку все-таки это научное исследование, то оно должно базироваться и на цитируемой литературе. Например утверждая, что целеполаганию не уделяется внимание, неплохо бы привести ссылки .
Да цитируется толковый словарь и энциклопедия, но и все...
-
2greesha
И?
С точки зрения "обычного" менеджера, "самоуправляемая команда" несёт полную ответственность за разработку продукта: "Я даю вам полную свободу и умываю руки".
Хорошо, если над командой нет такого менеджера. А если есть? Интересно, кстати, было бы узнать, что думает по этому поводу команда, которая представляла пример внедрения SCRUM на прошедшем в прошлый четверг семинаре AgileRussia.
-
С точки зрения "обычного" менеджера, "самоуправляемая команда" несёт полную ответственность за разработку продукта: "Я даю вам полную свободу и умываю руки".
Это какой-то дезинформированный менеджер. В Agile команда несёт ответственность только за техническую часть. Фичи и целеполагание остаются на менеджере продукта.
Хорошо, если над командой нет такого менеджера. А если есть? Интересно, кстати, было бы узнать, что думает по этому поводу команда, которая представляла пример внедрения SCRUM на прошедшем в прошлый четверг семинаре AgileRussia.
Ни Эда, ни Сергея на семинаре не было. Спросите у команды. Она про целеполагание не читает, я уверен )
-
80 просмотров и ни одного критического замечания. 1 отзыв в стиле "ЙОУ". кто знает, что это может означать?
Сережа, я честно не осили еще статью. Просто есть другие приоритеты. Почитаю выскажусь :-)
-
Одни из моих коллег точно знают, как ставить цели ИТ проекта, другие точно знают, что это их не касается. Первые абсолютно правы - вторые счастливы.
То что вторые счастливы - можно понять, но почему первые правы, да еще абсолютно?
Неплохо бы прикрепить возможность комментирования прямо в статье
-
80 просмотров и ни одного критического замечания. 1 отзыв в стиле "ЙОУ". кто знает, что это может означать?
80 просмотров - это потому, что я на тебя вчера ссылку поставил )
а отзывов нет, т.к. неудобно отзываться
-
Сергей, я бы так сказал - для меня пока что самой важной вещью из тобой написанного стало то, что не следует бизнес-цели тащить в IT-проект.
А выводы, почему не делается целеполагание, я у себя расписал (http://beskov.livejournal.com/39865.html).
-
Хотел сразу отметить некоторый момент. Часто используется понятие модель требований. Это понятие довольно часто встречается и в иностранной, и отечественно литературе. Так же прослеживается и в case-инструментарии.
В очень интересной книге по требованиям: Элизабет Халл, Кен Джексон, Джереми Дик. "Разработка и управление требованиями"
<< Некоторые употребляют термин «моделирование требований». Это термин является неверным по сути. Моделируется реализация системы, а не требования к ней. Моделирование поддерживает наиболее творческий процесс - разработку реализации системы, выработку конкретных системных решений. Моделирование помогает инженеру уточнять и детализировать реализацию системы путем разбиения ее на компоненты при движении вниз от одного уровня требовании к другому. Требования это полный «снимок» того, что именно требуется от системы на каждом уровне. При этом детализация «снимка» увеличивается при движении вниз от уровня к уровню.>>
-
На происхождение цели ИТ проекта можно предложить как минимум два взаимнодополняющих взгляда:
- системное происхождение цели проекта - разрабатываемая система рассматривается, как часть надсистемы, обеспечиващая выполнение функций надсистемы;
...
Первый случай более упорядочен и предполагает точное знание будущего окружения ИТ системы. Обычно первый подход годится для разработки систем управления оборудованием, серверного ПО, конверторов, программ индивидуального пользования. В этом случае на первый план выходит техническое окружение системы и непосредственные требования к функционированию (программные интерфейсы, форматы, требования к быстродействию, надежности и т.п.)
Не могу согласиться с примером. В данном случае речь идет не о системе и надсистеме, а об объекте управления и системе управления. Последняя должна удовлетворять принципу Эшби. это очевидно, но система управления не является надсистемой или суперсистемой (поскольку именно такой смысл скрывается под "над" в описании автора)
Второй случай исходно несет гораздо меньше определенности, так как технология использования разрабатываемой ИТ системы неизвестна. При разработке системы предстоит разработать как организационный регламент, так и средства, которые его поддерживают. К таким системам относится большинство ИТ систем для групповой работы: учетные, документооборотные, CRM, PLM и т.д.
Не понятна логика выводов. Любой проект, а тем более инновационный (а ИТ проект как мне думается и относится к таковым, то есть венчурным связанным с риском), подразумевает вопросы организации, выбора средств и т.п.
Мне не ясно из статьи в чем разница системного происхождения цели и проблемного, и почему они противопоставляются?
если кроме создания ПО не планировалось больше ничего - это принципиальная ошибка создателей сайта
Это камень в известный мне огород? ;)
Для того, чтобы не нести бремя этого риска самостоятельно любой исполнитель, чем бы он не зарабатывал себе на жизнь, ДОЛЖЕН УМЕТЬ ФОРМАЛИЗОВЫВАТЬ И ФИКСИРОВАТЬ НА БУМАГЕ ЦЕЛИ, относящиеся к его обласи компетенции, ВЫБИВАТЬ ПОДПИСЬ ЗАКАЗЧИКА под этими целями и ПРИТЯГИВАТЬ ЗА ЯЗЫК в случае попытки нагрузить избыточной ответственностью за чужие просчеты.
Может легче государство поменять, а лучше Галактику :)
Что удручает, это отсутствие вообще ссылок на мировой опыт в виде ссылок на книги, статьи, тезися докладов и т.п. Вернее оно присутствует, но пренебрегается явным цитированием и указанием первоисточников..
Мне кажется, что в начале статьи нужно более четко сказать (ибо это ощущается при прочтении статьи) что фаза проектирования - есть нечто иное как фаза целеполагания. Т.е. постановка задачи, возникновение проблемы, поиск их причины, выбор цели системы, цели проекта и т.п., определение требования, анализ требования, реализация требования в виде проектных воплощений - все это целеполагание! Конструирование системы - есть целереализация. Наконец рефлексия - оценка достижения целей, корректирование и переконструирование если необходимо. Очевидно, учитывая современный опыт разработки ПО и системы активно использующих ПО, жеского разделения нет - есть сплав, фьюжен называемым agile. Но этот подход совершенно естественен для новационных венчурных проектов, каковыми ИТ-проекты по сути и являются.
Т.е. надо сразу высказаться определенно и точно - целеполагание - это не фиксированный шаг проекта, - это тело проекта, его бог и дьявол...
В общем статья создает двойственное впечатление. Начало както не гармонизируется с концом. Начали с понятия цели, кончили концепцией.
Мне кажется, статья должна быть образцом целепостановки и целедостижения. Т.е. нужно поставить цели статьи - чтобы они были понятны и соответстовали СМАРТ, а также были показаны результаты - достигли ли мы цели или нет, в чем возникло противоречие в ходе рассуждения. Ведь необязательно результат должен быть положительным - негативный дает постановку проблемы и потребность понимания ее причин
-
Спасибо Сергею за статью. Почитал и обсуждение в блоге Дениса.
Хочу обратить внимание на то, что при обсуждении проблемы целеполагания смешиваются два разных явления. Одним и тем же словом называются (или имеются ввиду) разные вещи. С одной стороны, цель - это то, к чему я стремлюсь, моя потребность, желаемый результат моей деятельности. Я сам управляю своим собственным поведением. Достижение цели зависит не только от интеллектуальной продуманности, но и от внутренней готовности и концентрации внимания. Значительные усилия требуются на борьбу со всякими отвлекающими, мешающими факторами. Я занят делом, решаю важную проблему, но каждые пять минут ко мне кто-нибудь подходит с вопросом, просьбой, звонит телефон и т.д. В реальной жизни у человека есть множество целей (и все важные), между которыми нужно переключаться, все успевать, отбрасывать лишнее, выбирать нужное и правильное ...
С другой стороны, слову цель придается и другой смысл. Подошел ко мне начальник. Говорит, ставлю тебе цель, сделать то-то и то-то. Конечно я тут же побежал все это делать, высунув язык :). Становится ли чей-то приказ, требование, чье-то желание моей целью автоматически? Думаю нет.
Далее. Стремясь грамотно и эффективно организовать свою деятельность, человек может использовать разные полезные инструменты и методики. Можно, например, сформулировать цели на бумаге, по пунктам, повесить бумагу над рабочим столом. Это мой рабочий инструмент. Если кто-нибудь завтра повесит над моим столом другую бумагу, должен ли я выполнять то, что там будет написано?
При обсуждении темы смешиваются две вещи:
- эффективное решение проблемы
- успешное взаимодействие с людьми
Это два разных явления. Связь между ними есть. Но, на мой взгляд не возможно решить одно за счет другого. И в частности, нельзя сделать клиента довольным, оставить о себе хорошее впечатление только путем достижения некоей (очень правильной) цели.
Если человечество для регулирования целенаправленной деятельности много лет успешно применяет SMART :). То для регулирования отношений тоже очень давно применяются другие подходы. Культура, ритуалы, нормы, правила, законы и т.д. служат механизмами устранения и регулирования конфликтов между людьми. Стандарт - вот это слово. Часто не понимаем, зачем он нужен. Думаем, что стандарт помогает сделать качественный продукт. Ну в какой-то мере это и так. Впрочем изготовить действительно отличный и качественный продукт можно и без соблюдения стандартов. Выполнение процедур, соблюдение стандартов нужно именно для урегулирования взаимоотношений с заинтересованными сторонами. Разговор о стандартах, понятно, отдельная история. Отрасль развивается быстро. Стандарты не успевают стареть ...
Таким образом, IMHO, истинные цели проекта и другие технические характеристики не могут играть самостоятельную роль при урегулировании отношений с заказчиком. Отношения с заказчиком должны поддерживаться стандартными процедурами, в которых будут опосредованно представлены и цели, и требования, и др. технические условия.
-
Взгляд, классический для системного анализа: существует наша система, которая является частью надсистемы. Все что взаимодействует с нашей системой - это части надсистемы, связанные с нашей системой. Будет ли это объект управления и система управления или что-то еще, это уже более конкретные вопросы.
Хорошо пусть будет так. В данном случае это нужно трактовать так, что цель системе, исходя из классического похода, ставится суперсистемой, частью которой первая и является.
Не всякий ИТ проект венчурный и инновационный. Если, например, система учета, выполненная на FoxPro переводится под MS SQL+Delphi при том, что все устраивает то, как работала предыдущая система - это ИТ проект с известной спецификацией требований, но цель его не создать новую организационную структуру, а расширить возможности имеющихся технических средств.
Хорошо пусть так. Вряд ли рассматриваешь в статье тривиальные задачи. Тем более ты привел пример, где проблем нет, цели абсолютно понятны, задачи формализованы. В данной задаче нет и предмета для разговора.
В статье насколько я понимаю все-таки говориться о проекте - как уникальной или близко к уникальной практической деятельности. Потму я естественно и не включал эти варианты в рассмотрение. Хотя на мой взгляд переезд с одной платформы на другую может быть и не тривиальной задачей. Я например знаю отличный пример, где переезжают с интербейза на мсскл. Очень знаешь не тривиальная задача
Согласен ссылок мало. Но тут могу сказать, что формат именно этого материала не позволяет излагать слишком отсушенным языком.
ссылки это не отсушенный язык а признак зрелости и приемственности
Вот ты мне скажи, куда ссылаться для подкрепления тезиса о необходимости SMART целей и оперделения, что есть SMART?
ну скажем http://www.tonich.ru/glossary/term/?id=37
http://www.hrm.ru/db/hrm/0A1C8BB8A0CA78E4C3256F8700534EF9/category.html
http://www.improvement.ru/bibliot/decision/decision04.shtm
Можно найти и более интересное.
Обзор литературы нужен, но до него надо еще дожить.
Обычно с него и начинается все. Я понимаю - это авторский материал, а не научная работа. Кончено, этим можно пренебречь.
Вообще, это тонкий момент. Я бы не сказал, что можно провести грань, где заказчивается целеполагание и начинается инженерная деятельность. Надо подумать об этом.
Все зависит от того, что ты вкладываешь в понятие инженерная деятельность - для меня это практическая деятельность по конструированию системы от замысла до реализации и эксплуатации.
Смотря для какого. Концепция - это письменно зафиксированные цели проекта. Как только она утверждена можно говорить о том, что целеполагание почти закончено. Почти - на случай изменения целей, но они меняются не всегда.
Да конечно, если мы полагаем в данном случае самые общие концептуальные цели. Однако говорить о стабилизации цели даже в этом случае вряд ли имеет смысл.
Не все так просто, но попробуем.
Я и не настаиваю :) просто предлагаю... Решать тебе все равно.
-
Насчет изложенного Концептуального документа в статье.
Читаю сейчас 3-издание Лармана. Конкретное на мой взгляд чтиво.
Так вот Ларман буквально в каждом втором обзаце пишет, все эти документы не обязательны, они нужны лишь тогда, когда нужны. Не делайте все документы последовательно - это не реально. Нереально делать видение сразу и полностью, не реально определять все требования до начала выполнения проектирования. Тот кто не понимает этого - работает каскадно, а следовательно практически обречен на провал. 65% требований определяемых таким образом не используются в системе.
В начальной фазе проекта возможно делается набросок видения, в котором уясняются проблемы, определяются основные функции системы, определяются границы системы, намечаются этапы работы, выделяются архитектурно значимые нефункциональные требования. неболее 10-15 % прецедентов детализируются и обсуждаются в ходе 2-х дневного семинара, устаканивается общее понимание проблем, целей всеми сторонами.
На первой итерации фазы Развития идет дальнейшее уточнение видения, требований и т.д.
-
В начальной фазе проекта возможно делается набросок видения, в котором уясняются проблемы, определяются основные функции системы, определяются границы системы, намечаются этапы работы, выделяются архитектурно значимые нефункциональные требования. неболее 10-15 % прецедентов детализируются и обсуждаются в ходе 2-х дневного семинара, устаканивается общее понимание проблем, целей всеми сторонами.
Семинар - это хорошо. Как бы мне хотелось сейчас провести такой семинар. Но получается так, что один из ключевых участников расположен в Новосибирске, два других в Питере (при этом один из них даже не подозревает, что его назначили ключевым), а третий (Заказчик), хоть и в Москве, но добиться его аудиенции невероятно сложно, а от его подчинённых толку, как оказалось, мало.
-
Семинар - это хорошо. Как бы мне хотелось сейчас провести такой семинар. Но получается так, что один из ключевых участников расположен в Новосибирске, два других в Питере (при этом один из них даже не подозревает, что его назначили ключевым), а третий (Заказчик), хоть и в Москве, но добиться его аудиенции невероятно сложно, а от его подчинённых толку, как оказалось, мало.
Забавная, но как я понимаю жизненная ситуация. Странная, хотя бы по тому, что решение же делается для Заказчика, а он ишь вроде как неособо и заинтересован.
Хотя может данное исключение - подтверждение правила? Главное цена вопроса: если в такой позиции вы-таки работаете несмотря на трудности, значит все-таки это выгодно, либо деваться некуда. Но это уже смахивает на феодолизм.
Интересно - а как на Западе. У того же Лармана? Неужели у него самого никогда не было опыта беганья за Заказчиком и умоления его об встречи. Может и не было, тут уж кто перед кем круче...
-
Забавная, но как я понимаю жизненная ситуация. Странная, хотя бы по тому, что решение же делается для Заказчика, а он ишь вроде как неособо и заинтересован.
Ну, как говорится, "зри в корень".
Мы являемся поставщиком оборудования, и из-за некоторых особенностей имеющихся сертификатов (ограниченный срок действия) именно в наших интересах провести начальные этапы как можно быстрее - разработать архитектуру, выкатить счёт, продать оборудование, а потом уже спокойно заниматься разработкой. Остальные участники никуда не спешат. Заказчик, что характерно, тоже особенно не торопится - ему это решение, можно сказать, навязано "сверху", и он действует по принципу "не спеши выполнять приказ - его могут отменить". А другого поставщика оборудования, со свежими сертификатами, он всегда найдёт.
Так что если вернуться к теме топика (про целеполагание), цель нужно искать совсем не там, где она по логике должна быть. :)
-
1. Западный заказчик на много более замотивирован на участии в проекте. Наши заказчики даже в ЮМЛ моделях разбирались :)
2. Ну а что нельзя провести веб/тел семинар? Было бы желание.
3. Ну давайте посмотрим картику РУПа или ОпенЮП, концепция/БМ прорабатывается в основном на первых этапах, естественно, когда требования уточняются может/должна уточняться концепция, но уже при разработке она не трогается.
4. Без условно, документы надо создавать ТОЛЬКО по необходимости. Маленький проект - концепция 2-3 листа (проблемы, ЗЛ, нужды, фичи). Средний/большой проект - концепция полее точно описывает границы (цели, проблемы, ЗЛ, нужды, фичи, БМ и т.д.)
5. Опять же здесь стоит разделить два разных продукта - создание с нуля и внедрение/кастомизирование. Как я понимаю Сергей описывает больше опыт во втором.
-
Сергей, что-то не загружается продолжение. Проверь ссылку, или это сервис упал?
-
Сергей, статья прикольная. Мысль понятная. Читается легко. Правда, как обычно много ошибок - может пропустить через word?
Насчет выполнения "через зад" - да, подтверждаю, практика такого подхода имеет место быть. Вероятно, все начинается с обучения. А обучение у нас идет именно по этому принципу, к сожалению. И хотя отдельные курсы могут быть вполне комиль фо, но в своей массе, в работе на единую цель - синхронизации нет. Т.е. стиль обучения не процессно-ориентированный (хотя и декларируется именно так, а жестко функциональный. Отсюда и раздрай в профессиональной деятельности.
-
Сумбурный текст со скандальным названием "Из жизни проктологов"
Почему сумбурный? Чувствуется, что написано на одном дыхании, читается легко, и всё понятно.
-
Проблемы, описанные в статье характерны не только для ИТ, но и для других видов отечественного бизнеса. Тяжело приживается практика расчета смет в строительстве. Ведь по большому счету этой практике лет 16 только, раньше соотносить натуральные объемы работ с их денежным выражением не было настолько актуально на "микроуровне", уровне отдельного предприятия. Поэтому специалисты, которые этим занимаются, рисуют очень похожую картину . Даже в ИТ-компаниях мысли, близкие по содержанию к высказанным в данном статье, высказывают маркетологи, HR, но при этом они-то говорят о своем деле!
В каком-то смысле можно говорить о недостаточной культуре проектного мышления в широком смысле этого слова: т.е. очень распространено представление о том, что
1. сложные вещи можно делать "просто", решая возникающие проблемы по ходу их возникновения,
2. а некое представление о том, что именно должно получиться в результате и как именно оно будет делаться (проект) вроде бы и не нужно.
Причем драматизм ситуации для ИТ заключается в том, что "промышленным образом" могут автоматизироваться достаточно "регулярные практики": типовые ИТ-решения для типовых видов бизнеса. В какой мере можно считать бизнес заказчика типовым, в той мере можно его успешно автоматизировать типовым ИТ-решением, а также реализуя решение типовым способом. В каком-то смысле можно говорить о том, что существующая культура бизнеса, недостаточное развитие "регулярных бизнес-практик" сдерживает развитие ИТ.
-
Сергей,
А к вам уже посылают: http://community.livejournal.com/ru_pm/87575.html
-
Сергей, предлагаю следующим шагом в развитии boatmanshome.ru прикрутить RSS к новостям. Или хотя бы mail-рассылку. А то интереснейшие статьи как-то пролетают мимо и обнаруживаются с опозданием.
Пиарю в этой ветке:
Техника в руках дикаря - статья об отношениях между работадателями и работниками (http://boatmanshome.ru/cgi-bin/page.pl?2notes_007)