27 October 2019

Senior, TechLead, Architect — что дальше? Как бороться с рабочей рутиной и куда двигаться дальше?

DevOps
Sandbox
Многие технические специалисты сталкиваются с тем, что достигают максимума в своей вертикали и не понимают, куда двигаться дальше, чтобы работа не превращалась в бесконечную рутину и давала профессиональный рост.

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

С чего я начинал


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

После этого работал в системных интеграторах, где начинал с консультанта по инфраструктурным решениям и за 8 лет дорос до должности CTO, с зоной ответственности в ключе стратегического технологического развития компании. На тот момент мне это было интересно, поскольку открывает возможности для профессионального развития. Я переориентировал часть инженеров на технологии Open Source, которые на нашем рынке особо не пользовались популярностью, мы начали заниматься OpenStack как альтернативой продуктам VMWare.

Через какое-то время я понял, что уперся в потолок, когда расти дальше было некуда и задачи, которые раньше воспринимались как вызов, превратились в рутину.
Было очевидно, что пора менять направление. Я перешел в SoftServe, где изначально собеседовался на должность архитектора, но из-за отсутствия опыта в аутсорсе мне предложили только позицию senior. Я понимал, что это несколько шагов назад, но иногда это необходимо, чтобы разогнаться и двигаться вперед еще быстрее.

Клиентский путь в аутсорсе


Меня привлекли на новый проект имеющегося клиента. Соответственно, нужно было для начала провести основательное исследование, чтобы найти оптимальное технологическое решение. Я сделал сравнительный анализ возможных вариантов, пришел к выводу, какой из них решает задачу лучшим образом, и представил эти результаты клиенту. Он мой выбор утвердил, соответственно меня оставили реализовывать этот проект – я исполнял функции архитектора, работал в связке с одним Python Developer. За полгода проект вырос до команды в 20 человек. Было очень сложно, но интересно. Затем в силу политических процессов компании клиента проект закрылся.

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

Это один популярный сервис, веб-приложение которого попадает в ТОП-50 по посещаемости в США. Заказчик столкнулся с рядом проблем, к примеру, сервис не масштабировался и не мог выдержать нагрузку, когда в силу внешних обстоятельств резко увеличивался поток запросов от пользователей. Клиент пришел к нам с запросом полностью изменить решение, для начала перевести его на другую программную платформу. Помимо инженерной составляющей (всей инфраструктуры, CICD, мониторинга, логгинга и тд), мы покрывали часть DevOps и тесно сотрудничали с разработчиками, которые переписывали старое решение.
Мне повезло, поскольку этим проектом руководил очень опытный Solutions Architect.

Я наблюдал за его работой и многому учился. Например, понял, что раньше недооценивал важность soft skills и что мне нужно поработать в этом направлении. Ведь выбрать технологически правильное решение – это хорошо, но еще нужно суметь донести свое виденье клиенту так, чтобы он понял и принял мою точку зрения, а потом наладить работу внутри команды. Без этого нет шансов показать хороший результат. Архитектор – это мост между клиентом и технической командой. Через полгода этот Solutions Architect вышел из проекта и передал свою функцию мне.

Работать было сложно в первую очередь потому, что условия диктовал исключительно бизнес, соответственно нам нужно было отстаивать свои интересы, чтобы точно знать, что мы выпускаем качественный продукт – например, клиенту была важна скорость и они готовы были выпускать релиз без тестирования, чего мы допустить не могли. За год мы успешно перевезли сервис на новую платформу. После этого клиент к нам вернулся с запросом перевезти решение на другую облачную платформу. Это растянулось еще на год.

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

В тот момент как раз у нас в компании начал активно развиваться Center of Excellence. Туда перешли многие мои знакомые, и я видел, что они там занимаются интересными вещами. Обдумав перспективы и взвесив все «за» и «против», я решил переходить в этот отдел. Это было в начале 2019 года.

Как построена работа в Center of Excellence (CoE)?


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

Набор требований к кандидатам в CoE выше, чем обычно. Например, мы не делаем упор на глубокое знание точечных технологий, скорее — на умение выходить за рамки и учиться новому. Важную роль играют также навыки коммуникации.
Наши специалисты вовлекаются на проект под четкую задачу. У меня среда еще более динамичная, поскольку я работаю в команде Pre-sales. Нас подключают на проекты, которые только заходят в компанию, чтобы разработать их концепцию, которую потом реализует команда delivery.

Схема выглядит так:

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

После этого, начинаем сотрудничество с процесса discovery, который состоит из двух этапов:

  • Onsite – едем в офис клиента на неделю/две/сколько нужно, в зависимости от сложности кейса и объема проекта, проводим встречи и воркшопы с командой, чтобы углубиться в ту проблему, которую мы решаем. Ездим к ним, поскольку личные встречи для этого намного эффективнее телефонных переговоров.
  • Offsite – возвращаемся к нашей команде со всей добытой информацией, чтобы вместе готовить документацию. Она содержит архитектурное видение проекта с обоснованием, что и зачем нужно делать и объясняет, как это решит поставленную задачу. Это очень важный этап, когда нужно все максимально детально и прозрачно объяснить, подготовить качественные шаблоны, посчитать бюджет, чтобы у клиента не осталось никаких вопросов.

Получив всю документацию, клиент решает, будет ли имплементировать предложенные решения. В большинстве случаев он соглашается. Тогда наши компании подписывают следующий договор, после чего проектная команда начинает работу.

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

Пока работаю с delivery командой, параллельно бываю задействован в pre-sale для трех-четырех клиентов. А если какой-то из проектов затягивается, чаще всего в очереди ждут уже несколько новых. К примеру, в это воскресенье я вернулся из Хьюстона и по состоянию на среду у меня уже в календаре на ближайшее время запланированы onsite-сессии с тремя разными клиентами.

Меня такой динамичный темп работы не выматывает, а наоборот заряжает. В среднем за месяц я полторы недели провожу у клиента, остальное время – работаю с командой в Киеве. Но бывают и исключения, когда на стороне клиента нужно провести пару месяцев. В целом, если посмотреть статистику по нашей команде, то за границей мы проводим до 6 месяцев в году. Сейчас у нас есть клиенты из США и Европы (Британия, Австрия), недавно появился еще проект в Сингапуре.

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

Приходится очень быстро перестраиваться и учиться новому как в плане технологий, так и soft skills. Часто на on-site сессии нужно ехать самому. Соответственно, на тебя ложится ответственность достойно представить свою компанию и доказать, что ты – профессионал с высоким уровнем экспертизы и опытом, благодаря чему ты можешь решить проблему.
При этом нужно успевать постоянно учиться и развиваться, следить за трендами и технологиями, которые появляются.

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

Могу посоветовать:

  • Вступите в International Software Architecture Club. Много опытных единомышленников, которые всегда готовы помочь развиваться в направлении архитектуры и нетривиального решения задач.
  • Читайте. Не только профильную литературу, но и литературу по смежным областям знаний.
  • Учитесь новому. Перестаньте думать рамками технологий. Учитесь думать с точки зрения проблемы бизнеса, которую пытаетесь решить.

Ежедневно я сталкиваюсь с таким количеством вызовов, что вряд ли в обозримом будущем это превратится в рутину.
Tags:карьера в it-индустриикарьера в itархитектура
Hubs: DevOps
+17
9.2k 67
Comments 6