IAMPM
65000
+38 (091) 481 01 38+7 (495) 128 58 05info@iampm.club

Что делать, если не берут в IT без технических знаний?

20 января 2021

  • Автор: Уля Днипрова

  • Сложность: норм

  • Время: 8 мин

Чтобы качественно руководить IT-проектом, одной управленческой экспертизы будет недостаточно. Понадобится еще и понимание процесса разработки ПО. 

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

Значит ли это, что в IT не попасть без технического бэкграунда? Совсем нет, — считают наши эксперты, Денис Шаматажи и Наталья Белоусова. Если релевантного опыта маловато, его можно приобрести достаточно быстро. 

Денис в IT уже 8 лет, из них 5 — лет в роли менеджера удаленных команд. Наталья руководит проектами в мобильной разработке. За время работы оба эксперта провели не одно собеседование и составили собственный список, чего ждут в IT-компании от кандидатов на управленческую должность. 

Собрали советы Дениса и Натальи в одну статью, чтобы можно было сразу проанализировать, каких знаний не хватает и составить «роадмап» по развитию нужных скилов. 

Почему в приоритете люди с техническими навыками 

недостаток технических навыков

Кажется, что опытный менеджер из «нетехнической» сферы будет так же хорош и в IT. Если управлял постройкой дома, значит справишься и с разработкой мобильного приложения. Так ли это на самом деле? 

Наталья Белоусова: 

Однажды я искала себе помощника РМ-а. Один кандидат — менеджер из туристической сферы, очень подходил по софт-скилам. 

Во время собеседования, я поймала себя на мысли, что мы говорим абсолютно на разных языках, и осознала тот объем знаний, который нужно передать, чтобы кандидат начал нормально работать РМ-ом в IT. 

В итоге, я поняла, что подготовка к работе «не-айтишного» специалиста будет слишком трудозатратной, поэтому сосредоточилась на кандидатах у которых кроме софт-скилов, был еще и опыт в IT. 

Какие трудности возникают у РМ-а при переходе из «неайтишной» области в «айтишную»: 

  • Непонимание процесса в целом. Приходится начинать с основ: что такое вообще процесс разработки, как он проходит, какие сложности бывают на каждом этапе. РМ-у нужно руководить проектом, но управлять тем, чего не понимаешь, нелегко
  • Общение с клиентом. Менеджер без знания IT-терминологии на встрече с заказчиком может показаться клиенту некомпетентным. Когда технические специалисты со стороны заказчика разговаривают с менеджером и понимают, что он не владеет терминологией, не знает важных вещей, — вся компания выглядит непрофессионально.
  • Авторитет у команды. Эффективность РМ-а всегда напрямую зависит от уважения команды. А если менеджер слабо разбирается в процессе, трудно будет преодолеть снисходительное отношение девелоперов.   

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

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

Что изучать, если хотите подтянуть знания самостоятельно

недостаток технических навыков

Не требуется, чтобы РМ подробно разбирался в разработке, важно чтобы у специалиста было общее представление, как производят программные продукты.

Жизненный цикл ПО 

Программные продукты — это не о том, что программист сел, что-то написал — и на этом все. Существуют определенные этапы разработки, а Рroject Мanager в IT знает эти этапы, понимает их особенности и то, какие люди нужны на каждой стадии: 

  • Формирование требований к ПО. Ответственность РМ-а — обеспечить качественное планирование функциональности и анализ требований. 
  • Проектирование решения. На этом этапе выстраивается понятный интерфейс и визуальное представление продукта. Строится также архитектура решения. 
  • Реализация и тестирование. Нужно понимать, что разработка и дальнейшее тестирование с исправлением ошибок — это нормальный процесс. Часто приходится объяснять клиентам, далеким от IT, как делают программные продукты и почему баги, например, это норма. 
  • Ввод в действие (внедрение) и что происходит после него. 
  • Эксплуатация и сопровождение (техподдержка). Почему мы не можем просто бросить продукт после внедрения, что такое гарантийное обслуживание, техническая поддержка и т.д. 

Модели и методологии

Чтобы понять эту тему в целом, достаточно прочитать несколько статей. Цель — сформировать совокупность понятий, которые должны быть у человека, заходящего в IT-компанию.

Необходимо знать самые распространенные модели: каскадная (Waterfall), итерационная, инкрементная модель. Где во всем этом место для Agile и что такое Kanban. Важно понять преимущества и недостатки каждого подхода, чтобы правильно выбрать модель для управления продуктом. 

Терминология 

Нужно понимать базовые вещи, чтобы суметь ответить на общие технические вопросы: 

  • Что такое архитектура?
  • Что такое бэкенд и фронтенд?
  • Как взаимодействуют платформы?
  • Что такое базы данных, таблицы и связи, первичный ключ?
  • Что такое DNS, load balancer, репликация?
  • Клиент-сервер: толстый и тонкий клиент, что это?
  • Чем отличается клиент-сервер на web и mobile?
  • Что такое REST? 
  • Какая логика должна быть на фронтенде, а какая на бэкенде. 
  • Безопасность, как ее обеспечить. 

Денис Шаматажи

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

Поэтому, если времени мало, лучше найти знакомого из похожей компании, например, для для game-проекта это может быть game-разработчик. Попросите знакомого, чтобы он позадавал вам общие технические вопросы. Обычно это помогает выявить проблемные области, где знаний нет или они забылись, и тогда становится понятно, что подучить. 

Техническая документация

Менеджер не прописывает совсем технические вещи, такие как code style или описание архитектуры. Но точно придется изучить, что такое техническое задание и как его поставить.

Чтобы ставить задачи команде, РМ-у нужно самому разобраться в понятиях:

  • Описание API: понимать, где какие API используются, в какой момент нужно вносить изменения, а когда нет. Это нужно, чтобы обновления различных частей системы не ломали работающую функциональность. Очень часто на аутсорсе бывает, что mobile делает одна компания, а бэкенд — другая, и в такой ситуации РМ-у надо чуть внимательнее следить за тем, что происходит «под капотом».
  • Описание архитектуры. В аутсорсе достаточно часто бывает, что клиент просит описать для внешнего заказчика или для интеграции с внешней системой работу какого-то модуля. И тут РМ должен понимать, что подразумевал разработчик в описании, чтобы на созвоне с заказчиком или с кем-то из внешних подрядчиков, суметь ответить на всплывающие вопросы
  • Test case, bug report, use case, user story — что это и для чего нужно.

Если хотите получить чек-лист с общими техническими вопросами для подготовки к собеседованию в IT-компанию, заполните короткую форму

Инструменты проекта 

В этом блоке знаний, главная цель — освоить понятийный аппарат и понимать вопросы которые могут задать на собеседовании: 

  • Какие бывают task trackers и какой лучше?
  • Где зачем применяют project planning? Как построить диаграмму Ганта? 
  • Где хранить и менеджить требования?

Наталья Белоусова: 

Практический совет: Выберите пробный вариант одного из task трекеров, например, той же Jira и попробуйте посмотреть, позаводить задачки. Когда на собеседовании вас спросят об опыте работы с task трекерами, сможете отвечать:

— Да, с джирой немножко работал, — и это будет дополнительный плюс в вашу пользу.

Task трекеры похожи, и если попрактиковаться с одним, будете в целом понимать, как работают остальные. 

Тестирование

Нужно сформировать представление о типах тестирования (функциональное, регрессионное, нагрузочное), в какой последовательности проводят, когда они нужны: 

  • Внутреннее и внешнее тестирование.
  • Как отличить баг от change request.
  • Артефакты тестировщиков: test cases, ПМИ (программа и методика испытаний).
  • Серьезность (severity) и приоритет (priority) бага/дефекта.
  • В какой момент нужно остановиться в тестировании?
  • Можно ли сдать проект при наличии багов, какого порядка могут быть эти баги и в каком количестве? 

Когда определились с тем, ЧТО изучать, поговорим, ГДЕ брать нужную информацию. Поговорим о теоретических знаниях и практических умениях. 

Где искать ответы

недостаток технических навыков 3

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

Денис Шаматажи

Сейчас я работаю «мобильным» РМ-ом, поэтому так или иначе проектировал мобильный дизайн, постоянно читаю про мобильные платформы и могу сам написать простенькое приложение. 

Теоретические знания

