Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Дисциплины и технологии: трудности в объяснениях

Объяснять людям разные дисциплины (в терминах альф) очень трудно, ибо в окружающем мире люди не обнаруживают никаких альф, а только самые разые рабочие продукты.

С утра ваяю и переваиваю, точу и перетачиваю слайды по архитектурным описаниям. Средний размер книжки по системной архитектуре -- полтыщи страниц. Курс системной архитектуры в Loughborough Univercity -- 150 часов. Моя задача в этот раз: рассказать людям про архитектуру так, чтобы они поняли хоть что нибудь и начали тратить на эту архитектуру достаточно времени, несмотря на "текучку", "авралы" и "некогда", возникающие как раз от плохой архитектурной проработки. Архитектура есть у любой системы, есть обычно и архитектурные описания -- весь вопрос, какие это описания, насколько удобно с ними работать, насколько они полны для ответа на вопросы разных стейкхолдеров.

Например, эти архитектурные описания называются "методика проектирования", "принципиальная схема", "компоновочная схема" -- при этом слово "архитектура" не встречается там совсем, а каждый термин в названии описания варьруется, как варьируются и сами методы описаний. Например, "принципиальная схема" может оказаться PFD, P&ID, гидравлической схемой, пневмогидравлической схемой, технологической схемой -- как разглядеть общее за всеми этими словами? ГОСТы тут немного добавляют.

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

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

Вот это самое трудное: объяснить людям, что никакой дядя или тётя снаружи проекта не научит их принимать решения по выбору их технологии (инструментария, набора разрабатываемых рабочих продуктов, необходимого уровня детальности в их разработке, необходимого числа и момента проверок и т.д.). Можно научить людей рассуждать на эту тему, научить терминам, познакомить с примерами. Нельзя сделать за инженеров работу в их проектах, нельзя написать "методичку" на все случаи жизни.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 12 comments