AXForum  
Вернуться   AXForum > Рынок > Рынок труда Microsoft Dynamics
CRM
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 13.10.2023, 14:49   #1  
ТРЕНЕР is offline
ТРЕНЕР
Участник
Аватар для ТРЕНЕР
 
599 / 50 (3) ++++
Регистрация: 11.06.2003
Адрес: Москва
Переход на другие системы и требования в вакансиях
В связи с периодически обсуждаемыми темами «куда идти после Аксапты» решил посмотреть вакансии на 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 (1), Шрэк (1).
Старый 13.10.2023, 22:00   #2  
twilight is offline
twilight
MCTS
MCBMSS
 
871 / 237 (9) ++++++
Регистрация: 17.10.2004
Адрес: Королёв
Тут есть требования для менеджеров проектов, а есть то, что относится больше к DevOps/разработке.
По идее, если вы себя позиционируете именно как менеджер проектов, то методогии и стандарты вам желательно знать. Или вы считаете, что они бесполезны?
__________________
I could tell you, but then I would have to bill you.
Старый 13.10.2023, 22:04   #3  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от ТРЕНЕР Посмотреть сообщение
на моих местах работы как ни странно либо не встречалось, либо встречалось редко. Или возможно встречалось – но в явном виде никогда не говорилось, например что вот у нас тут принято работать по такой методике, эта методика называется так-то, состоит из таких то шагов, мы их все выполняем, и это все прописано в руководствах, инструкциях и т.п. Ну вот нет, на самом деле. Причем не только в конторах, где я работал – но и у наших подрядчиков и интеграторов.
Может, вы каких-то не тех интеграторов выбирали? Какой длительности и трудоемкости в часах были проекты? Как часто подписывались акты и проводились оплаты? Если подрядчик готов начать работать без предоплаты, а всю оплату получить в конце проекта после "обмывания" его завершения в баре, то, наверно, методологии, шаги, документы не нужны. А если подрядчик, к примеру, хочет оплату после каждого этапа или, о, ужас, каждый месяц, хочет зафиксировать рамки проекта и прочие условия, то он должен объяснить клиенту, откуда взялась оценка, почему рамки проекта именно такие, откуда взялись этапы, какими документами они закрываются, что и с какой регулярностью актируется, почему именно так... Чтобы каждый раз не изобретать велосипед, и придумали всякие методологии ведения проектов.
Цитата:
Сообщение от ТРЕНЕР Посмотреть сообщение
Я работал исключительно на стороне заказчиков, а не в компаниях-разработчиках/интеграторах, со сроками работы на одном месте от 3 до 10 лет. Возможно, что дело в этом.
Весьма может быть. Работа на клиенте сужает кругозор и искажает восприятие того, что на самом деле востребовано на рынке.
Цитата:
Сообщение от ТРЕНЕР Посмотреть сообщение
Возможно, что если бы я имел опыт работы 50 лет, менял место работы 2 раза в год и постоянно переходил туда-сюда между клиентами и интеграторами (причем разными) – то все было бы иначе.
Скорее так: опыт работы 10 лет в интеграторе и менял клиентов/проекты 2 раза в год - и всё было бы иначе
За это сообщение автора поблагодарили: LETTO (3), ТРЕНЕР (2).
Старый 16.10.2023, 01:11   #4  
ТРЕНЕР is offline
ТРЕНЕР
Участник
Аватар для ТРЕНЕР
 
599 / 50 (3) ++++
Регистрация: 11.06.2003
Адрес: Москва
Интеграторы были разные, в том числе оба "большие К". Но я же не писал что у них нет методологии. Конечно же был устав проекта, определенные этапы и определенные документы. Но мой пост был о конкретных требованиях в вакансиях. В проектных документах интеграторов не написано, по какой именно методологии ведения проекта они работают, по какой методологии ведут разработку в рамках проекта. Интересно было бы спросить их ведущих пиэмов и посмотреть, смогут ли они ответить без интернета и без предварительной подготовки, например на эти вопросы:
- по какой методологии ведете проект - по 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 ведение такого списка - это элемент процесса решения уже свершившихся инцидентов. Этот пример смешения двух методологий на одном проекте, и о том что это смешение - думаю что большинство пиэмов понятия не имеет.

Последний раз редактировалось ТРЕНЕР; 16.10.2023 в 01:15.
За это сообщение автора поблагодарили: ice (1).
Старый 16.10.2023, 12:21   #5  
LETTO is offline
LETTO
Участник
 
282 / 63 (3) ++++
Регистрация: 14.07.2022
Цитата:
Сообщение от ТРЕНЕР Посмотреть сообщение
Я думаю, что на большинство этих вопросов пиэмы интеграторов не смогут ответить вообще или ответить правильно.
А зачем им это. Они пользуются "выжимками" из PMBOK ровно в тех границах, которые нужны для нашей сферы. У нас нет потребности в каком серьезном управлении проектами. Команда обычно человек 5 на проекте.

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

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

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

Последний раз редактировалось LETTO; 16.10.2023 в 12:32.
Старый 16.10.2023, 12:41   #6  
LETTO is offline
LETTO
Участник
 
282 / 63 (3) ++++
Регистрация: 14.07.2022
Ну и всё таки разработка ПО под продажу это отличается от нашей темы. ПО обычно под инвестора - отсюда БОЛЕЕ высокие требования по бюджетам, строкам, рискам и прочему, нежели в нашей сфере. Потому требования к управлению проектами и к ПМ посерьезней.
Плюс требования к интерфейсу высочайшие. Отсюда эти User Stories, Use Cases; UX и UI, а не инструкции как у нас.
СУБД обычно не SQL, а бесплатные аналоги.
Ну и микросервисы, естественно. Чего нет в нашей сфере.

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

Ну и да. ПМ надо всё это знать, если в разработку ПО переходить. Просто совещания и дергать разработчиков "когда готово будет" уже не прокатит. ПМ отвечает перед инвестором по полной.
Старый 16.10.2023, 13:10   #7  
ТРЕНЕР is offline
ТРЕНЕР
Участник
Аватар для ТРЕНЕР
 
599 / 50 (3) ++++
Регистрация: 11.06.2003
Адрес: Москва
Цитата:
Сообщение от LETTO Посмотреть сообщение
В вакансиях пишут методологии скорей для понимания и факта что надо управлять проектом.


Цитата:
Сообщение от LETTO Посмотреть сообщение
Хорошо если еще предметную область хоть немного знаете.
Работа на стороне клиентов, как было отмечено кем-то выше, сужает кругозор в технологиях, но позволяет очень глубоко погружаться в предметные области.
Старый 16.10.2023, 13:16   #8  
LETTO is offline
LETTO
Участник
 
282 / 63 (3) ++++
Регистрация: 14.07.2022
Цитата:
Сообщение от ТРЕНЕР Посмотреть сообщение
Ну а чего смеетесь. Известная байка и постоянно над этим спецы шутят. Что в вакансиях перечисляют всё подряд.
Не надо с этому относится как к "must have", скорей как "should have"
Старый 16.10.2023, 14:52   #9  
twilight is offline
twilight
MCTS
MCBMSS
 
871 / 237 (9) ++++++
Регистрация: 17.10.2004
Адрес: Королёв
Обычно кандидата оценивают формально и неформально.
Неформально - рассказ о себе, на каких проектах работал, за что отвечал, что знаешь, с чем работал и т. д.
Формально - тут зависит от должности. Программистам тестовое задание на кодирование. Спрашивают по таблицам, классам и т. д.
Консультант - дают задание на подготовку презентации и спрашивают по функционалу.
Прожект менеджера как оценивать формально?
__________________
I could tell you, but then I would have to bill you.
Старый 16.10.2023, 15:28   #10  
LETTO is offline
LETTO
Участник
 
282 / 63 (3) ++++
Регистрация: 14.07.2022
Цитата:
Сообщение от twilight Посмотреть сообщение
Прожект менеджера как оценивать формально?
MS Project, методология, проектная документация.

Последний раз редактировалось LETTO; 16.10.2023 в 15:30.
Старый 16.10.2023, 15:32   #11  
ТРЕНЕР is offline
ТРЕНЕР
Участник
Аватар для ТРЕНЕР
 
599 / 50 (3) ++++
Регистрация: 11.06.2003
Адрес: Москва
Цитата:
Сообщение от LETTO Посмотреть сообщение
MS Project, методология, проектная документация.
Ну вот и я об этом. Если в вакансии указано требование PMBoK - то вполне можно ожидать формальных вопросов если не на знание, то хотя бы на понимание. Ну как минимум кандидат должен сказать по каким методологиям управления проектами ему приходилось работать. Не уверен что многие пиэмы смогут даже это сказать. Поэтому вопрос - готовиться ли к этому или нет. Я считаю что готовиться. Примеры потенциальных вопросов я набросал в посте выше.
Старый 16.10.2023, 15:39   #12  
LETTO is offline
LETTO
Участник
 
282 / 63 (3) ++++
Регистрация: 14.07.2022
Цитата:
Сообщение от ТРЕНЕР Посмотреть сообщение
Не уверен что многие пиэмы смогут даже это сказать.
Ну в интеграторах я встречал сильных пиэмов. На клиентах не особо. Часто только формально пиэмы. На деле просто руководитель группы. Поэтому тут разделять все таки кого называть пиэмами.
Цитата:
Сообщение от ТРЕНЕР Посмотреть сообщение
Поэтому вопрос - готовиться ли к этому или нет. Я считаю что готовиться. Примеры потенциальных вопросов я набросал в посте выше.
Да по любому лишним не будет. Если реальным хорошим пиэмом цель быть.
Старый 16.10.2023, 15:46   #13  
ТРЕНЕР is offline
ТРЕНЕР
Участник
Аватар для ТРЕНЕР
 
599 / 50 (3) ++++
Регистрация: 11.06.2003
Адрес: Москва
Цитата:
Сообщение от LETTO Посмотреть сообщение
Да по любому лишним не будет. Если реальным хорошим пиэмом цель быть.
Пока цель сменить работу с повышением заработка на 50%.
Старый 17.10.2023, 11:58   #14  
ТРЕНЕР is offline
ТРЕНЕР
Участник
Аватар для ТРЕНЕР
 
599 / 50 (3) ++++
Регистрация: 11.06.2003
Адрес: Москва
Ну хорошо, методологию ведения проекта обсудили, никто против моих тезисов вроде бы не возразил.

А что с методологией разработки? по какой методологии ведут например разработки в интеграторах на проектах внедрения Аксапты? или по вашему мнению на подобных проектах это такое же "бал-бла-бла", как и методология ведения проекта? как ведете разработку для клиента - Agile? SCRUM? RUP? Или сами не знаете как это называется? Ответы - в студию!
Старый 17.10.2023, 12:24   #15  
LETTO is offline
LETTO
Участник
 
282 / 63 (3) ++++
Регистрация: 14.07.2022
Цитата:
Сообщение от ТРЕНЕР Посмотреть сообщение
как ведете разработку для клиента - Agile? SCRUM? RUP? Или сами не знаете как это называется? Ответы - в студию!
Это всё методики УПРАВЛЕНИЯ проектами. Так что вопрос не к разработчикам.
А так у нас обычная старая добрая каскадная модель управления. Что соответствует наших потребностям.

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

Хотя я не спец в этих делах. Может для поддержки и хорош Agile. Для внедрения с нуля или какой то функциональности не представляю как это будет выглядеть - типа кидай заказчик нам требования, а мы будем быстренько выкатывать изменения. Куда такой проект зайдет то. Бухгалтерия одни требования накидает, финансы другие, склад третьи.
Старый 17.10.2023, 12:38   #16  
ТРЕНЕР is offline
ТРЕНЕР
Участник
Аватар для ТРЕНЕР
 
599 / 50 (3) ++++
Регистрация: 11.06.2003
Адрес: Москва
То есть waterfall. Ну ок.

В этой модели управления проектами запрещено возвращаться на предыдущие уже выполненные этапы разработки и что-то в них переделывать. Соблюдаете это принцип? Нет? Какие еще принципы каскадной модели не соблюдаете?
Старый 17.10.2023, 12:41   #17  
LETTO is offline
LETTO
Участник
 
282 / 63 (3) ++++
Регистрация: 14.07.2022
Цитата:
Сообщение от ТРЕНЕР Посмотреть сообщение
или по вашему мнению на подобных проектах это такое же "бал-бла-бла", как и методология ведения проекта?
Я кстати вообще не говорил, что "методология ведения проекта" это "бал-бла-бла".
Видимо не так я мысль донес.
Старый 17.10.2023, 12:43   #18  
LETTO is offline
LETTO
Участник
 
282 / 63 (3) ++++
Регистрация: 14.07.2022
Цитата:
Сообщение от ТРЕНЕР Посмотреть сообщение
То есть waterfall. Ну ок.

В этой модели управления проектами запрещено возвращаться на предыдущие уже выполненные этапы разработки и что-то в них переделывать. Соблюдаете это принцип? Нет? Какие еще принципы каскадной модели не соблюдаете?
Это ж всего лишь "модель" управления. А не законы управления.
Старый 17.10.2023, 12:49   #19  
LETTO is offline
LETTO
Участник
 
282 / 63 (3) ++++
Регистрация: 14.07.2022
Цитата:
Сообщение от ТРЕНЕР Посмотреть сообщение
В этой модели управления проектами запрещено возвращаться на предыдущие уже выполненные этапы разработки
Да вроде на предыдущие никто не возвращается.
Делают новые доп. этапы на изменение функционала.
Старый 17.10.2023, 13:02   #20  
axm2017 is offline
axm2017
Участник
 
1,791 / 293 (13) ++++++
Регистрация: 15.05.2017
Цитата:
Сообщение от LETTO Посмотреть сообщение
.. Agile это про продукты с быстро меняющимися требованиями (мобилы, веб), где пользователи нон стопом накидывают хотелки и наша задача их быстро покрыть. В долгую такие проекты тяжело проектировать. Да и смысла нет.

Хотя я не спец в этих делах..
Нда а мужики то и не знают....
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
DAX, 1С и другие. Розница, дистрибуция. Попытка облегчить муки выбора. Luck77 Сравнение ERP-систем 65 09.04.2009 14:09
Семинар "Системы автоматизации управления производством для пищевой промышленности" Georgy Полезное по Microsoft Dynamics 0 31.07.2007 13:23
IBS приступила к внедрению корпоративной системы управления в компании «БАТ Россия» mazzy Microsoft и системы Microsoft Dynamics 1 26.03.2005 00:52
Компания «ЭЛФОР СОФТ» успешно завершила проект по внедрению корпоративной системы на базе Microsoft Navision в ООО «СовТрансЭкспорт» mazzy Microsoft и системы Microsoft Dynamics 0 12.02.2005 13:48
Вышла новая версия системы Navision (3.60) Роман Кошелев Microsoft и системы Microsoft Dynamics 0 21.01.2003 17:11
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 11:55.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.