Приходя в айти, разработчик вряд ли задумывается о карьере как таковой. Обычно все начинается с простого интереса: сидишь в интернете и вдруг задумываешься — а как это работает? Дальше по-разному: кто-то делает проекты в школах, у кого-то родители тоже работают в этой отрасли — и вот уже верстаешь простейшие HTML-странички и начинаешь углубляться в CSS. Меня сфера айти окружала всю жизнь, с самого детства. Сейчас, накопив опыт и став архитектором решений, я с радостью поделюсь рекомендациями с теми, кто хотел бы тоже идти этим непростым, но интересным путем.
Собеседования, технологии, языки и молодой разработчик
Прежде всего, начинающий разработчик должен учитывать: для начальных вакансий редко указывают конкретный язык, с которым придется работать, и не ищут конкретного специалиста. Обычно пишут список близких языков и спрашивают примерно… про все. Редко есть понимание, что конкретно ты будешь делать на этой вакансии — поэтому не упускайте шанса изучать новое.
Скажем, я не планировала работать именно с Siebel CRM, просто искала разные вакансии в рамках разработки ПО. Мне ответили в компании ITFB, будущий непосредственный руководитель довольно интересно рассказал, чем они занимаются, и я решила попробовать. Дальше — обучение, порядка месяца, и примерно трехмесячная стажировка, во время которой новобранцы показывают усвоенные навыки и решение типовых задач. Там происходит и некая первичная фильтрация: например, у нас стажировку начинали шестеро, а на работу приняли двоих. Насколько я знаю, это весьма распространенная схема в айти-компаниях.
Не бойтесь «немодных» технологий и специфических областей разработки. Мой опыт в Siebel-интеграторе прекрасно показывает: из-за узкой специфики сложнее найти опытного специалиста. Пока жива технология — работа будет. Такого специалиста непросто найти и выучить, круг их узок, и обычно все так или иначе знакомы — поэтому по цепочке контактов специалист и компания всегда могут найти друг друга. Если область разработки, к тому же, позволяет получить разносторонний багаж знаний, как в случае с Siebel — от базы данных до интерфейса, то после этого для тебя нет вообще ничего невозможного.
То, на чем вы пишете, на самом деле неважно. Технология — это инструмент. Разные языки были просто созданы для разного, они все со своими плюсами и минусами. И если у человека есть интерес к разработке, он может так или иначе освоить любой из них.
На собеседованиях часто оценивают: нравится ли человеку вообще разработка? Многие становятся разработчиками, потому что это модно, популярно, хорошо оплачивается. И это всегда видно — достаточно спросить, что еще ты сам пробовал написать для души и на чем? Почти любой айтишник, действительно любящий сферу, всегда изучал еще что-то интересное ему, искал, куда применить свои навыки — делал свои сайты, создавал свои игры. Для него это вызов, у него азарт в глазах. И мне кажется, только такие люди могут подняться выше уровня среднего разработчика.
Творчество айти
Когда человеку не интересно, он быстрее сгорает. Когда в первый раз делаешь то, что заработало, — чувствуешь себя богом. Это ощущение превосходства, что машина тебя слушается, есть в каждом разработчике. Это и есть романтика отрасли. Те, кто говорят, что айти-профессия — это скучно, неправы. Это всегда творчество, и в итоге здесь остаются только творческие люди. Ведь машина делает все по инструкциям, но их так много, они конфликтуют — и лишь человек может понять, где этот конфликт. Ты все время играешь в Шерлока Холмса, расследуешь баги, открываешь логи, строишь теории.
То, что программисты скоро будут не нужны и программы будут писать программы, — неправда. Программы пишут программы очень давно, с 70-х годов. И программисты все еще нужны! Дело в том, что любая программа, даже самообучающаяся, она… глупая. И всегда нужен человек, который поймет, что она делает не так.
В айти, кстати, так много молодежи, потому что им проще обучаться, выяснять что-то новое, но наиболее фундаментальными знаниями обычно обладают люди старше, те, кто был в этом с момента развития. И они понимают, что современные технологии — это надстройка над давними идеями. Никогда не было идеальных решений, идеальных разработок без багов. Любая технология растет, достигает технического пика и становится слишком сложной и неподдерживаемой — и придумывается что-то на замену. Мы всегда работаем с тем, что уже кто-то придумал за нас. И это здорово, это успех, если твое решение повторяют.
Когда разработчик перерастает рядовой уровень, появляются новые тонкости. Обычный разработчик выполняет конкретную задачу, как умеет, теми инструментами, которыми умеет. Он не знает, как в принципе все устроено внутри, и ему не обязательно это знать — есть более старший разработчик и архитектор, который дает задачи. Архитектор приходит обычно именно в поддержку на уже существующий проект, он должен понять всю структуру и все взаимосвязи.
Если проводить аналогии с домом, то снаружи вы видите, что дом построен из кирпича, у него такая-то форма крыши. А архитектор — это прораб, который руководит рабочими, строящими этот дом. Программист наносит штукатурку, решает конкретную задачу, а прораб-архитектор понимает, что если нанести эту штукатурку, то нужно будет переделать, так как под этой стеной еще нужно отремонтировать электрику, а здесь нельзя сносить стену, потому что в будущем наверху будет еще один этаж. Рядовой разработчик этого не знает.
Архитектор распределяет задачи разработчикам, придумывает, как внедрить решения в уже существующую архитектуру, как совместить всех разработчиков, чтобы они делали то, что нужно, не мешали друг другу и правильно понимали свои задачи. Чтобы все делалось в правильный момент и в правильное время, а не заливали пол до того, как возвели стены. Это идет от имеющегося у него опыта разработки.
Становление архитектора-управленца
Управленческий опыт наращивается по большей части эмпирически. Мне, например, на момент, когда я стала архитектором, просто не хватало времени на специальную литературу или курсы. Я не умела грамотно построить свой график. Поэтому я потихоньку училась на опыте, прислушиваясь к советам коллег. Каждый разработчик со своим характером. А ты должен и задачу сделать, чтобы все скоммуницировались, и при этом на их эго не надавить. По книжке этому нельзя научиться, надо видеть людей, общаться с ними.
У архитектора неизбежно наступает момент, когда тебя не хватает, тебя разрывают на части и ты ничего не успеваешь. Самое правильное в этот момент — просто выдохнуть, отдохнуть. Потому что все всегда в аврале, дома всегда будут гореть, а кони бежать. Если чувствуешь, что больше не можешь, перегораешь, — это просто знак того, что нужно прекратить думать и пойти копать картошку в огороде, например. И в какой-то момент начинаешь опять что-то смотреть, изучать — затягивает обратно.
В первое время ты всегда в переработках, ты не умеешь планировать свое время и четко ставить границу работы: нельзя просто идти отдыхать, если что-то не доделал. И всегда есть люди с синдромом отличников или просто трудоголики. Но важно понять, что отдых — это тоже работа, и на нее тоже нужно находить время. Обо всем остальном вам обязательно напомнят, а вот за этим никто не будет следить. Можно очень быстро выгореть, если не принять, что не все в мире зависит от тебя.
Очень важно уметь делегировать и доверять своим коллегам. Лучше потратить время и научить человека что-то делать, чем регулярно делать это за него, даже если так быстрее. Большая часть разработчиков немного эгоцентричны, нам нравится чувствовать себя экспертами. Сложно указывать человеку на ошибки, да еще и делать это достаточно корректно — мы же помним, как неприятно было когда-то нам на таком месте. И есть еще профессиональная гордость: сколько интересных задач, а у тебя просто нет на них времени. И нужно наступать на горло своей гордости, и отдать задачу тому, кто сможет ее сделать. В какой-то степени нужно делать выбор между собой-специалистом и собой-управленцем.
Я сама наступила на эти грабли: первые несколько месяцев прошли в диком аврале, потому что я просто не умела делегировать, завязывала все процессы на себя. Потом пришло понимание, что я не могу все делать сама. На пути архитектора потихоньку учишься таким коммуникационным и управленческим навыкам, которые до этого никогда не было необходимости постигать. Тебя вдруг начинают тащить на миллион каких-то встреч, на которые в жизни никогда не звали, чтобы узнать твое экспертное мнение. Теперь ты вдруг стал человеком, который должен сказать — а как это сделать.
Сначала я была в панике. Но меня поддерживал мой непосредственный руководитель, Антон Телепнев, объяснял, что я должна и не должна делать, что правильно и нет — не только с технической стороны, но и с управленческой. Как общаться с заказчиками — я не всегда умела корректно это делать, была очень категорична.
А для бизнеса задача не в том, чтобы узнать, что что-то сделать нельзя, а в том, чтобы придумать, как это сделать. Нужно помочь людям сделать тот продукт, который они хотят. И задача архитектора — придумать решение, которое удовлетворит бизнес. Любой архитектор понимает, каковы бизнес-требования к продукту и чего хочет заказчик.
Кстати, редко бывает так, что один проект от начала и до конца закреплен за одним архитектором. Часто мы как подрядчики бываем на проектах, где архитекторы менялись часто, и на архитектуре проекта видны те решения, которые принимал тот или иной архитектор, его профессиональный почерк. Каждый пользуется теми инструментами, которые ему ближе. Поэтому важно иметь понимание того, каким должен быть этот проект, и подбирать человека, который будет делать его именно таким.
Гармония развития архитектора
Каждый архитектор развит по-разному, у кого-то сильнее технические навыки, а у кого-то управленческие. У каждого свой набор софт-скиллов. И всегда нужно контролировать, какая часть у тебя слабее, и стараться развивать именно ее. Если проблема с коммуникацией — обязательно подтягивать, потому что ты будешь общаться непосредственно с людьми, а люди бывают разные. Непродуктивную критику нужно уметь сдерживать, вспоминать, каково было тебе самому в период обучения. Чем лояльнее ты относишься к людям, тем легче управлять командой: люди не делают вопреки, а прислушиваются к тебе. И если ты видишь, что разработчик самостоятельный и ему не нравятся указания, нужно позволить набивать собственные шишки, чтобы понять, почему так делать не стоит. А кому-то нужна помощь, подсказка и коммуникация.
Архитектору самому важно не запускать технические навыки, быть в тренде, быть играющим тренером, иначе не получится грамотно оценивать технические аспекты задачи. Его дальнейшее развитие зависит от развития продукта, которым он непосредственно занимается. Интересно и продолжать его изучать, и внедрять на его базе новые решения, делать то, что раньше никто не делал. Мне такое нравится больше всего. Например, мы на проекте СКБ взяли старенький, немножко некрасивый Siebel, переписали и сделали визуальную часть полностью на Vue.js. Это более популярный фреймворк, и людям, которые с ним работают, проще поддерживать именно фронт-часть.
Лучшее для любого разработчика — быть полезным через свой продукт, создавать то, что помогает людям.
Нет более дурацкой работы, чем делать что-то, что точно никому не понравится. Наша область, например, затрагивает деятельность чуть ли не всех удобных систем, которые вы используете каждый день: Siebel под капотом имеют банки, колл-центры, он применяется для работы с милями авиакомпаний и программ лояльности в косметических магазинах. И так приятно, когда делаешь удобно, чтобы какой-нибудь девочке из колл-центра, которой звонит миллион рассерженных клиентов, стало легче. Даже на уровне какой-нибудь маленькой фичи: скажем, вы сделали иконку загрузки в виде играющего котика. Задача бизнеса — выполнить конкретную задачу за максимально короткое время. Наша задача — сделать так, чтобы нравилось пользователю. Да, иногда твои решения не принимают, а иногда вообще делаешь разработку, которая тебе не нравится. Но в большинстве случаев ты помогаешь людям, и это хорошо!