Вхід і реєстрація
Блоги · 10 липня 2011, 21:13 71002
Yuriy Silvestrov, PM в Oracle

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

Провожу с командой 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

Теми: аналітика, кар’єра
LinkedIn



167 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
Андрій Лисюк Senior Product Owner / Project Manager / Business System Analyst / Team Lead в NDA LTD 21.02.2017 10:42

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

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

Відповісти
Підтримати
Oleksandra Zadorozhnykh Recruiter в Intellias 21.12.2015 13:26

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

Відповісти
Підтримати
ILYA M PM в DH 14.09.2013 01:00

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

Відповісти
Підтримати
Stas Sydorov Basic Unit в Levi 9 11.04.2013 21:40

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

Відповісти
Підтримати
Stas Sydorov Basic Unit в Levi 9 11.04.2013 21:42

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

Відповісти
Підтримати
Stas Sydorov
Yuriy Silvestrov PM в Oracle 18.04.2013 16:53

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

Відповісти
Підтримати
Stas Sydorov
Stas Sydorov Basic Unit в Levi 9 18.04.2013 16:56

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

Відповісти
Підтримати
Stas Sydorov
Yuriy Silvestrov PM в Oracle 18.04.2013 16:51

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

Відповісти
Підтримати
Stas Sydorov
Responsibility To 21.03.2012 09:44

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

Responsibility To 21.03.2012 09:42

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

Responsibility To 21.03.2012 09:36

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

Sergii Shmarkatiuk CTO в CodeCompath 24.02.2012 10:24

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

Відповісти
Підтримати
Dmytro Lapshyn Solution Architect 15.03.2012 19:03

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

Відповісти
Підтримати
Sergii Shmarkatiuk
Sergii Shmarkatiuk CTO в CodeCompath 21.03.2012 16:15
кто-то из разработчиков
про разработчиков согласен, но ...
или тестировщиков
Никогда не приходилось наблюдать как тестировщик настраивает работу системы контроля версий, пишет билд-скрипты, настраивает работу 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 — это так, эпизодическая никому не нужная функция в то время, как это уже давно (на западе по-крайней мере) стало отдельной инженерной дисциплиной.

Відповісти
Підтримати
Dmytro Lapshyn
Dmytro Lapshyn Solution Architect 21.03.2012 23:57

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

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

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

Відповісти
Підтримати
Sergii Shmarkatiuk
Yuriy Silvestrov PM в Oracle 29.05.2012 08:33
Сергей, а из кого Configuration Managers вырастают? Из админов? И какие скилзы для этого нужны?

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

Відповісти
Підтримати
Sergii Shmarkatiuk
Sergii Shmarkatiuk CTO в CodeCompath 30.05.2012 00:11

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

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

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

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

Відповісти
Підтримати
Yuriy Silvestrov
Sergey Khaperskov Lead Engineerist 14.09.2013 00:39

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

Відповісти
Підтримати
Sergii Shmarkatiuk
Gremlin 17.12.2011 19:39
квадратно-гнездовая карта.

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

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

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 18.12.2011 10:54

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

Відповісти
Підтримати
Gremlin
Gremlin 18.12.2011 14:56
До некоторой степени, чем позже стартуешь, тем резвее набираешь нужные навыки — просто за счёт жизненного опыта.
получается, топливо опыта необходимо для нормального взлёта ПМ-а.
в нормальной компании.
в наших реалиях возможны варианты...
зы:
в бодишопах, распиловках и маленьких карманных рабовладельческих конторках
ньюба-ПМ-а могут держать за руки, клевать мозг и требовать результатов.
потом — сломать крылья и сказать: «ну вот, видите — из хорошего дева получился никакой ПМ»
собсно, я о чём... кроме запаса топлива-опыта ещё важно выбрать правильную стартовую площадку и правильное время)) isn’t it?
Відповісти
Підтримати
Yuriy Silvestrov
Volodymyr Vorobey PPV Knowledge Networks 29.10.2011 23:53

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 31.10.2011 11:11

ОК, спасибо.

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

Відповісти
Підтримати
Volodymyr Vorobey
Yuriy Silvestrov PM в Oracle 27.09.2011 11:33

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

Відповісти
Підтримати
Max Tkachuk design engineering 16.07.2011 18:01
И да, куда вы во всех этих постах про jun/mid/sen дели pnincipal/associate?

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

