Правила жизни Solution-архитектора

Сотрудник отдела Travel Solutions Николай Зенькевич уверен: главное в Solution-архитектуре — это не просто найти решения, но и доказать — самому себе, в первую очередь, — что эти решения наиболее оптимальны для поставленной задачи. Чем руководствоваться и как добиться этого на практике? Николай разложил все по полочкам.

«Как я пришел в Solution-архитектуру? Просто в один прекрасный момент поймал себя на мысли: мне хочется постоянно решать сложные задачи и при этом еще и писать код, — вспоминает Николай Зенькевич. — На своих проектах я ежедневно сталкивался с задачками, которые мне проще было решить самому, в силу своего опыта, знаний, тяготы ко всему непростому. С тех пор так и продолжается — занимаюсь архитектурой, бизнес-анализом, моделями данных, контрактами, интеграций и так далее.

Возможно, главная причина этого кроется в психологии личности — мне сложно дается делегирование трудных вещей кому-то другому. Особенно, если я уверен, что все равно придется за кем-то проверять и пересматривать. В таком случае, всегда проще и быстрее сделать самому. И я делаю. Мне приятно прийти на работу и сделать нечто такое, что без меня бы не вертелось, не работало. А Solution Architect — как раз та роль, которая сочетает в себе много пунктиков: ты не оторван от кода, тебе приходится очень глубоко погружаться в бизнес и рассказывать людям не только о том, как этот бизнес уже работает, но и делать так, чтобы этот бизнес работал лучше».

Итак, в чем заключаются основные задачи Solution-архитектора?

1. Уметь мыслить и видеть частности.

Многие думают, что главное — это рассказать бизнесу, что ему действительно надо. Нет. На самом деле, это простая задача. Есть у архитекторов более сложная цель — убедить бизнес, что ему что-то не надо. Вот это гораздо сложнее, чем прийти и сказать: ребята, вам надо вот это, вы от этого получите такой-то и такой-то профит. Гораздо сложнее переубедить кого-то со стороны заказчика в том, чтобы сделать что-то по-другому, а не так как они себе это придумали и видят. Находить компромисс. Вот есть люди, которые мыслят сверху-вниз и снизу-вверх. Я мыслю снизу-вверх. То есть докапываюсь до сути, до деталей, разбираюсь в них, потом обобщаю.

Прежде всего, на первых митингах с заказчиком, я пытаюсь понять, как работает бизнес. Отлично, говорю, вот мы начали рассматривать кейс – давайте его дороем до конца! Всех жирафов посмотрим потом, а пока найдем и изучим одного конкретного. Потом нам это поможет легко понять остальных. Почему? Потому что мы будем смотреть на них не как на нечто новое и непознанное, а сравнивать с уже изученным. И надо будет искать только отличия. Если систематизировать, то сначала — вглубь проблемы, до сути, еще немного рядышком, потом — загрузить в себя, пережить и выдать решение.

2. Быть готовым к обычному дню.

  • отвечать на вопросы команды, заказчика;
  • проектировать и писать техническую документацию, разбираться с требованиями;
  • изучать новые технологии;
  • работать с кодом проекта, заниматься прототипированием, оптимизацией, рефакторингом;
  • делиться знаниями.

3. Уметь говорить, слушать и читать.

Читать в прямом смысле слова: быть готовым вычитывать документы по 100-200 страниц. Причем делать это так, чтобы все закреплялось в твоей памяти, откладывалось на полочках в «хранилище», и ты в любой момент мог достать это и применить. Это очень важно: прочитать документ, пропустить его через себя и осознать. Я преподаю в БГУ на РфиКТ «Прикладное программирование» и «Безопасность корпоративных систем» и вижу, что студенты потеряли этот навык. Почему? Они перестали работать с бумажными документами.

Понятно, что книга в электронном виде – практично. Но есть один минус: когда ты работаешь с электронной версией, ты не воспринимаешь ее как книгу. А потом в курсовой или дипломной работе студенты противоречат сами себе, и разницы в этих противоречиях – страниц 10. А все потому, что не видят общей картины. Это погрешность современного чтения.

Отсюда и еще одно важное качество – умение правильно работать с текстом: вычленять сущность, складывать стройную картину мира… Текст можно вообще прочитать вслух как бэкграунд – сюжет давно потерян, мысли далеко, но ты все равно машинально произносишь слова. Мой совет простой: думай о том, что ты читаешь.

4. Постоянно задавать вопрос «зачем».

