Разрабатываем бизнес-приложения на основе процессов жизненного цикла бизнес-систем
Привет, я Алекс Степанов — независимый разработчик бизнес-приложений. В настоящее время я также сотрудничаю в роли ИТ-аналитика с топовой федеральной розничной сетью. Но то, о чём я сообщу далее, было получено мною задолго до этого сотрудничества.
Если вам приходилось проектировать ИТ-решения для бизнеса, то никогда не задавались такими вопросами? — Конечно ли вообще пространство вариантов создаваемых ИТ-решений? — И если да, то что определяет границы этого пространства? — И из каких областей, это пространство может состоять? Или говоря другими словами: то, что нашей проектной команде предстоит сделать, имеет вообще объективные разумные границы и счетное количество вариантов реализации? Эти вопросы и ответы на них отделяют ИТ, как ремесло и бизнес, от ИТ, как инженерия и наука. В данной статье я решил поделить с вами некоторой частью своей системы знаний…
Когда я участвовал в проектах разработки, внедрения и сопровождения бизнес-приложений в роли консультанта, аналитика/проектировщика, программиста/кодера и даже специалиста техподдержки, то часто чувствовал дискомфорт, связанный со множеством проектных и технических неопределенностей. В основном это происходило на этапе обработки исходных требований и формирования замысла (образа) ИТ-решения и на этапе его проектирования. Это самые ответственные этапы, ошибка на которых может привести к кратному превышению затрат и времени ИТ-проекта. Корень этих неопределенностей в том, что понять, чего на самом деле хотят бизнес-заказчики часто непросто, а не поняв это достаточно глубоко, возникает целое поле альтернатив, выбрать из которого что-то одно наиболее подходящее еще сложнее.
Высокий уровень ответственности в условиях неопределенности и связанный с этим дискомфорт возникает не из-за того, что вы не имеете четкого плана разработки ИТ-решения — это как раз и есть творческая составляющая профессии («в этом вся соль»), а осознание того, что «мы — заказчик и исполнитель, выбираем единственный путь, но даже не знаем из потенциально какого числа». И вот в какой-то момент я начал искать основу, на которую можно было бы опереться — своего рода парадигму, в рамках которой можно было бы ставить вопросы, применять методы поиска и находить обоснованные решения. Таким образом владеть проектной ситуацией, а как следствие, снизить уровень того самого дискомфорта. И в конечном быть лидером, а не пассивным исполнителем, ведомым неизвестно куда.
От личной мотивации теперь перейдем к проблеме и инструменту. Итак, перед нами задача на разработку бизнес-приложения (а точнее, пока лишь нечетко сформулированная потребность заказчика), и вместе с ней у нас появляются вопросы типа таких: «о каком типе приложения идет речь?», «чем оно будет управлять?», «что пользователям нашего приложения понадобится завтра?», «какие функциональные модули, расширяющие функциональность приложения, нам вероятно придется делать в будущем?», «какая архитектура/структура/паттерны/платформа нам нужна, чтобы все создаваемые в будущем функциональные модули/функции/«фичи» гармонично интегрировались друг с другом?». Как правило, заказчик может сказать вам только про «вчера» и «сегодня». И если вы не будете задаваться похожими вопросами, вы, во-первых, скорее всего сделаете ИТ-решение для «вчера» (к моменту релиза или внедрения «сегодня» точно превратится во «вчера» или «позавчера»), а во-вторых, это будет «одноразовое» приложение, в том смысле, что его придется переделывать, и если не вскорости, то немного погодя, когда будут создаваться дополнения/расширения/новые модули. Я видел много примеров типа «давай лепить то, что нужно сейчас, а потом видно будет», и вот это «слепленное» потом многократно «перелепливается» и доходит до точки невозможного — «нам нужно больше времени, нам нужно больше программистов, нам нужно больше…, больше…, больше…», потом коллапс, и народ разбегается на «новые и хорошо оплачиваемые» проекты. А если коллапс и не наступает, то у построенных таким образом ИТ-решений все равно часто нелегкая судьба в плане их эксплуатации и развития, а вернее, у тех, кому приходится дальше эти решения поддерживать — их стихийно-случайный и ситуативный «жизненный цикл».
Поэтому возможность прогнозировать вероятные направления развития ИТ-решения является ценностью. Особенно если оно строится на объективной основе, а не на мнениях. Это и есть отправная точка для «software engineering».
По мере накопления практики я стал замечать «управленческую» ограниченность (в определяемом далее смысле) вариантов целевых/первичных бизнес-систем — говоря языком кибернетики, объектов управления — функциональных областей, таких как управление финансами, транспортная логистика, производство и хранение товаров, управление персоналом и т.д. Исходя из этого я пытался обнаружить и ограниченность «целесообразных» вариантов обслуживающих/поддерживающих их ИТ-решений; ведь любые бизнес-приложения — суть поддерживающие соответствующую область бизнеса и подчиненные ее целям информационные инструменты/системы. В качестве примера ИТ-решений приведем системы класса MRP/CRP, WMS, CRM/SRM, ERP и т.д.
Хотя для одной и той же целевой системы (управляемого бизнес-объекта/процесса) можно создать произвольное количество формальных вариантов реализаций (экземпляров) ИТ-решений, просто меняя их исходный программный код, эти варианты с точки зрения некого стратегического управления разработкой ПО будут являться тавтологиями. Существенные и ценные вариации, как то алгоритмы расчетов (например, оптимизации планов), также можно рассматривать как отличия ИТ-решений в отдельных компонентах, и с нашей «разрешающей способностью» в данном контексте «не видны» (ИТ-решение, как образно говоря, «агрегат», остается тем же, но с замененной «деталью»). Принципиальным различием в вариантах ИТ-решения являются их информационные сущности (объекты модели), которыми они оперируют, и логика операций над ними (последовательность и правила обработки данных).
Выбранный вариант, является «скелетом» ИТ-решения и определяет всю его дальнейшую «судьбу», так как фиксирует его основные возможности и определяет область применения, приводит к достаточности или ограниченности его применения в будущем, закладывает необходимость переделки или безальтернативность разработки нового ИТ-решения и т.д. Как было сказано вначале, отсутствие стратегического видения (его невозможности) приводит к созданию «одноразового» ИТ-решения, жизненным циклом которого сложно, а, следовательно, дорого управлять.
В своей работе я основываюсь на стандарт ISO/IEC 15288 (ГОСТ Р ИСО/МЭК 15288). Понимание стандарта в данном контексте: создание и развитие любой искусственной системы сводится к управлению тридцатью (в последней редакции стандарта) процессами жизненного цикла (ЖЦ) систем. Хотя у нас нет ничего, что подтверждало бы ограниченность вариантов целевых (предметных) систем, но благодаря стандарту есть уверенность, что любая из них будет представлена (воплощена) в той или иной комбинации процессов ЖЦ систем. Таким образом, полагая, что ИТ-решения являются вспомогательными по отношению к целевым и призваны повышать эффективность их ЖЦ, то можно считать, что любое создаваемое и развиваемое ИТ-решение — это инструмент для повышения эффективности управления процессами ЖЦ целевых систем. Известно количество этих процессов, описана деятельность и результаты каждого из них.
Повторю еще раз, это тонкий ключевой момент: «я не знаю точную конфигурацию бизнес-системы для которой строю свое ИТ-решение, но я знаю, что любая бизнес-система управляется на основе не более, чем тридцати уже известных процессов ее жизненного цикла, значит, любое создаваемое приложение — это инструмент для управления какой-то комбинацией этих процессов». А в этих процессах ЖЦ я уже хорошо разбираюсь (моя трудовая книжка уже в трех томах и пока нет признаков, что не добавятся новые вкладыши). И у меня уже есть высокоуровневые паттерны разработки для каждого из этих процессов (или «паттерн для разработки паттернов»).
Таким образом, я предлагаю методически сводить разработку ИТ-решений не к разработке программных приложений, поддерживающих частные случаи (варианты) целевых систем/объектов управления (представление о которых, как было отмечено выше, на практике всегда сильно «зашумлено» и неполно), а к разработке ИТ-решений для поддержки процессов ЖЦ целевых систем. Независимо от имеющихся ресурсов, краткосрочных проектных целей, проектных методологий и технологий разработки, у лица, контролирующего ЖЦ ИТ-решения будет инвариантная методология для понимания предельных границ развития ИТ-решения и управления промежуточными этапами этого развития.
Ниже несколько слайдов для предлагаемой концепции (из моих выступлений). Эти иллюстрации для своего рода «макро-ИТ-решений», но парадигма распространяется и на любые «малые» бизнес-приложения.
Вы можете написать мне по адресу: erpacademy.ru@gmail.com
