Какую профессию выбрать, чтобы стать программистом
Современная разработка программного обеспечения — это фактически завод, где каждый участник крутит свою гайку на конвейере, а в результате с ленты сходит готовое к использованию решение. Времена, когда один программист мог разработать супер хит типа Prince of Persia, ушли в прошлое. Сейчас схожие по популярности игры разрабатывают сотни и тысячи специалистов разных специальностей. В статье я дам краткий обзор профессий, которые принимают участие в разработке современных программных продуктов. Эта информация будет полезной для тех, кто только начинает свой карьерный путь, или просто интересуется темой информационных технологий («кто эти таинственные айтишники, которым столько платят и дают льготную ипотеку?»). Поехали.
Для того чтобы в дальнейшем рассказывать про специальности необходимо пояснить, а что такое программные продукты, про разработку которых идет речь. Хороший продукт обладает следующими свойствами:
- Имеет необходимую функциональность, то есть решает какую-нибудь проблему пользователя. Например, MS Word позволяет удобно форматировать тексты, а браузер Chrome серфить в интернете.
- Продукт должен быть удобен и понятен, то есть пользователю должно быть удобно с ним работать, а не тратить время на поиск нужной кнопки.
- Продукт должен быть качественным. Не существует программного обеспечения без ошибок и багов, но нужно чтобы их количество не сильно раздражало. Например, в одной из версий Tesla был интересный баг: полная луна воспринималась за желтый сигнал светофора и машина начинала притормаживать, однако по совокупности свойств машина пользователям нравится.
- Продукт должен поддерживаться и развиваться, то есть в случае возникновения багов, производитель мог быстро выпустить обновление и помочь пользователю.
Менеджер по продукту определяет функционал, который должен иметь продукт. Требований и пожеланий к продукту всегда больше, чем можно реализовать. Задача Product manager'а выбрать из всего этого многообразия то, что сделает продукт востребованным рынком, при этом максимизирует прибыль от его продажи. То есть не обязательно вкладывать много усилий для того, чтобы сделать продукт самым крутым по всем параметрам. Например, фуре не обязательно уметь разгоняться до 200 км/час, хотя это и круто. Ее покупают для того, чтобы стабильно и надежно возить грузы. Результатом работы менеджера по продукту являются бизнес требования к продукту. Например, фура должна иметь спальное место для отдыха водителя и расход топлива 25 литров на 100 км. Таким образом, менеджер по продукту отвечает за первое свойство продукта: выбор функциональности, которая решает проблему клиента.
Системные аналитики переводят бизнес требования на язык понятный инженерам, прорабатывают детальные сценарии использования и выставляют требования уже не к продукту в целом, а к конкретной подсистеме. Например, если есть требования к месту отдыха водителя, то нужно уточнить размеры места отдыха (водители бывают разных размеров), место расположения (в кабине, а не на крыше, например), а также добавить сценарий, что водитель может быть не один. Могут быть уточнения, нужен ли рядом стол и т.п. Это только на первый взгляд кажется, что инженеры умные и сами сделают как надо без пояснений, в реальности же спальное место может оказаться в полуприцепе. Аналитик отвечает за второе свойство продукта - удобство использования, а также доносит до остальных членов команды требования к продукту.
Программисты - собственно люди, которые пишут код продукта. В народном понимании именно они истинные авторы продукта, хотя как видно из этой статьи не только программисты создают продукт. Существует много различных языков программирования и различных фреймворков: постоянно появляются новые, а некоторые устаревают и перестают использоваться. Например, сравнительно недавно появился GoLang, а в новых продуктов на Cobol или Pascal никто не делает. По-крупному разработчики делятся на front end, которые разрабатывают интерфейс пользователя, и back end, разрабатывающих внутреннюю часть. На примере фуры front-end это кабина с рулем, ручкой переключения передач и сиденьями, а back end - двигатель и коробка передач. Также есть full stack специалисты, которые умеют разрабатывать и то, и другое.
Архитекторы придумывают из каких крупных модулей будет состоять продукт и каким образом и через какие интерфейсы эти модули будут взаимодействовать друг с другом. В примере с фурой - это полуприцеп и собственно тягач, а интерфейс - сцепное устройство. Сцепное устройство стандартизовано и позволяет собирать итоговый продукт, "фуру", из разных тягачей и полуприцепов. Правильная архитектура продуктов непосредственно влияет на его качество, а также на возможность развития и поддержки продукта.
Инженеры по тестированию, как понятно из названия, тестируют продукт, т.е. непосредственно отвечают за его качество. Оговорюсь, что за качество продукта отвечают все члены команды разработки, а не только тестировщики, но это выходит за рамки данной статьи. Существует множество видов тестирования, но можно выделить три основных направления:
- Ручное или функциональное тестирование: человек руками кликает в интерфейс продукта и смотрит, как он работает. Развивая тему фуры - сел и совершил поездку на ней.
- Автоматическое тестирование: пишут другую программу, которая тестирует заданный продукт, заменяя собой регулярно повторяющиеся ручные тесты. Может тестироваться как продукт целиком, так и отдельные модули. Например, делаем стенд, который отдельно тестирует различные режимы работы двигателя.
- Нагрузочное, нацеленное на проверку продукта под нагрузкой. По-простому, чтобы продукт не тормозил и выдерживал длительные нагрузки :) Гоняем фуру по треку на максимальной скорости в течение суток. Смотрим, что получится.
Технические писатели или Doc&Loc - к продукту необходима документация, которую, как и автомобильную, никто не читает пока что-нибудь не сломается. Кроме этого, у продукта есть интерфейс, содержащий различные надписи на различных языках (локализация интерфейса). Документация и интерфейс не должны содержать грамматических ошибок и быть удобочитаемыми. Далеко не все front end разработчики умеют грамотно писать на человеческом языке, поэтому технические писатели необходимы.
UX/UI designer - отвечают за красоту (UI designer) и удобство (UX designer) интерфейса пользователя. UI - сокращение от User Interface, т.е. интерфейс пользователя, а UX - User Experience, т.е. опыт пользователя. Последнее время UX является важным направлением развития, так как избалованный пользователь выбирает то, что ему удобно. Например, можно сделать автомашину и поставить рычаг поворотника справа, а не слева (так бывает у многих праворульных машин). Формально, все требования к интерфейсу выполнены, но пользователям из большинства стран мира это будет неудобно.
DevOps (development & operations) - разработка продуктов - это большой конвейер, поэтому есть те, кто создает этот конвейер и обеспечивает его работоспособность. Команда DevOps отвечает за инфраструктуру разработки, как hardware (сервера, системы хранения данных), так и software составляющую (хранение кода, сборка продукта, виртуализация и т.д.). Случись что с инфраструктурой - встает вся разработка, уместно вспомнить старый советский анекдот:
В НИИ стали приводить львов и выпускать в рабочее врем в коридоры, чтобы сотрудники работали, а не болтались. Потом случилось ЧП, и львов убрали. Один лев - другому: "И нужна была тебе эта уборщица! Я двадцать два научных сотрудника съел, и никто не заметил!"
Менеджеры (управленцы, teamlead'ы) занимаются выстраиванием процессов разработки и взаимодействия внутри коллектива, распределяют задачи и решают конфликтные ситуации, которые неминуемо возникают в любом творческом коллективе. А так же являются постоянными негативными героями народного фольклора.
Телеграм канал автора статьи: https://t.me/CTO_in_Action