Русский
Русский
English
Статистика
Реклама

Постановка задач

Перевод Трехступенчатый фреймворк для решения проблем

26.06.2020 18:17:05 | Автор: admin


От автора перевода

В компании ВсеИнструменты.ру каждое бизнес-подразделение инициирует проекты, направленные на развитие компании, и те из них, для реализации которых необходимы изменения в IT-системах, приоретизируются и согласовываются совместно с IT. В ходе очередной сессии обсуждения проектов, планируемых на следующий квартал, пришло понимание простой истины: количество проектов всегда кратно больше, чем ресурсов в IT. И из этого следуют два не менее простых вывода.
  1. Мы никогда не сможем взять в работу все проекты, которые хотелось бы.
  2. Нужно научиться правильно их выбирать.



Уверен, что с аналогичными проблемами сталкивается абсолютное большинство продуктовых компаний. В качестве рабочего инструмента для решения этих проблем полезным представляется подход, описанный в статье Ленни Рачитски, product lead Airbnb.

Это был 2012 год, когда наша команда только присоединилась к Airbnb. Перед нами стояла задача создания опыта социальных путешествий для путешественников Airbnb. Мы исходили из того, что они разбросаны по городу, и, если мы упростим им возможность встречаться и делать что-то совместно, путешествия с Airbnb для них станут гораздо содержательнее.

Перенесемся на 6 месяцев позже, когда мы запустили первую версию в Сан-Франциско. Продукт получился великолепным, все прошло как по маслу. Внедрение же было не столь успешным. Мизерный процент путешественников попробовали его. И все бы ничего, но это был совершенно не тот результат, на который мы рассчитывали. Мы пробовали еще не раз, внедряли некоторые усовершенствования, но несколько месяцев спустя завершили этот проект.


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

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



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

  • Шаг 1. Кристаллизация проблемы
  • Шаг 2. Согласование проблемы с командой и стейкхолдерами
  • Шаг 3. Постоянный возврат к проблеме



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

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



Шаг 1. Кристаллизация проблемы


Начните с ответа на эти вопросы о своем проекте.

  • Описание: что это за проект?
  • Проблема: какую проблему он решает?
  • Почему: как мы поняли, что это реальная проблема и ее нужно решать?
  • Успех: как мы узнаем, что проблема решена?
  • Аудитория: для кого мы делаем это?
  • Что это: как будет выглядеть реализация в продукте?

Описание: что это за проект?


Это краткое описание идеи. Люди, читающие его, смогут быстро понять суть. Будьте кратки.

Проблема: какую проблему он решает?


Сама постановка проблемы является настолько основополагающей, что стоит потратить на это дополнительное время. Поразмышляйте о проблеме гипотетически. Какую, по вашему мнению, проблему вы решаете и почему? Вы добавите больше контекста позднее.

Назовем ключевые характеристики правильной постановки проблемы.

  1. Проблема кратка. Цель описать проблему одним предложением. Чем больше вам требуется объяснений, тем менее ясной становится проблема в конечном итоге.
  2. Сфокусирована. У нас есть единственная ясная проблема, которая может быть решена одной командой и в разумные сроки. Часто очень полезно привести несколько примеров других проблем, которые вы НЕ решаете.
  3. Связана с неудовлетворенной потребностью. Сосредоточьтесь на потребностях пользователя или бизнеса. Тут крайне полезно использовать вот этот фреймворк.
  4. Включает ответы на вопрос что и почему. Что идет не так и почему это проблема? Возможно, вам придется вернуться сюда в следующей секции.
  5. Не зависит от решения. Подавляйте в себе желание слишком быстро перейти к решению проблемы.

Хорошие примеры постановки проблемы

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