Наталья Белоусова:

Если бы ко мне пришел друг и спросил: «Наташа, хочу в IT, что делать?»— я бы посоветовала фундаментальный курс на Coursera или базовый TechMind, а можно вообще пойти на второе высшее. Все зависит от длительности обучения и целей человека, насколько глубоко он хочет погрузиться в техническую часть.

Денис Шаматажи: 

У фундаментальных технических курсов есть один минус: там часто изучают супер-технические подробности, которые РМ-у не нужны. Вместо того чтобы объяснить специфику проекта, вам расскажут как поднять сервис, настроить хостинг и т.д. А менеджеру, чтобы управлять, надо просто понимать в целом, как работает система. 

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

Хороший источник знания — взаимодействие со специалистом. Общение может быть совсем неформальным: просто какой-то знакомый, которого можно расспрашивать.

Другой вариант — найти более опытного РМ-а либо ментора и попросить подкинуть актуального контента или помочь разобраться в техническом вопросе. 

Теорию можно изучать самостоятельно: читать новости, статьи, следить за происходящим, подписаться на IT-сообщества. Это очень важно. 

Допустим, вы работаете с пользователями в сфере мобильных проектов, и здесь любое новшество в операционной системе сразу становится очень актуальным. Можно каждое утро заходить на определенные ресурсы и отслеживать информацию: например, вышел новый IOS или Android alfa, там вот такая функциональность. 

Отслеживая актуальные новости, вы будете понимать, что улучшается, а что становится хуже. Это вроде не какие-то специальные знания, нужные для прямых обязанностей РМ-а, но они дают хорошее контекстуальное мышление.

Где брать информацию: 

  • Habr и vc.ru — русскоязычные ресурсы
  • The Verge, Wired— технические новости на английском 
  • TechCrunch, MacRumors — для тех, кого интересует тема стартапов.
  • Producthunt, KickStarter, IndieGoGo — примеры новых продуктов. 

Наталья Белоусова:

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

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

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

Денис Шаматажи

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

Книги быстро устаревают и часто излишни: несколько вещей, которые можно объяснить на 10 страницах, объясняются на 50, и вы просто теряете время. Поэтому технические знания я сейчас беру не из книг, а из статей, научных работ, блогов.

Практические умения 

Если говорить о получении практических знаний, то сколько бы книг и сайтов вы не изучили, пока не сделаете что-то своими руками, понять IT-сферу не получится. Попробуйте создать что-то вручную, чтобы увидеть как это работает: например, сайт на wordpress или минимальное приложение, а-ля «Hello, Word». Когда попробуете воплотить теорию в реальность, знания превратятся в практический навык. 

Это будет похоже на какие-то лабораторные работы при изучении программирования. Такие «лабораторки» можно делать самостоятельно или пойти на курс, где вас проведут за руку, скажут что делать, проверят, разберут ошибки. 

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

Денис Шаматажи: 

Есть действительно много профессий, с которых можно заходить в IT, даже без опыта. Некоторые мои друзья стали продактами из customer support, потому что эта позиция прокачивает два важных скила: 

  • Понимание продукта, нужд и болей клиентов. 
  • Понимание технических деталей, нужных для формулировки ответа.

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

Наталья: Белоусова: 

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

А если ищете именно менеджерскую роль — идите в джуниор РМ-ы или на стажировку. Это будет невыгодно по финансам, но вы наберетесь опыта. Подумайте о позиции с точки зрения не заработка сейчас, а будущего развития и опыта. 

Составить план развития технических скилов — только начало пути. Поэтому, когда роадмап готов — начинайте действовать. 

Если в вашем плане есть пункт: получить технические навыки с точки зрения менеджмента — приходите на TechMind

Программа специально составлена так, чтобы после каждой лекции становилось понятно, как устроена эта часть процесса. За полтора месяца вы получите базовые технические знания и и научитесь общаться с разработчиками на их языке.

 

Аватар

Уля Днипрова

Уля - копирайтер IAMPM. Всегда готова помочь юным авторам советом и просто обожает разговаривать о маркетинге, текстах и смыслах. Лучше всех относится к контентщикам, которые внимательно читали «Пиши-сокращай» и рассылку Максима Ильяхова.