Сколько зарабатывали менеджеры проектов различных профилей в 2022 году. За исследование спасибо Артёму Летюшеву.

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

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

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

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

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

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

Качество системы определяется двумя параметрами:

1. Предсказуемость выдаваемых результатов.
2. Способность к самостоятельной работе.

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

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

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

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

1

Error happened.

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

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

Есть три основных аспекта, которые сильно влияют на нужность дедлайна.

Творчество и НИОКР

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

Изменчивость среды

Также имеет значение, изменчива ли среда, в которой делается задача. Меняется среда — меняются параметры задачи, едут сроки. Поэтому в постоянно изменяющихся условиях от жёстких дедлайнов мало толку. Готовность к изменениям важнее следования плану.

Состояние процессов

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

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

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

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

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

А вот исходный файл (Minjet Mindmanager).

Вот ещё хороший пост про передачу дел:

1

Error happened.

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

Сначала нужно выучить терминологию, например, по этой статье.

Софт для календарно-сетевого планирования

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

Лучшее решение, которое я видел — плагин BigPicture для Jira. Позволяет брать реальные эпики и таски из джиры и из них делать «колбаски» ганта. Состояние задач в диаграмме будет апдейтиться автоматически. Даём гостевой доступ заказчику и ссылку на эту диаграмму и наступает общее счастье.

Если этот вариант невозможен, придётся использовать Microsoft Project для винды или аналоги для макоси, вроде Merlin Project или Omni Project. Все они устроены примерно одинаково.

Принципы ООП и основы программирования

Для того, чтобы понимать в речи разработчиков что-то, кроме предлогов, основы программирования знать и понимать нужно. Разберитесь, что такое переменная, цикл, ветвление, массив, класс, подкласс, экземпляр класса, объект, метод, интерфейс. Многое сразу станет понятно.

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

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

Умение собирать требования и писать ТЗ

Скорее всего, вам придётся начинать карьеру в маленькой компании, в которой на всех экономят, в том числе, на аналитиках, поэтому выяснять, что же нужно сделать в рамках проекта и оформлять всё это в читабельное ТЗ нужно вам. Пробегите Вигерса, хотя бы по диагонали, станет легче.

Да, в скраме нет ТЗ, там есть стори. Но легче от этого не становится, фичи всё равно, нужно расписывать, если этого не делать, разработчики закодят трешню. А если закодят не трешню, на этапе приёмки заказчик вам скажет, что имел в виду не это и вы ничего не сможете доказать, придётся переделывать.

Базы данных вообще и SQL в частности

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

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

Иногда бывает полезно уметь составить простенький запрос к какой-нибудь таблице с каким-нибудь условием.

Вот, например, код, выгребающий из одной базы подробную статистику трудозатрат по идентификатору доработки:

declare @id nvarchar(1000)
SET @id = 'CAS-191131-B8B3'


SELECT ROUND((SUM([Затраты])* 24), 2) as 'Итоговые затраты'
FROM [STAdministrationResource].[dbo].[vw_DO_TFS]

WHERE Затраты IS NOT NULL 
AND [Запрос.Номер CRM] LIKE @id


SELECT Роль, ФИО, Тикет, ROUND((SUM([Затраты])* 24), 2) as 'Затраты'
FROM [STAdministrationResource].[dbo].[vw_DO_TFS]

WHERE Затраты IS NOT NULL 
AND [Запрос.Номер CRM] LIKE @id

GROUP BY Роль, ФИО, Тикет
ORDER BY Роль, ФИО, Тикет

GO

Более сложные запросы нужны реже, можно попросить программиста помочь.

REST и SOAP API

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

Научитесь читать и редактировать XML и JSON файлы. Если сильно не повезёт, вам могут поручить и проектирование API, у меня такое было раза три за карьеру.

Много очков в глазах работодателя даёт умение пользоваться Postman. Изучите его, он интуитивно понятный.

HTML и CSS

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

Потом научитесь пользоваться консолью разработчика, хотя бы в одном браузере. Очень важно уметь посмотреть, какие стили применились к данному элементу страницы и если надо, их подправить. Также нужно уметь пользоваться консолью ошибок, потому что первый вопрос, который вам задаст разработчик в ответ на ваше: «На сайте ошибка», будет: «Что в консоли?».

Во всяких бутстрапах разбираться необязательно.

Устройство админки популярных CMS.

Скорее всего, в работе вы столкнётесь либо с Битрикс, либо с WordPress. Очень полезный навык — умение разобраться, где в админке поправить данный кусок контента и сделать это, когда это нужно срочно, а контентер уже спит.

Таблицы

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

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

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

Вот хороший телеграм-канал про секреты гуглотаблиц.

Основы девопс

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

Очень хороший ролик Дмитрия Ильенкова из PM Club о самых частых ошибках прожектов.

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

Менеджмент

Менеджер продукта

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

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

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

Если вы пиэм, продакт, как правило, не является вашим руководителем, скорее заказчиком.

Аккаунт-менеджер

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

Занимается тем, что уменьшает количество вашего общения с заказчиком, беря его на себя. Часто берёт на себя оформление различных юридических документов при поддержке юристов. Поддерживает с заказчиком хорошие отношения, часто допродаёт услуги (иногда не посоветовавшись с вами). Если аккаунт технически подкован, ему можно делегировать встречи по статусу проекта, но я бы рекомендовал делать это самостоятельно.

Эйчар

Эйчары бывают как в продуктовой, так и в заказной разработке.

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

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

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

Технический директор

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

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

Разработчики

Тимлид

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

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

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

Фронтенд-разработчик

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

Если в двух словах, он делает две вещи. Чтобы итоговая страничка выглядела строго так, как в дизайне, причём на всех поддерживаемых разрешениях, включая мобилки. Называется «интеграция вёрстки». И чтобы интерактивные элементы на странице вели себя правильно, анимации воспроизводились, кнопки нажимались и всё такое. Кроме того, подключается к API, созданном бэкендерами, забирает из него данные и красиво отображает на странице. Но если API пока не готово, умеет отображать вместо реальных данных моковые.

Делает он всё это, как правило, на JavaScript. В чистом виде JS используется редко, чаще применяется один из JS-фреймворков, например React, Vue или Angular.

Бэкенд-разработчик

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

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

Хорошие бэкендеры владеют несколькими языками программирования: C++ или C#, PHP, Python и фреймворками, которые сильно облегчают им бэкенд-разработку. В случае, например с PHP, это Laravel или Symphony, для Python популярен Django.

Если нет девопса (о нём ниже), чаще всего вопросами гита и развёртывания тоже занимается один из бэкендеров.

Мобильный разработчик

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

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

Айосники обычно пишут либо на Swift (чаще), либо на Objective С (реже). Андроидщики — на Java или более новом Kotlin.Технически подкованные ведроводы, пищущие особо сложные приложения или игры, используют C/C++

У специалистов по кроссплатформе всё сложно.

Quality assurance

Мануальный тестировщик

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

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

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

Когда-то путь тестировщика считался самым простым способом входа в айти. В 2022 требования к ним сильно выросли, современный тестировщик должен уметь развернуть на своём компе ветку разработчика, постучаться в API при помощи Postman или Swagger, отлично уметь пользоваться консолью разработчика в браузере и не только в Хроме, а вообще во всех, уметь составить запрос к БД и многое, многое другое.

Самые системные и коммуникабельные тестировщики становятся лидами тестирования и начинают относиться уже больше к менеджменту.

Тестировщик-автоматизатор

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

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

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

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

Пишут автотесты они на скриптовых языках, прежде всего на Python и JS. Используют массу инструментов, например, Selenium и Protractor.

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

Дизайнеры

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

Функция UX (User Experience) ближе к аналитикам. В рамках этих задач дизайнер определяет, как будет работать интерфейс, его логика. Как сделать, чтобы интерфейс был максимально простым, не вызывал у пользователя желание обратиться в саппорт.

Функция UI (User Interface) уже чуть более «творческая». В рамках этих задач дизайнер определяет, как будет выглядеть интерфейс, его внешний вид. Эти функции неотделимы.

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

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

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

Аналитики

Бизнес-аналитик

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

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

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

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

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

Системный аналитик

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

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

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

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

Сисадминская братия

Системный администратор

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

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

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

В целом, они как электрики, вы с ними будете взаимодействовать редко, но без них жить невозможно никак.

Девопс

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

Эти ребята могут разворачивать процесс непрерывной интеграции и развёртывания при помощи разных инструментов — Git, Docker, Kubernetes, уменьшая тем самым головную боль программистов. Автоматизируют процессы в Jira, уменьшая головную боль всех остальных участников процесса и повышая связность системы. Также настраивает мониторинг всех развёрнутых контуров, контролирует работоспособность.

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

Администратор баз данных

Достаточно редкие звери в современной разработке, за 13 лет работы я встречал выделенного dba-шника всего один раз. Нужен там, где много баз данных, все они здоровенные и критически важные.

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

Чаще всего же на dba экономят и всё это делает девопс или сисадмин.

Прочие специалисты

Контент-менеджер

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

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

Особенно весело, когда на сайте часть информации сделана средствами CMS, часть хардкодом и нужно поменять и то, и то.

Маркетолог

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

Например, вас могут попросить реализовывать нетипичный интерактивный элемент на сайте, лендинг (обычно по готовому дизайну, с чёрным фоном, конечно же), современный маркетолог может запросить ещё и телеграм чат-бота.

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

Технический писатель

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

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

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

Чаще на техписе экономят и инструкции пишет либо кто-то из аналитиков, либо вы.

Специалист по информационной безопасности

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

ИБ — это уже чисто айтишники.

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

В общем, с этими ребятами надо дружить.

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

Сохранять молчание

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

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

Работать в нерастущей организации

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

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

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

Терять энтузиазм в случае отказа

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

Шантажировать

В статье о безответственных сотрудниках я писал, что если человек употребляет фразу: «Не нравится, как я работают — увольняйте», его надо аккуратно и быстро уволить.

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

Взял навскидку три серьёзные вакансии менеджера проектов на хедхантере:

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

Лучше сразу после школы начать работать.

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

На самом деле, у обладателя диплома гарантированно есть следующие качества:

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

Он совершенно точно адекватен как человек. Неадекватные вылетают после первой-второй сессии с гарантией.

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

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

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

Доводы при Биллов Гейтсов и Стивов Джобсов, бросивших университеты — чистой воды казуистика, таких людей ещё меньше.

В университете дают устаревшие знания.

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

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

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

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

Почему в вакансиях пиэма чаще требуют вышку?

Вышку в вакансиях требуют, чтобы отсеять некоторые категории людей:

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