Переход на другие системы и требования в вакансиях

[ТРЕНЕР]

В связи с периодически обсуждаемыми темами «куда идти после Аксапты» решил посмотреть вакансии на hh на предмет того, какие конкретно требования пишут работодатели (исключая «бла-бла» общего характера) и что из этого у меня есть за 25+ лет опыта в ИТ. Просмотрел несколько десятков вакансий на позиции менеджеров проектов в ИТ и системных/бизнес аналитиков, сделал выписки. И результатом был несколько озадачен. «Я знаю только то, что ничего не знаю» - несколько успокаивает только то, что стою в одном ряду с Сократом. Но если без шуток: реальность такова, что то, что по факту широко используется (судя по вакансиям– практически везде), на моих местах работы как ни странно либо не встречалось, либо встречалось редко. Или возможно встречалось – но в явном виде никогда не говорилось, например что вот у нас тут принято работать по такой методике, эта методика называется так-то, состоит из таких то шагов, мы их все выполняем, и это все прописано в руководствах, инструкциях и т.п. Ну вот нет, на самом деле. Причем не только в конторах, где я работал – но и у наших подрядчиков и интеграторов. Я работал исключительно на стороне заказчиков, а не в компаниях-разработчиках/интеграторах, со сроками работы на одном месте от 3 до 10 лет. Возможно, что дело в этом. Возможно, что если бы я имел опыт работы 50 лет, менял место работы 2 раза в год и постоянно переходил туда-сюда между клиентами и интеграторами (причем разными) – то все было бы иначе.

Ниже - выписки с hh. Если вы увидите, что где-то в одну кучу свалены совсем разные термины – то это в основном не я, это составители вакансий в hh. Но возможно, что я что-то не так классифицировал. Часто в описании написано так: наш стэк - и дальше всё в одной куче (умному достаточно, знающий поймет..)


Методологии: Agile, SCRUM, Kanban, Scrumban, SADT, ART, LeSS, SAFe, MSF, RUP, waterfall, RAD (Rapid Application Development), DSDM, FDD, BDD, PMTriangle, Eisenhower Matrix, RICE, BurnDown/Up.

Комментарий: в разных местах их называют то методологиями ведения проектов, то технологиями ведения разработки, то инструментами управления проектами. Удивительно, но ни в одном месте моей работы ни разу нигде руководство ИТ не озвучивало, по какой методологии мы работаем. И наши подрядчики ни на одном проектов с нами – тоже. Что касается hh, то мало вакансий, где говорится что мы работаем например четко по Agile – как правило, все методики перечисляются списком через запятую в требованиях, хотя они разные и предназначены для разных случаев. Ощущение, что составители объявлений сами понятия не имеют, по какой методике они работают и что конкретно им надо от кандидата. Из всего перечисленного выше – я сходил как-то на курсы по RUP и прочел книжку про SADT…

Системы трекинга задач и управления проектами: Jira, Redmine, gitlab, enterprise architect, swagger, Confluence, YouTrack, Postman, Битрикс.24, Trello, Хmind, Gantt, Notion, Whimsical, Asana, Miro, MS Project

Комментарий: наиболее часто встречаются Jira и Confluence – причем вместе. Да, я знаю конечно компании, где работают с этими системами. и людей который с ними работают. (Также их иногда на hh указывают как системы для ведения проектной документации). Но почему-то во всех местах куда я приходил – использовались другие. Ну разве что только MS Project.

Описание и моделирование бизнес-процессов: BPMN, UML, EPC, PlantUML, ER, DFD, IDEF0‚ IDEF1X, Aris, MS Visio, draw.io, Camunda. Kaiten. Матрицы CRUD и их разновидности, fishbone-диаграммы. eTom

Комментарий: в разных местах их называют: нотации, языки описания, инструменты моделирования, ПО для рисования схем и т.п. На практике мне приходилось использовать DFD, IDEF0 и UML.

Знание стандартов в области управления проектами: PMI - PMBOK, IPMA – ICB, ФАТРМ – ГОСТ Р 54869 и др., JAPM – P2M, APM – Prince 2, ISACA – HERMES; PRINCE2. Сбор и управление требованиями к ПО по ГОСТ Р 59194-2020,.ВАВОК. знание ГОСТ 19, 34, РД 50

Ведение документации в форматах User Stories, Use Cases; UX и UI (как будет работать и выглядеть интерфейс продукта).

СУБД и сопутствующее ПО: SQL, MySQL ,Postgres, Tomcat, Airflow, ngnix, ClickHouse, TablePlus, DBeaver

Инструменты для проектов на Web: python: FastAPI, pytest, aiohttp, Typescript, Javascript, React, React Native, Redux, Java, PHP, Go, WebSocket, gRPC. Знание программ для разработки прототипов пользовательских интерфейсов (Balsamiq Mockups или аналоги)

Интеграция, API, микросервисы: REST, SOAP ASP.NET, MQ,, GraphQL брокерами сообщений rabbit, kafka, ESB, API, Webhooks, SDK, REST, MQ, SOAP ASP.NE, XML/XSD, JSON/JSON-Shema, SOA, MSA, CI/CD, Jenkins, Docker, DBLink

[twilight]

Тут есть требования для менеджеров проектов, а есть то, что относится больше к DevOps/разработке.
По идее, если вы себя позиционируете именно как менеджер проектов, то методогии и стандарты вам желательно знать. Или вы считаете, что они бесполезны?

[gl00mie]

Цитата:

Сообщение от ТРЕНЕР

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

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

Цитата:

Сообщение от ТРЕНЕР

Я работал исключительно на стороне заказчиков, а не в компаниях-разработчиках/интеграторах, со сроками работы на одном месте от 3 до 10 лет. Возможно, что дело в этом.

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

Цитата:

Сообщение от ТРЕНЕР

Возможно, что если бы я имел опыт работы 50 лет, менял место работы 2 раза в год и постоянно переходил туда-сюда между клиентами и интеграторами (причем разными) – то все было бы иначе.

Скорее так: опыт работы 10 лет в интеграторе и менял клиентов/проекты 2 раза в год - и всё было бы иначе

[ТРЕНЕР]

Интеграторы были разные, в том числе оба "большие К". Но я же не писал что у них нет методологии. Конечно же был устав проекта, определенные этапы и определенные документы. Но мой пост был о конкретных требованиях в вакансиях. В проектных документах интеграторов не написано, по какой именно методологии ведения проекта они работают, по какой методологии ведут разработку в рамках проекта. Интересно было бы спросить их ведущих пиэмов и посмотреть, смогут ли они ответить без интернета и без предварительной подготовки, например на эти вопросы:
- по какой методологии ведете проект - по PMBok , по PRINCE2 или по какой-то другой?
- по какой причине в компании выбрана именно эта методология?
- проводится ли в компании обучение для пиэмов, аналитиков и консультантов по этой методологии, кто проводит обучение ?
- в других компаниях где работали - была эта методология или другая?
- знаете ли вы в чем основные различия PMBok и PRINCE2 ?
- допустим, ваша компания ведет проекты по PMBok - можете ли описать общую архитектуру PMBok, а не только этапы и документы которые составляете по ходу проекта?
- допустим, ваша компания ведет проекты по PMBok - знаете ли по какой редакции PMBok вы работаете: 5й, 6й или 7й, и в чем вообще разница между ними, хотя бы примерно?
- по каким конкретно процессам управления проектом вы вели (ведете сейчас) свой последний проект? (подсказка: в PMBok их расписано несколько десятков)
- во всех проектах внедрения есть этап бизнес-анализа, какие конкретно методики бизнес-анализа используете на этом этапе, используете ли в работе BABOK ?
- какую методику разработки используют ваши программисты для модификаций по проекту?
- если часть модификаций по проекту делают программисты клиента (например, интеграцию с существующими там системами), то знаете ли вы по какой методике работают они, и как при управлении проектом вы сочетаете одновременно методики разработки ваших и их программистов ?

Я думаю, что на большинство этих вопросов пиэмы интеграторов не смогут ответить вообще или ответить правильно. Ну может быть только скажут что у них в компании принят PMBok, или что у них в компании "своя" методология выработанная лучшими практиками.
На самом деле скорее - второе. То есть неосознанное применение частично элементов PMBok и частично элементов PRINCE2 в сочетании со "здравым смыслом".
Пример. На всех проектах ведется список возникающих в ходе проекта проблем - issue log. Везде это фиксация проблем именно по факту их неожиданного возникновения. И такой способ ведения issue log - взят именно из PRINCE2. потому что в PMBok - issue log это список возможных проблем который продумывается заранее, то есть в PMBok это элемент процесса управления рисками. А в PRINCE2 ведение такого списка - это элемент процесса решения уже свершившихся инцидентов. Этот пример смешения двух методологий на одном проекте, и о том что это смешение - думаю что большинство пиэмов понятия не имеет.

[LETTO]

Цитата:

Сообщение от ТРЕНЕР

Я думаю, что на большинство этих вопросов пиэмы интеграторов не смогут ответить вообще или ответить правильно.

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

Сравните со строительством тем же. Где сотни человек, сотни подрядчиков, тысячи материалов, строгие строки и огромные бюджеты. Ну и риски постоянные (от чиновника до погоды). Это для них PMBOK

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

ЗЫ Хотя для ПМ не плохо бы знать методологии. Но вы народ специфический. Хорошо если еще предметную область хоть немного знаете. А то обычно кто наглей тот и ПМ

[ТРЕНЕР]

Цитата:

Сообщение от LETTO

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

Цитата:

Сообщение от LETTO

Хорошо если еще предметную область хоть немного знаете.

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

[LETTO]

Цитата:

Сообщение от ТРЕНЕР

Ну а чего смеетесь. Известная байка и постоянно над этим спецы шутят. Что в вакансиях перечисляют всё подряд.
Не надо с этому относится как к "must have", скорей как "should have"

[LETTO]

Ну и всё таки разработка ПО под продажу это отличается от нашей темы. ПО обычно под инвестора - отсюда БОЛЕЕ высокие требования по бюджетам, строкам, рискам и прочему, нежели в нашей сфере. Потому требования к управлению проектами и к ПМ посерьезней.
Плюс требования к интерфейсу высочайшие. Отсюда эти User Stories, Use Cases; UX и UI, а не инструкции как у нас.
СУБД обычно не SQL, а бесплатные аналоги.
Ну и микросервисы, естественно. Чего нет в нашей сфере.

Т.е. у меня изначальный список технологий не вызывает никакого "диссонанса". Всё по делу.

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

[twilight]

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

[LETTO]

Цитата:

Сообщение от twilight

Прожект менеджера как оценивать формально?

MS Project, методология, проектная документация.

[ТРЕНЕР]

Цитата:

Сообщение от LETTO

MS Project, методология, проектная документация.

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

[LETTO]

Цитата:

Сообщение от ТРЕНЕР

Не уверен что многие пиэмы смогут даже это сказать.

Ну в интеграторах я встречал сильных пиэмов. На клиентах не особо. Часто только формально пиэмы. На деле просто руководитель группы. Поэтому тут разделять все таки кого называть пиэмами.

Цитата:

Сообщение от ТРЕНЕР

Поэтому вопрос - готовиться ли к этому или нет. Я считаю что готовиться. Примеры потенциальных вопросов я набросал в посте выше.

Да по любому лишним не будет. Если реальным хорошим пиэмом цель быть.

[ТРЕНЕР]

Цитата:

Сообщение от LETTO

Да по любому лишним не будет. Если реальным хорошим пиэмом цель быть.

Пока цель сменить работу с повышением заработка на 50%.

[ТРЕНЕР]

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

А что с методологией разработки? по какой методологии ведут например разработки в интеграторах на проектах внедрения Аксапты? или по вашему мнению на подобных проектах это такое же "бал-бла-бла", как и методология ведения проекта? как ведете разработку для клиента - Agile? SCRUM? RUP? Или сами не знаете как это называется? Ответы - в студию!

[LETTO]

Цитата:

Сообщение от ТРЕНЕР

как ведете разработку для клиента - Agile? SCRUM? RUP? Или сами не знаете как это называется? Ответы - в студию!

Это всё методики УПРАВЛЕНИЯ проектами. Так что вопрос не к разработчикам.
А так у нас обычная старая добрая каскадная модель управления. Что соответствует наших потребностям.

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

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

[axm2017]

Цитата:

Сообщение от LETTO

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

Хотя я не спец в этих делах..

Нда а мужики то и не знают....

[LETTO]

Цитата:

Сообщение от axm2017

Нда а мужики то и не знают....

Да не стесняйтесь. Не прячьте свои мысли.
Я не буду особо спорить - не буду делать вид что разбираюсь в Agile - не разбираюсь.

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

Может ошибаюсь. Интересно было бы узнать тонкости

[LETTO]

Цитата:

Сообщение от ТРЕНЕР

или по вашему мнению на подобных проектах это такое же "бал-бла-бла", как и методология ведения проекта?

Я кстати вообще не говорил, что "методология ведения проекта" это "бал-бла-бла".
Видимо не так я мысль донес.

[ТРЕНЕР]

То есть waterfall. Ну ок.

В этой модели управления проектами запрещено возвращаться на предыдущие уже выполненные этапы разработки и что-то в них переделывать. Соблюдаете это принцип? Нет? Какие еще принципы каскадной модели не соблюдаете?

[LETTO]

Цитата:

Сообщение от ТРЕНЕР

То есть waterfall. Ну ок.

В этой модели управления проектами запрещено возвращаться на предыдущие уже выполненные этапы разработки и что-то в них переделывать. Соблюдаете это принцип? Нет? Какие еще принципы каскадной модели не соблюдаете?

Это ж всего лишь "модель" управления. А не законы управления.