Паттерны постановки задачи

4015279Иногда культурологам удается озвучить то, что не могут или не хотят выразить инженеры и менеджеры: инструмент значимо влияет на наше поведение, [пред]определяет принимаемые нами решения или, как минимум, задает диапазон возможных выборов. Принцип: Если у вас в руках молоток, то большинство вещей в этом мире представляется вам гвоздями – не только работает, но и преобладает при принятии решений.

Традиционный подход к анализу требований и проектированию информационных систем изначально игнорирует наличие концепций. Причем не важно, о каких именно процессных подходах идет речь: водопаде, итеративном процессе или гибких методологиях. Согласно любому из них в момент старта проекта в нашей пустой голове нет ни малейшего представления об образе будущего решения. Мы постоянно пытаемся убедить себя в существовании процесса проектирования сверху-вниз. Хотя весь практический опыт свидетельствует о успехе противоположного подхода, проектировании снизу-вверх, подборе решений методом поиска среди имеющихся шаблонов (см. Роберт Гласс “Программирование и конфликты 2.0”).

Прежде чем продолжить я хочу представить вам короткий видеоролик с ПостНауки о новых медиа. Что главное в современном медиа-пространстве, какой фактор определяет его: форма контент, его содержание, канал доставки? Главное (по мнению ряда культурологов) в современных медиа это software – набор конструкций и ограничений, в рамках которых медиа создаются, доставляются, потребляются и воспроизводятся. И дело не только в том, кто создает медиа и использует возникающие после этого эффекты – знаменитая фраза Генри Дженкинса: “Если раньше, Большой Брат наблюдал за нами, то теперь мы все наблюдаем за Большим Братом и постоянно следим за тем, что он делает, мы можем его обличать” – а вопрос в самих правил игры и формируемом этими правилами пространстве возможных событий.

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

  1. Пустота Т.е. приступая к описанию постановки задачи мы не имеем ни малейшего представления чего хочет заказчик.  В методологиях обычно рассматривается именно этот вариант.
  2. Update 14/01/2017 Забыл добавить самый распространенный паттерн – Инструмент. Это когда заказчик рассказывает трогательную историю о том, что автоматизация позволит ему повысить производительность собственного нелегкого труда.
  3. Объектный подход. Мир состоит из объектов (сущностей), которые на основании их атрибутов и отношений надо сгруппировать в набор классов. Классы, к которым отностяся объекты предопределены и неизменны, а взаимодействия – это такие же свойства как атрибуты.
  4. Процессный подход. Аналитик изначально уверен в том, что окружающая его действительность представляет собой набор действующих лиц, активностей и артефактов (информационных объектов). Действующие лица (роли) в ходе активностей создают и преобразуют некоторые артефакты. Далее, в зависимости от степени перфекционизма в организме, уровня образования и имеющегося опыта мы либо допускаем вариативность процессов, зависимости между различными экземплярами, допустимость изменения алгоритма в ходе исполнения, исчерпаемость используемых ресурсов и многообразие организации данных, либо фигачим form-driven workflow с «бизнес-логикой» в формате BPMN
  5. Сервисный подход. В отличии от предыдущего случая люди не просто перекладывают документы из пустого в порожнее, но и пытаются достичь некоторых целей. Роли делятся на тех, кто является выгодоприобретателем процесса (имеет эти самые цели) и тех, кто способствует их достижению (сторона сервиса). Сценарии делятся на основные, т.е. доставляющие ценность и вспомогательные (заказ услуги, поддержка). Появляются каталоги услуги, базы знаний, типовые сценарии и т.п.
  6. Платформы. Поставщики и потребители сервиса свободно взаимодействуют друг с другом поверх определенной структуры вещей и процессов. Поставщики создают свои решения в некотором заданном контексте, что снижает уровень неопределенности и позволяет разделить коммунальные издержки. Смешно читать пресс-релизы компаний с заявлениям, о разработке той или иной новой платформы, по отношению к которой никак не обозначены потенциальные клиенты, возможности поставщиков решений, виды оказываемых и потребляемых услуг.

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

Паттерны постановки задачи: 2 комментария

    1. Главное моё опасение следующее: сейчас цикл “постановка задачи – поиск варианта решения – корректировка постановки …” очень сильно сжимается. Возможно, при проектировании коробочного решения или многопользовательского сервиса, время и ресурсы на оконтуривание problem space найдутся. Может быть ещё в Lean Startup это важно. Но в основном объеме корпоративной практики это вряд ли реализуемо.

      Я уже писал на FB, что мне нравится процесс, озвученный Дмитрием Песковым https://www.facebook.com/mxsmirnov.arch/posts/1023675924402888 про обнаружение и преодоление барьеров внедрения технологий. Мне кажется, мы вступаем в период когда EA должен в большей степени отслеживать 5-7 потенциально прорывных технологий (в основном, коммунального плана, т.е. типа: станут вдруг железные дороги станут популярными, надо вовремя от нашей фабрики узкоколейку к ним протянуть) )и анализировать готовность организации к извлечению выгод из таких технологий.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *