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

[Raven Melancholic]

Цитата:

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

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

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

[ax_mct]

Цитата:

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

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

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

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

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

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

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

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

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

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

Цитата:

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

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

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

[ax_mct]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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