От проблемы к требованиям. Теория принятия решений в разработке ПО

    Введение


    Некоторое время назад обратил свое внимание на артефакт Концепция продукта (product vision) методологии разработки программного обеcпечения RUP (Rational Unified Process) и обнаружил, что отправной точкой разработки программного продукта является выявление проблемы, на решение которой нацелен продукт.

    Аналогичный подход существует и в отечественной практике – так в ГОСТ 34.601-90 говорится, что на стадии Формирование требований к АС (автоматизированной системе) производится «выявление проблем, решение которых возможно средствами автоматизации».

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

    Общая характеристика процесса принятия решений


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

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

    С чего начинается родина решение?

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

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

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

    Цель

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

    Задача

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

    Операция и решение

    Когда перечень задач определился, ЛПР приступает к формированию целенаправленной деятельности организации по достижению цели. Целенаправленная деятельность комплекса мероприятий, осуществляемых ЛПР в интересах достижения намеченной цели носит название — операция.

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


    Рисунок 1. Типовой процесс управления организацией

    Оценка эффективности управленческого решения

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

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

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

    Природа требований к программному продукту


    Какая задача – такое и решение

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

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

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

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

    Что такое требование?

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

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

    Уровни требований

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


    Рисунок 2. Процесс создания автоматизированной системы

    Потребность

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

    Функция

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

    Программное требование

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

    Оценка эффективности программного решения

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

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

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

    Почему так получается?

    Кто виноват и что делать?


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


    Рисунок 3. Искажение требований

    На рисунке 3 показан пример процесса, в ходе которого возникают искажения. Когда ЛПР осознал проблему и сформулировал цель деятельности по ее устранению он доводит перечень задач (T0) до исполнителей — персонала организации. Допустим, что именно эти исполнители будут использовать разработанный позднее программный продукт, т.е. они будут являться его пользователями. Каждый из них по-своему понимает поставленную ему задачу и при формулировании требований к программному продукту исходит из своих предположений (T1).

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

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

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

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


    Рисунок 4. Соотнесение требований с проблемой

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

    Как этого добиться?

    Определение проблемы

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

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

    Элемент Описание
    Проблема [описание проблемы]
    воздействует на [перечень сторон, на которых оказывает влияние данная проблема]
    результатом чего является [описание воздействия данной проблемы на заинтересованных лиц и\или бизнес-деятельность]
    Выигрыш от [описание предлагаемого решения]
    Может состоять в следующем: [перечень основных преимуществ, представляемых решением]


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

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




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

    Заключение


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

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

    В исследовании компании Standish Group International, результаты которого отражены в документе The CHAOS Chronicles 2013, ключевыми факторами успешности программного проекта названы:
    • вовлечение в проект заинтересованных лиц (Executive management support) — 20%;
    • привлечение конечного пользователя (User involvement) — 15%;
    • управление масштабом проекта (Optimazation) — 15%.

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

    ***

    Все вышесказанное подтверждает аксиому, что программные продукты создаются для пользователей. Ориентация на проблемы заинтересованных лиц и потребности реального (конечного) пользователя является залогом успешности проекта по разработке программного обеспечения. Уже на начальном этапе проекта пользователь должен быть привлечен к работе, как результат этого — определение проблемы (problem statement) и концепция продукта (product vision) должны показывать, что команда проекта ясно осознает решаемую проблему, понимает потребности пользователей и готова их удовлетворить.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 19

      +1
      Концепция по ГОСТУ и Vision — это не совсем одно и то же. Точнее, совсем не одно и то же. Я об этом даже писал как-то (см. «Ловушка вторая»):
      www.webursitet.ru/article/terminologicheskie-lovushki-gost-34.html

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


      imho при внедрении любой новой системы нет ничего сложнее, чем изменение бизнес-процесса в организации. Бизнес-процесс — это поведение людей, и больше всего сил уходит на то, чтобы его изменить.

      Подстроить бизнес-процесс под инструмент можно сравнительно легко только там, где этот инструмент даёт явные преимущества всем его участникам. Например, если вы внедряете АБС в банке, в котором до сих работают только с экселем, то вас наверняка встретят с распростёртыми объятиями (правда, таких банков уже не осталось). А вот при попытке поменять одну АБС на другую вы наткнётесь на жёсткое сопротивление пользователей на всех уровнях: процессы уже устоялись, и поменять их можно только боем, с кровью и потерями.
        0
        Концепция по ГОСТУ и Vision — это не совсем одно и то же. Точнее, совсем не одно и то же.

        Greesha, я не ставил в один ряд ГОСТ и Vision, а лишь сказал, что оба указанных подхода отталкиваются от Проблемы.

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

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

        Был в моей практике пример, когда в организации заменялась информационная система. Так пользователи просто отказывались работать в старой системе, видя как их коллеги работают в новой.

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

        Еще чуть-чуть — и диссер :)
          0
          Какой диссер? Это пересказ пары глав из книжек про требования.
          0
          о, какую редкую и интересную тему вы затронули!

          Хочу предложить пару дополнений:

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

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

          Поэтому хочу предложить ещё несколько терминов и компонентов модели для ситуационного анализа, кроме проблем:
          1. Собственно Ситуация — совокупность контекста, действующих лиц, их интересов, фактов, проблем, причин и последствий.
          2. Факт — некоторое существенное обстоятельство реальности, единичное или систематическое.
          3. Причина — вид факта, который порождает проблему.
          4. Последствие — вид факта, который порождается фактом-проблемой.
          5. Проблема — вид факта, который порождает последствия, наносящие ущерб ЗЛ (деньги, время, репутация, здоровье, мотивация, настроение).

          Почему я предлагаю понимать проблему именно так?

          Потому что иначе в качестве проблемы берётся, например «У нас нет CRM». И в парадигме «проблема — это разница между желаемым и существующим» (которая мне тоже раньше нравилась) получается всё формально корректно:
          * Текущее состояние — CRM нет
          * Целевое состояние — CRM есть.

          И всё, поехали в качестве результата и цели проекта ставить «Внедрить CRM» со всеми вытекающими :)

          А если проанализировать последствия того, что CRM нет, то можно обнаружить много интересного и выйти на реальные проблемы, типа «потери клиентов» и т.д. И увидеть, что отсутствие CRM является не единственной возможной «причиной», а есть ещё и отсутствие правил работы, конфликт интересов сейла и руководства и т.д.
            0
            Да, в нашей культуре слово «проблема» носит исключительно негативную окраску, равно как и слово «конфликт», например. Но это очень узкое понимание термина.

            Потому что иначе в качестве проблемы берётся, например «У нас нет CRM»

            В статье сказано, что наличие или отсутствие автомитизированной системы не может являться проблемой — это предположение заинтересованного лица о том, что операция по ее внедрению изменит сложившуюся на предприятии ситуацию. Какую ситуацию? Выяснить это и является задачей проектной команды (в частности, аналитика) и потом внедрить не просто CRM, а CRM с требуемой функциональностью.
              0
              В каком именно месте это сказано?

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

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

                Как именно найти настоящую проблему?

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

            Недостаточное вовлечение пользователей и менеджмента, например — это недостаточное вовлечение. А требования — это требования.

            С ежедневными итерациями (общаемся с пользователями и топами утром и вечером), например, можно создать ПО/систему и без всяких требований.
              0
              beskov, а разве общение с пользователями и менеджерами (топами) не порождает требования?
                0
                Агилисты, например, считают, что нет. И мне эта точка зрения импонирует.

                В некоторых подходах считается, что пользователи и менеджеры описывают проблему, а команда проекта создаёт набор решений этих проблем. Но ничто из этого не называется «требованием».
                  0
                  «Считается» — очень подходящее слово. На деле же оказывается иначе — пользователи и менеджеры формулируют свои пожелания к поведению программы, а команда проекта сначала выясняет чем поможет пользователям требуемое поведение, а уже потом предлагает соответствующее программное.
                    0
                    Я не увидел, в чём разница.
                      0
                      А разница в том, что зачастую пользователи не могут сформулировать решаемую проблему и необходимо вместе с ними к ней придти, а уже потом решать.
                        0
                        Ну а для этого уже и существует роль аналитика/product owner, как посредника между ними, чтобы вернуть первых от разговора про требования и кнопочки к разговору про ситуацию, проблемы, результаты.

                        Пользователи же описывают свои потребности не сами по себе, в виде «заполните бриф».
                          0
                          И мы вернулись к посылу статьи — выясняй проблему, потом делай! ))
              +1
              Ловлю себя на мысли, что представленный план довольно статичен. То есть принимается как аксиома неизменность потребностей пользователей и уровня владением созданным инструментом. В моем опыте, довольно большое количество проблем решается более глубоким знакомством с используемыми инструментами работы. Конечно, для произведения действия необходимо зафиксировать стабильный уровень опытности пользователей, но очевидно, что его необходимо регулярно пересматривать и приводить в соответствие инструменты-уровень владения.

              Кроме того, мне неясен критерий необходимости автоматизации против оптимизации бизнес-процесса (подскажите, может быть не увидел). Можно было бы например рассматривать выигрыш от переложения рутинной работы на автомат и снижение числа человеческих ошибок, но обычно это еще труднее оценить.
                0
                Александр, судя по этой статье и вашим ответам в комментариях, вы упорно пытаетесь изобрести велосипед, а точнее даже собрать нечто велосипедообразное из фрагментов конструкций, подсмотренных у других «изобретателей».

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

                В частности, стратегическое и тактическое проектное планирование, фокусирующееся на эффекте (читай: решении проблем и реализации возможностей), в последние годы находит всё большее распространение в ИТ сфере под эгидой техники «Карт влияния» (Impact mapping). Техника заключается в построении ментальных карт (mind maps), отражающих взаимосвязи между целями организации, вовлечёнными (прямо и косвенно) в достижение этих целей людьми, необходимыми изменениями в их поведении и конкретными программно-аппаратно-административными-… мерами/инструментами, необходимыми для воплощения этих изменений в жизнь.

                К сожалению, время сейчас не позволяет, но, если интересно, я могу проработать с помощью этой техники пример с «хранилищем медицинских данных о состоянии здоровья населения». Разница с вашей табличкой будет колоссальная. Хотя даже моя «Карта» всё ещё будет сферическим конём в вакууме, потому что строить её будет всего один человек, который при этом ещё и слабо знаком с вопросом. Мне придётся делать огромное количество предположений относительно каждого из уровней, точно так же, как один ЛПР вынужден делать предположения, как минимум, относительно того, какие реальные изменения в поведении необходимы и какими инструментами они могут быть обеспечены. Все эти знания не могут находиться в голове одного человека (если, конечно, он не гений, которыми человечество, увы, не особенно располагает) и даже при их наличии всё равно остаётся высокая мера неопределённости, связанная с изменчивостью предметной области и мира в целом.

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

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

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое