Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

В защиту функциональных рассмотрений целевой системы

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

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

Всё функциональное на верхнем уровне — это обычно из предметной области, и ровно вот этого понимания у айтишников нет, несмотря на победное шествие domain driven design и event storm, несмотря на все попытки привлечь внимание к предметной области, в которой решаются задачи.

И вот уже в архитектуре айтишной системы магазина появляется просто "база данных", а не "цены товарных позиций, правила предоставления скидок, история покупок". Это понятно, что всё это должно где-то храниться, но даже не факт, что в нарисованной айтишником на первой же его диаграмме "базе данных" (часть, например, может браться на API какого-то сервиса, а правила представления скидок могут храниться в настроечном файле или вообще оказаться нейронной сеткой), и не факт, что даже "база данных" будет одна. Объяснить айтишнику это невозможно, ибо он мыслит модулями, которые по его мнению абсолютно универсальны, поддержат "любую функцию" Любую-любую? Нет, конечно. Но разочарование будет не в начале проекта, а поближе к концу -- когда окажется, что универсальных прикладных софтверных систем не бывает, так же, как и любых других.

Я вот придумал пример более понятный, потому что неайтишный, хотя и инженерный. Вот так обычно выглядит типичная работа, которая приходит мне на оценку как первая итерация:
У нас стоит задача тонкого химического синтеза диметилфторидметилхлорпентилбензолтитана для задач фармацевтической промышленности. Известно, что его трудно синтезировать, и при синтезе получается много примесей, от которых потом мрут люди. Поэтому мы предложим аптекам такой чистый продукт, от которого люди не будут мереть, и маркетинг будет оригинальный: через уборщиц медицинских учреждений, которые будут подбрасывать наши буклеты врачам, а также задушевно беседовать с пациентами в очередях ко врачам. Для того, чтобы получить чистый диметилфторидметилхлорпентилбензолтитан, мы будем использовать четыре стальных реактора, соединённых трубами диаметром 56мм, последняя труба с тефлоновым покрытием. Второй реактор закажем внешним контракторам. Чистоту получающегося диметилфторидметилхлорпентилбензолтитана будем отслеживать при помощи независимой экспертной службы. Все четыре реактора должны будут пройти проверку на выдерживание давления в 156 атмосфер.
С моей точки зрения, многие присылаемые работы именно такие: никаких идей, какие именно примеси имеют максимально вредный эффект (это ж архитектурное требование, самое важное!), как же получить чистый именно от этих примесей (а не от любых -- безвредные ведь нам не мешают) диметилфторидметилхлорпентилбензолтитан, какие там нужны исходные вещества и доступны ли они, или их тоже нужно делать, далее химические реакции, начиная с доступных веществ — т.е. что там вообще в этих реакторах происходит.

Теперь представим инженера, которому маркетологи говорят, что ему нужно будет решить задачу химического синтеза, но непонятно ещё какую. И они наймут химика, который потом всё объяснит. ОК, инженер берётся за дело и предполагает, что там нужны будут реакторы и трубы. Реакторов непонятно сколько, ибо непонятно, сколько там в синтезе будет химических реакций. Поэтому лучше бы этих реакторов было побольше. Он выбирает цифру 4, как "не очень мало, но и ещё не очень дорого", нюхом чует, что там может быть хитрая эндотермическая реакция, но сам он для этого реактор вряд ли спроектирует. Второй реактор он отдаёт проектировать контракторам и честно об этом пишет. Хотя контракторы и спрашивали, что там с массами и температурой, ответ пока никто не может дать, поэтому контракт планируется без разговора о требованиях — но контрактор, разумеется, от заказа не отказывается и говорит, что "сделаю любой реактор". Слово "любой" никого не отпугивает, ибо нет химика, который бы сказал, что будет в этом реакторе происходить. Есть только инженеры по железу, хорошо разбирающиеся в марках стали и сварке, и маркетологи, беседующие с врачами.

В случае железа реактора и труб всё тут очевидно: вероятность выпуска чистого диметилфторидметилхлорпентилбензолтитана в этой ситуации равна нулю. Но в случае софта почему-то кажется, что задачу так решать можно. И вот пишут про "сервера" и "базы данных", но каким образом там будет происходить обработка какой информации, и с чего бы эта обработка вдруг оказалась даже не лучше конкурентов, а вообще возможной, этого вопроса не возникает. Ровно как в предыдущей задаче, где нет химика, есть только сварщики и спецы по корпусам высокого давления. Они точно сделают софтверный "универсальный реактор", но вот что там с чистотой "информационного вещества" или даже просто запуском нужной "информационной реакции" (слова "обработка информации" или "расчёт" так и пишутся, без малейших уточнений, какой именно), и удаётся ли закупить даже исходные ингридиенты, тьфу, получить исходные данные (или исходную информацию? данные! ибо информация что-то означает, а данные тут как сырьё -- можно игнорировать их содержание) это не к ним. В задаче получения чистого диметилфторидметилхлорпентилбензолтитана химика нет, про химию разговор поддержать некому, равно как сообразить, как же эта химия влияет на примеси, а примеси на здоровье пациента. Ох, за этими разговорами про реакторы и трубы мы уже забыли, что задачка про медицину? А зря. Потребности тут в здоровье пациента. А делать приходится железную конструкцию. И нужно протянуть строгую логическую цепочку от одного к другому.

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

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

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

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

Мыслить только про конструкции нельзя. Отсутствие мышления о функциональности нужно как-то осознавать и исправлять. А это отсутствие мышления о функциональности заметно только в случае наличия системного мышления.

UPDATE: Обсуждение -- https://www.facebook.com/ailevenchuk/posts/10211725609509790
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 3 comments