Мое почтение.

Александр Кудрявцев wrote:

как не решая (не тратя времени) отсекать нерешаемые задачи?

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

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

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

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

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

Сергей Малкин wrote:

Я же хочу получить методику анализа ситуации обеспечивающую ПОСТАНОВКУ задачи. Не все мыслимые вопросы, а тот минимум, который обеспечить сразу отсечение нерешаемых задач. <...>
Определение целей, это обозначение конечного результата вашего проекта. Цели, сами по себе, не объясняют как они будут достигнуты. Цель, говорит о том, какой результат должен быть достигнут. Не вносите процесс достижения цели в саму цель. Методы поиска решений мы будем использовать позднее.
<...>

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

Quote:

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

Здравствуйте, Lynx!

Lynx wrote:

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

Lynx wrote:

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

Lynx wrote:

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

Сергей Малкин wrote:

Я предлагаю проверять на "Что будет если решим?". Очень часто (15%) клиент не верно представляет последствия "решения" или не задумывался, что ситуация изменилась. Простой толчок подумать об альтернативах и их последствиях кординально меняет ситуацию. Не всегда и не на 100%. Тут скорее противоречие: введешь в методику отсекающие процедуры, клиент в силу нетренированного воображения отсечет перспективные направления.

Сергей, я вынужден объяснить вам как иностранцу некоторые особенности русского языка. В русском языке конструкция "я предлагаю... + объяснение" сообщает в том числе и о том, что сообщающий - автор высказываемого предложения.
Но должен сказать, что мир узнал о вашем предложении из книги Дмитрия Дмитриевича Максутова еще в 1946 году (см Максутов Д. Д. Астрономическая оптика – М.-Л. : ОГИЗ Гос. изд-во техн.-теорет. лит., 1946.)
Чуть позднее мыслительную схему, описанную Максутовым сделал методическим приемом Г.С. Альтшуллер, о чем и сообщил в книге "Алгоритм изобретения". Было два издания этой книги - в 69 и 71 годах.
В.М. Герасимов, которого вы даже может быть знаете, довольно плотно занимался проблемой такого "проскока" через еще не найденное решение, что отражено в ряде его работ.
Примерно об этом несколько дней тому назад в предельно деликатной форме сообщил вам Григорий ( см http://metodolog.ru/node/562#comment-9445 )
Поэтому, Сергей, изучайте "материальную часть", для разработчика это полезно.

Сергей Малкин wrote:

Кстати в наших проектах отрицательный результат, тоже результат.
Решая задачу снижения себестоимости дверного замка автомобиля проект закончился через час. Клиент хотел снижекние себестоимости на 30%. При этом попросил не менять процессор и ремоут. Быстро посчитали, что если выкинуть все остальное, то можно снизить на 25%. Лидер проекта - пошел с докладом к руководству. Проект закрыли. Учасников наградили.

Опять встряну.

«если выкинуть все остальное, то можно снизить на 25%» -- так это и есть противоречие, тут и надо изобретать. Сергей, зачем вас приглашали то?

С уважением, Александр.

Сергей Малкин wrote:

Сагадеев Александр wrote:

Опять встряну.

«если выкинуть все остальное, то можно снизить на 25%» -- так это и есть противоречие, тут и надо изобретать. Сергей, зачем вас приглашали то?

С уважением, Александр.

Приведите мысленное описание (не надо решения) как это может быть.

Сергей Малкин
www.pretiumllc.com[/quote]

Сергей, что «это» может быть?

Вы попытались решить задачу в лоб, убрав всё лишнее. Получили противоречие. Вы интересуетесь, как работать с противоречиями?

Мысленное описание, как работать с противоречиями прекрасно изложено ГСА в куче всяких изданий.

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

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

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

В Вашем случае, конечно, необходимо знать все условия задачи и приступить к её решению, что бы предложить более конкретное «мысленное описание». У нас это называется «описание объекта модернизации» и «разработка концепции» и выполняется на предпроектной стадии.

Скажем, первым делом возникает вопрос, что означает запрет на изменение процессора. Это электронный замок? Процессор -- это электронное устройство?

У меня был случай, когда также требовалось сохранить СВЧ аттенюаторы при задаче по снижению веса изделия. Выяснилось, что существуют точно такие же, той же фирмы, по той же цене, в том же форм-факторе, но не с параллельным управлением (8 проводов на восемь бит + обратный), а с последовательным (1 провод на всё устройство + обратный). Причём, вместо параллельной разводки (по толстенному жгуту к каждому корпусу), последовательная (т.к. в новом исполнении использовался сдвиговый регистр с битом переноса на следующий корпус). Дополнительно исчезла необходимость в куче коммутаторов и защёлок, т.к. управление велось от одного процессора и от его восьми битной шины нужно было реализовывать звезду с количество лучей по количеству аттенюаторов. Последовательное же управление этого не требует. Я уже молчу о том, что кардинально улучшилось удобство монтажа. Вместо разводки кучи перепутанных жгутов, появилась изящная витая пара.

Думаю, что ни у кого не вызывает сомнений, что ограничения заказчика выполнены (на 99,9999[9]%), и эффект получен огромнейший.

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

В массовом производстве 30% экономия -- это бешеные доходы. Ради этого, организационно, можно и уволить на фиг того манагера, которые ввёл запрет на смену процессора, доля которого в цене (вместе с ремоутом), как Вы вычислили, составляет 75%. ФСА, скажем, впрямую потребовало бы начать искать возможности удешевления со смены процессора.

С уважением, Александр.

Сергей Малкин wrote:

В примере запрет на изменение процессора был "правильным" - звмена поставщика в автомотив - это мереприятие на 1-2 года и 30% экономии его не покроют.

С уважением, Александр.