Rose debug info
---------------

product management | маркетинг | психология | аналитика | книги | истории

«Хотя язык, на котором я пишу, был и есть лучший язык тех, на котором они писали» (М. М. Жванецкий)

Позднее Ctrl + ↑

КНИГИ. ДеМарко Том — Deadline. Роман об управлении проектами

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

  1. Если человек не чувствует, что находится в безопасности, он будет противиться переменам.
  2. Перемены необходимы руководителю для успешной работы (наверняка они необходимы и в любой другой деятельности).
  3. Неуверенность заставляет человека избегать риска.
  4. Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.
  5. Человека легко запугать прямыми угрозами, но также можно просто дать ему понять, что при случае с ним могут обойтись грубо и жестоко. Эффект будет таким же.

2. Отрицательная мотивация
Отрицательная мотивация работает в малых объемах.

  1. Угрозы — самый неподходящий вид мотивации, если вас волнует производительность сотрудников.
  2. Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени.
  3. Более того, если люди не справятся, вам придется выполнить свои обещания.

3. Части тела, необходимые для управления проектами

  1. Для руководства нужны сердце, нутро, душа и нюх.
  2. Так что:
    • руководить надо сердцем;
    • чувствовать нутром;
    • вкладывать в команду и проект душу;
    • иметь нюх на всякую ерунду и бессмыслицу.

4. Главнокомандующий на поле битвы, как метафора управления проектами.
К началу сражения работа главнокомандующего уже закончена.
Собеседование и прием на работу.

  1. Чтобы нанять человека на работу, менеджеру необходимы все его способности: сердце, душа, нюх и способность чувствовать нутром (по большей части последнее).
  2. Не пытайтесь нанимать людей в одиночку — гораздо лучше задействовать в этом процессе интуицию двух менеджеров.
  3. Попросите новых членов команды взяться в проекте за ту работу, которую им уже случалось успешно выполнять в прошлом, а прочие амбиции и рост отложить до следующего проекта.
  4. Попросите наводку — тот человек, которого вы выбрали себе в команду, наверняка может посоветовать, кого вам еще следует нанять.
  5. Больше слушайте, меньше говорите.
  6. И все это сработает еще лучше, если вы слегка подтасуете колоду.

5. Повышение производительности

  1. Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность роботы.
  2. Повышение производительности — результат долгосрочных усилий.
  3. Любые средства для повышения производительности, которые обещают немедленный результат, на самом деле не что иное, как «птичье молоко».

Управление рисками

  1. Чтобы управлять проектом, достаточно управлять его рисками.
  2. Создайте список рисков для каждого проекта.
  3. Отслеживайте те риски, которые являются причиной провала проекта, а не только конечные риски.
  4. Оцените вероятность возникновения и стоимость каждого риска.
  5. Для каждого риска определите показатель — симптом, по которому можно определить, что риск превращается в проблему.
  6. Назначьте специального человека для управления рисками, и пусть он не поддерживает девиз «Мы можем все!», который культивирует начальство.
  7. Создайте доступные (возможно, анонимные) каналы для сообщения плохих новостей руководству.

6. Играй в защите

  1. Сокращайте потери.
  2. Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам.
  3. Чем раньше вы прекратите ненужную работу, тем лучше для всего проекта.
  4. Не пытайтесь создавать новые команды без необходимости; поищите в коллективе уже сложившиеся и сработавшиеся команды.
  5. Оставляйте команды работать вместе и после окончания проекта (если они сами того хотят), чтобы у пришедших вам на смену руководителей было меньше проблем с плохо срабатывающимися командами.
  6. Считайте, что команда, которая хочет продолжать работать вместе и дальше, — это одна из основных целей любого проекта.
  7. День, который мы теряем в начале проекта, значит так же много, как и день, потерянный в конце.

7. Моделирование процесса разработки

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

8. Извращенная политика

  1. В любой момент нужно быть готовым отказаться от работы и попросить расчет…
  2. …однако это не означает, что тем самым вы сумеете избежать последствий извращенной политики.
  3. Извращенная политика достанет вас везде, даже в самой здоровой и чистой организации.
  4. Главный признак извращенной политики: во главу угла ставятся личные цели и влияние, а не общие интересы компании.
  5. Это может произойти даже тогда, когда личные цели напрямую противоречат целям организации.
  6. Один из побочных эффектов извращенной политики: иметь хорошо укомплектованную команду становится небезопасно.

9. Сбор метрических данных

  1. Определяйте размер каждого проекта.
  2. Не усердствуйте поначалу с выбором единицы измерения — если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.
  3. Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).
  4. Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.
  5. Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.
  6. Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.
  7. Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.
  8. Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.

Процесс разработки и его улучшение

  1. Хороший процесс разработки и его постоянное улучшение — весьма достойные цели.
  2. Но существуют еще и рабочие цели и задачи: хороший работник сконцентрирует внимание как раз на них, даже если вы его об этом не просили.
  3. Формальные программы, направленные на улучшение существующего процессе разработки, будут дорого стоить команде — и во временном, и в денежном отношении. Даже отдельные усилия по улучшению процесса могут отбросить команду далеко назад. Что касается возможного повышения производительности, то даже если это и произойдет, то едва ли выгоды от этого повышения покроют затраты.
  4. Можно надеяться получить положительный результат от одного какого-нибудь хорошо взвешенного и тщательно выбранного усовершенствования в методике работы. В этом случае оно может покрыть деньги и время, потребовавшиеся на его внедрение.
  5. Попытка внедрить более одного усовершенствования методологии — гиблое дело. Программы, направленные на улучшение многих приемов и навыков (например, переход на следующий уровень СММ), скорее всего приведут к тому, что сроки только увеличатся.
  6. Опасность стандартизированного процесса разработки состоит в том, что за рутинными операциями люди могут не заметить возможность сэкономить время и усилия по разработке проекта.
  7. Что касается чрезмерно больших команд, то там стандартизированный процесс будет неукоснительно соблюдаться до тех пор, пока он позволяет всем чувствовать себя при деле (не важно, с пользой для проекта или нет).

10. Делать работу по-другому

  1. Есть только один способ сократить время на разработку, когда его и без того мало — уменьшить сроки отладки программы.
  2. Проекты с высокой производительностью требуют гораздо меньше времени на отладку и исправление ошибок.
  3. Проекты с высокой производительностью требуют гораздо больше времени на проектирование.

11. Что дает давление сверху

  1. Люди не начнут быстрее соображать, если руководство будет давить на них.
  2. Чем больше сверхурочной работы, тем ниже производительность.
  3. Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда плохо.
  4. Возможно, руководство так любит применять давление, потому что просто не знает, как еще можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся им слишком сложными.
  5. Ужасная догадка: давление и сверхурочная работа призваны решить только одну проблему — сохранить хорошую мину при плохой игре.

12. Сердитый начальник

  1. Злость и неуважение заразительны. Когда высшее руководство демонстрирует злость и неуважение к подчиненным, руководители среднего звена начинают копировать их поведение. Точно так же дети, которых наказывали в детстве, часто впоследствии становятся жестокими родителями.
  2. Неуважение и злоба, по мнению некоторых начальников, должны заставить подчиненных лучше работать. Это типичная политика «кнута и пряника». Но разве когда-нибудь неуважение со стороны начальства приводило к тому, что люди начинали лучше работать?
  3. Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность (а вовсе не признак того, что у него плохие подчиненные).

13. Туманные спецификации

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

14. Конфликт

  1. Проект, в котором участвуют несколько сторон, обязательно столкнется с конфликтом интересов.
  2. Процесс создания и распространения программных систем — прямо-таки рассадник всевозможных конфликтов.
  3. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов.
  4. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением.
  5. Донесите до каждого, что постараетесь учитывать интересы всех участников, и проследите, чтобы так оно и было.
  6. Тяжело договариваться. Гораздо легче выступать посредником.
  7. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника.
  8. Не забывайте: мы находимся по одну сторону баррикад. По другую сторону находится сама проблема.

15. Кто такой катализатор проекта

  1. Существуют люди-катализаторы. Они помогают создать здоровую команду, отношения, боевой дух. Даже если бы они больше ничего не делали (а как правило, они делают куда как много), их роль в проекте остается одной из наиболее важных.
  2. Посредничество — еще одна сфера, в которой люди-катализаторы просто незаменимы. Впрочем, посредничеству можно научиться, это не очень сложно.
  3. Первым шагом к посредничеству должна быть маленькая церемония. Например, можно произнести фразу: «Вы позволите мне попробовать помочь вам решить этот спор?»

16. Человеку свойственно ошибаться

  1. Нам кажется, что самое страшное — не знать чего-то. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.

17. О персонале

  1. Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы — определения архитектуры системы (потому что всем разработчиком надо скорее дать какую-то работу).
  2. Если работу раздать людям и командам еще до того, как завершится стадия дизайна продукта, не получится создать простые и эффективные модели взаимодействия между людьми и рабочими группами.
  3. Это приведет к потере независимости, увеличению числа собраний и совещаний, общему недовольству.
  4. В идеале было бы хорошо сначала набрать маленькую команду, которая создала бы продуманную архитектуру системы, а уже потом, на последнюю, шестую часть времени разработки в эту команду можно было бы добавить новый персонал (который работал бы непосредственно над кодированием).
  5. Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!

18. Проблемы социологии

  1. Собрания должны быть небольшими. Для этого нужно сделать так, чтобы люди не боялись пропускать ненужные им собрания. Самый простой способ — заранее опубликовать повестку дня, а потом всегда строго ее придерживаться.
  2. Каждому проекту нужна какая-то церемония или ритуал.
  3. С помощью церемоний можно концентрировать внимание собравшихся на основных целях и задачах совещания: сократить состав рабочей группы, повысить качество программного кода и т. п.
  4. Защищайте людей от оскорблений и ругани Начальства.
  5. Запомните: в работе страх = гнев. Те руководители, которые любят кричать на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чего-то очень боятся.
  6. Наблюдение: если бы для всех проявление грубости и злости к подчиненным всегда значило бы, что начальник просто боится, то никто из начальников не стал бы так себя вести просто из страха, что его страх станет заметен! (Это, конечно, не решает проблем такого руководителя, но, по крайней мере, оберегает его подчиненных.)

19. О патологической политике (еще раз)

  1. Эту патологию невозможно вылечить снизу.
  2. Не стоит терять время или подвергать себя опасности, чтобы проверить предыдущий постулат на собственном опыте.
  3. Иногда единственным выходом из ситуации становится выжидание. Попробуйте подождать, пока проблема не разрешится сама по себе или пока вы не найдете способ уйти от нее в сторону.
  4. Чудеса, конечно, случаются, но лучше все же на них не рассчитывать.

20. Злоба и скупость

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

21. Основы здравого смысла

  1. У проекта должно быть два срока сдачи — запланированный и желаемый.
  2. Эти сроки должны быть разными.

Интервью в рамках Custdev

1. Общие правила

Правило 1. «Почему? / почему это так важно?»

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

Правило 2. Проблемные и решенческие интервью отличаются

Интервью бывают проблемными (ПИ), в которых мы изучаем боли и потребности респондентов, и решенческими (РИ), в которых мы подтверждаем, что наши решения справляются с потребностями респондентов.

РИ проводим на стадиях:

— MVP на коленке (презентация/чат-бот и т. п.)
— полноценного MVP
— схемы монетизации
— в повседневной работе над развитием продукта

Проверка по РИ важна как при создании продукта, так и при его дальнейшем развитии для того. Она помогает сэкономить деньги и время (тратим 2 недели и 100 тыс. рублей вместо миллионов и месяцев):
— Срок запуска MVP — 6-12 месяцев;
— Ненужные фичи несут в себе минорные баги, на исправление которых уйдут сотни тысяч и миллионы рублей.

Почему возникают риски после того, как проведены проблемные интервью.
— изначально неверно трактовали боли и потребности;
— не передали знания в MVP (потеряли по пути).

Правило 3. Особенности B2B

В интервью B2B стоит понимать, с кем проводить интервью. Если бенефициар только ЛПР — можно ограничиться только им. Если пользователи — то с пользователями и питчинг ЛПР, чтобы тот был в курсе.

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

Вопросы Скрипт Димы Думика:

Опишите, пожалуйста, вашу роль и зону ответственности? Проверяем, действительно ли человек, которого мы интервьюируем является ЛПРом
А кто в вашей компании отвечает за... ? Кто влияет на решения ЛПРа (ЛВР) Если перед вами не ЛПР.

Правило 4. Избегаем ошибок

Ошибки по Фитцатрику:

1. Вопросы про будущее (Заплатишь ли ты, если мы это сделаем).

2. Обобщение (часто, обычно, всегда).

3. Комплименты неискренние. Интервьюируемые хотят отблагодарить интервьюэра.

4. Интервьюировать в одиночку.

2. Что спрашивать на проблемных интервью (ПИ)

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

Вопросы могут быть разные, важно понять:

1. Существует ли потребность в принципе?

Наверно, у вас накапливается большое число тасков. Вам приходится периодически «чистить» канбан-доску?

2. Как сейчас?

