Юнит менеджер что за должность

Обновлено: 02.07.2024

На рынке труда в ИТ-сфере даже в трудные времена спрос превышал предложения. Высококвалифицированные ИТ-специалисты всегда очень востребованы.

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

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

Краткое описание должностей специалистов

Название должности

Основные задачи и результаты работы

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

разработка веб-приложения;
разработка и внедрение UI;
участие в построении архитектуры клиентской части;
взаимодействие с дизайнерами и верстальщиками.

резка макетов; верстка веб-страниц с нуля;
адаптивная верстка;
внесение правок в существующие сайты;
умение оценить сроки реализации верстки макетов.

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

PHP – скриптовый язык общего назначения, интенсивно применяемый для разработки веб-приложений.

разработка и поддержка сайтов;
проектирование и реализация новых сервисов;
разработка собственных и взаимодействие с внешними API.

Ruby – динамический, рефлективный, интерпретируемый высокоуровневый язык программирования. Язык обладает независимой от операционной системы реализацией многопоточности, строгой динамической типизацией, сборщиком мусора и многими другими возможностями.

разработка новых сервисов компании на Ruby;
проектирование и архитектура продукта;
развитие инфраструктуры.

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

разработка нового проекта;
участие в проектирование архитектуры проекта;
написание backend-кода.

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

разработка различных проектов для системы управления бизнес-процессами;
разработка клиент-серверных решений;
использования реляционных СУБД.

NET – программная платформа, выпущенная компанией Microsoft. Основой платформы является общеязыковая среда исполнения Common Language Runtime (CLR).

участие в проектировании архитектуры БД, анализ технических заданий;
разработка структуры БД, хранимых процедур, триггеров, представлений;
поддержка работы БД: мониторинг нагрузки, поиск "узких" мест производительности, оптимизация SQL-запросов и структуры БД;
взаимодействие с аналитиками и программистами в процессе проектирования и реализации заданий.

Программист Swift (ObC)

Swift – открытый мультипарадигмальный компилируемый язык программирования общего назначения. Создан компанией Apple в первую очередь для разработчиков iOS и macOS.

разработка iOS приложений;
проектирование архитектуры приложений и сервисов;
тестировании, доработка существующих.

Программист Android (java)

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

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

Unity – это инструмент для разработки двух- и трёхмерных приложений и игр, работающий под Windows, macOS, Linux, Xbox One, Wii, Wii U, PlayStation 3, PlayStation 4, PlayStation Vita, iOS, Android, WebGL, Tizen, Facebook, TvOS и Nintendo Switch.

разработка кроссплатформенного клиента;
активное участие в проектировании и разработке архитектуры;
проектирование и реализация игровых фич;
принятие совместных решений с художниками, 3D-моделлерами, гейм-дизайнерами.

Программист Unreal Engine (С++)

Unreal Engine – игровой движок, разрабатываемый и поддерживаемый компанией Epic Games.

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

Такое несоответствие реальной потребности и воображаемой я встречаю повсеместно.

Корпоративные иерархии и HR-отделы оперируют набором красивых слов, и вот некоторые из них:

Head of Product
Chief Product Officer
Senior Product Manager
Senior Product Owner
Product Manager
Project Manager
Product Owner
CTO
CIO
Tech Lead
Team Lead
Architect
Head of PMO
Chief Architect
Project Lead
Business Owner

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

О ролях и функциональности я и хочу поговорить ниже.

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

Отвечает за развитие технологической части компании.

Размытое определение? Уточним: — В стартапе на 10 человек CTO обычно выполняет функции тимлида, но получает красивое название по двум причинам: чтобы потешить собственное эго и в расчете на то, что в будущем он займет эту роль. Объясняется это тем, что человек отвечает не за конкретную команду, а за развитие всей технологической части сейчас и в будущем.

— В компании на 100 человек основная задача CTO — отвечать за выполнение технической части продуктовых планов компании, развивать компетенции технического отдела, синхронизировать подходы разных команд к разработке, способствовать устойчивости технической части бизнеса.

— В компании на 1000+ человек частью задач предыдущего блока (синхронизация подходов разных команд к разработке, поддержание единого стэка и архитектуры) занимается Chief Architect. Фокус CTO уходит на найм и развитие руководителей, управление техническими лидерами направлений, и ответственность за выполнение технических планов.

— В компании на 10 000+ CTO отвечает за долгосрочное техническое видение компании и выполнение стратегических планов.

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

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

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

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

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

Задача тимлида — выполнить планы команды, на это завязана его мотивация. Когда в компании одна команда, тимлид — то фактически CTO, у него много свободы и ответственности.

С ростом количества людей и делением их на команды, каждая команда начинает (и должна) переживать только о своих планах. Чтобы синхронизировать их работу появляется CTO, человек который отвечает за все команды.

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

Чтобы было понятнее: CTO нанимает руководителей, участвует в постановке проектных целей, отвечает за согласование и выполнение планов и за стратегическое развитие технической части. Архитектор создает стратегическое архитектурное видение и делает так, чтобы команды в погоне за своими планами его не сломали.

Зеркало роли CTO в продуктовой части. Если компания маленькая, то CPO по сути будет единственным менеджером продукта, а роль — это просто красивое слово.

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

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

Здесь тоже существуют разные интерпретации, но мы обратимся к слову Senior. Когда видишь такую приставку хочется спросить senior to whom. Очевидно, что в погоне за блестящими значками и бантиками просто опытных менеджеров продукта стали называть Senior, но если следовать логике, то старший менеджер продукта появляется, когда есть младшие.

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

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

Здесь мы подходим к классическому квартету Product Owner / Product Manager / Product Manager / Business Owner и разделению ролей.

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

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

Менеджер проекта отвечает за реализацию бэклога в оговоренный срок и бюджет.

Отвечает за результаты капиталовложений в разработанный продукт перед советом директоров/акционерами.

Владелец продукта и бизнес-оунер — это роли, а менеджер продукта и менеджер проекта это еще и профессии.

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

Business Owner редкая роль — поскольку именно Product Owner обычно выступает со стороны бизнеса. Но в некоторых ситуациях, которые должны существовать только в больном воображении, а не реальности, появляется еще один уровень абстракции в виде человека который отвечает за продажи.

Недавно Scrum Inc стала продвигать альтернативное видение роли Product Owner как человека ответственного за тактическую реализацию стратегического видения менеджера продукта. Я буду придерживаться оригинальных идей Agile, а для еретиков приведу цитату преподавателя Гарвардской школы бизнеса: “I’ve trained dozens of teams who are using SAFe and I have never seen this work well.”

Красивое название для менеджера продукта. Иногда применяется в ситуации когда в продукте есть несколько менеджеров продукта и кто-то из них чуть главнее других.

Красивое название для менеджера проекта. Иногда применяется, когда в продукте есть несколько менеджеров проектов и кто-то из них чуть главнее других.

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

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

Долгое время я считала, что комьюнити-менеджер – это человек, который общается с аудиторией в соцсетях и блоге компании. Проводит конкурсы и другие активности, которые делают аудиторию ближе к бренду. Вызывают у нее симпатию. И все это в конечном счете сказывается на продажах. Чтобы узнать больше информации о комьюнити-менеджменте, я связалась с Федором Скуратовым, основателем Российской Ассоциации комьюнити-менеджеров (RCMA). Примерно после второго вопроса я поняла, что мои представления о КМ очень поверхностны :-) В общем, читайте интервью, и вы узнаете, кто такой комьюнити-менеджер и почему его ни в коем случае нельзя путать с SMM-щиком или маркетологом.

Да, с удовольствием.

Давайте тогда начнем с первого вопроса, который вам задавали, наверное, миллион раз. Что такое комьюнити-менеджмент и зачем он нужен бизнесу?

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

А как это может помочь бизнесу? Есть такое мнение, что комьюнити-менеджмент способствует увеличению продаж. Что вы можете сказать по этому поводу?

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

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

А я не могу создать сообщество на моей площадке? Разве для этого как раз-таки и не нужен комьюнити-менеджер?

Можно. Нужен :-) Но это часто экономически не оправдано. А главное – очень многие пытаются это сделать, построить сообщество, не понимая, какие бизнес-цели они преследуют. Это инструмент, а не самоцель. То есть, понятно, например, зачем Microsoft создали сообщество. Они сильно зависят от этого. Аудитория многих продуктов Microsoft – гики, программисты, разработчики, продакт-менеджеры, которые много между собой общаются, и компании важно все заземлять на себя. Чтобы люди просто не выпадали из этой экосистемы. Поэтому они устраивают конференции и так далее.

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

То есть какой-нибудь компании, которая продает пластиковые окна, нет смысла создавать сообщество?

Абсолютно никакого. Никакого. Смысла. Нет.

Честно? Вы сейчас перевернули мое представление о комьюнити-менеджменте :-)

Понимаю :-) Часто так случается. Комьюнити-менеджментом занимаются почти все так или иначе. Потому что, например, внутренние коммуникации в крупных компаниях – это тоже комьюнити-менеджмент. Все, что связано не с зарплатой, а с мотивацией сотрудников, – это комьюнити-менеджмент на 100 %.

Но если все-таки перенестись в сферу интернет-маркетинга. Допустим, отработка негативных отзывов. Это работа комьюнити-менеджера?

Тут зависит от масштаба бизнеса. Комьюнити-менеджмент – это четыре уровня:

Более подробно о каждом уровне комьюнити-менеджмента смотрите на видео:

В последнее время стало очень модно на проекты, связанные с криптовалютами и ICO, брать комьюнити-менеджеров. Такое модное поветрие. Комьюнити-менеджер очень разными вещами часто занимается. Самое ужасное, когда берут SMM-щика и называют его комьюнити-менеджером. Но в принципе, с точки зрения повседневных обязанностей, главная задача комьюнити-менеджера – общаться. Очень много общаться.

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

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

Я поняла, что у КМ широкий спектр обязанностей, но я не совсем понимаю, какие именно. Можете по пунктам перечислить самые важные?

Комьюнити-менеджер отвечает либо за часть системы, любо за всю. Зависит от того, на что его наняли, и так далее.

Может быть, на каком-то примере разберем? Возьмем существующую компанию…

А их очень много. Допустим, в игровых компаниях комьюнити-менеджер отвечает за коммуникации с аудиторией, в первую очередь. Начиная с контента и заканчивая личными переписками с саппортом и обратной связью: почта, модерация чатов и так далее. Если брать комьюнити-менеджера, например, в компании-застройщике, он очень много занимается работой с негативом, офлайн-встречами. Главное – суть работы. Суть работы – знать своего клиента (know your client).

Допустим, у нас есть клиент. Он хочет продвигаться в соцсетях. У него есть SMM-щик…

И нет, ему не нужен комьюнити-менеджмент. Ему достаточно просто взять SMM-щика с хорошо подвешенным языком. Это уже комьюнити-менеджмент как скилл общения и скилл сбора обратной связи.

Что лучше: взять комьюнити-менеджера со стороны или переквалифицировать сотрудника компании, который уже в теме?

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

Где можно этому научиться? В вашей школе?

Если вам нужны базовые навыки (совсем базовые, на уровне, как работать с негативом), есть курсы Влада Титова. Но там уровень прям… У меня идеологические разногласия с Владом, но, наверное, для нулевого уровня он сгодится. То есть, при наличии хоть какого-то опыта это уже нерелевантно.

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

Влад на нулевом уровне действует, на уровне КМства как скилла. Дальше он даже не забирается.

А вы более системно к этому подходите?

Можете чуть поконкретнее?

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

Понятно. Федор, хотела задать вам вопрос, не знаю, насколько он будет уместен. Может быть, вы какими-то техниками поделитесь? Теория теорией, но хочется чего-то практического.

10 главных техник комьюнити-менеджера:

Долгое время (первые полгода) основным поставщиком контента должен быть основатель сообщества. Остальные со временем подтянутся.

Каждого участника надо приветствовать. Лучше — не сразу. Best practices from SaaS: через 1-2 дня после регистрации от сервиса приходит письмо от комьюнити-менеджера, который интересуется мнением о продукте и предлагает ответить на вопросы. Само собой — это автоматические письмо. На Facebook можно добавить участника в друзья и написать ему ЛС. Не ленитесь это делать.

У любого сообщества, в том числе профессионального, есть три повестки:

Нехватка любого элемента — сигнал, что сообщества нет — или оно умирает. Более детально — в статье о циклах развития сообществ.

Вопросы в посте ничего не значат. Mention (упоминания) тех, кто может высказаться по теме, провокационные темы или радикальные взгляды — вот хорошие способы вовлечения. Их тысячи — и их надо комбинировать.

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

А что по поводу KPI комьюнити-менеджера? Как они устанавливаются?

Это зависит от компании и, более того, работа комьюнити-менеджера часто не имеет KPI. Это сильно зависит от того, какие задачи ему навесили. Подо что подписался, то и делаешь. Но в принципе комьюнити-менеджером неверно называть медийщиков: SMM-щики и так далее. Это просто исключено. Это разные вещи. Создается путаница.

Это важно! Комьюнити-менеджер – это менеджер. Не маркетолог. Это ключевое различие. Комьюнити-менеджеры занимаются менеджментом. Не маркетингом. У нас это часто путают. Вообще не понимают, в чем разница между маркетингом и менеджментом в том, что касается соцсетей. Огромная! Менеджер управляет. Маркетолог продает.

Они консультировались у вас?

Федор, можно вопрос немного провокационный? Я про Влада Титова знаю уже давным-давно, знаю, что он книгу написал, видео его смотрю, на паблик подписана. А про вас узнала буквально недавно. Это мой косяк?

Нет, все очень просто. У Влада широкое вещание, охват большой, а я предпочитаю свою деятельность концентрировать на практиках и на тех, кто понимает, потому что у всех разный фокус. Я занимаюсь консультированием КМов, а не обучением того, как быть КМом всех подряд. У нас просто разные уровни.

Как вас тогда ищут клиенты? Как вы продвигаете себя?

Сарафанка. Исключительно сарафанка. Я не занимаюсь рекламой. У меня выходит по рекомендациям.

Да, тоже вариант.

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

У всех просто свои способы. Кому надо, тот найдет.

Спасибо.

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

Кто главный в IT-компании?

Главенствующую роль в IT-компании занимает CEO (Chief Executive Officer) или Owner. Это главный исполнительный директор, высшее должностное лицо компании. Он определяет общую стратегию предприятия, принимает решения на высшем уровне и выполняет представительские обязанности.

СЕО управляет не только внутренней средой компании, но и взаимодействует с внешней. Внешняя среда — это акционеры, инвесторы, органы государственной власти, поставщики, банки и т.д.

Главный исполнительный директор принадлежит ко второму уровню управления — административному, то есть непосредственно управляет компанией. К первому уровню управления относится Совет директоров, который выбирают на общем собрании акционеров данной компании.

За разработку новых сервисов или продуктов отвечает СТО (Chief technology officer). СТО или Главный технический директор управляет процессами разработки в проектных командах, руководит обучением и повышением квалификации сотрудников, а также внедряет и поддерживает различные процессы внутри компании.

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

Обязанности CTO могут сильно различаться в зависимости от размера и типа компании (сервисная или продуктовая). В общем случае, chief technology officer — это исполнительный топ-менеджер, чья должность предполагает стратегическое решение научно-технических вопросов в организации и не предполагает участия в разработке конкретных задач и проектов.

Виды разработчиков над проектом

Junior Developer
Работники уровня Junior — это новички без практического опыта, которые устраиваются в компанию, чтобы его получить. Работники уровня Junior получают маленькую заработную плату, но это компенсируется получением опыта.
Junior работают в основном над легкими проектами под присмотром ментора.
Основное требование для такого уровня — способность самостоятельно выполнять технические задачи.

Developer или Middle Developer
Программист или Developer или Middle dev — это человек, ответственный за качественное и своевременное исполнение разработки информационно-программных систем, основанных на применении современных программных технологий. Программист выполняет задачи по написанию и базовому тестированию порученных ему компонентов системы. Поддерживает Junior разработчиков, занимается как архитектурой, так и модульной реализацией проектов, производит реализацию работоспособности прототипов. Кроме того, постоянно занимается самообразованием, понимает алгоритмы, процессы разработки программного обеспечения. Обладает знаниями в следующих областях: языки разметки, понимание технологии web-серверов и серверов приложений, знанием клиентских и серверных технологий, работы браузера, СУБД, операционных систем, офисных пакетов, сред разработки, профильных языков программирования, технического английского.

