Рождение задачи: формулирование Технического Задания

УДК 62+001.894+001.82        

                                                                                                          Быстрицкий А. А., Никитин В.Н.

                                                                                                          Россия, Иркутск

 

– Two tickets to Dublin.

– Куда, блин?

To Dublin.

Аннотация

В работе рассматривается вопрос том, каким образом происходит формулирование технического задания (ТЗ), которое является формализованным текстом задачи, решаемой ТРИЗ-экспертом. Рассмотрение вопроса ведётся с точки зрения подходов, используемых специалистами Ангарского центра методологии научно-технического творчества (АЦМНТТ) с 1990 годов до сегодняшнего дня.

Проблемная ситуация

Творчество – это решение таких проблем и такими способами, которые лежат за пределами вашего предыдущего опыта.

Проблемная ситуация возникает в мышлении человека в форме конфликта между желаемым и реальным состоянием дел. Процесс осмысления проблемной ситуации и проектирования дальнейших действий может быть осмыслен с помощью аналитической модели «Цикл процесса развития» (рис. 1), описывающей развитие бизнеса.

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

В процессе работы с проблемой развития, совершенствования бизнеса можно выделить три значимых этапа:

  1. Диагностика проблемной ситуации;
  2. Формулирование технического задания («ТЗ»);
  3. Решение сформулированных задач.

Аналогичный подход, то есть движение от эмоционального восприятия ситуации к её последующей вербализации, реализован в шестиэтапной модели принятия управленческих решений по Г. Саймону [1]. Данная аналитическая модель может рассматриваться как надсистемная по отношению к методологии классической ТРИЗ (рис. 2).

Рис. 2. Модель принятия управленческого решения (Герберт Саймон).

Методологии ТРИЗ в данной модели соответствуют шаги с 3-го по 5-й, при этом выявление проблем (шаг 1) и их формулирование (шаг 2) с последующим уточнением могут также выполняться аналитическими инструментами ТРИЗ.

Модель Г. Саймона имеет следующий алгоритм реализации.

Этап «Обдумывание», шаги 1-3:

  1. Выявление симптоматики проблемы;
  2. Формулирование и уточнение проблемы;
  3. Определение критериев достижения результатов.

Этап «Проектирование вариантов решения», шаг 4:

  1. Разработка различных вариантов решений.

Этап «Выбор», шаги 5-6:

  1. Оценка вариантов по соответствию их критериям шага 3;
  2. Выбор лучших вариантов по результатам оценки.

На шаге 2 проблема формулируется как некий позитивный результат, который желательно достичь. При этом формулировка проблемы, как правило, начинается со слов «Хочу, чтобы».

На шаге 3 (модель Г. Саймона) определяются критерии достижения результатов при решении проблемы, и происходит формулирование ТЗ. Техническое Задание становится «золотым звеном цепи», объединяющим интересы заказчика, который ощущает проблемную ситуацию, и эксперта, получающего измеряемые характеристики решения, которое ему предстоит создать в будущем.

Именно процессам формулирования Технического Задания посвящена данная статья.

Уровни постановки проблем.

Критерии достижения результатов на шаге 3 при решении проблемы и формулировании Технического Задания могут быть сформулированы на трёх иерархических уровнях:

  1. Социальном;
  2. Административном;
  3. Техническом.

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

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

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

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

Решения проблемы также могут быть найдены на различных уровнях, если они будут учитывать все или основные критерии.

Формулирование задачи как формализованный процесс

Для формулирования критериев решения проблем в процессе декомпозиции и детализации проблемной ситуации целесообразно использовать модель Розмари Стюарт [2]. Данная модель сводит ситуацию принятия решений к анализу списков требований и ограничений, которые полно характеризуют то, что «дано» в задаче. При этом позиция «требуется» определяется как некоторый набор возможных операций – «альтернатив», выполнение которых приведёт  к достижению требуемого результата. Сама модель не предусматривает какого-либо алгоритма формулирования этих альтернатив.

Требования – это то, что необходимо достичь в будущем. Источниками требований является руководство, сотрудники всех уровней, поставщики, клиенты и дальняя внешняя среда.

Ограничения – это то, что необходимо учитывать как недопустимые изменения в настоящем. Ограничениями могут быть:

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

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

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

Требования и ограничения могут быть разбиты на три группы: критерии экономичности, критерии результативности и критерии эффективности (рис. 3).

Рис. 3. Модель Вход-Выход и области критериев.

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

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

Показатели результативности дают информацию о том, какой объём продукции и с каким качеством (функционалом) должен быть получен в процессе производства за некоторый период времени.

При этом показатели выполнения процесса могут быть абсолютными, взятыми за некоторый период технологического процесса или партионными (удельными), т.е. отнесёнными к партии (единице) продукции (таблица 1).