Вспомните последний раз, когда это делали — как вы это делали?

С какими сложностями столкнулись?

Вы делаете только так или есть еще варианты?

3. Затраты на потребность

Тут спрашиваем: как часто возникает, сколько на этот тратите времени/денег.

Часто ли этим занимаетесь?

Сколько на это уходит времени/денег?

4. Эмоции, зависимость от потребности

Спрашиваем, нравится ли текущий способ. Что является идеалом

Какую эмоцию вы испытывали в этот момент? Если человек закрыт, приводим собственный опыт или подсказываем: «Это было ужасно? Это было неприятно?»

Оцените эмоцию по 10-балльной шкале. Что для вас 10-ка? Это нужно, чтобы не наслаивать свою оценку на кастомера. Если боль выше 7-ки, мы с ней работаем, если ниже — скорее, не работаем (если у вас продукт в сфере массового B2C, тогда работаем). Важно ответы разных респондентов стоит привести к одной шкале. В восточной Европе люди относятся более скептично, поэтому, «если не громят, то это уже круто».

Что вообще доставляет вам неудобство при решении потребности? С чем приходится справляться каждый день? Вопрос, который заходит в «кэш» собеседника и достаёт его боли. Когда ты говоришь с человеком впервые, он либо говорит, что всё нормально, либо называет 2−3 боли. В процессе интервью потом вскроются и другие, поэтому не стоит ждать от этого вопроса слишком многого сразу.

Что будет, если вы не будете это делать / не сможете решить потребность? Проверяем, сильна ли потребность

Что для вас успех? Как поймете, что вы решили свою потребность классно? Что мешает достигать этого успеха? В b2b так можно выявить OKR/KPI/цели, которые поставил руководитель.

3. Что спрашивать на решенческих интервью (РИ)

На РИ мы показываем на коленке собранный MVP или презентацию.

1. Обязательно обновляем информацию о потребностях и болях клиента

Это нужно для того, чтобы был верный контекст последующего разговора.

2. Показываем решение (презентацию, лендинг), не питчим.

Просим дать обратную связь и думать вслух. Тут приходится сначала выводить на обратную связь (что ты об этом думаешь, что о том). Через 5 минут собеседник уже сам втягивается и сам начинать давать обратную связь. Как правило, больше всего обращают внимание на то, что не нравится и что очень нравится.

3. Получаем оценку

Почему решили воспользоваться? Почему не воспользовались? Если речь про MVP или фичу.

А покажите, как достигли своих целей? Как сделать это (нужные JTBD)?

Какие сильные стороны?

Какие слабые стороны?

Сравните с конкурентами: в чем выигрывает, в чем проигрывает?

Решает ли вашу потребность?

4. Проверяем монетизацию

Сколько вы готовы заплатить? Способы определения: лесенка (называем самую большую цену, называешь самую маленькую и постепенно приходишь к психологически комфортному уровню для клиента), доля от затрат (Есть мнение, что b2b готовы заплатить за решение проблемы 5-20% от экономии затрат при решении этой проблемы; т. е. если автоматический постинг постов экономить 10 тыс. рублей в месяц, комфортная цена сервиса — 500-2000 руб.)

Готовы ли купить сейчас? Почему да или нет?

5. Выжимаем выгоду для себя

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

Готовы купить или подписать соглашение о намерениях? Если дело не в деньгах, просим заплатить социально — рассказать коллегам/друзьям.

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

Если человек тебя не знает, у него включается барьер — лимбическая система квалификации «свой/чужой»:

— исходит ли от тебя угроза;

— ты победитель или неудачник;

— ты союзник или враг

Если ты не преодолел этот барьер в течение первых минут, потом интервью можно не продолжать. Как растопить лед:

1. Улыбнись (зеркальные нейроны застявят собеседника тоже улыбаться)

2. Сделай искренний комплимент. Именно искренний

3. Продемонстрируй формат, что в ходе разговора будут эмоции

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

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

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

5. Поза — открытые руки и больше жестикулируй.

6. Сделай небольшую ошибку — урони ручку, пролей кофе.

7. Возвращай подтверждение получения: «ага, понял», «перефразирование».

8. Подчеркни что-то общее между вами

9. Если ничего не помогает, можно попробовать вывести на отрительные чувства — фрустировать. Например, дать невыполнимую задачу.

10. На встречу одевайся чуть хуже, чем ожидаешь придет респондент.

5. Сигналы