Відповісти
Підтримати
Max Tkachuk design engineering 16.07.2011 19:43

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

Відповісти
Підтримати
Yuriy Silvestrov
Max Tkachuk design engineering 16.07.2011 17:58
Привет, братья.
Пять копеечек по пункту Design на карте:
— Чем в этой схеме web designer отличается от ui designer и ui designer от ux designer?
— Куда подевался interaction designer? Почему нет senior?

Спасибо.

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 16.07.2011 18:24
Макс, расскажи плиз, кто такой interaction designer. Лучше со ссылками.
Web designer — это верстальщик со знанием фотошопа. Человек, который дизайнит сайты и выдаёт готовую вёрстку.

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

Відповісти
Підтримати
Max Tkachuk design engineering 16.07.2011 19:14

Юра, ну раз мы тут рисуем красоту правильную, то надо бы учесть пару моментов. хотя бы в виде абстрактной сказки :)
лентяй получает ссылку :) о, я еще 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% дизайнеров

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

Відповісти
Підтримати
Yuriy Silvestrov
Bogdan Shyiak SE or Dev 15.07.2011 23:03
О! Теперь карта стала намного лучше: в стрелочках х... разберешься :)
Более конструктивно:
По уровням можно поспорить что:
— системный аналитик выше лида (хотя я бы не стал);
— дизайнеры начинаются с уровня аналогичного джуну. ИМХО на пол-ступеньки выше. Нет верстальщиков (часто верстальщик и дизайнер — это разные люди) как таковых.

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

Відповісти
Підтримати
Alex Fruzenshtein Director of Engineering в VidIQ 14.07.2011 12:07

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

Відповісти
Підтримати
Stas Sydorov Basic Unit в Levi 9 11.04.2013 21:52

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

Відповісти
Підтримати
Alex Fruzenshtein
Oлександр V 13.07.2011 20:35
ждем читы на эту систему прокачки!

poweroverwhelming

Відповісти
Підтримати
Alex Kukharchuk 21.07.2011 10:24

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

Відповісти
Підтримати
Anna Miroshnichenko Technical Talent Sourcer 12.07.2011 18:00

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

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

Відповісти
Підтримати
Sergiy Prokhorenko Co-founder в Agile.Live 12.07.2011 18:43

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

Відповісти
Підтримати
Zakhar Khrystych Head of Business Analysis в FAVBET 14.04.2016 22:58

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

Відповісти
Підтримати
Sergiy Prokhorenko
Yuriy Silvestrov PM в Oracle 12.07.2011 21:25

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

Відповісти
Підтримати
Alex Nagorniak Senior Software Engineer 12.07.2011 11:05
мне очень понравилась эта карта!! но она ничего не обьясняет к сожалению в плане почему кто то растет а кто то не растет. Ведь каждая компания отличаеться. Чтоб обьяснить куда рости или почему в той или иной компании вырости не удасться или наоборот будет быстрый рост схемка должна показывать что то более динамичное, а не статическую картинку. Иногда очень важны личные предпочтения. Например в компании или тиме могут рости например только люди выского роста или маленького или модельной внешности, по хобби, политическим убеждениям и прочее. Ведь решает вырос или нет не схемка а конкретный человек или группа людей...
Кроме того может быть разряд (демотивация) у любого из этих ролей (как результат оскорбления, несправедливая оценка performance — а и т.д.).

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 12.07.2011 17:15
Алексей, это карта. Она объясняет, в каком направлении идти от точки «здесь и сейчас» до точки «там и тогда».

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

Відповісти
Підтримати
Alex Nagorniak Senior Software Engineer 13.07.2011 11:38

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

Відповісти
Підтримати
Yuriy Silvestrov
Sergiy Prokhorenko Co-founder в Agile.Live 11.07.2011 17:30

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

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

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 21:54
Junior BA — ИМХО и есть Requirements Analyst, конечно его никто к бизнесу не пустит — пусть сидит и документы пишет, учится.

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

Відповісти
Підтримати
Sergiy Prokhorenko Co-founder в Agile.Live 11.07.2011 23:50

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

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

Відповісти
Підтримати
Yuriy Silvestrov
Yuriy Silvestrov PM в Oracle 12.07.2011 00:01
ОК, переименовал в Requirements Analyst :) Теперь будем знать, как это правильно называется.

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

Відповісти
Підтримати
Sergiy Prokhorenko Co-founder в Agile.Live 12.07.2011 00:30

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

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

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

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 21:49

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

Відповісти
Підтримати
Alexander Puhachev Engineer в EPAM 11.07.2011 23:08

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

Відповісти
Підтримати
Yuriy Silvestrov
Spark 11.07.2011 09:33

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

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

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

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 10:41

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

Відповісти
Підтримати
Anton Naumov
Spark 11.07.2011 12:48

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

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 13:10
Дерево не обещаю, но мы в команде работаем над системой оценки технических знаний (что-то типа грейдов, ну или как получится). Ну и соответственно — план развития.

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

Відповісти
Підтримати
Spark 11.07.2011 13:20

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

Відповісти
Підтримати
Mykyta Knysh Lead test automation engineer в N-iX 11.07.2011 09:05

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

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 10:18

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

Відповісти
Підтримати
Max Ischenko Founder в DOU.ua 11.07.2011 07:57

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 10:20
Открыл рядом, буду сравнивать.

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

Відповісти
Підтримати
Alexander Stoyakin Developer 11.07.2011 10:55

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

Відповісти
Підтримати
Yuriy Silvestrov
Yuriy Silvestrov PM в Oracle 11.07.2011 12:17

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

Відповісти
Підтримати
Bertram Gilfoyle 11.07.2011 12:18

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

Відповісти
Підтримати
Yuriy Silvestrov
Volodymyr Prokopchuk Software Development Manager в Nomis Oy 11.07.2011 14:35

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

Відповісти
Підтримати
Yuriy Silvestrov
Yuriy Silvestrov PM в Oracle 11.07.2011 15:07

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

Відповісти
Підтримати
SemiCoder 11.07.2011 01:23
developer -> SA/BA -> .... ->CxO

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 01:39
SA — это Software Architect?

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

Відповісти
Підтримати
Bogdan Shyiak SE or Dev 11.07.2011 01:55

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

Відповісти
Підтримати
Yuriy Silvestrov
Alexander Stoyakin Developer 11.07.2011 08:56

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

Відповісти
Підтримати
Yuriy Silvestrov
reality_hacker 11.07.2011 09:00

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

Відповісти
Підтримати
Alexander Stoyakin Developer 11.07.2011 09:13

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

Відповісти
Підтримати
reality_hacker 11.07.2011 09:15

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

Відповісти
Підтримати
Alexander Stoyakin Developer 11.07.2011 09:31
К началу ветки.

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

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

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

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

Відповісти
Підтримати
Alexander Stoyakin Developer 11.07.2011 10:45

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

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 12:03
Подумал и повспоминал ещё.

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

Відповісти
Підтримати
Alexander Stoyakin Developer 11.07.2011 13:07

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

Відповісти
Підтримати
Bertram Gilfoyle 11.07.2011 12:32

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

Відповісти
Підтримати
Sergiy Prokhorenko Co-founder в Agile.Live 11.07.2011 17:17

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

Відповісти
Підтримати
reality_hacker 11.07.2011 18:16

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

Відповісти
Підтримати
SemiCoder 11.07.2011 10:13

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

Відповісти
Підтримати
Yuriy Silvestrov
Yuriy Silvestrov PM в Oracle 11.07.2011 10:43

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

Відповісти
Підтримати
Aleksey Kolupaev CTO в eduki 11.07.2011 01:12

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

Відповісти
Підтримати
Aleksey Kolupaev CTO в eduki 11.07.2011 01:24

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

Відповісти
Підтримати
Tanya Zavialova
Yuriy Silvestrov PM в Oracle 11.07.2011 01:37
Интересная ссылка, почитаю.

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

Відповісти
Підтримати
Bogdan Shyiak SE or Dev 11.07.2011 01:50

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

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

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

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 08:54

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

Відповісти
Підтримати
Aleksey Kolupaev CTO в eduki 11.07.2011 01:51

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

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 08:56

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

Відповісти
Підтримати
Aleksey Kolupaev CTO в eduki 11.07.2011 09:01

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 10:15

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

Відповісти
Підтримати
Aleksey Kolupaev CTO в eduki 11.07.2011 10:21

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 10:44

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

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

project manager -> program manager

Відповісти
Підтримати
Tanya Zavialova Co-Founder в KyivUX 11.07.2011 00:04

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 00:09
Татьяна, а может быть Вы расскажете о карьере дизайнера?

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

Відповісти
Підтримати
Bogdan Shyiak SE or Dev 11.07.2011 00:29
Теоретически я слышал об UX-дизайнерах, например.
UX к дизайнерам имеет такое же отношение как и к Дев или КуА или к ПМ (продукт) — это отдельная специализация. Специалистов очень мало, и я к сожалению не встречал контор в которых бы понимали что такой человек нада, а не просто Куа/дизайнер/ПМ с доп нагрузкой.
Відповісти
Підтримати
Yuriy Silvestrov
Tanya Zavialova Co-Founder в KyivUX 11.07.2011 01:02

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

Відповісти
Підтримати
Bogdan Shyiak SE or Dev 11.07.2011 01:09

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

Відповісти
Підтримати
Tanya Zavialova Co-Founder в KyivUX 11.07.2011 01:12

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 01:43
Да, надо бы дизайнеров добавить.
Что-нибудь типа:

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

Відповісти
Підтримати
Tanya Zavialova Co-Founder в KyivUX 11.07.2011 09:49

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 10:29
Татьяна, а разве мобайл и десктоп — это не разновидности UI?

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

Відповісти
Підтримати
Tanya Zavialova Co-Founder в KyivUX 11.07.2011 10:49
Веб, мобайл, десктоп это специализации (можно сказать и разновидности) которыми часто занимаются разные люди.

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

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

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 12.07.2011 17:20

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

Відповісти
Підтримати
Tanya Zavialova Co-Founder в KyivUX 12.07.2011 20:18
Здорово! Спасибо :)

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 12.07.2011 21:24

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

Відповісти
Підтримати
Tanya Zavialova Co-Founder в KyivUX 12.07.2011 21:39

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 13.07.2011 14:46

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

Відповісти
Підтримати
Aleksey Kolupaev CTO в eduki 11.07.2011 01:09

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

Відповісти
Підтримати
Bogdan Shyiak SE or Dev 11.07.2011 01:11

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

Відповісти
Підтримати
Tanya Zavialova Co-Founder в KyivUX 11.07.2011 01:14

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 01:40

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

Відповісти
Підтримати
Bogdan Shyiak SE or Dev 11.07.2011 02:01

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

Відповісти
Підтримати
Tanya Zavialova Co-Founder в KyivUX 11.07.2011 01:10

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

Відповісти
Підтримати
Yuriy Silvestrov
Andrey Lomov 10.07.2011 23:57

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 00:18

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

Відповісти
Підтримати
Tanya Zavialova Co-Founder в KyivUX 10.07.2011 23:50

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

Відповісти
Підтримати
Eduard Dudar Sr. Software Engineer в Aol Inc. 10.07.2011 22:17

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

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

Відповісти
Підтримати
Bogdan Shyiak SE or Dev 10.07.2011 22:25

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

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

Відповісти
Підтримати
Eduard Dudar Sr. Software Engineer в Aol Inc. 10.07.2011 22:31

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

Відповісти
Підтримати
Bogdan Shyiak
Bogdan Shyiak SE or Dev 10.07.2011 22:29

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

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 10.07.2011 22:32

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

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

Відповісти
Підтримати
Eduard Dudar Sr. Software Engineer в Aol Inc. 10.07.2011 22:39

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

Відповісти
Підтримати
Yuriy Silvestrov
Yuriy Silvestrov PM в Oracle 10.07.2011 22:46

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

Відповісти
Підтримати
Alexander Puhachev Engineer в EPAM 11.07.2011 09:57
Хорошему тестировщику автоматизатору нет смысла переходить в девелоперы.
Оглянитсь вокруг, сколько вы знаете хороших програмистов, а сколько хороших автоматизаторов?

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 10:30

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 10:47
Алексей, мы просто усиленно хантим сейчас. Ищем и девелоперов, и QA.

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

Відповісти
Підтримати
Aleksey Kolupaev CTO в eduki 11.07.2011 10:53

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

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

Відповісти
Підтримати
Anton Naumov SSE в Just Techologies AS 10.07.2011 22:40

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

Відповісти
Підтримати
Yuriy Silvestrov
Yuriy Silvestrov PM в Oracle 10.07.2011 22:44
Ты, по-моему, уже в менеджеры перешёл, пусть даже и в программирующие?
Но ОК, пусть это Engineering. Что может быть в твоей карьере следующее за Senior Java Software Engineer? И что после него?

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

Відповісти
Підтримати
Anton Naumov SSE в Just Techologies AS 10.07.2011 23:25
Ну был я начальником отдела, ну был менеджером проекта. Это все мелочи — важно, что я не менеджер, а вполне себе SJSE.
Что дальше? Ну есть брать классику, то есть fellow. Вряд ли это появится у нас быстро, но появится. И я когда-то хотел им быть. Сейчас мне совершенно не интересны погоны и звания. Мне интересен характер работы, горизонты ответственности и размер компенсации. А там хотите назовите CTO, хотите — младший помощник старшего дворника.

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 00:17
То есть карьера остановилась (дальше двигаться некуда), но развивается компетенция в рамках текущей должности. В результате чего повышается трудность и сложность задач, которые ты решаешь, растёт ответственность — и соответственно растёт и компенсация.
Т.е. вместо карьерного роста идёт рост компетенции. Так?

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

Відповісти
Підтримати
Anton Naumov SSE в Just Techologies AS 11.07.2011 09:59

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

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

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 10:40
Ага. То есть бывает две разных карьеры :)

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

Відповісти
Підтримати
Anton Naumov SSE в Just Techologies AS 11.07.2011 10:07

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 11.07.2011 10:36
ОК, я понял, спасибо. Хорошая, годная концепция.
Да, в украинских компаниях с fellow трудно — по-моему, об этом Макс писал www.developers.org.ua/...s/have-a-voice

А жаль.

Відповісти
Підтримати
Bogdan Shyiak SE or Dev 10.07.2011 22:13

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 10.07.2011 22:23

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

Відповісти
Підтримати
Bogdan Shyiak SE or Dev 10.07.2011 22:26

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

Відповісти
Підтримати
Yuriy Silvestrov
Yuriy Silvestrov PM в Oracle 10.07.2011 22:34

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

Відповісти
Підтримати
Bogdan Shyiak SE or Dev 10.07.2011 22:12

есмотря на странное японское название, 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 — я так понял бизнес-аналитики?

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

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

Відповісти
Підтримати
Eduard Dudar Sr. Software Engineer в Aol Inc. 10.07.2011 22:18

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

Відповісти
Підтримати
Bogdan Shyiak SE or Dev 10.07.2011 22:23

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

Відповісти
Підтримати
Eduard Dudar
Yuriy Silvestrov PM в Oracle 10.07.2011 22:24

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

Відповісти
Підтримати
Eduard Dudar Sr. Software Engineer в Aol Inc. 10.07.2011 22:34

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 10.07.2011 22:41

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

Відповісти
Підтримати
Bogdan Shyiak SE or Dev 10.07.2011 22:54

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

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

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

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

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

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

Відповісти
Підтримати
Bogdan Shyiak SE or Dev 11.07.2011 00:26

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

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

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

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

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

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

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

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

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

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

Відповісти
Підтримати
Ilya Bogunov 10.07.2011 21:52

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

Відповісти
Підтримати
Yuriy Silvestrov PM в Oracle 10.07.2011 22:00
В аналитики — да, там даже есть зелёная стрелка :)

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

Відповісти
Підтримати
satellite 17.12.2011 11:29

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

Відповісти
Підтримати
Yuriy Silvestrov
Yuriy Silvestrov PM в Oracle 17.12.2011 12:20
Не поверю.
Во-первых, потому что своими глазами пока не видел, по крайней мере в Украине.

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

Відповісти
Підтримати
satellite
satellite 17.12.2011 14:47
Такие люди и в циклуме есть :)) присмотритесь ))
Ну а по поводу учить, так это вы же пытаетесь учить — кому, как, и куда расти ))

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

Відповісти
Підтримати
Yuriy Silvestrov
Yuriy Silvestrov PM в Oracle 17.12.2011 15:10
C удовольствием с ними пообщаюсь, если узнаю имена. Не подскажете ли?
Если же вернуться к TW — то на сегодняшний день в харьковском отделении сиклума их пятеро, из них четверо — в моей команде. Есть определённое подозрение, что я знаю, о чём говорю :)

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

Відповісти
Підтримати
satellite
satellite 17.12.2011 15:48

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

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

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

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

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

Відповісти
Підтримати
satellite
satellite 17.12.2011 16:52

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

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

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

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

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

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

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

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

Відповісти
Підтримати
satellite
satellite 17.12.2011 20:43

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

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

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

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

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

Відповісти
Підтримати
Yuriy Silvestrov

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.