Comments 23
Архитекторы не нужны - уже разработано много готовой архитектуры для типовых проектов, программисты не нужны - есть же AI, дизайнеры не нужны - готовых бесплатных дизайнов полно, тестеры точно не нужны, во-первых по той же причине, что и программисты, во-вторых есть же Selenium, DevOps еще немного нужны, но им тоже недолго осталось, есть же terraform или helm, а для них уже есть AI. Пора переквалифицироваться в управдомы.
Ещё один кандидат на замену архитектора — это техлид.
В моём понимании техлид работает внутри команды человек на десять, если над продуктом работает десяток таких команд - нужен всё таки отдельный человек, определяющий общую архитектуру.
Ещё один кандидат на замену архитектора — это техлид.
И фару на лоб, чтоб ночью косил.
А если к компании N команд и у каждой свой техлид? Один сишник-хардкорщик, другой ехидный джавист, третий смузи-лоукодер. Собственно вот здесь и нужен архитектор, чтобы правила игры задавал. А на более мелких масштабах он не нужен вообще.
Ну да, архитектор - это про правила взаимодействия разных команд в первую очередь. И никакой agile не убрал необходимости в архитекторе (как и не было необходимости в позиции архитектора в микропроектах на одну небольшую команду).
Но в статье вообще путают активности, роли и позиции. Активности архитектора есть в любом проекте, роль - почти всегда, а позиция нужна уже только при нескольких командах.
Про DDD и архитекторов много референсов, но в крупных компаниях его убивают архитекторы, а небольших нет системной работы над архитектурой.
Хм, вроде бы стратегические паттерны DDD - это как раз работа архитектора (как роли и, иногда, как позиции). Да и выявление UL/BC полезно в проекте любого размера.
В РФ другая практика - TOGAF, карты бизнес возможностей, Корп.Модель данных; иными словами "коты и мыши". На мой взгляд, статья не раскрывает этой подоплёки, а она и содержит в себе суть того зачем нужна роль архитектора и какие формы это может принимать в разных обстоятельствах. Например, если взять банки или телекомы - это огромные департаменты, которые юзают свои фреймворки, и очень часто на практике не стремятся быть ближе к бизнесу, а становятся частью внутреннего сервиса (вопросы к пуговицам есть?). Этим самовоспроизводящимся системам не нужны ни гибкие подходы, ни DDD)) Иными словами, вряд ли есть коллективы больше 200 человек, всеобъемлюще применяющие такие подходы.
Хм, TOGAF и прочее - это скорее про Enterprise Arch, а не про SolArch или SysArch. Да, эта роль возникает только в очень крупных компаниях. Но наличие корпоративного архитектора не значит, что на уровне отдельного продукта внутри департамента не используется DDD. Большие компании - большие, там много что внутри происходит )
в веб-разработке это «здание» не будет закончено никогда. Его просто нет. Как у самураев: нет цели, есть только путь.
напомнило:
Статья крутая, реально написано хорошо, прочитал с интересом.
По выводам (как архитектор 10+ лет):
Уже разработано много готовой архитектуры для типовых проектов — она есть во фреймворках и головах разработчиков
Для простых проектов да, тут действительно - раз-два и понесли. Но даже если таких проектом много в абсолютном исчислении, то с точки зрения относительного вряд ли что-то сильно поменялось
В гибких Agile-командах многие готовы подхватить роль архитектора, например, тимлиды и техлиды.
Вот тут я не совсем понял, причем тут методология. Смотрите, если условно есть гипотетический продукт, который разработан двумя командами по разным методологиям.
в waterfall архитектор принял 90 решений сразу и написал документ, потом еще 10 и чего-то по ходу переписали.
в случае Agile он принял те же 100 решений, но не все сразу. Условно сначала 20, а потом остальные 80
Все тоже самое :)
Суть в том, что в сухом остатке архитектор:
собирает требования
принимает решения
оформляет их в каком-то виде: схемы, пояснения, таблицы, ...
Методология разработки не примет решения сама, и эту работут надо делать. И именно так "собрал" -> "решил" -> "описал". При любой методологии. Я б даже сказал, в любом виде деятельности :)
Из реального примера. Идет проект, заказчик озвучил идею отправки email пользователям в слуучае наступления событий. Там много нюансов, так как мы пишем только новые компоненты к легаси приложению. Надо не просто отправить, а учесть, что старое тоже как-то это делает. Соответственно надо:
посмотреть "а как там делается в старом"
описать вариант с нуля (ничего сложного, но в команде никто AWS сервисом не пользовался)
показать два варианта заказчику и помочь принять решение
сделать рабочий PoC
поставить команде задачу, чтобы она могла появиться в backlog
Безусловно, это может сделать и тим лид. Но тогда, вместо работы над текущими задачами, ему надо это все проделать, а это не 5 минут, и даже не час. А там внутри много нюансов :)
Тут конечно непонятно, может я взял на себя функции лида ... но это такое.
И таких примеров много, особенно если помимо простых технических решений надо чего-то нарисовать и показать, что именно так будет лучше всего (либо залидить совещание, на котором будет принято решение - а иногда бывает не совещание, а полноценное сражениие с подготовкой резервов, тактическими маневрами, заготовленными ловушками и т.д.).
Методология тут вообще не причем, как по мне. Вопрос в том, кто и как принимает решения.
Всё будет работать хорошо, пока не потребуется небывальщина — то, для чего готовых типовых решений нет
Ну смотрите, базовая теория управления проектами определяет проект как "временно́е предприятие, направленное на создание уникального продукта, услуги или результата" (нагло скопировал с интеа). Слово "уникального" там ключевое, потому что все проекты действительно разные. Причина наличия этой разницы проста до безобразия, у всех разные условия, окружающий ИТ-ланшафт, бюджеты и т.д. Архитектор - это 99% не генерация "небывальщины", а скучные выбор между доступными вариантами, иногда их поиск (просто не очень можеть быть приятно, когда ты выбирал между двумя вариантами, а кто-то принес третий, который в 10 раз лучше, поэтому лучше поискать аккуратно). И в одном случае подходит один вариант, а в другом - другой.
Кстати тут ярко проявляется разница между background тим лида и архитектора. Тим лид всегда копает глубже, а архитектор - шире. На большом проекте банально может быть 5 тим лидов. Каждый из них знает свою область лучше чем архитектор (это почти всегда), но собрать всех в кучу обычно легче архитектору из-за широкого кругозора. Условный джавист все будет писать на джава, а архитектор может достать из кармана "тул", с которым все заработает за "5 минут" (просто потому, что у него уже был такой опыт, а не потому что он таким родился).
В маленьких компаниях архитектура, скорее всего, не пойдёт никуда дальше этой компании, и это обойдётся слишком дорого.
Он скорее совмещает. Плюс надо помнить, еще есть:
сейловые активности, куда тоже нужно кому-то из технарей ходить. Это:
показать чего у нас есть
послушать, чего хотят
накидать схем/слайдов на зказачика
поговорить с тех спецом с той стороны
...
конктрактинг
накидать описания, чего делать для компании, так как оценка сама по себе не подсчитается (и да, в Agile контрактинге тоже вам просто так денег не дадут, потому что где-то там в глубине у заказчика конечный бюджет на год и необходимость чего-то выдать к сроку)
накидай требований, если ты на строне закказчика
прочиать/написать свои разделы (если вы думаете, что SoW написал себя сам - сильно ошибаетесь)
...
discovery (если большой проект)
за несколько недель "разпедалить", что надо сделать
расписать перспективы и планы, как будет делаться
провести туевую хучу встреч, написать столько же документов
фактически помочь продать фазу внедрения, так как часто это еще не факт, что случится
Прикол в том, что у проекта внедрения програмного продукта много фаз, а почти на каждой из них архитектор принимает участие. А тим лид часто уже видит фазу "деливери" и думает что детей приносит аист сразу в с ранцем и дневником :)
В целом - архитектор это то, кто закрывает там, где "пусто" в техническом смысле.
У главное - у тим лида есть много своих забот. Он прораб. Если джун пишет фиговый код - сношать будут и джуна, и лида. Возиможно лида не при всех, что правильно ... но точно будут ставить на вид. И это его забота, либо улучшить джуна, либо обосновать почему его надо выкинуть за борт. Пул реквесты - ну а кому еще смотреть? Раскидать таски в команде - он же. Ревью кода, коучинг - все на нем. Ходить еще и "торговать лицом" с заказчиком, сидеть на всех совещаниях, поддерживать менеджера везде, где есть намек на технический вопрос - да он просто не будет иметь столько времени :)
очень грамотный комментарий. архитектор - тот, кто поддерживает целостную модель проекта с пониманием всех деталей и выдает на гора диаграмы поясняющие связность для участников всех уровней. ключевое для всех уровней - одностраничные high level design, используемые в exec level decisions.
чем больше проекты - тем больше уровней вложенности, поэтому в командах на десяток человек этим занимается тех лид, в компаниях с большим количеством проектов выделяют отдельных людей.
togaf и прочие фреймфорки несут определенный смысл, но в основном теряют суть этого определения уходя в формальности, бюрократизация, фокус на форме вместо сути, присущая любой крупной структуре от компаний до государств и церквей.
Уважаемый автор, вы меня извините, но вы не смогли в биохимию. Процессы, связанные с работой нейромедиаторов, не имеют ровным счётом ничего общего с тем, что вы описали.
В моем понимании - архитектор суть человек работающий с требованиями, которых еще не существует. Команда разработчиков, включая тимлида - готова строить при условии что им хотя бы примерно объяснят что именно (где нужны стены, какие заказчик хочет материалы и тд). Заказчик же хочет абстрактно: "ко мне родственники с конем через месяц приедут - сделайте пристройку чтобы их там поселить?". И вот тут нужен опыт и знания архитектора чтобы понять: во-первых, родственники с конем вместе жить не будут - поэтому нужно отдельно жилье для родственников и отдельно - для коня. Дальше надо посмотреть, можно ли быстро растолкать родственников в уже имеющиеся комнаты, а коню сделать огороженный навес (и согласовать такое изменение с заказчиком). Если нельзя - то дать предложения по пристройке (и заодним подумать как ее будут использовать после того как родственники с конем уедут - не сносить же ее). Да и проследить чтобы пристройка не мешала текущей хозяйственной жизни (а в идеале - потом и приносила какой-то дополнительный доход).
Иными словами - архитектор это вам человек, который благодаря своему опыту и насмотренности, "... увидев каплю воды - сможет немедленно сделать вывод о существовании океанов" (C) Стругацкие.
А если техническое задание бизнесом сформулировано точно и исчерпывающе - тут смысла платить архитектору нет, просто надо делать то, что написано.
Аналогично, если бизнес бесконечно богат, и готов постоянно тратить деньги чтобы строить и перестраивать - тоже не надо архитектора. Собрали скрам-команду, завели бэклог и погнали без остановки!
Совет автору - если используете в статье какие-то утверждения из других областей знаний, было бы неплохо про эти утверждения почитать хотя бы википедию. Будет меньше ляпов, из-за которых основную часть текста читать всерьез даже не хочется.
Закон Мура - не закон, и не замедляется, а нейромедиаторов не два, а много десятков, и работают они совершенно не так, как вы тут нафантазировали.
Если же выбросить подобное словоблудие из текста - статью можно сократить до пары содержательных предложений, о которых и можно было бы разговаривать.
Про биохимию как будто всё наоборот.
С чего вдруг разработка ПО идёт на процессах торможения мозга?
А всякие совещания с бизнесом - на разгоне?
На таких совещаниях лично мой мозг отдыхает и никуда не разгоняется. Ибо обсуждение БП - вещь скучная. А выбор движка, заточка под проект - как раз и требует чтобы мозг работал.
Есть такие люди которые думают что совещания - двигатель прогресса, наверно потому что все что они могут это Собирать Совещания (именно с большой буквы). Они наверно и про Эйнштейна будут вам доказывать, что он Теорию Относительности смог придумать, потому что на совещания ходил, а не потому что формулы выводил-перевыводил-преписывал-пересчитывал годами.
Вехи и технологии в ИТ - докер и кубер, дочитал до этого и забил. Уровень компетенции автора понятен.
Про здание, которого нет, и веб-разработку.
Инфраструктура и разработка строят не здание, а заводской цех с конвейером. Или гаражную мастерскую. Но архитектура - в любом случае является средством производства, а то, что на ней реализуется - его (средства) эксплуатацией.
Реализация закона Мура вдолгую на инфраструктуре и ее эксплуатации зависимы, но не корректно их сливать в одну. Чем лучше инфраструктура, тем выше будет плато у разработки.
Есть ли будущее у архитекторов и на кого их можно заменить?