Менеджер в it как правило знает

Менеджер в it как правило знает

Вы собираетесь отправить сообщение о следующей ошибке:

10 стыдных вопросов о no-code

Как ставить цели, чтобы их достигать: исчерпывающий гайд по OKR

Что читать, смотреть и слушать продакт-менеджеру: 179 ресурсов

Что нужно знать ИТ-менеджеру или ученье свет, а за свет надо платить

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

Итак, что же надо изучать настоящему или будущему IT менеджеру, где изучать и сколько это стоит. Всё сугубое IMHO.

1. Английский язык

Это первое, что надо изучать и поддерживать в хорошем состоянии. Я оставлю за рамками этой дискуссии его необходимость для товарищей, решивших «завести трактор» и остановлюсь на других аспектах. Англоязычный пул документации, фреймворков, сообществ, экспертов и книг НАМНОГО превышает русскоязычный. Вы не сможете нормально развиваться, как IT менеджер (да и вообще как IT специалист), без знания английского, хотя бы на уровне чтения документации без словаря — если вы просто IT специалист и владения на уровне Intermediate и выше — если вы нацелились на гордое звание профи IT менеджмента. Где: это зависит от ваших возможностей. В идеале очень здорово провести пару месяцев в стране носителей языка, но этот вариант подойдёт 5% от желающих улучшить свои языковые навыки. Для тех, кто не может себе этого позволить, есть отличный ресурс — EF School. Хорошая онлайн школа, с отличным материалом, живым общением с носителями и по доступной цене (2000 рублей в месяц). Из сопутствующих рекомендаций — полезно смотреть каждый день по 30 минут перед сном какой-нибудь англоязычный канал, а в выходные англоязычный фильм. Начинать лучше с фильмов, которые вы уже видели в русском дубляже, и смотреть первые 10-15 фильмов с английскими субтитрами.

2. ITIL

Без него современному IT менеджеру никак не прожить. База большинства систем основана именно на сервисном подходе и глоссарии ITIL (тикеты, инциденты, проблемы, SLA, CMDB, время реакции, время решения, эскалация, change, запросы на обслуживание и т.п.). Начать можно с русской версии глоссария ITIL (Глоссарий), далее почитать статьи на itsmonline.ru и itsmforum.ru.

Желательно пройти курс ITIL Foundation и сдать экзамен (курс ITIL F — 229 $). Поработать в системах хелпдеск, поддерживающих ITSM подход (ServiceNow, HP OpenView, ManageEngine ServiceDesk и др.). При достаточном уровне английского можно чуть позже взяться за сами книжки в оригинале. Если с английским не очень хорошо, то будет полезно прочитать вот эту книжку — Free ITIL (хотя её наверное стоит прочитать даже тем у кого с английским хорошо).

3. Проектные методологии (ANSI PMI PMBOK, PRINCE2)

IT менеджер постоянно сталкивается с теми или иными проектами, поэтому он должен уметь грамотно ими управлять. Тут без вариантов. Это базис. Выбирайте то, что вам по душе и изучайте (PMI PMBOK, PRINCE2). Цена вопроса в пределах 1000 $, в зависимости от уровня сертификации. Какая из методологий лучше — вопрос личных предпочтений и места работы (пример — в Европе более популярен Prince2). Настоятельно советую всё же выбрать себе одну, как основную и, обязательно, ознакомиться с основами второй методологии.

4. Agile

Это модное слово скрывает за собой целый пласт, который называется гибкий подход к разработке (Scrum, FDD, XP и другие). Где почитать: почитать можно на самом деле много где. Об Agile не писал только ленивый. Вот здесь, например — блог. Можно даже пройти сертифицированный курс (например вот — курс — 549$. Дороговато, но это цена популярности), хотя я бы стал это делать, только если решил сконцентрироваться на работе в качестве скрам мастера или при наличии формальных требований от «вкусного» работодателя. На что обратить внимание — гибкие методологии не панацея! Кое-где они даже вредны. У них есть недостатки, которые сразу неочевидны. Но, в целом, это то, что «доктор прописал», для нужд большинства команд разработчиков. Недостатки гибкого подхода можно нивелировать, если вникнуть глубже в тему.

5. DevOps

Если описать в двух словах — это, как-бы, Agile, но для сисадминов. Это очень неточно, но передаёт суть. Когда разработчики перешли к использованию гибких методологий, IT operations стало отстающим блоком, который тормозил, выдающих «на-гора», каждые две недели, разработчиков. DevOps ликвидирует эту проблему (или пытается это сделать). Где почитать: можно купить или найти на просторах сети PDF версию книги DevOps Cookbook и ознакомится с ней. Можно (если вы ещё не потратили все деньги на сертификации и курсы из предыдущих пунктов списка) пройти сертификационный курс, одобренный DevOps Institute вот здесь — курс DevOps. Цена вопроса — 499$.

6. Вендоро-зависимая сертификация

Сразу отмечу, что от вендеро-независимых сертификаций толку чуть больше чем нуль (за очень очень редким исключением) и, я не буду на них подробно останавливаться. Сертификацию какого вендора проходить — я не подскажу, это зависит от стези которую вы выбрали. У многих путь выглядит так: по молодости Microsoft, потом «ой без Linuх в серьёзных компаниях никак», потом «ой мне нужно бы разобраться в SAP, за неё платят больше всех» (шутка). Полезно то, что используется в больших компаниях. Вы же наметили себе в качестве места работы именно такие компании, а не ООО «Двери Плюс»? Тогда вам нужна сертификация от компаний Microsoft, Cisco, RedHat, SAP, IBM, HP. Если вы наметили себе путь в менеджеры, то сильно углубляться в техническую сертификацию не стоит, можно остановиться на базовых уровнях. Примеры: MCSA для Microsoft, CCNA для Cisco и RHCSA для RedHat. Цена вопроса: MCSA — 240$, CCNA — 450$, RHCSA — 400$. Более глубоко, если планируете развиваться как менеджер, я бы не советовал лезть.

7. MBA

Много горячих баталий было посвящено вопросу, а нужно ли тратить время и силы на MBA? Моё мнение — если есть возможность, то оно того стоит. Как: выбрать школу, которая вам подходит по критерию цена/качество/доступность/рейтинг, обратить внимание на наличие аккредитации (AMBA, EFMD, AACSB), проверить аккредитацию и поискать информацию. По зарубежным можно посмотреть информацию здесь — рейтинг FT. Обратите внимание, что ни одна бизнес школа из России не попала в первую сотню этого рейтинга! Поэтому ценность вашего обучения в бизнес-школе в России будет актуальна только для России. Цена вопроса: очень разнообразная примерно от 6 000$ в РФ и до 130 000-150 000$ за границей. Пример: MBA в INSEAD, занимающей 5 место в рейтинге, обойдётся примерно в 80 000$ + 50 000$ уйдёт на проживание и другие расходы. Так же не стоит забывать об упущенной выгоде, так как вы потеряете, как минимум один год дохода, при очном обучении. Стоит всё очень хорошо взвесить.

8. Финансы

ИТ-менеджеру, в любой его ипостаси приходится иметь дело с финансами. Понимание таких вещей как бюджетирование, виды затрат, амортизация, срок окупаемости и возврата инвестиций и многие другие — жизненно необходимы в повседневной деятельности. В идеале, неплохо, получить второе высшее образование, связанное с финансами и экономикой. Цена вопроса: от 4500 до 7500$, в зависимости от ВУЗа и программы обучения. Обратите пристальное внимание на процесс управления финансами в библиотеке ITIL и область знаний «Управление стоимостью проекта» в PMBOK. Если вы нацелились на карьеру в качестве ИТ менеджера в банковской/страховой сфере, то подумайте о сдаче экзамена CFA. Замечу, что это недешёвое удовольствие — без курсов и других затрат, первый уровень CFA стоит порядка 1100 — 1500$, в зависимости от времени регистрации. Также, обратите внимание, что порядка 40% от кандидатов сдают его с первого раза. Экзамен, конечно, на английском языке, как и большинство значимых сертификаций в мире ИТ(вы же уже записались на курсы английского или знаете язык?)

9. Безопасность

Обеспечение безопасности в информационных систем является одной из ключевых сторон работы ИТ менеджера. Необходимо, как минимум, знать основы и знать ПО для обеспечения безопасности: антивирусное, IDS/IPS/DLP системы, анализаторы протоколов, криптографическое ПО, межсетевые экраны, средства и ПО для аутентификации, средства и ПО для видеонаблюдения. Очень полезно ознакомиться со стандартом ISO 27001 (стандарт). Хорошим опытом будет участие в сертификации на соответствие стандартам PCI DSS любого уровня. Стандарт PCI DSS содержит перечень достаточно конкретных технических и организационных требований к обеспечению информационной безопасности. Даже тем, кто не работает с картами, тоже очень полезно просто почитать опросник SAQ (опросник SAQ D).

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

• ит-менеджмент
• ит-индустрия
• карьера
• карьера ит-специалиста
• менеджмент
• развитие личности
• развитие

• Управление проектами
• Карьера в IT-индустрии

Карьера менеджера в ИТ: от командной строки к командной работе

Мир IT сегодня не похож ни на одну из других отраслей — над кодом приложений, игр, корпоративных решений, сервисов работают увлечённые, грамотные ребята. Программисты и инженеры, дизайнеры и тестировщики, системные администраторы и новомодные DevOps превращают идеи в программное обеспечение, которым пользуются миллионы людей. Они вдохновенно пишут код, разрабатывают алгоритмы, готовят макеты и соединяют это в работоспособные полезные механизмы. Мы, пользователи Хабра, часто говорим о разработке, администрировании, новых технологиях и языках программирования, зарубаемся в жарких спорах о преимуществах одного стека над другим, но забываем о важном звене в любой IT-компании — менеджерах проектов и продуктов. А между тем не факт, что завтра именно вам не предложат отойти от дел программерских и стать менеджером. Мотивация? Стоит ли? Потолок? Карьерный тупик? Новый горизонт? Давайте разбираться.

Менеджер в айти, бэклог его ити…

Мы внедряем свою CRM-систему и поэтому имеем не только опыт развития своих собственных менеджеров (это, в основном, гибриды с програмистами — ближе к тимлидам) в RegionSoft Developer Studio, но и встречаемся с чужими менеджерами ИТ-проектов (и не ИТ тоже, но это другая история). За много лет нам удалось выявить ряд типичных признаков менеджеров «с плохим характером».

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

• Работа без цели, плана и этапов проекта. Такая ситуация может возникнуть, если менеджер плохо представляет себе этапы разработки и вообще процесс создания программного обеспечения, то есть фактически ему просто трудно адекватно планировать. Сумбурная работа, метание от задачи к задаче, постоянно изменяющиеся требования выматывают всех членов команды, приводят к увольнениями и профессиональному выгоранию.
• Изменение проекта на лету — ещё одна ненавистная черта менеджера. Вы легко узнаете этот тип работника: услышав на конференции или очередном митапе о новой технологии или модных моделях управления, он возвращается в компанию с горящими глазами и начинает активно продавливать новинку на старом проекте. Причём это не эксперимент с лучшими практиками, а именно тотальное и безоглядное погружение во что-то новое. По ощущениям — больше макание. Приводит к срывам срока проекта и резкому падению качества и скорости разработки. Если горе-новатор умудряется заручиться поддержкой топ-менеджмента — пиши пропало.
• Стратегия любой ценой — девиз менеджеров ИТ-проектов, работающих на свой собственный бонус, но не на благо команды. Такие ребята готовы на всё ради KPI и ROI и исключают любые риски, лишь бы не потерять заветные значения коэффициентов. Самый опасный вариант, когда менеджер лоббирует внедрение в матрицы показателей коэффициенты, связанные с «нетрудовыми» достижениями — такие как коэффициент лояльности, показатель внутренней мотивированности и оценочный уровень взаимодействия с коллегами. Как правило, профессионалы-интроверты сквозь это решето не проходят и остаются без премий. А там и без мотивации, и… без работы.
• Непонимание принципов разработки — бич менеджеров-нетехнарей. Не зная особенности создания кода, скорость работы программистов, принципы тестирования, сроки выведения продукта в продакшен, крайне трудно прийти к общему знаменателю с R&D и стать настоящим связующим звеном внутри проекта. Именно такие менеджеры любят заучить несколько словечек ИТ-тематики и говорить: «Успеешь фичу до пятницы?», «Отрефакторь код, чтобы быстрее работало», «Да там всего две строчки поменять. Зачем весь билд тестировать?».

Из программистов в менеджеры — путь самурая

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

1. Сменить компанию и получить новые задачи в рамках нового проекта — самы простой, но часто самый нежелательный для всех исход. Давайте забудем о нём до других постов.
2. Сменить проект внутри своей компании и развивать новое направление — отличный вариант, выгодный компании и мотивирующий разработчика. Но не в каждой компании ведётся параллельная разработка нескольких проектов, такой возможности может просто не быть.
3. Продолжать расти на своём месте, углубляясь в оптимизацию разработки, наращивая функциональность продукта, совершенствуя его через рефакторинг и использование новых алгоритмов и технологий. Отличный вариант, который чаще всего и выбирают лучшие программисты.
4. Стать менеджером — в том случае, если программист проявляет управленческие черты и очевидно готов взвалить на себя груз проектной работы, а разработку доверить своей же команде.
5. Стать технологическим евангелистом — для очень крупных компаний или для очень редких и ультра популярных продуктов.

Особое мнение — главный разработчик RegionSoft Developer Studio рассказывает о своём опыте работы с менеджерами и программистами.

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

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

Менеджер экспертного уровня — это всегда звезда в любой команде, потому что он и умеет работать «продвиженцем» и знает предмет вопроса изнутри. Это как Королев, когда он возглавил КБ для разработки ракеты. Если бы он сам эти детские ракетки и самолёты не запускал и не конструировал, он бы никогда не смог управлять целым КБ и не создал бы ракету, способную покорить космос.

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

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

Переход из разработчиков в менеджеры разработки — это карьерный рост с точки зрения и общества, и руководителя, и коллектива. Это повышение заработной платы, новые задачи и новая ответственность. Но разработчик не всегда готов забросить код и приступить к новым обязанностям — хотя бы просто потому что программировать ему нравится гораздо больше. Эта позиция заслуживает огромного уважения (и повышения зарплаты — да-да, господа руководители, это свидетельство почти что патологической лояльности продукту и оно дорого стоит!), но мы всё же остановимся на более распространённой ситуации: зарплата манит, новые задачи будоражат и вы почти согласны стать менеджером, но с чего начать? Как встать на этот путь и стать на нём эффективным, а не попасть в ловушку принципа Питера?

Менеджер в ИТ — это почти всегда человек-оркестр. Но всегда ли слаженно он играет?

Что нужно осознать?

Любая смена деятельности как внутри компании, так и вне её — это определённый стресс, сопряженный с множеством вопросов и сомнений. Даже если вы знаете проект много лет, всё равно вам предстоит посмотреть и на него, и на команду с другой стороны, обратиться к новым сторонам взаимодействия, стать руководителем своих коллег, стать лидером. Важно сразу осознать несколько моментов, которые помогут собраться и приступить к работе «с той ноги».

• Должность менеджера — это рост для программиста, новый виток развития в сфере управления. Когда разработчик достиг практически всего в коде, ему стоит шагнуть дальше и управлять именно так, как того проект требует. Когда знаешь процессы разработки и особенности продукта изнутри, ты способен изменить многое в управлении, сделать команду по-настоящему сильной. Бонус за все риски — новые задачи и материальная сторона.
• Переход в менеджеры — способ преодолеть достигнутый карьерный потолок. Особенно это важно для тех специалистов, которые хотят развиваться внутри своей компании, а не менять работу. Это способ применить накопленные знания в новом качестве.
• Менеджеру проще перейти на высокооплачиваемую работу в другую компанию, поскольку программист должен вникать в код, стиль разработки, разбираться с не всегда лучшим «наследством» от предшественника, а менеджер приходит со способностью грамотно управлять проектом, понимая разработку, но тратя время на разгребание кучи кода. Он изначально эффективен (хотя не факт, что разборки с кучей отменяются!).
• Став менеджером, следует избежать микроменеджмента и перестать вникать в мельчайшие особенности разработки, в каждую строчку кода, — нужно дать возможность команде решать задачи разработки. Однако часто менеджер, выросший из программиста, продолжает просматривать билды и отдельные коммиты, нередко даже сам продолжает писать код. однако рано или поздно объём серьёзных менеджерских задач вытеснит такую возможность, поэтому важно правильно выстроить делегирование в команде.
• Менеджер — это не айтишный бюрократ и не боец на тёмной стороне. Это человек, который способен применить свой опыт для того, чтобы сделать живой идею продукта, создать ПО, которым можно пользоваться и которое способно приносить пользу.

Как по мне, нет причин для беспокойства

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

С автоматизацией можно перестараться. В теории. На практике ощущается вечная недоавтоматизация.

И да, вам придётся столкнуться с этой картинкой в жизни 🙂

Главное — очень-очень любить свой продукт. Иногда, конечно, вопреки 🙂

Итак, вы менеджер. Долгое время вы были разработчиком, инженером, многому научились в проекте. Теперь вы получаете новый опыт, ответственность и деньги в обмен на огромный объём работы, много давления и необходимость принимать сложные решения. Вы видите возможности и можете влиять на развитие бизнеса.

Что придётся принять?

Есть несколько вещей, которые нужно принять в роли менеджера: риски, умение прислушиваться к критике и реагировать на неё, новая мера ответственности, умение принимать жёсткие и иногда непопулярные решения. Придётся стать лидером своей же команды. Впрочем, если вы доросли до менеджера разработки, скорее всего, вы уже были неформальным лидером.

Самый большой страх

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

Как научиться быстро

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

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

1. Самая дешёвая и вполне адекватная возможность — найти наставника в компании, который позволит вам войти в новую колею. Это может быть глава департамента, опытный менеджер или даже генеральный директор, особенно в небольшой компании. Сотрудник, зная свою сторону работы, быстро освоится и изначально будет знать о проблемных точках проекта.
2. Углубиться в книги, блоги, материалы, заняться самообразованием. Отличное решение, но оно займёт много времени и будет иметь теоретическую основу. Скорее, это обязательное дополнение к любому из перечисленных способов.
3. Пойти на второе высшее, в магистратуру, на сложные курсы. Ну, если у вас есть время и деньги… На самом деле, это довольно затратно и не всегда эффективно — фишечка вузов, понимаете ли: есть учебный план и неприкаянные преподаватели, поэтому кроме нужных вещей вы будете изучать разную -логию. Впрочем, если вы студент последних курсов или хотите войти в ИТ уже не просто джуниором, но и подающим надежды молодцом, можете попробовать свои силы.
4. Получить степень МВА. Дорого, сложно, жрёт много времени, региональных работодателей не впечатляет. К тому же, хороших программ в России мало. Обычно на MBA решаются топы или почти готовые топы крупных корпораций, в которых это добавляет веса. Но, по нашему опыту, в ИТ-сфере ценятся несколько иные навыки: мозги, опыт, умение работат.

Внимание, Нижний Новгород, мы ищем менеджера!

Нижний Новгород, мы ищем таланты! Мы разрабатываем и внедряем RegionSoft CRM. Порой это очень (ОЧЕНЬ) сложные и длинные внедрения и интеграционные проекты. Нам нужен менеджер с навыками программирования. Проще говоря, ищем толкового парня, который сечёт в разработке, умеет выбивать из людей требования, составлять ТЗ, убеждать, что для облёта поля пшеницы 4 кв. км нужен кукурузник, а не «Боинг», даже если есть деньги на этот Боинг 🙂 Возраст значения не имеет, опыт — имеет, и огромное. Записывайтесь на собеседование по адресу contact@regionsoft.ru и приходите поговорить. Территориально Сормово, удалёнка невозможна. Работа суровая, не говорите, что не предупреждали. Люди хорошие, руководитель адекватный.

Наш пока живой Телеграм-канал BizBreeze. Всякое про CRM и бизнес, по уму, без копипаста и на 90% без рекламы. Подписывайтесь.

Должен ли программист получать больше своего менеджера?

©

Теперь, собственно, разберем топик на запчасти. В ИТ-шной конторе менеджер — понятие размытое, как облачный сервис, поэтому сначала определимся с функционалом менеджера:

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

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

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

Почему, соответственно, нередко программисты получают все же больше?
Два варианта:

• крайне редкая ситуация, когда программист уникальный гуру, обладающий уникальными же знаниями, без которых проект вообще не живёт. Эта ситуация встречается куда реже, чем программистам хотелось бы думать 🙂
• корявая организация (которая распадается на подварианты — «ответственность раскидана как попало на кого попало», и «принцип ответственности руководству неизвестен или непонятен»)

Типичный пример «как попало» — есть девочка, у которой есть английский, она общается с клиентом, есть командир, например, спецов по Перлу, у которого есть команда, и есть некий человек, которому поручено делать планы в МС Проджекте и бегать к начальству на доклад. Этот человек, заодно, вроде как командует проектом. Далее, у командира перлистов и так хватает геморроя, его люди тянут три проекта, это четвертый, овертаймы уже норма, и так далее.

Девочке, в общем-то, все пофиг, так как она студентка последнего курса, рада иметь хоть какую-то работу, но платят ей копейки, а потому энтузиазма у нее нет. Ах да, и решать, какие фичи в проекте будут, а какие нет — поручено лично программисту Васе, т.к. перловщик занят, а начальник и девочка не отличают Foxbase от ftp protocol.

Знакомая картина? Кстати, pay grades в этой ситуации могут быть вообще раскиданы «Великим Белорусским Рандомом», плюс, могут постоянно возникать конфликты из-за зон ответственности, прав на юзание тех или иных сотрудников, дележка серверных ресурсов и проч.

Типичный пример «непоняток» — любимый программист начальства получает зп Х денег, т.к. он ценный и так далее, а командир этого программиста и еще пары десятков тестеров, дизайнеров и прочих сисадминов, получающий по голове сверху, от начальства, и снизу, от подчиненных, с убитым здоровьем, порванными нервами и седыми волосами — едва за 30 — получает 0.7Х денег. Потому, что «программиста фиг найдешь», а «менеджеров этих развелось, как собак».

Тоже знакомо, да? Менеджеры среднего звена — самая нелояльная часть постсоветских ИТ-компаний, и, нередко, с полным на то основанием, ведь жизненная ситуация такого менеджера (реальный случай, детали изменены) : «прикинь, у Васи, который просто средний программер на Яве, зарплата 3 000, а у меня, которому приходится возиться с сотрудниками, 3500. ». Как относится такой условный менеджер к компании и к начальству? Ага.

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

Собственно, а как надо? Есть у меня положительный пример решения этой проблемы из другой отрасли. Из аудита (не следует, однако, полагать, что я предлагаю их практику один в один скопировать).

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

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

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

Интересны и ваши мысли по данной проблеме 🙂

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

Схожі статті

Коли та як варто підвищувати зарплату розробнику

Віталій Федоркович 5 березня 2021

Пригоди програміста-фрилансера в Азії, або Зарплатна халепа

Anvar Azizov 7 лютого 2019

Найкращі коментарі пропустити

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

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

Толстый толстый тролинг )
могу сказать по ситуации в Норвегии в определенной большой компании вожделенного многими банковского сектора — т.к. есть публично доступная информация по доходам.
Во всех командах PM был чуть ли не самым низкооплачиваемым специалистом.
Проблема в том что 90% вещей что делают PM в типичной аутсорц компании может делать любая старая уставшая обезьяна

В общем кончайте надувать щеки — не отвлекайтесь от получения очень ценного MBA никому не извесном вузе

Определять размер з/п по степени взмыленности — путь в никуда.

Капитан О. кагбэ подсказывает нам, что менеджер, увы, понятие размытое не только в айтишной конторе. Менеджер туристического или рекламного агентства, ага. Девушка/юноша «чего изволите?» с тремя телефонами на столе, двумя в сумке и ещё один дома забытый.
Так вот. Почему акканут-менеджер — это именно менеджер, а не рядовой линейный клерк — аккаунтер? Почему менеджер проекта — это менеджер, а не линейный клерк — планировщик?
И почему в таком случае программист — это не «код-менеджер»? Человек, который знает функционал и особенности каждого модуля и технологии, обсуждает эстимейшены, отвечает за своевременность и полноту функционирования проекта. Менеджер? Менеджер. Почему тестировщик — это не «кволити менеджер»?
Тот же аккаунт-мнгр вступает в действие тогда, когда сейлс (который действительно менеджер) поработал печенью и принял решение — да, мы берём этот проект, потому что мы можем на нём заработать. Планировщик вступает в действие тогда (менеджера команды, кстати — тоже туда же, в планировщики), когда менеджер продукта (или сервиса) принял решение, как (должен будет) выглядеть продукт со стороны потребителя — потому что в этом случае он понравится потребителю и мы сможем на нём заработать.

Вот как-то так. ТруЪ менеджеров гораздо меньше, чем титульных, и они УЖЕ зарабатывают больше девелоперов и не заморачиваются подобными вопросами.

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

Лично знаю, что у нас есть и другие отрасли, где подчиненные получают больше начальников.

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

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

Чем программисты хуже?

497 коментарів

Alexander Shapoval Software Developer (Intertech) 17.12.2012 14:57

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

С ног на голову.
Как раз стремление удержать свой рейтинг аудитора, а соответственно рейты и маржу приводит к построению вертикали по мере ответственности.
«Перед угрозой близящейся проверки спрос на адиторские услуги и услуги адвакатов перестает быть эластичным».

Вы еще американскую систему здравоохранения возьмите, — «Должна ли медсестра получать больше врача?»

Знание размеров чужих зарплат умножает скорбь.

Oleksandr Korobov Software Developer 24.09.2012 12:06

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

Oleksandr Korobov Software Developer 24.09.2012 12:03

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

Если бы нашим менеджерам да образование.

// Лягушкам только образования не хватает, а так они на все способны. Марк Твен.

Andrey Varnava Game Developer (Patriotic Games) 13.04.2012 17:46

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

Edik Oganesyan connecting people 18.01.2012 23:57

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

Антон Пушков Software Engineer в Roku 11.11.2011 19:11
статистика из гугла по этому поводу www.glassdoor.com/. aries-E9079.htm

видно что сениоры зарабатывают больше продукт менеджеров

Valentine Golovach Product manager в DOU.ua 20.01.2012 14:29

Ну медиана у продакт менеджеров выше чем у сениоров. Все относительно.

Valentine Golovach Product manager в DOU.ua 20.01.2012 14:30

Ну и 60 голосов против 1508 🙂

К тому же, следует упомянуть о рисках, с которыми связана работа менеджера — в первую очередь, карьерных: кого сокращают в первую очередь? менеджеров; кто понесет ответственность за провал проекта? менеджер, конечно; программисты требуются всегда и в большом количестве — им работу найти легко. Менеджеров требуется гораздо меньше, и конкуренция гораздо выше. И придется побегать.

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

Антон Пушков Software Engineer в Roku 11.11.2011 19:14

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

А какая, по-Вашему, должна быть ответственность? уголовная? )))
Да, это штрафы, увольнения, но, главное — подмоченная репутация ПМ-а. Если девелопер что-то напартачил, то виноват не девелопер. И если тестировщик не нашел баг, то тестировщик не виноват. Виноват менеджер, допустивший это. Что касается примеров, я не знаю, какие менеджеры Вам известны, чтоб привести очень известный пример. Если в Вашей компании настроен процесс, похожий на Скрам, то, скорее всего, ответственности как таковой мало. Скрам ориентирован на мотивацию и лояльность команды, при неограниченных бюджетах вроде time&material. Примеры «ответственности» можно найти в унифицированных процессах типа RUP или Agile UP, часто с фиксированной моделью цены, которые в большей степени ориентированны на результаты и успех проекта (но они более строгие, и по мотивации проигрывают тому же скраму): клиенты платят только за результат, а не за потраченное время на кодинг и тестинг. Если Вы, как ПМ, обозначили майлстоун и обсудили его критерии с клиентом, и потом не выполнили обязательств (не уложились в сроки, бюджет, не учли риски) — то это Ваш личный факап, а не команды. Иначе говоря, не обеспечили оговоренные результаты, при том, что сами и оценивали. Здесь персональная ответственность.

Пример: клиент настаивает на сдаче проекта в сентябре, т.к. в конце сентября он хотел бы показать продукт на выставке и, возможно, обеспечить пиар или перепродать. Оценка скоупа проекта по длительности занимает, к примеру, 6 месяцев, и конечная дата — в середине декабря (и это только девелопмент! а еще ведь тестирование, деплоймент и т.д.). Т.е. с имеющимися ресурсами невозможно уложиться к началу сентября. В этой ситуации, можно нанять большее количество исполнителей в команду, но при этом необходимо очень четко представлять себе critical path, т.е. строгую последовательность задач, которые ни при каких обстоятельствах не могут выполняться параллельно. За счет же «параллельных» задач, можно выиграть время. Если этот планируемый выигрыш, с учетом возможных рисков, позволяет Вам уложиться в предлагаемые сроки. То можно стартовать. Причем, клиент должен быть готов оплатить привлечение новых ресурсов. Если это не так, то не стоит что-либо обещать.
Если же идете на поводу клиента, то будьте готовы к риску провала («пообещал — и не сделал» — не уложился в сроки, вышел за рамки бюджета). Т.е. клиент потратил деньги, а результат не обеспечен. И никого не волнует, что Вы не смогли быть достаточно хладнокровным. За это вполне могут уволить менеджера (может зависеть от степени — финансовой, репутационной).

Антон Пушков Software Engineer в Roku 12.11.2011 14:31

почему то когда заходит разговор о менеджере, то имеется в виду такой «сферический менеджер в идеальном мире», а вот только заходит разговор о 23 летнем сениоре, так берется вполне реальный 23 летний сениор.
возможно в идеальном мире все и происходит так как вы описали, но я хотел бы реальных примеров, с жертвами, типа: менеджер К нафакапил за что быо положен в багажник машины и вывезен в лес, с тех пор его никто не видел, экспертиза трупа найденного спустя 3 года, показала что ДНК соответствует ДНК менеджера К — программисты любят такие истории, так как они в нашем мире практически невозможны, но при этом менеджеры факапят очень часто и типично вместе с перекладыванием обязанности, они перекладывают и ответственность.
ну и из вашего поста не видно за что платить, допустим вернемся в идеальный мир в котором не каждый программист становится сениором, но каждый менеджер закончив институт становится менеджером, внимание вопрос: почему зарплата менеджера должна быть больше, если сениором стать намного сложнее?

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

надо еще пожаловаться «почему продавцами становятся сразу, а токарями 5го разряда — надо попотеть?»

Антон Пушков Software Engineer в Roku 12.11.2011 15:05

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

вас это беспокоит? ©

еще раз намекну: «почему пилотами становятся сразу после училища, а токарями 5го разряда — надо попотеть?»

Антон Пушков Software Engineer в Roku 12.11.2011 16:39

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

приведите мне хоть один пример где менеджер чем-то рискнул.

а менеджеры ничем не рискуют, да и ответственности у них особо никакой.

внезапно выяснилось, ага 🙂

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

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

приведите мне хоть один пример где менеджер чем-то рискнул.

жду с нетерпением примеров про программеров

Антон Пушков Software Engineer в Roku 12.11.2011 17:43

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

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

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

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

там и будут ответы на твои вопросы.

ну и как бы на моей памяти программистов увольняли сильно чаще менеджеров

наверное потому, что программеров сильно больше, чем менеджеров, не?

я даже не могу припомнить случаев, когда менеджеров бы штрафовали

ага, они конечно же сразу бежали к вам жаловаться, что их оштрафовали, при этом улюлюкая «НЕСПРАВДЛИВО ЖЕ!».

которого оштрафовали за грустное лицо

программиста сначала оштрафовали а потом уволили за то что он победил своего начальника

вы решили нас удивить примерами человеческой тупизны?

Антон Пушков Software Engineer в Roku 12.11.2011 17:51

вы решили нас удивить примерами человеческой тупизны?

от которой обычно страдают типичные землекопы ИТ индустрии, а не менеджеры.

а менеджеры боги ИТ значит?

Владимир Кравченко Senior Developer 08.08.2012 12:28

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

и что это доказывает?

там ПМ случайно не оказался по совместительству учредителем или «своим»? и если вы там такие дружные, чего же молча все ушли,а не рассказали кто из вас Дартаньян?

Владимир Кравченко Senior Developer 10.08.2012 00:46

Не был ни своим ни учредителем, просто инвестору умело доносилось что не ПМ бокопорит а во всем виноваты злобные девелоперы и так два года, при этом ивестор доверял этому ПМу который под конец моей работы только начал читать книжки в стиле как вести свой проект для чайника. Потому и не донесли что все занимались работой в отличии от ПМа который успешно прикрывал свой зад типа неквалифицированностью всех остальных, но когда всех выгнали думаю инвестор понял наконец-то что дело не в команде, ну а если и не понял, то могу только посочувствовать, так как он еще долго будет оплачивать работу этих бездарей, а я в этот проект хотел вложить всю свою душу и когда шел к ним думал буду работать долго и почти как над своим проектом и за 8 месяцев провел в офисе не одну ночь 🙂 Да и все кто ушли пошли в более крупные группы и на большую зарплату, где все по-моему успешно и работают. Хотя тебе уже конкретный пример привел, а ты все продолжаешь препираться! Ты наверное из таких ПМов, которые пытаются инвесторы что кодеры гавно попались и без них проект проживет, и меняя их перчатки, заваливает очередной проект, а потом через год-два уходит на другую работу а в резюме пишет, что закончил предыдущий проект на должном уровне Ж)

это вы ко мне обращались?

А вообще, что мешало пойти к инвестору всей толпой и сказать «Вася-ПМ охренел, гоните его в шею»? Страшно, лениво, хомяческий инстинкт, «само рассостется»?

Владимир Кравченко Senior Developer 11.08.2012 15:46

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

«А Баба-Яга против!» :)))

Примеры вам выше привели — и с точки зрения работодателя в том числе.

С другой стороны, я подчеркивал несколько раз (!) что менеджер необязательно может зарабатывать больше разработчика. А вы все какие-то страшилки рассказываете )). Кто же это вам так насолил? ))

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

а в чью пользу забрали? не в вашу ли? ))

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

Это РАЗНЫЕ профессии, и оцениваются они по-разному. Программист Java зарабатывает в Киеве больше многих Пмов. Почему вы не сравниваете Java с С++? Переквалифицируйтесь, и зарабатывайте больше. При этом, не надо быть «ненавистным» менеджером )))). Задачи менеджера находятся в другой плоскости — организация, планирование, мотивация, контроль.

Если зарабатывает он 3к, значит, в рамках своей квалификации он стоит 3к.

А вы в рамках СВОЕЙ квалификации, возможно, не стоите 3к (хотя искренне вам желаю, чтобы стоили, и даже больше )))))

Надеюсь, вы не сравниваете себя с пилотами — уж вы -то точно ничем не рискуете по-сравнению с ними.

Антон Пушков Software Engineer в Roku 12.11.2011 18:10

Надеюсь, вы не сравниваете себя с пилотами — уж вы -то точно ничем не рискуете по-сравнению с ними.

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

Программист Java зарабатывает в Киеве больше многих Пмов.

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

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

а кто-то исходит из других критериев?

Антон Пушков Software Engineer в Roku 12.11.2011 18:17

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

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

Антон Пушков Software Engineer в Roku 12.11.2011 19:06
вот я ж тут и пытаюсь узнать, какого плана?

ответственность над всем проектом не предлагать, это и есть работа менеджера — знать что происходит в его части. сказать что ответственность больше нельзя.

знать что происходит в его части.

у вас весьма ограниченное представление об ответственности 🙂 но таки да, звучит именно так:

ответственность над всем проектом

в том числе за кусочек кода в репозитории.

Антон Пушков Software Engineer в Roku 12.11.2011 20:18

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

мда уж 🙂 ничего не меняется 🙂

Антон Пушков Software Engineer в Roku 12.11.2011 21:47

есть особое мнение на этот счет?

С автором статьи, допустим, я не во всем согласен. Но реальность именно такова — джавист зарабатывает больше. А в GL недавно Хмиль афишировал зарплату Python разработчика/архитектора в размере 4,5к (так что далеко не все менеджеры согласны).

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

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

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

Антон Пушков Software Engineer в Roku 12.11.2011 19:01

насчет меня, я могу заработать больше даже не переходя на яву, и я не против что кто-то зарабатывает больше, лишь бы это было заслуженно.
допустим мой теперешний менеджер зарабатывает больше меня и я с этим согласен, он этого стоит. более того, на оценивании он просит написать на него что нибудь плохое, потому как если ничего плохого не написать, то его начальство не поверит в правдивость анкеты, но писать особо нечего. мы видим его неделю в месяц, типичный мой разговор с ним: «How are you, Anton?» — и ответ «I’m fine» его устраивает вполне.
Это первый менеджер за мою пятилетнюю карьеру (соврал, был еще один), которого я считаю частью команды, а не человеком который приносит плохие новости, как это было до этого.
Но сколько таких как он? я люблю потролить менеджеров, особенно я люблю потролить менеджеров которые приходят на работу за деньгами. То есть если для программистов такое поведение приемлемо, то менеджер, которому пофиг на проект, вообще не должен получать зарплату и таких большинство, у нас в геймдеве таких сразу видно. я сужу не только о тех с кем я работал, сюда попадают и те к кому я приходил на собеседование.
в этом треде много раз обсудили сферически идеального менеджера, но если таких наберется 5% из всех менеджеров, то это уже будет успех.

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

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

так зарабатывайте :))) в чем проблема?

мы видим его неделю в месяц, типичный мой разговор с ним: «How are you, Anton?» — и ответ «I’m fine» его устраивает вполне.

У вас, видимо, свое специфическое представление об идеальном менеджере 🙂 Но это дело вкуса.

То есть если для программистов такое поведение приемлемо

Если вы так считаете, то точно не стоите тех денег, за которые работаете, вы стоите дешевле.

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

Должен вас разочаровать — за риски (в т.ч. исходящие со стороны команды) в проекте отвечает ПМ. Учите матчасть.

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

Антон, открою вам маленький секрет: в лице менеджера кастомеры хотят видеть человека, который будет экономить их время и деньги, — это волнует любого клиента. Коммуникации играют очень большую роль — клиент хочет получать объективную и полную информацию в любой момент. Клиенты хотят видеть менеджеров, грамотно (!) расходующих его средства и время, именно поэтому они готовы (! это не значит, что обязательно должны!) платить бОльшую зарплату, чем разработчику. Если бы клиенты общались напрямую с разработчиками, это привело бы значительным временным потерям (если команда к примеру, нет смысла общаться с каждым, — даже если вы владеете английским, и, не дай Бог, другими ин. языками, это еще не означает, что вы хороший communicator).

Далеко не каждый разработчик способен выполнять эти функции.

Поэтому, менеджеры МОГУТ зарабатывать больше разработчиков. Но и программист МОЖЕТ зарабатывать больше менеджера. И никто никому ничего НЕ ДОЛЖЕН.

Желаю вам избавиться от стереотипов :))

Антон Пушков Software Engineer в Roku 12.11.2011 20:09

Если вы так считаете, то точно не стоите тех денег, за которые работаете, вы стоите дешевле.

я считаю что программисты имеют право работать с 9 до 6, а овертаймы это уже проблемы менеджера, но при этом менеджер с одной стороны должен быть доступен всегда, с другой стороны вообще невидим.

ну а про остальное, разве это не суть работы менеджера — управлять?

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

Антон, о зарплате менеджеры договариваются напрямую с клиентами в единичных случаях — разве что на более высоких позициях. ПМ — это такой же наемный сотрудник, как и вы. Зачастую есть директор, HR, которые и ведут переговоры о ЗП. То же касается всех остальных позиций в команде. Менеджеры чаще оперируют человеко-часами в бюджете, чем долларами.

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

Так и не увидел ваших конкретных аргументов — чем измеряется польза менеджера в проекте?

очевидно же, если нравится разрабу — значит годный менеджер 🙂

Антон Пушков Software Engineer в Roku 12.11.2011 20:13

еще скажите что не согласны с этим

Антон Пушков Software Engineer в Roku 12.11.2011 20:12
я сам хочу найти ответ на этот вопрос, потому как риск и ответственность меня не устраивает.

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

Задача Пма — привести проект к успеху. Для этого ему даны инструменты — time, scope, quality, risk, integration, cost, communication, HR (это то, что описывает PMBOK framework). Это целая наука, которой занимаются специалисты проектного института в США (PMI). Но в наших IT далеко не всегда эти инструменты в наличии, особенно, если компания изначально задумывалась как аутстафф. Количеством этих инструментов в большинстве случае и определяется власть/ответственность ПМа, плюс количеством проектов. Кроме того, важно понимание процессов разработки софта — например, RUP, Agile, MSF, и методологий управления проектами — напр. ITIL, или Scrum (хотя это очень громко звучит для скрама). Пример: процесс игровой индустрии + scrum. Процесс+методология. Из опыта могу сказать, что важна не новизна процесса, а то, насколько эффективно он настроен/адаптирован в компании.

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

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

В классических проектах «температура» проекта, если так можно выразиться, определяется ключевыми показателями, или метриками.

Например, SPI — schedule performance index (как проект идет по графику), QA (с каким качеством), также можно определить скорость проекта (в COCOMO есть формулы), показатели бюджета — actual costs, например, earned value и т.д. Т.е. здесь все зависит от необходимости контроля того или иного показателя. Чем положительнее эти показатели, тем полезнее ПМ, в задачи которого входит обеспечение этих метрик (например, еженедельно).

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

Антон Пушков Software Engineer в Roku 12.11.2011 21:41

спасибо за информацию.

Антон, искренне желаю вам удачи и хороших менеджеров!

Антон Пушков Software Engineer в Roku 12.11.2011 21:55
сейчас у меня в этом плане все в порядке.

хотя кто его знает, может бывает и лучше.

как не рискуют? даже водители погрузчиков рискуют:)

еще раз намекну: «почему пилотами становятся сразу после училища, а токарями 5го разряда — надо попотеть?»

ну это уже полный бред.

на очень ценно ваше мнение, хотя логики вам бы стоит поучиться.

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

разложу по полочкам, почему заявления типа вашего полный бред:
1. вы сравниваете сферического пилота и конкретного токаря 5го разряда.
2. формально, пилотом вы сможете стать даже после летной школы, но каким — пилот-любитель. токарем вы можете стать, в лучшем случае, закончив ПТУ.
3. а вот теперь возьмем и сравним двух реальных персонажей;)
возьмем требования несферического «Аэрофлота» для кандидата на пилота/комондира судна:
Образование: высшее авиационное или техническое
Знание англ. яз. не ниже 3 уровня по шкале ИКАО
Свидетельство линейного пилота
Общий налёт не менее 4000 ч.
Для КВС налёт не менее 500 ч.
Налёт на ВС с кабиной ’glass cockpit’ не менее 1000 ч.
Перерыв в лётной работе не более 5 лет (для кандидатов на переучивание)
Проводится дополнительное обучение/переучивание
Уровень знаний англ. яз., достаточный для переучивания в Тулузе (AIRBUS)
а специально для сферических личностей вашей породы с каспаровской логикой, добавлю, что первый класс линейного пилота присваивается: пилотам многодвигательных самолетов, имеющим: общий налет 4000 часов; из них: самостоятельный налет на указанных в настоящем пункте самолетах не менее 1000 часов или общий самостоятельный налет не менее 1500 часов, из которых 500 часов — на многодвигательных самолетах.

а дальше еще требования к налету ночных часов и т.п.

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

Попотеть придется и там и там, но пилот первого класса и токарь или разряда просто не сравнимы, как небо и земля:))

удачи с логикой! учи матчасть;)

P.S. сидеть за шрурвалом самолета с сотнями людей на борту — это не ступором с режушим интрументом ворочить.

это конечно хорошо, что вы хамоваты, с быдляческими нотками, в жизни может пригодится, но ваши излияния мимо кассы. Жаль что вы не видите разницы между профессией и квалификацией, видимо на курсах ПХП, точнее актуального андрйда, этому не учат. Хотя 23 летние синьоры, ой, джуниоры, нас жизни и не так научат, построят комунизм 🙂

не нужно завидовать так громко;)

еще бы, удаляюсь в лучах вашей неотразимости 🙂

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

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

программисты любят такие истории

На моей памяти ни разу не увольняли девелоперов. Даже слабых джуниоров сегодня «холят по холке и лелеют по лелейке» 🙂 Если же вы работаете в такой компании, где увольняют девелоперов за промахи Пма, — сочувствую. Я никогда ни на кого не перекладывал ответственность, возможно, потому, что начинал карьеру в компании, где эта ответственность была строго определена. На должности Пма я, как ни странно, занимался работой Пма.

Ваша патологическая ненависть к менеджерам, судя по описанному примеру :), вызвана личной неприязнью. К тому же прослеживается мысль «менеджер должен отвечать за все, а я только за свой участок работы». Вы абсолютно правы, но, возможно, поэтому и финансовая мотивация у менеджера выше? Задайте тот же вопрос о зарплате своему работодателю. Станьте менеджером, и докажите, что готовы работать за те же деньги :), и что все вокруг неправы.

Возьмем пример «старой школы». Если вы опытный программист, обладающий лидерскими качествами, и вам предлагают должность ПМа в той же компании, то как работодателю мотивировать вас бросить заниматься программированием, и начать заниматься совершенно другим делом? Плюс получить карьерные риски? Хотите ли вы сами этого? Готовы ли Вы зарабатывать при этом меньше? Уверен, что нет.

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

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

Антон Пушков Software Engineer в Roku 12.11.2011 17:33

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

мне кажется более полезное занятие — становиться более сениористым сениором.

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

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

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

Вам не надоело сравнивать теплое с мягким? всмысле сравнивать профессию с лычку абстрактного разработчика.

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

Антон Пушков Software Engineer в Roku 12.11.2011 17:46
вот и я о том же, работа равнозначная а зарплата почему-то не равнозначная.

и вообще не понятно, почему до сих пор нет мема о 25 летнем менеджере, по моему это ржака покруче чем 23 летний сениор.