Чаще всего IT-специалисты хотят работать в продуктовых компаниях. Даже если там есть бюрократия и какие-то куски legacy-кода, все же причастности к продукту и возможностей для развития там зачастую больше. Но, безусловно, важно помнить, что все зависит от каждого конкретного человека. Некоторых, например, драйвит и хороший аутсорсер. А потому не делаем выводы за кандидата и задаем вопросы!
Глава 6
Обзор IT-профессий
Описать всех специалистов в области IT физически невозможно, потому что каждый день, по мере развития технологий и рынка в целом, появляются новые специальности. В этой главе я опишу основные профессии, с которыми рекрутер может столкнуться чаще всего.
Важно помнить, что теория и практика, к сожалению, совпадают далеко не всегда. И любые теоретические правила на практике могут не выдерживать никакой критики. Описание профессий, которые вы найдете ниже, — теоретическое. На практике аналитик в компании может выполнять роль продакт-менеджера, а тот — заниматься разработкой. Бывает всякое! Однако надо же нам от чего-то отталкиваться. Я предлагаю эту систематизацию как базисную, и по мере развития в профессии вы будете ее для себя уточнять.
Аналитики. В сфере IT мы говорим «аналитик», а подразумеваем — «системный аналитик». Хотя существуют еще бизнес-аналитики и аналитики Big Data (о них позже).
Чем же занимается этот специалист? Он прорабатывает сценарии использования будущего продукта, пишет технические задания для разработчиков, тестирует и принимает готовое ПО.
Подключаясь к проекту, аналитик в первую очередь собирает требования к разрабатываемому продукту: каким он должен быть и какие функции выполнять. Происходит это, как правило, с помощью интервью. Аналитик опрашивает заказчиков со стороны клиента, если это заказная разработка, или потенциальных пользователей продукта, если софт планируется продавать.
На основе того, что выяснилось, аналитик составляет техническое задание для разработчиков. Это масштабная, точная, очень дотошная работа — создать такой документ, в котором подробно описано, как система будет работать. Любой упущенный, не оговоренный в документации фактор может легко увести проект с нужного курса. Как говорил доктор Хаус про девочку-пациентку, «если бы в ее ДНК отклонение было на один процент, она была бы дельфином».
После того как ТЗ начинает воплощаться в жизнь, задача аналитика — участвовать в тестировании и прогнозировать возможные ошибки.
Бизнес-аналитики обычно занимаются более верхнеуровневыми задачами, больше коммуницируют с заказчиком, знают предметную область, но не включаются в процесс написания детального ТЗ.
В своей работе аналитики чаще всего используют нотации — специальный софт для создания различных блок-схем и диаграмм. После того как вы отрисовали с помощью нотаций какой-нибудь пользовательский сценарий (как использовать ваше приложение), можете подгрузить его, например, к Jira (система отслеживания ошибок) — и уже там отмечать существующие баги. Это гораздо удобнее, чем объяснять на пальцах.
Среди популярных нотаций можно выделить UML, BPMN, Visio и т. п.
Общаясь с аналитиком, скорее всего, вам нужно будет попросить его показать пример ТЗ или различных схем, которые он сможет показать, чтобы ваш бизнес-заказчик мог оценить, насколько хорошо проработано ТЗ.
Технический писатель — специалист, который занимается составлением документов в рамках разработки продукта. Он описывает функционал продукта по установленным нормам, руководство по эксплуатации для пользователей и многое другое. В некоторых случаях он может заниматься оформлением этой документации: добавлять иллюстрации, видео, анимацию.
На российском рынке не очень много таких специалистов. Продолжение карьерного роста технического писателя — системная аналитика, и если человек вырос в аналитика из писателя, то он часто сам выполняет всю текстовую работу.
Техническому писателю необходимо уметь объяснять сложные вещи простым языком. Для этого, конечно же, нужен навык понимания этих самых сложных вещей. Его цель — докопаться до сути проекта, понять ее и уже только после этого описать.
Помните все эти убогие инструкции? Так вот, часто их делают технические писатели. Теперь понимаете, почему так важен хороший техпис? Ведь он работает не только с пользовательской инструкцией, но и с внутренней документацией.
Project manager (проджект-менеджер — менеджер проекта) и Product manager (продакт-менеджер — менеджер по продукту). Мы подробно разберем эти позиции в отдельной главе, пока же важно отметить, что Project manager в IT обычно занимается «административной» работой. Его задача — успешная реализация проекта в установленные сроки в рамках запланированного бюджета.