— Если в первой презентации готовы купить 40% (8 респондентов из 20), это хорошо.

— Когда продукт уже есть — если 40% отвечают, насколько они будут разочарованы, если не смогут больше пользоваться продуктом, то это тоже хорошо.

См. также

Книга по кастдеву. Иван Замесин https://zamesin.me/books/custdev/intro

Решенческие интервью: как проверить ценность продуктовой идеи. Иван Замесин https://www.youtube.com/watch?v=1qBcKODd6YE

КНИГИ. Альтшуллер Генрих — Найти идею. Введение в ТРИЗ — теорию решения изобретательских задач. Конспект

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

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

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

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

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

Альтернативные методы

Часто задачи решают методом проб и ошибок. Этот подход лежит в основе цивилизации, но у него серьезные недостатки:
— большой объем затрат;
— проклятие «фильтрации»: инженеры не выполняют часть проб, поскольку уверены в неудаче. А вместе с тем это закрывает дверь решению задач, требующих «диких» идей. Этот эффект подтверждается данными с обучений ТРИЗ: в тестовых задачах профессионалы выбирают консервативные пути решения.

Те же проблемы свойственны и методам интенсификации метода проб и ошибок:

  1. Морфологический метод. Суть метода состоит в построении таблиц по нескольким важнейшим характеристикам системы, которые должны охватить все варианты (например, по одной оси откладывают все возможные формы, по другой — все возможные материалы). Получается большое поле для перебора;
  2. Метод мозгового штурма (процесс генерации идей отделяется от процесса проверки). Группа из 6-8 человек высказывают идеи в непринужденной обстановке. Каждую идею группа старается развить. При этом запрещена критика. Философская основа — теория Фрейда. Этот метод создает условия для прорыва бессознательным тонкой прослойки сознания.
  3. Синектика, как метод улучшения мозгового штурма (разработана Уильямом Гордоном). Отличия подхода заключаются в следующем:
    — обсуждение происходит в «притертых» группах, поэтому есть место критике без потери эффективности;
    — есть роль руководителя группы, который направляет процесс решения задачи по методологии учения;
    — есть два механизма творчества: неоперационные процессы (вдохновление) и операционные (использование различных аналогий)
    — многое зависит от понимания задачи, поэтому стоит перейти от ПКД — проблемы как она дана — к ПКП — проблеме, как она понята.

Пример. ПКД — предложить недорогой экспресс-метод обнаружения мест утечки воздуха в автомобильной шине (для контроля при изготовлении). ПКП — 1) как найти места утечки; 2) как предсказать возможное расположение этих мест; 3) как найти способ самоустранения утечки.

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

Задачи в ТРИЗ

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

Ситуацию легко перевести в максимальную и минимальную задачи. Схема макси-задачи: требуется принципиально новая техническая система для такой-то цели. У мини-задачи иная схема: необходимо сохранить существующую систему, но обеспечить недостающее полезное действие (или убрать имеющееся вредное свойство).

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

Задачи в ТРИЗ делят на пять уровней.

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

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

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

— Четвертый уровень. Синтезируется новая техническая система. Поскольку эта система не содержит технических противоречий, иногда создается впечатление, что изобретение сделано без преодоления ТП. На самом же деле ТП было, однако относилось оно к прототипу — старой технической системе.

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

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

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

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

Это можно представить в виде схемы.

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

Методология ТРИЗ

  1. При решении ситуации необходимо ориентироваться на идеальный конечный результат (ИКР)
  1. Для достижения ИКР следует максимально использовать вещественно-полевые ресурсы (ВПР): воздух, энергию и проч.

Решение ситуации направлено на устранение противоречия. Противоречия бывают:
— технические (ТП) — конфликт между частями или свойствами системы (или «межранговый» конфликт системы с надсистемой, системы с подсистемой). Типовые ТП: вес-прочность, точность-производительность.
— физические (ФП) — конфликт на физическом уровне (элемент должен обладать свойством А и одновременно свойством не-А, чтобы удовлетворять требованиям задачи).

По методологии АРИЗ-85-В этап решения ситуации состоит из девяти частей

  1. Анализ задачи
  2. Анализ модели задачи
  3. Определение ИКР и ФП
  4. Мобилизация и применение ВПР
  5. Применение информационного фонда (картотеки изобретательских решений)
  6. Изменение и/или замена задачи
  7. Анализ способа устранения ФП
  8. Применение полученного ответа
  9. Анализ хода решения
Ранее Ctrl + ↓