Удаленная разработка в MS Dynamics AX

[macklakov]

Цитата:

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

соответствие ожиданий - это все.

Подтверждаю. Expectation management очень важен.
И еще не забываем что когда прокет или контора банкротится, аутсорсер среди последних в очереди за деньгами. И среди первых на кого валят всю вину. Вернее так, вину валят на менеджера программы, а консультанты и PM-ы отмазываются тем, что это его авантюрная идея была использовать аутсорсеров из индии/пакистана/восточной европы.

Цитата:

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

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

Мне кажется, что будущее именно за подобными ребятами. И за .net-чиками широкого профиля. Ведь вендор пытается опираться именно на них. Есть стандартные сценарии, описанные четкими инструкциями, которым тупо надо следовать. А вот тупо делать то что скажут эти ребята умеют очень хорошо. Их к этому готовили и они уверены что именно в этом смысл их жизни заключается.
Опять таки, expectation management. Здешние солдаты сами просятся в горячие точки. Просто потому что из них по 5-10 лет делают воинов. И им потом тяжело просто ходить на службу за зарплату, довольствие и раннюю пенсию. Им кажется что они что-то важное в жизни упускают. Точно так если из студента готовят покорителя космоса или великого ученого, то потом на обычной работе ему будет печально. А когда сотрудник печален, его эффективность оставляет желать лучшего. Поэтому здесь типичного студента выпускают за 3 года не заморачивая матаном и сопроматом, зато постоянно собирают хотелки от индустрии и часто обновляют учебную программу. И получается что студент закончив универ приходит на банальную работу и чувствует себя там на своем месте. Ходит довольный жизнью, всем улыбается, болтает о пустяках. А наш выпускник смотрит на него и думает:"Вот же дебил тупой! Не знает даже кто такой Макс Планк или хотя бы Хэмингуэей."

[ax_mct]

Цитата:

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

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

Не дает мне одобрить так как превысил

Только вот это. Если туповатый (консультант) и слеповатый (программист) в паре то как внедрение вытаскивать?

Если по теме то в тренде таки те кто видят и думают и они нужны для той же удаленной и не очень работы в AX. C учетом web в AX 7 стоимость разработки еще более повысится если делать все классически и по старинке.

Для Agile/DevOps и снижения стоимости нужны человеки-оркестры. Если по теме, то кого таки ищут для удаленной разработки?

[AlexeyS]

Цитата:

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

Мне кажется, что будущее именно за подобными ребятами. И за .net-чиками широкого профиля. Ведь вендор пытается опираться именно на них. Есть стандартные сценарии, описанные четкими инструкциями, которым тупо надо следовать. А вот тупо делать то что скажут эти ребята умеют очень хорошо. Их к этому готовили и они уверены что именно в этом смысл их жизни заключается.
Опять таки, expectation management.

imo в такой ситуации могут проявиться большие риски просто завалить проект, потому-что во-первых, стандартные инструкции к стандартным ситуациям должен кто-то описать и этот кто-то должен на пару уровней превосходить исполнителей. Во-вторых, документация обычно сильно запаздывает, а в третьих, что делать в случае нестандартных сценариев? будь их мало, мы бы давно "программировали" галочками в настройках.
Плюс, в любом проекте должно быть управление рисками и ответственный ПМ, а в случае выпускников бух.ПТУ и .net-чиками широкого профиля, для которых аксапта просто очередная erp с кучей классов и табличек эти самые риски могут возрасти до неприличия, поэтому потребуются грамотные консультанты как промежуточное звено, не?

[ax_mct]

Цитата:

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

imo в такой ситуации могут проявиться большие риски просто завалить проект, потому-что во-первых, стандартные инструкции к стандартным ситуациям должен кто-то описать и этот кто-то должен на пару уровней превосходить исполнителей. Во-вторых, документация обычно сильно запаздывает, а в третьих, что делать в случае нестандартных сценариев? будь их мало, мы бы давно "программировали" галочками в настройках.
Плюс, в любом проекте должно быть управление рисками и ответственный ПМ, а в случае выпускников бух.ПТУ и .net-чиками широкого профиля, для которых аксапта просто очередная erp с кучей классов и табличек эти самые риски могут возрасти до неприличия, поэтому потребуются грамотные консультанты как промежуточное звено, не?

А поскольку "грамотные" консультанты на Западе это не реально так как важнее им лицом к процессам клиента а к AX задом, то только "грамотные" программисты могут выравнивать лодку.

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

А кто такой "грамотный" программист? Что особо вычленяется когда он рынке как удаленный ресурс. Analyst developer. Вполне себе устоявшийся термин.

P.S. Не ради оффтопа, а про (возможные) ожидания от удаленного программиста AX.
Вот мнение
http://stevepeacocke.blogspot.co.uk/...developer.html

A Programmer is a person who is given a task and codes that task as it is described. Usually this task is described by a Business Analyst in the form of a Requirements Document or a User Story.

An Analyst Developer will speak to the users to help define what their need is, then code that need.
(А консультанты часто что те же super-users).

[ALES]

Цитата:

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

А поскольку "грамотные" консультанты на Западе это не реально так как важнее им лицом к процессам клиента а к AX задом, то только "грамотные" программисты могут выравнивать лодку.

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

А кто такой "грамотный" программист? Что особо вычленяется когда он рынке как удаленный ресурс. Analyst developer. Вполне себе устоявшийся термин.

P.S. Не ради оффтопа, а про (возможные) ожидания от удаленного программиста AX.
Вот мнение
http://stevepeacocke.blogspot.co.uk/...developer.html

A Programmer is a person who is given a task and codes that task as it is described. Usually this task is described by a Business Analyst in the form of a Requirements Document or a User Story.

An Analyst Developer will speak to the users to help define what their need is, then code that need.
(А консультанты часто что те же super-users).

А не в том ли тут дело, что на "удаленку" сбрасывают темы по "допилу" уже внедренного и в целом "работающего" решения? Зачем платить "консультанту" за "перевод" "разработчику", что юзверь не хочет сохранения строчки в форме "продаж" в случае "X" ? "Консультант" (типа не нужный совсем) уже отработал свое, "лицом к клиенту", определив три года назад, что "отложенный переход собственности" тут не нужен и "стандартный" DAX со своей формой заказов для ввода "продаж" вполне подойдет

[ax_mct]

Цитата:

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

А не в том ли тут дело, что на "удаленку" сбрасывают темы по "допилу" уже внедренного и в целом "работающего" решения? Зачем платить "консультанту" за "перевод" "разработчику", что юзверь не хочет сохранения строчки в форме "продаж" в случае "X" ? "Консультант" (типа не нужный совсем) уже отработал свое, "лицом к клиенту", определив три года назад, что "отложенный переход собственности" тут не нужен и "стандартный" DAX со своей формой заказов для ввода "продаж" вполне подойдет

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

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

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

P.S. Теги в яблочко! Я точно тут на кушетке после нервов

Цитата:

консультанты не нужны, кушетка психоаналитика;

[ALES]

Цитата:

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

Просто функция роли консультанта изначально абсолютно не та к которой мы привыкли.

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

[NetBus]

Цитата:

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

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

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

[ALES]

Цитата:

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

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

Не потому ли, что истинные кодеры, архитекторы и т.д. реализуют саму ERP, а не "бредово-отвязные" бизнес-требования в ERP?

[ax_mct]

Цитата:

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

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

Цитата:

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

Не потому ли, что истинные кодеры, архитекторы и т.д. реализуют саму ERP, а не "бредово-отвязные" бизнес-требования в ERP?

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

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

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

[macklakov]

Цитата:

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

Нет уважения к "правильным" и "полезным" "западным" бизнес-процессам

На самом деле, есть. Просто это не очень очевидно из документации. И по коду тяжело понять бывает, для какого региона вот эта приблуда сделана. Это приводит к тому, что в Австралии консультант может задействовать функционал, созданный под законодательство существующие лишь с некоторых американских штатах.
Вот это реальная проблема и перманентный генератор косяков. И по этой же причине СНГ это всемирная кузница отличных девелоперов. Слишком сильно учет отличается от ЕС-овского и американского.
По хорошему, локализация должна писаться сбоку, а не поверх "стандарта". Но это не так важно. Тут как в анекдоте про экзамен в миллицейскую академию:"поступили самые умные и самые сильные". Если майкрософт поставил цель чтобы процесс из коробки внедрялся без дорого допила, значит так будет рано или поздно. Даже если архитектурно это будет чудовищное месиво из одних заплат. Это не важно. Оно будет работать

[ax_mct]

Цитата:

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

На самом деле, есть. Просто это не очень очевидно из документации. И по коду тяжело понять бывает, для какого региона вот эта приблуда сделана. Это приводит к тому, что в Австралии консультант может задействовать функционал, созданный под законодательство существующие лишь с некоторых американских штатах.
Вот это реальная проблема и перманентный генератор косяков. И по этой же причине СНГ это всемирная кузница отличных девелоперов. Слишком сильно учет отличается от ЕС-овского и американского.
По хорошему, локализация должна писаться сбоку, а не поверх "стандарта". Но это не так важно. Тут как в анекдоте про экзамен в миллицейскую академию:"поступили самые умные и самые сильные". Если майкрософт поставил цель чтобы процесс из коробки внедрялся без дорого допила, значит так будет рано или поздно. Даже если архитектурно это будет чудовищное месиво из одних заплат. Это не важно. Оно будет работать

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

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

Но ладно что есть то нам и есть. Интересно то что типичному AX программисту надо либо в NET либо в Функционал, а подвиду удаленному и туда и и туда. Или совсем оттуда.

[macklakov]

Цитата:

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

Другое дело что только на такие проекты меня и приглашают.

Цитата:

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

Но ладно что есть то нам и есть. Интересно то что типичному AX программисту надо либо в NET либо в Функционал, а подвиду удаленному и туда и и туда. Или совсем оттуда.

Мне так думается, что нам, тем кто в этой теме по уши, рано дергаться. Да, тема прикроется рано или поздно. Но период перехода к "светлому будущему" генерит массу "интересных задач", за исполнение которых, при определенной сноровке, можно получать хорошее вознаграждение. Года на 3-4, по идее, должно хватить. Это время лучше использовать на то, чтобы наесть жирка. Чтобы было что инвестировать в смену специализации.

[AlexeyS]

Цитата:

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

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

Но ладно что есть то нам и есть. Интересно то что типичному AX программисту надо либо в NET либо в Функционал, а подвиду удаленному и туда и и туда. Или совсем оттуда.

Процитирую отсюда: Евгений Кривошеев — Как не угробить архитектуру сразу же "Вот вы пишите учетную систему, где там главные риски? Сложная объектная модель. Как завещал великий Эрик Эванс в своей книжке по Domain Driven Design. Он говорил, что инженерия это фуфел, а вся сложность - она в предметке. Ты, дорогой инженер возьми и попробуй описать модель скидок, которую использует твой бизнес. И ты поймешь, что все это Java & Haskel это ерунда по сравнения с той сложностью бизнеса, который мы пытаемся смоделировать и автоматизировать. Сложность там, в предметке."

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

С этими товарищами я абсолютно согласен, поэтому, как говорил Деминг: "Меняться не обязательно. Выживание - дело добровольное"

[Pavel]

Цитата:

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

По хорошему, локализация должна писаться сбоку, а не поверх "стандарта". Но это не так важно. Тут как в анекдоте про экзамен в миллицейскую академию:"поступили самые умные и самые сильные". Если майкрософт поставил цель чтобы процесс из коробки внедрялся без дорого допила, значит так будет рано или поздно. Даже если архитектурно это будет чудовищное месиво из одних заплат. Это не важно. Оно будет работать

Хорошая 'задумка', вопрос как это можно реализовать специализируясь в технологиях?
Это же как мастер, кладущий камень, вдруг решит создать архитектурный проект дома или инженерные коммуникации (программист создавать новый функционал). Возникают вопросы...