Сергей Тарасов - Дефрагментация мозга. Софтостроение изнутри

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

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

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

Приведу мнение коллеги по проекту, Владимира Иванова, аналитика и руководителя группы разработки бухгалтерской подсистемы. Роль функционального архитектора или, в терминах MSF [107], менеджера продукта он называет просто «маркетолог».

Я попробую сформулировать, что делалось неправильно и какие решения были найдены, их уже удалось применить большей частью в проектах за пределами Ultima-S на базе ее разработки.

Проектированием системы на самом деле должен заниматься не технарь, а маркетолог как Стив Джобс. Система – это товар, удовлетворяющий потребности. Маркетолог может понять потребности рынка, сформулировать требования к товару, может оценить осуществимость маркетинговой компании. На деле технический архитектор нужен маркетологу для оценки себестоимости проекта и его сроков, а также для информации о новых перспективных технологиях, тогда маркетолог сможет искать сочетания «потребность + технология». Проблема проекта Ultima-S и многих других в том, что там не было маркетолога, определяющего вид продукта и программу продвижения, что сделало бессмысленным большое количество технологических действий.

Следуйте совету Джобса: «Обычные художники заимствуют – великие воруют». Для меня, как руководителя группы разработки бухгалтерского модуля, существовала проблема: никто не мог поставить задачу. Системный архитектор был «не совсем в теме», маркетолог со знанием продукта отсутствовал. Но мне в голову пришла удачная идея начать копировать макроязык и систему настроек 1С, одновременно обеспечивая совместимость с объектной моделью Ultima-S. Если бы разработчики Ultima-S, до того как взяться за написание кода, провели тщательное изучение архитектур аналогов на рынке, все было бы иначе. Можно было бы передовую платформу Ultima-S приспособить к куче хороших идей у 1С и «Галактики». Я в то время часто общался с экспертами «Галактики», они серьёзно опасались, что мы именно так и сделаем: реверс-инжиниринг и переписывание в новой технологии. Ресурсы для этого у нас были. Но, увы, сделали только частично, а 1С – это все-таки модель малого бизнеса, тогда как мы целились в сектор Enterprise, где была «Галактика».

Учитесь у лидеров рынка, их успех не от «просто так». Я получил два важных опыта в этом проекте – объектно-реляционное моделирование и проблемно-ориентированные конструкторы, которые популяризовал Нуралиев. Могу сразу сказать: Нуралиев круче. Дело в том, что его функциональная архитектура была следствием изучения потребности рынка и типовых сценариев внедрения. Наш

бухгалтерский модуль из Ultima-S до сих пор живёт и здравствует в нескольких холдингах, которые не раз оценивали миграцию на Axapta, но оставались все равно на нём. Концепция 1С плюс возможность Transact SQL-программирования – мечта многих разработчиков бизнес-решений. Нуралиева много раз просили это сделать, но он держался за свой подход, чтобы поддержать кросс-платформенность [108].