Репутація українського ІТ. Пройти опитування Асоціації IT Ukraine
×Закрыть

Як стати Application Architect і які навички розвивати. Поради з власного досвіду

Усім привіт! Мене звати Влад, працюю в IT понад 10 років і наразі обіймаю посаду Application Architect у компанії SoftServe.

У статті розповім про свій шлях від студента факультету програмного забезпечення автоматизованих систем Запорізької державної інженерної академії (ЗДІА) до посади архітектора. Цей матеріал буде корисним як програмістам-початківцям, так і спеціалістам з досвідом, які думають, як розвивати далі свою кар’єру.

Коротке інтро

Народився і вчився я у Запоріжжі. У школі цікавився історією України та комп’ютерами, тож вступав і пройшов на історичний факультет ЗНУ і на факультет програмного забезпечення ЗДІА. Та все ж навчатись пішов на програмування.

Із четвертого курсу почав працювати за спеціальністю у Запоріжжі — індустріальному місті, в якому вибір ІТ-фірм не дуже широкий, а великих компаній на кшталт SoftServe, EPAM взагалі немає. На цьому етапі мені доводилось верстати, проєктувати бази даних, писати серверну частину на Zend Framework (PHP) і встановлювати це все на сервери. Це були як прості сайти-візитівки, так і написаний з нуля інтернет-магазин. Зазначу, що саме той досвід був дуже важливий і допоміг мені зрозуміти повний цикл побудови вебзастосунків.

Попрацювавши так певний час, я почав відчувати, що розвиваюсь не так швидко, як би хотілося. Пощастило, що друг закінчив курси в SoftServe IT Academy і порекомендував їх мені. Тоді я пройшов відбір і потрапив на курс Web UI, зібрав речі та переїхав у Львів вчитись.

Після успішного закінчення курсів я розпочав роботу у SoftServe з посади Trainee Web UI (HTML/CSS/JavaScript). Мені пощастило потрапити в команду, де був архітектор, який допоміг мені зорієнтуватися далі. Ми довго працювали разом на різних проєктах, і я бачив, чим саме займається архітектор. І одразу поставив собі за мету розвиватись у цьому напрямі.

Хто такий архітектор

У нашій компанії є кілька варіантів кар’єрного розвитку до позиції архітектора, але, на мою думку, найоптимальнішим є такий:

Сама посада архітектора має ще кілька рівнів:

Детально кар’єрний шлях можна роздивитись тут.

Наразі я Application Architect, тож у мене попереду довгий шлях по кар’єрній драбині. Але в цій статті поділюся досвідом, як дорости від Trainee-інженера до архітектора.

Спершу пропоную розглянути, що це за посада «архітектор», які обов’язки вона передбачає.

Архітектор — це технічний експерт, який ухвалює високорівневі рішення стосовно продукту і стежить, щоб команда правильно втілила їх у життя. Самі рішення архітектор ухвалює, керуючись бізнес-вимогами, нефункціональними вимогами та обмеженнями. З бізнес-вимогами, думаю, все зрозуміло. Нефункціональні вимоги — це, наприклад, можливість застосунку витримувати навантаження, коли багато користувачів одночасно заходять на нього, безпека (захист від атак) тощо. Вищенаведені вимоги та обмеження архітектор має витягти із замовників. Це означає, що він безпосередньо спілкується з клієнтами й має знайти ключ до спілкування з різними людьми, часто складними за характером.

Як дорости до архітектора

Тепер ми можемо сконцентруватися на ключових моментах, які допоможуть на шляху до бажаної посади.

Різносторонній розвиток hard skills та pet-project

Як Web UI інженер я одразу ставив собі за мету стати експертом свого напряму і водночас цікавився серверною розробкою. На мою думку, важливий саме різносторонній розвиток інженера. Якщо на проєкті немає нагоди опанувати нову мову програмування або новий напрям (наприклад, ви пишете на JavaScript для браузера, а хочете писати JavaScript для сервера), рекомендую придумати цікавий домашній проєкт (pet project) і працювати над ним у вільний від роботи час.

