7 сентября мы поговорили в прямом эфире с Алексеем Левановым, исполнительным директором в Сбербанке. Леша пришел в Сбербанк в 2014 году на позицию Junior-разработчика. Сейчас он исполнительный директор: продакт и тимлид платформенной команды Сбербанк Инвестор и занимается МП Сбербанк Инвестор и Школами Разработки Сбербанка. Леша рассказывал на примере своего пути: как расти и развиваться в крупной компании, каких ошибок стоит избегать и как инициировать изменения. Поговорили про вызовы и возможности, про work-life balance, про то, как не выгореть и вернуться, если все же выгорел. Делимся с вами расшифровкой эфира.
Меня зовут Алексей Леванов. Мы поговорим о том, как в сфере IT, как мне кажется, стоит строить свою карьеру тем, кто находится в начале пути. Я расскажу то, что мне удалось узнать, и подсвечу ошибки, которые я делал. Может быть, через такую призму это будет восприниматься чуть ярче. Я бы хотел, чтобы наше общение помогло вам расти в большой компании, не перегорать и двигаться в светлое завтра.
Есть три главных качества, которые, как я считаю, необходимы, если вы хотите строить карьеру в IT-компании. Первое и самое избитое – это то, что вам, скорее всего, встречалось не раз; назовем его условно «стрессоустойчивость». Я знаю, что его уже все кладут в свои резюме, но это все-таки краеугольный камень — если это не просто строчка в резюме, а действительно ваше качество. Хотя я бы назвал это качество по-другому: «принятие изменений». Под ним я понимаю способность не просто работать в стрессовой ситуации и принимать изменения, но принимать их достаточно легко – так, чтобы они не были для вас постоянным источником мучений.
Современный мир – это жестко, он постоянно меняется: новые вызовы, новые процессы. Это не обязательно плохо или хорошо – он просто меняется. Появляются новые средства разработки и бизнес-требования, постоянно все новое. Если вы каждый раз будете испытывать стресс по этому поводу, то работать в IT и вообще строить карьеру будет довольно сложно. Особенно учитывая то, что IT всегда на передовой изменений.
Вторая важная вещь состоит в следующем: мало принимать изменения, надо их еще и создавать. Конечно, мы не создаем изменения просто ради изменений, потому что можем; мы меняем что-то, потому что мы эксперты. Мы видим несовершенство процессов, технологий, клиентского пути. После этого мы берем и меняем несовершенную часть. Мы драйвим изменения.
Третья история – самая важная из всех: мы доводим дела до конца. Мало быть стрессоустойчивым и драйвить изменения: если мы не доводим этот драйв до конца или не выполняем свои задачи – грош нам цена.
Вот такие три краеугольных камня. Если вы заметили, я ни слова не сказал о хард скиллах – хотя это принципиально важная вещь.
Сделаем ремарку. Все говорят про хард/софт скиллы, и на этот счет есть много разных мнений. Я считаю так: если вы в начале карьерного пути (только начинается ваша история как разработчика ПО или вообще как IT-специалиста) – делайте упор на хард скиллы. Вышеописанные принципы будут работать, если вы – хороший специалист. Вы можете быть хорошим человеком, обладать эмпатией и развитым умом, даже стараться доводить дела до конца и быть стрессоустойчивым; но, если вы не делаете руками то, что должны делать – тоже грош вам цена, как специалисту. В дальнейшем, с развитием, чем прокачаннее вы становитесь, тем большую роль начинают играть софт скиллы — это правда. На определенном этапе они могут стать такими же важным, или важнее, чем хард скиллы. Но, если мы говорим о начале построении карьеры – делайте упор на хард скиллы, без них никуда.
Изначально я хотел построить нашу дискуссию вокруг своей истории жизни, но понял, что вряд ли такое будет интересно кому-то, кроме моих родителей. Поэтому я попробую рассказать, используя призму личных историй, про перемены, которые происходят – которые делаем мы, про то, как с этим работать, и про то, что может нам помешать. Но сначала — пара вопросов.
Вы исполнительный директор или product-owner (PO)?
Это разные вещи: одно – это должность, а второе – роль. По должности я исполнительный директор, а по роли — product-owner и тимлид. То есть, одна вещь условно записана в трудовой, а вторая – то, что я делаю.
Так это вы придумали, как запрятать подключение быстрых платежей в приложении Сбера?
Очень приятно, классный вопрос, но нет, не я. Передам вопрос нашим экспертам, я сам не изучал, где там система быстрых платежей.
Как много времени сейчас вы занимаетесь именно разработкой?
Хороший вопрос — к этому я хотел дойти постепенно через историю. Если коротко – примерно часа 3 в день уделяю разработке (код, проверка пулл-реквестов и так далее). Понятно, что есть рабочие встречи, которые отнимают время, есть условный бэклог или нарезка задач, но, в целом, разработку хардкорную никто не отменял, и это здорово.
Как взять ответственность product-owner и получить должность?
Честно говоря, я не очень понимаю, что значит «взять ответственность PO». А чтобы получить должность, надо работать. Трудишься, много трудишься, решаешь задачи, если успешно решаешь их – ты растешь. Это базовая история, она везде плюс-минус одинакова. На самом деле, PO – это просто направление развития, которое вам может быть интересно. Мне была интересна не просто хардкорная разработка, а также и влияние на продукт, возможность им управлять – поэтому я развивался в сторону PO. То есть, нужно желание, работа и три основы, о которых мы говорили – из этого складывается история получения должности.
Итак, я рассказал о том, на чем стоит фокусироваться (напомню: на хард скиллах, если вы новичок, далее – в процессе прокачивать софт скиллы), и о трех основных качествах, которые надо в себе воспитать – принятие изменений, драйв изменений и доведение дел до конца. Перейдем к более конкретным историям.
Насчет изменений. Я начал заниматься разработкой в далеком 2011 году, и меня помотало по разным темам. Сначала я писал под Android. Пришел я в разработку так: мы с другом увидели, что на Хабре периодически появляются статьи о том, как очередной человек разработал клон тетриса и заработал миллиарды; собственно, чтобы заманить студента, ничего другого и не надо. Я читал их и думал – я в деле. Макбук появился у друга, поэтому вначале я писал на Android; прошло несколько фрилансов и несколько мест в других компаниях, и в 2014 году я пришел в Сбер. В этот момент у меня уже были приложения в AppStore, некоторые – достаточно успешные, о них написали на Iphones.ru, AppleInsider; я заработал некоторое количество денег и думал, что это – вершина мастерства и карьеры, а другие разработчики мне не нужны. Конечно, когда я пришел в команду разработки, я оказался в ней самым слабым, хотя потребовалась пара дней, чтобы это осознать.
Это было замечательное время. Все общение с бизнесом и другими специалистами шло через нашего project-менеджера, но среда была замечательной для того, чтобы расти. Когда ты один пишешь код, ты в какой-то момент решаешь, что все уже отлично; а потом ты узнаешь, что есть правильные подходы к разработке, паттерны, о которых ты даже и не думал. В среде крутых профессионалов растешь гораздо быстрее.
В какой-то момент наша команда начала не просто расти, а переходить в agile. До этого все разработчики были в одной команде. Это было здорово – каждый работает над разными частями приложения; сегодня – эта, завтра – другая. Было сложно, но интересно. Я помню, что это был мой выпускной год, надо было делать диплом, отрабатывать практику и кое-как ходить на пары помимо полного рабочего дня. Это было сложно, я тогда подсел на кофе – гляссе перед входом в офис стало утренним ритуалом. Тем не менее, это был невероятный опыт, было очень круто. Сама возможность работать над таким продуктом – это было замечательно. Потом мы стали переходить в agile, и от платформенной команды, сконцентрированной только на разработчиках, мы перешли к команде, в которой были специалисты всех отраслей – то есть, к кросс-функциональной команде. С одной стороны, это очень круто и интересно: у вас появляются коллеги смежных направлений, аналитики, дизайнеры, тестировщики, разработчики других платформ и мобильных операционных систем. Но от концепции «вы делаете все приложение» вы переходите к концепции «вы отвечаете за направление в приложении, за какую-то часть». Чем дальше, тем больше таких частей: приложение растет, функционал дробится.
И здесь мы приходим к пониманию того, что нужно больше людей. Для того, чтобы к нам попасть в команду, человек должен был обладать определенным набором качеств, преимущественно – хард скиллы, потому что у нас есть определенный стек технологий, подходы к разработке, и всего этого мы ждали от соискателя. Мы поняли, что всех, кого можно, мы уже схантили; а все, кто еще мог бы нам подойти, уже сидят на теплых местах, и их все устраивает. В тот момент родилась инициатива школ разработки – не лично моя идея, но пришедшая снизу. Это была моя любимая история, и я какое-то время занимался ими.
Мы еще вернемся к кросс-функциональным командам, но сначала я сделаю паузу и расскажу про проблемы, которые могут возникнуть, когда вы решаете строить свою карьеру в IT. На самом деле, если вы выработали три основных качества, то единственная ваша актуальная рабочая проблема – это то самое эмоциональное выгорание, которое уже образовало социокультурный пласт. Это серьезная проблема: хоть оно и не убьет вас, оно представляет серьезную угрозу для вашей продуктивности (и работы, команды, продукта, компании).
Определений выгорания много, но я придерживаюсь такого: это состояние, в котором те задачи, которые вы раньше решали с легкостью, вдруг становятся невыносимо тяжелыми. Вы с трудом заставляете себя их делать, постоянно приходится прилагать неимоверные усилия для того, чтобы концентрироваться и работать. Фрустрация нарастает. Само по себе оно не проходит, но может появиться по ряду причин; я их выделил три – все три я сам прошел.
Самая простая причина – это усталость от продукта. Предположим, вам всегда нравилось распознавание образов; любите вы это направление. Вы пришли в команду, которая занимается распознаванием дорожных знаков или автомобильных номеров, например. И вот вы стали работать над продуктом, изучили OpenCV. Поняли, что он не подходит, и перешли на нейросети. Стали обучать свою сеть, прочитали все, что можно, про математику нейросетей; может быть, даже написали научную статью. Выпустили классный продукт. Прошло несколько лет, и вы понимаете – все, вы больше не хотите этим заниматься. Прошла любовь к автомобильным номерам. Это нормально, это естественный путь, он у всех наступает рано или поздно. Мы все устаем.
Надо двигаться дальше, и нужно понять, как именно. Конечно, лучше такой ситуации не допускать: как только вы понимаете, что тема уже не вызывает восторга, лучше всего поговорить с руководством и перевестись на другое направление. Если не получается – может быть, вы сами сможете создать новое направление. Может быть, распознавание как таковое вам все еще нравится, и можно распознавать что-то другое. А возможно, вся сфера уже не та, и надо менять ее. По-хорошему, надо подготовить преемника на ваше место и спокойно перейти. Хорошая, красивая история.
Бывает такая история, что вы хотели бы остаться в этой же команде. Вам нравится продукт, команда, у вас замечательный product-менеджер – все хорошо, но только не хочется больше писать код распознавания номеров. В кросс-функциональных командах здорово то, что есть возможность переключиться и стать тем самым T-shaped-специалистом, о которых много говорят. Для вас это хорошо тем, что вы учитесь новому. Вы продолжаете развиваться в своей области – хотя и чуть медленнее, изучаете смежные области и повышаете свою ценность как специалиста. Для работодателя – тем, что уменьшается buzz-фактор.
T-shaped-специалист – это эволюция I-shaped-специалиста, обладающего глубокими познаниями в одной определенной области. Допустим, человек учился в школе и решил стать программистом; нравится ему писать на C# или в Unity, допустим. Он не пошел в университет, но он стал экспертом в своей области, и делает игры. Он – I-shaped-специалист; на работу его, скорее всего, уже возьмут. Если этот же человек изучит интеграцию с бэкендом, будет способен подключаться к различным вопросам хотя бы аналитически, будет смыслить в тестировании (наверно, в базовых основах авто-тестирования и написания тест-кейсов), то он будет T-shaped-специалистом. То есть, это человек, который может помочь в смежных компетенциях внутри кросс-функциональной команды.
Buzz-фактор – это выдуманная метрика, которая показывает количество людей, которых можно… куда-то далеко отправить на автобусе, но команда при этом продолжит хоть как-то работать. У идеальной T-shaped-команды он равен N-1 (N – размер команды): даже если из такой команды останется один человек, он сможет продвигать работу вперед, пусть и очень медленно. Конечно, это предельный пример, такого в жизни почти не бывает; тем не менее, создание такой команды – это хорошая практика.
Став T-shaped-специалистом, вы остаетесь в том продукте и с теми людьми, с которыми вам комфортно, вы продолжаете развиваться, и вашему работодателю это на руку, потому что вы закрываете «узкие места» проекта.
Хуже бывает ситуация, когда вы выгораете, не рассчитав силы. Допустим, вам очень нравится проект, вы горите им. Он очень интересен. Вместо того, чтобы понимать, что эта история – долгая, вы пытаетесь ее пробежать в спринтерском темпе. На какое-то время вас хватает. Может быть, вы выгорите после финиша, но скорее – на середине; и то и то – плохо. В моем случае – мне безумно нравился продукт, над которым я работал; меня очень драйвило его создавать и видеть результат, но вот отдыхать у меня не получалось. Я как бы слышал про «work-life balance», но он не действовал. Даже если вечером я оставлял незавершенную задачу и шел с девушкой в кино или с друзьями в бар, в мыслях я все равно оставался в задаче; вроде бы и время хорошо проводил, но не отдыхал по-настоящему, и задачу не делал. Поэтому я решил наплевать на work-life-balance и стал просто работать – работал, работал, работал, а потом что-то щелкнуло. Очень повезло, что само явление «щелчка» произошло после завершения проекта и перед моим отпуском. Я уехал в отпуск, много думал, а, вернувшись, поговорил с руководителем – сказал, что я сейчас не могу писать этот код. Руководитель у меня был замечательный; он спросил, чем бы мне было интересно заниматься.
Так я переключился на развитие того самого проекта школ разработки. Как я уже говорил, у нас был момент, когда оказалось, что разработчиков больше брать неоткуда, и было решено обучать их самостоятельно. Первые школы запустились успешно, часть обучившихся людей была успешно нанята. Сам проект был инициативой снизу. Руководитель отдела мобильной разработки эту идею стартовал, а мы, как сообщество, определяли: что будет в программе обучения, как отбирать людей, как их валидировать на выходе, кого брать – в общем, идея для закрытия потребности. И, когда я выгорел, мне сказали: если тебе этот проект интересен, займись им. Оказалось – жутко интересно.
Стандартные истории про выгорание говорят, что нужно полежать на пляже и посмотреть в небо, пока не отойдете. В моем случае помогло переключение сферы деятельности. С одной стороны я понял, что «work-life balance» все-таки работает; вернувшись из отпуска, я понял, что те задачи, над которыми я сидел, я могу делать быстрее – с одной стороны. С другой стороны – эта новая сфера оказалась безумно интересной, и мы сделали очень многое. Запустили новые направления программы, взяли новых людей, запустили партнерства с университетами, стали выдавать сертификаты об окончании – успешный большой перезапуск. После этого я сумел вернуться в разработку, но вся эта история – о том, что не надо доводить до крайностей. Если вы чувствуете, что что-то идет не так, что вы работаете больше, чем можете – это не хорошо ни вам, ни работодателю. Вы у себя один, а для работодателя это – сложно прогнозируемая история, непонятно, когда вы не сможете идти дальше.
Третий тип выгорания – самый простой, отчасти. Допустим, вы соблюдаете все три основных правила. Легко принимаете изменения, драйвите их. Драйв изменений – это создание возможностей. Если останется время, я расскажу о моей рабочей поездке длиною в год в Стэнфорд, о том, как я попал на MBA-программу в Сбере, и детальнее про школу разработки. Все это было либо за счет того, что я хватал возможности, либо за счет драйва изменений, создания возможностей.
Но, когда вы создаете или хватаете слишком много возможностей – при том, что вы привыкли все доводить до конца – может образоваться снежный ком. В этот момент вы понимаете, что дел попросту слишком много, и вы сами их себе выбрали: это ваш основной и дополнительный проекты, какие-то pet-проекты, обучение. И к такой ситуации нет рецепта; вам придется просто пережить несколько таких снежных шаров, чтобы определить для себя, какой максимальный объем задач вы способны взять.
Это не очень страшная история. Хуже – и для вас, и для работодателя – бывает история, когда вы долгое время работаете на износ, а потом не можете резко вернуться, и возвращаетесь только через отпуск и смену деятельности. В целом, я понял, что отдых – это такая же важная часть работы, хотя раньше я думал, что классно просто работать, работать и работать. Вы просто будете более продуктивны.
Насчет того, нужно ли сейчас идти в мобильную разработку – этот вопрос я слышу часто. То, о чем я рассказывают, актуально для IT в целом, но для мобильной разработки – в частности. Вы можете сказать, что сейчас разработчиков слишком много, рынок насыщен и новые устройства не покупаются. Я скажу, что в среднесрочной перспективе это направление точно останется актуальным. Хотя количество смартфонов подходит к линии насыщения, впереди нас ждут носимые устройства; умные часы уже многие таскают – я тоже, кстати. Я почти уверен, что крупные компании скоро выпустят что-то новое. Нас ограничивает емкость аккумуляторов, но она медленно растет последние N лет. Люди, единожды попробовав не сидеть на одном месте ради решения задач и решать их с помощью носимых устройств, мобильников и других средств, вряд ли вернутся к этому паттерну поведения. Количество устройств будет увеличиваться, и разработчиков будет требоваться больше. Если вы ощущаете, что мобильная разработка – это ваше, то в нее стоит идти. Если вы — уже состоявшийся разработчик, то вы сможете прийти к нам; нам состоявшиеся разработчики всегда нужны. А если вы хотите, но еще не умеете – для вас открыты наши школы. Мы не смотрим на ваши знания Objective C / Swift / Kotlin / Javascript; мы смотрим на базовые вещи, вроде знания алгоритмов и структур данных, понимания принципов ООП, умения писать алгоритмы типа сортировки и объяснять их сложность – то есть, на простые вещи, которые изучают в универе. Это та самая шляпка для ‘T’ — вам остается только получить хорошие знания.
Добавлю про университеты. Признавая и принимая проблемы высшего образования – я все-таки 6 лет учился и 5 лет преподавал, будучи в аспирантуре – я считаю, что ВУЗ, хотя и не обязателен, очень желателен. Хотя ВУЗ и не даст специфических знаний – то есть, если вы захотите быть крутым DevOps-специалистом или разработчиком мобильных приложений, то вам придется самому получать нужные знания – вы сможете получить, помимо базовых вещей (вроде стрессоустойчивости и желания получать новые знания) широкое знание того, что в IT происходит. Вы выйдете тем самым T-shaped-специалистом.
В конце сентября или в октябре у нас начнется новый набор. Приходите к нам, пишите мне; буду очень рад ответить на вопросы.
По идее, проект надо менять каждый год-два, иначе – застой.
Я в целом не спорю, хотя ситуации бывают разные. Кроме того, зависит от человека – от того, что у вас в приоритете. Если в приоритете – интерес проекта, то да. А может быть, в приоритете – команда, с которой вы сработались, и вам не хочется переходить (хотя вы и понимаете, что дальше на этом проекте вы не будете развиваться); у меня такое тоже было. В общем, менять проект надо, но все ситуации уникальны.
Насколько распространена практика у product-менеджеров — устанавливать приложения конкурентов и брать оттуда идеи новых фич?
Напрямую такого не делается, но говорить, что банки и другие IT-игроки совсем не смотрят друг на друга, нельзя. Понятно, что они смотрят; но прежде, чем что-то копировать, надо провести исследования. Хотя бы понять: конкурент это сделал, подумав, или просто так выкатил? И вести собственные исследования, конечно. Прежде, чем продукт будет разработан, проходит несколько этапов – от дизайн-мышления и построения CJM. Нужно понять, нужен ли этот продукт пользователю, какие проблемы он решает. А просто копировать – эта история больше про инди-разработчиков, когда они решают, что могут скопировать и сделать дешевле что-то успешное. Крупные компании все-таки идут своим путем, хотя и смотрят друг на друга.
Возможно, что будущее – за дополненной реальностью?
Возможно. Я сам тоже считаю так – последние несколько лет тот же Apple на своих конференциях для разработчиков (WWDC) делает упор на AR Kit / Reality Kit, движки работы с дополненной реальностью. И все это выглядит как переход от простого MVP к добавлению надстроек на него. Пользоваться этим в телефонах пока неудобно, и стоит дожидаться более удобных форм-факторов.
Как в Сбере происходит перевод сотрудника на уровень выше?
Смотря, что понимать под этим. Если взять простое повышение – то, наверно, так же, как в других компаниях. Я до этого работал в двух местах (и еще в трех стажером), и везде это было приблизительно одинаково. Хороший кейс – вы заранее обсуждаете глобальные цели, по достижению которых можно говорить о следующей ступени. Более плохой кейс – ни вы, ни руководители об этом изначально не говорили; вы просто работали, а потом, через год, вдруг поняли: вы достойны большего. Тогда вы идете и инициируете разговор; тоже нормальная история. Иногда бывает так, что человеку безумно нравится его окружение (проект-продукт-команда); на моей памяти был такой человек: к нему приходили и говорили о том, что его собираются повысить. Он рос, и хорошо, но не начинал разговор сам. В целом, целевая история — составление индивидуальных планов развития, и их выполнение – заявка на обсуждение повышения.
Как часто вы проходите обучение и курсы?
Надо сделать ремарку: я начинал заниматься разработкой в то время, когда нормальных курсов, к сожалению, почти не было. То есть, я вижу два способа обучения разработке: мой и правильный.
Правильный – это через курсы, школы разработки (хорошо бы – наши, но может быть любая школа с наставником, съевшим в этой технологии пуд соли). А вот мой вариант – просто биться головой об эту тему, делать ошибки, смотреть варианты на StackWorkflow. Это тоже рабочий вариант, ты будешь получать готовые продукты, но в голове останется каша, с которой потом придется разбираться.
Я до сих пор не очень люблю курсы. Это у меня пошло со школы – из общеобразовательной я перешел в лицей информационных технологий, где было круто, но я не дотягивал по уровню. У нас в школе не было программирования, а в лицее оно уже подразумевалось. Под угрозой двойки я обложился книжками и стал разбираться; этот паттерн, собственно, и остался у меня. Я тяготею больше не к курсам, а к набору книг. Могу потом приложить в комментариях.
Сейчас я прохожу MBA-программу от Сбера, она включает в себя множество курсов: очных, заочных, виртуальных. Но все эти курсы объединены в единый продукт; чтобы самостоятельно выбирать какие-то направление и учиться в нем – такого не было давно. Хотя я смотрю образовательные сессии с WWDC, больший упор у меня именно на литературу и статьи.
Какие мысли про Dart / Flutter, стоит ли тратить время?
Не люблю занимать позицию обвинителя, но в этом случае все-таки скажу: наверно, не стоит. Я не верю в перспективы этой технологии (хотя это не совсем моя специальность). Пару лет назад все об это говорили, но воз и ныне там. Но, если вам очень интересно, можно потратить некоторое время и решить для себя, нравится ли вам это (и посмотреть, востребовано ли на рынке). Не надо смотреть на тренды – пробуйте делать то, что вам нравится.
MBA от Сбера – что из себя представляет? Очное обучение внутри Сбера или во внешнем университете?
Есть различные курсы и направления. Некоторые кажутся мне очень интересными – те, что связаны с управлением продуктом. Как технический специалист, я привык к тому, что есть задача и её нужно качественно решить; как самостоятельный разработчик, я пытался работать с пользователями и их желаниями-проблемами – но у меня не было в голове карты того, как это делается. В общем, некоторые курсы очень интересны; некоторые — менее интересны, чем могли бы быть. В целом, программа хорошая. Я бы на нее еще раз пошел.
У Сбера есть Корпоративный университет — по сути, он является дочерней организацией. С ним мы и начали взаимодействовать, когда перезапускали школы: теперь КоУ выдает сертификаты тем, кто успешно окончил обучение. Он находится в Подмосковье – это большой кампус зданий, студенты могут проживать на территории.
Достаточно ли внутренних курсов Сбербанка, или внешние тоже необходимы?
Это зависит от того, что вы хотите. Если нужно поддерживать свой уровень в том, чем вы занимаетесь (в разработке, допустим), то, во-первых, надо успешно решать рабочие задачи; во-вторых, комьюнити устроено так, что вы априори будете поддерживать свой уровень и развиваться, если захотите. В этом один из плюсов большой компании: это большое сообщество. Я сейчас не могу назвать другую компанию в России, где есть по 200 разработчиков на iOS и Android; такое комьюнити создает свою культуру – наставничество, обучение. В целом, этого может быть достаточно: нужно тянуться к тем, кто впереди.
Я уже говорил, какой у меня паттерн: я не против курсов как таковых, но я убежден, что книги лучше. Книгами можно заниматься в том темпе, какой вам удобен.
Опять-таки, в корпоративном университете есть множество курсов – и очных, и онлайновых.
Удобно ли ездить в центр на работу и еще в Подмосковье в КоУ?
Ну, сейчас я нахожусь на удаленке – так же, как и вся команда. Проблемы выезда из центра пока нет; когда мы выйдем с удаленки, я буду ездить в центр из Москвы. А в КоУ мы ездим не так часто: в рамках MBA-программы я бываю там примерно три раза в неделю.
Как много времени тратите сейчас на разработку, на каких языках?
Я сам – разработчик мобильных приложений под iOS (изначально – только iPhone и iPad, потом появились часы). Изначально мы писали на Objective C – старом, с примесью 1.0, с использованием MRC). Сейчас у нас отдельный новый проект, в его рамках мы пишем на чистом Swift; то есть, MVVM с координаторами и сервисами, отсутствие реактивщины – мы биндим все через делегаты. Насчет времени я уже говорил: стараюсь тратить побольше, но есть определенное количество важных рабочих встреч – особенно на этапе старта продукта, поэтому получается часа 3-4 в день. Разработка мне все еще нравится, я стараюсь выкраивать, как могу.
Расскажите про Стэнфорд.
Однажды в рабочей почте было сообщение о том, что есть программа Stanford US–Russia Forum, и сотрудники Сбербанка могут попробовать податься на нее. Я подался, прошел 3 или 4 этапа отбора, итоговое собеседование на английском, и попал в рабочую группу с еще тремя сотрудниками Сбера. Суммарно там каждый год 10-15 человек из России и 10-15 из Штатов. Программа направлена на улучшение взаимоотношений между странами; создаются смешанные группы из наших и американцев, которые работают над научными проблемами. Наш год был первым, когда появились конкретные технические проблемы: до этого были социальные и правовые вещи. Наша группа была «FinTech» (финансы и технологии). Год мы делали исследование, а потом защищали его в Стэнфорде. Были на ужине с профессором Зимбардо, который провел знаменитый эксперимент (к нему есть вопросы, но опыт-то классный). В целом, замечательный кейс, который позволял окунуться в другую сферу. Оставаясь в области финтеха, мы исследовали децентрализованные технологии на примере блокчейна, например, и встретились с кучей выдающихся людей, которые этим занимаются как в России, так и в Штатах.
Бэкендом не занимаетесь? Часто ли проводите собеседования?
Собеседования проводим часто. Я участвую собеседованиях как в Сбербанк-Онлайн, так и в новый проект Сбербанк-Инвестор. Плюс, когда речь идет о школах, в собеседованиях на прием и на выпуск я тоже стараюсь участвовать. В скольких именно – зависит от нагрузки: может быть и 0, и 10 в неделю, но обычно 1-2. Бэкендом я не занимаюсь, но интересуюсь. Хотел бы попробовать, когда MBA завершится и станет больше свободного времени.
Как выбираете стек для разработки? Требования формирует заказчик?
Это зависит. Если мы говорим про отдельный модуль для Сбербанк-Онлайн, то стек ограничен существующим продуктом. Если продукт новый, то стек выбирает, наверно, не бизнес-заказчик, а IT-специалист, подсвечивая плюсы и риски для бизнеса. Например, если взять одну технологию – она удобная, классная, быстра, но она отсечет некоторый процент аудитории. Итоговое решение примет, конечно, представитель заказчика, но стек формируют IT-специалисты. В целом, мы смотрим на то, чтобы стек был удобным, достаточно новым, но не хайповым; так, сейчас брать Swift UI на enterprise-проект преждевременно – это не отменяет того, что нужно опробовать эту технологию, но она должна устояться. То есть, не надо брать то, что только вышло, хайпово и явно будет менять API в ближайшие несколько лет, а также то, что уже полумертво.
То есть, стек выбирается, исходя из минимальных логических доводов: это должна быть проверенная, но достаточно новая технология, для которой легко найти специалиста и с которой у нас есть опыт – либо мы легко можем получить его.
Что нужно, чтобы попасть в команду беспилотных автомобилей?
Надо просто подать заявку. Я видел вакансию в направление, связанное с беспилотными автомобилями, у себя в Facebook. Это не какая-то секретная информация; если организаторы потом передадут мне этот вопрос, я поделюсь ссылкой.
Что является Сбербанк-Онлайн, а что – подпроектом?
Сбербанк-Онлайн – например, на платформе iOS – это проект, состоящий из подпроектов (подмодулей). За каждый из них отвечает команда или группа команд. Внутри себя они могут, не отходя сильно от гайдов разработки Сбера, некоторые вещи определять самостоятельно – например, архитектурный подход внутри этого модуля. Важно, чтобы, например, API этого модуля все еще позволял к нему обращаться, но в остальном — все, что происходит внутри него (если оно не идет вразрез с гайдами Сбербанк-Онлайн и базовыми подходами) остается на усмотрение его главных разработчиков. Из таких модулей и собирается итоговый проект.
То есть, все платежи и переводы – это Сбербанк-Онлайн?
Да, всё – СБОЛ. И кредиты, и депозиты. СБОЛ – это большой дом из разных кирпичиков: процессов (например, оплаты) и продуктов (например, депозитов). И их разработка может идти параллельно.
Из СБОЛ можно зайти в Око?
Да, но вы попадете в другое приложение. Все, что внутри Сбербанк-Онлайн – это одна история, это части Сбербанк-Онлайн; когда вы переходите в другое приложение, вы переходите в другую часть экосистемы. Например, из СБОЛ можно зайти в Око, Доставку посылок, Инвестиции; все это – отдельные приложения из экосистемы Сбербанк-Онлайн. То есть, хотя они и самостоятельны, между ними осуществляется нормальная навигация, они интегрированы с СБОЛ, в часть из них можно заходить по универсальному Сбербанк-ID.
Как в Сбере запускается новый продукт, и как в нем стать PO? Например, если идея твоя – не факт, что ты будешь PO.
Здесь возможно несколько подходов. Первый – инициировать изменения. То есть, не просто прийти и предложить идею нового продукта, а предоставить план развития этого продукта. Если у вас есть релевантный опыт и понимание того, как развивать продукты, то гораздо проще будет взять вас – так как будет очевидно, что вы понимаете, что с этим продуктом делать – чем искать другого человека. Часто бывает так, что PO становятся люди, не имеющие отношения к идее; допустим, когда идея носится в воздухе, или когда она давно уже должна была быть реализована, и теперь стал доступен человек с опытом управления продуктами. Есть разные паттерны.
Если у вас есть классная идея продукта – хорошо продумайте ее: посмотрите, какую проблему клиента продукт будет решать, как изменится клиентский путь, что можно будет оптимизировать, какие будут ожидаемые метрики. И презентуйте ее как бизнес-идею; проблем не должно быть. Либо вы можете стать PO другого продукта, имея релевантный опыт; сейчас есть курсы, посвященные этому, также можно поучиться у PO в вашей команде. PO обычно соглашаются менторить.
Какие крутые книги посоветуете?
Очень общий вопрос. Зависит от того, про какие книги идет речь. Если про узкую часть мобильной разработки, то – есть ряд серий, в которых неплохо дается материал. Зависит от того, что вам интересно, какое направление вы хотите.
Что было ранее
- Илона Папава, Senior Software Engineer в Facebook — как попасть на стажировку, получить оффер и все о работе в компании
- Борис Янгель, ML-инженер Яндекса — как не пополнить ряды стремных специалистов, если ты Data Scientist
- Александр Калошин, СEO LastBackend — как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
- Наталья Теплухина, Vue.js core team member, GoogleDevExpret — как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
- Ашот Оганесян, основатель и технический директор компании DeviceLock — кто ворует и зарабатывает на ваших персональных данных.
- Сания Галимова, маркетолог RUVDS — как жить и работать с психиатрическим диагнозом. Часть 1. Часть 2.
- Илья Кашлаков, руководитель фронтенд-отдела Яндекс.Денег — как стать тимлидом фронтендеров и как жить после этого.
- Влада Рау, Senior Digital Analyst в McKinsey Digital Labs — как попасть на стажировку в Google, уйти в консалтинг и переехать в Лондон.
- Ричард «Левелорд» Грей, создатель игр Duke Nukem 3D, SiN, Blood — про личную жизнь, любимые игры и о Москве.
- Вячеслав Дреер, гейм-дизайнер и продюсер игр с 12-летним стажем — про игры, их жизненный цикл и монетизацию
- Андрей, технический директор GameAcademy — как видеоигры помогают прокачивать реальные навыки и найти работу мечты.
- Александр Высоцкий, ведущий PHP-разработчик Badoo — как создаются Highload проекты на PHP в Badoo.
- Андрей Евсюков, заместитель CTO в Delivery Club — про найм 50 синьоров за 43 дня и о том, как оптимизировать фреймворк найма
- Джон Ромеро, создатель игр Doom, Quake и Wolfenstein 3D — байки о том, как создавался DOOM
- Паша Жовнер, создатель тамагочи для хакеров Flipper Zero — о своем проекте и другой деятельности
- Татьяна Ландо, лингвист-аналитик в Google — как научить Google-ассистента человеческому поведению
Автор: galimova_ruvds