Плохие примеры постановки проблемы

  • Количество пользователей растет медленно. [Что не так: проблема слишком широка. О стратегии приближения большой картины можно прочитать здесь и здесь. К тому же не учитываются потребности пользователя.]
  • Создать программу лояльности. [Что не так: это решение. Какую проблему мы хотим решить?]
  • Пользователи не доходят до конца регистрации. [Что не так: недостаточная фокусировка, упущена предполагаемая причина. Нужно опуститься на один уровень ниже.]

Почему: как мы поняли, что это реальная проблема и ее нужно решать?


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

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

Несколько советов для этого шага.

  1. Изучите количественные и качественные доказательства. Соберите все данные, которые указывают на то, что это действительно реальная и важная проблема.
  2. Качество важнее количества. От 3 до 5 прямых фактов лучше дюжины косвенных. Во втором случае ваши выводы будут слабее, так как они будут основаны на второстепенных и не имеющих отношения к делу фактах, выглядящих как куча доказательств. Лишний перфекционизм также ни к чему.
  3. Сыграйте сами с собой в адвоката дьявола. Попытайтесь убедить себя, что это совершенно незначимая проблема. Какие пробелы имеются в ваших доказательствах? Действительно ли доказательства соответствуют тому, что вы думаете? Проверьте себя.

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

Успех: как мы узнаем, что проблема решена?


Вы достигли того, что планировали достичь? Как вы узнаете? Ответьте на этот вопрос и запишите ответ.



Этот критерий становится невероятно важен на протяжении всего проекта, так как он помогает принимать решения и расставлять приоритеты. Фича X увеличивает шансы достичь поставленной цели? Если нет, не делаем ее.

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

Несколько советов для определения критериев успеха.

  • Постарайтесь получить конкретное число, например: 10% прирост показателя X; 50% уменьшение показателя Y.
  • Цель должна быть достижима, но амбициозна. Достижение какой цели приведет вашу команду и руководителей в восторг?
  • Если вы не смогли придумать метрику для своей цели (думать нужно долго и напряженно), опишите, как будет выглядеть мир в случае успеха проекта. Сделайте это критерием успеха.

Аудитория: для кого мы делаем это?


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

Что: как будет выглядеть реализация в продукте?


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

Шаг 2. Согласование проблемы с командой и стейкхолдерами


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



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

Я обычно подхожу к этому шагу так.

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

Шаг 3. Постоянный возврат к проблеме


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

image

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

Я помню, как несколько лет назад работал над проектом по созданию админки для хозяев жилья в Airbnb. Изначально мы решали проблему уменьшения времени ответа от хозяина, а именно сокращения времени ответа хозяина на сообщение гостя. Наша гипотеза заключалась в следующем: хозяева отвечали бы быстрее, если бы непрочитанные сообщения им были более заметны. Вдобавок мы напоминали бы им о том, что скорость ответа на сообщения влияет на их поисковый рейтинг. В итоге мы оказались правы. Но на протяжении проекта с ростом его масштаба и сложности я постоянно находил себя напоминающим команде, какую проблему мы должны решить. (Профессиональный совет: админки классическая проблема буррито в фольге.) От размывания фокуса проекта ничто не помогает лучше, чем постоянное возвращение к первоначальной постановке задачи и критериям успеха. Вы можете решить множество проблем множеством способов, но можете также создать прекрасный продукт, который не решает никаких проблем.

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

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

И в заключение


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

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

Марк Менсон. Тонкое искусство пофигизма

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

Очень рекомендую прочитать следующие 5 книг.



  1. Deep Work (Кэл Ньюпорт. В работу с головой. Паттерны успеха от IT-специалиста)
  2. The Subtle Art of Not Giving a F*ck (Марк Менсон. Тонкое искусство пофигизма)
  3. Good Strategy, Bad Strategy (Ричард Румельт. Хорошая стратегия, плохая стратегия. В чем отличие и почему это важно)
  4. Measure What Matters (Джон Дорр: Измеряйте самое важное. Как Google, Intel и другие компании добиваются роста с помощью OKR)
  5. Lean Analytics (На момент написания статьи не переведена на русский)

От автора перевода

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




Взял фреймворк себе на вооружение. Для удобства использования разработал форму для кристаллизации проблем.

Выражаю благодарность нашему журналисту Анисимовой Татьяне и арт-директору Забегалову Алексею за помощь в редактировании и оформлении статьи.
Подробнее..

В чем состоит работа ИТ-аналитика по улучшению бизнес-процессов

21.11.2020 22:12:40 | Автор: admin

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

Что делает ИТ-аналитик и в чем ценность его работы для бизнеса? Пробуем разобраться.

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

Понятия потребность и требование

В анализе и проектировании аналитик работает с двумя областями. Область потребностей = нужд (needs) и область решений (solution).

Закрыть одну потребность можно разными способами. Каждый способ имеет разные атрибуты качества. Поесть в ресторане быстрее и вкуснее, но купить продукты в магазине, приготовить и съесть что-нибудь дома дешевле.

Бизнес обращается к нам с какой-то проблемой, болью, которую он не знает как решить и наша задача - показать ему что делать.

Задача аналитика в поиске и выборе наиболее подходящего для заказчика способа решения (solution) его боли и проблемы.

Выявление потребностей и целеполагание

Пациент приходит к доктору и требует Выпишите мне аспирин, срочно!!!.

Требование = Выписать аспирин. Что делает доктор в данном случае? Плохой доктор даст аспирин. Хороший доктор будет выявлять причины проблемы и лечить их.

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

Требование лежит в области решения (solution). Поесть в ресторане, Приготовь еду - это требования.

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

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

В разное время разные бизнесы стремятся к оптимизации разных атрибутов качества своих систем и процессов.

  1. Обеспечить функциональность

  2. Качественную работу

  3. Скорость/Производительность

  4. Безопасность

  5. Низкие издержки

  6. И т.п.

Разрыв ожиданий и реальности атрибутов качества создает проблему, которую нужно решить, и для этого нужны какие-то изменения. Устранение разрыва будет целью (goal) будущего изменения.

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

Выявление контекста и ограничений

Разумеется заказчик находится в какой-то ситуации и он ограничен принятыми ранее решениями (decision).

Разгрузить грузовик - это сложно? Неясно, так как неясен контекст.

К примеру, Разгрузи грузовик в минус 40, на дне озера и Разгрузи грузовик в плюс 25, на асфальте выглядят как совершенно разные задачи.

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

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

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

  1. Сделать к черной пятнице,

  2. Сделать, потому что каждый день мы что то теряем,

  3. Сделать, иначе с какого-то момента мы будем каждый день что-то терять.

Таким образом выявляются ожидания/ограничения по срокам.

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

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

В итоге, складывается понимание ограничений на проектный треугольник (стоимость/сроки/качество).

Кроме того, область решений (solution) ограничена еще:

  1. Ограничениями по ресурсам

  2. Требованиями удобства пользователей

  3. Решениями по существующему ИТ-ландшафту и уровню ИТ сервиса

  4. Выбором подрядчиков и правилами привлечения новых

  5. Правилами работы с подрядчиками

  6. Требованиями безопасности и распространения информации

  7. Требованиями регуляторов

  8. И т.д.

Не зная ограничения, нельзя спроектировать решение с их учетом.

В случае слишком жестких ограничений решения может и не найтись. Тогда ограничения заменяются функциями штрафа и аналитик ищет наименее болезненное решение.

Проектирование решения

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

Моделей системы может быть несколько (и довольно много), но типовые это

  1. Функциональная модель, отвечающая на вопрос как это работает, функционирует, обеспечивает функцию.

  2. Конструктивная модель, отвечающая на вопрос как это сконструировано, из каких частей состоит.

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

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

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

Аналитик решает задачу по проектированию такого решения, которое закрывает потребности по правилу Парето, 20% усилий должны принести 80% бизнес-результата, где усилия берутся из треугольника (цена-качество-сроки) в рамках выявленных ограничений, а результат - это оценка улучшения атрибутов качества бизнес-процесса.

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

ИТ аналитику в поиске помогают

  • Знание того, как ИТ решают задачи по улучшению процессов,

  • Знание того, какие ключевые свойства потребностей влекут разные способы реализации,

  • Знание готовых ИТ решений, решающих задачу полностью или частично или умения быстро их находить и выбирать оптимальное,

  • Знание предметной области,

  • Знание процессного управления и процессов управления изменениями,

  • Понимание трудоемкости, стоимости и сложности решения широкого спектра ИТ задач,

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

  • Знание того, как ИТ решают задачи по улучшению процессов,

  • Знание того, какие ключевые свойства потребностей влекут разные способы реализации,

  • Знание готовых ИТ решений, решающих задачу полностью или частично или умения быстро их находить и выбирать оптимальное,

  • Знание предметной области,

  • Знание процессного управления и процессов управления изменениями,

  • Понимание трудоемкости, стоимости и сложности решения широкого спектра ИТ задач,

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

  • Знание того, как ИТ решают задачи по улучшению процессов,

  • Знание того, какие ключевые свойства потребностей влекут разные способы реализации,

  • Знание готовых ИТ решений, решающих задачу полностью или частично или умения быстро их находить и выбирать оптимальное,

  • Знание предметной области,

  • Знание процессного управления и процессов управления изменениями,

  • Понимание трудоемкости, стоимости и сложности решения широкого спектра ИТ задач,

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

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

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

Дайте мне аспирин А это вылечит вашу боль?(неизвестно, если причина боли не диагностирована)

Внедрение решения

При проектировании на первых итерациях получается не полнофункциональная ИТ-система. При создании ИТ системы с нуля, как правило, закрывается главная дорога, а исключения и боковые ветви остаются за рамками создаваемого ИТ решения. При внедрении готового решения за рамками остаются процессы, которые туда не ложатся. Для внедрения ИТ-системы нужно выработать подходы, что делать с этими случаями. Либо менять процессы, либо закрывать потребности с помощью более простых и универсальных решений типа Excel (Googledocs, ) и регламентов.

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

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

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

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

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

Резюме

Работа аналитика это превращение проблем в задачи, при котором характерны этапы:

  1. Выявление потребностей и целеполагание,

  2. Выявление контекста и ограничений,

  3. Проектирование решения,

  4. Внедрение решения.

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

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

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

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

P.S. Спасибо участникам КиФБ за отзывы и корректировки к статье

Подробнее..

Постановка задач для универсального интеллекта у нас нет общего языка

21.01.2021 16:23:47 | Автор: admin

Введение или о каком ИИ я говорю

В первую очередь меня интересует универсальный ИИ как машина достижения сложных целей. То есть некий программно-аппаратный комплекс, которому можно сказать: сделай самолёт, который будет стоить 100$, летать на 1000 километров со скоростью 800 км/ч и перевозить 5 человек. Или так: вылечи человека такого-то от рака на терминальной стадии.

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

На данный момент я вижу два пути, как получить универсальный ИИ.

Первый путь - это системы, подобные reinforcement learning. Они подключаются в сенсорам и исполнительным механизмам некоего робота, и ещё у них есть сигнал награды. Reinforcement learning (далее RL) действует так, чтобы получать в среднем как можно больше награды. И канал вознаграждения - это основной способ сообщить ИИ, чего мы от него хотим.

обобщённая схема RLобобщённая схема RL

Второй путь - это системы, подобные GPT-3, генераторы текстов. О них скажу всего пару слов. Они берут начало текста и продлевают - так, чтобы выглядело связно. Часто эти тексты звучат глубоко и здорово, но Если вы спросите GPT-3 почему астрология - это самообман - он подробно это аргументирует. А если спросить его же почему астрология - это реально эффективная практика - наш продлеватель текстов опять же, подробно аргументирует. На вопрос эффективна ли астрология? GPT-3 ответит, исходя из контекста. Эти особенности не позволяют просто в лоб применять GPT-3 и его аналоги для создания хороших планов.

Проблемы с Reinforcement Learning и подобными системами

Я бы разделил проблемы на две большие группы.

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

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

Проблемы данных, памяти и вычислительной мощности

Проблема размерности

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

Проблема решается сжатием картинки в маленький информативный вектор. Есть два основных способа это сделать:

1) Взять готовую нейросеть, умеющую классифицировать изображения на много классов. Отрезать последний слой, взять выход предпоследнего. Там будет вектор размерности ~1000-2000 элементов. Это намного меньше, чем исходная картинка, но этот вектор остаётся очень информативным.

2) Обучить автоэнкодер. Автоэнкодер - это нейросеть, у которой есть узкое место, то есть промежуточный слой малого размера. На вход нейросеть получает кадр, на выходе должна воспроизвести его же. Если отрезать все слои, что идут после узкого места, получится нейронка, создающая из картинки то самое сжатое представление.

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

Проблема опасных исследований

Обычно RL стартует с пустой памятью. Его поведение случайно. Со временем RL накапливает больше данных и обучается управлять условным роботом более-менее сносно. Или так и не обучается - как повезёт.

А теперь представим себе, что мы такой RL поместили в продакшн. На бирже торговать или искать новый способ изготавливать скрепки. Пока RL будет экспериментировать и познавать мир, он допустит множество ошибок, и это серьёзно навредит бизнесу.

Как с этим бороться?

  1. Можно сделать мир-симуляцию, и гонять RL в нём. А лишь потом, когда он научится справляться, выпускать ИИ в реальный мир. Очевидный минус - для некоторых случаев мы не можем сделать симуляцию. Мы сами слишком плохо знаем интересующую нас среду.

    RL эксплуатирует кривую физикуRL эксплуатирует кривую физику
  2. Запустить в среду другого игрока - человека или иную систему управления. Залогировать их действия и передать в RL так, будто это его собственный опыт. Например, человек играет в Doom, игра записывается на видео, все ключевые переменные записываться, все действия записываются. Затем нейросеть в RL учится по кадру с экрана и текущему действию предсказывать, сколько будет награды. Таким образом у RL на момент выхода в мир уже будет какая-то стратегия - теоретически она должна быть не хуже, чем у живого игрока, но на практике это не всегда выполняется. Сигналы подкрепления проставить ретроспективно - мы же этими сигналами хотим гнать ИИ к какому-то результату, значит, у нас есть какое-то правило, по которому входящий кадрназывается "хорошим" или "плохим".

Проблема отдалённой цели

Допустим, мы даём RL задачу: пройти уровень из Doom. Награда даётся только за полное успешное прохождение.

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

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

Но всё равно, люди гораздо быстрее бы поняли, куда идти.

Как решать проблему?

  1. Дать RL человеческий опыт. Или опыт некоего другого бота. Так он хоть поймёт, к чему стремиться.

  2. Сделать несколько миниатюрных уровней, где прямо перед RL находится та самая дверь с переходом на новый уровень. Можно даже просто записать ему в память видео, как кто-то другой проходит такой мини-уровень и получает награду.

  3. Дать подсказку через канал подкрепления: пусть RL получает небольшие награды за подбор предметов и убийства врагов, и небольшие наказания за ранения. Это похоже на то, как человек проходил бы первый шутер в своей жизни - он бы воспринимал аптечки и победы как награды, а ранения - как наказания. Но есть вариант, что RL найдёт какой-то возобновляемый источник наград и вообще не захочет покидать уровень.

    RL зациклился на вспомогательной наградеRL зациклился на вспомогательной награде
  4. Явным образом описать цель: отснять эту дверь с разных ракурсов, получить её сжатое представление. Все кадры проверять на предмет того, насколько они похожи на эту дверь - и давать пропорциональную награду. Таким образом может получиться, что RL станет целенаправленно искать объекты, похожие на дверь с надписью Exit. Недостаток в том, что он может залипнуть на какую-нибудь другую дверь - ну да, степень сходства 5%, но зато можно просто смотреть на дверь и бесконечно получать небольшие награды. Возможно, стоит совместить такое описание цели с эвристикой любопытства - пусть награда от созерцания двери будет пропорциональна и её новизне, и её похожести на Ту Самую Дверь.

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

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

RL, которому подсказывают цельRL, которому подсказывают цель

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

Есть вариант создать много целевых состояний и обучить некую нейросеть отличать целевое состояние от не-целевого. А затем использовать что-то вроде Model-Based подхода. ИИ будет в воображении генерировать траекторию изменений мира - он же знает по прошлому опыту, как изменяются входные кадры, и как на них влияют активные действия. Можно каждому придуманному кадру (или сжатому представлению кадра, или сжатому представлению от цепочки кадров) поставить в соответствие награду. Награду проставляет та самая нейросеть, которая пыталась выучить правило, чем целевые кадры отличаются от не-целевых.

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

Таким образом можно было бы свести реальные эксперименты в физическом мире к массивному перебору в воображении.

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

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

Проблемы на уровне ТЗ

Допустим, мы хотим создать универсальный ИИ, который сможет лечить неоперабельный рак. Допустим так же, что универсальный ИИ мы уже делать умеем - это просто достаточно хороший RL.

Но какое тело мы дадим нашему ИИ? Для RL важно, чтобы было конкретное тело, у которого одни и те же датчики и исполнительные органы в разное время имеют примерно одинаковый смысл. Это означает, что не выйдет сделать его неким просто абстрактным интеллектом, который свободно подключается к любому оборудованию. Не то, чтобы это вообще невозможно - но нейросетям будет очень тяжело обучиться в таком случае.

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

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

Необязательно ставить задачу именно вылечить человека напрямую - можно ставить задачу сделать некий механизм, который вылечит. Или некое лекарство. Впрочем, высокоразвитый RL с богатым опытом и сам понимает эти возможности.

А теперь ключевой вопрос: как сформировать сигнал подкрепления? Как постфактум определить, решена ли задача?

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

Есть другой вариант: если мы хотим ретроспективно оценить, здоров ли пациент, надо за ним наблюдать. Смотреть, насколько он справляется со своими обычными делами, и смотреть, сколько он проживёт. В конце концов, если все анализы показывают, что человек болен, а человек явно ведёт себя как здоровый, не чувствует дискомфорта и доживает до 110 лет - значит, проблема в анализах.

Но как это всё выразить в терминах прямых наблюдений?

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

Это бы сработало, если бы рентген был одним из входных сенсоров, интегрированных в ИИ. Причём даже не сам рентген, а вся процедура, как провести рентгеновский снимок. Если же мы говорим ИИ надо сделать, чтобы снимок выглядел вот так, ИИ может этот снимок нарисовать или снять на рентген что-то постороннее.

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

Можно ли с этим бороться? Можно ли запретить ИИ ослеплять свои приборы?

В какой-то мере. Например, можно обучить нейросеть-ревизора, которая по наблюдаемым кадрам будет проверять, верно ли проходят измерения. Но эту нейросеть можно обмануть, потому что она не дообучается, а RL дообучается постоянно. Можно этого ревизора тоже дообучать - скорее всего, вручную заносить в датасет ситуации, где ИИ всё-таки сумел её обмануть.

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

Ещё есть вариант вынести процедуры контроля за пределы той территории, где ИИ активно работает. ИИ может запросить рентген, но делать его будут люди. В такой ситуации может выйти, что RL сможет хакнуть людей - убедить их совершить подлог, спровоцировать на ошибку или сделать роботов, которые выйдут за пределы цеха и сами неправильно сделают рентген. Будет ли ИИ всё это делать?

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

Наконец, можно создать автоматическую систему контроля, работающую наподобие GAN. ИИ (не именно хирург, а просто какая-то система RL) ищет способы подделать, например, рентгенограмму тестовой мишени. Затем тестовая мишень уезжает за пределы цеха, и её отснимает простенький необучаемый робот. Если результаты тупого робота и умного разошлись - значит, произошёл взлом, и обучаемая нейронка-ревизор добавит этот случай в датасет. А взломщик получит свою награду.

А потом всякий раз, когда RL проводит планирование, его план проверяет ревизор - нет ли там подлога. В данной ситуации хитрого ИИ будет останавливать опытный надсмотрщик, который насмотрелся на не менее хитрого ИИ в контролируемых условиях.

Пару слов об ИИ-безопасности

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

Обычно в таких историях говорится, что ИИ должен быть самоулучшаемый - то есть RL должен уметь влезать в свой код и как-то его улучшать, а потом улучшенный код будет снова улучшать себя. Автору этой статьи не доводилось видеть научных работ по RL, способному к рекурсивному самоулучшению. Рекурсивное самоулучшение чего-то вроде эволюции - это пожалуйста, но эволюция не умеет решать задачи RL.

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

В первую очередь, рекурсивная самоулучшающася система нестабильна. Она может выкрутить размер буфера памяти, например, в такие значения, что ИИ начнёт сильно тормозить.

Он даже не понял, что его убилоОн даже не понял, что его убило

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

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

Другой момент заключается в том, что RL идёт по наиболее очевидному пути. Если есть простой способ достичь цели, система не будет искать сложный. Конечно, сложность выражается во внутренних концепциях RL - например, он может в шутерах разбивать локацию не на дороги и стены, а на теневые и светлые зоны. А противников видеть не как объекты, а как изменения текстуры. За счёт этого стратегии поведения будут не вполне человеческие.

Обратите внимание, что именно лучше всего заметила нейросеть. Тени, светлые зоны, HUD, линию горизонтаОбратите внимание, что именно лучше всего заметила нейросеть. Тени, светлые зоны, HUD, линию горизонта

Так вот, если проще не взламывать защиту, а решать задачу, то ИИ именно этим и займётся. Судя по наблюдениям автора, ИИ гораздо чаще взламывает системы, которые можно взломать чуть-чуть, и это уже принесёт отдачу. Например, однажды автор этой статьи делал ИИ для торговли на бирже. Провёл тестирование на симуляторе биржи и получил странный результат: ИИ научился делать 1000$ из 100$ на интервалах в полчаса. Как? Оказалось, в симуляторе можно брать кредит, и ограничения нет. ИИ стал понемногу наращивать объём кредита, и добрался до десяти миллионов долларов. Покупал на всё акции, потом продавал и возвращал кредит. В случае, если контролирующая система - это нейросеть, она будет давать чуть-чуть разные значения награды за чуть-чуть разные наблюдения. В результате можно, двигаясь малыми шагами, подобрать такие входные данные, на которые нейросеть будет отвечать неоправданно большой наградой. Так что если мы хотим, чтобы нейросеть проверяла, справился ли RL, это должна быть или очень надёжная нейросеть, или она должна дообучаться, получая всё новые примеры хаков, или RL не должен иметь возможности много экспериментировать с ней.

Подводя итоги

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

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

Но это всё, как мы понимаем, не похоже на сингулярность силами одного ИИ.

Я задумывал эту статью как способ спровоцировать диалог. Наверняка я где-то неправ и есть более хитрые решения, чем те, до которых мне удалось додуматься. Так что развёрнутые комментарии и интересные споры приветствуются!

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru