×

Карта карьеры

Провожу с командой post-evaluation беседы, и часто приходится отвечать на один и тот же вопрос, в разных вариациях возникающий почти каждый раз: «Что мне делать, куда развиваться? В каком направлении? Какие скиллзы стоит приобрести, чтобы пройти на следующую ступеньку карьерной лестницы?»

Чтобы ответить, составил карту переходов по должностям в IT — заодно и сам систематизировал свои представления.

Конечно, карта довльно условная. Во-первых, что там — в правом нижнем углу (где CTO, CIO и прочие страшные аббревиатуры) — знаю только понаслышке, и могу ошибаться. Во-вторых, градации разные у всех компаний: одни пользуются системой Junior — Middle — Senior, другие — цветовой дифференциацией поясов, третьи — нумерованными бендами; смысл, впрочем, от этого не меняется. Тем не менее, если мне подскажут изменения и дополнения к карте — буду очень благодарен, и изменённую версию обязательно расшарю :)

Саму карту вы найдёте ниже, а сейчас хочу прорекламировать сервис, который позволил мне её нарисовать. Несмотря на странное японское название, Cacoo — cacoo.com очень хорош. Позволяет рисовать диаграммы онлайн из браузера (и даже совместно над ними работать), экспортировать диаграммы в разных форматах и всё такое. Бесплатная версия имеет небольшое количество ограничений, а платная — весьма вменяемую стоимость.

P.S. Реклама не проплачена; наоборот, уговорил своё начальство купить team-подписку. Просто сервис действительно удобный.

(для просмотра картинки в исходном разрешении кликните на ней)

Расшифровка сокращений:
QA — Quality Assurance, Специалист по качеству
TW — Technical Writer, Технический писатель
BA — Business Analytic, Бизнес аналитик
CIO — Chief Information Officer, Директор по информационным технологиям
CTO — Chief Technology Officer, Технический Директор
CEO — Chief Executive Officer, Директор компании

UPD: Проапдейтил диаграмму, добавил System Analyst и дорисовал несколько карьерных путей. Переименовал Junior BA в Requirements Analyst. Добавил линейку дизайна.
Если вам не показывает обновлённый рисунок — очистите кеш браузера и перезагрузите страницу.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




167 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

МИР
хорошая схема, видно ее TW писал
я вот вижу как TW становиться UX а потом BA
и lead может быть только у DEV и QA
нет PO, убрано половину ролей SA прилеплен сбоку....
прежде чем писать такие схемы надо хоть немного начать разбираться в материале...

Но как рекламам сервиса круто :-) жаль что не заплатили....

Нема DevOps... додайте, будь-ласка

некропост, но все же.
нужно бы добавить линию для техподдержки (support)

начнем с того, что padaWan. W.

подрожим тем, что раз уж Automatization, то и Administratization должно быть.

Вообще-то конечно Automation правильнее. Но и Automatization вполне допустимо, порукой чему 7+ миллионов результатов, находимых гуглем по запросу «automatization QA»

я больше не буду задротить, честно!))

ОК, спасибо, не знал. Запомню :)

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Меня вот интересует, когда уже в этих «картах карьеры» начнет появляться позиция configuration manager? Пусть эта должность и не так востребована как остальные специализации, но присутствовать в подобных классификациях обязательно должна. Необходимость уже давно назрела. Кроме того, позиция конфигурейшн менеджера может стать отличной возможностью дальнейшего развития и профессиональной самореализации если вдруг возник вопрос «а куда дальше?». Не столь важно что для многих работодателей/компаний не совсем актуально (вакансии открываются не так часто). Более важно показать, что существует еще одно обширное направление, в котором можно и нужно развиваться.

Дело в том, что очень часто configuration manager — это не отдельная позиция, а роль, которую по совместительству выполняет кто-то из разработчиков или тестировщиков.

кто-то из разработчиков
про разработчиков согласен, но ...
или тестировщиков
Никогда не приходилось наблюдать как тестировщик настраивает работу системы контроля версий, пишет билд-скрипты, настраивает работу continuous integration сервера и следит за зависимостями.

Кроме того, разве UI developer, UX developer и тому подобные «позиции», которые присутствуют на диаграмме — это не такие же роли, которые ситуативно выполняются в большинстве команд на интуитивном уровне? Что уж говорить, если очень часто project manager — это скорее роль, нежели позиция? Поэтому мне кажется, что ваш аргумент не очень состоятелен.

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

  • version control management
  • continuous integration management
  • build management
  • deployment management
  • dependency management
  • merge management
  • release management

Я ни в коем случае не собираюсь вас переубеждать, просто по каким-то причинам я очень часто сталкиваюсь с сопротивлением вроде вашего. Дескать, configuration management — это так, эпизодическая никому не нужная функция в то время, как это уже давно (на западе по-крайней мере) стало отдельной инженерной дисциплиной.

просто по каким-то причинам я очень часто сталкиваюсь с сопротивлением вроде вашего. Дескать, configuration management — это так, эпизодическая никому не нужная функция в то время, как это уже давно (на западе по-крайней мере) стало отдельной инженерной дисциплиной.

Так я и не спорю, что это отдельная инженерная дисциплина. Просто для большинства вышеперечисленных пунктов существуют готовые наработки и решения-раз, и в большинстве проектов достаточно весьма легковесных и неформальных подходов к управлению версиями, билдами, зависимостями и т.п. — два. Так что full-time configuration manager зачастую не нужен из исключительно прагматических соображений.

Это разве что представить гипотетическую организацию, которая занималась бы исключительно медицинскими, аэрокосмическими и военными проетами — вот там, да, наличие подобной full-time позиции может быть вполне оправдано.

Сергей, а из кого Configuration Managers вырастают? Из админов? И какие скилзы для этого нужны?

Просто ни разу не видел ни одного CMа живьём :)

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

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

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

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

Фигасе, впервые вижу выделенную позицию Configuration Manager. Везде где я работал, эту роль разбивали между engineering manager и IT департаментом. Первый отвечал за процессы, вторые за реализацию.

квадратно-гнездовая карта.

думаю, что траектория творческой личности в IT напоминает либо броуновское движение, либо кривую по диагонали данной roadmap))

хотя, да, — неплохая схема.

на ней ранний старт с позиции разработчика на руководящую позицию означает ранний финиш, это спорно.

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

До некоторой степени, чем позже стартуешь, тем резвее набираешь нужные навыки — просто за счёт жизненного опыта.
получается, топливо опыта необходимо для нормального взлёта ПМ-а.
в нормальной компании.
в наших реалиях возможны варианты...
зы:
в бодишопах, распиловках и маленьких карманных рабовладельческих конторках
ньюба-ПМ-а могут держать за руки, клевать мозг и требовать результатов.
потом — сломать крылья и сказать: «ну вот, видите — из хорошего дева получился никакой ПМ»
собсно, я о чём... кроме запаса топлива-опыта ещё важно выбрать правильную стартовую площадку и правильное время)) isn’t it?

Якщо ви шукаєте перелік компетенцій для розвитку своїх працівників — зверніть увагу на Європейську рамку компетенцій у сфері ІКТ — www.ecompetences.eu — є версії англійською, німецькою та російською.

ОК, спасибо.

Читаю — выглядит интересно.

Are they IT? And is really differ to be sales in IT and in non-IT?

И да, куда вы во всех этих постах про jun/mid/sen дели pnincipal/associate?

Или senoir это предел мечтаний? =)

Почти одно и тоже. Чисто по традиции Associate выше, но щас эту традицию забыли и лепят как попало :)
Principal Developer Salary например :)

Привет, братья.
Пять копеечек по пункту Design на карте:
— Чем в этой схеме web designer отличается от ui designer и ui designer от ux designer?
— Куда подевался interaction designer? Почему нет senior?

Спасибо.

Макс, расскажи плиз, кто такой interaction designer. Лучше со ссылками.
Web designer — это верстальщик со знанием фотошопа. Человек, который дизайнит сайты и выдаёт готовую вёрстку.

UI дизайнер — дизайнит пользовательский интерфейс, настольный или мобильный. UX — дизайнит User Experience, т.е. делает то же самое, но на более высоком уровне.

Юра, ну раз мы тут рисуем красоту правильную, то надо бы учесть пару моментов. хотя бы в виде абстрактной сказки :)
лентяй получает ссылку :) о, я еще html помню, шото будет :)

По поводу твоих объяснений — они едва ли годные :(
Терминология — злая сyка, но я попробую:

Web designer — высокоуровневый дизайнер
На сегодняшний день ближе всего к должности Graphic designer ( в традиции Cogniance, например, Art designer — Коля Апостол яркий пример. привет ему) — занимается преимущественно кожурой (графикой, спрайтами етк.) Близок к верстальщику, в лебедевской традиции — технологу (html/css/js/etc) по долгу службы.

IxD — низкоуровневый дизайнер
Старообрядники до сих пор называют их UID, забывая при этом, какой век на дворе, и что мы давно работаем с динамикой, а не статикой (читай ссылку вверху).
Владеет смешанным стилем IA/WA (web architecture). Результат работы — вайрфреймы (UI) / динамические прототипы + библиотеки паттернов (IxD).

UXD = Т-образный спец — редкий зверь у нас. в сферическом идеале — широкополосный специалист, который целиком закрывает собой вопрос дизайна в плане качества конечного продукта включая края — маркетинг и девелопмент — выторговывает нужный feature list не смотря на бюджеты, сроки и месячные. Тоесть если продукт допустим финансово успешен — этот человек отвечает за все остальное, с чем приходится столкнуться пользователю. Может по глазам определить на сколько ты ему соврал по срокам и найти элегантное решение практически любой проблемы. Владеет скилами предыдущих двух ребят в совершенстве. По поводу UXD хорошо написал недавно Andy Budd.

зы: в этом смысле UX дизайнера нельзя назвать более высоким или более низким — он широкий дизайнер — на сегодня самый востребованный. именно это заставляет всех дизайнеров судорожно лезть в профиль линкедина и менять свою должность на магические IxD/UXD. Увы, оправдывают этот гордый тайтл <2% дизайнеров

Надеюсь, длинно но понятно :)

О! Теперь карта стала намного лучше: в стрелочках х... разберешься :)
Более конструктивно:
По уровням можно поспорить что:
— системный аналитик выше лида (хотя я бы не стал);
— дизайнеры начинаются с уровня аналогичного джуну. ИМХО на пол-ступеньки выше. Нет верстальщиков (часто верстальщик и дизайнер — это разные люди) как таковых.

— нет перехода от Дев и КуА к УКсу.

Respect! Отличная карта =) Наглядная =)

длавное padaVam не показывать :)

ждем читы на эту систему прокачки!

poweroverwhelming

:D, да с читами было б гораздо лучше!

Отличная карта, Юрий. Спасибо!

Но почему на ней нет службы HR :) ?

Наверное, потому, что HR != IT?

Проте в Luxoft таки спостерігається точка біфуркації dou.ua/...s/new-ceo-luxoft-ukraine

Анна, а можете рассказать, где на этой карте можно разместить HR?

мне очень понравилась эта карта!! но она ничего не обьясняет к сожалению в плане почему кто то растет а кто то не растет. Ведь каждая компания отличаеться. Чтоб обьяснить куда рости или почему в той или иной компании вырости не удасться или наоборот будет быстрый рост схемка должна показывать что то более динамичное, а не статическую картинку. Иногда очень важны личные предпочтения. Например в компании или тиме могут рости например только люди выского роста или маленького или модельной внешности, по хобби, политическим убеждениям и прочее. Ведь решает вырос или нет не схемка а конкретный человек или группа людей...
Кроме того может быть разряд (демотивация) у любого из этих ролей (как результат оскорбления, несправедливая оценка performance — а и т.д.).

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

Алексей, это карта. Она объясняет, в каком направлении идти от точки «здесь и сейчас» до точки «там и тогда».

Здесь непременно будут материалы о том, как расти и что для этого делать. Но — описать это я могу только для своего тима или похожего. Как расти в тиме, где продвигают только людей высокого роста и модельной внешности — я ХЗ :)

:-)
буду ждать этих материалов и с удовольствием почитаю.

По бизнес-аналитикам немного каша, по-моему. Во-первых, что значит junior BA? БА — это уже сеньорная позиция, «новобранца» никто не пустит с бизнесом общаться, максимум — за БА документировать требования (это если agile не практикуется). Я бы разделил на functional analyst (requirements analyst) и business analyst.

Ну и миграция в ПМ тоже как-то надуманно выглядит, есть и архитекторы и аналитики, получающие куда больше среднего ПМ (я не говорю о деливери менеджерах аутсорс-проектов в 50+ голов, получающих премиальные в виде процента от бюджета).

А развиваться БА всегда есть куда, только это не ИТ, а предметная область. Полученные знания можно конвертировать как в более высокий уровень общения с клиентами (участие в steering committee и формировании долгосрочного бэклога ), так и в пре-сэйлы для аутсорс-проектов, когда важно показать ширину охвата отрасли, мол, у компании есть достаточная бизнес-экспертиза для managed delivery вместо тупого аутстаффинга.

Junior BA — ИМХО и есть Requirements Analyst, конечно его никто к бизнесу не пустит — пусть сидит и документы пишет, учится.

Миграция в менеджмент надуманно не выглядит, и происходит не только (и не столько) из-за зарплат. Просто много общих функций — хороший PM в какой-то мере всегда аналитик, а хороший BA знает и умеет менеджмент.

Я ж и говорю, junior — это не BA :) То, что в компаниях такая позиция встречается, говорит только о непонимании менеджерами и/или рекрутерами словосочетания «business analyst». Это как junior team lead примерно.

Насчет миграции — я не говорю, что это невозможно (скорее, наоборот), просто действительно хороший аналитик больше нужен на своем месте, чем в менеджменте (действительно хорошего БА нанять очень сложно), Ну, и многим (мне, например) неинтересен people management. Просто банально скучно этим заниматься, а это некислая такая часть работы project/program/delivery manager-а.

ОК, переименовал в Requirements Analyst :) Теперь будем знать, как это правильно называется.

Что же до миграции — то сложность работает в обе стороны: хорошего БА трудно нанять, и хорошему БА трудно найти хорошее место, особенно в случае наступления каких-то кризисов. Менеджерских должностей тупо больше, вот некоторые и уходят. А кому-то просто нравится работать с людьми :)

До переименования лучше было. Я себе не хочу представлять круг обязанностей analist-а ;-)

Что касается хороших мест — чем больше крупных аутсорсинг-клиентов, тем больше анализа мигрирует в оффшор. Понятно, что в команде аутстафферов, сидящих на саппорте индусского гуанокода, анализом никаким и не пахнет. А если делать с нуля (или, как минимум, активно участвовать в разработке) крупную систему для инвестиционного банка из первой десятки (а таких в Украине уже, как минимум, три), то там анализа существенно больше, чем кодирования. И учиться нужно постоянно, т.к. готовых специалистов в предметной области можно по всей стране пересчитать на пальцах двух рук (особенно, желающих работать в айти).

Еще в большинстве крупных компаний есть должности Test Manager и Development Manager. Отвечают за соответствующие процессы по компании в целом, иногда привлекаются для решения сложных задач на отдельно взятых проектах.
В Европе часто встречается должность Software Development Engineer in Test (это по номенклатуре МС), или просто девелоперо-тестер. Связано с тем, что на тестировании часто экономят и отдельных людей для этого не держат.

Также бывают Build Manager или Release Manager — думаю, тут всё понятно.

Это всё да, конечно — но боюсь, не для наших украинских реалий. Даже если возникает необходимость в Build Manager или Release Manager — эти функции просто «донакладывают» на кого-то из имеющихся работников...

Подтверждаю. Одно время совмещал работу девелоперо-тестера\автоматизатора и также отвечал за авто сборку билдов, инсталяционные пакеты, CD-browser, апгрейды, апдейты документации. Брать для этого еще одного человека никто бы не стал, это просто экономически не выгодно.

Спс за проделанную работу. Было бы неплохо составить план по изучению технологий и освоению доп языков. Будет конечно сложно воссоздать полную картину и учесть все веяния современного времени, но если получится это будет бомба :) ! Да и темы «что учить и куда податься» пропадут, ну или уменьшатся в разы ...

PS: Одному мне кажется, что Architect с последующим переходом в СТО это уже «божественная сфера» недоступная простым смертным :-D ?

Думаю, не одному Вам. Но, уверяю Вас, это пройдет — просто у Вас еще есть несколько ступенек, которые нужно пройти :) В должности CTO нет ничего божественного. Как говорил Дима Ефименко «директор — это человек, который заслужил право работать оп 16 часов в сутки». И в этой фразе значительно меньше доля шутки, чем может показаться на первый взгляд :)

А план по технологиям врядли получится составить — у всех людей разные стремления, увлечения и интересы. А в технологиях именно увлечения и интересы играют ведущую роль

Кроме того, планы по технологиям очень разные. Скажем, составленный мной план для моей C#/.NET команды точно не подойдёт например Антону.

Хм, похоже меня неправильно поняли. Постараюсь объяснить, что имел ввиду. Я не прошу создать прямую инструкцию к действию, что именно вот так надо развиваться и не иначе. Просто создать дерево, например как в World of Warcraft реализовано talens tree (извините за глупый пример, просто как визуальный пример только это пришло в голову :) ), а какой skill «прокачивать» это уже личное дело каждого.

PS: Или хотя бы напишете свои соображения по развитию в C#/.NET и ASP.NET, думаю найдутся люди кому это будет интересно.

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

Как только что-то будет конкретное — на ДОУ обязательно появится.

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

Очень интересная работа, спасибо!

Могу добавить, что, насколько я могу видеть, TW нередко переходят в QA.

Да, согласен. Добавил стрелочку, сейчас проапдейчу диаграмму.

Для сравнения — дерево должностей из нашего зарплатного опроса: i.imgur.com/ps0TH.png

Открыл рядом, буду сравнивать.

Точно буду добавлять ветку дизайна. Непонятно, что делать с DBA — есть ли у них вообще какое-то развитие?

Директор по базам данных?:) Или менеджер, руководящий работой сисадминов, ДБА и пр., назвать можно по-разному. В наших реалиях это скорее всего СТО.

Вот так прямо из DBA в CTO? Как-то не верится в такой карьерный рост :)

Конечно же есть развитие. Скорей всего по аналогии с Junior, Middle, Senior

По сертификации MS есть целая своя градация специалистов СУБД.
В частности, там:
DBA — Database Administrator.
DBD — Database Developer
BI — Business Intelligence
Database Architect
Это всё должности не в ИТ конторах а на реальных предприятиях. Уже где-то на уровне BI человек получает такие деньги, что никаким TL-PM-SA в ИТ и не снятся.
Но ответственность — сами понимаете, человек отвечает за сохранность всех данных компании.

На реальных предприятиях, не в IT — там всё по-другому. Это понятно.

developer -> SA/BA -> .... ->CxO

думаю тоже возможно

SA — это Software Architect?

и к тому же — не видел ни одного девелопера, ставшего бы BA. ИМХО навыки противоречат друг другу...

Проблема скорее в реалиях нашего рынка: Девы часто получают большую ЗП чем БА (иногда даже большую чем ПМы).
Кстати возвращаясь к пресейлс — девы часто уходят туда.

Почему противоречат? Из девелоперов получаются очень хорошие БА. Как вариант — девелоперы, которым надоело программировать :) Ну и «навыки противоречат...» — вообще странно. Что в работе БА противоречивого для девелопера?

Доки писать, с людьми общаться, ба — это человек человек, а программист — человек цифровая система.

Project Manager — это тоже человек-человек.

Согласен, только не понял к чему это?

К началу ветки.

не видел ни одного девелопера, ставшего бы BA. ИМХО навыки противоречат друг другу...

Противоречий между БА и девом не больше чем между ПМ и девом. Вообще, тема напоминает «аутсорсинг vs продукты». Тут все зависит от конкретных людей, специфики проекта и т.д., поэтому схема может отличаться от компании к компании. Правильнее было бы, как уже сказали, нарисовать 2 ветки (2 схемы) — engineering and management. Менеджмент далеко не всем нужен и интересен, но это не значит, что сеньор девелопер — это тупик.

Алекс, я видел (и сам являюсь) девелопером, который получил BA-навыки, став (или для того чтобы стать) проджектом. Такое бывает, и часто — потому как это апгрейд навыков.
А вот переход из девелоперов в BA — означает приобретение новых навыков с частичным отбрасыванием старых, ибо навыки по крайней мере ортогональны. Поэтому при нашей нехватке девелоперов — такое должно происходить очень-очень редко, ИМХО.

Кстати, отличное название для холиварной статьи «Тупик синьор девелопмента» :)

А вот переход из девелоперов в BA — означает приобретение новых навыков с частичным отбрасыванием старых, ибо навыки по крайней мере ортогональны. Поэтому при нашей нехватке девелоперов — такое должно происходить очень-очень редко, ИМХО.

В целом, согласен, QA -> BA более реально. Но dev -> BA не следует игнорировать, это не так уж редко происходит, но очень сильно зависит от проектов. Думаю, это должно чаще происходить в «продуктовых» компаниях.

Подумал и повспоминал ещё.

Девелоперы таки не уходят в BA, а вот Senior Developer может уйти в Senior BA — таки научившись понимать, чего же хотят заказчики :)

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

Работал в продуктовой компании. Разрабатывали продукт из разряда долгостроев ... 4-5 лет писали и усовершенствовали его. Из основных разработчиков и архитектов никто даже не задумывался о карьере BA, скорее расматривался вариант горизонтального карьерного роста нежели вертикального.

Ну, вот он я: dev->BA. В какой-то момент задолбало работать с некомпетентными аналитиками и понял, что смогу приносить больше пользы обществу, занимаясь бизнес-анализом и требованиями.

Я там уже писал, что при правильном разделении труда и достаточных ресурсах в компании дев растет в тим лид а потом в dev. manager а не в пм. ПМом он тоже может стать конечно, но это утрируя как лесоруб перебрался в сталевары.

я предполагал System Analyst )
в принципе такой переход сам и планирую сделать

Вот системный аналитик — это да, это запросто. Где-то примерно рядом с Архитектором — а оттуда можно и к «сияющим высотам»

И что, люди, которые находятся в одной клетке — получают у вас одинаковую зарплату?

А по-моему это весьма неглупая мысль для менеджера, который заботится о целостности команды. www.joelonsoftware.com/...0000000038.html

Интересная ссылка, почитаю.

Но сам считаю, что зарплата должна соответствовать ответственности человека. Допустим, есть Project Manager, отвечающий за проект из 20 человек, стоимостью больше миллиона долларов. И другой Project Manager, у которого в проекте он один, и стоит проект 20 тысяч долларов. При (допустим) равной квалификации — почему у них должна быть равная зарплата?

При (допустим) равной квалификации — почему у них должна быть равная зарплата?

Возвращаясь к многострадальной теме аутсорса:
А почему их ЗП может отличаться более чем на 20% (число может быть другое).

Все забыли про аутсорс.

С ПМами — проще один отвечает за милион багзо, второй за 20К. А вот что с девами/инженерами (пусть даже лидами/архитекторами)? 2 человека хорошо делают свою работу (на равном уровне), но один на милионном проекте второй на 20-тисячном; как должна отличаться их ЗП?

Если на равном уровне — то никак. Потому что на миллионном проекте таких девов ещё полтора десятка, и ответственность делится на всех.

Вы правда считаете, что у них равная квалификация?

На самом деле интереснее сравнивать не разные проекты — а одну команду. Все Senior Developer получают одинаковую зарплату?

Нет, не все. Потому что есть квалификация внутри ступеньки. Как всегда — кто-то придумывает архитектуру и супервайзит двоих-троих разработчиков, а кто-то пишет код (пусть и самостоятельно и на приличном уровне). А оба при этом — Senior Developers.

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

Смысл в том, что неравенство в ней что-то означает непременно. Скажем, Junior Developer ВСЕГДА получает меньше, чем просто Developer.

... в рамках одной взятой команды/компании

Да, конечно. Как и почти всё, о чём мы здесь говорим :)

Менеджерская иерархия имхо неправильная. ИМХО правильный следующий рост:
team lead -> engineering manager, development manager
BA -> product manager

project manager -> program manager

мы (дизайнеры) бываем разные :)

Татьяна, а может быть Вы расскажете о карьере дизайнера?

Теоретически я слышал об UX-дизайнерах, например. Но на практике обычно в команде максимум один специалист-дизайнер, который умеет запускать фотошоп :) - ну и на все руки мастер: и веб, и логотип, и картинки для презентаций, и баннер на флеше... и куда и как расти?

Теоретически я слышал об UX-дизайнерах, например.
UX к дизайнерам имеет такое же отношение как и к Дев или КуА или к ПМ (продукт) — это отдельная специализация. Специалистов очень мало, и я к сожалению не встречал контор в которых бы понимали что такой человек нада, а не просто Куа/дизайнер/ПМ с доп нагрузкой.

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

Так вы УКс или УИ-дизайнер — это очень разные специальности.

я два в одном :) была УИ. теперь УИКС

Да, надо бы дизайнеров добавить.
Что-нибудь типа:

Junior Designer, потом может перейти либо в Web Designer, либо в UI Designer. Web Designer может уйти в программисты, а UI Designer — дорасти до UX Designer и потом двинуться в сторону BA?

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

Татьяна, а разве мобайл и десктоп — это не разновидности UI?

С электронным оборудованием — всё-таки сейчас для украинского IT слишком экзотическая сфера. Я в Харькове всего пару таких компаний знаю, и слишком далеки они от айтишных тенденций.

Веб, мобайл, десктоп это специализации (можно сказать и разновидности) которыми часто занимаются разные люди.

Электронное оборудование, ambient intelligence — это современные мировые тренды, которые со временем дойдут и до нас.

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

А вот веб — разновидность слишком частая, чтобы её игнорировать, да к тому же требующая отдельных навыков (HTML/CSS, а зачастую — ASP.NET/PHP).

Проапдейтил рисунок, добавил дизайнеров.

Здорово! Спасибо :)

Парочка комментариев по переходам между орбитами. В UI/UX кроме дизайнеров приходят еще из технических писателей (яркий пример Джеф Раскин и его детище Макинтош), из тестировщиков и девелоперов (джуниоры или мидл).

ОК, логично, завтра дорисую. iPad всем хорош, но флеш на нём не работает :)

да. еще веб-дизайнеры, читающие правильные книги вырастают в информационных архитекторов (IA)

А можно подробнее рассказать об IA? Кто это такие, что они делают? Может, какие-то ссылки?

Не могу не отметить Bigmir, где еще в 2007 (то есть четыре! года назад) было не только это понимание, но и отдельный UX-отдел, в котором было 4 человека.

Класс, будем надеяться что это станет нормой (может уже стало но я не вижу).

ну до нормы еще расти и учиться. причем всем. и дизайнерам, и менеджменту :)

Есть фирмы, которые UX-дизайном профессионально занимаются. Мы, например, работаем с turumburum.com

УКс — это не только дизайн — это еще и некоторое понимание пользователя. Например дизайн «бухгалтерии»: Для профессионального бухгалтера одни интерфейс, для домашнего использования другой. И разница не только в текстах, но и в подаче информации. То есть мне в домашней бухгалтерии не надо экселивских листов, а надо пару полей получил/потратил/дата. А профессиональному бухгалтеру нужна форма с кучей стандартных полей (расположенных в *правильном* порядке).

С технической стороны и фотошоп по-разному открыть можно. И чтобы адекватно тот же сайт покрасить надо понимать возможности и ограничения технологии. Расти можно в менеджерском направлении и в техническом/технологическом.

Вы ничего не понимаете в техническом росте. С.. — это не технические специалисты, к сожалению уже.

Андрей, с чего Вы взяли, что я ничего в этом не понимаю? Аргументы?

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

Есть такое, что смущает в этой диаграмме. В частности, тупиковые ветви. Например, по линии Developer есть развитие вплоть до высоких Management позиций. ОК, тогда идем дальше. QA Lead и Senior Automatization QA. Что им-то делать? Тупик? Так нет же вроде... Также и касательно других позиций.

Чего, как мне кажется, тут радикально не хватает, так это представления того, что есть две принципиально разные ветви развития — Engineering и Management. Сейчас у вас представлено, что только став классным Engineer есть дорога в Management. В реальности же это не так, потому как это очень разные наборы навыков и далеко не всякий хороший engineer станет хорошим manager и наоборот. Итого мы имеем, что есть два глобальных пути развития, между которыми возможны переходы в определенных позициях, и есть прямые переходы в рамках выбранного пути. Лиха беда начало :)

QA Lead и Senior Automatization QA. Что им-то делать? Тупик?

Я так понял что указаны минимальные уровни перехода.

Может и так, но из Automatization ветки нет переходов дальше вообще, только вертикально, а это тупик. Как прапорщик и старший прапорщик.

Сейчас у вас представлено, что только став классным Engineer есть дорога в Management.

Я так понял что не совсем. Верхушка — это всякие СхО. И в принципе так оно и есть.

По поводу QA Lead — исправил, добавил переход в Project Manager, сейчас попробую перезалить диаграмму. A Senior Automatization QA... боюсь, это и впрямь тупик — в смысле, двигаться дальше сохраняя все наработки своей ветки, практически некуда. Только полностью или частично меняя специализацию.

Что же касается двух разных ветвей развития... Говорят, на западе в крупных компаниях это так и есть. Хотя и там стараются продвигать программистов в менеджеры. А в украинских реалиях Engineering путь развития очень быстро заканчивается :(

Не могу ручаться на 100%, но мне кажется, что automatization qa все-таки должны быть подветкой QA, и иметь возмоность перехода на middle developer или вроде того (чего на практике практически не может general qa), благо уровень навыков к тому времени уже не малый...

Хм. Надо бы у QA поспрашивать. Пока что живьём такого перехода не видел, а вот обратных примеров — разработчиков в тестировщики/автоматизаторы — много.

Хорошему тестировщику автоматизатору нет смысла переходить в девелоперы.
Оглянитсь вокруг, сколько вы знаете хороших програмистов, а сколько хороших автоматизаторов?

Также добавлю что «хороший тестер получает больше чем <плохой> програмист» ;-)

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

Алексей, мы просто усиленно хантим сейчас. Ищем и девелоперов, и QA.

Да, на диаграммах ЗП указано другое. Но вот именно переманить (а по-другому сейчас даже миддлов нигде не возьмёшь) QA стоит дороже.

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

Может быть, например, вы не умеете хантить.

Да ну? Вот это новости, оказывается мой путь развития БЫСТРО закончился. А можно с этого места по-подробнее?

Ты, по-моему, уже в менеджеры перешёл, пусть даже и в программирующие?
Но ОК, пусть это Engineering. Что может быть в твоей карьере следующее за Senior Java Software Engineer? И что после него?

Вполне возможно, я чего-то не знаю :)

Ну был я начальником отдела, ну был менеджером проекта. Это все мелочи — важно, что я не менеджер, а вполне себе SJSE.
Что дальше? Ну есть брать классику, то есть fellow. Вряд ли это появится у нас быстро, но появится. И я когда-то хотел им быть. Сейчас мне совершенно не интересны погоны и звания. Мне интересен характер работы, горизонты ответственности и размер компенсации. А там хотите назовите CTO, хотите — младший помощник старшего дворника.

