[Анализ и проектирование систем, Программирование] Мама, кажется я архитектор
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Статья направлена на диалог о необходимости архитектора в команде. Она будет интересна тем, кто задумывается о пути своего развития, когда “все дороги уже исхожены”. Когда имеющийся богатый опыт делает твою работу “неэффективной” с точки зрения коллег. Когда тебя уже почти ничего не удивляет и каждый следующий проект это дежа вю. Ты выгораешь.
Кто такой архитектор?
Погуглить на эту тему может каждый самостоятельно. Я постараюсь не быть кэпом и отражу сущность архитектора под необычным углом. Лично мне нравится шуточное определение этой роли:
Архитектор — человек, который способен любому разработчику в команде аргументированно доказать, что его мнение ничего не стоит.
или:
Архитектор — человек, который лучше других знает когда нужно уходить из проекта.
Хотя оба определения шуточные, но они демонстрируют пару ключевых способностей этой роли:
- Широкий кругозор с одновременно глубоким погружением в детали;
- Способность комплексно видеть причинно-следственные связи и возможные результаты развития событий.
За этими пунктами стоит большой опыт. Можно ли обойтись без десятка(ков) лет в профессии, чтобы стать архитектором? Можно. Так же, как стать сеньором С++ через пару месяцев. Все зависит от человека, его способностей и самокритичности.
Если вы сами создавали хотя бы одну программку, вы уже архитектор. Архитектор-джун. Смешно звучит. Хотя….
Если мы возьмем команду примерно равных по опыту разработчиков, кто из них станет архитектором? Тут обычно два сценария:
- каждый сам себе архитектор;
- архитектор тот, кто может внятно доносить свои мысли и преимущества своих решений.
Возможно покажется странным, но первый сценарий более жизнеспособный. Дело в том, что имея конфликт интересов или профессиональный конфликт в команде, можно получить повышение качества продукта. Конечно, жертвуя временем.
А вот второй сценарий может привести к тому, что более талантливый специалист будет попросту задавлен харизмой и софт-скилами самовыдвиженца. И продукт проиграет, получив самоуверенную персону, не терпящую альтернативного мнения.
Поэтому, к важным качествам архитектора относится и:
- Высокий эмоциональный интеллект.
Архитектор должен уметь использовать интеллектуальный ресурс команды, прислушиваться к мнению, настаивать там где нужно, брать на себя ответственность, быть наставником, учиться (много и постоянно), находить компромиссы и уметь заразить команду идеей.
Что должен делать архитектор?
Из стереотипных представлений об архитекторе известно, что он должен рисовать всякие схемы во всяких там нотациях. Бизнес-процессы, требования к системам и т.п. штуки, которые мешают творить разработчикам.
Но это лишь артефакты деятельности. В ходе создания этих артефактов происходит магия, которая и отличает архитектора от плохого художника.
На самом деле, ключевой функцией роли является архитектурный охват. Т.е. осознание того как система функционирует. И совсем не обязательно все должно быть документально выражено. Примером может стать проект, на котором задействован всего один разработчик. Он вполне успешно способен создать основу системы в голове и тут же выразить ее в коде.
Если же в проекте участвует много людей с разными профессиональными векторами, то простое удержание в голове уже недостаточно. Архитектор, это роль, которая должна позволить всем четко понимать конечный технический портрет системы. И для этого требуется наглядное изложение того, что уложено в его голове. Вот тут на помощь приходят кружочки и квадратики.
Часто архитекторы загоняются по нотациям. В целом, это хорошо. Т.к. есть стандартизация представления архитектуры. Но далеко не всегда конечный потребитель архитектуры умеет читать такие нотации. При высоком уровне развития процессов в компании это оправдано. Всех приучаем к стандарту и вперед. Но в стартапах, где нужно оперативно запустить разработку в компании разношерстных высококвалифицированных сеньоров (которые сами все знают), нотации обычно не заходят. Приходится быть ближе к людям. И рисовать понятно. А не умно.
Тем более это станет проблемой, когда нужно будет получить от кого-то из команды его представление о верном архитектурном решении. Человек или не сможет вам его описать или закомплексует. И это фейл архитектора — неспособность использовать интеллектуальный ресурс команды.
Если показалось, что я выше ёрничал, написав в скобках о сеньорах, что они все сами знают, то это не так. Они действительно все сами знают. Часто это люди, разделяющие роль архитектора и разработчика. Но зачастую, у них есть проф-деформация — они тоталитарно проводят свое мнение о необходимом решении. Это связано с тем, что в команде они были (есть) самыми сильными разработчиками. И вынуждены брать на себя ответственность.
Архитектор обязан выстроить с командой доверительные отношения. Я пишу доверительные, а не дружеские или просто хорошие. В понятие доверия я включаю возможные профессиональные конфликты. Но при этом, каждая сторона понимает, что этот конфликт не личный. Каждая из сторон хочет лучшего проекту. И даже если ты уступишь в споре, это не проигрыш, а выраженное доверие использовать решение оппонента.
Архитектор обязан делиться своим опытом и уметь “переваривать” чужой. В команде всегда найдется кто-то с интересным опытом. К сожалению, обычно, этот опыт имеет узкий угол обзора его предпосылок. При выборе стека разработчик может сказать:
- А давайте все сделаем на React! Мы так делали и у нас все получилось!
Сомневаться в этом нет причин. Но это не повод делать также. У проекта на котором он работал есть свои исторические корни и проблемы. Весьма вероятно, что React имеет минусы, о которых разработчик или умалчивает, или не знает.
Умалчивать разработчик может ненамеренно. Возможно он исключительно React использовал до этого. Ему не с чем сравнивать. Случается и обратное. Например, на рынке разработчик React выше оплачивается. На прошлом месте он завидовал коллегам пишущим на React. Но шанса изменить стек не было. Т.е. разработчик имеет исключительно шкурный интерес.
Архитектор обязан рассмотреть предлагаемый опыт. При рассмотрении он должен учесть все детали. Составить свое мнение и аргументированно донести его.
Например, в вопросе выбора элементов стека хорошо зарекомендовал себя документ “Выбор ключевого решения”. В нем, в водной части, описываются требования, ограничения и специальные условия. Затем под эти рамки подбираются и сравниваются решения. В заключении делается мотивированный вывод. Последней фазой является утверждение документа командой.
Это необходимая бюрократия. Подобный выбор будет влиять на успех проекта, если не все время его существования, то длительный промежуток времени. Команда должна быть уверена, что выбор был сделан взвешенно и разделять его.
И конечно, архитектор обязан создавать системы с бизнесом, для бизнеса и ради бизнеса.
Чего не должен делать архитектор?
Самое главное, что не должен делать архитектор — допускать демократию.
Т.е. количественный метод принятия решений. Где любой в равной степени может воздействовать на выбор.
Любое решение должно иметь основания. В какой-то степени, можно допустить случай, когда имеется пара решений с идентичными свойствами и остается только ткнуть пальцем не глядя… но из моего личного опыта этого можно избежать дообследованием.
Случается, что при защите выбранного решения архитектор может столкнуться с тем, что оно не утверждается. По какой-то причине аргументы, определяющие выбор, воспринимаются недостаточными. Это не повод отступать. Требуется дополнить матрицу сравнения неохваченными свойствами. Учесть критику. И идти на второй заход. Третий. В любом случае, документ должен отражать причины выбора. Только так проект гарантирован от флэшбэков и запоздалых разборок. Никакой демократии.
Второе по важности — недопустимо дистанцироваться от бизнеса и разработчиков. Иногда, так хочется пожить в своем идеальном мирке, где все понятно и логично. Но, жизнь сурова. Бизнес стремится развиваться. Нужно уметь слушать идеи бизнеса и понимать вектор их развития. Закладывать в архитектуру концепции, которые позволят решать задачи, еще несформулированные бизнесом.
Держи друга близко, врага еще ближе, а с разработчиком нужно быть одним целым.
Какую бы классную архитектуру не наваял архитектор, если разработчик не видит в ней ценности, он ее похоронит.
Требуется осознавать, что разработчик не смотрит на систему как архитектор. Он фильтрует информацию, стараясь оставить только то, что ему необходимо в его непосредственной деятельности. Не потому, что он злобная сволочь. Просто у него голова забита иной очень важной информацией, помогающей выполнять ему его работу.
Важно уважать это и доносить ровно ту часть информации, в которой он испытывает потребность. Лучший способ — доносить информацию так, чтобы у разработчика возникла та же идея, которую заложил архитектор. В этом случае успех гарантирован.
Архитектор не должен манипулировать бизнесом. Таланты архитектора могут сыграть злую шутку с ним самим и проектом в целом. Он намеренно или ненамеренно может стать частью системы принятия решений бизнесом.
Опасно, когда бизнес начинает ориентироваться на мнение архитектора в несвойственных ему областях. Риск и асистемность в молодом бизнесе необходимое зло. Юные менеджеры-стартаперы, поддавшиеся на манящие песни архитектора о том, что все должно быть системно, могут с удивлением обнаружить, что затраты на операционку (поддержание системы) превосходят бизнес-профиты.
Где искать архитектора?
У нас в компании встал вопрос поиска архитектора на проект. Как водится нужно описать вакансию. Требования относительно очевидны:
- Широкий, актуальный и релевантный опыт в ИТ;
- Лидерские качества;
- Развитые софтскилы.
Предлагаю эксперимент — закройте рукой слово “архитектор”. Какая роль рисуется под этими скилами? Скорее ИТ-директор или CTO. И это вполне справедливо. Более того, вероятна ситуация, когда от архитектора требуются гораздо более развитые скилы из этого перечня. А разница заключается в обязанностях.
Для архитектора:
- Создавать и развивать архитектуру систем;
- Участвовать в разработке процессов компании;
- Наставничество;
- Разработка стандартов.
- ...
Для директора:
- Работа с подрядчиками;
- Управление бюджетом;
- Управление и развитие команды;
- Обеспечение непрерывности процессов;
- ...
Что мы видим? Очевидно, что архитектор и руководитель расходятся в цели существования.
Типичный юный ИТшник видит перед собой карьеру: джун->мидл->сеньор->тимлид->CTO. Но где-то на третьей ступени он начинает понимать, что, что-то идет не так. И уже на последнем — теряет самореализацию в разработке. Он перегружен административкой. Забыл когда в последний раз код писал.
Я видел много примеров, когда люди, добившись шаблонного карьерного успеха, тухли. Многие, теряя то, что им так нравилось, заводят свои pet-проекты. И пытаются там самореализоваться.
Путь архитектора это иной, весьма интересный путь. Я бы сказал, это правильный путь ИТшника. Не менеджера, а именно ИТшника. Который хочет иметь все более серьезные профессиональные вызовы. Он имеет возможность самореализации каждый день на всем карьерном пути.
Так где искать архитекторов? Мне кажется: среди счастливых профессионалов или внутри несчастных менеджеров.
Вместо заключения
Предлагаю пообщаться на тему необходимости архитектора в команде. Как вы себе представляете его роль? Сталкивались ли вы с его необходимостью? Возможно напротив, он вам мешал? Видите ли вы себя архитектором в перспективе? Хотели бы вы поменять путь менеджера на путь архитектора? Сделало бы вас это счастливее?
===========
Источник:
habr.com
===========
Похожие новости:
- [Алгоритмы, Высокая производительность, Математика, Программирование] Динамическая балансировка нагрузки в pull-схеме
- [Python, Алгоритмы, Лайфхаки для гиков, Научно-популярное, Программирование] Определяем пульс по вебкамере в 50 строчек кода
- [Godot, Дизайн игр, Прототипирование, Разработка игр, Читальный зал] Итеративный геймдизайн, Godot и мир маленьких планет
- [.NET, ASP, C#, Программирование, Тестирование IT-систем] Я десять лет страдал от ужасных архитектур в C# приложениях — и вот нашел, как их исправить
- [JavaScript, Программирование, Разработка веб-сайтов] JavaScript: область видимости простыми словами (перевод)
- [Python, Программирование, Машинное обучение] Как мы научили робота чувству юмора
- [Программирование, Анализ и проектирование систем, Управление разработкой] Как программист читает «Происхождение видов» Дарвина
- [Swift, Разработка под MacOS, Разработка под iOS] Swift Best Practices которые не стыдно знать
- [Процессоры, Разработка под Linux, Софт] Microsoft оптимизирует ядро Linux для серверных ARM
- [Карьера в IT-индустрии, Управление проектами, Учебный процесс в IT] Новое поколение разработчиков. Чем они отличаются и почему это нормально
Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_programmirovanie (Программирование), #_arhitektura (Архитектура), #_razrabotka (разработка), #_komanda (команда), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_programmirovanie (
Программирование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 00:16
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Статья направлена на диалог о необходимости архитектора в команде. Она будет интересна тем, кто задумывается о пути своего развития, когда “все дороги уже исхожены”. Когда имеющийся богатый опыт делает твою работу “неэффективной” с точки зрения коллег. Когда тебя уже почти ничего не удивляет и каждый следующий проект это дежа вю. Ты выгораешь. Кто такой архитектор? Погуглить на эту тему может каждый самостоятельно. Я постараюсь не быть кэпом и отражу сущность архитектора под необычным углом. Лично мне нравится шуточное определение этой роли: Архитектор — человек, который способен любому разработчику в команде аргументированно доказать, что его мнение ничего не стоит.
Архитектор — человек, который лучше других знает когда нужно уходить из проекта.
За этими пунктами стоит большой опыт. Можно ли обойтись без десятка(ков) лет в профессии, чтобы стать архитектором? Можно. Так же, как стать сеньором С++ через пару месяцев. Все зависит от человека, его способностей и самокритичности. Если вы сами создавали хотя бы одну программку, вы уже архитектор. Архитектор-джун. Смешно звучит. Хотя…. Если мы возьмем команду примерно равных по опыту разработчиков, кто из них станет архитектором? Тут обычно два сценария:
Возможно покажется странным, но первый сценарий более жизнеспособный. Дело в том, что имея конфликт интересов или профессиональный конфликт в команде, можно получить повышение качества продукта. Конечно, жертвуя временем. А вот второй сценарий может привести к тому, что более талантливый специалист будет попросту задавлен харизмой и софт-скилами самовыдвиженца. И продукт проиграет, получив самоуверенную персону, не терпящую альтернативного мнения. Поэтому, к важным качествам архитектора относится и:
Архитектор должен уметь использовать интеллектуальный ресурс команды, прислушиваться к мнению, настаивать там где нужно, брать на себя ответственность, быть наставником, учиться (много и постоянно), находить компромиссы и уметь заразить команду идеей. Что должен делать архитектор? Из стереотипных представлений об архитекторе известно, что он должен рисовать всякие схемы во всяких там нотациях. Бизнес-процессы, требования к системам и т.п. штуки, которые мешают творить разработчикам. Но это лишь артефакты деятельности. В ходе создания этих артефактов происходит магия, которая и отличает архитектора от плохого художника. На самом деле, ключевой функцией роли является архитектурный охват. Т.е. осознание того как система функционирует. И совсем не обязательно все должно быть документально выражено. Примером может стать проект, на котором задействован всего один разработчик. Он вполне успешно способен создать основу системы в голове и тут же выразить ее в коде. Если же в проекте участвует много людей с разными профессиональными векторами, то простое удержание в голове уже недостаточно. Архитектор, это роль, которая должна позволить всем четко понимать конечный технический портрет системы. И для этого требуется наглядное изложение того, что уложено в его голове. Вот тут на помощь приходят кружочки и квадратики. Часто архитекторы загоняются по нотациям. В целом, это хорошо. Т.к. есть стандартизация представления архитектуры. Но далеко не всегда конечный потребитель архитектуры умеет читать такие нотации. При высоком уровне развития процессов в компании это оправдано. Всех приучаем к стандарту и вперед. Но в стартапах, где нужно оперативно запустить разработку в компании разношерстных высококвалифицированных сеньоров (которые сами все знают), нотации обычно не заходят. Приходится быть ближе к людям. И рисовать понятно. А не умно. Тем более это станет проблемой, когда нужно будет получить от кого-то из команды его представление о верном архитектурном решении. Человек или не сможет вам его описать или закомплексует. И это фейл архитектора — неспособность использовать интеллектуальный ресурс команды. Если показалось, что я выше ёрничал, написав в скобках о сеньорах, что они все сами знают, то это не так. Они действительно все сами знают. Часто это люди, разделяющие роль архитектора и разработчика. Но зачастую, у них есть проф-деформация — они тоталитарно проводят свое мнение о необходимом решении. Это связано с тем, что в команде они были (есть) самыми сильными разработчиками. И вынуждены брать на себя ответственность. Архитектор обязан выстроить с командой доверительные отношения. Я пишу доверительные, а не дружеские или просто хорошие. В понятие доверия я включаю возможные профессиональные конфликты. Но при этом, каждая сторона понимает, что этот конфликт не личный. Каждая из сторон хочет лучшего проекту. И даже если ты уступишь в споре, это не проигрыш, а выраженное доверие использовать решение оппонента. Архитектор обязан делиться своим опытом и уметь “переваривать” чужой. В команде всегда найдется кто-то с интересным опытом. К сожалению, обычно, этот опыт имеет узкий угол обзора его предпосылок. При выборе стека разработчик может сказать:
Умалчивать разработчик может ненамеренно. Возможно он исключительно React использовал до этого. Ему не с чем сравнивать. Случается и обратное. Например, на рынке разработчик React выше оплачивается. На прошлом месте он завидовал коллегам пишущим на React. Но шанса изменить стек не было. Т.е. разработчик имеет исключительно шкурный интерес. Архитектор обязан рассмотреть предлагаемый опыт. При рассмотрении он должен учесть все детали. Составить свое мнение и аргументированно донести его. Например, в вопросе выбора элементов стека хорошо зарекомендовал себя документ “Выбор ключевого решения”. В нем, в водной части, описываются требования, ограничения и специальные условия. Затем под эти рамки подбираются и сравниваются решения. В заключении делается мотивированный вывод. Последней фазой является утверждение документа командой. Это необходимая бюрократия. Подобный выбор будет влиять на успех проекта, если не все время его существования, то длительный промежуток времени. Команда должна быть уверена, что выбор был сделан взвешенно и разделять его. И конечно, архитектор обязан создавать системы с бизнесом, для бизнеса и ради бизнеса. Чего не должен делать архитектор? Самое главное, что не должен делать архитектор — допускать демократию. Т.е. количественный метод принятия решений. Где любой в равной степени может воздействовать на выбор. Любое решение должно иметь основания. В какой-то степени, можно допустить случай, когда имеется пара решений с идентичными свойствами и остается только ткнуть пальцем не глядя… но из моего личного опыта этого можно избежать дообследованием. Случается, что при защите выбранного решения архитектор может столкнуться с тем, что оно не утверждается. По какой-то причине аргументы, определяющие выбор, воспринимаются недостаточными. Это не повод отступать. Требуется дополнить матрицу сравнения неохваченными свойствами. Учесть критику. И идти на второй заход. Третий. В любом случае, документ должен отражать причины выбора. Только так проект гарантирован от флэшбэков и запоздалых разборок. Никакой демократии. Второе по важности — недопустимо дистанцироваться от бизнеса и разработчиков. Иногда, так хочется пожить в своем идеальном мирке, где все понятно и логично. Но, жизнь сурова. Бизнес стремится развиваться. Нужно уметь слушать идеи бизнеса и понимать вектор их развития. Закладывать в архитектуру концепции, которые позволят решать задачи, еще несформулированные бизнесом. Держи друга близко, врага еще ближе, а с разработчиком нужно быть одним целым.
Требуется осознавать, что разработчик не смотрит на систему как архитектор. Он фильтрует информацию, стараясь оставить только то, что ему необходимо в его непосредственной деятельности. Не потому, что он злобная сволочь. Просто у него голова забита иной очень важной информацией, помогающей выполнять ему его работу. Важно уважать это и доносить ровно ту часть информации, в которой он испытывает потребность. Лучший способ — доносить информацию так, чтобы у разработчика возникла та же идея, которую заложил архитектор. В этом случае успех гарантирован. Архитектор не должен манипулировать бизнесом. Таланты архитектора могут сыграть злую шутку с ним самим и проектом в целом. Он намеренно или ненамеренно может стать частью системы принятия решений бизнесом. Опасно, когда бизнес начинает ориентироваться на мнение архитектора в несвойственных ему областях. Риск и асистемность в молодом бизнесе необходимое зло. Юные менеджеры-стартаперы, поддавшиеся на манящие песни архитектора о том, что все должно быть системно, могут с удивлением обнаружить, что затраты на операционку (поддержание системы) превосходят бизнес-профиты. Где искать архитектора? У нас в компании встал вопрос поиска архитектора на проект. Как водится нужно описать вакансию. Требования относительно очевидны:
Предлагаю эксперимент — закройте рукой слово “архитектор”. Какая роль рисуется под этими скилами? Скорее ИТ-директор или CTO. И это вполне справедливо. Более того, вероятна ситуация, когда от архитектора требуются гораздо более развитые скилы из этого перечня. А разница заключается в обязанностях. Для архитектора:
Для директора:
Что мы видим? Очевидно, что архитектор и руководитель расходятся в цели существования. Типичный юный ИТшник видит перед собой карьеру: джун->мидл->сеньор->тимлид->CTO. Но где-то на третьей ступени он начинает понимать, что, что-то идет не так. И уже на последнем — теряет самореализацию в разработке. Он перегружен административкой. Забыл когда в последний раз код писал. Я видел много примеров, когда люди, добившись шаблонного карьерного успеха, тухли. Многие, теряя то, что им так нравилось, заводят свои pet-проекты. И пытаются там самореализоваться. Путь архитектора это иной, весьма интересный путь. Я бы сказал, это правильный путь ИТшника. Не менеджера, а именно ИТшника. Который хочет иметь все более серьезные профессиональные вызовы. Он имеет возможность самореализации каждый день на всем карьерном пути. Так где искать архитекторов? Мне кажется: среди счастливых профессионалов или внутри несчастных менеджеров. Вместо заключения Предлагаю пообщаться на тему необходимости архитектора в команде. Как вы себе представляете его роль? Сталкивались ли вы с его необходимостью? Возможно напротив, он вам мешал? Видите ли вы себя архитектором в перспективе? Хотели бы вы поменять путь менеджера на путь архитектора? Сделало бы вас это счастливее? =========== Источник: habr.com =========== Похожие новости:
Анализ и проектирование систем ), #_programmirovanie ( Программирование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 00:16
Часовой пояс: UTC + 5