Проєкт має бути повноцінним: якщо це сайт, то він має мати домен і бути в публічному інтернеті, якщо мобільна програма, то викладена в App Store або Play Market. Це дасть змогу зрозуміти повний цикл розробки і закрити потрібну сферу. Мені подобаються pet projects, тому я сам вивів у продакшн один благодійний проєкт, вивчивши завдяки цьому цікавий набір технологій. Потім ця робота дала мені матеріал для публічних доповідей — такий от бонус :) Про важливість доповідей ми поговоримо далі.

Наразі у вільний час працюю над новим і цікавим проєктом, що пов’язаний з мобільною розробкою. Вдається виділяти на це 10-15 годин на тиждень. Маю чудових друзів, які водночас є класними спеціалістами у мобільній розробці, серверній та веброзробці, тож завжди є з ким порадитись щодо тих чи інших рішень. На мою думку, для архітектора важливо не втрачати навичок програмування і всі знання закріплювати на практиці.

Постійне навчання та самовдосконалення

Головна порада: ніколи не зупинятись і продовжувати постійний розвиток і навчання. Підійдуть будь-які методи: книги, тренінги, конференції. Особливо відзначу конференції. Я почав їх відвідувати 2013 року і продовжую донині. Конференції дають змогу відчути трендові речі, познайомитись з експертами у галузі. Рекомендую не зациклюватись на профільних заходах (наприклад, тільки події JavaScript чи тільки C#), а відвідувати різноманітні форуми.

Я продовжую активно вчитись, адже є ще багато напрямів, де хотілося б отримати досвід і посилити свою компетенцію. Архітектор має тримати руку на пульсі технологій і постійно аналізувати, що нове доцільно використовувати у проєктах, а що ні.

Від себе пораджу те, що мало б допомогти інженеру-програмісту на шляху до позиції архітектора незалежно від спеціалізації.

Книги:

  1. Object-Oriented Analysis and Design with Applications by Grady Booch, Robert A. Maksimchuk, Michael W. Engle, Bobbi J. Young, Jim Conallen, Kelli A. Houston
  2. Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Grady Booch
  3. Functional Programming In Javascript by Luis Atencio
  4. Refactoring by Martin Fowler
  5. xUnit Test Patterns: Refactoring Test Code 1st Edition by Gerard Meszaros
  6. Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin
  7. Software Architecture in Practice (SEI Series in Software Engineering) 3rd Edition by Len Bass, Paul Clements, Rick Kazman

Хмарні сертифікації від AWS, GCP або Azure (класно отримати сертифікат хоча б з однієї «хмари»):

  1. Professional Cloud Architect
  2. AWS Certified Solutions Architect
  3. Microsoft Azure Architect Technologies

Також для архітектора важливо розуміти, як автоматизується життєвий цикл програмного рішення, починаючи від розробки і закінчуючи розгортанням, підтримкою і моніторингом — те, чим займаються DevOps-інженери. Можу порекомендувати чудовий канал для цього.

Вміння говорити й доносити свою думку

Я вважаю, що найкраще ці навички розвивають публічні виступи. Свої перші презентації я почав готувати ще у 2013 році, розбираючи цікаві теми й розказуючи про це на окремих мітингах членам своєї команди. Потім були виступи на внутрішніх заходах всередині компанії. А згодом і зовнішні презентації.

Найбільшим моїм досягненням є виступ англійською мовою у Вроцлаві 2019 року. Завдяки попередньому досвіду в Україні я мав чудову підготовку: не боявся аудиторії та складних запитань. Це дуже допомогло у Польщі, адже перспектива доповідати англійською мовою додавала переживань. Але все минуло гарно: виступ вийшов цікавий, адже я отримав багато питань від аудиторії.

Навички, які я здобув під час презентацій, дають мені більше впевненості як у перемовинах з клієнтами, так і у спілкуванні з командами.

Виступ на IT Weekend у Рівному, 2018

Вміння брати нові виклики й гідно долати їх

Не боятись випробувань — важливе вміння для архітектора. У своїй кар’єрі я завжди намагаюсь братись за проєкти будь-якої складності, адже саме так найшвидше вчишся і вдосконалюєшся. Якщо вам пропонують стати лідером проєкту — треба погоджуватись. Навіть якщо проєкт здається складним або ви чули відгуки, що там багато проблем. Це буде важко, але потрібно навчитись долати перешкоди.

Найчастіше мене залучають до складних проєктів і я завжди проходжу ці випробування. Для мене найскладнішим викликом було почати керувати людьми. Спочатку запропонували бути технічним лідером команди, яка розробляла клієнтську частину застосунку, а потім і технічним лідером всього проєкту.

Це неймовірно складно — зрозуміти, що твоє завдання тепер не тільки писати якісно код, а й організовувати роботу колективу, говорити з людьми, чути їх. Не все виходило, я припускався помилок. Інколи був занадто вимогливий до колег. Зараз бачу, що це було причиною додаткової напруги на проєкті, та намагаюсь з більшим розумінням ставитись до проблем спеціалістів, адже у житті буває різне і всі ми помиляємось.

Здолати це випробування мені допомогли м’які навички, про які ми поговоримо далі і які є, на мою думку, надзвичайно важливими для архітектора.

Розвиток soft skills і лідерських якостей

М’які навички (англ. soft skills) — комплекс неспеціалізованих, надпрофесійних навичок, які відповідають за успішну участь у робочому процесі, високу продуктивність і, на відміну від спеціалізованих навичок, не пов’язані з конкретною сферою. Детальніше можна почитати тут або на DOU.

Університет Східного Кентуккі склав список м’яких навичок для керівників підприємств. Це зв’язок, люб’язність, гнучкість, цілісність, міжособистісні навички, позитивне ставлення, професіоналізм, відповідальність, командна робота, робоча етика.

Пропоную розглянути деякі приклади:

  • Люб’язність. Попри різноманітні обставини треба намагатись бути максимально люб’язними, навіть якщо вам людина не подобається. У кожного трапляються важкі дні, з деким просто складно спілкуватися, але треба вчитись працювати з різними людьми, бо всі ми маємо як плюси, так і мінуси.
  • Зв’язок. Працюючи у великій компанії, варто налагоджувати зв’язок з людьми, інвестувати в них свій час. Потім це повертається назад і добре допомагає в роботі.
  • Гнучкість. Треба вміти змінювати пріоритети за потреби, перемикатися, швидко пристосовуватись до нових умов. Наприклад: часто архітектора просять допомоги в завданнях, пов’язаних з бізнес-аналізом або з керуванням людьми — варто приставати на це, хоча й міра теж має бути.

Програмісти нерідко нехтують розвитком цих навичок. І даремно — саме проблеми з м’якими навичками часто стають перешкодою на шляху від лінійного інженера до лідера. Тож моя порада така: якщо хочете дорости до лідера, звертайте увагу на софт скіли на старті кар’єри: з вами в команді має бути приємно працювати (і колегам, і клієнтам), а керівник проєкту має спокійно покладатись на вас.

Недарма рекомендують мати лідерський досвід для отримання посади архітектора. Тобто інженер повинен попрацювати певний час технічним лідером і тільки після того може рухатись в архітектуру. Нерідко люди не розуміють, для чого це треба. Насправді архітектор має бути лідером для лідерів, вибачте за тавтологію. Архітектор працює в лідерській команді з менеджерами, лідером інженерів з контролю якості, з бізнес-аналітиками, дизайнерами й технічними лідами. Тут важливо навчитись знаходити спільну мову зі всіма лідерами команди, особливо з технічними, адже саме вони мають втілити у життя те, що запроєктував архітектор.

Без лідерського досвіду і м’яких навичок зробити все вищенаведене буде важко. Колись я працював у команді, де керував усім головний архітектор. Людина мала колосальний технічний досвід і знання, але зовсім не володіла софт скілами. Це призводило до того, що головний архітектор фактично не міг пояснити ані своїм архітекторам, ані менеджерам команд, в яких ті архітектори працювали, для чого потрібно впроваджувати ті чи інші технічні рішення. У результаті технічні рішення або втілювались неправильно, або саботувались через нерозуміння.

Крім того, архітектор має знаходити спільну мову з топменеджерами замовників. Це переважно люди, які багато чого досягли у житті й мають своє чітке бачення на багато технічних питань. Саме тут архітектору знадобляться м’які навички, щоб вдало побудувати стосунки. А від того, наскільки добре це вдасться, залежить доля проєкту.

Висновок

Отже, хороший архітектор — це лідер із сильними технічними знаннями, багатим досвідом і чудовими м’якими навичками. Від успішної роботи архітектора залежить майбутнє проєкту/компанії, адже він має витягнути із замовників/власників потрібну інформацію для побудови системи та довести їм, що ухвалені рішення є правильними. А також простежити, щоб команда розробників належним чином втілила ці рішення у життя.

Саме це й надихає мене в роботі: можливість реалізувати себе у складних умовах і допомогти зробити бізнес замовників успішним або ж посилити успіх.

LinkedIn

36 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Хотілося б більше практичних прикладів з вашої роботи архітектора

класно отримати сертифікат хоча б з однієї «хмари»

лол

упомянутый в списке литературы под 1м номером Гради Буч оч сильно устарел. Его пример с датчиками(и злоупотребление наследованием в нем) не критиковал только ленивый. Но 25 лет назад его книга была прорывом, факт.

По крайней мере во всяких Датабриксах и тд — Solution Architect это англоязычный джун/миддл, который всеми силами пытается тебе впарить их «самый лучший» продукт.

По крайней мере во всяких Датабриксах и тд — Solution Architect

Потому что это звучит лучше чем «пресейлс инженер». А роль солюшн архитектора там выполняют «принсипл инженеры» (или типа того)

Ну это как бы и был мой поинт :) (чем условный аутсорсер Х от них отличается?), что главное английский и умение хоть как-то коммуницировать, «system design» возможно даже не понадобится.

Ну это как бы и был мой поинт :) (чем условный аутсорсер Х от них отличается?)

1) Не ограничены стеком «который нужно продать». Задача продемонстрировать не возможности, а экспертизу.
2) Вовлечены не только на пресейле, но и несут ответственность (не просто консультации) за констракшн фазу.

Кожен, хто мав досвід співбесід у Фаанги, знає чи хоча б чув, що таке System Design.
Поправте мене, але я десь ± уявляю собі роботу архітектора як людини, що створює/модифікує цей дизайн для конкретної аплікухи чи великої системи з багатьма аплікухами.
Власне це найцікавіша частина роботи архітектора і одна з найвагоміших причин, чому багато хто хоче бути саме архітектором, а не просто техлідом чи сіньйором.

А це не було висвітлено у статті.
Хотілося б почути чи дійсно ви, як архітектор, займаєтесь System Design, якщо так, то як качали саме цей скіл, а не знання джаваскрипта.
Ну і виклики, поразки/перемоги саме в цьому аспекті роботи.

Стаття, безперечно, цікава і корисна, але мені вона більше схожа на типову статтю про те, як бути хорошим інженером і що для цього потрібно, а хотілось спеціалізовано-архітекторського.

Так я займаюсь як архітектор системним дизайном, але суттєва цікавий нюанси роботи архіртектора в тому, що перед тим, як створити/мотифікувати дизайн треба зрозуміти суть проблеми, зібрати у замовників архітектурні драйвери, а вже потім будувати системний дизайн. Напевно найбільшим викликом для мене стала сама ця частина роботи архітектора тому я зробив великий наголос на мягких навичка/ вмінні комунікувати.

Також я вказав, що скіл будування складних систем я качав на різних проектах маючи досвідчених архітекторів як наставників + власні проекти + різнопаланове навчання. Це велика вдача — мати таких наставників, які одразу можуть пояснити чому обирається те чи інакше рішення бо мають багато років досвіду у архітектурі.

архітектурні драйвери

Не зовсім зрозуміло, що це таке, можете пояснити?

зрозуміти суть проблеми, зібрати у замовників

З такими обов’язками особисто я стикався на 100% своїх проектів. Більше того, вже починаючи з того моменту як я став мідлом маючи на той момент 2 роки досвіду, я комунікував із відповідними стейкхолдерами для узгодження вимог та цілей. Чи був я архітектором тому що виконував такі обов’язки)? Очевидно що ні.
Окремостоячою є позиції бізнес аналітика та продукт овнера. Вони також збирають вимоги, комунікують з усіма зацікавленими людьми, формують документації та часто ставлять цілі. Але чи є вони архітекторами?) Очевидно що ні.

Також я вказав, що скіл будування складних систем я качав на різних проектах маючи досвідчених архітекторів як наставників + власні проекти + різнопаланове навчання

Тобто ви хочете сказати, що ви навчились бути архітектором виключно методом проб і помилок на проектах не маючи відповідної теоретичної підготовки і тільки спостерігаючи за більш досвідченими колегами? Якщо так, то це трохи п**ц. Тільки уявіть аби так вчились бути програмістами. Як мінімум, є дуже велика ймовірність перевинаходу костилів, як максимум, ви збудуєте щось дуже не ефектевне чи навіть шкідливе для бізнесу, сам того не усвідомлюючи.

Не знаю вас особисто, не бачив ваших проектів і робіт але з вашої статті та коментарів склалось враження, що ви виконуєте функції БА, трішечки девелопера, трішечки тімліда, трішки дісно архітекторськими задачами, а компанія все це назвала «Архітектор».

архітектурні драйвери
Не зовсім зрозуміло, що це таке, можете пояснити?

Це термін такий (визначення може відрізнятись у різних «школах») :)
Туди входять нефункціональні вимоги, деякі функціональні вимоги (зазвичай високорівневі, типу має видправляти емейли) і констрейнти (вимоги від бізнесу або архітектурного комітету, які не можна обійти, типу ми хочемо на гуглоклауді).

Тобто ви хочете сказати, що ви навчились бути архітектором виключно методом проб і помилок на проектах не маючи відповідної теоретичної підготовки і тільки спостерігаючи за більш досвідченими колегами? Якщо так, то це трохи п**ц. Тільки уявіть аби так вчились бути програмістами.Як мінімум, є дуже велика ймовірність перевинаходу костилів, як максимум, ви збудуєте щось дуже не ефектевне чи навіть шкідливе для бізнесу, сам того не усвідомлюючи.

-100500. Вот так вот курсы попроходил, книжек начитался, и синьором вышел, или даже архитектом)). Это не означает, что теория не нужна, просто чем выше уровень, тем слабее теория работает, поэтому другого [эффективного] пути, кроме как подгребать под себя хай-левел обязанности, особо-то и нет.

Это не означает, что теория не нужна, просто чем выше уровень, тем слабее теория работает

ну да ну да и грамота не нужна и математика и вообще вот это всё и главное софт скиллы и чтобы человек был хороший и упорный и амбициозный а теорию придумали трусы ))

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

Я бы сказал, что математику изучают сначала в теории: штудируют многотомных Фихтенгольцов, например. А потом уже закрепляют эту теорию решением примеров.

С работой архитектора во многом похожая ситуация. Скажем для того, чтобы правильно использовать сервисы AWS полезно сначала изучить что именно они позволяют — прочитать документацию, white papers.

А потом уже закрепляют эту теорию решением примеров.

И в нашей ситуации закрепление будет именно таким, как написал автор. Почему людей от этого так коробит, мне непонятно от слова совсем. Получается какая-то нелогичная дихотомия: учится по ходу дела — плохо, как он посмел, зато после книжек с корабля на бал в реальный проект архитектором сразу — это нормально, видимо). Может, где-то существуют «джуниор архитекторы», которых кто-то учит после книжек, но я таких не видел, поэтому единственный путь — постепенно подгребать на себя соотв. обязанности (бизнес анализ, дизайн баз, разбиение домена на подконтексты, инфраструктура/девопс, нефункциональные требования).

С работой архитектора во многом похожая ситуация. Скажем для того, чтобы правильно использовать сервисы AWS полезно сначала изучить что именно они позволяют — прочитать документацию, white papers.

Такие вещи нужно начинать делать уже будучи миддлом, только вот незадача — миддл очень много не поймёт, пока... не попробует (см. выше). Да и синьор не поймёт, если вся «сеньорность» заключается только в идеальном знании любимой программной платформы и сиквела. Поэтому порция теории -> learning by doing -> очередная порция теории и т.д. Но никак не

сначала в теории: штудируют многотомных Фихтенгольцов

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

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

Никто ведь не говорил сугубо о чтении книг годами. Классическая система преподавания матана: теоретические лекции + практические занятия. Результаты получаются вполне неплохие.

С архитекторской работой ситуация похожая. Часто это день проработки базы плюс несколько дней на POC (цифры условны).
И я совершенно не против пути в архитектуру, который изложил автор — вполне себе работающий вариант. Он и базисные книги читает, и сертификации получает, и в конференциях участвует, и пет-проекты ведет. Векторов развития много, суммарно дают результат.

У мене інтерес дуже шкурний:
Я рядовий сіньйор, яких хоче бути архітектором.
Я бачу вакансію архітектора, приходжу на співбесіду і починаю задвигати, що давайте працювати, а в процесі я буду брати більше обов’язків і спостерігати за старшими товаришами)? Це так працює)))?

Я бачу вакансію архітектора, приходжу на співбесіду і починаю задвигати, що давайте працювати, а в процесі я буду брати більше обов’язків і спостерігати за старшими товаришами)? Це так працює)))?

Есть разные варианты в зависимости от компании. Самый быстрый — сервисные компании с низким капасити, где приходится влазить во всё то, о чём я Вас ниже цитирую; либо продуктовые компании, в которых ценится инициатива. После этого, когда уже сами успели задизайнить какое-то типичное решение среднего размера, уже найти подходящий проект/продукт большого масштаба (например, тех лидом), где рядом будет архитектор, какое-то время у него учиться, и в какой-то момент человек дорастает.

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

И, кстати

але з вашої статті та коментарів склалось враження, що ви виконуєте функції БА, трішечки девелопера, трішечки тімліда, трішки дісно архітекторськими задачами, а компанія все це назвала «Архітектор».

Не совсем понимаю, что Вас смущает. Архитектор именно что должен через всё это пройти, чтобы не быть космонавтом.

Хотілося б почути чи дійсно ви, як архітектор, займаєтесь System Design

Это зависит от компании/проекта. В некоторых детальный System Design может быть задачей лида, а у архитектора очень высокоуровневый. В некоторых случаях, архитектор может даже кодить части конечного солюшена.

Тут важнее фокус:
У лида фокус — деливери той или иной части требований (функциональных или нефункциоанльных).
У архитектора (аппликейшн, солюшин) фокус — принятие дизайн решений для достижения, как правило, нефункциональных требований, в которые так же входят и требования по соответствию решения практикам и стандартам в организации. Как правило System Design является выходом от таких решений.
У ентепрайз архитектора фокус — создание и управление этими самими практиками.

Важно понимать что архитектор — это роль в проекте/организации, а не «следующая ступень после лида». Грубо (и не правильно) говоря: архитектор — это бизнес аналитик по нефункциональным требованиям.

Важно понимать что архитектор — это роль в проекте/организации, а не «следующая ступень после лида».

вот тут неистово плюсую )

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

Набор книг выглядит как обычная литература для обычного софтвар инженера, к которой нужно добавить еще пяток другой книг.

Ну а в целом, наверное, история как стать архитектором должна описывать количество и сложность спроектированных решений, факапов в этих решения и как они были преодолены. Хотелось бы послушать про это, а не про книжки и софтскилы)))

Андрюха привет! Не нагнетай. Инфляция тайтлов — не шутка, да и эволюция — штука достаточно индивидуальная. Сам то с зоны когда откинешься?)))

Собственно, какое проектирование в аутсорсе. Там «архитектура» — это в лучшем случае про пресейл.

Собственно, какое проектирование в аутсорсе

Ну уровень Application Architect довольно радостно отдают на аутсорс, ибо это изолированный кусок.

мені пощастило останній рік займатись повноцінними рішеннями, розробка яких відбувається «з нуля» ( так, таке теж буває, у нас велика компанія і проекти дуже різнопланові ) Тож так, що б стати Solution Architect треба викорувати роботу Solution Architect чим я зараз і займаюсь :)