К чему спич — есть уровни компетенции, которые можно развивать бесконечно. И мне почему-то кажется, что SJSE или просто Senior Sofware Engineer — один из них.

То есть карьера остановилась (дальше двигаться некуда), но развивается компетенция в рамках текущей должности. В результате чего повышается трудность и сложность задач, которые ты решаешь, растёт ответственность — и соответственно растёт и компенсация.
Т.е. вместо карьерного роста идёт рост компетенции. Так?

И кстати, с концепцией fellow я не знаком. Можешь хотя бы вкратце рассказать?

Вот мне интересно, что есть карьера? Педевикия говорит следующее

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

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

Ага. То есть бывает две разных карьеры :)

Можно транспрофессионализироваться из синьора в пээмы, а можно специализироваться и стать синьор девелопером 80го левела.

Про fellow. В американских компаниях, славящимся своими методами не материальной мотивации персонала, это строчка была введена в табель о рангах именно затем, чтобы показать высшую ступень инженерной иерархии. Если говорить совсем-совсем плоско и грубо — это есть человек, который стратегически важен для компании, который занимается развитием технологии/отдела/продукта/языка/whatever и является признанным экспертом в своем деле. Джеймс Гослинг был Sun Fellow, например. Применительно к аутсорсингу уважаемые коллеги неоднократно высказывали тезис о том, что де в аутсорсинге не может быть должности fellow. И это редкий случай, когда я соглашусь — при той модели, которая сейчас используется не может. Но текущая модель явно не эффективна, а в эффективной модели аутсорсинга место должности fellow есть. Если конечно эта должность кому-то важна.

ОК, я понял, спасибо. Хорошая, годная концепция.
Да, в украинских компаниях с fellow трудно — по-моему, об этом Макс писал www.developers.org.ua/...s/have-a-voice

А жаль.

Кстати, нет пресейлс.

С этими просто не сталкивался, ХЗ откуда они берутся.

Обычно из Дев или КуА (скорее авто-КуА). На мой взгляд — это ветка на пол-уровня выше БА.

ОК, поузнаю в продуктовых компаниях, кто они эти пресейлс такие. И добавлю на карту.

есмотря на странное японское название, Cacoo — cacoo.com очень хорош.

На флеше — не тру :) Хотя сервис полезный.

Ближе к теме:
— Можете пояснить почему Automatization QA на уровне Senior Dev (Senior QA) и Senior Automatization QA на уровне QA Lead. На мой взгляд Automatization QA и Senior Automatization QA должны находится между QA и Senior QA; по крайней мере так выглядит со стороны.
— Не понятно почему Team Lead находится в одной линейке с Project Manager (а QA Lead нет)
— Простите мое невежество, но кто такие TW? BA — я так понял бизнес-аналитики?

— У админов может быть все намного сложнее чем простая линейка с тремя уровнями :) Хотя так же сильно зависит от компании.

Основное замечание: По моему, связи и положение узлов все-таки нельзя так просто располагать так просто по «квадратной сетке». В зависимости от компании сетку может очень перекосить (перестановки/урезания мы не рассматриваем).

TW — Technical Writer, если не что-то экзотическое :)

Тогда, ИМХО, надо всю линейку на пол-пункта вниз опустить, я не встречал ситуаций когда TW были бы на одном уровне с QA.

В смысле — TW должны быть квалифицированней QA или наоборот?

А может все-таки яблоки с яблоками сравнивать? А не зеленость апельсинов? Вертикальность этой таблицы не влияет ни на уровень знаний в конкретной области, ни на уровень компенсации, ни на что иное, просто нечто усредненное. Нельзя сравнивать Senior TW и Senior QA — это сильно разные позиции. Только яблоки к яблокам. Вертикальность в данном случае не имеет масштаба.

Думаю, что это правда. Действительно разные ветки очень трудно сравнивать.

Нельзя сравнивать Senior TW и Senior QA — это сильно разные позиции.

Ну это Дев и ТВ сравнивать сложно. А КуА и ТВ хоть как-то соотносятся, хотя конкретные положения могут серьезно зависеть от конкретной конторы. Яркий тому пример Дев и КуА: много где — это равносильные позиции, но очень часто Дев на пункт выше КуА, наоборот — реже, но встречаетсо.

То же с БА: Синьор БА выше чем большенство Дев, КуА или ТВ.

Но все-таки надо понимать что это попытка определить «среднюю температуру по больнице» :)

Я, например, видел очень квалифицированных TW, особенно в продуктовых компаниях. Люди, которые отвечают за User Manual к продукту типа PhotoShop — должны иметь нефиговую квалификацию :)
И видел неквалифицированных QA, в том числе и Senior.
Так что не очень согласен, что TW — по необходимой квалификации — следует ставить ниже QA.

Или Вы по чему-то другому сравниваете?

Люди, которые отвечают за User Manual к продукту типа PhotoShop — должны иметь нефиговую квалификацию :)

А КуА которые проверяют этот фотошоп?

Суть в том что в обязанности КуА еще входит и усовершенствование продукта, а в обязанности ТВ, вроде как, нет.

Или Вы по чему-то другому сравниваете?

Больше по ответственности и возможности влиять на продукт. В некоторой мере по перспективам роста.

Так что не очень согласен, что TW — по необходимой квалификации — следует ставить ниже QA.