Senior developer
Ведущий программист – человек, отвечающий за качество и своевременность работ по разработке информационно-программных систем, основанных на применении новейших программных технологий. Обладает глубокими, структурированными знаниями и работает внутри проектной команды, совершенно не имея необходимости контактировать с представителями менеджмента заказчика. Выполняет такие работы, как детальное проектирование и создание спецификаций проектов, полностью контролирует и зачастую и самостоятельно выполняет проектирование мелких проектов и внутренних под-проектов (модулей), занимается программированием и базовым тестированием компонентов. Как правило, имеет законченное высшее образование, реже незаконченное, стаж от 3х лет в качестве developer, умеет комментировать программы, не прибегая к использованию словаря. Также ведущий программист должен разрабатывать документацию, свободно общаться на английским языком, владеть методами и инструментами анализа и проектирования, Software Engineering Process, языками разметки, глубоким пониманием клиент-сервер технологии, работ браузера, web серверов, серверов приложений, БД, ОС, офисными пакетами, может контролировать других разработчиков и ставить им задачи.

Кто работает над проектом, кроме разработчиков?

Помимо разработчиков, над проектом работают и другие специалисты, в частности, тестировщики ПО и специалисты по обеспечению качества (Quality Assurance Engineers, QA-инженеры). Границы между этими двумя должностями смазаны, однако различия все-таки есть.

Задача тестировщика — проверить готовый продукт на несоответствие требований и наличие ошибок и задокументировать найденные ошибки. А задача QA-инженера — не только непосредственно тестирование. Он планирует тестирование и анализирует его результаты, ищет способы улучшить процесс разработки ПО и предотвратить дефекты.
Таким образом, тестирование — это лишь узкая специализация в рамках QA. В компаниях с небольшим штатом QA-инженер может выполнять функции тестировщика, а в крупных компаниях эти должности часто разграничены. У QA-инженеров, как и у разработчиков, есть своя иерархия: Junior QA, Middle QA, Senior QA и т. п.

Также в проекте могут быть задействованы технические писатели (Technical Writers, Technical Authors). Они создают различную документацию, как внутреннего назначения, так и для конечных пользователей ПО (руководства пользователя, справочные системы и т. п.). Технический писатель должен, с одной стороны, хорошо владеть языком, с другой — разбираться в технической стороне вопроса.

Руководители, координирующие процесс

Разумеется, в каждой команде должны быть руководители, координирующие процесс. Существуют различные руководящие IT-должности, в их числе Project Manager, Software Architect, Team Lead, Tech Lead.
Project Manager (менеджер проекта) осуществляет управление проектов в целом: расставляет приоритеты, планирует выполнение задач, отвечает за организацию работы в команде, оперативное решение проблем, коммуникацию с заказчиком и т. п. По сути, менеджер проекта — не техническая должность, но знание технических нюансов необходимо, без него нельзя эффективно организовать рабочий процесс. Многие PM в прошлом были тестировщиками или разработчиками, а потом решили уйти в управление. Но случается и по-другому: на должность Junior PM берут человека без технического образования, зато с опытом менеджмента, и обучают его техническим нюансам.

Если организационная деятельность проектного менеджера направлена на менеджмент, то Software Architect (архитектор ПО) координирует именно техническую сторону процесса. Он должен иметь целостное видение будущего продукта и на его основе уметь находить оптимальные решения как с точки зрения команды, так и с точки зрения заказчика. В архитекторы ПО обычно уходят старшие/ведущие инженеры, которые не хотят отдаляться от технических задач.

Должности Team Lead (руководитель команды) и Tech Lead (технический руководитель) — это нечто среднее между проектным менеджером и архитектором. Оба выполняют и менеджерскую и техническую роли. Однако у тимлида акцент сделан на менеджмент (коммуникацию и организационные вопросы), а у технического лидера — на техническую часть.
Обычно должности Team Lead и Tech Lead занимают ведущие разработчики, которым пришла пора двигаться дальше по карьерной лестнице, но они не могут определиться, что их привлекает больше — менеджмент или техническая сторона. После некоторого времени работы в должности Team/Tech Lead специалист становится либо менеджером проектов, либо архитектором ПО.

Еще одно отличие тимлидов и техлидов от проектных менеджеров и архитекторов ПО состоит в том, что зачастую тимлиды/техлиды координируют не весь проект, а лишь какой-то его аспект. К примеру, QA Tech Lead руководит группой QA-инженеров и отвечает непосредственно за тестирование и обеспечение качества.

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

Ряд должностей, которые не связаны с разработкой, например, менеджеры по продажам (Sales Managers) и рекрутеры (HR). Человек, работающий на такой должности, может не иметь технического образования, но при этом должен разбираться в технической стороне вопроса настолько, насколько это необходимо для эффективного выполнения обязанностей.

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

Читайте также: