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

[Vadik]

Цитата:

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

Работа по хорошим и детальным спецификациям - это в песочнице для детишек

В таком случае вопрос "Как оцените?" уберите, будьте добреньки. Возьмусь и буду делать и переделывать пока не будет готово (agile же, чо там), а Вы (как заказчик) - оплачивать почасовую ставку. Как Вам такой вариант?
P.S. про особенности западного консалтинга - спасибо, буду иметь в виду

[ice]

"Вот тут то карта мне и пошла". Беремся за все, до последнего евро/доллара у клиента будем делать любую задачу

[ax_mct]

Цитата:

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

В таком случае вопрос "Как оцените?" уберите, будьте добреньки. Возьмусь и буду делать и переделывать пока не будет готово (agile же, чо там), а Вы (как заказчик) - оплачивать почасовую ставку. Как Вам такой вариант?
P.S. про особенности западного консалтинга - спасибо, буду иметь в виду

А тут вилы. И деталей нет и стоимость надо прикинуть.
Без примерной оценки никак. Иначе нет работы.

На практике оцениваешь на глазок по опыту и печальным предчувствиям.
Один черт потом все надо будет резко переигрывать и все предыдущие оценки летят к черту.

Но корректная оценка это первая проверка на адекватность и профессионализм.
Оценивая в 6 дней подобную задачу вы f@cked в любом случае.
Можно сказать что через 5 дней вы сделаете proof of concept, это да.

[Raven Melancholic]

Цитата:

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

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

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

[ax_mct]

Цитата:

Сообщение от Raven Melancholic

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

Бизнес ситуация такая. Пригласили к себе, много рассказывали и еще больше смотрели в глаза, что-то в них пытаясь рассмотреть. Когда я понял что еще немного и по моим глазам они поймут что я их буду убивать попросил изобразить на доске.

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

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

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

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

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

Единственный нормальный вариант это когда это время удаленного ресурса или очень дешево или фиксированный оклад. Иначе просто лотерея заработаешь на этом или нет.

Но проблема не столько в деньгах сколько в другой культуре.

[Raven Melancholic]

ax_mct, я, задавая вопрос, имел ввиду не общее Ваше эмоциональное состояние, а то, о чем речь шла во время разговора с заказчиком, то есть что они изобразили на доске.
Спасибо за разъяснения.
Как я понял, в данной теме обсуждение скатилось к какой-то абстрактной ситуации:

• Есть "облако" заказчиков (перепродавцы ресурсов или конечные потребители ресурсов), которым нужно что-то реализовать и привлечь поставщика ресурсов (непосредственного исполнителя или перепродавца).
• Есть "облако" поставщиков ресурсов (конкретные личности, обладающие нужными знаниями и умениями или опять же перепродавцы ресурсов).

И ax_mct задает вопрос автору топика как тот собирается работать когда состыковываются два облака (совпадение с существующей фирмой с таким названием случайно - Витя прости) - облако заказчиков и облако поставщиков ресурсов.
Я думаю ,что это очень абстрактная ситуация. Как правило, те кто работают удаленно, работают в каких-то парах - кто-то бегает по клиентам, кто-то реализует задачи. Роли могут меняться.
Так чтобы было море заказчиков, море исполнителей и их нужно состыковать работает на стандартных задачах. Ну, применительно к DAX, возможно что-то подобное:

• Есть загрузка курсов валют с сайта ЦБ РФ, нужно её расширить для возможности загрузки с сайта нацбанка Казахстана.
• Есть загрузка выписки банка по формату, предложенному Сбером и 1С с 90-х годах, есть загрузка выписки в формате Сити Банка (расширенный формат SWIFT), нужно доработать для загрузки в формате Сбера Казахстана (похож на Сити Банк, но есть особенности).
• Ну и тому подобные задачи, в которых нет каких-то тонкостей, завязанных на конкретного клиента.

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

[Bobkov]

Цитата:

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

Первый рабочий день по договору 4-го мая - посмотрим как пойдёт...

Как пошло-то? Расскажите по свежим впечатлениям, пока не остыли!

[ax_mct]

Рынок меняется. Это часть тренда. Не было раньше столько виртуальных центров разработки по АХ содержащих удалённых разработчиков. Вот и интересно что и как. Не общие слова рисующее большой зал с 50 программистами барабанящими по клавам по "красивой" методологии, а реальные ситуации которые собрат поймет.

Мне действительно интересно что и как это все выглядит на конкретных примерах.
Что я и пытался выяснить у автора, чтобы нарисовать реальную картинку.
Так ничего я и не понял. Но намёк сверху на задачи "не связанные с особенностями клиента" интересен. Типа интерфейсы, что-то такое ближе к техническим аспектам чем к функционалу.

Вообщем хочу страшную правду а не пыль в глаза

Зы: То есть примеры задач решаемых передаваемых на удалённую разработку. В этом вся соль темы.

[Raven Melancholic]

Цитата:

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

То есть примеры задач решаемых передаваемых на удалённую разработку.

Первое же что приходит на ум - экспорт в 1С разных версий и конфигураций.
На мой взгляд, это вообще задача Microsoft. Но какое же количество фрилансеров (да и не только их) этим кормится!

[ax_mct]

Celenia looking for Senior Software Development Engineers (MS Dynamics AX)
Celenia looking for Senior Software Development Engineers (MS Dynamics AX)

Цитата:

Requirements Role Description
The Senior Software Development Engineer (SSDE) is responsible for development of applications, software modules and solutions. In addition, the SSDE represents Celenia in a professional manner and has the good communication skills, very deep knowledge and multiple Dynamics AX functional areas, is responsible for managing tasks assigned on him, requirements analysis, technical architecture design, technical documentation, business logic development, and code performance optimization.

Цитата:

ability to professionally communicate directly with clients

Где говорите кодеры еще не вымерли?

[ax_mct]

Цитата:

Сообщение от Raven Melancholic

Первое же что приходит на ум - экспорт в 1С разных версий и конфигураций.
На мой взгляд, это вообще задача Microsoft. Но какое же количество фрилансеров (да и не только их) этим кормится!

Да, интеграция пожалуй на первом месте для аутсорсинга. Машина <-->Машина. Это тип задач с минимальными изменениями и максимальной простотой понимания.

А вот как обстоит дело с аутсорсингом задач не столь плоских?

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

Подумалось что "Удаленная разработка в AX" это не обязательно фриланс.
Но вот чем отличается от фриланса роль в Селении? Разве что крышей.

Цитата:

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

Именно так. Строить без проекта и проектно-сметной документации. Вернее вы сами должны ее создавать.

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

Цитата:

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

Формулировка взялась как реальный пример постановки задачи.
Сформулировал консультант консалтинга. Причём это мой уже перевод задачи, в реальности это просто заметки с совещания с клиентом в виде бизнес ситуаций.

А как он будет проверять правильно вы выполнили задачу или нет? У него в голове есть сценарий тестирования? Или можно такому консультанту впарить что-угодно и сказать что так и надо?

Цитата:

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

Как результат есть неоправданные ожидания: вы ожидаете что постановщик задачи знает AX достаточно, а он ожидает того же от вас.

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

Цитата:

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

В таком случае вопрос "Как оцените?" уберите, будьте добреньки. Возьмусь и буду делать и переделывать пока не будет готово (agile же, чо там), а Вы (как заказчик) - оплачивать почасовую ставку. Как Вам такой вариант?
P.S. про особенности западного консалтинга - спасибо, буду иметь в виду

Именно так. За все нужно платить

Цитата:

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

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

Вот про разжевывать верное замечание, но заказчик должен четко сформулировать критерий приемки работы.
Я недавно выступал заказчиком, делегировал часть работ в период аврала.
Четкую спецификацию писать так проще действительно самому, но я обозначил как буду проверять.
Нажму то-то, посмотрю сюда-то и планирую увидеть то-то. Если увидел, молодцы, если нет, не молодцы.
По поводу деталей типа расположения полей, все на усмотрение исполнителя, даже если мне что-то не понравится, я проверяю только то, что оговорил заранее.
Если что-то упустил при постановке, значит сам себе злобный Буратино.

[macklakov]

Цитата:

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

Как результат есть неоправданные ожидания: вы ожидаете что постановщик задачи знает AX достаточно, а он ожидает того же от вас. А по факту никто ситуацию не балансирует своим опытом и знаниями. Поскольку тема затронула иностранного заказчика, я просто предупредил

Я бы описал это несколько другими словами.
Высокий уровень доходов в AX привлек большое количество аферистов. Они закладывают клиентам неоправданные ожидания, просто потому что не знают системы. Спихивая задачи на аутсорс они надятся что некие смышленные человечки что-то там запрограммируют и "консультанты" чудесным образом смогут внедрить тот бред, который понаобещали клиенту в продажном угаре. Есть целые консалтинговые компании состоящие исключительно из таких личностей.
Как с такими себя вести? Работать исключительно по time and material. Проект они все равно провалят. Большинство модификаций, как минимум, бесполезны, а чаще вредны для системы. Вменяемые уточнения они дать не смогут, т.к. не в курсе что это надо было у клиента спрашивать, а теперь боятся обнаружить свою несостоятельность. Так что кроме почасовой ставки с такими ребятами ловить нечего. И пусть жадность не вводит вас в заблуждение ложными надеждами. Есть заказы которые лучше не брать.

