Кодер -> Программист -> Архитектор?

Question

[Алиса Васильева]

Предыстория

В одном из докладов на небольшой it-конференции однажды была описана градация развития программиста по уровню решения задач (по памяти формулировка неточная):

1. Написание кода - когда руководитель дает четкое описание, которое нужно перевести в код, со входными и выходными данными
   
2. Решение небольших задач - когда необходимо самому продумывать способ решения данной задачи (это может быть метод, модуль и т.п.)
   
3. Решение задач бизнеса - когда нужно спроектировать решение проблемы бизнеса, взаимодействовать с людьми вовлеченными в это, на выходе может получиться не просто модуль, а отдельный проект со своими правилами
   
4. Решение задач пользователей - планирование развития программного продукта, взаимодействие с большей аудиторией.
   
5. Решение глобальных задач - то, что "меняет мир", написание инструментария, платформы для решения более широкого списка задач
   

Из этого выходит, что если уровень "написания кода" обозначает кодера, уровень "решения задач" - "программиста", то следующий уровень - "решение задач бизнеса" - будет соответствовать "архитектору".
Является ли переход программист-архитектор последовательным профессиональным ростом?

Как происходит это развитие? Некоторые советуют часто менять работу, чтобы пробовать разные проекты в разных предметных областях, изучать их и черпать понимание архитектуры оттуда. Но этот способ не для всех.
Также очевидно, что только хорошей технической подготовки не хватит для построения с нуля архитектуры ИС для бизнеса.
Какие нужны дополнительные знания для этого и где/как их эффективнее всего получить? В какую сторону гуглить, с чего начинать?

Comments

[Алиса Васильева]

SmInc, Тут речь скорее об автоматизации процессов в бизнесе. Четвертый и пятый уровень для меня тоже выглядят несколько размыто, но, думаю, они больше относятся уже к развитию существующих проектов и это задача не для одного человека а для команды (с маркетологами и прочим).
Мой вопрос все же о третьем уровне.

[Константин Нагибович]

nyarloc, третий уровень из вашего вопроса - это очень интересная деятельность. Я, в качестве фриланса, занимаюсь подобным. Очень круто когда твои решения удачно вписываются в бизнес и дают ощутимую выгоду, которая выражается конкретными суммами в доходе компании-заказчика.

[Константин Нагибович]

Мне кажется, что 3 и 4 пункты надо местами поменять.

[Евгений Ромашкан]

Мне кажется, что 4 и 5 пункт это и есть решение задач бизнеса

[kreatr]

Архитектор это тот кто проектирует здания и сооружения, а все остальное надо уточнять дополнительными словами.
Тот архитектор которого вы имеете ввиду это программный архитектор. Или нужно другое название этой профессии.

[Валентин]

5~7 лет назад ещё не было такого понятия как архитектор программного обеспечения. Запасаемся попкорном и смотрим, как зп программистов падают до 30-40 тр, а потом этот функционал отдают на аутсорс.

Answer 1

[Saboteur]

Архитектор - в первую очередь опыт работы, в идеале в разных проектах, чтобы понимать на практике разницу между реализацией разных SDLC.

Название Waterfall или Scrum - это просто названия без конкретной реализации. Можно реализовать отличный Waterfall и все будут довольны, можно реализовать ужасный Scrum и все развалится. Поэтому опыт разных проектов помогает увидеть именно разные реализации.

Архитектор, бизнес-аналитик и менеджер - три звена, которые создают основу работы проекта, каждый со своей стороны.
Бизнес-аналитик - должен максимально разбираться в бизнесе заказчика, чтобы понимать значение требований и переводить их для исполнителей.
Архитектор - должен как минимум немного разбираться в бизнесе, но его основная задача - решить как воплощать требования бизнеса. Определять железо, технологии, требования. Говорить, что "вот для этого нужно использовать 10 этого и 20 этого, и использовать вот такие языки, библиотеки, платные решения". Техническое hi-level видение проекта.
Менеджер - по согласованию с бизнес-аналитиком и архитектором должен решать кадровые вопросы. Количество людей, качество людей, работу команды, тайминги, офис и оборудование - все денежные вопросы. Отчеты. Договариваться, убеждать заказчика о ценах и сроках. Выбивать новые задачи и развивать проект. Следить за настроением в команде.

Переход программист-архитектор не всегда последователен. Он должен быть инициирован программистом.

Программист может остаться просто сеньор программистом, может стать тим-лидом, тратя часть времени на менджмент команды но все-равно основную часть времени оставляя на кодинг.

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

Comments

[hx510b]

Добавлю, что тимлид и архитектор - это разные направления деятельности.

