Слишком часто архитекторы программного обеспечения принимают решения со своих заоблачных академических высот, игнорируя обратную связь от разработчиков. И чаще всего это приводит к расхождению мнений в команде, а затем и к открытому протесту, в результате получается программный продукт, не имеющий ничего общего с изначальными требованиями. Каждый проектировщик должен знать, как формулировать цели и задачи проекта. Ключевыми стратегиями в этом являются ясность и лидерство.
Под ясностью подразумевается то, каким образом вы подаете информацию. Никто в вашей команде не будет читать стостраничное описание архитектуры системы. Простота и краткость в объяснении ваших идей жизненно важны для успеха любого проекта. Старайтесь все делать как можно проще, особенно в самом начале проекта. В том числе это означает и не писать огромные вордовские документы. Используйте средства вроде Visio для создания простых диаграмм, наглядно объясняющих ваши мысли. Не усложняйте их, поскольку в начале они будут меняться часто.
Еще один хороший способ эффективно передать информацию – неформальные митинги в комнате с доской и маркерами. Это один из лучших способов для обсуждения – пригласить в комнату группу разработчиков (или других архитекторов) и нарисовать все ваши идеи на доске. При этом имейте под рукой цифровой фотоаппарат. Оставить только на доске результаты долгого и эффективного обсуждения – не самая лучшая идея. Сфотографируйте то, что получилось, а фотографию разошлите всей команде. Забудьте о многостраничных вордовских документах и сфокусируйтесь на обсуждении ваших идей, и лишь после этого начинайте работать над деталями ваших архитектурных решений.
Еще одна вещь, которую архитекторы программного обеспечения часто не осознают – это то, что проектировать архитектуру также означает быть лидером. Вы должны добиться уважения ваших коллег, чтобы эффективно работать в здоровом коллективе. Скрывать от разработчиков полную картину или не объяснять принятые решения – верный путь к провалу. Если же разработчики на вашей стороне, то тем самым ваши архитектурные решения получают поддержку и с их стороны тоже. В свою очередь, вы идете навстречу разработчикам, посвящая их в тонкости разработки архитектуры. Работайте вместе с разработчиками, а не против них. Помните, что вся команда (тестеры, аналитики, менеджеры проекта и разработчики) требуют ясности и лидерства. Совершенствование этих навыков поможет построить здоровое рабочее окружение.
И если коммуникация – это король, то ясность и лидерство – его покорные слуги.
Автор оригинала: Mark Richards
Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!
