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

Project manager (PM)
Наше все - человек, который отвечает за выполнение проекта за заданное время и в рамках бюджета.
Важно, «по определению» менеджер проекта контролирует именно планы, т.е. чтобы написанное в техническом задании было сделано вовремя и компания не потратила на это больше, чем заработала.
На больших проектах менеджеры проектов могут вообще не погружаться в технические детали.

Project manager officer (PMO)
Руководитель менеджеров проектов. Если такой роли нет, этим занимается CTO (технический директор). Когда в компании много проектов, кто-то должен распределять ресурсы между ними и контролировать работу PM-ов, это как раз PMO.
Если нам для проекта нужен дополнительный разработчик, который есть в соседней команде, мы просим его именно через PMO, а не нагло воруем (хотя второе и проще).

Delivery manager
Достаточно редкая роль и чаще это архитектор.
Менеджер доставки решений отвечает за техническую сторону проекта: определяет стек технологий, политики разработки, объясняет разработчиком, что и как у нас устроено внутри.

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

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

Product manager
Служит внутренним заказчиком для project manager-ов.
Отвечает за развитие продуктов компании, анализирует аудиторию, формирует гипотезы, прикидывает потенциальную прибыль.

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

Важный анонс!
Обещали - выполняем

7 июля (завтра) в 20:00 в прямом эфире общаемся с:
- Ex исполнительным директором и лидером мобильной разработки Сбера,
- Директором IOS Podlodca Crew,
- Head of mobile 3commas,
Евгением Ртищевым

Где пройдет
За час до интервью в канале появится ссылка-приглашение.
Присоединиться и задать вопрос сможет любой желающий.

Что будем обсуждать
Мы старые друзья, конкретного плана нет, но точно обсудим:
- Сбер, как место работы и культуру ведения проектов внутри
- Релокацию (Женя перебрался в иностранный стартап)
- Крипту (то, чем Женя занимается теперь)

Скоро начинаем!

В 20:00 стартует наше первое интервью с Женей, подключиться можно по ссылке
Тайминги: 1,5 часа (общение + ваши вопросы)

Это будет первый подобный опыт, минимум подготовки, максимум импровизации.

Успехом буду считать аудиторию в 20 человек.
Репосты категорически приветствуются :)

Мы это сделали!

Нас было не много, но получилось интересно, желание продолжать выросло🔥
Огромное спасибо @katleta3000 за интервью и каждому присоединившемуся❤️

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

7 красных линий
Минутка юмора

За много лет это по прежнему самая правдивая короткометражка про работу в корпорациях и не только:

https://youtu.be/8BctbPxfVQ8

Менеджмент в IT, Сбер, крипта и релокация

Интервью с Женей обработано, а чтобы картинка из zoom не была совсем скучной, немного поиграл в режиссера:)

https://youtu.be/yIZWcZw58e0

Unit test

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

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

Звучит полезно, но у юнит-тестов есть и обратная сторона медали:
1. Время на написание - создание теста занимает около 50% от написания самого функционала
2. Поддержка - если мы правим функционал, то придется править и тест этого функционала
3. Еще больше ошибок - если тесты написаны плохо, вам придется править и функционал и сами тесты

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

Давайте подытожим, каким проектам нужны юнит тесты:
1. Крупные проекты (5000 часов +)
2. Проекты с большой частотой релизов (CI/CD)
3. Проекты, у которых условия контакта завязаны на количество ошибок

PS Если хотите подробно разобраться в вопросе юнит-тестов, очень рекомендую почитать вот эту статью

Рубрика "Разбор вакансий"

Алгоритм действий по освоению любой профессии:
1. Открыть пару вакансий этой профессии, посмотреть требования;
2. Сопоставить требования со своими возможностями;
3. Отправиться гуглить пробелы.

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

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

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

Вам - знания, мне - контент, все в плюсе :)

Вакансия Менеджер проекта 80-100тыс., 1-3 года.

Предисловие
Начну с того, что если вакансия РП стоит меньше, чем 150 - это не чистый РП, а ассистент на выполнение всякой рутины.
Это не плохо, но при условии, что вам нравится проект или сфера проекта (например, вы стартуете в IT).

Разберем требования вакансии

«Координировать команду сервис инженеров»
Внимание! Руководитель проекта руководит проектами, а не сервисными инженерами!
Соответственно документации, этапов и процессов здесь не будет.

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

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

«Взаимодействовать с заказчиком и управлять его ожиданиями на всех уровнях ведения проекта»
Никогда менеджеру с зп 100 тыс не дадут контактировать с заказчиком на всех уровнях, к тому же важно, кто этот заказчик (внешний/внутренний)

«Выстраивать процессы на проекте»
Нормальное требование, это также рутина РП

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

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

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

Менеджер IT проектов в КРОК от 3 до 6 лет

Предисловие
На старших курсах Бауманки представители разных компаний хантили студентов на вакансии стажеров. Заманивали рассказами о перспективах и зарплатами (по тем временам около 10-20 тыс).
Представитель КРОК пол часа рассказывал, что у них настоящая спарта и ни о какой оплате не может быть и речи.
Некоторые пошли и не пожалели.
КРОК - это жесткая, но эффективная кузница с огромным арсеналом разнообразных проектов, зачастую из гос. сферы.

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

«Плотное взаимодействие с заказчиком, выстраивание партнерских отношений и управление ими, совместный поиск оптимальных решений»
Если вы sale manager, то коммуникации - это 80% вашей работы

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

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

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

«Контроль подготовки документации (договора, акты, календарные планы)»
Это Крок, это госы, 100% много бумажек. Из плюсов - также огромное количество шаблонов, аналитиков и тех. писателей в помощь.

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

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

Руководитель проектов по цифровизации в Сколково

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

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

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

«Контроллинг внедрений»
Разумеется :)

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

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

«Управление ресурсами (in-house разработка, подрядчики) для получения оптимального результата»
Все понятно, но стоит поинтересоваться, кто эти ресурсы, вероятно подрядчики (если это так, то важно узнать, outstaff или outsource)

От нас ждут:
1. Высшее образование
2. Опыт в цифровизации производственных процессов, он же опыт принуждения людей работать в чуждых для них системах
3. Опыт управления в условиях сильной неопределенности, он же классический быт проектов из Сколково
4. Знание рынка решений для производств Индустрии 4.0: ML/AI, DataScience, IIoT - пришлось немного погуглить и оказалось, что это просто страшные слова (почитайте сами)
5. Agile
6. Свободный английский

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

Налаживание процессов

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

Мой подход, который с удовольствием обсужу с желающими:

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

2. Проработка решения
Если на этапе анализа мы со всеми поговорили и все узнали, то теперь пора браться за дело.
Описываем, как по нашему все должно работать. Здесь нам очень понадобится умение составлять регламенты (а это документы, которые без воды, можно понять и можно применять).
Регламент не должен жить где-то у вас на гугл диске, он должен быть в корпоративной базе знаний (а если ее нет, то стоит начать с ее заведения).
Если есть объективные проблемы и несостыковки - зафиксируйте их (в правилах русского языка тоже много исключений).

3. Согласование решения
Возвращаемся к участникам из этапа анализа, демонстрируем наш результат, вносим правки.
Если участников много, иногда полезно предварительно обговорить это тет-а-тет или просто маленькими группами.

4. Внедрение решения
Вот теперь собираем большое собрание и доносим до всех, кого касается ваш регламент информацию, как они теперь будут жить.
Если предварительно вы честно провели пункты 1 и 3, то у вас будет сильная поддержка и все пройдет хорошо.

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

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

Руководитель проектов в Сбербанк страхование

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

Обязанности

«Декомпозиция стратегических целей Общества»
Интересно узнать, что понимается под "обществом" (коллеги из Сбера, подскажите), но в целом декомпозиция - обычное занятие РП (получить бизнес-постановку, уточнить ее и описать по человечески, разбить на задачки)

«Участие в разработке целей ГАК и стратегии Общества, работа с целями и метриками в JIRA, Confluence, Miro»
ГАК и "Общество" игнорируем, это на языке Сбера.
В части работы с целями снова вспоминаем SMART или гуглим, чем хорошая цель отличается от плохой.
JIRA, Confluence и Miro - обязательны к изучению любым РП, если не пользовались, то обязательно зарегистрируйтесь, посмотрите пару обучалок, сделайте шуточный проект (например, по ремонту в квартире).

«Участие в координации работы agile команд Общества, планирование и контроль соблюдения дедлайнов»
Слово "Участие" намекает на то, что кто-то этот процесс уже ведет, а мы идем в помощь (скорее всего пинатором-подгонятором).
Планирование обычно происходит в Jira или с помощью Ганта, вспоминаем азы скрама.

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

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

Хороших выходных!

https://www.youtube.com/watch?app=desktop&v=A4CnacPXXXg

Продвинутые возможности Jira

Jira - самый популярный инструмент для управления задачами.

Огромная часть работы в Jira связана с написанием JQL запросов (используются для поиска задач по разным критериям).

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

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

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

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

Что нас просят делать:

«Обучать и консультировать клиентов по штатному функционалу»
Мы что-то внедряем, соответственно мы должны консультировать клиентов о том, что им внедряем

«Разработка технической документации проекта (брифы, технические задания)»
Любой РП много работает с документами, запасайтесь шаблонами, изучайте структуры

«Составлять видеоинструкции и базы знаний»
Видеоинструкции - это несколько необычно, но и не то, чтобы сложно

«Информировать текущих клиентов о новом функционале/кейсах/сценариях»
Звучит просто, но на деле требует системного подхода и составления стабильной системы по сбору и отправке коммуникаций

«Вести документооборот (выставлять счета/акты в ЭДО)»
Совсем не задача РП, но и сложного в этом ничего нет, просто другой вид коммуникаций

Выводы
Приятная вакансия для новичков. Не согласен с требуемыми «3-6 лет опыта», но спишем это на опечатку (РП с опытом 3+ года не пойдет работать на 70тыс. зарплаты). Технических требований как таковых нет, больше ответственности и системного подхода к выполнению задач.

Разбор кейса из блога Юлии Бажановой

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

" Будни общения с разработчиками государственных информационных систем

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

Разработчики: – Ну учитывайте по цветам, что вам мешает?

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

Разработчики (а именно – девочка-методолог): – Но сапфиры ж голубые…

Мы: – Вашу мать, чаще всего голубые, но бывают коричневые, красноватые и вообще всякие разные!

Разработчики: – Упс, как неудобно вышло… Но вы сами виноваты, что раньше не подключились к тестированию, и не сказали нам! И мы теперь не знаем, что делать, придумайте сами что-нибудь.

У меня подгорало неделю, честное слово. "

Давайте напишем в комментариях, что должно было произойти, чтобы у Юлии не подгорало :)

Разбор кейса из блога Юлии Бажановой ч.2

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

Что у нас есть:
Со стороны гос. заказчика:
1. Юлия - статус неизвестен
2. РП со стороны заказчика

Со стороны исполнителя:
1. Методолог
2. Остальная команда, названная разработчиками

Из артефактов:
1. Постановление правительства

Как выглядит процесс работы с гос. заказчиком со стороны исполнителя:
1. На вход мы получаем бизнес-требования в виде постановлений, распоряжений, приказов и иногда технических заданий
2. Мы превращаем полученные артефакты в документацию для исполнения
3. Мы согласуем разработанную документацию с заказчиком
4. Мы делаем план реализации, создаем задачки, выполняем их, отлаживаем
5. Мы устраиваем показы заказчику

Что здесь пошло не так:
1. Если что-то не сделано, не имеет смысла ссылаться на "Постановление", разработчики по нему не работают, проверять стоит документацию к исполнению (если там этого нет, виноват в том числе заказчик, он ее согласовывал)
2. Если в документации функциональность (в данном случае выбор по цвету) есть, то виноват исполнитель (а именно РП и аналитики, которые не завели задачу)
3. Если задача тоже есть, но сделана не по описанию, тогда это на совести разработчика

В вариантах 2 и 3 исполнитель должен исправить ситуацию
В варианте 1 стоит обсудить добавление функциональности и корректировку сроков/денег

PS Также удивительным является игнорирование тестирования, но это уже дело десятое, что было, то было

Вопросы с собеседования Yandex (1/3)

Ко мне в руки попали вопросы, которые направляет Yandex для проверки будущих руководителей, предлагаю пройти их вместе.

Вопрос 1
"Сегодня ваш первый рабочий день на позиции тимлида дизайнеров презентаций. В вашей команде 40 человек. С чего вы начнете работу в первый день? Что планируете сделать за первую неделю, месяц?"

Вопросы с собеседования Yandex (2/3)

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