Текст книги "IT-рекрутмент. Как найти лучших специалистов, когда все вокруг горит"

Раздел 2
Сфера IT. Основные языки программирования, понятия и термины

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

В этом разделе мы рассмотрим основы – базис, на который вы сможете опереться в своей работе. Остальные же знания, я уверен, вы приобретете в процессе поиска кандидатов через общение с работодателем, самими кандидатами и с помощью более специфических справочных пособий (много актуального и полезного, например, можно найти на habr.com), которые будут вам необходимы для закрытия той или иной вакансии.

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

Глава 5
Компании на рынке IT

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

IT-компании условно можно разделить по следующим типам деятельности:

● продуктовая разработка;

● заказная разработка.

Также существуют компании-вендоры, IT-консалтинг и IT-отделы в организациях, напрямую не связанных с разработкой ПО.

Мы рассмотрим их деятельность с акцентом на то, как их воспринимают кандидаты: какие плюсы и минусы они видят в трудоустройстве в организацию того или иного типа и вида.

Продуктовая/собственная разработка. Компании, занимающиеся этим видом деятельности, разрабатывают и продают свой продукт. Среди классических примеров – всем известные Microsoft, «Лаборатория Касперского», Google, «Яндекс», Cian, Avito и др. Такие организации или развивают один продукт, или реализуют сразу несколько проектов – главное, что все задачи по разработке, маркетингу, исследованию рынков и ценообразованию фирма решает сама.

Можно выделить два подтипа продуктовых компаний:

● создание главного продукта;

● создание продукта, обеспечивающего жизнедеятельность офлайн-бизнеса.

В первом случае компания производит собственный IT-продукт – некий софт, который продается и является основным источником прибыли: операционные системы, онлайн-бухгалтерия, антивирусы и т. д.

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

Какие преимущества видят кандидаты в продуктовых компаниях? В первую очередь стабильность и перспективы роста (пусть не быстрого, но планомерного). Однажды устроившись в «Яндекс», можно провести там всю жизнь, постепенно развиваясь в своей специализации или осваивая смежные профессии.

В крупных продуктовых компаниях есть время и средства, чтобы отлаживать бизнес-процессы, повышать квалификацию персонала, обучать и мотивировать сотрудников. Отсюда – комфорт и устойчивое ощущение, что «в Багдаде все спокойно». Но давайте не будем идеализировать большие продуктовые команды: у них достаточно времени, чтобы выстроить процессы, но вы же не думаете, что все компании реально выстраивают процессы? Нет, разумеется. И среди больших продуктовых компаний есть те, которые так и не внедрили изменения, уже считающиеся условной нормой на рынке. Так что тут все всегда зависит от конкретной компании.

С психологической точки зрения для разработчиков такие компании привлекательны тем, что они видят результат своих трудов, а значит, есть чувство моральной удовлетворенности. Часто программисты уходят из заказной разработки в продуктовые фирмы именно по этой причине: «Я хочу гордиться тем, что делаю».

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

Но, бесспорно, есть и весомые минусы. Самый главный из них – скука. Порой работа внутри продуктовой компании не отличается разнообразием: программист может несколько лет заниматься одним и тем же продуктом или модулем. Или работать в поддержке старых продуктов: бесконечно «фиксить баги» – исправлять ошибки, разрабатывать дополнительные внутренние инструменты. Такая монотонная деятельность без дополнительных интересных задач может деморализовывать. Ну и в конце концов, если компания крупная, то она может обрасти бюрократией, от которой будут мухи дохнуть.

Заказная разработка – это аутсорсинговые или сервисные организации, которые, как и следует из их названия, разрабатывают программное обеспечение под заказ для других фирм. Компании передают определенные бизнес-процессы или производственные функции на аутсорс, а фирмы-аутсорсеры «продают» им собственных специалистов в качестве рабочей силы. Примеры таких компаний: ICL, SimbirSoft, «ЛАНИТ», «Ай-Теко» и др.

В каких случаях для бизнеса актуален именно такой вид сотрудничества? Есть несколько характерных ситуаций, при которых, как правило, обращаются к аутсорсерам:

● Проверка бизнес-гипотезы. Когда разработчики ПО не уверены, стоит ли вкладываться в новый проект, его минимальную версию (так называемую MVP[14]14
  MVP (minimum viable product) – минимально жизнеспособный продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями.


[Закрыть]) заказывают сторонней организации. Это отлично экономит и бюджет, и время. Если по результатам работ идея оказывается актуальной, компания берется за ее реализацию самостоятельно: нанимает продуктовую команду, выстраивает бизнес-процессы, планирует маркетинговую составляющую.

● Разработка уникального решения. Бывают ситуации, когда коробочные (то есть уже существующие) программные продукты не покрывают все потребности компании. Например, порой компании заказывают разработку ERP-системы, потому что существующий коробочный функционал той же 1С их не устраивает, SAP – это очень дорого, а компания считает, что их процессы уникальны. Тогда она решает обратиться к аутсорсеру.

● Разовые или регулярные доработки и усовершенствования существующего продукта, например «затачивание» 1С под нужды того или иного производства. В таком случае зачастую выгоднее обратиться в специализированную фирму, чем нанимать своих разработчиков, так как собственный штат обойдется существенно дороже.

Какие плюсы существуют в аутсорсинговых компаниях? Здесь потенциального сотрудника ждет большое разнообразие проектов, что позволяет быстро повысить свою квалификацию и стать многопрофильным специалистом. У разработчиков нет необходимости думать о конечном пользователе: они ориентируются на ТЗ заказчика, а не на переменчивые вкусы потенциальных покупателей софта.

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

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

Кроме того, в аутсорсе очень сложно общаться с заказчиком. Далеко не всегда от лица компании с разработчиками коммуницирует технически грамотный специалист, и тогда общение происходит в прямом смысле слова на разных языках – с соответствующими печальными результатами работ. Или же заказчик бывает таким упертым и негибким (или чересчур гибким), что подрядчикам приходится пилить уже неактуальный, но согласованный в ТЗ функционал или регулярно менять курс, не понимая, с чем это связано.

Плюс к этому есть аутсорсинговые компании, которые работают по ТЗ заказчика, поддерживая legacy-код – то есть систему, которая была написана кем-то раньше (возможно, на устаревшем языке программирования). В обиходе программистов такой вид деятельности называется «работой на галерах». Представьте, вы сталкиваетесь с некоей программной сущностью, которую написал кто-то – возможно, не очень талантливый и одаренный – много лет назад. Это своеобразный программный лабиринт, в котором даже сориентироваться не всегда возможно, не говоря уже о том, чтобы поддерживать его в порядке. Поэтому есть компании, которые полностью отказываются от такой деятельности и берутся за разработку только с нуля. В таком случае уровень «страдания на галерах» можно значительно снизить.

Кстати, по-хорошему разработчики должны покрывать свой код документацией, которая объясняет, что делает тот или иной кусок кода. Тогда новому сотруднику будет понятно, что для чего нужно. Но в случае с legacy такой документации зачастую нет. Вместо нее – костыли, то есть временные решения каких-то проблем: изначально хотели сделать всё хорошо и грамотно, но разработка требовала слишком много времени – и от глобальной переделки отказались. Что-то вроде заклеенного изолентой шлема живущего на Марсе Мэтта Деймона в фильме «Марсианин».

Вендор – это компания, разрабатывающая технологии под собственным брендом. На базе их разработок другие организации могут создавать свои продукты. К такому виду компаний относятся Intel, IBM, Oracle, а наиболее известный российский вендор – фирма «1С».

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

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

Работа консалтинговой компании состоит из следующих этапов:

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

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

● И наконец, новая система внедряется: специалисты проверяют ее работоспособность и обучают сотрудников компании пользоваться новым софтом.

Примеры организаций, которые успешно занимаются консалтингом на российском рынке: «ЛАНИТ», «Ай-Теко», «Компьюлинк», «Террасофт», «ЭкоСофт».

В IT-консалтинге есть несколько неоспоримых преимуществ. В частности, финансовая мотивация в этом секторе порой выше среднего. А удовлетворенность работой высокая: вы чувствуете свою сопричастность к развитию крупных, известных компаний – это настоящая помощь, которая не просто оплачивается. За нее искренне благодарят! При хорошем развитии событий, конечно же.

Что же может пойти не так? Консалтинг – это работа с людьми: представители заказчика могут быть некомпетентны в технологических вопросах. Из-за этого возникают разногласия, требования в процессе работы могут многократно меняться, сроки внедрения – откладываться. Это важный стрессообразующий фактор, который не всегда окупается даже самыми высокими зарплатами.

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

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

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

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

Чаще всего IT-специалисты хотят работать в продуктовых компаниях. Даже если там есть бюрократия и какие-то куски legacy-кода, все же причастности к продукту и возможностей для развития там зачастую больше. Но, безусловно, важно помнить, что все зависит от каждого конкретного человека. Некоторых, например, драйвит и хороший аутсорсер. А потому не делаем выводы за кандидата и задаем вопросы!

Глава 6
Обзор IT-профессий

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

Важно помнить, что теория и практика, к сожалению, совпадают далеко не всегда. И любые теоретические правила на практике могут не выдерживать никакой критики. Описание профессий, которые вы найдете ниже, – теоретическое. На практике аналитик в компании может выполнять роль продакт-менеджера, а тот – заниматься разработкой. Бывает всякое! Однако надо же нам от чего-то отталкиваться. Я предлагаю эту систематизацию как базисную, и по мере развития в профессии вы будете ее для себя уточнять.

Аналитики. В сфере IT мы говорим «аналитик», а подразумеваем – «системный аналитик». Хотя существуют еще бизнес-аналитики и аналитики Big Data (о них позже).

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

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

На основе того, что выяснилось, аналитик составляет техническое задание для разработчиков. Это масштабная, точная, очень дотошная работа – создать такой документ, в котором подробно описано, как система будет работать. Любой упущенный, не оговоренный в документации фактор может легко увести проект с нужного курса. Как говорил доктор Хаус про девочку-пациентку, «если бы в ее ДНК отклонение было на один процент, она была бы дельфином».

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

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

В своей работе аналитики чаще всего используют нотации – специальный софт для создания различных блок-схем и диаграмм. После того как вы отрисовали с помощью нотаций какой-нибудь пользовательский сценарий (как использовать ваше приложение), можете подгрузить его, например, к Jira (система отслеживания ошибок) – и уже там отмечать существующие баги. Это гораздо удобнее, чем объяснять на пальцах.

Среди популярных нотаций можно выделить UML, BPMN, Visio и т. п.

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

Технический писатель – специалист, который занимается составлением документов в рамках разработки продукта. Он описывает функционал продукта по установленным нормам, руководство по эксплуатации для пользователей и многое другое. В некоторых случаях он может заниматься оформлением этой документации: добавлять иллюстрации, видео, анимацию.

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

Техническому писателю необходимо уметь объяснять сложные вещи простым языком. Для этого, конечно же, нужен навык понимания этих самых сложных вещей. Его цель – докопаться до сути проекта, понять ее и уже только после этого описать.

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

Project manager (проджект-менеджер – менеджер проекта) и Product manager (продакт-менеджер – менеджер по продукту). Мы подробно разберем эти позиции в отдельной главе, пока же важно отметить, что Project manager в IT обычно занимается «административной» работой. Его задача – успешная реализация проекта в установленные сроки в рамках запланированного бюджета.

Product manager отвечает за продукт в целом. В его функции входят анализ рынка, общение с потенциальными пользователями, ценообразование, позиционирование продукта и много других деталей. Некоторые функции, как вы заметили, пересекаются с работой аналитика, но менеджер по продукту – это все-таки более управленческая позиция.

UI– (user interface) и UX– (user experience) дизайнеры – несмотря на то, что в реальности эти функции выполняет один человек, разница между ними все-таки есть. Хотя в последние годы ситуация, на мой взгляд, улучшается.

Итак, UI-дизайнер занимается только непосредственно дизайном, а UX-специалист больше погружен в аналитическую сторону создания продукта.

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

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

Разработчик (junior, middle, senior, teamlead). Если вы откроете hh.ru, то увидите там и программистов, и разработчиков, и developers, и software engineers. Все это – разные названия одной профессии. Детально про разработчиков мы поговорим, когда будем разбирать языки программирования.

Пока же важно понять, что разработчик – это человек, который непосредственно пишет код и реализует поставленное ТЗ. Обычно выделяют четыре уровня (грейда) сотрудников:

● junior (начинающий специалист);

● middle (специалист среднего уровня, но так пишут очень редко: звучит это дико; скорее уж middle, или мидл);

● senior (старший/ведущий специалист);

● тимлид (руководитель команды).

Тимлид – руководитель группы сотрудников (это могут быть как разработчики, так и тестировщики или, например, аналитики). В процессе руководства группой разработчиков тимлид также может участвовать в формировании команды, принимать решения по архитектуре ПО или выполнять роль аналитика. По факту тимлид всегда участвует в найме, ведь именно к себе в команду он ищет людей, и ему важно понять, с кем предстоит работать.

Тестировщик. Главная задача этого специалиста – найти в ПО баги (ошибки). Он анализирует работу продукта, ищет слабые места, документирует их и передает разработчикам, чтобы те всё исправили.

Сисадмин. Когда рекрутер ищет системных администраторов, он должен понимать, что они могут выполнять очень много различных задач. Самое простое – «спасение» пользователей от любых проблем, связанных с состоянием компьютеров. Сисадмин участвует в закупках новой техники, следит за ее состоянием и при необходимости чинит, устанавливает операционную систему и новые программы, создает учетные записи. Это самые очевидные для обычного пользователя задачи.

В IT-компании всё сложнее. Здесь системный администратор может, например, заниматься администрированием физических и виртуальных серверов или управлять базами данных.

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

IT-директор & CTO. CTO, или Chief Technology Officer, или технический директор в IT-компании – это человек, отвечающий за разработку и развитие всего ПО, которое выпускается. У него в подчинении находятся все технические отделы.

Тогда как IT-директор (CIO), скажем, в небольшой строительной компании – это специалист, отвечающий за IT-инфраструктуру, и в подчинении у него будут, например, два системных администратора.

Единой терминологии, определяющей, кто такой IT-директор, нет, все зависит от контекста. Единственное, что можно уверенно сказать об этой должности, – она управленческая. Не подумайте, что рынок не определился. Просто СТО небольшого продукта в 30 человек и СТО нескольких бизнес-юнитов в Mail.ru – это разные специалисты. И тот и другой обладают технической экспертизой, но первый порой может и к процессу кодинга подключиться, и продуктовые задачки на себя взять, а второй, вероятно, будет больше менеджером.

Специалист по информационной безопасности – человек, который, как и следует из названия должности, отвечает за обеспечение конфиденциальности данных. Он анализирует информационные риски компании и внедряет мероприятия по их предотвращению. Также в его обязанности входит оформление документации по информационной безопасности (различных соглашений по неразглашению конфиденциальной информации и др.).