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

[NetBus]

Цитата:

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

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

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

[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).

[ice]

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

[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

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

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

[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]

Цитата:

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

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

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

[DaxDevRemote]

Первая задача от иностранной компании оказалась угадайкой. Причём в AX 4.0. Сформулировать её не могу, да и больше похоже, что программировать там ничего не нужно.
Спросил кто выступает консультантом по этой задаче - дали консультанта. Похоже, что все консультанты и программисты в компании говорят на русском: Россия, Украина, Белоруссия. Только руководство иностранное.
Раз есть консультант, то просто спросил у него постановку задачи. Он играет в угадайку, уточнять задачу у клиента не хочет. Отвечаю на его вопросы, рассказываю функционал по коду.

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

[AlexeyS]

Цитата:

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

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

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

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

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

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

[Pavel]

Цитата:

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

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

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

[ax_mct]

Цитата:

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

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

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

Role: Dynamics AX Developer
Project: AX 2012 R3
Location:
Length: 6 months +
Rate:

Skills and Experience:
- Dynamics AX 2012 experience
- Dynamics AX2012 R2 experience
- AX modular experience
- Manufacturing experience
- Scrum
- Agile environment
- SQL Server ( SSRS,SSIS)

[AlexeyS]

Цитата:

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

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

разверните мысль плз., к концу дня сложно читать между строк ))

[AP-1055D]

Вычёркиваем:
- Dynamics AX 2012 experience
- Dynamics AX2012 R2 experience
- AX modular experience
- Manufacturing experience

Оставляем:
- Scrum
- Agile environment
- SQL Server ( SSRS,SSIS)

Добавляем:
- SQL Server SSAS

и получаем раз в 10 больше вакансий с той же или большей зарплатой. Плюс возможность почти безболезненно перейти на другой BI/ETL-стек.

А если добавить ASP.Net MVC + AngularJS / Backbone.js / ReactJS, то имеем непрерывный поток вакансий / проектов на 2000-5000$ удалённо.

[ax_mct]

Цитата:

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

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

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

Цитата:

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

разверните мысль плз., к концу дня сложно читать между строк ))

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

Подобное описание требований к программисту AX как бы становится стандартом.
Как-то за последние года 3-4 классическое "X++, AOT" ушло в небытие.

Отношение к теме удаленной разработки в AX имеет непосредственное так как отражает методологию и ожидания от ресурса. И в случае делегирования или прямого аутсорса оно в таком же виде и пойдет.

[ice]

ИМХО тут подмена понятий Scrum и Agile, вовсе не говорят, что разработка ведется методом проб и ошибок, а уточнение задания ведется после недовольства предоставленным решением. на мой взгляд данная методология лишь разделяет некую большую задачу (проект) на множество итераций и подзадач, с каждым релизом приближающее решение или вносящее улучшение в продукт