Таблица 1

Виды показателей

Показатели оценки процесса (примеры)

 

абсолютные

относительные

Экономичность

кг

кг/час

 

кВт*час

кВт*час/м2

Эффективности

--

единицы/кг сырья

 

--

м3/кВт*час

Результативности

единицы

единицы/час

 

м3

м3/секунду

 

Люди, решающие проблему

Люди, участвующие в процессе решения проблемы могут играть три творческие роли:

  1. «Владелец проблемы» — тот, кто в данный момент ощущает, понимает и сообщает, какая проблема, которая ощущается как повод для тревоги, должна быть решена. При этом задача для решения формулируется как выстроенный по рейтингу комплекс требований и ограничений, которым должен соответствовать требуемый результат решения творческой проблемы. Как правило, роль владельца проблемы выполняет заказчик, и в этом случае величины и рейтинг требований и ограничений должны быть зафиксированы документально.
  2. «Владелец знаний» — тот, кто владеет и передаёт по запросу комплекс профессиональной информации, относящейся к проблематике задачи. Этот комплекс может содержать информацию о протекающих процессах и их параметрах, причинно-следственных связях параметров, о факторах, управляющих процессами и т.д.
  3. «Решатель проблемы» — тот, кто ищет и находит решение проблемы, опираясь на знание методологии решения задач, в интересах владельца проблемы, используя профессиональную информацию от владельца знаний.

При выполнении «инициативного» проекта, когда одиночка сам формулирует проблему, собирает и консолидирует профессиональные знания и решает проблему, эти три роли может исполнять один человек. При решении «корпоративной задачи» на каждую из ролей может быть назначено несколько человек, участников творческого процесса.

Задачи. Классификация…

В зависимости от того, каким образом, в каких показателях, сформулировано ТЗ, все виды творческих задач можно разделить на следующие типы:

  1. Снижение операционных затрат, т.е. снижение операционной себестоимости;
  2. Повышение производительности труда и, как следствие, снижение полной себестоимости;
  3. Повышение качества продукции или снижение уровня брака;
  4. Снижение технологических рисков (устранение нежелательных эффектов) или предотвращение аварий;
  5. Разработка нового продукта.

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

Выводы

  1. В процессе решения проблемы участники играют три творческие роли: владелец проблемы, владелец знаний и решатель проблемы.
  2. Техническое задание формулируется как комплекс требований и ограничений.
  3. Требования и ограничения могут быть сформулированы на социальном, административном и техническом уровне.
  4. Требования и ограничения могут быть разделены на критерии результативности экономичности и эффективности.
  5. Формулирование Технического Задания выполняется по следующему алгоритму:
  • Определяются возможные критерии оценки будущих решений (требований и ограничений), учитывая все виды показателей;
  • Классифицируются требования по уровню постановки проблемы;
  • Ранжируются требования по уровню приоритетности;
  • Выполняется корректировка требований и определяется тип задачи.

Литература

  1. Соколов Н.Н. Навыки эффективного руководителя при принятии и реализации управленческих решений. Учебно-методическое пособие. М.: Изд-во "Спутник+", 2014. - 52с. http://iguip.narod.ru/sokolov/Posobie_RUR-2_Sokolov_GUU.pdf
  2. Инструменты для руководителя. Описания, примеры. Выпуск 25. Работа руководителя. Модель Стюарт.  https://subscribe.ru/archive/economics.school.finishmanager/200905/26020519.html/

Алфавитный указатель: 

Рубрики: 

Комментарии

Re: Рождение задачи: формулирование Технического Задания

Изображение пользователя Redkolis.

Хотела бы выразить благодарность авторам статьи за вынесение на обсуждение вопросов, столь актуальных в настоящее время (в условиях активного внедрения ТРИЗ на отечественных предприятиях).

Ниже оставлю свои комментарии, надеясь на вовлечение в дискуссию чуть большего количества участников этого славного форума.

 

 

Как было отмечено, вопросы, вынесенные в статье, без сомнения злободневны. Однако хотелось бы еще раз уточнить, в чем они заключаются?

 

Наверняка, есть некая статистика об опыте формирования ТЗ на Проект и опыте применения на тех или иных этапах Проекта разного рода классификаций? Показания к применению той или иной классификации? Или, например, существует перечень рекомендаций, как поступать, если у тебя в Проекте обнаружился тот или иной объект из классификации – как его препарировать, что с ним делать? – Такая информация, без сомнения также была бы полезна для обсуждения.

 

Далее по тексту.

 

1. Разные уточнения.

A)

content manager wrote:
В процессе работы с проблемой развития...

О какой проблеме развития идет речь?

Насколько я понимаю, - не о "проблемной ситуации", о которой сообщается в начале статьи.

 

content manager wrote:
можно выделить три значимых этапа:...

Поскольку не уточнена проблема развития, сложно понять, почему именно эти 3 этапа значимы, и почему менее значимы последующие.

Возможно, это этапы, на которых идет "Процесс осмысления проблемной ситуации"?

 

К вопросу о целесообразности применения модели Саймона к ТРИЗовским будням.

content manager wrote:
Методологии ТРИЗ в данной модели соответствуют шаги с 3-го по 5-й...

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

1) Чтобы говорить, какие шаги напрямую соответствуют методологии ТРИЗ, полезнее детализировать связку пп. 2-3. В случае же, если этого не предпринимать, к кругу интересов ТРИЗ необходимо также отнести и п. 2.

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

 

B)

content manager wrote:
Критерии достижения результатов на шаге 3 при решении проблемы и формулировании Технического Задания могут быть сформулированы на трёх иерархических уровнях:  Социальном; Административном; Техническом.

 

А могут и не быть... Хотелось бы узнать вывод, на основании многолетней практической деятельности авторов, в чем преимущества и недостатки формулирования критериев на таких уровнях? Почему рекомендованы именно они?

 

Соглашусь, что критерии формулируются на каждом из этих уровней, но не соглашусь в том, что это уровни одной иерархии. Если неверно уловила мысль авторов, прошу меня поправить.

 

Теперь к приведенным примерам.

1)

content manager wrote:
"На социальном уровне... повысить производительность труда на участке".

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

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

 

2) В чем преимущество такого подхода (деление на социальное, административное и техническое), по мнению авторов? Мне видится такая классификация более осмысленно-описательной, чем практически-применимой.

Может быть, отталкиваясь от того, что ТРИЗ работает с искусственными системами, гораздо полезнее классифицировать проблемы и задачи исходя из уровня абстракции, на котором они осознаются и решаются (физический, технический, структурный...)?

 

3)

content manager wrote:
"...на физическом уровне формулируются не критерии решения проблемы, а требования к свойствам ТС или её элементов".

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

Аналогично "к свойствам ТС". Так значит, к "системным свойствам"? - Так значит, к «технике», а не к «физике»?

 

4)

content manager wrote:
"Решения проблемы также могут быть найдены на различных уровнях, если они будут учитывать все или основные критерии."

Возможно ли обратиться к опыту нахождения решения не на том уровне, на котором формулировалась задача? Речь о вполне себе ТРИЗовской задаче, сформулированной уже, например, на уровне противоречия.

 

Насколько слабым и имеющим пагубные последствия является попытка применить подходящее решение, возникшее в голове попутно, на другом уровне абстракции? Насколько прозрачен для решателя должен быть переход от одного уровня поиска решения к другому? И какие последствия от такой непрозрачности могут возникнуть? Можно ли их типизировать?

Это ни в коем случае, не претензионные вопросы к авторам статьи. А только лишь мои размышления о необходимости или бесполезности приложения усилий в те или иные направления исследований относительно развития методологии ТРИЗ.

 

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

А далее - работать над внятной процедурой ретрансляции полученного решения на все нижележащие уровни, вплоть до физической реализации (пойди-принеси-сделай).

 

C) Из трех перечисленных ролей (владелец проблемы, эксперт, решатель) самой (если не единственной) творческой ролью является решатель.

В чем польза, опять-таки, такой интуитивной и общей классификаций?

Куда полезнее, на практике, особенно в групповых проектах, выделять творческие роли внутри именно коллектива решателей (раз только решатель, по сути, и «творит») и делить их, например, по характеру прогнозов (оптимистичный, пессимистичный, нейтрально-рациональный). Практическая иллюстрация такого подхода - 6 шляп де Боно.

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

 

2. О полезности классификаций.

Ремарка. Как-то, работая над большой (по количеству параметров) научной задачей, услышала от академика следующие слова: «Создавать, да и анализировать классификации – удел докторских диссертаций, и то не всех».

 

Абстракция ради процесса абстрагирования? – Малополезна для текущего уровня развития методологии ТРИЗ.

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

 

Далее снова по тексту.

 

content manager wrote:
Задачи. Классификация…

Опять-таки, не ясно основание, выбранное для классификации. Новизна?

Тогда пп. 1-5 укладываются в совершенствование существующих продуктов и процессов. А п. 6 - относится к созданию нового.

Этой классификации точно не хватит для того, чтобы описать "все виды творческих задач" (о чем пишут авторы). "Все" придется скорректировать на прикладную, и может быть даже только промышленную отрасль.

 

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

И в связи с этим возникает закономерный вопрос, если ТРИЗ работает с любыми искусственными системами, стоит ли плодить узкие классификации, еще сильнее стаскивая методологию в обычную инженерную рутину? - Дискуссионно.

 

Есть такого рода классификация проектов в ТРИЗ:

1) Создание новых продуктов (в т.ч. определение направления развития продуктов при переносе их в новые отрасли);

2) Совершенствование продуктов (определение направлений совершенствования продуктов в соответствие с их потребительскими ценностями, = увеличение «value» продукта);

3) Совершенствование процессов;

4) Верификация проектов;

5) Создание продуктов, не подпадающих под действие патентов конкурентов (обход патентов);

6) Прогноз.

Она, скорее всего, получилась путем ментальных переживаний относительно типового порядка применения ТРИЗ-инструментов для каждого вида проектов (aka "roadmap").

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

 

И применительно к беседе о грамотности и удачности формулировки ТЗ, кажется мне, такой классификации достаточно. Потому что она хоть как-то позволит оценить количество шагов (=количество ТРИЗ инструментов), которые необходимо будет пережить по решению. Далее, на для каждого типового шага установится типовое время. Сумма времен шагов умножится, из чувства самосохранения, на 1,5 или 2. И Проект запустится в работу.

И, в общем-то, такой подход широко распространен.

 

3. О возможности применить результаты копания в классификациях.

На этапе формирования ТЗ не ясно, насколько творческой окажется задача. Сколько ментальных, а также вполне осязаемых усилий решателям и Заказчику придется предпринять в ходе Проекта. Да и задача-то (в ТРИЗовском понимании) не всегда присутствует.

Недооцененная трудоемкость - одна из самых распространенных ловушек, в которую попадает Исполнитель.

 

Повысить же верность оценки трудоемкости на этапе формулировки ТЗ  можно, если иметь как минимум, некоторый Контрольный Опросник, который бы позволил оценить:

а) уровень формализации исходной проблемной ситуации;

б) количество и "качество" доступных для привлечения отраслевых экспертов;

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

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

 

И вот как раз в процессе проработки подобного опросника и следует двигаться по всевозможным классификациям задач, участников, этапов работы над задачами. Там-то они и будут полезны.

 

Порядок же такого движения может быть следующим:

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

2. Определить основания классификации для каждого отобранного пункта. Формализовать сами классификации.

3. Проработать вопросы, ответы на которые являлись бы лакмусовыми бумажками для выявления каждого фрагмента каждой классификации.

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

5. Агрегировать результаты пп. 3-4. Количественно спроектировать опрос.

6. Приступить к тестированию опроса на производстве.

 

Конечно, прежде чем ввязываться в неблагодарную затею с составлением Опросника, следует «крепко подумать», а надо ли вообще оценивать, насколько творческие задачи придется решать?

 

Утилитарно зачем классифицировать творчество?

И чем известные подходы к определению, например, сложности и уровня задач не полны?

 

Единственный ответ, который пока приходит мне на ум, порождает физическое противоречие по отношению к решаемой задаче. Но,.. как разбираться с противоречиями, мы знаем... !

Re: Рождение задачи: формулирование Технического Задания

Сложные у меня ощущения от этой статьи. С одной стороны, там приведен анекдот про ДаБлин, и это, конечно, в плюс. С другой стороны, как-то странно ссылаться на Герберта Саймона, приводя при этом ссылку не на его работу а на методичку для студентов некоего НН Соколова, который в своем 38 страничном труде так и не сделал сам ссылки на Саймона, поскольку видимо прочитал о нем у кого-то еще. Ну и с госпожой Стюард поступили примерно также, сославшись на какую-то безымянную одностраничную памятку в интернетах.

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

• Ощутить наличие проблемы 

• Сформулировать и уточнить цель 

• Определить критерии, которым должно удовлетворять успешное решение

• Проектирование вариантов решения (генерация альтернатив)

• Сравнить варианты с критериями

• Выбрать наилучший вариант

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

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

В общем, так и не смог определить для себя, что нового можно узнать о постановке ТЗ из этой работы.  Но здесь, конечно, большие пртензии в первую очередь к редактору. :(

Re: Рождение задачи: формулирование Технического Задания

 

В общем, так и не смог определить для себя, что нового можно узнать о постановке ТЗ из этой работы.  Но здесь, конечно, большие пртензии в первую очередь к редактору. :(

 Вход в  Тему с анекдота Мастерски использовал  Геннадий Иванович...Светлая ему Память.. 

 Сам думал : Что к чему?  Дважды перечитал.. С третьего захода зацепился взглядом за указание УДК в шапке материала. 

 

 Указано УДК . Надо понимать, чтобы  статья депонировалась в Библиотеке и имела  силу публикации.

М.б.  кто-то собирает необходимое количество публикаций для защиты кандидатской?  Но... тогда, действительно, почему  такой откровенно бледный список первоисточников.   Фигня короче. 

  

 

[/quote]

Subscribe to Comments for "Рождение задачи: формулирование Технического Задания"