Автор книги о построении карьеры Роман Жихарев беседует с техническим директором G-Core Labs, Василием Михаленей о том, чего современные it-компании ждут от своих сотрудников.
— Как в твоем понимании выглядит концепция ценности разработчика?
Чтобы увеличивать свою стоимость, надо делать три вещи:
— Давай начнем с самого простого. Какие технологии осваивать?
Тренды сегодня меняются невероятно быстро. Поэтому я бы хотел озвучить какие-то общие принципы, а не описывать тренды или заниматься предсказаниями. Идеальной конфигурацией опыта и умений я считаю человека с Т-образной экспертизой (T-shape people). Суть термина в том, что являясь экспертом в конкретной технической области, он должен иметь представление о том, что происходит в соседних.
Например, backend разработчику кроме глубокого знания особенностей языка (например Python) и распространенных фреймворков, обязательно нужно знать и, желательно, уметь построить процесс тестирования, сборки и деплоймента (CI/CD pipeline, например в Jenkins). Он должен знать особенности среды, в которой будет работать код, и как в ней обеспечить отказоустойчивость. Например, совладать с AWS/Azure/GCE или on-premise инсталяцией k8s, уметь поправить ошибку в инструментах развертывания, написанных на golang.
В некоторых областях ценность повышает наличие сертификатов. При приеме на работу значение имеет ваше портфолио, проще всего продемонстрировать ваши навыки и код через участие в open-source проектах или размещении своих pet-projects на github.
— Ты упомянул несколько популярных технологических решений. Получается, надо учиться тому что в тренде?
Не обязательно. На рынке можно идти за хайпом, а можно идти в обратную сторону. Если вам интересна редкая технология и вы не хотите бежать за модой, есть шанс повысить свою стоимость за счет уникальных знаний.
Современные технологические гиганты достаточно гибки и могут позволить себе успешно модернизировать свои системы. И, насколько можно судить, Яндекс и Гугл не имеют внушительного наследия решений, основанных на устаревших технологиях.
Но есть более консервативные отрасли: международные банки, промышленные и энергетические гиганты, оборонка. Им очень тяжело найти специалистов под свой стек и они готовы платить хорошие деньги. Хороший пример — использование «умирающего» Perl в booking.com и mail.ru. Или COBOL, разработанный в 60-х, и до сих пор используемый в некоторых финансовых учреждениях США.
— А что тогда подразумевается под универсальными навыками?
Умение общаться с другими людьми значительно увеличивает ценность разработчика для компании. На практике это означает, что человек может поднять проблему, обосновать свое мнение, предложить решение, правильно определить стейкхолдеров, умеет результативно взаимодействовать с разными людьми (гибкость), конструктивно решать конфликты, вести переговоры, обучать, менторить и коучить. И даже публично выступать или презентовать.
Сюда же можно отнести способность говорить на одном языке с дизайнером и понимание мотивов своего руководителя. Про знание английского думаю и так все понятно.
— Что значит брать больше ответственности?
Мы стремимся нанимать людей, которые смотрят чуть дальше своего рабочего инструмента (технологии) и концентрируются на ценности для конечного потребителя. Например, тех, кто предлагает варианты оптимизации процессов разработки, ищет варианты решения проблемы клиента, готов прилагать усилия для обсуждения и внедрения изменений.
К сожалению, часто можно видеть разработчиков, которые создают культ вокруг своих инструментов. Но надо понимать, что если код не попал в продакшен вовремя, то его качество или используемые инструменты не имеют значения. Этот код не принес прибыли компании.
— Это чем-то напоминает мне ценности Agile. Тут есть связь?
Да. Есть такой набор практик под названием DevOps, развивающий ценности Agile. Он помогает компании сместить фокус с формализации процессов на взаимодействие внутри для создания ценности. Но это невозможно без принятия ответственности за итоговый результат всеми членами команды.
Хороший разработчик понимает культуру DevOps и умеет её применять в своей команде и, в идеале, компании. Или даже насаждать. Например, одной из практик DevOps является CI/CD (наиболее частые релизы). И если вы действительно захотите делать частые релизы (хотя бы один в день), вы не сможете делать это в отсутствие автоматизации интеграции и тестирования, автоматизации и стабилизации процесса деплоймента, отделения релиза от деплоймента (feature toggling), работающего и понятно разработчикам мониторинга, сохранения обратной совместимости, механизма отката изменений и т.д. Вам станет очевидно, что ответственность хорошего разработчика не заканчивается при передаче задачи в отдел QA.
Ценность частых релизов вроде бы всем очевидна.
Анти-паттерн DevOps — это разделение производственного процесса на два и более функциональных колодца: разработка, тестирование, оперирование, безопасность. Как следствие — каждая функция решает только свои проблемы.
Общий смысл в том, что команда должна принять на себя ответственность за качество выпускаемого продукта, ценность фичей для клиента, сроки, и в гораздо меньшей степени формальное соответствие требованиям в описании задачи. У разработчика не должно быть предубеждения в сторону ограничения своей ответственности: «Я уже передал задачу в тестирование. Больше ничем не могу помочь».
Чем больше ответственности, тем больше влияния на результаты компании. В хорошей компании люди влияющие на её рост продвигаются по карьерной лестнице.
Командная ответственность требует хорошей коммуникации. Построить все вышеописанное без навыков конструктивного общения и работы в команде практически нереально.
— Везде так?
В большой компании с уже поставленными зрелыми процессами, принятие ответственности будет означать делать что-то сверх работы на своем проекте: организация митапов, tech talks, хакатонов; участие в presale или обучении интернов.
— Выводы?
Подводя итог, можно сказать, что самой оптимальной стратегией личного развития будет приобретение навыков коммуникации для более результативного расширения границ ответственности за то, что происходит с вашим продуктом и в вашей команде или компании.
— Как в твоем понимании выглядит концепция ценности разработчика?
Чтобы увеличивать свою стоимость, надо делать три вещи:
- Изучать технологии востребованные на рынке сегодня и завтра.
- Развивать универсальные навыки (soft skills).
- Брать на себя больше ответственности.
— Давай начнем с самого простого. Какие технологии осваивать?
Тренды сегодня меняются невероятно быстро. Поэтому я бы хотел озвучить какие-то общие принципы, а не описывать тренды или заниматься предсказаниями. Идеальной конфигурацией опыта и умений я считаю человека с Т-образной экспертизой (T-shape people). Суть термина в том, что являясь экспертом в конкретной технической области, он должен иметь представление о том, что происходит в соседних.
Например, backend разработчику кроме глубокого знания особенностей языка (например Python) и распространенных фреймворков, обязательно нужно знать и, желательно, уметь построить процесс тестирования, сборки и деплоймента (CI/CD pipeline, например в Jenkins). Он должен знать особенности среды, в которой будет работать код, и как в ней обеспечить отказоустойчивость. Например, совладать с AWS/Azure/GCE или on-premise инсталяцией k8s, уметь поправить ошибку в инструментах развертывания, написанных на golang.
В некоторых областях ценность повышает наличие сертификатов. При приеме на работу значение имеет ваше портфолио, проще всего продемонстрировать ваши навыки и код через участие в open-source проектах или размещении своих pet-projects на github.
— Ты упомянул несколько популярных технологических решений. Получается, надо учиться тому что в тренде?
Не обязательно. На рынке можно идти за хайпом, а можно идти в обратную сторону. Если вам интересна редкая технология и вы не хотите бежать за модой, есть шанс повысить свою стоимость за счет уникальных знаний.
Современные технологические гиганты достаточно гибки и могут позволить себе успешно модернизировать свои системы. И, насколько можно судить, Яндекс и Гугл не имеют внушительного наследия решений, основанных на устаревших технологиях.
Но есть более консервативные отрасли: международные банки, промышленные и энергетические гиганты, оборонка. Им очень тяжело найти специалистов под свой стек и они готовы платить хорошие деньги. Хороший пример — использование «умирающего» Perl в booking.com и mail.ru. Или COBOL, разработанный в 60-х, и до сих пор используемый в некоторых финансовых учреждениях США.
— А что тогда подразумевается под универсальными навыками?
Умение общаться с другими людьми значительно увеличивает ценность разработчика для компании. На практике это означает, что человек может поднять проблему, обосновать свое мнение, предложить решение, правильно определить стейкхолдеров, умеет результативно взаимодействовать с разными людьми (гибкость), конструктивно решать конфликты, вести переговоры, обучать, менторить и коучить. И даже публично выступать или презентовать.
Сюда же можно отнести способность говорить на одном языке с дизайнером и понимание мотивов своего руководителя. Про знание английского думаю и так все понятно.
— Что значит брать больше ответственности?
Мы стремимся нанимать людей, которые смотрят чуть дальше своего рабочего инструмента (технологии) и концентрируются на ценности для конечного потребителя. Например, тех, кто предлагает варианты оптимизации процессов разработки, ищет варианты решения проблемы клиента, готов прилагать усилия для обсуждения и внедрения изменений.
К сожалению, часто можно видеть разработчиков, которые создают культ вокруг своих инструментов. Но надо понимать, что если код не попал в продакшен вовремя, то его качество или используемые инструменты не имеют значения. Этот код не принес прибыли компании.
— Это чем-то напоминает мне ценности Agile. Тут есть связь?
Да. Есть такой набор практик под названием DevOps, развивающий ценности Agile. Он помогает компании сместить фокус с формализации процессов на взаимодействие внутри для создания ценности. Но это невозможно без принятия ответственности за итоговый результат всеми членами команды.
Хороший разработчик понимает культуру DevOps и умеет её применять в своей команде и, в идеале, компании. Или даже насаждать. Например, одной из практик DevOps является CI/CD (наиболее частые релизы). И если вы действительно захотите делать частые релизы (хотя бы один в день), вы не сможете делать это в отсутствие автоматизации интеграции и тестирования, автоматизации и стабилизации процесса деплоймента, отделения релиза от деплоймента (feature toggling), работающего и понятно разработчикам мониторинга, сохранения обратной совместимости, механизма отката изменений и т.д. Вам станет очевидно, что ответственность хорошего разработчика не заканчивается при передаче задачи в отдел QA.
Ценность частых релизов вроде бы всем очевидна.
Анти-паттерн DevOps — это разделение производственного процесса на два и более функциональных колодца: разработка, тестирование, оперирование, безопасность. Как следствие — каждая функция решает только свои проблемы.
Общий смысл в том, что команда должна принять на себя ответственность за качество выпускаемого продукта, ценность фичей для клиента, сроки, и в гораздо меньшей степени формальное соответствие требованиям в описании задачи. У разработчика не должно быть предубеждения в сторону ограничения своей ответственности: «Я уже передал задачу в тестирование. Больше ничем не могу помочь».
Чем больше ответственности, тем больше влияния на результаты компании. В хорошей компании люди влияющие на её рост продвигаются по карьерной лестнице.
Командная ответственность требует хорошей коммуникации. Построить все вышеописанное без навыков конструктивного общения и работы в команде практически нереально.
— Везде так?
В большой компании с уже поставленными зрелыми процессами, принятие ответственности будет означать делать что-то сверх работы на своем проекте: организация митапов, tech talks, хакатонов; участие в presale или обучении интернов.
— Выводы?
Подводя итог, можно сказать, что самой оптимальной стратегией личного развития будет приобретение навыков коммуникации для более результативного расширения границ ответственности за то, что происходит с вашим продуктом и в вашей команде или компании.
