Введение
По традиции, для самых жаждущих и нетерпеливых, эта статья будет о:
С чего начинается построение любой архитектуры?
За счет чего реализуются потенциальные бизнес возможности?
Кто нужен для реализации намеченных возможностей?
Как создать цифровые продукты, которые будут удовлетворять требованиям заказчиков, вписываться в намеченные сроки и бюджеты?
Из чего должна складываться структура продукта и как он должен реализовывать функциональные требования?
Если нет интереса к предисловию, то переходите к первому "почему". Для тех, кто хочет сложить причинно-следственные связи - добро пожаловать. Прорабатывая цикл лекций для студентов ВШЭ по предмету анализа требований, я решил, что логично закончить курс обзором практик и подходов к построению архитектуры. Архитектуры конкретного решения, архитектуры создаваемого продукта, архитектуры ландшафта компании? Да о чем же я хочу рассказать? Четкого понимания о какой именно архитектуре рассказывать у меня не было. Имея определенный опыт работы над архитектурой решения, архитектурой продукта и внутри блока корпоративной архитектуры, у меня сложилось субъективное понимание того, как взаимосвязаны эти виды архитектур. Определить и понимать их границы полезно не только для самих архитекторов, но и для всех вовлеченных в процесс производства цифровых продуктов. Польза определяется эффективностью и точностью вопросов, задаваемых в том или ином окружении для выявления/уточнения/выбора/принятия производственных решений. Как итог - появился обзор/эссе, который систематизирует информацию по архитектурным концептам разного уровня процесса создания цифрового бизнес продукта. В качестве стержня обзора я выбрал и немного адаптировал аналитическую практику - 5 почему (ссылка). Эта техника ориентирована на то, чтобы от актуальных условий дойти до причин определенного события. Это индуктивная техника (ссылка), которая скрывает широту происходящего и приводит нас к "субъективному общему". Для систематизации эта техника хорошо подходит, но в ней нет рефлексии (ссылка). Вся возможная рефлексия будет адвокатировать уже принятым решениям. Поэтому перевернем ее и сделаем дедуктивной (ссылка). Это важно для осознания картины в целом. Постепенно, отвечая на каждое следующее почему мы будем фокусироваться на том, что наиболее важно для построения эффективной, востребованной архитектуры, что бы не вкладывалось в это понятие.
Почему архитектура нужна?
С чего начинается построение любой архитектуры?
Не усложняем. Начинаем с основ. Давайте дадим определение архитектуры. Такое определение, которое будет интуитивно понятным, ясным и однозначным:
Архитектура - элементы и связи между ними, которые в совокупности представляют собой описание создаваемого объекта (Автор статьи)
Ну что же. По-моему у нас получилось. Описание ясное, понятное, не очень сложное, но достаточно абстрактное. В нем нет критериев и оценок. Оно помогает погрузиться в контекст. Не более. Отлично. Сформулировано. Теперь вопрос. Как нам это поможет? И тут мы начинаем задаваться онтологическими вопросами (ссылка):
Для чего мы создаем наш объект?
Какую функцию должен выполнять наш объект?
Что нужно для функционирования нашего объекта?
Кто будет пользоваться результатами работы нашего объекта?
Все эти вопросы рано или поздно может задать себе каждый специалист. Эти вопросы позволяют оценить себя и результаты своей работы, для того, чтобы сфокусироваться на самом важном. А что такое "важно" мы понимаем через конкретный опыт. Через метод проб и ошибок, через эксперименты и коммуникацию. Для построения архитектуры важно ответить на все возникшие вопросы. Уровень детальности и подробности ответов может быть разный. Детальность определяет пониманием текущего контекста. Чем больше опыт, чем более точные ожидания, тем более ясная архитектура получается. Вопросов может быть много, но все они будут либо о разных аспектах архитектуры, то есть элементах и связях, либо о глубине описания и формализации тех же самых элементов и связей. Немного абстрактно. Я надеюсь, что при этом понятно. Теперь попробуем конкретизировать абстрактность. Все эти концепты, в приложении к создаваемым информационным системам формализовались в виде конкретной методологии, которая направлена на описание архитектуры любого предприятия. Это модель Захмана (ссылка). Модель Захмана - фундамент для построения любой информационной системы или набора систем, основываясь на конкретном контексте (Рисунок 1).
Модель оформлена в виде матрицы, где по горизонтали вопросы, которые поясняют и конкретизируют разбираемый аспект предприятия, то есть формируют элементы ее архитектуры: Почему, Как, Что, Кто, Где и Когда. По вертикали - рассматриваемые аспекты - контекст, концептуальное представление, логическое представление, физическое представление, детализированное представление. Матрица Захмана похожа на пирог, в котором есть 5 аспектов/слоев. Каждый слой должен быть самодостаточным. В противном случае он будет неполным и при переходе к следующим уровням мы будем постоянно сталкиваться с темными "дырами". "Дыры" - следствие умолчания ответов на вопросы, которые были заданы на предыдущих уровнях рассмотрения. Самый важный, первый уровень - концептуальный. Это уровень миссии компании, уровень ее целеполагания. Он самый абстрактный и эфемерный. Он не несет никакой конкретики, не помогает принимать конкретные тактические решения, но он направляет развитие организации и задает ориентиры и тренды. Проигнорировав его можно сделать хороший продукт, но нельзя ожидать его признания и востребованности у клиентской аудитории. Модель Захмана не поможет:
Делать продукты хорошо;
Формализовать нужные для производства роли;
Сделать качественный продукт;
Принимать верные стратегические и тактические решения;
Модель Захмана поможет:
задать рамки и границы архитектуры конкретной компании;
определить артефакты, документы, которые помогут провести рефлексию опыта организации.
По мнению самого Захмана именно это нужно для формирования более сфокусированных и конкретных ожиданий того, что можно и нужно ждать от службы информационных технологий конкретной организации. Архитектурный уровень по Захману структурирует опыт и обосновывает возможности. Подытоживаем. На какие вопросы мы найдем объяснения на этом уровне:
Каковы наши потребности?
Почему нужно обосновывать возможности?
За счет чего реализуются потенциальные бизнес возможности?
Мы прошли первый этап. Следом ответим на вопросы целеполагания, которые помогут делать то, что нужно:
Что мы за организация?
Как мы реализуем поставку нашего продукта до целевого пользователя?
Что мы делаем для нашего пользователя?
Кто в организации нужен для создания того самого продукта?
Где мы располагаемся, что бы поставка продукта удовлетворяла нашего пользователя?
В какой момент времени мы поставляем ему продукт?
Переходим к тому, каким будет процесс создания продукта. Какие этапы в этом процессе необходимы, чтобы принимать взвешенные и обоснованные решения в рамках нашего контекста о том, как реализовать ту или иную функциональность. Это уже не уровень онтологии, а уровень действий - процессов или проектов. Мы понимаем ограничения. Ограничения помогают принимать решения, то есть по сути являются для нас принципами. Ядро реализации возможностей - требования. Требования фокусируют на моментах, которые важны. Важны прежде всего для тех, кому нужны реализуемые возможности.
Мы не оправдали ваши ожидания, – это не наши проблемы. Это ваши проблемы (Андрей Сергеевич Аршавин)
Целеполагание и оправданные ожидания направляют процесс достижения результатов. Если процесса нет, то достижение результатов - удача/случай/везение. Мы пришли к процессам, проектам, активностям, которые должны приводить к принятию конкретных решений и разработке/внедрению конкретных информационных продуктов. Это уровень практических методологий и методик. На этом уровне есть ряд методологий и методик, каждая из которых заточена под определенную специфику. Это UP (ссылка), MSF (ссылка), ГОСТ 34 (ссылка), TOGAF (ссылка). Архитектурное дерево может развиваться по любому из приведенных стволов. Наиболее полный и комплексный - TOGAF. Мы и пойдем по нему далее (Рисунок 2).
В основе TOGAF находится концепция принятия решений. ADM - Architecture Development Method. ADM состоит из активностей/этапов. Это чеклист архитектора, помогающий не запутаться во всех рассматриваемых аспектах. Основа правильного решения - актуальное понимание требований и учет факторов, важных для нашей организации. С актуальностью требований - ясно. Изменения происходят каждый день, и создаваемые нами системы должны уметь их адаптировать, а вот про важность не все так очевидно. Поэтому об этом стоит немного поговорить. Важным, по TOGAF, являются:
Концепция архитектуры;
К Захману - Ограничения и цели, которые помогают нам более детально разбираться с тем, как, что и в каком порядке мы будем делать;
Бизнес архитектура;
Структурированное описание того, как должен/может измениться обще организационный контекст в результате наших действий, как изменится взаимодействие с другими системами с помощью сквозных бизнес процессов и что, на кого в этих бизнес процессах влияет или может повлиять. А раз влияет или может повлиять, то как это сказывается на текущей и потенциальной ценности, которую реализуют те самые бизнес-процессы, выделенные в бизнес-архитектуре;
Архитектура информационных систем;
Из каких структурных элементов состоит наша система. Компоненты и единицы, связанные в систему, реализующую определенную ценность;
Технологическая архитектура;
Какими типами информационных систем мы пользуемся для того, чтобы создавать наши цифровые продукты. Код, классы, облачные кластеры, БД, внешние сервисы, оркестраторы инфраструктуры, системы мониторинга, системы хранения кода и т.д.
Возможности и решения;
Назначение информационных бизнес систем - решать конкретную бизнес проблему. Бизнес проблема решается за счет пользовательского процесса, в котором конкретные пользователи выполняют конкретные бизнес-операции. Бизнес-проблема решается так, как договоримся и согласуем на уровне бизнес архитектуры, но, как правило, выбранное нами решение не единственное. Контекст любой организации имеет множество возможных вариантов пользовательских действий. Их все желательно знать и понимать, чтобы иметь возможность использовать в меняющихся условиях то, которое будет наиболее выгодным для конкретной цели;
Планирование перехода;
Путь трансформации. Для небольших проектов и инноваций этот этап схлопывается. Там, где предпочтение отдается крупнорелизному циклу, и от одного до следующего релиза необходимо поддерживать эффективную операционную работу пользователей, этот этап актуален. В этом пункте необходимо отдельное внимание уделять трансформационным требованиям;
Управление реализацией;
Это про управление процессом разработки и налаженные механизмы валидации продукта;
Управление архитектурными изменениями;
Это стартовая/замыкающая точка через которую необходимо пропускать изменения. Она оркеструет этот процесс.
Подход TOGAF, на сегодня - наиболее распространенный подход к реализации и поддержанию архитектуры или архитектур решений в компаниях. Он включает в себя наиболее важные вехи, которые необходимо учитывать при работе над информационными продуктами. Он не требует сильной адаптации. Этап может быть сколь угодно мал, но он обязан быть. Иначе бардак, хаос, размытие ответственности. Если в компании заговорили про архитектуру (что бы не имели в виду), то стоит присмотреться к этому подходу. TOGAF концентрирует внимание на активностях и ресурсах, но ничего не говорит о том, какие ресурсы должны быть. Он отвечает на вопросы:
Как выстроить процесс разработки и поддержки архитектуры?
Какие этапы должны быть для построения архитектуры?
Что является ядром архитектурной деятельности и как этапы связаны между собой?
Почему нам нужны именно такие ресурсы?
Кто нужен для реализации намеченных возможностей?
Мы подошли к 3 почему. С одной стороны, ситуация становится все более понятной, но с другой стороны все наши рассуждения остаются на уровне абстракций. Как проще всего заземлить абстракции на конкретное решение? Точно. Найти того, кто сможет из целевых активностей встроится в процессы и своими действиями приносить результат. Именно результат, а не абстрактные архитектуру, организации деятельностей и управление артефактами.
Кадры решают всё (Иосиф Виссарионович Джугашвили)
Мы подошли к ролям. Де-факто, единственная методология, которая раскладывает деятельность по ролям с привязкой к уровням управления организацией - SAFe. Не стоит обманываться названием. Scaled Agile Framework не такой уж и Agile. Kanban многие эксперты подходов к управлению организацией считают не Agile, а крайне waterfall подходом. И что у нас остается - Scrum на уровне производства продуктов. Этот Scrum с легкостью заменяется на любой подход к разработке. Но вот роли, и в особенности архитектурные, разложенные по слоям, в этом SAFe уникален (Рисунок 3).
Уровни:
Уровень владельцев бизнеса и корпоративных архитекторов:
Cтратегия и планы развития. На этом уровне и нужен Захман и его основополагающая матрица для фокусировки проектной и продуктовой направленности компании в целом;
Для управления используется Kanban;
Без каких ролей не поедет -> Владельцев бизнес направлений, способных договариваться между собой и корпоративных архитекторов, которые могут предоставлять компетентную информацию о том, как можно/нужно организовывать процессы и что необходимо для того, чтобы они становились все более и более эффективными;
Уровень управления бизнес решениями и архитекторов решений:
Тут должен быть выстроен процесс, чтобы поддерживать архитектуру. И снова здраствуйте, милый TOGAF;
Для управления используется Kanban;
Без каких ролей не поедет:
Архитектор решений (набор продуктов объединенных между собой бизнес смыслом);
Менеджер решений
Роль которая организует контекст, в котором архитектор наводит порядок;
Запуск новых продуктов, изменение существующих, найм и увольнение персонала;
Среднесрочная стратегия;
STE
Cкрам мастер для менеджеров и архитекторов - Solution Train Engineer (ссылка);
SDM (ссылка) уровня набора продуктов;
Уровень команд
Тут изготавливают продукты. Сначала думают, а потом делают.
Думают - Менеджеры продуктов, Системные архитекторы (архитекторы по конкретным системам) и RTE - scrum мастера для менеджеров решений и архитекторов - Release Train Engineer (ссылка);
Делают - Команды разработки;
Для управления архитекторами и менеджерами решений используется Kanban, для управления командами разработки используется SCRUM, для поддержки выведенных продуктов тоже Kanban;
Все ясно и понятно. Об описании каждой роли можно написать отдельную статью. Слой формирует границу, роль наводит порядок по профильной деятельности в рамках слоя. SAFe помогает нам найти ответы на вопросы:
Как должна быть организована деятельность по поставке продуктов?
Какая ответственность закреплена за каждым иерархическим слоем в компании?
Какие роли, и - за что они отвечают?
SAFe очень подробный подход, который дает конкретные рекомендации (ссылка). Этот фреймворк помогает структурировать и упорядочить профессиональные уровни организации и закрепить величину вклада в реализуемую организацией ценность для клиента. Общая картина выстраивается. Мы постепенно упорядочиваем контекст и приходим к пониманию о том, какие элементы есть на каждом уровне и что такое архитектура (чтобы под этим не имелось в виду). Нам бы теперь научится делать продукты так, чтобы это укладывалось в рациональные рамки (ссылка).
Почему мы делаем именно такие продукты?
Как создать продукты, которые будут удовлетворять требованиям, вписываться в намеченные сроки и бюджеты?
Казалось бы, мы продвинулись дальше и должно стать попроще, но нет, и не надейтесь. Каждый следующий уровень дополняет предыдущий, более абстрактный, но требует для своей реализации конкретные ресурсы и действия.
Даже путь в тысячу ли начинается с первого шага (Лао Цзы)
Мы подошли к разговору о том, что такое архитектура конкретной системы и из чего она состоит. Все те же элементы и связи между ними - только на более конкретном уровне. Мы подошли к модели "4 + 1". Альтернативно можно, рассмотреть модель уточнения абстракций c4, о которой я тут подробно рассказывать не буду, но с которой точно стоит познакомиться С4 (ссылка) (Рисунок 4)
4+1 - взгляд на создаваемую систему с точки зрения основных действующих лиц процесса разработки и контекста эксплуатации создаваемой системы. В основе этой архитектурной модели лежит представление прецедентов (Use Case). Это описание основных лиц и систем, задействованных в формировании результатов, которые достигаются при использовании системы. Это +1. Дальше 4 представления:
Логическое представление. Основными заинтересованными лицами в нем являются аналитики и тестировщики. Это представление описывает общую логику процессов. Как результат мы получаем сформированный словарь терминов и законченное функциональное описание того, какие процессы исполняются в системе. Для этого используется диаграмма классов (ссылка);
Представление процессов. В нем заинтересованы те, кто отвечает за внедрение разрабатываемой системы в определенной бизнес-среде. Это представление помогает с формулированием и обоснованием эффективности, расширяемости и производительности создаваемой и внедряемой системы. Для этих целей может быть использована диаграмма деятельности (ссылка) и последовательности (ссылка). Диаграмму деятельности со спокойной совестью можно поменять на BPMN (ссылка), а вот диаграмма последовательности, де факто, стандарт на описание интеграционных процессов;
Представление реализации, основные заинтересованные лица в котором – программисты и разработчики. Представление реализации помогает управлять процессом производства. Основная диаграмма, используемая для этого представления, – диаграмма реализации.
Представление развертывания. В нем наиболее всего заинтересованы технологические лидеры создаваемой системы. Представление развертывания реализуется посредством диаграммы компонентов. Представление развертывания определяет топологию системы, принципы ее развертывания, инсталляции и коммуникации элементов между собой;
Все представленные диаграммы создаются с помощью UML и/или BPMN инструментария. Как собирать данные, отображать и синтезировать в архитектурное описание - предмет другого разговора. Описание есть. Очередной архитектурный уровень закрыт. Он нужен нам для того, чтобы ответить на вопросы:
Какие роли должны быть в процессе/проекте создания и внедрения системы?
Какие у ролей ответственности и обязанности?
Какие артефакты необходимы для старта процесса кодирования?
Ну что же, у нас есть описание. Они задают функционал и ограничения процесса разработки. Отлично. Теперь можем идти далее и думать о том, что нужно делать для реализации продукта.
Почему информационный продукт должен быть именно таким?
Из чего должна складываться структура продукта и как он должен реализовывать функциональные требования?
На этом уровне мы проектируем дизайн системы. Архитектура задает дизайн. Архитектура базируется на аспектах. Аспекты должны сочетаться и воплощаться в создаваемой системе и программных модулях (части создаваемой системы) (Рисунок 5). Тут обойдемся без цитат. Все будет достаточно конкретно.
Модульность
Этот аспект предписывает независимость и самодостаточность каждого компонента, создаваемого в системе. Система должна базироваться на определенных "столбах". Каждый такой столб сам по себе должен быть независим от остальных и при этом привносить в архитектуру функциональность. Если такие столбы, то есть модули, будут независимы друг от друга, то это обеспечит надежность, сопровождаемость и развиваемость создаваемой системы. Модульность – базисное понятие. Она помогает в организации и распараллеливании работ, способствует взаимозаменяемости устаревших компонентов.
Открытость
Этот аспект предписывает создавать системы и компоненты, которые будут просты для внесения изменения. Простота достигается за счет того, что у каждого компонента есть четко определенное единое назначение и ответственность. Так, локализуя ответственность информационного объекта в одном компоненте, мы получаем единое место, в котором при необходимости нужно вносить изменения. Это упрощает работу с компонентом и системой в целом.
Адаптивность
Еще его можно назвать гибкостью. Это синоним приспособляемости. При проектировании нужно выделять консервативные и динамические части нашей архитектуры. Консервативные части, традиционно – ядро будущей системы. Это основные алгоритмы, которые составляют ценность выполняемых работ. Динамические части – части, которые характеризуют каналы связи между нашей системой и ее потребителями. Эти каналы могут быть представлены в виде интеграционных потоков или интерфейсов, представляющих или потребляющих данные. Наборы данных, которыми обменивается наша система, должны быть ясными, понятными и легко заменяемыми. В этом состоит суть адаптированности отдельного компонента или системы в целом. Система не должна зависеть от конкретных данных. Алгоритмы должны учитывать принципы, а данные – эволюционировать вместе с развитием определенного бизнес-направления.
Моделируемость
Синоним в данном контексте – воспроизводимость. Создаваемый компонент системы должен быть ясным и понятным, принципы его работы должны быть прозрачны для пользователя. Он не должен допускать неоднозначности в трактовании своего внутреннего устройства и поведения.
Дружественность.
Это аспект, производный от моделируемости. Система должна быть дружественна для своего разработчика. Она должна быть понятна, как структурно, так и функционально. В ней не должно быть темных пятен, ответственность которых скрыта от взгляда и непонятна стороннему пользователю.
Несоблюдение любого из рассмотренных принципов постепенно может приводить к тому, что систему станет сложно поддерживать и развивать. В совокупности эти принципы воплощаются в архитектурных шаблонах разработки, каждый из которых решает определенную задачу в заданном контексте функционирования системы. Шаблоны решают задачи выбора наиболее подходящего набора элементов. Они задают образ создаваемой системы, то есть описывают то, какой она должна быть. Можно провести аналогию и сказать о том, что архитектурный шаблон проектирования задает части системы, каждая из которых может быть создана с помощью набора тактических шаблонов проектирования (шаблонов разработки). Основные шаблоны архитектурного проектирования:
«Многоуровневая архитектура»
«Модель», «Представление», «Контроллер»
«Каналы и фильтры»
«Управление событиями»
«Микросервисная архитектура»
«Сервисная архитектура»
На хабре есть очень хорошие статьи и разъяснение на тему того, чем шаблоны разработки отличаются от архитектурных шаблонов. Мне нравится эта (ссылка), но можно найти много дополнительного и интересного. Мы добрались до самого детального уровня рассмотрения архитектуры. При желании можно перейти на уровень шаблонов разработки, но это будет в других статьях. Суть - архитектурные шаблоны позволяют ответить на вопросы:
Из каких элементов должна состоять создаваемая система?
За что отвечает каждый элемент?
Как элементы взаимодействуют между собой?
Порассуждаем об приведенных уровнях, связях между ними и значимости каждого уровня? То есть, ориентируясь на данные тут определения, составим архитектуру архитектур.
Вместо и в дополнение к итогам
Я привел 5 уровней, которые характеризуют архитектуру (чтобы не вкладывалось в это понятие) любой компании (Рисунок 6).
Я постарался продемонстрировать классификацию и структурирование архитектурной деятельности любой компании. В этом структурировании какие-то уровни могут игнорироваться, какие-то уровни могут реализовываться альтернативным образом, но предложенная классификация решает главную задачу – дает представление о том, что такое архитектура и из каких частей она состоит. Перечитывая статью и выискивая в ней логические и грамматические ошибки, я стал задаваться вопросом: А что будет с этим концептом, если в нем не будет отдельного уровня, двух, трех, четырех. Что из этого более важно для того, чтобы сделать крутой, востребованный продукт, который будет приносить пользу. Давайте разбираться. Все уровни нужны. Игнорирование каких-то уровней крайне не желательно. Если вы собираетесь создавать и развивать инженерную организацию, которая целенаправленно будет двигаться к своим целям, то вам нужно думать о каждом архитектурном уровне. Но, на мой взгляд, в ситуации когда у нас ограниченные ресурсы и нам нужно делать продукты, которые будут эволюционировать вместе с организацией, умирать, возрождаться в поисках более оптимальной стратегии развития - все пять уровней часто являются избыточными. Мы будем строить правильную организацию, вводить архитектурные уровни и систематизировать работу в них вместо того, чтобы сосредотачиваться на создании нужного здесь и сейчас информационного продукта. Верхний уровень, уровень Захмана или онтологии, как Вам будет удобнее, это уровень профессиональных устоев и культуры. Он предлагает искать ответы на конкретные вопросы, при этом он абсолютно нетерпим к ситуации, когда для нас вопросы являются не актуальными/не важными/не понятными. Этот уровень может дополняться вместе с постепенным эволюционированием на других слоях представленного описания. То есть цель будет уточняться по ходу движения. Уровень выстраивания процессов важен для того, чтобы выстроить процесс поставки ценности, очевидно же. Процесс может быть разной степени полноты учета факторов и комплексности. От этой полноты будет зависеть полнота достижения задуманной бизнес ценности. Процесс может быть даже не процессом, а стихийным проектом с этапами, которые важны именно в данный момент времени и именно для того, чтобы создать конкретную систему (CMMI - 0 процессный уровень). С ролями и уровнем "прав и обязанностей" (SAFe) ситуация аналогичная. Цель выстраивания архитектуры - создание продукта с заданным уровнем качества. Пользователи системы должны быть удовлетворены. Хорошо, если они счастливы, но это over. Главное - они должны иметь возможность быстро, качественно, удобно выполнять нужные им действия. И вот тут уровень "продуктополагания" (4+1/с4) незаменим. Какие-то представления мы может проигнорировать или выполнить для "галочки", но это будет иметь последствия. С уровнем архитектурных шаблонов ситуация похожа. Уровень, на котором мы закладываем качество создаваемых продуктов. То есть верхние уровни более важны тактически (для выполнение работы здесь и сейчас), более приоритетны для формирования конкретных информационных продуктов, а нижние уровни важны стратегически (цель, к которой мы идем). Но стратегия это очень эфемерный артефакт.
Мёд – это очень уж странный предмет… Всякая вещь – или есть, или нет, – А мёд (я никак не пойму, в чём секрет!)…
Стратегия формируется долго, результаты ее не всегда видны и понятны. Если мы допустим ошибки на более верхних, тактических уровнях они сразу станут видны и понятны, условно - дешевоисправимы. А если на более нижних, стратегических уровнях, то выявить их будет более сложно, исправить более дорого. Без ложки дегтя не всегда обходятся бочки с медом. А что по этому поводу считаете Вы?
Благодарности
Спасибо моей семье, друзьям, коллегам за содержательные разговоры, критику, возможности делать интересные продукты вместе. Это сподвигает на разговоры, рассуждения, споры и, как следствие, поиск ответов на сложные и интересные вопросы. Не скучайте сами и не давайте скучать своим коллегам.
