Роли в проекте выглядят так:
- Аналитик слышит от бизнеса задачу в духе «нам надо работать быстрее» и идёт выяснять, что для этого нужно. Долго ковыряется и узнаёт, например, что производству нужна более простая или прозрачная схема процесса обработки заказов. Обсуждает с командой. Бизнес решает делать. Аналитик бросает в архитектора требованиями к новой системе. Аналитик узнаёт, к чему надо идти.
- Архитектор смотрит на требования, смотрит на систему, удивляется, смотрит ещё раз туда-сюда — и после этого ставит точное техническое задание. Архитектор видит, что нужно делать.
- Проектировщик — самый счастливый человек. Он берёт требования архитектора и просто лабает их до уровня детального проекта системы. Проектировщик знает, как нужно делать конкретные детали.
- Проект-менеджер берёт проект и смотрит, сколько нужно людей, железа, денег и других ресурсов. Делает план работ. ПМ знает, кто будет делать, и сколько это будет стоить.
Потом в обратном порядке проект принимается.
Ещё тут могут участвовать главные инженеры (в местах, где много железа или где требуются комплексные работы) и другие люди. Часто роли совмещаются — например, архитектор может быть как проектировщиком, так и брать на себя часть аналитики. ПМ может быть иногда тимлидом разработчиков. Но модель ролей примерно такая.
Дальше — имхо про то, что нужно от первых трёх ролей.
Архитектор, как это ни странно — человек, который соприкасается с реальным миром. Если рассматривать модель развития разработчик или инженер -> проектировщик -> архитектор (части проекта) -> ведущий архитектор, то сначала реальный мир за стеклом и кажется безопасным. У проектировщика на входе сухие требования старшего коллеги-архитектора. По мере роста по этой цепочке (она не единственно возможная, не обязательно развитие идёт так), нужно всё больше и больше общаться с другими людьми из своей команды и у заказчика.
Появляется необходимость в дополнительных навыках. Сначала идут технические навыки — например, мы, когда отбираем проектировщиков из разработчиков и инженеров, хотим, чтобы они умели внятно смотреть мониторинг больших сетей, групп приложений, умели управлять конфигурацией сети, делать инвентаризацию сети, знали теорию про сетевые модели и протоколы управления. Для молодых архитекторов нужны уже не только навыки сбора данных, но и их отображения, нужно уметь работать с массивами собранного визуально, строить понятные всем в команде схемы.
Опять же, вряд ли проектировщику понадобятся навыки управления сервисдеском или навыки миграций-изменений. А архитектору — очень даже, потому что у процесса есть три стадии: где мы сейчас, как будем жить ближайший год, и где мы будем в конце проекта. И этот год хорошо бы не потерять под девизом «under construction».
По мере роста искушённости архитектора растут требования к знаниям стандартов. Можно начать с ласкового и нежного ГОСТ 34, а потом почитать про принципы размещения ГИС для медицины с персональными и платёжными данными сразу. Там же — методологии проектирования. Проектировщику не нужно знать теорию управления проектами, а архитектор должен понимать, как люди работают (хотя бы на уровне понимания, что такое ошибка планирования). Ведущий архитектор должен уметь быть ПМ'ом при необходимости, но никогда не делать такую работу.
А дальше начинается нестандартное и часто недооцениваемое. Вот, например, зачем нормальному ИТ-специалисту навыки выступлений и проведения презентаций? А они нужны, хотя бы базовые. Для начала — чтобы не начинать объяснение новой системы словами:
— Вы здесь все блаженные идиоты. Смотрите, что мы будем делать.
Реальный случай, кстати. Самое главное — человек ответил за слова и доказал, почему именно они такие люди. Но исполнители после такого начала не горели желанием работать. На самом деле, навыки презентаций нужны не для этого, а для того, чтобы объяснять свои задумки остальным в команде. Там есть несколько базовых вещей, которые очень берегут всем время.
Проектировщику и обычному архитектору, по идее, не надо знать много про продажи. Ведущему — надо, он должен был хоть раз продать ИТ-решение. Потому что тогда он будет знать, на каком языке говорит бизнес. И это будет не «некоторые риски повышения FRR навигационной системы», а «если не поменяем вот это — у вас будет полный самолёт трупов на полосе». Есть небольшая разница в убедительности и точности донесения данных. Очень близко лежит навык выбора перспективных продуктов, когда ничего непонятно про технологию (если смог выбрать сам, то знаешь, что заказчик оказывается в похожей ситуации, когда архитектор показывает пару вариантов).
Нужен навык аудита чужой инфраструктуры. Это чтобы уметь понимать, что важно, а что нет. По стандарту любой может, а вот с пониманием, что в прикладном уровне важнее, и где можно смириться с некоторыми особенностями инфраструктуры и проекта — лишь бы работало, как надо бизнесу — уже нет.
Очень важный навык в выборе проектного решения — умеет человек обосновывать выбор или нет. Если оценка делается по цене, надёжности, масштабируемости и другим факторам в совокупности — это уже рациональный проектировщик. А если оценка делается с учётом всех возможных сценариев, собранных аналитиком, — это ведущий архитектор. Почему? Потому что ещё надо уметь выявлять зависимости проекта, его риски и точные требования. Выявлять — это не когда ты внедрил и узнал, что чего-то не хватает, а когда заранее знал, что будет, и заранее же подготовился. За пару лет. Здесь ведущий архитектор отличается от своего более прикладного коллеги тем, что думает об этом всегда и во всём.
Вообще, вот это — подготовиться заранее и продумать все варианты — наверное, самое главное отличие профессионала от человека, способного спроектировать систему. Архитектору надо учесть всё: и возможные нетрадиционные использования, и защиту от дурака, и продумать точки отказов, переходный процесс. Упрощённая аналогия такая: если вы играли в градостроительные стратегии, то знаете, что иногда лучшая архитектура на «через 10 лет» бывает крайне контринтуитивной. Нужно сначала построить город, а потом его отрефакторить, чтобы понять, как надо правильно. У архитектора такой роскоши нет — строительство и рефакторинг идут в голове, а в работу берётся уже оптимизированная модель. Архитектор — он думает про концепцию и влияние на смежные системы, о назначении, применимости и выгодах.
Важны навыки формулировки техтребований и техзаданий. А ещё — оценки рисков и изменений. Если человек работал только с проектами до, скажем, 50 дней — навыки оценки, скорее всего, недостаточные. На реально больших проектах есть свои особенности, связанные со спецификой заказчика и тем, что при большом накоплении обычных погрешностей уже не получается «за полчаса вечером доделать». Точнее, время — это очень ограниченный ресурс, и лишнее рабочее время из ниоткуда не появляется.
Подготовка разных планов — мало иметь план по своему подразделению, ещё готовятся ресурсные планы (независимо от принадлежности к подразделениям). Это снимает необходимость контроля плана целого чужого подразделения, — понимать компетенции и возможности команды надо.
Разработка документации — просто полезный навык, нужен в любой стадии. Ещё он здорово дисциплинирует в плане системного .
Декомпозиция работ — вроде бы ПМ'ный навык, но на деле это задача архитектора. Проект-менеджер сам этого сделать не сможет, поскольку не обладает достаточными компетенциями в проектируемой системе, и он просто собирает информацию с архитектора, проектировщиков и инженеров, оформляет в виде календарного плана и аккуратно контролирует выполнение, при необходимости мотивируя команду. Да, проджекты часто достаточно хорошо подкованы, чтобы понимать, что откуда растёт, но правильную декомпозицию делает именно архитектор.
Навыки делового общения — если ведущий архитектор этого не умеет, то он очень быстро перестаёт быть ведущим, поскольку с ним серьёзные люди не разговаривают. Потому что одно дело высказать мнение о системе со словом «жопа» в середине в курилке, а другое — то же самое вице-президенту европейской компании. Плюс нужен беглый английский для общения с вендорами. Печень и сохраняются в первозданном виде. Хотя, например, я часто в процессе встречаюсь с тем, что «сейлзы» как раз знают, на какие встречи нужен архитектор, чтобы рисовать в воздухе правильные узоры пальцами — и берут с собой к заказчику.
Из «общечеловеческих» навыков обычно при назначении роли оцениваются отзывы предыдущих руководителей человека по трудовой биографии. Нужна нацеленность на результат: не сдать систему, а решить задачу. «Всё сделано по ТЗ, но не работает» — это не решение задачи.
Очень важный критерий — любознательность: как правило, если человек сам ищет новые знания и сам учится, это повод задуматься, зачем же он живёт. Значит, ему не всё равно (ну или он готовиться сменить компанию, гы-гы). Архитектору должно быть не всё равно больше всех.
Важно управление временем: для проектировщика — определение приоритетов в духе коротких спринтов (получил задачу — сделал — сдал — получил новую), а вот для архитектора — уже самому определить сроки своих задач, их приоритеты — и самому всё сделать правильно. И ещё умение принимать решения в условиях недостатка времени, дефицита ресурсов и когда всё вокруг горит: и велосипед горит, и костыли горят, и ты горишь. «Вытянутый» проект, когда что-то пошло не так, — это не только километр нервов и недосыпы, но и шанс стать круче, поняв что-то для себя о том, как действительно решаются задачи в реальном мире.
Вот примерно так. Повторюсь: это суровое имхо, но моя школа у опытных товарищей показала, что расти надо примерно в эту сторону. И чего-то похожего я жду от своих коллег по направлениям на проектах.
Поэтому, как я уже говорил, быть архитектором и напряжно, и интересно. Особенно интересно стало в последние годы, когда появились инфраструктуры, которые можно изменять относительно быстро — в частности, на базе облаков. Например, в нашем облаке Техносерв архитекторы нужны почти на каждый переезд — для многих это возможность не только перенести инфраструктуру в облако, но и сразу отрубить «хвост» из всякого легаси и тянущихся костылей, спроектировав систему правильно — раз уж всё равно она меняется.
Если вдруг вы хотите стать архитектором, а у вас в компании есть не очень-то нужные вам курсы — задумайтесь. Очень многие компетенции связаны с такими базовыми вещами, как управление проектами и переговоры. Хоть это больше история ПМ’а или «сейлза», вам она тоже может неожиданно пригодиться.
Это материал нашего архитектора Александра Шубина. Вот его прошлый пост про архитектора: как выглядит его работа.
Автор: TS_Cloud
