Роли в проекте выглядят так:
- Аналитик слышит от бизнеса задачу в духе «нам надо работать быстрее» и идёт выяснять, что для этого нужно. Долго ковыряется и узнаёт, например, что производству нужна более простая или прозрачная схема процесса обработки заказов. Обсуждает с командой. Бизнес решает делать. Аналитик бросает в архитектора требованиями к новой системе. Аналитик узнаёт, к чему надо идти.
- Архитектор смотрит на требования, смотрит на систему, удивляется, смотрит ещё раз туда-сюда — и после этого ставит точное техническое задание. Архитектор видит, что нужно делать.
- Проектировщик — самый счастливый человек. Он берёт требования архитектора и просто лабает их до уровня детального проекта системы. Проектировщик знает, как нужно делать конкретные детали.
- Проект-менеджер берёт проект и смотрит, сколько нужно людей, железа, денег и других ресурсов. Делает план работ. ПМ знает, кто будет делать, и сколько это будет стоить.
Потом в обратном порядке проект принимается.
Ещё тут могут участвовать главные инженеры (в местах, где много железа или где требуются комплексные работы) и другие люди. Часто роли совмещаются — например, архитектор может быть как проектировщиком, так и брать на себя часть аналитики. ПМ может быть иногда тимлидом разработчиков. Но модель ролей примерно такая.
Дальше — имхо про то, что нужно от первых трёх ролей.
Архитектор, как это ни странно — человек, который соприкасается с реальным миром. Если рассматривать модель развития разработчик или инженер > проектировщик > архитектор (части проекта) > ведущий архитектор, то сначала реальный мир за стеклом и кажется безопасным. У проектировщика на входе сухие требования старшего коллеги-архитектора. По мере роста по этой цепочке (она не единственно возможная, не обязательно развитие идёт так), нужно всё больше и больше общаться с другими людьми из своей команды и у заказчика.
Появляется необходимость в дополнительных навыках. Сначала идут технические навыки — например, мы, когда отбираем проектировщиков из разработчиков и инженеров, хотим, чтобы они умели внятно смотреть мониторинг больших сетей, групп приложений, умели управлять конфигурацией сети, делать инвентаризацию сети, знали теорию про сетевые модели и протоколы управления. Для молодых архитекторов нужны уже не только навыки сбора данных, но и их отображения, нужно уметь работать с массивами собранного визуально, строить понятные всем в команде схемы.
Опять же, вряд ли проектировщику понадобятся навыки управления сервисдеском или навыки миграций-изменений. А архитектору — очень даже, потому что у процесса есть три стадии: где мы сейчас, как будем жить ближайший год, и где мы будем в конце проекта. И этот год хорошо бы не потерять под девизом «under construction».
По мере роста искушённости архитектора растут требования к знаниям стандартов. Можно начать с ласкового и нежного ГОСТ 34, а потом почитать про принципы размещения ГИС для медицины с персональными и платёжными данными сразу. Там же — методологии проектирования. Проектировщику не нужно знать теорию управления проектами, а архитектор должен понимать, как люди работают (хотя бы на уровне понимания, что такое ошибка планирования). Ведущий архитектор должен уметь быть ПМ'ом при необходимости, но никогда не делать такую работу.
А дальше начинается нестандартное и часто недооцениваемое. Вот, например, зачем нормальному ИТ-специалисту навыки выступлений и проведения презентаций? А они нужны, хотя бы базовые. Для начала — чтобы не начинать объяснение новой системы словами:
— Вы здесь все блаженные идиоты. Смотрите, что мы будем делать.
Реальный случай, кстати. Самое главное — человек ответил за слова и доказал, почему именно они такие люди. Но исполнители после такого начала не горели желанием работать. На самом деле, навыки презентаций нужны не для этого, а для того, чтобы объяснять свои задумки остальным в команде. Там есть несколько базовых вещей, которые очень берегут всем время.
Проектировщику и обычному архитектору, по идее, не надо знать много про продажи. Ведущему — надо, он должен был хоть раз продать ИТ-решение. Потому что тогда он будет знать, на каком языке говорит бизнес. И это будет не «некоторые риски повышения FRR навигационной системы», а «если не поменяем вот это — у вас будет полный самолёт трупов на полосе». Есть небольшая разница в убедительности и точности донесения данных. Очень близко лежит навык выбора перспективных продуктов, когда ничего непонятно про технологию (если смог выбрать сам, то знаешь, что заказчик оказывается в похожей ситуации, когда архитектор показывает пару вариантов).
Нужен навык аудита чужой инфраструктуры. Это чтобы уметь понимать, что важно, а что нет. По стандарту любой может, а вот с пониманием, что в прикладном уровне важнее, и где можно смириться с некоторыми особенностями инфраструктуры и проекта — лишь бы работало, как надо бизнесу — уже нет.
Очень важный навык в выборе проектного решения — умеет человек обосновывать выбор или нет. Если оценка делается по цене, надёжности, масштабируемости и другим факторам в совокупности — это уже рациональный проектировщик. А если оценка делается с учётом всех возможных сценариев, собранных аналитиком, — это ведущий архитектор. Почему? Потому что ещё надо уметь выявлять зависимости проекта, его риски и точные требования. Выявлять — это не когда ты внедрил и узнал, что чего-то не хватает, а когда заранее знал, что будет, и заранее же подготовился. За пару лет. Здесь ведущий архитектор отличается от своего более прикладного коллеги тем, что думает об этом всегда и во всём.
Вообще, вот это — подготовиться заранее и продумать все варианты — наверное, самое главное отличие профессионала от человека, способного спроектировать систему. Архитектору надо учесть всё: и возможные нетрадиционные использования, и защиту от дурака, и продумать точки отказов, переходный процесс. Упрощённая аналогия такая: если вы играли в градостроительные стратегии, то знаете, что иногда лучшая архитектура на «через 10 лет» бывает крайне контринтуитивной. Нужно сначала построить город, а потом его отрефакторить, чтобы понять, как надо правильно. У архитектора такой роскоши нет — строительство и рефакторинг идут в голове, а в работу берётся уже оптимизированная модель. Архитектор — он думает про концепцию и влияние на смежные системы, о назначении, применимости и выгодах.
Важны навыки формулировки техтребований и техзаданий. А ещё — оценки рисков и изменений. Если человек работал только с проектами до, скажем, 50 дней — навыки оценки, скорее всего, недостаточные. На реально больших проектах есть свои особенности, связанные со спецификой заказчика и тем, что при большом накоплении обычных погрешностей уже не получается «за полчаса вечером доделать». Точнее, время — это очень ограниченный ресурс, и лишнее рабочее время из ниоткуда не появляется.
Подготовка разных планов — мало иметь план по своему подразделению, ещё готовятся ресурсные планы (независимо от принадлежности к подразделениям). Это снимает необходимость контроля плана целого чужого подразделения, — понимать компетенции и возможности команды надо.
Разработка документации — просто полезный навык, нужен в любой стадии. Ещё он здорово дисциплинирует в плане системного мышления.
Декомпозиция работ — вроде бы ПМ'ный навык, но на деле это задача архитектора. Проект-менеджер сам этого сделать не сможет, поскольку не обладает достаточными компетенциями в проектируемой системе, и он просто собирает информацию с архитектора, проектировщиков и инженеров, оформляет в виде календарного плана и аккуратно контролирует выполнение, при необходимости мотивируя команду. Да, проджекты часто достаточно хорошо подкованы, чтобы понимать, что откуда растёт, но правильную декомпозицию делает именно архитектор.
Навыки делового общения — если ведущий архитектор этого не умеет, то он очень быстро перестаёт быть ведущим, поскольку с ним серьёзные люди не разговаривают. Потому что одно дело высказать мнение о системе со словом «жопа» в середине в курилке, а другое — то же самое вице-президенту европейской компании. Плюс нужен беглый английский для общения с вендорами. Печень и мозг сохраняются в первозданном виде. Хотя, например, я часто в процессе встречаюсь с тем, что «сейлзы» как раз знают, на какие встречи нужен архитектор, чтобы рисовать в воздухе правильные узоры пальцами — и берут с собой к заказчику.
Из «общечеловеческих» навыков обычно при назначении роли оцениваются отзывы предыдущих руководителей человека по трудовой биографии. Нужна нацеленность на результат: не сдать систему, а решить задачу. «Всё сделано по ТЗ, но не работает» — это не решение задачи.
Очень важный критерий — любознательность: как правило, если человек сам ищет новые знания и сам учится, это повод задуматься, зачем же он живёт. Значит, ему не всё равно (ну или он готовиться сменить компанию, гы-гы). Архитектору должно быть не всё равно больше всех.
Важно управление временем: для проектировщика — определение приоритетов в духе коротких спринтов (получил задачу — сделал — сдал — получил новую), а вот для архитектора — уже самому определить сроки своих задач, их приоритеты — и самому всё сделать правильно. И ещё умение принимать решения в условиях недостатка времени, дефицита ресурсов и когда всё вокруг горит: и велосипед горит, и костыли горят, и ты горишь. «Вытянутый» проект, когда что-то пошло не так, — это не только километр нервов и недосыпы, но и шанс стать круче, поняв что-то для себя о том, как действительно решаются задачи в реальном мире.
Вот примерно так. Повторюсь: это суровое имхо, но моя школа у опытных товарищей показала, что расти надо примерно в эту сторону. И чего-то похожего я жду от своих коллег по направлениям на проектах.
Поэтому, как я уже говорил, быть архитектором и напряжно, и интересно. Особенно интересно стало в последние годы, когда появились инфраструктуры, которые можно изменять относительно быстро — в частности, на базе облаков. Например, в нашем облаке Техносерв архитекторы нужны почти на каждый переезд — для многих это возможность не только перенести инфраструктуру в облако, но и сразу отрубить «хвост» из всякого легаси и тянущихся костылей, спроектировав систему правильно — раз уж всё равно она меняется.
Если вдруг вы хотите стать архитектором, а у вас в компании есть не очень-то нужные вам курсы — задумайтесь. Очень многие компетенции связаны с такими базовыми вещами, как управление проектами и переговоры. Хоть это больше история ПМ’а или «сейлза», вам она тоже может неожиданно пригодиться.
Это материал нашего архитектора Александра Шубина. Вот его прошлый пост про архитектора: как выглядит его работа.
Комментарии (18)
Gruxon
19.12.2017 11:16+1Речь, вероятно про архитектуру инфраструктуры. Здесь архитектор работает с ИТ-подразделением заказчика. Видимо поэтому вы «пустили вперёд» аналитика, а затем уже архитектора. Если Архитектор с большой буквы «А» и действительно системный (системный подход) далее СА, то аналитик для него такой же ресурс, как и проектировщик. Он получает задачу от СА на исследование предметной области заказчика на уровне бизнеса (процессы, цели, задачи). На основании результатов, СА предлагает верхнеуровневое решение декомпозированное по задачам для проектировщиков.
Главные задачи, которые решает СА:
1. Соответствие решения(результата проекта) требованиям заказчика (решение бизнес-задачи заказчика)
2. Декомпозиция работ между исполнителями (собственными и подрядными) и авторский надзор
3. Контроль работоспособности и качества решения в целом
4. Оптимизация стоимости решения
В остальном соглашусь, особенно про структуру проекта и план. Без СА РП не в состоянии управлять сложным комплексным проектом.
TS_Telecom
19.12.2017 11:26-1Вокруг понятия «системный архитектор» существует много терминологической путаницы, более связанной с личным кругозором или комплексом решаемых задач теми, кто его употребляет. Поэтому сразу же следует отметить, что термин «системный» может происходить от двух понятий — собственно система и системный подход, что в современном мире отнюдь далеко не одно и то же. Поэтому при любом разговоре о системных архитекторах (а это весьма важная тема для всех сегментов рынка) следует вначале уточнить, о каких именно архитекторах идет речь.
Помимо специалистов по конкретным решениям конкретных поставщиков можно встретить архитекторов по конкретным технологиям и по сервисам, по безопасности и по приложениям, по конкретным направлениям или по какой-либо предметной области, по телекоммуникациям и по ИТ, по системам управления и по ПО, по ИТ- и по бизнес-процессам, по инфраструктуре и по интеграции, по технике и по функциональным решениям. Локально каждого из них могут даже называть системным архитектором, но это будет соответствовать истине только в случае, если кроме ниши, в которой работает данный архитектор, в проекте ничего больше нет. В противном случае кто-то другой должен будет находиться на вершине, с которой виден весь проект во всем разнообразии решаемых задач. Это и будет «настоящий» системный архитектор.
А вот знать он должен, прежде всего, что такое системный подход и системный анализ, а также обладать системоинженерным мышлением.
Что касается системной инженерии, то это способы создания успешной системы (то есть удовлетворяющей все потребности заказчиков, пользователей и прочих имеющих отношение к системе стейкхолдеров) на базе междисциплинарного подхода, означающего работу с различными инженерными специальностями.
Система может представлять собой все что угодно от комплекса информационных систем до целых промышленных предприятий (промышленных групп) со всеми входящими, включая технологические и производственные процессы, логистику, бизнес-процессы, а также оборудование и здания. Междисциплинарный подход подразумевает работу отнюдь не только исключительно с инженерными специальностями, а вообще с любыми специальностями, которые будут необходимы для реализации той или иной системы (проекта).
Помимо указанного системному архитектору необходим опыт как реализации успешных систем, так и ошибок (разумеется, не только своих). Поэтому на становление настоящего системного архитектора порой уходит целая жизнь.
Ничуть не пытаясь хоть как-то принизить значение и достижения множества молодых специалистов, грезящих превращением в настоящих системных архитекторов, «редкая птица» из последних бывает моложе 30 лет.
Поэтому чтобы стать настоящим системным архитектором надо учиться, учиться и еще раз учиться!
KorP
19.12.2017 11:32Вот очень хочется мне найти себе наставника в виде опытного СА, да у нас таких в общем то и нет, а учиться у кого то надо :(
sshmakov
19.12.2017 12:32Хотя, например, я часто в процессе встречаюсь с тем, что «сейлзы» как раз знают, на какие встречи нужен архитектор, чтобы рисовать в воздухе правильные узоры пальцами — и берут с собой к заказчику.
Как это знакомо
Вот у нас как раз сидит Петров, он наш лучший специалист в области рисования красных линий. Мы его специально пригласили на совещание, чтобы он высказал свое компетентное мнение.
InstaHeat
19.12.2017 14:56+1Хорошо бы сделать чек-лист компетенций архитектора, с комментариями. Это покроет запрос тех, кто желает развиваться, да и для проверки и выявления слабых мест удобно.
Я бы почитал подобное, но сам написать не могу — некомпетентен
vdeneko
19.12.2017 18:22Архитектор смотрит на требования, смотрит на систему, удивляется, смотрит ещё раз туда-сюда — и после этого ставит точное техническое задание.
Я как-то был всегда уверен, что Техническое Задание пишет Заказчик, а не Исполнитель…
Хотя если нацеленность на успех в проекте, то можно и помочь ему написать ТЗ до тендера. Там и смотреть на требования становится легче и сжатые сроки сразу соблюдаются.InstaHeat
20.12.2017 09:58Техническое задание пишет тот, насчет кого договорились. Но чаще исполнитель, как полностью владеющий темой (знанием о возможностях продукта), и потом согласовывается.
Зависит от многих факторов. Например, если заказчик обращается к исполнителю с разработкой новой системы, то ТЗ может исходить от него. Или если ему нужно реализовать подсистему у него уже есть ряд наследных требований
sshmakov
20.12.2017 10:20Я как-то был всегда уверен, что Техническое Задание пишет Заказчик, а не Исполнитель…
Я как-то чаще видел заказчиков, которым ТЗ пишет исполнитель. Некоторым и тендерные требования приходилось писать, по которым будущий исполнитель выбирался…
valis
20.12.2017 10:27Про презентации нужно написать отдельный пост. Я так и не нашел решение делемы, которую попробую пояснить в следующем абзаце:
Как архитектор решения описываю все что касается и будет (или не будет) входить в скоуп проекта. С другой стороны нужна декомпозиция задач для отдельных групп разработки. Задачи спускаются проектировщикам и те описывают детальное ТЗ, которое возвращается мне на проверку. Задачи проектировщикам достаточно узкие, но чтоб правильно проектировать систему нужно знать не только на вопрос «Что?» (по сути это есть в постановке задачи) но и «Зачем?» (все что снаружи).
Так вот — общая презентация проекта всем разработчикам это абсолютно провальное мероприятие (по крайней мере у меня) т.к никто не понимает что из этого его и не может внятно сформулировать вопросы. Презентация задач для проектировщика конкретной системы тоже не всегда удачно — проектировщик часто либо выпрашивают малейшие детали — фактически мы проектируем систему вместе либо проектируют систему не правильно т.к не смогли словить контекст (я возвращаю их ТЗ обратно и так пару десятков итераций что равно по времени совместному проектированию).
Пару раз делал эксперимент описывать задачу вместе с контекстом, при этом пытаясь выбрать правильный контекст. Тут ситуация с проектированием по лучше — проектировщик знает все что ему необходимо в отдельном документе. Но на выбор нужного контекста, описание и презентацию задач каждой группе разработки в отдельности уходит слишком много времени.
Хотелось бы чтоб автор статьи поделился своим опытом в данном направлении.
P.s Если у вас есть позиция архитектора в Украине с экспертизой в области ERP систем ритейла я бы рад сотрудничать с вами
vadimpl
21.12.2017 09:52Предположу причины происходящего.
1. Во время презентации своей команде архитектор недостаточно чётко формулирует цели как всего проекта, так и задач для групп. Возможно, не может перевести со своего языка на язык исполнителей.
В статье проектировщики показаны примитивно: "получил задачу — сделал — сдал — получил новую" — такого не бывает. В целом, разложение цепочки задействованных в проекте ролей показано однобоко. Каждая роль в себя включает и архитектора, и аналитика, и менеджера, и исполнителя. Только области применения соответствующих навыков (знаний,...) разная. Применительно к проектировщику — как только он получит понятную ему цель — дело сделано на 90%, количество итераций с СА для принятия своих решений будет в пределах разумного.
Отсюда вывод. Задача СА (как и любой другой роли) понятным языком ясно обозначить цель.
2. По какой-то причине проектировщики немотивированы работать в полную силу. Профессиональный проектировщик способен построить своё общение (вспоминаем качества, необходимые каждой роли) с СА так, что даже при малоопытном СА проектировщик быстро получит необходимое инфо для своей работы.
Да, бывают проектировщики в чистом виде исполнители (а нужны ли вам такие?). Но чаще — что-то неладно в датском королевстве.valis
21.12.2017 10:06По пункту 1 на счет целей вы в точку — у нас проблема со стратегией, соответственно очень сложно ответить на вопрос «Почему?» (мы должны принять ту или иную архитектурную альтернативу, потратить кучу времени одной команды, хотя другая команда в свое системе справится с задачей быстрее и т.д)
TS_Cloud Автор
21.12.2017 09:55По нашему опыту нужно обязательно делать общую встречу, можно презентацию, для всей рабочей группы на старте проекта. По ходу проекта обязательно нужно собираться и делиться статусами. Важно поддерживать у всего коллектива одинаковое понимание ситуации, задач заказчика, последних вводных и так далее. В дополнение к этим встречам нужно ставить отдельное ТЗ каждому участнику. То есть не нужно выбирать что-то одно. И ещё обязательно нужно делать матрицу, где весь проект бить на задачи, каждую задачу приписывать конкретному исполнителю. Эта матрица всегда должна быть доступна всем участникам. Как-то так. А насчет вашего P.S., предлагаем вам написать сюда ISapozhnikova@technoserv.com, это мейл нашей коллеги из HR.
Legion21
4. ПМ никогда не узнает точно за сколько по времени можно выполнить задачу)
TS_Cloud Автор
Кажется, мы не до конца поняли вопрос. Раскройте вашу мысль, пожалуйста.
mklochkov
Вольно цитирую супругу, она ПМ в разработке: «Конечно, я сама никогда не определю, за сколько времени можно запрограммировать ту или иную фичу. Но я знаю всех своих разработчиков, и знаю, что от каждого ожидать. Паша оценивает срок относительно точно, а то, что оценил Юра, всегда нужно умножать на два».