Текст книги "Управление персонажами в IT"
Автор книги: Валерия Калугина
Жанр: Управление и подбор персонала, Бизнес-Книги
Возрастные ограничения: +16
сообщить о неприемлемом содержимом
Текущая страница: 2 (всего у книги 8 страниц) [доступный отрывок для чтения: 2 страниц]
1.3. Разновидности IT-компаний
Компании делятся на две больших категории, исходя из ролей и персонажей, которые играют специалисты в разработке программного обеспечения. Различия в управлении и планировании персонала среди персонажей в IT отличаются, как корпоративных дух в стартапе и в бюрократической компании.
Первая группа – это те компании, в которых IT – это просто отдел, который не является основным бизнесом, а вторые – те, в которых бизнес построен вокруг IT.
С теми компаниями, в которых IT представлен в качестве отдела, все достаточно просто. Это могут быть фабричные производства, банки, крупные строительные и любые другие компании, в которых нужна автоматизация. Чаще всего эти IT-отделы нужны именно для автоматизации документооборота или улучшения каких-то бизнес-процессов внутри компании, и от IT-отдела не требуется ничего сверхъестественного, кроме решения конкретных потребностей этого бизнеса.
В таких компаниях чаще HR-отдел занимается массовым подбором персонала, начиная от вакансий менеджеров продаж до программистов, редко бывают отдельные HR-подразделения для работы с IT-специалистами. Культура такой компании строится, в основном, как общая для всех подразделений без исключения.
Вторая категория компаний – это те компании, в которых бизнес построен вокруг IT. Они делятся еще на несколько типов, о которых тоже нужно знать.
ЗАКАЗНАЯ РАЗРАБОТКА (OUTSOURCING)
Первый тип – компании, занимающиеся заказной разработкой, или аутсорсингом. Такие компании имеют в своем штате разработчиков – иногда совершенно разных – и буквально продают их рабочее время заказчикам, у которых своих разработчиков нет, но им нужен какой-то софт. Большие аутсорсеры работают с представителями различных направлений бизнеса: промышленными предприятиями, страховыми компаниями, банками – теми, кому нужен серьезный софт, в разработке которого задействовано много разработчиков.
Из-за особенностей бизнеса заказной разработки, по сути, построенного в том или ином виде на продаже времени своих сотрудников, он стабилен, когда в нем много разработчиков – чем больше, тем лучше. По этой причине аутсорсеры стараются быть очень большими, у них работает очень много молодых разработчиков, они часто интегрируются с университетами, имеют кучу офисов по всему миру. В крупных компаниях, таких как EPAM, Luxoft и DataArt, работают тысячи разработчиков. Эти компании прибыльны и устойчивы на рынке.
Помимо таких гигантов, в аутсорсинге работают очень много небольших компаний: от 1–2 до 50–100 разработчиков. Однако чем меньше компания, тем более она нестабильна: если у вас в одном месте где-то заказ не пошел, освобождаются люди, которых надо чем-то занимать, иначе их высокая зарплата не будет окупаться фирмой. С одной стороны, этому бизнесу присущи большие риски, но с другой, его очень легко начать – отсюда и большое количество конкурирующих компаний. Можно предпочесть и аутсорсинг.
Аутсорсинг в IT – это передача организацией определенных видов или функций технической и/или предпринимательской деятельности другой компании, действующей в нужной области.
Некоторые компании, осуществляющие заказную разработку, именно так и начинали свою деятельность, сдавая услуги и время своих разработчиков в аренду другим IT-компаниям (outstaff).
ПРОДУКТОВАЯ РАЗРАБОТКА
Другое большое и перспективное направление – это продуктовая разработка, когда компании занимаются развитием собственных продуктов, интересных потребителям.
Клиентами продуктовых компаний могут быть и люди, и другие компании, и госучреждения. Если у компании реально получается сделать востребованный на рынке продукт и маркетологи его успешно продвинули на рынок, то соотношение заработка к затратам обычно несоизмеримо.
В ЧЕМ ОСНОВНЫЕ ОТЛИЧИЯ АУТСОРСИНГА И ПРОДУКТОВОЙ РАЗРАБОТКИ?
В аутсорсинге все достаточно просто: вы берете человека, он обходится вам в определенную сумму в часах, и разница между продажами его часов и затратами компании на оплату этих часов будет чистой прибылью компании. Обычно компании готовы расти и принимают гибридную форму, когда разрабатывают свои проекты, но при этом имеют и постоянных заказчиков параллельно. В классической продуктовой разработке, если ваш продукт востребован, вы можете иметь команду в 4 человека, но при этом зарабатывать миллионы долларов и обслуживать миллионы пользователей.
Таким образом, компании занимаются разработкой собственных продуктов. Продуктом может быть все что угодно – мобильное приложение, социальная сеть, среда разработки или любая программа на ПК или для электронного устройства.
Название таких продуктовых IT-компаний, как Microsoft, Google или «Яндекс», у всех на слуху. Миллионы людей ежедневно пользуются их продуктами.
Чтобы добиться таких результатов в своей нише, продуктовой компании важно постоянно держать руку на пульсе, иметь штат маркетологов или обратиться в соответствующее агентство. Нельзя допустить, чтобы пользователи предпочли продукты конкурентов, ведь они основной источник дохода. Именно поэтому компании постоянно проводят маркетинговые исследования по методу customer development, узнавая потребности своих клиентов и меняясь вслед за ними.
Customer development – это тестирование идеи или прототипа будущего продукта на потенциальных потребителях.
Модель продуктовых компаний немного интересней, потому что позволяет вам неограниченно масштабироваться, но создать такой продукт значительно сложнее, чем начать аутсорсинг. Кроме того, жизненные циклы некоторых продуктов время от времени подходят к концу из-за изменения рынка, они часто перестают существовать, поэтому риски продуктовых компаний стать банкротом гораздо выше, чем у аутсорсеров.
От того, где IT-специалисты предпочитают работать, зависит многое. На собеседовании вы услышите вопросы об источниках дохода компании, есть ли заказчики или собственный продукт компании. От желания самого разработчика: делать свои интересные продукты с риском их провала на рынке или делать проекты, которые дают сверху, но со стабильной оплатой и типовыми задачами – многое зависит в его карьере.
1.4. Роли в технической команде: из чего строится иерархия
Рассмотрим роли в IT-проектах, которые имеют непосредственное отношение к разработке продукта. Как мы помним из мифов, в IT-компании работают не только программисты. И даже стоит отметить, что в небольших компаниях часто один человек выполняет сразу несколько ролей, и это частая история в стартапах и небольших продуктовых компаниях.
Итак, начнем с ключевых управленческих для IT-проекта ролей:
МЕНЕДЖЕР ПРОДУКТА, ПРОДУКТОУНЕР (PRODUCT MANAGER)
По названию профессии уже понятно что этот специалист управленец и создает саму стратегию развития и поэтапной разработки продукта. Он узнает требования от заказчика и пользователей и проводит исследования, изучает и прогнозирует, что будет с рынком, на который рассчитан его продукт.
Он больше всех знает о достоинствах и недостатках продукта, презентует его, с точки зрения потребителя, но не погружается в технологический стэк. Часто имеет навыки ручного тестирования.
МЕНЕДЖЕР ПРОЕКТА (PROJECT MANAGER)
Эта ключевая роль в IT-команде, этот человек ответственнен за результаты работы всех программистов, аналитиков и тестировщиков, ответственный за достижение целей проекта в рамках бюджета, за дизайн и качество реализации в срок нужный заказчику.
Проектный менеджер анализирует, мотивирует и контролирует членов команды чаще с помощью профессионального ПО, вроде программы для управления проектами JIRA. Однако часто в небольших IT-компаниях обязанности проджект-менеджера и продукт-менеджера совмещены на одном сотруднике.
Аналитические роли в IT, тоже не программисты:
АРХИТЕКТОР (ARCHITECT)
Самая сложная часть проекта – это проектирование архитектуры ПО, то есть принятие и разработка технических решений относительно внутреннего устройства программной системы, облачного сервиса, приложения – всех технических интерфейсов.
Архитектор определяет конструкцию ПО, из каких элементов она состоит и как эти элементы связаны внутри и со сторонними сервисами. При этом архитектор учитывает, что с точки зрения бизнеса должна выполнять система, и строит свою модель на основе лучших мировых практик разработки ПО.
Часто архитектуру представляют в виде схемы с указанием технологического стэка разработки. Архитектор часто является опытным разработчиком который может помочь настроить саму среду разработки для других специалистов и сам пишет код.
БИЗНЕС-АНАЛИТИК (BUSINESS ANALYST)
Напрямую общается с заказчиками продукта и выясняет их пожелания и требования. Иногда его заменяют продуктоунером. Задача бизнес-аналитика – понять, чего хочет заказчик, как он видит продукт, который будет разрабатываться, какая цель у продукта и какие задачи он будет решать. На момент общения с заказчиком бизнес-аналитик может предлагать свои идеи по улучшению идеи продукта и совместно с заказчиком формировать так называемый vision.
Видение проекта, или vision, – это описание сути и ценности будущего продукта, заключенное в Уставе проекта. В этом документе описывается, что это за продукт, каковы цели и задачи его создания, кто его пользователи и каковы основные возможности будущей системы.
СИСТЕМНЫЙ АНАЛИТИК (SYSTEM ANALYST)
Этот специалист отвечает за анализ данных и договаривается с заказчиком проекта и архитектором, как будет работать ПО, какие методы разработки будут использоваться. Во многом он занимается написанием основных технических документов (техническое задание, или ТЗ, устав проекта, спецификации). Важная часть работы – функциональный анализ, в результате которого выделяется перечень функций, которые должна выполнять система, а также определение бизнес-требований.
Основная задача системного аналитика – детально расписать еще и технические функции ПО, учитывая взаимодействие между функциональными модулями и сторонними сервисами.
ТЕХНИЧЕСКИЙ ПИСАТЕЛЬ (TECHNICAL WRITER)
Редкий специалист, который занимается составлением документации в рамках разработки различных программ. Результат работы технического писателя – инструкция по эксплуатации системы, причем как для внешних пользователей, так и для сотрудников, обеспечивающих поддержку системы, или менеджеров клиентского сервиса.
ТЕСТИРОВЩИК (TESTING ENGINEER), ИЛИ QA-ИНЖЕНЕР (QUALITY ASSURANCE)
Специалист, который занимается тестированием программного обеспечения (ПО) с целью выявления ошибок в его работе и их последующего исправления.
Тестировщики бывают разного уровня квалификации, в зависимости от видов тестирования: ручного и автоматизированного.
На ручное тестирование достаточно пройти обучающие курсы с любым базовым образованием, но автоматизированное тестирование требует написания программного кода (авто-тестов) для автоматической аналитики ошибок. Такой уровень требует высокой квалификации специалиста: знания основ программирования и умения писать автоматизированные тесты в зависимости от задач проекта.
Самые творческие личности в IT:
ПРОЕКТИРОВЩИК
Занимается построением макетов создаваемой системы с учетом удобства ее использования, превращает описанные в ТЗ функции в панели инструментов, кнопки, поля, таблицы и прочее, что видит и с чем взаимодействует пользователь. Результат его работы – макет, как правило, черно-белый, без графических элементов, который показывает расположение элементов интерфейса и возможные переходы между элементами и страницами (экранами) продукта. Пример макета ниже на картинке.
ВЕБ-ДИЗАЙНЕР (DESIGNER)
Дизайнер прорабатывает все элементы макетов системы, определяя форму, цвета, размер элементов, шрифты, прорисовывает графические элементы (картинки, баннеры, логотип), которые должны присутствовать в нашем продукте.
Простыми словами, дизайнер берет черно-белый макет проектировщика и заливает его красками. Часто называют UX/UI-дизайнером. Критикует программистов, обычно по делу.
UX/UI дизайн – это проектирование пользовательских веб-интерфейсов в которых удобство использования так же важно как и внешний вид.
ВЕРСТАЛЬЩИК (WEB DEVELOPER / FRONT END DEVELOPER)
Специалист, выполняющий верстку веб-страниц. Он оживляет макеты дизайнера, делая элементы интерфейса доступными для взаимодействия с пользователем. С помощью специального языка разметки HTML и CSS верстальщик задает правила, как браузеру отображать элементы на web-страницах. Например, размер монитора у всех пользователей разный, и браузеры по-разному отображают те или иные элементы, для того чтобы все элементы отображались правильно, и работает верстальщик.
Благодаря верстальщикам на сайтах появляются красивые эффекты нажатия на кнопку (и другие!), текст выровнен по правильному краю, а сайтом удобно пользоваться как с ноутбука, так и с мобильного телефона.
Наконец-то, роли в IT для программистов:
РАЗРАБОТЧИК/ПРОГРАММИСТ (DEVELOPER)
Это ключевая роль в IT, этот специалист занимается разработкой программного обеспечения (ПО), алгоритмов компьютерных программ. Человек, благодаря которому у тестировщиков, проектных менеджеров и системных аналитиков всегда будет работа!
Разработчик реализует написанные аналитиком требования. Его задача – воплотить в жизнь все функции, которая должна уметь делать система.
ОБЫЧНО РАЗРАБОТЧИКОВ ДЕЛЯТ НА FRONTEND, BACKEND И FULLSTACK:
Frontend – это внешний вид программы, то, с чем непосредственно взаимодействует пользователь. По факту, Frontend-разработчик может делать задачи верстальщика, связывая дизайн с внутренним устройством сайта.
Backend – это логика, которую не видит пользователь, но благодаря которой все функции системы выполняются верно. Вackend делает обработку информации, введенной пользователем, полученной из frontend, и возвращает frontend’у результат в понятной визуальной форме для пользователя.
Fullstack – программисты, которые делают и Frontend, и Backend-разработку вместе, также они могут осуществлять тестирование своего кода самостоятельно. Обычно это продвинутые разработчики с хорошим базовым IT-образованием.
Пример работы: форма регистрации на сайте. Frontend-разработчик сделает красивую форму и разместит ее в нужное место в правом верхнем углу экрана и сведет с дизайном.
Backend-разработчик реализует логику, по которой после заполнения полей в правом верхнем углу экрана и нажатия на кнопку «Регистрация» данные записи будут занесены в базу данных.
Теперь давайте разберемся, какие виды программного обеспечения и направления разработки существуют, куда можно идти и чем заниматься программистам.
Существует множество различных классификаций программного обеспечения, но при выборе направления работы программисты в первую очередь обращают внимание на платформу (среда выполнения кода).
Классификация ПО по платформам:
• программная платформа,
• аппаратная платформа,
• кроссплатформенное ПО.
Наиболее популярно в мире IT, создание кроссплатформенного ПО – в связи с быстрым изменением технологий кросс-платформенное ПО может пережить ту конкретную платформу, для которой оно создавалось.
Примерами программного обеспечения, выполняющегося на разных аппаратных платформах и под управлением разных операционных систем (например Linux или Windows), являются разнообразные программы, написанные на языках программирования для виртуальных машин, таких как, например, PHP, JavaScript, Python, Java и многие другие.
В последнее время огромной популярностью пользуются мобильная и веб-разработка – в них больше вакансий, денег и возможностей. В разработке есть специальные направления, не связанные с одним типом платформы, например разработка игр (gamedev). Программисты пишут игровые движки, игры для веб-версий, и все больше и больше игр портируется или разрабатывается для мобильных устройств. Это лишь отвлеченный пример, связанный с трендами современности: все уходит в веб и мобильные устройства, но в целом он прекрасно иллюстрирует взаимосвязь платформ и специализированных отраслей разработки, показывая важность первых при выборе направления своей деятельности через несколько лет.
Инструментарий – это все, что помогает разработчикам: средства отладки, фреймворк (скелет приложения или веб-сервиса), да и сами языки программирования. Это отдельное направление, которое требует очень серьезного уровня разработчиков. Без базового фундаментального образования заниматься этим направлением очень сложно, но при большом желании и усердии возможно.
Другие роли в IT:
ЗАКАЗЧИК (CUSTOMER)
Сторона (человек, компания), заинтересованная в осуществлении проекта и достижении его целей. Будущий владелец финансовых результатов и юридической ответственности проекта. Заказчик определяет основные требования к результатам, обеспечивает финансирование проекта за счет своих или привлекаемых средств, может заключать договор о конфиденциальности кода с основными исполнителями проекта.
ПОЛЬЗОВАТЕЛИ (USERS)
Юридические и/или физические лица, являющиеся покупателями и пользователями результата проекта, определяющие требования к производимой продукции и оказываемым услугам, формирующие спрос на них.
ЗАИНТЕРЕСОВАННЫЕ ЛИЦА (STAKEHOLDERS)
Физические лица или организации, имеющие права, долю, требования или интересы относительно разрабатываемой системы. К заинтересованным лицам относят и заказчика, и пользователей, и всех, кто так и иначе ждет реализации вашего продукта.
Мы рассмотрели основные роли в IT-командах и узнали языки программирования, с которыми предстоит встречаться в вакансиях. Можно заметить постоянное разрастание поля IT-вакансий от программиста со знанием мультипликационной анимации до логистики. Часто IT-специалистам предстоит по ходу проекта узнать новую сферу с нуля, в зависимости от требований заказчика, рынка, и работа продуктоунера будет строиться на ранее не существовавшей системе.
Язык программирования (англ. Programming language) – система обозначений для описания алгоритмов и структур данных, определенная искусственная формальная система, посредством которой можно выражать алгоритмы.
Трудно определить, какой язык программирования наиболее популярен, так как значение слова «популярность» зависит от контекста. Существуют различные метрики для измерения популярности языков, каждая из которых разработана с пристрастием к определенному смыслу понятия популярности:
• подсчет числа вакансий, упоминающих язык;
• количество проданных книг (учебников или справочников);
• оценка количества строк кода, написанных на языке (что не принимает в расчет редко публикуемые случаи использования языков);
• подсчет упоминаний языка в запросах поисковиков.
Существует уже несколько тысяч языков программирования, но все равно новые языки появляются каждый год. Обычно язык делается для решения каких-то конкретных задач, но иногда и для одного-единственного нового устройства. Так происходит, когда имеющийся язык почему-то стало неудобно использовать.
Важно следить за актуальными новостями относительно языков программирования, ведь чем популярнее и проще язык, тем проще найти разработчиков.
Актуальное состояние можно и нужно отслеживать по международным рейтингам, в частности, рекомендуются TIOBE Index и Stack Over^ow (исследования Developer Survey). Относительно российского IT-сообщества вы можете всегда заглянуть на порталы Habr.com или же vc.ru.
Привычно популярными в мире и России являются такие языки: вся группа С-языков, Java, JavaScript, PHP и Python.
Библиотеки – наборы функций, готовых шаблонов, написанных на каком-то из языков программирования. Это удобно и похоже на книги в обычной библиотеке: на них можно ссылаться внутри программ и сразу получать результат без необходимости каждый раз писать много кода.
Например, в современном языке программирования Python есть модуль – библиотека yandex_translate, которая переводит тексты на разные языки. Программистам не надо создавать программу-переводчик с нуля, достаточно подключить этот модуль и обратиться к нему из любой точки кода.
Программная платформа, определяющая структуру программной системы; программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта, называется фреймворк (framework – остов, каркас, структура).
Представьте: вам нужно построить дом. Можно выбрать готовый типовой проект и немного поиграть с планировкой. В типовом проекте уже все продумано: оптимальное расположение коммуникаций, деление комнат, электрика и другие нюансы. Вы получаете теплый и уютный дом, самостоятельно расставляя мебель и декор. В рамках готового проекта вы еще можете сделать отклонения от шаблона в виде нескольких розеток или чернового входа в дом.
Так же и во фреймворке программист использует готовый шаблон и наполняет его своим кодом. Такая программа работает стабильно: все основное фреймворк берет на себя.
Фреймворк отличается от понятия библиотеки тем, что библиотека может быть использована в программном продукте просто как набор подпрограмм близкой функциональности, не влияя на архитектуру программного продукта и не накладывая на нее никаких ограничений. В то время как фреймворк диктует правила построения архитектуры приложения, задавая на начальном этапе разработки поведение по умолчанию – каркас, который нужно будет расширять и изменять, согласно указанным требованиям.
Более подробно понять, какие языки программирования, библиотеки и фреймворки чаще используются известными IT-компаниями и на каких проектах они применяются, вы можете узнать, обратившись к актуальным аналитическим данным международного портала stackoverflow.com.
Созидательный характер деятельности над новым инновационным проектом обычно является мощным аргументом для претендента на вакансию принять именно ваш оффер, а не конкурентов. Всегда нужно подавать вакансию для отработки интересных задач, которые развивают таланты разработчика в зависимости от уровня его задач, знания языков программирования и опыта использования библиотек и фреймворков. Слишком нагруженная IT-терминами вакансия будет пугать начинающего разработчика, тогда как легко написанная без подробностей и техстека разработчика будет проигнорирована опытным кандидатом.
Последнее, о чем мы будем вести речь в этом пункте, – это уровни разработчиков в зависимости от опыта работы: junior, middle, senior. Эта классификация по понятным причинам удобнее для работы в международных и российских компаниях. Также она более гибко отражает разделение в рамках требований каждой конкретной компании.
Junior (джуниор): студент старших курсов или выпускник без существенного опыта работы, обычно 0,5–1,5 года реального опыта на одном-двух языках программирования. Решает стандартные задачи с незначительными рисками. Джуниору нужно помогать и проверять результаты, не давать слишком сложные и длительные задания. После выполнения приходится регулярно делать code review (проверку кода). Владение предметной областью неполное.
Middle (мидл): основной разработчик, умеющий самостоятельно выполнять поставленные перед ним задачи. Обычно 1–3 года опыта. Простые задачи можно не проверять. Разработчик может делать длительные задачи на 1–2 недели и принимать архитектурные решения. Справляется с нестандартными задачами, а стандартные делает быстрее и с меньшим количеством ошибок, чем джуниор.
Senior (синьор): работник, хорошо знающий предметную область. Опыт работы – 4–7 лет. Проводит рефакторинг кода (улучшение и переписывание по канону языка), мыслит проектом на уровне архитектуры и понимает долгосрочные последствия технических решений. Умеет предложить глобальные решения и (если это имеет смысл) ищет альтернативные стеки технологий. Нередко совмещается с управляющими должностями, если этого захочет.
Нужно понимать, что на задачи, которые синьор решит за десять минут, джуниору может потребоваться три подхода по два часа каждый, а в процессе код будет переписывать полностью мидл, затратив массу дополнительного времени.
Управляющему менеджеру и HR важно чувствовать баланс в команде и планировать потребность в разработчиках исходя из загрузки синьоров и мидлов на обучение начинающих разработчиков. Более подробные отсылки к тому, как работать с разными категориями людей в IT (по возрасту и статусу в команде) можно будет прочитать в 3 главе книги. В ней подробно рассказывается о теории поколении: X, Y, Z.
Внимание! Это не конец книги.
Если начало книги вам понравилось, то полную версию можно приобрести у нашего партнёра - распространителя легального контента. Поддержите автора!Правообладателям!
Данное произведение размещено по согласованию с ООО "ЛитРес" (20% исходного текста). Если размещение книги нарушает чьи-либо права, то сообщите об этом.Читателям!
Оплатили, но не знаете что делать дальше?