Зачем? Три раза задай себе этот вопрос. Очень много вещей, которые хочет бизнес, разбиваются о него. Например, мы хотим запустить новую программу лояльности. Зачем? Чтобы привлечь больше клиентов. Зачем? Чтобы увеличить продажи. Зачем?... И вот когда ты докопаешься, зачем это все-таки надо, тогда и ищи решение. А когда нашел его – умей правильно донести. Отсюда и следующее качество – умение говорить. Не просто говорить, а делать это так, чтобы тебя понимали и понимали однозначно. Это приходит со временем. Ты приучаешься писать документацию, которая максимально однозначна.

5. Уметь читать чужой код.

Одно из самых важных качеств — не умение писать код, а умение читать чужой код, анализировать чужие данные, готовые контракты. Почему? Мы реже сталкиваемся с созданием чего-то совершенно нового, с нуля. Сегодня много реверсинжениринга. Сделаю акцент: не надо уметь, например, написать новую программу на «коболе», но надо суметь прочитать и работать с ней дальше. Еще всегда нужно думать и искать альтернативу — а для этого нужна хорошая техническая экспертиза.

Зачем альтернатива? Чтобы убедиться, что найденное решение – оптимальное. Но убедиться в этом самому мало – надо будет это доказать команде, бизнесу. А как проще доказать? Правильно – сравнить с чем-то. Вот я, к примеру, всегда при поиске решений строю матрицу: решение – положительные стороны — отрицательные стороны. К слову, это отлично визуализирует работу SA.

6. Проявлять гибкость мышления и находить 5-6 решений.

Кстати, как правило, 6-м оказывается решение do nothing. Оставь все как есть. Между прочим, это решение, с которым бизнес часто соглашается. На нашем проекте была ситуация, когда не очень корректно обрабатывались события на границе года: событие произошло в конце декабря, а обрабатывается в январе. Мы аккуратно прописали варианты ее решения, и среди них был «do nothing». Из профитов: ничего не надо делать. Из минусов: какие-то проблемы останутся.

Но был один большой плюс: мы не наделаем других проблем. Ибо все решения, которые были найдены, в какой-то мере решали данную задачу, но усложняли логику и создавали почву для появления дефектов в дальнейшем. В результате заказчик принял решение: все варианты технически сложные, оставляем все как есть, потому что проблема возникает не часто, и при необходимости ее можно решить «руками».

Или вот еще классический пример. На сайтах многих авиакомпаний ты можешь сделать новый букинг, можешь отменить, но не можешь его модернизировать. Почему? Потому что это происходит редко. Тот, кому это понадобилось, может позвонить по телефону и решить вопрос. Если же мы начнем делать это онлайн, будет сложно.

Но и это не самый главный аргумент: вопрос в том, кто этим реально из пользователей сможет воспользоваться! Бабушка из Оклахомы? Кнопочки «сделать все хорошо» не будет. И в результате, велика вероятность, что 80 % сложностей, которые мы сделаем, понадобятся всего лишь 20% клиентов… Поэтому, с точки зрения архитектуры, сразу важно вычленить тот минимум, который необходимо оптимизировать. Кстати, об оптимизации.

7. Не пропустить момент, когда бизнес начинает говорить не требованиями и запросами, а готовыми решениями.

Например, приходит запрос добавить страну Карибы в справочник. Как поступит просто девелопер? Все ОК, сейчас добавим. А как должен поступить архитектор? Во-первых, нет такой страны. Во-вторых, чем вызвано такое решение? При более внимательном изучении оказалось, что неудобно каждый раз добавлять эту группу стран. Наш выход: давайте разрешим группировать много стран и ссылаться на группу стран.

Что мы видим? Требование «нам надо быстро добавлять страны Карибского региона» бизнес превратил в техническое решение, причем, не самое оптимальное и правильное. Граница между бизнес-требованиями и архитектурными решениями очень тонка. Важно этот момент понять и отследить. И это задача Solution-архитектора.

8. Быть готовым к частым командировкам.

Без командировок понять бизнес, донести решения сложно. Командировки очень нужны, чтобы запустить проект, установить связи. Когда у тебя есть связь с человеком не только по работе, то работается легче, и ты его лучше понимаешь во время долгих телефонных переговоров.

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

К слову, благодаря командировкам, у меня появилось новое хобби: увлекся американским футболом. Теперь в сезон по воскресеньям смотрю по ночам игры.

9. Помнить: Solution Architect — человек, который пишет юзерстори, разговаривает с бизнесом, сам рисует спецификации, модели данных в базе и пишет код.

И все это одновременно.