Еще раз: Каждая контора уникальна, есть конторы где ТВ — по факту часть продукт менеджмента.

Проблема в том что рисовать «квадратную сетку не корректно»,

А не «квадратная» — очень зависит от конторы.

Кстати вспомнилось, есть контора где БА считают низшей кастой, просто потому что туда берут в основном студентов (называть контору не буду).

TW вполне может перейти в аналитики и\или Пмы.

В аналитики — да, там даже есть зелёная стрелка :)

В Пмы... ИМХО, без промежуточного звена карьеры — например, аналитика — мало что может получиться. Слишком далеки TW от народа в лице программистов, а наработать одновременно и менежерские, и аналитические скиллзы — очень сложно.

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

Не поверю.
Во-первых, потому что своими глазами пока не видел, по крайней мере в Украине.

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

Такие люди и в циклуме есть :)) присмотритесь ))
Ну а по поводу учить, так это вы же пытаетесь учить — кому, как, и куда расти ))

Успешная карьера может складываться совершенно по-разному.

C удовольствием с ними пообщаюсь, если узнаю имена. Не подскажете ли?
Если же вернуться к TW — то на сегодняшний день в харьковском отделении сиклума их пятеро, из них четверо — в моей команде. Есть определённое подозрение, что я знаю, о чём говорю :)

Я никого не пытаюсь учить. Даже в своей команде — менторство работает намного лучше. Но мне отчего-то кажется, что Вы своим комментарием пытаетесь раскрутить меня на аргументацию в стиле «сперва добейся»?

Не знаю, где в моих комментах вы нашли TW )), но я имел ввиду людей, которые могут приходить вообще не из IT сферы. ИМХО они даже лучше справляются с работой ПМа, чем «отягощенные бэкграундом», т.к. вносят свежий взгляд на решение обыденных проблем (конечно, еще есть компании, в которых считается, что основные задачи Пма — это ревью кода, архитектура, паттерны, тестирование и пр. — тут либо фундамент конторы шатается, и экономят на всем, либо неправильно называется должность). У них нет «запасного аэродрома» («а вдруг не справлюсь, то вернусь к работе девелопера/тестировщика/....») - т.е. рисков в карьере больше, поэтому и более ответственно относятся к своей работе. Т.е. думать как менеджер они начинают гораздо быстрее :)) И менторинг здесь будет только помогать. И я только за, чтоб такие люди приходили в IT.

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

Насчет имен, — их много. К примеру, недавно на DOU было интервью с Лилией Вершининой. Лично с ней незнаком, к сожалению.

TW были в комментарии, стартующем топик.
С Лилей Вершининой я лично знаком, но у неё а) очень специфичный проект, б) она работает в тандеме с сильным тех. лидом, который по совместительству является её мужем :) , и в) из-за отсутствия ITшного бэкграунда ей приходилось (и приходится) довольно тяжело. ИМХО, несколько тяжелее, чем она рассказывала в интервью.

Так что всё же склонен считать это исключением, которое скорее подтверждает правило.

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

По поводу тех.лидов, если команда небольшая, то тех. лида вообще может не быть. Есть, например, архитектор на стороне клиента. ПМ все равно не сможет заменить этих спецов. Вопрос в том, занимается ли ПМ, собственно, своей работой или делает ее за других (причем, вместо основных функций), повышая при этом риски в проекте? Или для вас идеальный ПМ, видимо, это «ПМ-аналитик-архитектор-девелопер-тестер-...», т.е. шизофреник? ))

О каких правилах речь? Кто их придумал, утвердил? Лично вы? :)

Мне кажется, вы склонны считать исключением все, что отличается от вашего опыта )) Так можно вообще любой пример считать исключением ))

Мне кажется, Вы склонны ставить диагноз по юзерпику :)
Всё, что я здесь высказываю — является моим личным мнением, и не претендует на истину в последней инстанции.
Идеальный ПМ для меня — вовсе не ахитектор-девелопер-тестер. Он вообще имеет дело с людьми, а не с кодом и архитектурой. Но некий опыт в этих профессиях помогает
а) оценивать людей на собеседованиях;
б) находить с профессионалами общий язык;

в) оценивать работу своих подчинённых.

И да, Гарвардская интерпретация, гласящая, что эффективный менеджер может одинаково хорошо руководить чем угодно — хоть сталелитейным предприятием, хоть рестораном Старбакс, лично мне кажется ошибочной. Если Вы считаете её правильной — что ж, вперёд, проверяйте :)

И да, наверное надо написать об этом очередную колонку.

Еще в 90-е в нашей стране только начали появляться IT компании, и руководителей выбирали скорее по количеству лет опыта работы программистом, чем по наличию необходимых качеств (и уж тем более образования) — т.н. «старая школа». Может быть, это было обусловлено тем, что тогда просто не из кого было выбирать. Не было еще четкого разделения по специализациям, да и вообще, всё только начиналось. Традиция сохранилась и по сей день во многих компаниях.

Опыт помогает, по пунктам а), б), в) согласен абсолютно.

Но время изменилось, ведь успех проекта сегодня обеспечивают далеко не только разработчики, на первое место в профессии ПМа выходят коммуникации и customer service (особенно в аутсорсе), — что чаще гораздо важнее technical skills.

Не знаю, причем здесь Гарвард (HBS ? :)), но я имел ввиду другое:

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

Підписатись на коментарі