×

«Архітектор — це не наступний рівень розвитку техліда». Senior Solution Architect в Івано-Франківську — про свою роль і перспективи професії

29-річний Роман Феняк живе і працює в Івано-Франківську. За 11 років в ІТ він дійшов до посади Senior Solution Architect і наразі працює в SoftServe, очолюючи відділ з семи архітекторів для одного великого акаунта. Також Роман став одним із переможців Ukrainian IT Awards 2020. В інтерв’ю для DOU він розповів, як саме роль архітектора відрізняється від техліда, як стати Solution Architect та куди рухатись далі, а також чому він не планує переїжджати з Івано-Франківська до Києва чи за кордон.

Роман у поїздці до Канади

— Яким був твій кар’єрний шлях і з чого все почалося?

Сферою ІТ я захопився, думаю, класу із восьмого: у школі вивчали основи інформатики, і мені «зайшло». В той час це ще не було так популярно, але мені одразу сподобалось. Я маю математичний склад розуму, тож обирав між фізико-математичним ліцеєм і коледжем електронних приладів (КЕП). У результаті вступив до коледжу, де й вчився чотири роки. Там продовжив вивчати ІТ і поступово зрозумів, що це моє.

У 18 років (це були 2010-ті) я вже почав працювати: мав невеликі підробітки та проєкти. У квартирі збиралося кілька людей, і ми писали маленькі сайти. Паралельно навчався в Івано-Франківському національному технічному університеті нафти і газу, адже в КЕПі не давали повної вищої освіти — лише рівень молодшого спеціаліста. Обрав для себе спеціальність «Програмна інженерія». Так що за освітою я якраз програміст. Нині багато хто переходить в ІТ з різних галузей, а я гордо можу сказати, що був програмістом, коли це ще не було модно (сміється).

Потім з’явилася перша офіційна фултайм-робота — я потрапив у SoftJourn. Тоді я був на LAMP-стеку. Сьогодні LAMP — не найпопулярніший стек, але на той момент це було трендово через низький поріг входження. Там пропрацював трішки більше як рік, після чого отримав офер в OSF Global Services. Компанія менша, ніж SoftJourn, але вона є міжнародною, відповідно майже вся моя команда була не з України. Півторарічний досвід роботи розробником там, безумовно, виявився цікавий і корисний, плюс допоміг швидко прокачати знання англійської мови.

У 2014 році у SoftServe запустили вакансії з моїм набором знань, і мене взяли на роботу. І вже там почалося кар’єрне зростання. Я прийшов у компанію як Middle Developer і практично відразу перекваліфікувався у Full Stack JavaScript Engineer, потім поетапно зріс до сеньйора, відтак до техліда. У 2017 році вирішив рухатися далі — обрав архітектуру. І от за чотири з половиною роки дійшов до Senior Solution Architect. Розвиток цей був доволі швидким, бо я намагався братися за різні завдання замість того, щоб концентруватися на чомусь одному. А ще я отримую задоволення від роботи, яку іноді жартома називаю своїм хобі — таке ставлення теж допомагає розвиватися. Здавалося б, банально, але треба любити те, що робиш.

— Чим ще ти займався останні роки?

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

Зрештою я повернувся на свій попередній юніт. Там я працював на пресейлах як консультант. Коли з’являвся новий потенційний клієнт, я мав якнайшвидше зрозуміти, що це за проєкт, скільки часу і які люди потрібні, щоб виконати його. Цим займаюся, до речі, досі. Була, наприклад, цікава платформа — щось на кшталт Upwork, але для фармацевтів. Наприклад, ви власник аптеки, вам потрібні працівники — відкриваєте цю платформу і шукаєте, все зручно.

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

— Повернімося до освіти. Наскільки корисним було твоє навчання в коледжі та університеті?

Основи, звісно, викладачі в коледжі заклали. Та, відверто кажучи, це не було критично важливо і потрібно, щоб потрапити в ІТ. Вважаю, що добрі курси, відео- чи онлайн-тренінги та спеціалізована література можуть дати більше і швидше, бо в університеті вивчаєш і низку недотичних дисциплін. Те, чого мене вчили в ІФНТУНГ, і те, з чим я стикнувся в роботі — це різні речі.

Однак зважмо, що мета університету — навчити людину вчитись, і далі це вміння допоможе. Для мене навчання в ІФНТУНГ стало у пригоді, адже зараз я працюю у вугільному домені, компанія займається видобутком коксового вугілля та металів. І я жартував, що вже маю потрібну доменну освіту, адже знаю, що таке видобуток і якими є певні техпроцеси. Навіть не здогадувався, що ці знання мене за десять років наздоженуть і стануть корисними.

— У чому саме полягає твоя роль як Solution Architect?

Головна відмінність між техлідом і архітектором — у ключових цілях і контексті, в якому вони працюють. Перший має зробити якісний код, базуючись на найкращих практиках, а другий має зрозуміти бізнесові потреби клієнта і перетворити це на правильне рішення. Отож архітектор — це не наступний рівень розвитку техліда. Часто техлід має значно глибші знання в технологіях, ніж архітектор.

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

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

І з нашого боку ситуація ідентична. У мене зараз є команда, я розвиваю в людей навички архітекторів та знання методологій. Спеціалістів ми підбирали поетапно. Маю сказати, що колеги в мене круті. Тож мені легко з ними працювати, все їм пояснювати.

На врученні премії IT Awards

— Щодо твоєї команди. Як саме ти їх вчиш і як відбувається відбір людей, які стануть архітекторами?

У нас є спеціальна архітектурна програма, яка триває пів року. Проводимо низку практичних занять, де майбутніх архітекторів вчать цього. Є певний кейс, і люди мають збудувати систему. Вони генерують оптимальну побудову цієї системи, архітектурні бачення, мають обмінятися ідеями, знайти сильні та слабкі місця в структурах одне одного, вибудувати золоту середину.

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

Дехто спробував і зрозумів, що це не його. Декого не брали саме через нерозуміння бізнес-потреби. Ще є і такий фактор: тренерів, які можуть цього навчити, у SoftServe буквально декілька, а охочих чимало. Відповідно формуються черги ледь не на рік вперед, і учаснику з часом повідомляють, що він може розпочинати навчання.

— Ти згадував про канадську компанію, з якою працюєш. Чим вони займаються і що ти робиш для них?

Це одна з найбільших канадських компаній, світового рівня, вона займається видобутком коксового вугілля. Вугілля потрібне для виплавки металів. Окрім того, видобуває цинк, мідь, свинець, молібден, срібло...

Специфіка цього бізнесу в тому, що вони мають чітку квоту від держави на всі копалини, а також визначену суму, за яку їх можна потім продати. Відповідно їхній спосіб заробітку — це економія: що дешевше вдасться це вугілля видобути, то більше залишиться грошей. І клієнти почали інвестувати в R&D, шукати, де у їхніх техпроцесах gaps або bottlenecks, як ці процеси удосконалити і що зробити ефективніше. Саме цим і займаємося ми — розбираємося з бізнес-потребами та будуємо рішення.

Я дуже радий, що зміг потрапити у цей домен, адже він проривний у плані технологій. Це, зокрема, трендові нині Big Data i Data Science. Взагалі, там багато нетривіальних речей.

— Solution Architect — це така посада, дорости до якої прагне багато розробників, а от виходить не у всіх. У чому твій секрет?

Є низка крутих навчальних програм. Скажімо, SoftServe працює із Software Engineering Institute від Carnegie Mellon University — приватним американським університетом. Вони мають багато власних тренінгів, і саме цю методологію ми використовуємо для навчання архітекторів. Дуже рекомендую.

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

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

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

Я серед іншого читав бізнес-літературу, вивчав рішення, які впроваджують великі ентерпрайз-корпорації. Йдеться про всілякі ERP-системи, CRM-системи, а також інші речі, які закривають базові бізнес-функції — у них теж варто орієнтуватися, аби щоразу не пропонувати зробити велосипед з нуля. Можна подумати: для чого воно мені потрібно? Але тут є проста відповідь: для розширення кругозору і кола понять, якими ви можете оперувати. Під час співпраці з клієнтом це нерідко стає у пригоді. Я вважаю, що варто розширювати спектр своїх знань і вивчати базові рішення для різних проблем, а не тільки концентруватись на глибшому розумінні однієї конкретної галузі.

Якщо говорити конкретніше про літературу, яку я читав для свого розвитку як архітектора і можу порадити іншим, то це такі книги: «МВА за 10 днів» Стівена Сільбіґера, «Data Science для бізнесу» Фостера Провоста, Тома Фоусетта, «Від хорошого до величного» Джима Коллінза, «Tribe of Mentors» Тімоті Феррісса, «The Four: The Hidden DNA of Amazon, Apple, Facebook, and Google» Скотта Галловея.

— Як це — думати про весь проєкт зразу і планувати його розвиток, масштабування? Чи завжди це вдається?

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

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

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

Щодо низькорівневого планування архітектури на декілька років уперед, то такого практично немає. Звісно, є глобальна стратегія розвитку, але все ж працюємо ми за методикою Аgile. Наприклад, у нас стартував проєкт: ми зібрали ключові вимоги й створили архітектурне бачення, збудували скелет, а далі воно все йде інкрементно. Провели спринт, і з’явилися нові вимоги, що зачіпають архітектуру? Окей, ми змінюємо архітектуру. З’явився технічний момент — додаємо, поправляємо й розвиваємо далі, все поетапно.

— У чому різниця між Solution Architect і Senior Solution Architect? Чи є перехідні посади між ними — наприклад, мідл, джуніор? Чим займаються ці фахівці?

Senior Solution Architect — це людина, яка має під собою команду. Члени цієї команди, архітектори, своїми силами будують цілу велику систему. А я працюю вже з рівнем Enterprise, координуючи при цьому дії команди, бо маю більше досвіду. Як і в будь-якій команді, є людина, яка ухвалює головні рішення, і в цій сфері вона називається Senior Solution Architect. Те саме, що й з розробниками.

Звичайно, є перехідні ланки. Щойно світчаєшся з посади, наприклад, техліда, стаєш Associate Architect. Це своєрідний аналог джуніора. Після того з часом людина зростає до рівня Application Architect. Тоді вже працює з конкретним доменом, на своїй конкретній технології, розробляє рівень аплікацій, тобто це більш низькорівнева розробка. І опісля стає Solution Architect, який розробляє повноцінну систему, потрібну замовникові.

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

— А що далі після Senior Solution Architect? Які є потенційні напрямки для розвитку кар’єри?

Є ще такі посади, як Principal Architect і Distinguished Architect. Це, образно кажучи, гуру, які можуть побудувати всі процеси великого ентерпрайзу. Що вища ланка, то ширша сфера, за яку фахівець відповідає. Наприклад, Distinguished Architect розвиває цілу величезну компетенцію. Principal Architect у сфері Big Data, до прикладу, займається цією компетенцією у всій компанії, має свій кластер архітекторів, яким передає свої навички.

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

— Чи варто очікувати значного зростання зарплати, якщо переходиш із посади техліда в архітектуру?

Сильного зростання одразу не буде. Це цілком логічно, адже ви переходите на рівень Associate Architect і отримуєте зарплату дуже близьку до тієї, що має Tech Lead. Тож на момент переходу не варто очікувати на стрибок.

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

— Чи можеш ти назвати мінуси цієї професії?

Досить незвичне питання. Можу сказати лише, що вона не для всіх — багато кому цікаво просто писати код, а не розбиратися в особливостях бізнесу. Ще тут треба багато комунікувати, тому якщо ви, наприклад, яскраво виражений інтроверт, то архітектура не для вас. Але я не можу назвати це мінусами, радше це особливості професії.

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

— Чому ти обрав для себе саме Івано-Франківськ як місце проживання? Адже на цьому рівні для тебе уже відкритий весь світ

Прозвучить, можливо, кумедно, але все просто: я тут народився і мені дуже подобається це місто. Я ніде більше не жив упродовж тривалого часу. Звісно, я поїздив по світу — був у різних проєктах, на discovery тощо, але бажання переїхати кудись назавжди не виникало.

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

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

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

— Наскільки реально розробнику дорости до архітектора в Івано-Франківську? Що зараз з ІТ-ринком у місті та чи багато перспектив?

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

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

— Чи багато ти працюєш і як виглядає твій типовий робочий день? Як до цього ставиться родина?

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

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

Щодо робочого дня, то час у мене трохи зміщений, адже працюємо з канадцями. Різниця в часі з ними становить 10 годин. Тому працюю, як правило, з 10:30 до 19:30. Бувають виняткові кейси, коли доводиться посидіти до 20:00–21:00, але це рідко, стараюся так не засиджуватися. Доки ще не було пандемії COVID-19 і я працював з офісу, було певною мірою простіше. Адже закінчив усе, поїхав додому. А тепер працюю, по суті, більше — в сумі набігає годин 9–10 щодня.

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

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

— В якому напрямі плануєш розвиватися далі? І за чим, на твою думку, майбутнє у сфері ІТ?

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

Щодо майбутнього, то сьогодні є серйозна тенденція до роботи з даними: Big Data, Data Analysis i Data Science і все з ними пов’язане. Адже ми вже можемо нагромаджувати великі обсяги даних і працювати з ними у всіх сферах. Тому багато великих проєктів будуть крутитися саме довкола цього домену. Ще цікаво було б отримати досвід з проєктами extended reality — віртуальної та доповненої реальності.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось31
До обраногоВ обраному16
LinkedIn

Схожі статті




Найкращі коментарі пропустити

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

Ну блин... Серьезно?.. Скоро уже чувак что закончил курсы полтора года назад будет такими фразами кидаться.
Нет, конечно в 2010 еще было не так популярно как сейчас, но... это простите не середина девяностых, и даже не начало двухтысячных.

Тут давеча статейка была про дядечку 61-летнего... вот он реально стартовал когда это было не модно.

Готовлюсь к бомбалейло в каментах от 40 летних миддлов, на тему, что молодому пацану дали синьор архитекта. И отмечаю, что непонимание того, что промоутят не за выслугу лет, а за готовность брать на себя ответственность, и является причиной, почему бомбящие до сих пор миддлы.

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

Solution Architect не единственный вид архитекта, есть ещё System Architect и другие. Но в разных компаниях часто Tech Lead и выполняет работу System Architect’а.

А solution да, больше про общение со стекхолдерами, попытки понять бизнес и построить очень высокоуровневую архитектуру, которую уже дорабатывать/реализовывать будет sys architect / tech lead. Это уже больше технический pre-sale manager.

29 лет — да какой он архитектор, молоко ещё на губах не обсохло, наивысших материй опыта ещё не познал, 49 лет — да какой он архитектор, старый пёс, на фортране разве что кирпичи класть. Так и живём

103 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Здається тут йдеться не про того архітектора що йде після Tech Lead

Так думают в основном разработчики :) Может в статье не совсем раскрыта суть ПОЧЕМУ же умение разговаривать с клиентами так важно? Потому что в разговоре с клиентами вы понимаете не функциональные требования и ограничения, так называемые качественные атрибуты. Плюс умеете их приоритизировать. И это как раз то, что больше всего влияет на архитектуру приложения. Тех вид конечно тоже принимает архитектурные решения, да и в архитекторы идут в основном бывшие тех Лиды, но мало кто понимают насколько разная это работа

Ніхто не говорив що розмовляти з клієнтом не потрібно, чи не потрібно вміти. Але отримати quality attributes може і BA. Робота саме АРХІТЕКТОРА РІШЕНЬ на цьому ТІЛЬКИ ПОЧИНАЄТЬСЯ.

ну я это ж и сказал.

Взагалі аутсорс наш вже скотився повністю в балабольство.

Кожен дев «говорить з клієнтом» — бо робота все більше нагадує аутстаф, скрам команди з членами з боку замовника у вигляді як мінімум продакт оунера і тд.

Кожен QA говорить з клієнтом — уточнює ріквайрменти ж.

Кожен лід тільки і робить що говорить з замовником — бо ж треба вияснити нарешті що ж саме треба закодати.

Те саме кожен BA за визначенням — говорить із замовником нон-стоп щоб витягти з нього ті кляті реквайрменти, а по факту допомогти йому їх створити і хоч якось формалізувати.

Є ще проектний менеджер, делівері менеджер — і вони звичайно ж говорять із замовником весь час. Ну а як же? Їм же треба проект із ним координувати.

Про сейлів і решта маркетинг взагалі мови немає.

Всі говорять із «замовником»! ВСІ!

І тут на сцені з’являється архітект. І всі такі «ах, а він що робитиме?» Ну і як що — говоритиме із замовником :D
А, ну все ясно ж.

А по факту що таке «замовник»? Це ж не одна людина, не одна роль, і навіть не десять. І може виявитись, що говорити з рандомним клерком з боку замовника про останні матчі по бейсболу — це не робота архітекта, раптово. А збір і приорітизація quality attributes це дуже конкретна річ, яку не можна описати як «говорити із замовником» — бо буде як мінімум не зрозуміло з ким саме з боку замовника, про що і з якою метою.

А по факту що таке «замовник»? Це ж не одна людина, не одна роль, і навіть не десять. І може виявитись, що говорити з рандомним клерком з боку замовника про останні матчі по бейсболу — це не робота архітекта, раптово.

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

А збір і приорітизація quality attributes це дуже конкретна річ, яку не можна описати як «говорити із замовником» — бо буде як мінімум не зрозуміло з ким саме з боку замовника, про що і з якою метою.

тем не менее в статье так общими словами и описали

Всі говорять із «замовником»! ВСІ!

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

в статье так общими словами и описали

Тобто не описали нічого. Це як сказати, а що робить архітектор — «працює».

в общем случае не вижу в этом ничего плохого

Мова про те що це нічого не означає. «Говорити з замовником» це дуже розмите формулювання, але ніхто нібіса не знає з ким конкретно і про що конкретно має архітект говорити.

надо отдельную статью писать короче, я понял уже :)
попробую дополнить, обязанности архитектора начинаются с выяснения какие архитектурные атрибуты больше всего важны для будущего решения. Проблема в том, что ПМ и БА не всегда фокусируются на сборе тех требования, которые могут быть важны для будущей архитектуры

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

вы сделали неправильное разделение ) есть продуктовые компании, а есть сервисные. И в сервисных компаниях потребность в архитекторах выше, хотя бы потому что они не строят решение для себя, а строят его для клиента.

красивое надо записать в аналы

БА не принимает решений о том, как именно требования будут реализованы

Есть systems architect, solution architect, enterprise architect. Так вот чем дальше, тем меньше хард скилов, и больше умения рисовать на вайтборде, обосновывать свою точку зрения и писать килотонны ентерпрайзной макулатуры.

меньше хард скилов, и больше умения рисовать на вайтборде

Як хард скіли стали протилежністю малювання на вайтборді? Що саме ви там малюєте? ;-)

обосновывать свою точку зрения

Це потрібно скрізь і завжди.

писать килотонны ентерпрайзной макулатуры

А, ну так би і сказали ;-)

Що саме ви там малюєте? ;-)

боянЪ жы ж )) youtu.be/BKorP55Aqvg

Про важливість хард скілів: www.youtube.com/watch?v=B7MIJP90biM
;-) :D

на самом деле вопрос с перпендекулярными решается просто вот смотри чтобы нарисовать 2 линии (уточнение речь об прямых) нужен лишь лист бумаги просто он 2-мерный чтобы нарисовать 3 линии достаточной перейти в 3-мерную картинку и вуаля соотв. дальше на 7 перпендикулярных линий (здесь прямых) достаточно просто 7-мерного пространства

— Професоре, допоможіть — я ніяк не можу уявити собі 4-вимірний простір.
— Ну це ж просто, студенте. Просто уявіть собі н-вимірний простір, а тоді покладіть н рівне чотирьом.

а ты проецируй ))

ну если есть желание

просто писать код

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

29 лет — да какой он архитектор, молоко ещё на губах не обсохло, наивысших материй опыта ещё не познал, 49 лет — да какой он архитектор, старый пёс, на фортране разве что кирпичи класть. Так и живём

Охренеть, я отстал от жизни. Концентрация тайтлов у архитектора зашкаливает в этой статье). И это реально? Супер архитектор с командой других архитекторов? Они там новый гугл разрабатывают?)

забавно читать этот камент от человека с тремя тайтлами

В своём глазу брёвна не видно ;-)

Так він на своїй шкурі відчув :D

Якщо в СС черги на навчання архітектів, то чому вони наймають сторонніх в той же час?
djinni.co/jobs/302177

Тому що навчати треба, умовно, півроку, а сторонього найняти можна вже завтра.

тобто ефективність внутрішнього навчання така собі

Якщо хтось тобі скаже, що у них можуть навчити бути архітектом (програмістом, тестером, аналітиком, газоелектрозварювальником...) за один день — плюй їм в очі.

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

Якщо, умовно, ЗСУ потрібно 100 танків на рік, а Львівський Бронетанковий може виготовити тільки 10 штук на рік і Харківський ще 10 — то решту 80 треба десь по можливості купити, так?
Тут аналогічно — якщо, умовно, є два архітекти, які можуть вести групи, то при розмірі групи в 5-10 осіб і тривалості навчання півроку — за рік 100 осіб ніяк не навчиш, навіть якщо бажаючих більше ніж достатньо.

