Паттерны постановки задачи
Иногда культурологам удается озвучить то, что не могут или не хотят выразить инженеры и менеджеры: инструмент значимо влияет на наше поведение, [пред]определяет принимаемые нами решения или, как минимум, задает диапазон возможных выборов.
Принцип, если у вас в руках молоток, то большинство вещей в этом мире представляется вам гвоздями – не только работает, но и преобладает при принятии решений.
Традиционный подход к анализу требований и проектированию информационных систем изначально игнорирует наличие концепций. Причем не важно, о каких именно процессных подходах идет речь: водопаде, итеративном процессе или гибких методологиях. Согласно любому из них в момент старта проекта в нашей пустой голове нет ни малейшего представления об образе будущего решения. Мы постоянно пытаемся убедить себя в существовании процесса проектирования сверху-вниз. Хотя весь практический опыт свидетельствует о успехе противоположного подхода, проектировании снизу-вверх, подборе решений методом поиска среди имеющихся шаблонов (Роберт Гласс «Программирование и конфликты 2.0»).
Что главное в современном медиа-пространстве, какой фактор определяет его: форма контент, его содержание, канал доставки? Главное (по мнению ряда культурологов) в современных медиа это software – набор конструкций и ограничений, в рамках которых медиа создаются, доставляются, потребляются и воспроизводятся. И дело не только в том, кто создает медиа и использует возникающие после этого эффекты – знаменитая фраза Генри Дженкинса: «Если раньше, Большой Брат наблюдал за нами, то теперь мы все наблюдаем за Большим Братом и постоянно следим за тем, что он делает, мы можем его обличать» – а вопрос в самих правил игры и формируемом этими правилами пространстве возможных событий.
Но вернемся к проектированию информационных систем. В большинстве случаев характер постановки задачи уже несет в себе то или иное решение. В зависимости от того, что было в подсознании, делавшего постановку аналитика, мы имеем уже заказ на чайник или заказ на свисток. Перечислю некоторые варианты таких установок.
Пустота. То есть приступая к описанию постановки задачи мы не имеем ни малейшего представления чего хочет заказчик. В методологиях обычно рассматривается именно этот вариант
Инструмент. Это когда заказчик рассказывает трогательную историю о том, что автоматизация позволит ему повысить производительность собственного нелегкого труда
Объектный подход. Мир состоит из объектов (сущностей), которые на основании их атрибутов и отношений надо сгруппировать в набор классов. Классы, к которым относятся объекты предопределены и неизменны, а взаимодействия — это такие же свойства как атрибуты
Процессный подход. Аналитик изначально уверен в том, что окружающая его действительность представляет собой набор действующих лиц, активностей и артефактов (информационных объектов). Действующие лица (роли) в ходе активностей создают и преобразуют некоторые артефакты. Далее, в зависимости от степени перфекционизма в организме, уровня образования и имеющегося опыта мы либо допускаем вариативность процессов, зависимости между различными экземплярами, допустимость изменения алгоритма в ходе исполнения, исчерпаемость используемых ресурсов и многообразие организации данных, либо фигачим form-driven workflow с «бизнес-логикой» в формате BPMN
Сервисный подход. В отличии от предыдущего случая люди не просто перекладывают документы из пустого в порожнее, но и пытаются достичь некоторых целей. Роли делятся на тех, кто является выгодоприобретателем процесса (имеет эти самые цели) и тех, кто способствует их достижению (сторона сервиса). Сценарии делятся на основные, то есть доставляющие ценность и вспомогательные (заказ услуги, поддержка). Появляются каталоги услуги, базы знаний, типовые сценарии и т. п.
Платформы. Поставщики и потребители сервиса свободно взаимодействуют друг с другом поверх определенной структуры вещей и процессов. Поставщики создают свои решения в некотором заданном контексте, что снижает уровень неопределенности и позволяет разделить коммунальные издержки. Смешно читать пресс-релизы компаний с заявлениям, о разработке той или иной новой платформы, по отношению к которой никак не обозначены потенциальные клиенты, возможности поставщиков решений, виды оказываемых и потребляемых услуг.
В общем, если ваша постановка задачи опять напоминает чертеж гайки в трех проекциях, то стоит ли в этом винить заказчика? Многие из них саботируют процесс написания функциональных требований по одной простой причине: аналитик не представляет им достаточных средств для адекватного выражения замысла продукта или услуги. Подумайте на тем, что software можно воспринимать не только как четко обозначенный алгоритм, но и пространство возможностей для деятельности ваших заказчиков – реквизит кооперативной игры в изобретение и коммуникацию.