Как координировать действия менеджеров активных продаж?
Инструкции в кейсе для отела активных продаж. А также: стандарты работы, система мотивации, чек-листы, должностные инструкции, методики и скрипты продаж
На сайте ведутся работы
сегодня 10928 Подписчиков
Уважаемый Валерий Викторович,
Правильно ли я поняла, что Вы хотите решить задачу с помощью приемов ТРИЗ, которая возникла в процессе написания программы?
Или Вас интересует перечень задач по программированию, которые можно решить с помощью методов ТРИЗ?
С Уважением,
Уважаемый Валерий Викторович!
Скажите, пожалуйста, а есть ли у Вас первичная картотека задач.
И, если, да, то какой ее объем.
Большое спасибо!
Добрый день!
1. Если не секрет, конечно, каково количество задач в картотеке:
2. Какой формуляр используется для сбора задач? Могли бы Вы здесь привести его + показать несколько примеров (3-4) задач, описанных по этому формуляру.
С Уважением,
Очень интересно было бы ознакомиться с вашими наработками. Наткнулся на сайт, при поверхностном осмотре некоторые приёмы ТРИЗ можно применить и в программировании. На вскидку -- "сделать наоборот". Могу предположить, что можно выделить целую подгруппу приёмов для работы с информационными, а не с техническими объектами.
Уважаемый Валерий Викторович!
В конце прошлого - начале этого года мною был написан ряд статей, посвященных исследованию, классификации и поиску типовых программных ошибок (ошибок программистов, допущенных при написании программ).
При написании статей была использована собранная на основе личного опыта и опыта коллег картотека ошибок.
С опубликованными материалами Вы можете ознакомиться по следующим ссылкам:
Уважаемые коллеги!
На официальном сайте Oracle опубликована статья о ТРИЗ:
"Seeing the Forest for the TRIZ" by Marta Bright
С уважением,
Исполнительный директор Официального Фонда Г.С. Альтшуллера Лариса Дмитриевна Комарчева
Уважаемые коллеги!
В программировании, как и в изобретательстве, тоже приходится решать изобретательские задачи. Например, при проектировании программы или при поиске ошибок.
Некоторые авторы сумели выделить целый ряд так называемых "шаблонов проектирования" и "шаблонов ошибок". Например:
Но почему-то дальше набора шаблонов дело не пошло. Например, с момента выхода первого издания книжки 1 прошло уже больше 10 лет. Однако список шаблонов так и не пополнился. Да и проектирование с учетом шаблонов не получила особого распространения. Каждый программист решает сам, использовать этот метод или нет.
Интересно, в чем заключается причина такого явления?
С уважением,
В программировании, как и в изобретательстве, тоже приходится решать изобретательские задачи. Например, при проектировании программы или при поиске ошибок.
Вы можете привести конкретный пример из своей практики, который можно назвать "изобретательской задачей"? Есть ли определение что такое "изобретательская" задача?
Да и проектирование с учетом шаблонов не получила особого распространения. Каждый программист решает сам, использовать этот метод или нет. Интересно, в чем заключается причина такого явления?
Рискну предположить, что полезность этих шаблонов неочевидна для начинающих. И, в ряде случаев, их использование противопоказано. Это не универсальное решение. А опытные люди на серьезных проектах их используют в полный рост.Уважаемый Сергей!
Вы можете привести конкретный пример из своей практики, который можно назвать "изобретательской задачей"?Есть ли определение что такое "изобретательская" задача?
Условно изобретательские задачи в программировании, как и в «железном» ТРИЗ, можно разделить на макси-задачи и мини-задачи. Макси-задача связана с проектированием новой системы (программы, библиотеки, функциональной части программы). Для ее решения требуется сформулировать и решить множество мини-задач.
Примеры макси-задач:
Разработать библиотеку контролей (элементов пользовательского интерфейса) или даже написать какой-нибудь один контроль (тулбар, строку состояния, список, тултип и т.д.).
Написать водителя-автомата (бота) для гоночной игры.
Разработать и реализовать физическую модель средства передвижения.
Разработать игровой движок.
Внести поддержку многопоточности в игровой движок.
Под мини-задачей, в принципе, можно понимать часть макси-задачи. Решение макси-задачи образуют решения целого «куста» мини-задач. Но не все из этих мини-задач можно считать творческими, изобретательскими.
Примеры неизобретательских мини-задач:
Написать функцию, возвращающую значение переменной.
Написать функцию перебора элементов массива.
Написать комментарий.
Под неизобретательскими мини-задачами будем понимать то, что надо просто сделать, и хорошо известно, как это можно сделать. В таких мини-задачах не содержится никакого противоречия.
Примеры изобретательских мини-задач:
Пример 1.
В редакторе геометрических фигур (в основном – ломаных линий и многоугольников) существуют несколько режимов редактирования. Два из них отвечают за изменение формы редактируемых фигур. Первый режим – режим перемещения точек – позволяет с помощью мыши передвинуть любую вершину фигуры в заданную точку. Второй режим позволяет добавить к контуру новую вершину (щелчком мыши ребро разбивается на две части). Пользователям (дизайнерам) очень неудобно работать с таким редактором. Им приходится постоянно переключаться из одного режима в другой. Для переключения нужно нажать мышью кнопку на тулбаре. Как быть?
В этой задаче четко видно противоречие: режима редактирования должно быть два, чтобы двигать точки и разбивать ребра. И в то же время, режим должен быть один, чтобы дизайнерам не нужно было переключаться между режимами.
Для решения можно использовать принципы разрешения противоречия в пространстве и в структуре. Если курсор мыши попадает в вершину (или в небольшую область рядом с ней), то автоматически включается режим редактирования (перемещения) точек. Если же курсор мыши при щелчке попадает в отрезок, то включается режим разбиения отрезка на части.
Пример 2.
В том же самом редакторе геометрических фигур (после объединения режима перемещения точек и режима рассечения ребер) остались следующие режимы редактирования: режим создания фигуры, режим перемещения фигуры, режим поворота фигуры и режим изменения формы фигуры.
Переключение из режима в режим осуществляется с помощью кнопок тулбара.
Для реализации всех четырех режимов редактирования нужно написать обработчики мышиных сообщений, т.к. редактирование осуществляется с помощью мыши. Однако если все четыре режима обрабатывать в каждом из обработчиков, возникнут следующие трудности:
Код обработчика будет слишком тяжел для понимания и сопровождения.
Для добавления или удаления нового режима придется изменять код обработчиков всех мышиных сообщений. А хотелось бы, чтобы добавление или удаление режима было бы простой процедурой.
Таким образом, сформулируем противоречия.
Противоречие-1. Код каждого обработчика каждого из мышиных сообщений должен содержать обработку всех четырех режимов редактирования, т.к. это надо для их реализации. И в то же время код обработчика должен содержать обработку только одного режима редактирования, т.к. он должен быть понятным.
Противоречие-2. Операция добавления и/или удаления режима редактирования должна приводить к изменению только в одном месте, чтобы было удобно сопровождать программу. В то же время, эта же операция должна осуществляться в каждом из обработчиков каждого мышиного сообщения, т.к. таких сообщений много, и их все надо обработать.
Первое противоречие разрешается с помощью приемов «вынесение» и «дробление». Вместо одного обработчика на одно мышиное сообщение пишутся четыре: по одному на каждый из режимов.
Второе противоречие разрешается с помощью приема «объединение». Все обработчики, относящиеся к одному и тому же режиму, объединяются в отдельный класс (отдельную структуру данных). Для всех классов пишется абстрактный базовый класс, который объявляет интерфейс режима редактирования. А каждый из режимов редактирования реализуется в производном классе.
В редакторе имеется массив режимов редактирования. Текущий режим редактирования является номером элемента в этом массиве. При поступлении сообщения от мыши оно передается для обработки активному элементу. Таким образом, для добавления или удаления нового режима редактирования нужно всего лишь добавить или удалить элемент из массива.
Из примеров видно, что изобретательская мини-задача обязательно содержит противоречие.
Рискну предположить, что полезность этих шаблонов неочевидна для начинающих. И, в ряде случаев, их использование противопоказано. Это не универсальное решение. А опытные люди на серьезных проектах их используют в полный рост.
Шаблоны проектирования – это аналог стандартов в «железной» ТРИЗ. Например, если не ошибаюсь, то решение, приведенное в примере 2, может быть получено с помощью применения шаблона «Состояние» (“State”). Среди шаблонов проектирования существуют аналоги и других ТРИЗ-приемов, например, «принципа посредника».
Один из недостатков шаблонов проектирования – это отсутствие четких указаний, когда и как их нужно применять. Т.е. отсутствует модель описания задачи и указатель применения шаблонов.
Вот мне и странно, почему это не было сделано ни авторами книжки «Приемы объектно-ориентированного проектирования. Паттерны проектирования», ни другими.
Шаблоны проектирования – это достаточно мощный инструмент. Но пригоден он только для решения мини-задач. Мне кажется, что ограниченное применение шаблонов связано именно с отсутствием инструмента для решения макси-задач, который бы позволял сводить любую макси-задачу к набору мини-задач.
Кроме того, когда программист приступает к решению конкретной мини-задачи, отсутствуют четкие критерии качества решения этой мини-задачи. Например, в том же самом примере 2 программист может пренебречь читаемостью кода и удобством его модификации, и реализовать обработку мышиного сообщения для каждого из четырех режимов редактирования в одном обработчике.
С уважением,
Уважаемые коллеги!
Хочу привести цитату из книжки, посвященной методологиям разработки ПО (Алистер Коберн. Быстрая разработка программного обеспечения. – М.: Издательство «Лори», 2002).
Вот как автор вкратце описывает свою методологию Crystal Clear быстрой разработки ПО:
«Поместите от четырех до шести человек в комнату с рабочими станциями, белыми досками и доступом к пользователям. Убедите их производить для пользователей работающие, протестированные программы каждые один-два месяца, во всем остальном оставьте их в покое» (с. 18).
Почему-то эта цитата напомнила мне цитаты из других западных книжек, посвященных методикам креатива в рекламе и PR.
С уважением,
Уважаемый Кирилл!
Прежде всего, хочу выразить искреннюю благодарность за столь развернутый ответ.
Однако вы не ответили на вопрос: Есть ли определение что такое "изобретательская" задача?
Может более опытные коллеги подскажут?
Вы делите задачи на "мини" и "макси".
Из вашего письма следует, что "макси":
А "мини" делятся на
То есть вы ставите в один ряд формулировки "изобретательская потому, что не четко сформулированная и/или слишком общая" и изобретательская потому, что содержит противоречие. Я правильно Вас понял?
Вобщем получается: сформулировал, раздробил, решил противоречие (которое сам увидел/придумал/выстрадал) неважно каким способом (сам придумал способ решения или не сам придумал) - сделал изобретение? Так?
У Вас не возникает ощущения, что вы подменяете слово "реализация" словом "изобретение"?
Отдельная благодарность за последний абзац про "критерии". Очень здорово было бы еслиб кто-то их сформулировал. А пока их нет - каждый их сам себе придумывает и исходя из придуманного делает и оценивает.
Теперь что касается шаблонов :-)
почитайте К. Ларман "Применение UML и шаблонов проектирования", возможно, картина станет яснее.
В книге Э. Гамма и др. "Приемы объектно-ориентированного проектирования. Паттерны проектирования", на которую вы ссылаетесь, на мой некомпетентый взгляд (:-) достаточно четко сформулированы "Назначение, Мотивация, Применимость, Структура, Участники, Отношения, Результаты, Реализация, Известные применения, Родственные паттерны" для описываемых шаблонов.
Вы пишите:
Шаблоны проектирования – это достаточно мощный инструмент. Но пригоден он только для решения мини-задач. Мне кажется, что ограниченное применение шаблонов связано именно с отсутствием инструмента для решения макси-задач, который бы позволял сводить любую макси-задачу к набору мини-задач.
Теперь посмотрите на сформулированное Вами определение "макси задачи":Макси-задача связана с проектированием новой системы (программы, библиотеки, функциональной части программы). Для ее решения требуется сформулировать и решить множество мини-задач.
Вот лично я, например, даже представить себе не могу, как можно создать инструмент для решения несформулированной задачи.В книге К. Ларман есть замечательный абзац, который я позволю себе процитировать:
«
Когда не следует применять шаблоны.
Иногда разработчики систем злоупотребляют добавлением интерфейсов и применением принципа полиморфизма с целью обеспечения дееспособности системы в неизвестных заранее новых ситуациях. Если точка вариаций известна и обоснована, если существует высокая вероятность вариантного поведения, то такие усилия по обеспечению гибкости системы и применению принципа полиморфизма вполне оправданы. Однако к применению этого принципа нужно подходить критически, поскольку зачастую усилия по обеспечению вариантов поведения "на все случаи жизни" затрачиваются впустую. Реально оценивайте вероятность вариантного поведения.
»
На всякий случай сформулирую вопросы, на которые ответы очень хочется получить (не важно от кого).
Еще раз спасибо за примеры.
С уважением,
"Изобретательской" называется задача, содержащая техническое противоречие - см. здесь www.altshuller.ru
Однако речь идет не о том, что цит.: "cам увидел/придумал/выстрадал", а о том, что есть в системе.
Например, противоречие между "функциональностью и сложностью", "весом и мощностью", "скоростью и точностью" и т.д., и т.п.
С Уважением,
Уважаемый коллега!
Если Вы имеете в виду вот эту задачу: "Задача 3.10. Нужно предложить подземоход, способный передвигаться в земной коре со скоростью 10 км/ч при запасе хода в 300—400 км.". И если Вы, при этом, действительно полагаете, что такая задача технических противоречий не содержит, то даже не буду с Вами спорить.
Если же в Вашем вопросе содержится просьба указать на конкретные технические противоречия в данной задаче (замечу 5-го уровня), то приведу цитату из первоисточника :
"Здесь хорошо видна характерная особенность задач пятого уровня: к моменту постановки подобных задач средства их решения лежат за пределами современной науки. Не известны те физические эффекты, явления, принципы, на основе которых может быть создан подземоход (а вместе с ним новая отрасль техники - глубинный транспорт).
Условия задачи пятого уровня обычно не содержат прямых указаний на противоречие. Поскольку системы-прототипа нет, то нет и присущих этой системе противоречий. Они возникают в процессе синтеза принципиально новой системы. Предположим, решено обеспечить продвижение подземохода путем расплавления горных пород. Сразу образуется узел сложнейших противоречий: расплавляя окружающие породы, мы облегчаем движение машины, но резко увеличиваем расход энергии, создаем гигантский теплоприток внутрь подземного корабля, затрудняем использование известных навигационных средств, следовательно, лишаем машину управления".
Источник: Г.С. Альтшуллер, "Найти идею" (3-е изд., дополн. - Петрозаводск: Скандинавия, 2003. - С. 49 -54)
Также см. www.altshuller.ru/triz/levels.asp
Успеха!
Именно "техническое"?
Если не выходить за рамки техники, то "да" ("техническое", либо "физическое"). В контексте обсуждения посвященного программированию, мне кажется, за эти рамки выходить не стоит.
Для тех случаев, когда техническое противоречие неочевидно ответ дан выше.
С Уважением,
Мне просто не нравится определение изобретательской задачи как "задачи, содержащей противоречие". Сами же цитируете: "Условия задачи пятого уровня обычно не содержат прямых указаний на противоречие." Да и не только пятого --- ведь отыскание и четкая формулировка противоречия как раз и составляют суть АРИЗ, т. е. противоречие в большинстве задач вовсе не лежит на поверхности. Получается, что определение звучит примерно так: "Изобретательская задача --- это задача, которая содержит такую штуковину, которую мы, основательно покумекав, можем в ней найти". Ну и зачем такое определение? Где его практический смысл?
На мой взгляд определение "ИЗ" как "З, которую неизвестно, как решать" куда проще и понятнее.
Но ведь программа не может иметь технических/физических противоречий. Что тогда понимать под "изобретательской задачей" в программировании?
Лебедев говорит - есть противоречие (!не техническое!) - значит изобретательская, непонятно до конца что делать (слишком общая/незаконченная формулировка) - изобретательская.
Можно конечно взять определение "изобретательской задачи" пятого уровня, но тогда что понимать под "отсутствием прототипа"?
Какими критериями должен руководствоваться человек, желающий прислать свою решенную или нерешенную задачу в картотеку, чтобы определить эта задача изобретательская или неизобретательская, слать ее или не слать. Нужна она Редакции или нет? Редакция принимает только решенные задачи или нерешенные тоже?
Что сделает Редакция с этой картотекой? Что будет в результате?
Вы можете прислать по адресу: sch@triz-ri.ru , а не в Редакцию 5-6 задач, которые были для Вас трудны, однако, относительно которых у Вас нет понимания "изобретательская" задача это или нет.
Если Вам сложно описать эти задачи по предложенному в конце предыдущего сообщения формуляру, опишите по следующему: "Задача - Решение".
После чего Вы получите подробный ответ.
С Уважением,
Если я уже решил задачу - зачем я буду ее присылать? Она уже решенная. И мне без разницы какая она с точки зрения ТРИЗ. Однако если я буду понимать что я посылаю ее Вам для какого-то полезного или нужного дела, и что это принесет какую-то пользу кому-то - я пришлю.
Вобщем наверно не только мне нужно понимание - ради чего что-то делается.
Вы не ответили для чего будет использована картотека примеров. Какую задачу мы решаем? Сформулируете?
И возможно общими усилиями мы быстрее достигнем результата.
Вы спросили здесь и выше о том,что такое изобретательская задача.
Я попробовал Вам ответить на Ваш вопрос. Для этого привел не только "точку зрения", но и примеры.
Готов и на Ваших (как решенных, так и не решенных) примерах, а не только своих попробовать это показать.
Такова "мини-задача": честно ответить на Ваш вопрос. Если он Вас, конечно, действительно интересует.
Пока, я думаю, этого достаточно. Ибо, сказано: "Большое пьянство начинается с маленьких рюмок".
С Уважением,
Я действительно спросил что есть "изобретательская задача" Вы привели определение и согласились с тем, что это определение для технических изобретательских задач.
Вам, также как и Кириллу Лебедеву огромное спасибо за примеры.
Но ни Вы, ни Кирилл так и не сказали явно и однозначно по каким критериям программист может увидеть, что он решает изобретательскую задачу.
Из ваших примеров следует, что любая программисткая задача, которая содержит противоречие - это изобретательская задача.
Я правильно Вас понял?
P.S. А причем тут алкоголизм? :-)
Огромное спасибо!
Итак у нас есть единственный (пока?) критерий изобретательской задачи - наличие любого противоречия. Получается есть противоречие -- есть изобретательская задача.
Теперь я попробую научиться формулировать противоречия. Надеюсь Вы мне в этом поможете.
Возьмем ваш пример номер 3.
Каким образом он попал в картотеку:
1. Программист сам сформулировал противоречие. приходит к Вам и говорит:
- я не могу сделать расчет потому что "Необходимо изменить каждую запись по сложному алгоритму, а этот алгоритм невозможно напрямую встроить в запрос на обновление. "
Потом он узнает (сам или от Вас) про Принцип 4.: «Использование Посредника». И ищет как бы ему переложить на свою задачу "принцип посредника", находит и решает задачу. То есть противоречие было сформулировано самостоятельно, и решено благодаря существованию принципа №4.
2. Программист долго сидел и делал, наконец сделал и отдал в картотеку приведенный пример как решение изобретательской задачи в процессе написания программы.
Как было дело? Кто формулировал противоречие?
Его нужно было сформулировать потому, что без формулировки противоречия задача осталась бы нерешенной или его нужно было сформулировать чтобы задача стала изобретательской?
Почему я это спрашиваю: имея решенную задачу можно найти в ТРИЗ прием и сказать, что эту задачу можно было решить с помощью вот этого приема.
Так вот, имея на руках: "Как мне изменить значение поля SUMMA в каждой записи по заданной сложной формуле, есле эта формула должна содержать цикл, а в команде UPDATE цикл не напишешь, а я кроме команды Update и SELECT больше больше (пока) ничего не знаю"
Какие шаги я должен выполнить чтобы: сформулировать из вот этого противоречия другое противоречие.
Можно взять любой другой пример. Возможно этот слишком примитивен. Суть одна: есть предельно точно сформулированное противоречие. По какому алгоритму я должен прийти к противоречию, имея которое а могу зайти в ТИПОВЫЕ ПРИЕМЫ УСТРАНЕНИЯ ТЕХНИЧЕСКИХ ПРОТИВОРЕЧИЙ
и ТАБЛИЦА ПРИМЕНЕНИЯ ПРИЕМОВ РАЗРЕШЕНИЯ ТЕХНИЧЕСКИХ ПРОТИВОРЕЧИЙ найти там нужное (ПУСТЬ ХОТЯ БЫ ВОБЩЕМ) направление, в котором дальше копать?
Что касается Примера 3. Реально дело обстояло следующим образом.
Программист, работая над базой, действительно "залип" на нескольких задачах (то есть, превысил нормативное время их решения). Поэтому я вынужден был подключиться. Вы лучше меня знаете, что в такие моменты надо проявлять настойчивость и требовать формализации задачи. Иначе дело уйдет в "долгий ящик" (то есть, в гроб).
Я дал требование сформулировать:
а. в виде противоречия - это получилось несложно, ибо он подробно рассказывал "почему невозможно";
б. без терминов.
Сейчас трудно сказать, кто формулировал на самом деле (я или он), поскольку был диалог, к тому же, программист упирался и спрашивал: "Зачем это надо?". Принцип посредника подсказал я. После реализации пример попал в картотеку. Аналогично было и с задачей про "упрощение запроса" (введение веса) и др.
Однако хочу обратить Ваше внимание, что это частный случай. Он ничего не доказывает и ничего не опровергает. Важно иметь много таких задач и тогда можно сделать формализованную процедуру (не сводящуюся к тому, как это было "у Сычева", "у Иванова", "У Сидорова", а универсальную), о которой, судя по всему, Вы и пишете. Замечу, что для создания таблицы приемов устранения ТП Г.С. Альтшуллеру потребовались годы работы в патентной библиотеке (это и есть первичная картотека ТРИЗ).
Как я предполагаю это должно быть сделано? Даже у приведенных выше примеров уже есть правила (приемы), например:
Далее. Нам надо соотнести задачи (типы задач) и приемы. Что должно лежать в основе типизации задач? Могу предположить, что "тип противоречия". Например, противоречия типа "много-мало" решаются такими-то приемами; противоречия типа "сложное - простое" - такими-то...
В очень упрощенном виде в настоящий момент, универсальная процедура (а не "как было в частном случае") могла бы выглядеть так: "Столкнувшись со сложной задачей, программист должен:
шаг 1. Формализовать ее по след. правилам: см. "ПРАВИЛА ФОРМУЛИРОВАНИЯ ПРОТИВОРЕЧИЯ"
шаг 2. Проверить типовое противоречие или нет; если типовое - шаг 3., нет - шаг 4.
шаг 3. См. "ПРАВИЛА ВЫБОРА ПРИЕМА"
шаг 4. Иные инструменты решения (тоже есть, и корни их тоже из ТРИЗ, но сейчас преждевременно об этом говорить)
Иными словами, надо написать ТРИЗ-приложение для решения задач программирования.
С Уважением,
Уважаемый Валерий Викторович!
Спасибо за полезную ссылку!
У меня пару студентов занимались как раз похожими делами - составляли типа тезауруса типичных ошибок начинающих программистов.
Имеются ли какие-нибудь публикации у Вас или у Ваших студентов на эту тему? Мне было бы интересно ознакомиться с ними.
С уважением,
Уважаемый Сергей!
1. Типичная ошибка многих исследователей (в том числе, античных и средневековых философов) заключалась в попытке вывести свою новую науку с помощью правил формальной логики из каких-то исходных посылок. В качестве таких посылок выступали научные труды других философов, нормы морали, права, религиозные нормы, типовые представления о здравом смысле, характерные для того времени, единичные факты.
Не смотря на приложенные усилия, науки и/или методики они так и не создали.
Подобная ситуация повторяется и сейчас со многими авторами, замахнувшимися на создание методик креатива в области программирования, рекламы и PR.
Примеры:
Не случайно на заре XVII века Френсис Бэкон в своей работе «Новый органон» предложил иной (индуктивный) подход к созданию науки: выведение закономерностей на основе реальных фактов. И описал приемы сбора таких фактов и правила вывода закономерностей.
2. По причине из п. 1 на начальном этапе исследования (а изучение творческих задач в программировании с позиций ТРИЗ началось сравнительно недавно) невозможно дать точное определение изучаемым понятиям.
«Из науковедения известно: исчерпывающе точные определения вырабатываются в споре ряда научных школ не на "заре" новой науки (дисциплины), а на её "закате"...» (И.Л. Викентьев, Легкость в мыслях обыкновенная…).
Можно назвать лишь критерии понятия (сущности). В случае с изобретением таким критерием является разрешение технического противоречия. Об этом в своих сообщениях Вам хорошо сказал Сергей В. Сычев.
3. Противоречия, скрывающиеся в задачах по программированию, появляются не по воле отдельного программиста и не благодаря его фантазии. Они могут быть сформулированы или не сформулированы программистом, но возникают они благодаря воздействиям совершенно разных факторов:
Перечислю несколько вариантов.
Вариант 1. Противоречия между требованиями разных пользователей: один пользователь предъявляет к программе или части программы одни требования, а другой – другие.
Пример 1. Один пользователь хочет, чтобы программа работала с командной строки, другой желает задавать все необходимые данные с помощью оконного интерфейса.
Пример 2. Один пользователь желает, чтобы программа использовала данные по умолчанию, другой хочет каждый раз задавать их самостоятельно.
Вариант 2. Противоречия между новыми требованиями к программе и ее текущей реализацией.
Пример. Работа с программой для создания земной поверхности (террэйна) производится по следующему алгоритму. Сначала дизайнер добавляет в стек модификаторы (модули, отвечающие за какую-нибудь отдельную операцию: триангуляцию, текстурирование, выравнивание и т.д.). Затем он применяет стек модификаторов и получает террэйн.
В процессе работы с программой выяснилось для улучшения качества террэйна некоторые операции, выполняемые модификаторами, нужно разбить на две части, и одну часть выполнять, скажем, в начале, а другую – в конце (после выполнения других операций).
Изменять принцип действия программы нельзя. Во-первых, на это нет времени. Во-вторых, нельзя трогать проекты уже существующих террэйнов. Некоторые из них содержат десятки, а то и сотни модификаторов.
Вариант 3. Противоречия между стилем программирования, принятым в фирме, и требованиями пользователя.
Пример. В приведенном мною примере про редактор геометрических фигур (см. предыдущее сообщение) необходимо в каждый из обработчиков мышиных сообщений вставить код, специфичный для каждого из четырех режимов редактирования.
Согласно правилам Компании «никакая функция не должна содержать код, специфичный для двух и более сущностей» (в данном случае – режимов редактирования), и «необходимо добиваться, чтобы внесение/редактирование/удаление сущности было локализовано в одном месте (файле, классе, функции)».
Таким образом, правила написания исходного кода вступили в противоречие заданием. И это противоречие было разрешено.
4. В упомянутой книге Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. «Приемы объектно-ориентированного проектирования. Паттерны проектирования» отсутствует ряд вещей, необходимых для практического применение «шаблонов проектирования».
К этим вещам относятся:
· Сводный указатель применения шаблонов проектирования по модели «Задача – Шаблон».
· Методика постановки задачи – алгоритм, который бы позволял переводить проблему (изобретательскую ситуацию – термин Г.С. Альтшуллера) в задачу.
· Разбиение задач на уровни.
Спасибо за полезную ссылку!
С уважением,
Уважаемые коллеги!
К сожалению, я вышел на этот форум только сегодня (11/12/2003), поэтому моя реплика несколько отстала от жизни, но всё же.
Прошу оценить мою статью "Законы развития технических систем и программное обеспечение" (http://cie.ase.md/~sereda/os_devel.htm).
Хотя она и не посвящена именно программированию, но в тему обсуждения вписываться должна. (Кстати, редакция сайта http://www.triz.minsk.by [ныне www.trizminsk.org] зарубила статью на корню без каких бы то ни было комментариев...)
P.S. Если вспомнить о том, что изобретения (ради которых, собственно и создавалась ТРИЗ) делятся по уровням, то я бы квалифицировал уровень задач программирования как 1-2, т.е. при программировании решаются задачи техники, но не технологии.
Задачи усложняются при переходе от разработки программного кода к разработке технологий обработки данных.
С уважением,
Сергей Середа
Движение "ПОтребитель"
Уважаемый Сергей,
Попытался зайти по указанной Вами ссылке http://cie.ase.md/~sereda/os_devel.htm, но она почему-то не работает... Нашел названную Вами статью по адресу http://consumer.nm.ru/os_devel.htm и ознакомился с ней. Впечатления:
- да, действительно операционные системы развиваются по принципам ЗРТС.
- конкретные достоинства конкретных ОС вопрос уж очень избитый и спорный.
- обращаю Ваше внимание, что реальное развитие ОС подчиняется еще и законам рынка, кроме того тесно взаимосвязано с развитием железа...
Ваш Яков.
Уважаемый коллеги!
Вышла новая книга, посвященная решению задач при модификации существующего кода. Все интересующимся программированием и технологиями программирования рекомендую ее прочитать:
С уважением,Интересующимся "рефэкторингом", по-русски - упорядочением и оптимизацией программного кода на ЯВУ, могу посоветовать перед тратами на книгу воспользоваться одним из сервисов Сети сетей, а именно поисковым.
Задав, например, поисковый критерий \'code + refactoring\' поисковику google, можно получить значительное количество ссылок на полезные ресурсы (разумеется, если задавать критерий поиска на английском, то в ответ текстов на русском не получишь), в частности, следующие ссылки:
www.refactoring.com
http://jerry.cs.uiuc.edu/~garrido/CRefactory.html
http://www.perl.com/lpt/a/2003/10/09/refactoring.html
http://www.cs.usfca.edu/~parrt/course/601/lectures/refactoring/refactoring.html
http://www.caetano.com/richard/Articles/fog0000000033.html
Тем, кто не владеет английским, могу советовать поискать материалы, задав критерий поиска на русском языке. Что-то вроде
\'рефакторинг || рефэкторинг || "оптимизация кода" || "Мартин Фоулер" || "Мартин Фаулер"\'.
Если информации в найденных данных будет недостаточно, тогда уж придётся тратить деньги на книгу.
С уважением,
Сергей Середа
Движение "ПОтребитель"
(http://consumer.nm.ru v http://cie.ase.md/~sereda/)
Очень интересное обсуждение ! Особенно фраза :
........А, например, если Вы поставите себе задачу создать такую систему, чтобы скорость загрузки страницы сайта в принципе не зависела бы от ее размера (и байт, и гигабайт "грузились" бы с одинаковой скоростью - быстро, мгновенно... причем, даже по самому узкому каналу)", то это будет изобретательская задача пятого уровня. То есть, противоречия, которые придется преодолеть, будут "покруче". Не факт, но не исключено и то, что для решения задачи такого уровня надо выйти за рамки собственной специальности.........
Уважаемые Коллеги!
Появился первый материал (из серии...), посвященный применению ТРИЗ в программировании.
Уважаемые Коллеги!
В этих материалах задачи, изложенные ранее в статье С.В. Сычев, К.А. Лебедев "Как вспомнить "и так известное" , разобраны иным способом.
Спасибо,
Уважаемые Коллеги!
Спасибо,
Уважаемые Коллеги!
Появился еще один материал С.В. Сычева и К.А. Лебедева, посвященный креативу и программированию:
Спасибо,
Действительно, создать качественную программу "из объектов", двигаясь "снизу вверх" (от подсистем к системе; от реализации к проекту), можно только при условии предельной простоты такой программы.
Однако, похоже, существует инерция мышления, оставшаяся с тех времен, когда все писали на низком уровне, и мысли о реализации неизбежно занимали наибольший промежуток времени. И многие программисты (конечно, не все) часто думают "снизу вверх". Больше над реализацией, чем над проектом.
Но, например, хороший архитектор никогда не проектирует дом "из квартир", а думает о нем сразу "в целом", "вписывает" в контекст окружающей среды, пользуется знаниями о готовых "стилях" (или создает свой стиль, зная о других). Хороший авиаконструктор не проектирует новый самолет "из его элементов", но пытается понять, как машина "летает в целом", или отталкивается от "принципов полета этого класса машин" и т.д., и т.п.
Мышление "снизу вверх" сродни попытке сложить организм из атомов углерода и водорода. Теоретически так сделать можно, но очень уж "многофакторно" и затратно как по времени, так и по ресурсам. И все равно, несмотря на затраты и при квалифицированной работе, получится урод + "теория неизбежности ошибок" вместо качественного продукта. За исключением, может быть, тех случаев, когда "организмом" (перепутав термины) назвали что-то предельно простое (например, 1 звено СН).
Эта парадигма создавалась из утилитарного стремления к идеалу, как в управленческом, так и в тризовском смысле. Формулировки идеальности (которые соответствуют по духу и замыслу тем, что сформулировал Генрих Альтшуллер, создавая ТРИЗ, и которые продвигали эту разработку) следующие:
1) Идеально - это когда программу сможет в отсутствие Автора не только сопровождать, но и развивать программист с меньшей квалификацией, чем Автор программы.
2) Идеально - когда добавление новой функциональности в программу не потребует внесения изменений и/или добавлений в программный код (более того, в совершенно идеальной программе увеличение функциональности приводит к сокращению кода); причём всё это без ущерба для любых параметров (например, быстродействия и т.д.).
И чтобы программы писались настолько быстро и сопровождались настолько просто, что их создание и сопровождение можно было бы поручить детям. А взрослые и умные специалисты пусть бы занялись чем-нибудь великим.
Один раз решили научить тупого молоть уголь и рисовать угольной крошкой по трафаретам на поверхностях и чуть не наломали дров. Сначала научили тупого рисовать углем "бабушку" на "окошке". Для этого, велели ему:
Кто придумал такую тупую инструкцию вспомнить уже невозможно — так, что материться глупо — надо работать. Поэтому с помощью воплей, дубины, «соцпакета» и 10-ти тупых администраторов кое-как упомянутый художественный результат достигался.
Причем 10 тупых администраторов периодически посещали семинары по мотивации тупых, где их учили более правильным "соцпакетам", в результате применения которых тупой должен был бы "раскрыться" и стать Личностью. А уж Личность смогла бы рисовать не только бабушек, но и птичек.
Однако, в связи с развитием рыночных отношений, задание усложнилось.
Сразу начнем с сути дела. Существует некий язык записи сути задачи. Если его применять, то сложные (креативные) задачи решать становится удобнее.
Как и любая модель, эта модель тоже жизнь собой не заменяет, однако авторы статьи попробовали и убедились в том, что действительно удобно. Хотя поначалу кажется непривычным… Впрочем, авторы, уважая время Коллег, постеснялись бы писать о привычном, знакомом, общеизвестном.
Рассмотрим серию примеров. Пока намеренно несложных. (Более сложные мы в дальнейшем тоже рассмотрим).
Для решения некоторых задач программирования в качестве "инструмента", облегчающего разработчику абстрагирование от конкретики, предлагается использовать "абсолютно тупого героя", которому поручается некая деятельность. Поскольку этот герой непроходимо туп (мы даже пишем его с маленькой буквы, чтобы и тени величия в нем не наблюдалось), то задача поручить ему деятельность, которая, тем не менее, должна быть выполнена — нетривиальна.
Тем не менее, надо описать решение так, чтобы тупой (несколько тупых) смогли качественно и незатратно порученную задачу выполнить.
Остальное понятно из контекста разбираемых примеров:
Данная закономерность была сформулирована автором в 1993 году в Иркутске. Ряд фактов уже тогда давали возможность построить модель, которую, тем не менее, нужно было проверять в течение долгого времени. Последующие 13 лет позволили сделать ряд обобщений, подтвердивших изначальную гипотезу. И в 2006 году автор счёл возможным первую версию закономерности опубликовать открыто.
Летом 2013 года публикуется версия 2.0 - более полная, развернутая и содержащая одно существенное методическое отличие от первой версии.
Автор будет признателен Коллегам, которые найдут "узкие места" данной работы и направят автору критические замечания и/или примеры, как подтверждающие, так и опровергающие положения изложенные в материале.
В материале приведен список основной литературы по ТРИЗ.
В разные годы издавались и другие книги (как правило, меньшим тиражом) других авторов. Но мы рекомендуем начинать знакомство именно с классики ТРИЗ - книг Г.С. Альтшуллера. Как правило, найти эти книги можно в крупных библиотеках.
Данная закономерность была сформулирована автором в 1993 году в Иркутске. Ряд фактов уже тогда позволил построить модель, которую, тем не менее, нужно было проверить… Последующие 13 лет позволили сделать ряд обобщений, подтвердивших изначальную гипотезу.
Материал публикуется с некоторыми сокращениями и в то же время – с небольшими дополнениями.
Два великих человека радикально высказались об оптимизации: "Единственный способ оптимизировать затратный проект – это его закрыть" (Питер Друкер) и "Идеальная система - та, которой нет, а функции ее выполняются" (Генрих Альтшуллер).
Этот материал посвящен (основанным на ТРИЗ) приемам сокращения работ при сохранении и улучшении их результатов. В этой части работы вслед за классиками сформулируем: "Лучшая работа – та, которую делать не надо, но результат ее получается".
Фрагмент выступления Сергея Сычёва на ежегодном TRIZ-RI ФОРУМе
"Открытые бизнес-методики и технологии",
Москва, 27 сентября 2011 г.
Фрагмент выступления 08 апреля 2014 года на конференции "Открытые бизнес-методики и технологии", г. Ростов-на-Дону
24 сентября 1998 г. умер великий человек. Генрих Саулович Альтшуллер, создатель и первый разработчик ТРИЗ - теории решения изобретательских задач, приемов развития творческого воображения, ЖСТЛ - жизненной стратегии творческой личности.
Уже сейчас ясно: это наука следующего тысячелетия. И нам будет трудно объяснить внукам, почему власть и электорат, начальники и ученые, спец. органы и педагоги так боялись новой науки в веке уходящем... Наверное потому, что ТРИЗ и ЖСТЛ меняют мышление, а значит и жизнь. Генрих Саулович считал, что человек должен прожить ее Достойно - на пределе своих возможностей. И он позволил себе так жить. Возможно, наши внуки окажутся сильнее нас...
И.Л. Викентьев
Часто бывает так: людей на работу взяли, а дело не движется. Звонков мало, заявок еще меньше, клиентская база тает… И не только в отделе продаж.
А Вы возьмите к себе "на работу" наших специалистов.
Каждый из нас имеет более чем 20-летний опыт практического внедрения системы управления предприятием, администрирования бизнес-процессов в отделах: активных продаж, закупки (снабжения), продвижения, складском хозяйстве, бухгалтерии, IT и пр.
С нашим приходом на предприятие уже через короткое время процессы управления организацией начинают работать как хорошо отлаженный механизм. А штатные сотрудники привыкают выполнять свои функции.
Если Вы бываете в Европе по делам бизнеса или с частными целями, найдите время заехать к нам в Прагу. На консультацию, на стажировку, на деловой завтрак. За свежими идеями, за новыми методиками, за иной обстановкой и за иными возможностями.
В Праге Вас встретят наши лучшие эксперты. Мы предложим Вам качественные программы бизнес-обучения по-европейски. В том числе, сделанные "под Вас". В том формате, в каком удобно Вам.
"ТРИЗ" - Теория Решения Изобретательских Задач – самая сильная, на сегодняшний день, система создания новых идей и изобретений известна во многих странах: Германии, Великобритании, США, Швеции, Франции, Японии, Корее, Израиле, Вьетнаме, Испании, Финляндии, Канаде и др.
Книги автора ТРИЗ Генриха Альтшуллера [15.10.1926 - 24.09.1998] переведены на десятки иностранных языков. Большинство успешных компаний активно используют её для совершенствования своих товаров и услуг.