і в чому ж причини що за майже 30 років СС не зміг побудувати конвеєр підготовки в потрібних масштабах? тобто повертаємося до моїх закидів про ефективність і утримання ))

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

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

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

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

А на чем основано такой утверждение? Я могу аргументированно утверждать что в Серве сотни людей которые пришли интернами/джунами без опыта и доросли до нормального уровня (и я не про лычки).

Доросли вони завдяки самонавчанню.

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

с помощью компании

А в чому ця допомога полягає?

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

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

А в чому ця допомога полягає?

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

Составление карьерного пути

Давайте без жартів.

стимулирование

Seriously? :D

компания может задать вектор

А хто в компанії це робить? ;-)

ну компания с которой мы с вами сотрудничаем отлично с этим справляется, есть школа архитекторов которая по моему мнению является отличным курсом — рекомендую.

Я пройшов. Сертифікат туточки: www.linkedin.com/...​-6817780006324891648-EUqd

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

Я написав кілометровий фідбек, і то всі зауваження не влізли — тільки найбільш drastic речі.

Але там ніякий фідбек не допоможе — бо щоб вивчити умовного сіньора/ліда на умовного солюшн архітекта потрібно дуже багато чого зробити, стільки що scope явно буде занадто великий для наших ІТ компаній. По хорошому це мав би бути full-time курс на 3-4 місяці. Та/або участь хоча б part-time як architect associate на проектах разом з досвідченим архітектом — для переймання досвіду. Ясно що в таке вкладатись ніхто не збирається і близько.

P.S. Але — честь і хвала EPAM-у хоча б за це!
Тому що в інших компаніях немає навіть того. А в деяких, особливо менших, взагалі немає тупо нічого. Всі хочуть знайти сіньорів і архітектів просто на вулиці.

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

Ну блин... Серьезно?.. Скоро уже чувак что закончил курсы полтора года назад будет такими фразами кидаться.
Нет, конечно в 2010 еще было не так популярно как сейчас, но... это простите не середина девяностых, и даже не начало двухтысячных.

Тут давеча статейка была про дядечку 61-летнего... вот он реально стартовал когда это было не модно.

Помиляєтесь, просто мотивація була більш романтична. Як казали на одному форумі в 2000-х, програмістами ставали ті, хто читав Стругацьких.

ну я про себя могу сказать, что в 2003 году, когда я поступал в универ «на программиста» о больших ЗП в ИТ я не слышал, и за ЗП шли тогда в юристов вроде как. Так что тогда шли в программисты в основном кто любил покодить ли просто ковырять компьютеры

Все верно.
Я поэтому и упомянул девяностые или начало двухтысячных.
Моя первая полноценная работа где я «нажимал кнопки» была за $200 по курсу 5. Одноклассники, что закончили на юристов/бухгалтеров и пошли по специальности получали больше, а некоторые — заметно больше :)
И то, на то время компьютеры были уже распространены, и это было не так необычно как в 90-е.

не хотів нікого образити цією фразою)
лиш додам контексту, я поступив в коледж в 2006 на програмну індженерію,
в 2010 вже працювати фултайм, тобто до того в парель з навчанням вже був парт-тайм 2-2,5роки
+ стосовно популярності варто до уваги брати ще місто — так як це не Львів, Київ і Дніпро, і на той час компаній в ІФ було мало

програмну індженерію

:D
— Як називається предмет?
— Оце валить!

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

Цікава стаття, дякую!

Питання — чи нема ностальгії за старими добрими часами, коли треба було сідати і писати код? :)

я не припинив писати код зовсім)
часто коли мені потрібно щось перевірити я сам створюю PoC/спайк і тд, щоб переконатись що то рішення насправді працює так як його описують
+ я намагаюсь ревювати ключові аспекти системи, щоб реально розуміти що там відбувається

У нас такой «архитектор» называется просто «менеджер» (по работе с клиентом) с определённым пуллом знаний в ИТ. И для этого ему не нужно быть технарём.
С другой стороны «архитектором» в моих круга называется чел, который может спроектировать систему основываясь в первую очередь на технических знаниях, а не на том, как эффективно он сидит в коллах с заказчиком.

Вообще правильный термин — presale manager

