Ясность

Некоторые правила, чтобы сделать ИТ архитектуру понятной и проект здоровым.

  1. Поддерживайте баланс между временем и скоупом на проекте, сокращайте скоуп.
  2. Используйте понятную терминологию.
  3. Используйте широкодоступные технологии.
  4. Поддерживайте баланс экспертизы в команде.
  5. Запускайте технологические проекты для расширения возможностей.
  6. Повторяйте опыт несколько раз перед обобщением.

Баланс между временем и скоупом

В каждом проекте Вы должны:

  1. Определить бизнес-ценность или техническую возможность, которая будет поставлена — цель проекта.
  2. Разделить проект на меньшие части (исследование, получение технической возможности, поставка функциональности), если необходимо.

Повторяйте вышеописанные шаги, пока каждый планируемый подпроект не будет укладываться в разумное время и бюджет.

Почему поддержание разумного охвата важно:

  1. Что-либо проще понять новому члену команды. Это означает, что экспертиза масштабируема.
  2. Проще коммуницировать из-за размера команды. Это ведёт к более эффективному процессу.
  3. Когда цель проекта находится в поле зрения, проще находить компромиссы.

В любой непонятной ситуации сокращайте охват проекта (берегите время).

В больших организациях могут быть тенденции на раздувание охвата, чтобы продать проект. Когда дела идут не так, менеджеры часто сокращают время на архитектуру, но не амбиции проекта. Здоровые организации останавливают проект, который идёт к провалу, пересматривают результаты и ошибки, затем стартуют новый (маленькие организации чаще так поступают).

Понятная терминология

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

Идея популярной книги "Domain-Driven Design: Tackling Complexity in the Heart of Software" Эрика Эванса (ISBN-13: 978-0321125217, ISBN-10: 0321125215) в том, чтобы выделять ограниченные контексты, внутри которых люди пользуются одинаково понимаемым языком. Язык и охват проектов связаны — чтобы управлять обоими вещами, нужно сбалансировать охват и поработать над пониманием.

Если одинаковое понимание недостижимо, это обычно означает:

  1. Слишком большой охват.
  2. Нет желания думать у участников проекта.
  3. Неуважение и некомпетентность прикрываемые экономией времени.

Широкодоступные технологии

С любым ИТ проектом Вы управляете неизвестностью и блокерами. Зачем добавлять их? Выбрав странную технологию, Вы можете быть вынуждены принимать компромиссы, которые в нормальной ситуации делать не должны были бы.

Обычно, использование мало-популярных технологий случается когда:

  1. Менеджер полагается на свою экспертизу в чём-то (это в целом ок, но поддержан ли он командой?).
  2. Менеджер убеждён поставщиком (поставщики часто вводят в заблуждение).

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

Поддержание экспертизы в команде

В SCRUM наличие универсальных членов команды и непрерывное обучение друг у друга — ключевая часть методологии. Это обеспечивает баланс экспертизы.

Если есть выделенные роли (аналитик, архитектор, разработчик, QA-инженер и т.д.), подумайте об уровнях внутри ролей:

  • ведущий — человек ответственный за финальные решения (должен обладать высокой экспертизой по определению).
  • синьоры — люди с высокой экспертизой. Лучше использовать их для трудных задач.
  • мидлы — люди, выполняющие 40-90% обычной работы.
  • джуниоры — люди, недавно начавшие свой путь в профессии. Они экономят деньги, выполняя простые задачи (20%-70% работы).

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

Что ещё более важно, роль начинается с ведущего. Лидом должен быть назначен крепкий синьор, способный контроллировать свою зону ответственности, когда речь идёт о коммитах (в прямом и переносном смыслах) других участников проекта. Если поставите джуниора на ведущую позицию будет вот что:

  1. Он будет расти в 2-3 раза медленнее, чем мог бы с хорошим лидом.
  2. Сначала он реально не сможет ничего контролировать, но может блокировать работу своим защитным поведением.

Нельзя думать, что набирая джуниоров вы что-то экономите, если они покидают вас, недорастая до синьоров.

Технологические проекты

Технологические проекты (исследования, переходы на новые технологии и т.п.) необходимы:

  1. Чтобы выстроить технологические возможности как таковые.
  2. Чтобы приобрести современные архитектурные практики.
  3. Чтобы поддержать баланс экспертизы в команде.
  4. Чтобы держать людей заряженными и отдающимися работе.

Вот почему вы не будете растущей компанией без технологических проектов.

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

Повторение опыта

Слишком раннее обобщение есть форма овер-инжиниринга (заумства).

Первое, соберите кейсы. Думайте над обобщающим решением проверяя его относительно сценариев, которые будут вскрыты. Отведите время на это. Иначе, шансы высоки, что придётся поломать архитектуру много раз.

Второе, модуляризуйте решение и избегайте тесного связывания.