розробка яких відбувається "з нуля«( так, таке теж буває, у нас велика компанія і проекти дуже різнопланові )

Реклама засчитана, можете просить премию. Собственно зачем еще вы это сказали? Какую информацию вы добавили к моему сообщению?

Тож так, що б стати Solution Architect треба викорувати роботу Solution Architect

Бімба. Вот тут и скрываются проблемы в вашем описании «пути архитектора», которою раскрыли в начале этой ветки (dou.ua/...​ome-an-architect/#1974679 )

роботу Solution Architect чим я зараз і займаюсь :)

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

розробка яких відбувається "з нуля"( так, таке теж буває, у нас велика компанія і проекти дуже різнопланові )
Реклама засчитана, можете просить премию. Собственно зачем еще вы это сказали? Какую информацию вы добавили к моему сообщению?

+500100

Прикол в тому, що б спроєктувати складне рішення з нуля( у мене є такий досвід ) треба дуже багато софтскілів для того, що б витягнути з клієнтів нефункціональні вимоги і потім ще отримати добре від їх технічних людей. Суб’єктивно мені оця вся комунікація і фокус на бізнес замовників виглядає складнішою, ніж спроєктувати саме рішення. Саме тому я звернув на це увагу. Щодо складності проектування рішень і факапів — це треба окрему статтю писати :)

спроєктувати складне рішення з нуля

А можна якийсь реальний приклад, як виглядає цей процес проектування?
Тобто для прикладу:
Ось ми написали сервіс b2btravel.com чи b2btelecom.com
Ось були такі нефункціональні вимоги
Ми вибрали такий стек, деплоїмо так, діаграмка така ось
Ось такі плюси
Ось такі мінуси
Ось такі кости на середовище, також ми маємо ще якісь там тести чи ще щось

це треба окрему статтю писати :)

Реально це було би цікаво почитати, якби там була якась конкретика
Бо писати якийсь прототип це одне, а які будуть наслідки такого прототипування, як буде поводитися аплікація в продакшині за 2 роки це зовсім інакше

хороша ідея, спробую описати у окремій статті. Вибачте, що не вдалось це зробити в цій — фокус був на інші речі

Ви на роботі програмуєте?

Ви на роботі програмуєте?

Уловка 22:
— Да — так ты просто девелопер которого выпускают к кастомеру.
— Нет — тю, так ты даже не инженер.

прототипи :) Тобто зовсім трошки, що б зрозуміти, що рішення має право на життя

10 років досвіду якось трошки замало для Application Architect, хоча Цукенбергу мав і меньше досвіду коли створив Фейсбук. Хотілось би все-ж прочитати про виклики які ви долали на цій посаді з конкретними прикладами, а не загальну інформацію і про виступ англійською мовою.

Дякую за ваш коментар.
Моя суб’єктивна думка щодо 10 років: мені здається, що тут дуже залежить як ці 10 років проходять.
Якщо це 8 годин людина відпрацювала і більше в комп не дивиться, а на вихідних суто відпочиває — це буде одні 10 років.
Якщо людина зранку встає щось вчить, потім працює( при тому не просто кодує, а з якогось часу починає приймати різноманітні виклики аля менеджмент, складні переговори з клієнтами, складні задачі, вирішення складних ситуація як в команді так і з замовниками), потім знову вчить, на вихідних працює( оскільки вищенаведені виклики важко встигнути зробити за 8 годин ) /вчить/робить домашні проєкти — це будуть інші 10 років.
Щодо свого випадку: я багато часу приділив кар’єрі( робота, навчання, власні проекти ) і багато від чого відмовився. Це trade-off який я зробив для себе.

Тому є люди, які все життя працюють сініорами і це абсолютно ок.
І є люди, які стають архітекторами через 8 років і це теж ок. Випадки різні

Щодо викликів: які саме вам цікаві? Технічні чи не технічні?

Щодо доповіді англійською з задоволенням розпишу просто скажіть, що саме вам цікаво :)

Подписаться на комментарии