Answer 2

[Ambrosian]

Кодер - это просто джун.
Ведомое существо, которого ни в коем случае нельзя пускать на свободную от контроля область, а то он такого накодит, что потом перекодивать заново.

Архитектор - не знаю где вы начитались. Любой разработчик с опытом - в той или иной мере архитектор. В современном высококонкурентном мире держать себе выделенных архитекторов могут позволить немногие конторы. В подавляющем большинстве случаев архитектор - это такой же разработчик.

Answer 3

[Krava]

В последние 2 года только и вижу отсутствие архитектора в команде, а для меня это ключевое звено без которого творится часто хаос., многие компании пренебрегают архитекторами пытаясь сэкономить.

Comments

[Ambrosian]

Выделенные архитекторы не нужны.
Толковые разработчики - сами должны уметь делать архитектуру.

[Dave]

Ambrosian, Да по причине того, что так можно сэкономить

[stratosmi]

Dave,

Да по причине того, что так можно сэкономить

По причине того, что иначе - тупо.
Выделенному архитектору большую часть времени делать нечего.
Вы считаете достоинством компании возможность платить зарплату человеку, который 90% времени не нужен?

[Saboteur]

Ambrosian, Dave, stratosmi,
Зависит от размера проекта и размера команды.
Если разработчиков 20+, то архитектор уже необходим. Даже если в проекте есть другие разработчики, должен быть человек, который скажет последнее слово, а не вечные споры.

[stratosmi]

Saboteur,

Если разработчиков 20+, то архитектор уже необходим. Даже если в проекте есть другие разработчики, должен быть человек, который скажет последнее слово, а не вечные споры.

Архитектор необходим и на проекте, где трое работают.
Только вот не выделенный. Прекрасно совмещается с разработкой.

[Sanes]

В небольших командах эту работу выполняет тимлид.

[Ambrosian]

Dave, Sanes,

В небольших командах эту работу выполняет тимлид.

Скажите, ТЕОРЕТИКИ, а вам доводилось работать в огромных командах, где без выделенного архитектора никуда?

[Sanes]

Ambrosian, и где здесь противоречие? Теоретик...

[Ambrosian]

Sanes,

и где здесь противоречие?

Подавляющее большинство участников Тостера, если и работала в командах - то в мелких, где выделенного архитектора вообще не надо.

В реальности происходит несколько иначе, чем в вашем воображении.

Вы пишете то, о чем не знаете.
Выдумывайте, одним словом.

Answer 4

[xmoonlight]

Является ли переход программист-архитектор последовательным профессиональным ростом?

Да.
В сторону понимания процессов и создания баз данных. (это в самом начале)
Затем - создание схем движения данных по узлам инфраструктуры.
И расчёты нагрузок и узких мест в системе.
После - уже к построению классов и изучению паттернов проектирования.

Answer 5

[asd111]

Обычно должности именно архитектора нет и его обязанности выполняют senior программисты совместно когда они приходят на митинг и обсуждают архитектуру. Самый умный делает начальный план проекта, а потом на совместном обсуждении можно что то добавить или убрать. И такие совместные обсуждения в больших проектах бывают каждую неделю чтобы все были в курсе архитектуры, а не только архитектор.
Т.е. программист редко становится именно архитектором, поскольку такая вакансия большая редкость и обычно рост происходит по двум вариантам:
1. программист, старший программист(senior), директор тех. отдела.
2. программист, менеджер проекта, директор продукта.
В первом варианте больше технической работы, во втором варианте больше финансов и бизнеса. При этом в обоих вариантах на топ должностях очень много общения с людьми.

Answer 6

[Алексей Павлов]

У меня есть личное описание уровней программиста, похожее на указанную градацию:
- Джуниор пишет код так, как понял задачу заказчика
- Миддл пишет код так, чтобы хорошо и правильно решить задачу заказчика
- Синьор пишет так, чтобы сделать будущую задачу заказчика (чтобы код проекта был готов к будущим задачам, без переписывания всего проекта с нуля)

Синьор имеет опыт и понимает, что в дальнейшем понадобится в проекте (если нужно - спросит, если нет, то догадается). Именно синьор может быть архитектором, который занимается инфраструктурой проекта, чтобы другие программисты переиспользовали уже готовые части проекта.
Миддл тоже имеет развитые навыки проектирования архитектуры, но часто работает со средними и большими фичами (частями), а не с системными вещами.
Джуниор делает маленькие задачки, его навыки архитектуры относятся к одному или нескольких связанных классов для текущей задачи. Хороший менеджер подбрасывает задачи чуть сложнее, чтобы дать возможность попрактиковаться в архитектуре.