Об этом и статья. Менеджер — это действительно пресейл|{не технарь}. А архитектор — это о бизнес-процессах клиента.

Помню в 90х между 2 и 3 курсом подрабатывал (программистом, да) в торговой конторке, но не о том сейчас....

Так вот, контора торговала всяким, и продавали его стадо «телефонистов».... нужно звонить и парить.

Вот тогда меня поразило, когда понял что треть своей зарплаты (то что ниже рынка) они получали тайтлами.
На секундочку, каждый из них именовался гордо; «технический директор». ))

На секундочку, каждый из них именовался гордо; «технический директор». ))

Американскся классика ж — каждый Vice President.
m.youtube.com/watch?v=cISYzA36-ZY

кстати да я когда-то столкнулся с «копроративной деградацией тайтлов» когда оказалось что vp почему-то главнее cto и пришлось разбираться кто есть кто и оказалось что cto должность техническая а vp уже чисто управленческая т.е. грубо говоря в заголовке чистый кликбейт и слово «архитектор» там «означает» совсем совсем другое и проще говоря не означает вообще ничего а «архитектура» как исходящий документ не имеет ничего общего с «архитектурой» как чисто технически того что и как на самом деле будет реализовано кроме возможно 20% упомянутых по тексту бизнес терминов и то это щетаю удача

«архитектором» в моих круга называется чел, который может спроектировать систему основываясь в первую очередь на технических знаниях, а не на том, как эффективно он сидит в коллах с заказчиком

сферическую в вакууме :) и не понятно то ли это, что хотел заказчик

Але є можна перекласти вияснення реквайрментів на BA (бо нащо він ще?)
ASR-и можуть бути очевидні (якщо у вас е-комерс рішення, новинний сайт, блог платформа, yada yada — треба окремо в замовника допитуватись що воно і як має працювати? нафіг не треба — все більш-менш зрозуміло і так, решту замовник і сам не знає).

Ну і головне — замовник САМ НЕ ЗНАЄ.

На архітектурних курсах розказують що треба з замовником зробити workshop і просто через сценарії і тп лабуду з ним виробити ті ASR-и через quality attribute-и і тп речі. Але в половині сценаріїв і без замовника зрозуміло як і що має працювати, а в іншій половині він буде видавати conflicting вимоги, приорітизувати одразу все на максимум, і взагалі банально заплутається.

Але в половині сценаріїв і без замовника зрозуміло як і що

Якщо вгадали — це круто. А що буде якщо не вгадали? Як і хто буде пояснювати, чому аутсорсер не має повертати бабло за 2-6 місяців роботи (або може ще якийсь штраф)?
Але це в аутсорсі.

В продукті ще цікавіше. В простих випадках ви не попали в АСРи і контора прогоріла (не отримала раунд інвестицій, не встигла до якоїсь події тощо). В складніших, все запустилось, але наступні 6-12 місяців замість того, щоб розвивати продукт, ви гасите пожежі:
— система не скейлиться після реклами на техкранчі, а користувачі йдуть;
— користувачі працюють по суботах, а ви розраховували, що буде 8/5, і апдейти ви робите по ночах (люди звільняються);
— поки ви налаштовували ЦІ/ЦД і писали чистий код, конкуренти писали фічі, і вже ви дописуєте фічі в сб та нд.

Ну і головне — замовник САМ НЕ ЗНАЄ

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

Якщо вгадали — це круто. А що буде якщо не вгадали?

А якщо астероїд в Землю навальнеться? Хто платити бабло за всі збитки буде?!? Га! :D
Читайте далі по тексту — замовник сам не знає, вгадувати будете без варіантів. Будете мучити замовника питаннями, сценаріями і всією решта лабудою — і все одно потім виявиться що ринок то потребував зовсім іншого. Але і цю всю лабуду легко делегують BA-ям.

В продукті ще цікавіше.

Та знаю я як там «цікавіше» — є інфа від людей як стартап, який аутсорсить їм, пиляє свій продукт. Прод падає регуляорно, останній раз ліг на два дні бо дурень CTO (з Дойчлянду) не хотів додати індекс в Монго, хоча сама Монго йому підказувала що треба додати туточки індекс. При тому що вони платять за Монгу, мають саппорт там, їм дзвонили звідти і казали «пацани, щось у вас лоад високий дуже і ривками» і тд і тп. Його пояснення було на 100 балів — I’m not a Mongo guy :D CTO! :D
І нібіса тому продукту не сталось — пиляють далі. Поки ви пишете тут казки про супер-дупер якісну розробку в продуктових контор.

Не «не знає», а «не усвідомлює».

Саме не знає. НЕ. ЗНА. Є.
Не знає, курча. 15 років я працюю з замовниками «от мала до велика» — ніхто ніде нічого ніколи не знає. Завжди розробка зводиться до «давайте щось зробим, запустим, посадим, а тоді бляха вже зрозумієм що нам треба щоб плавало». 15 довбаних років. Тому не вішайте мені лапші.

Якщо бізнес «не знає» в сенсі «не може пріоритезувати», то бізнес довго не проживе

Це беліберда. Коли заснуєте свій великий ентерпрайз тоді поговорим. Там ніколи ніхто нібіса не може приоритезувати — але спробуй цих потвор потопи. Подивіться на спискок фейлів одного хоча б Майкрософта. Вони проспали все! Мобайл (від мп3 плейерів починаючи), соцмережі, пошуковики, месенджери, сабскріпшн, тд тп, на останній сходинці забігли в клауд — роками після Амазона! Амазона — який взагалі рітейлер а не ІТ/софтверна компанія.
А якийсь IBM, наприклад, почав думати про стратегію щодо клауда коли Ажур вже релізався :D
І що? І нічого. Що ті, що інші — плавають собі чудово, нікуди не поділись.
Тому не розказуйте казок, в першу чергу собі.

Solution Architect не единственный вид архитекта, есть ещё System Architect и другие. Но в разных компаниях часто Tech Lead и выполняет работу System Architect’а.

А solution да, больше про общение со стекхолдерами, попытки понять бизнес и построить очень высокоуровневую архитектуру, которую уже дорабатывать/реализовывать будет sys architect / tech lead. Это уже больше технический pre-sale manager.

Готовлюсь к бомбалейло в каментах от 40 летних миддлов, на тему, что молодому пацану дали синьор архитекта. И отмечаю, что непонимание того, что промоутят не за выслугу лет, а за готовность брать на себя ответственность, и является причиной, почему бомбящие до сих пор миддлы.

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

ps профессиональную оценку автору делать не буду, мне пофик

вполне себе нормальная позиция

Полностью поддерживаю. Но такие миддлы обычно не бомбят по поводу 23х летних синьоров и прочих 2*летних тайтлов)

если человек в 23 года хочет отгребать от клиента с одной стороны и от технарей с другой, постоянно упарываясь в овертаймах это его выбор ))

Начав отгребать в 23 к 43 можно устроить себе шоколад и проводить больше времени с семьей. ;)

можно, но желание «контроля» не позволит, дети к тому времени часто уже подросли и время потеряно, да и нервы давно ни к чёрту

Вы сейчас слишком обобщаете

поддержу, да и бомбой попахивает )) немного

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

готовность брать на себя ответственность

материальную? всем своим движимым и недвижимым имуществом?
нет? www.youtube.com/watch?v=VCqGmFlsAVg

Готовлюсь к бомбалейло в каментах от 40 летних миддлов

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

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

Ні, не тому. Класовая нєнавість цікава штука, але спробуйте ще раз.

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

балакати і малювати діаграмки

Екстраполювання особистого досвіду на загальний то є когнітивне упередження.

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

чому завжди, коли хтось попадає в статті ДОУ про архітекторів з віком до 30 років, то він завжди з софт серва?

11 років досвіду і перемога на IT Awards думаю може відповісти на це питання, чи обовязково треба мати 40+ ?)

звісно ні )) IT Awards — це там де софт серв сам собі видає призи? :D

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

Меня не приглашали — ваши конкурсы не конкурсы.

оооо, ну раз IT Awards тогда вопросов нету =)))) господи, тебе самому не смешно?))))

жаба давить?)

ні :) я awards отримую у вигляді акцій компанії, а не статуетками :)

Я думаю, у архитекта из Софтсерва финансовый awards поболе будет, чем у рядового инженера из SAP, даже с учетом акций ;)

їм статуетки дають ))) може ще годинник іменний

рядовий інженер із САП створив суб продукт, який уже рік як в продакшні. чужі гроші нетреба рахувати :)

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

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

А ви приєднуйтесь до SoftServe і самі зрозумієте ;-)

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