[ax_mct]

Цитата:

Сообщение от Кирилл

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

В этом и прелесть - придумывать. Если не совсем то, то переделаем или добавим.
За счет клиента но в рамках одобренного. Спецификации в таких случаях только вредят.

Цитата:

Сообщение от Кирилл

А как он будет проверять правильно вы выполнили задачу или нет? У него в голове есть сценарий тестирования? Или можно такому консультанту впарить что-угодно и сказать что так и надо?

Программист как правило самый опытный в проектном плане. И если не подумает и не скажет сам какие есть сценарии и какие он реализовал а какие нет, то он плохой программист в глазах консультанта и в глазах клиента.

Цитата:

Сообщение от Кирилл

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

Мы то ожидаем одного а они другого. Консультант это передаст, а клиент - чайник.
Только с программиста как с самого взрослого спрос.

Цитата:

Сообщение от Кирилл

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

По возможности - да. Но это ограничение самой текучести процесса как дамба на реке.
Доверие - вот на чем все держится так как минимизируя риски мы бетонируем/фиксируем там где нужно и не нужно.
То есть заказчик должен доверять подрядчику в том что тот лучше его знает что ему как клиенту надо. В этом то и суть консалтинга.

[ax_mct]

Цитата:

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

Я бы описал это несколько другими словами.
Высокий уровень доходов в AX привлек большое количество аферистов. Они закладывают клиентам неоправданные ожидания, просто потому что не знают системы. Спихивая задачи на аутсорс они надятся что некие смышленные человечки что-то там запрограммируют и "консультанты" чудесным образом смогут внедрить тот бред, который понаобещали клиенту в продажном угаре. Есть целые консалтинговые компании состоящие исключительно из таких личностей.
Как с такими себя вести? Работать исключительно по time and material. Проект они все равно провалят. Большинство модификаций, как минимум, бесполезны, а чаще вредны для системы. Вменяемые уточнения они дать не смогут, т.к. не в курсе что это надо было у клиента спрашивать, а теперь боятся обнаружить свою несостоятельность. Так что кроме почасовой ставки с такими ребятами ловить нечего. И пусть жадность не вводит вас в заблуждение ложными надеждами. Есть заказы которые лучше не брать.

Да какой там высокий уровень доходов? Все среднее по бизнес-приложениям.

Не надо термин "спецификация" подменять словом "модификация".
Именно консультанты, претендуя на знание системы и следование методологии, все и портят.

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

Заказчик/клиент в своих бизнес-требованиях - он как ребенок. Невинен.
Все зло в искуствености спецификаций и искуствености разделения ролей.

[macklakov]

Цитата:

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

Да какой там высокий уровень доходов? Все среднее по бизнес-приложениям.

Для кого как. Вот представь ситуацию, операционистка по accounts payable Аманда посетила тренинг личностного роста. Она прониклась уверенностью что достойна большего и горит желанием чего-то достигнуть. Ее взгляд падет на инвойс от консалтеров, внедривших систему в которой она работает. И она говорит себе:"а я чем хуже? Почему они получают в 3 раза больше чем я?" Она пишет красивое резюме, где выпячивает свое базовое образование в accounting и упоминает о годе опыта работы с системой (но не уточняет в чем эта работа заключалась). Рано или поздно ей попадается PM который систему в глаза не видел. Этого PM радует что она довольно уверенно тыкается в менюшки и просит на треть меньше реальных консультантов. Вот эта Аманда и есть ваш заказчик.

Цитата:

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

Заказчик/клиент в своих бизнес-требованиях - он как ребенок. Невинен.

Это невинность библейского толка. В смысле, клиент даже не знает что можно чего-то хотеть, а тем более требовать. Он как крестьянин начала 20-го века, который решился не механизацию. Если к нему прийти и начать спрашивать про бизнес-процесс, он начнет много и подробно говорить про корма, конюхов, чистку навоза, услуги коновала и т.д. Задача же консультанта очистить требования до стадии "мне надо пахать и сеять" объяснить что такое трактор, как им пользоваться и обслуживать, какие к нему бывают плуги и сеялки.
Как понимаешь, слесарь-механник в этой схеме чаще всего нужен чтобы исправлять конструктивные недостатки трактора или если трактор пытаются использовать не по назначению.