Предисловие

Консалтинг умирал тихо, вроде как сначала умирала даже не профессия, а слабел бизнес консалтинговых компаний. Работая на стороне заказчика, я видел, что с каждым проектом уровень команд падает, и вот уже я сам за наши деньги делаю работу за них. Просто потому, что учить их дольше. Как так получилось? Хотя вопрос совсем в другом. Тот вопрос, который задаст себе таксист, когда проснётся однажды утром и увидит, что все остальные такси – беспилотные: а где, собственно, все?

Лично моя гипотеза состоит в том, что более-менее талантливые и амбициозные люди сейчас стремятся в тот самый digital, независимо от предыдущего опыта. Думаю, прекрасно, если это те же таксисты или "менеджеры среднего звена". У меня возникла идея серии статей на эту тему:

1. Что такое digital и зачем туда идти – это та часть, которую вы читаете; немного про рынок труда, уровень зарплат и карьерные перспективы.
2. Какие общие навыки вам потребуются, чтобы туда перейти: знание языков, личные качества, какие подходы из предыдущего опыта могут помочь.
3. Какие есть частные навыки, ссылка на github уже давно висит в меню слева, но там только список, а тут хотелось бы рассказать, на что обратить внимание.
4. Как найти работу или "пересечь пустыню безнадёжности".

Постараюсь параллельно рассказывать о собственном опыте, но истории у всех могут быть разные. Лично мой предыдущий опыт работы – консалтинг и управление проектами, но надеюсь, что цикл статей будет полезен и для людей не из этих областей. Также чуть больше будет про product management, но если вы решили стать дизайнером, программистом или кем-либо ещё, я постараюсь, чтобы мой материал вас в этом не ограничивал.

Наверное, нужно рассказать о том, откуда такое название: Паша – это мой друг и бывший коллега по консалтингу. Кстати, мы с ним вместе делаем подкаст "Мототрындёж", но это немного другая история. Паша сейчас продолжает работать в консалтинге и, похоже, ему это не очень нравится. Лично мне чуть проще писать для конкретного человека, тем более которого я очень ценю, поэтому "Паша".

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

Методология

Не бойтесь, здесь загрузки не будет, всё на самом деле очень просто и подходит для прочтения, даже если вы не знаете, что означает консалтинг. Скажем так, у человечества была потребность проводить изменения, и в прошлом (20-м) веке вершиной знаний для проведения изменений (в любой области) была "методология", которую применяли консалтинговые компании, брали за это большие деньги и держали её под большим секретом. Хотя этот секрет был у всех один и тот же и состоял он в последовательности шагов для проектирования и реализации изменений:

1. Анализ
2. Дизайн
3. Разработка
4. Внедрение

Когда я пишу "последовательность", то это означает ровно то, что эти этапы должны следовать строго последовательно друг за другом. Поверьте, я видел, когда это было не последовательно, и это было очень грустно. За схожесть на плане-графике с водопадом этот подход и называется waterfall. В чём проблема с ним? Если каждая стадия длится 1-3 месяца, то понятно, что пока дойдёшь до последней стадии, требования, снятые на этапе анализа, могут поменяться. Означает ли это, что этот подход порочен, устарел и не должен больше применяться? Лично моё мнение – конечно нет, и в сегменте B2B он ещё долго будет успешно жить, по финансовым причинам. Дело в том, что в бизнес-среде изменению и проекту, который и состоит из перечисленных стадий, соответствует договор, а договором с фиксированным объёмом легче управлять, чем договором с переменным объёмом. В юридическом смысле (а мы не можем абстрагироваться от юридической реальности) изменения в договоре возможны, но это требует подписания дополнительных соглашений к договору, а это требует ресурсов.

В итоге мы получаем, что для того, чтобы проект хорошо прошёл, требования желательно качественно проработать до начала проекта, иногда для этого делают даже отдельный проект. В моём опыте для внедрения облачной (то есть уже разработанной) системы для проекта длительностью 1 год потребовалось 2 года подготовки. Это реальные сроки, друзья мои, и тут есть от чего впасть в депрессию. Что и стало происходить с людьми, и они задались несколькими вопросами. Первый был, само собой: а нельзя ли побыстрее? А второй был: а зачем нам реализовывать требования, которые уже никому не нужны? Начну с второго: иногда это имеет смысл, потому что в бизнесе не всегда требования ставили полные идиоты, и возможно, в них есть смысл, просто мы не можем его понять. Ну и если найти нового владельца требований, согласовать с ним эти требования, то не факт, что получится лучше. И всё же по статистике 60-80% требований не используются приблизительно никем. Зато оставшиеся 20% могут оправдать даже такую уродливую конструкцию.

Насчёт "побыстрее", как сказал бы (не очень) добрый фей: конечно, дружок, мы можем побыстрее, но тебе придётся за это что-то отдать. Если посмотреть на agile подходы, к которым относится канбан и scrum, как минимум, разработки больше. Если требования постоянно меняются, нужно действовать итерационно, на каждом этапе делая готовый продукт. А чтобы каждый раз делать готовый продукт, нужно его каждый раз тестировать. А чтобы каждый раз тестировать, нужно написать массу автоматизированных тестов. Это не говоря о "мёртвых" ветках функционала, которые в итоге "не пригодились". То ли дело waterfall: один раз разработал, протестировал, привет, продуктив. Ну мы же его похоронили, так что не будем откапывать.

Agile, как мне кажется, подходит для B2C и тех компаний, которым waterfall стал тесен. Если же применять agile для тех, у кого не было владельцев процессов, требований или желания их формулировать, то, как мне кажется, получится только фиаско, что подтверждает опыт моих коллег. Это всего лишь вариация известной максимы "любая методология имеет ограниченные условия применения", тут я как про waterfall, так и про agile. Ну и в целом (кто-то же должен это написать): давайте не будем делать фетиш из подходов. Люди, которые перешли в agile, не зная waterfall, обречены его заново изобрести. Например, это означает, что не стоит обесценивать свой опыт, если вы раньше работали только с waterfall'ом.

Но кроме agile изменилось ещё кое-что: фокус переместился с проекта на продукт.

Product Management

Раньше было так: что нам нужно, чтобы реализовать изменение? Сделать проект! Получилось ли то, что хотели? Нет в 60% случаев. Почему? Потому что была разница между задачами проекта и тем, что в действительности необходимо сделать для реализации изменения. Кто за этим должен следить? Лично я не видел, чтобы руководитель проекта это делал, поэтому всегда требовался функциональный лидер, глубоко погруженный в предметную область: либо эксперт от заказчика, либо консультант. Нет такого человека – фиаско, но в проектной модели все молятся на руководителя проекта, и именно он является главным.

Область знаний "управление продуктами" была и раньше, но она была нацелена на разработку продуктов реального мира (в отличие от нашего digital, то есть цифрового мира), поэтому для разработки ИТ-сервисов была тяжёлой и неповоротливой. Критическую массу того, как концентрироваться на продукте и разрабатывать цифровые продукты быстро и эффективно, залил Марти Каган в книжке "Inspired". По крайней мере, это первое, что мне посоветовали почитать на тему product management, и я не пожалел. Она рассказывает о том, как должна быть организована команда по разработке цифрового продукта, какими инструментами пользоваться для описания и развития продукта, какие процессы и какая культура необходимы для этого. Здесь решаются обе проблемы проекта:

• Фокус всегда на продукте, конечной цели для клиента. Мы не "отпочковываем" некоторый "проект", чтобы потом, по закону Мерфи, он начал отличаться от того, что клиент хочет на самом деле.
• Лидером является не административный "руководитель проекта", а человек, который как раз управляет всеми аспектами продукта, от описания до достижения его состояний (промежуточных или конечного) – product manager. Как синоним дальше я буду использовать менеджер продукта, хотя есть другие переводы.

Здесь сразу хотел привести пару ссылок на статьи для более углублённого изучения:

• Почему продуктовый подход заменяет проектный: Moving from projects to products. Причём мне известны случаи, когда вместо проектных офисов в компаниях делают набор продуктовых команд.
• Как перейти в product management: Hired: How To Get a Product Management Job, здесь хорошо описывается переход в product management из таких профессий, как инженер (разработчик), дизайнер, предприниматель, маркетолог, консультант.

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

Но и это ещё не всё о digital, я бы сделал ещё акцент на облачных сервисах.

Облака

Можно ли применять agile, product management и при этом разрабатывать on-premise решения, то есть решения, которые существуют в уникальном экземпляре для конкретного заказчика? Безусловно. Будет ли это "тот самый digital"? Не уверен. Одним из тезисов видения того самого "digital-будущего" (извините, лень искать источник, грешен) будет то, что on-premise решения вымрут, кроме решений для автоматизации ключевой функции, которая является уникальным конкурентным преимуществом организации. Например, если вы не закупочная организация (не закупаете для других), то это, скорее всего, не функция закупок. Ключевой функцией может быть производство, исследование и разработки, планирование. Тогда можно обобщить опыт автоматизации "неключевых" функций и сделать для них единые решения. Наверное, это будет немного скучно, ведь у всех будет одинаково, но это будет удобно и недорого.

Вы всё ещё за on-premise? Лично видел человека, который поддерживал решение на FoxPro на одном заводе молочной продукции. Сидел он там 20 лет и платили ему космическую зарплату. Это legacy-решения, или старый хлам, в который рано или поздно превращается любое on-premise решение. Человеческая мысль развивается дальше, а оно там себе тихо жужжит, написанное на диалекте языка, который уже никто не знает. И генеральный директор молится, чтобы оно не упало или (что хуже), чтобы его не пришлось с чем-то интегрировать. Можно не интегрировать, но ценность систем, которые ни с чем не обмениваются данными, резко падает.

Зачем это всё

Вы вряд ли пойдёте в digital, чтобы танцевать в лохмотьях вокруг костра и выкрикивать: agile, product management, облака! Хотя... Да нет, не пойдёте. Мы живём в материальном мире, нам всем нужно оплачивать счета и покупать более дорогие предметы интерьера, либо реализовывать какие-то другие фантазии (включая благотворительность, либо выделять время на волонтёрство), что также оплачивается деньгами. И тут мы приходим к вопросам:

• А что там вообще есть?
• Каков уровень зарплат?
• Каков потенциал роста?

На последний вопрос ответить легче всего, в применении к product management гуглим "product management career path" и находим, например. Подставьте другую профессию и обрящете.

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

Насчёт уровня зарплат, необходимо уточнить: где? Плюс digital профессий в том, что они стандартизированы между странами, поэтому вы можете начать в одной стране (например, в России), а затем продолжить в другой, что многие успешно и делают. Вы можете идти по пути роста зарплаты, что, скорее всего, приведёт вас в США, или же просто жить там, где вам нравится, работая в той же стране или удалённо.

Насчёт конкретных величин зарплат надо просто зайти на сайты и посмотреть. Для digital профессий есть ряд специализированных сайтов, поэтому чтобы не путаться, имеет смысл начать с них. Например, product manager на hh.ru приведёт вас к менеджеру категории в обычной FMCG-компании. Возможно, затем вы вернётесь на hh.ru, поскольку там может быть больше вакансий (уже на этапе поиска работы), но пока мы говорим лишь о том, чтобы получить представление, поэтому для вакансий в России можно зайти на сайты:

• career.habr.com
• GeekJob

По product management я смотрел вакансии за рубежом на сайтах:

• LinkedIn, не забудьте включить VPN
• AngelList, в основном, стартапы в США и Европе
• Product School, аналогично

Также есть сайты фриланса, лично я работал с UpWork, и мне очень понравилось.

В завершении этой части мне осталось сообщить вам две новости, плохую и хорошую. Начну с хорошей: рынок digital специалистов сейчас достаточно разогрет, а резко много хороших профессионалов не появится. Поэтому зарплаты неплохие, и они растут. Но новость не в этом, а в том, что FaceBook после переименования в Meta в связи с желанием построить мета-вселенную, нанимает по всему миру 50.000 специалистов (пятьдесят тысяч человек, Карл). Они предлагаю ставки, в 3 (три) раза выше рыночных. Не думаю, что меня вдохновляет работа в Facebook и создание мета-вселенной, но тут суть в воздействии на рынок, его разогревают ещё больше. И это не отменяет планов других компаний по резкому расширению. Например, LinkedIn завален вакансиями от TopTal, и это с метавселенными никак не связано.

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

• Сама культура коммуникаций немного другая, то есть люди общаются по-другому; есть масса того, что принято и что не принято, то есть культурные различия будут сильно осложнять вам задачу.
• Профессия всё же немного различается: если в России тот же product manager может рассматриваться как "подающий патроны" разработчику: сидит себе, бэклог свой ведёт и пишет user stories; то за рубежом потребуется продемонстрировать такие вещи, как видение и стратегический анализ; да и конкуренция на рынке продукта, как правило, будет плотнее.

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

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