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

[DaxDevRemote]

08.06

От иностранной компании есть пара вялых проектов, на которых мы работаем.
Задачи ставятся ужасно - информацию нужно выуживать из каких-то старых чьих-то переписок. Такое ощущение, что была какая-то команда, и мы за ними доделываем то, что они по каким-то причинам не доделали.
Делал SSRS отчет - в качестве ТЗ была только одна картинка этого отчета без какого-либо описания и само название отчета, по которому можно было только догадываться откуда брать информацию для него. Пытался выяснить больше информации, не получилось. Пришлось сделать хоть как. Замечаний не поступало, скорее всего никто и не проверял.
В целом задач мало, время тратится неэффективно. Есть много организационных вопросов, которые пока не задаю - жду первую оплату (выставил инвойс за май).
Хорошо, что фиксированный оклад - главное чтобы платили!)

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

[ALES]

Цитата:

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

08.06
... главное чтобы платили!)...
Интегратор обещал поторопить клиента с приемкой задачи и промелькнула надежда на оплату на следующей неделе.

Платят?

[ax_mct]

Цитата:

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

Платят?

Присоединяюсь к вопросу. И от чего зависит оплата и зависит ли?

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

И всегда есть риск потерять оплату примерно за месяц работы. Но без рисков никак.
Альтернатива - подписанные таймшиты в конце/начале каждой недели. Но для удаленных программистов это не очень реально.

[macklakov]

Цитата:

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

Задачи ставятся ужасно - информацию нужно выуживать из каких-то старых чьих-то переписок. Такое ощущение, что была какая-то команда, и мы за ними доделываем то, что они по каким-то причинам не доделали.

Если тебя наняли "с дуру", чисто чтобы ресурс застолбить, то оптимальная стратегия сидеть тихонько и смотреть как деньги на счет капают, пока не выгонят или не запрягут наконец-то. Я лично наблюдал персонажа, который ухитрился в таком режиме 2 года на проекте просидеть, получая весьма вкусный рейт. Если же они тебя наняли потому, что зашиваются, то настоятельно рекомендую добывать контакты пользователей и самому их вылизывать. Крайне желательно перейти на вербальное общение. У русских не просто так иммидж "самой читающей нации", на западе народ, в среднем, читает с гораздо меньшей охотой. И потом, корпоративная переписка в ряде стран имеет статус официального документа (примерно соответствует российскому нотариально заверенному документу) поэтому опытные люди осторожничают и, опять таки, предпочитают обсуждать вопросу устно. Еще крайне желательно побывать в офисе клиента хотя бы пару недель. И там посвятить как можно больше времени налаживанию отношений.
Ситуация на проектах бывает такая, что человек тебя нанявший без продыху мотается по митингам и ему просто некогда требования составлять. И распределять работу среди сотрудников тоже некогда. Да и сотрудник западный личность самодостаточная, на микро-менеджмент нервно реагирует. Поэтому есть ожидание что зрелый профессионал возьмет под свой полный контроль кусок проблем и тем самым снимет часть головняка с нанимателя.

[pitersky]

Цитата:

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

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

Стесняюсь спросить, но откуда тогда разработчик должен брать задачи, если ему их никто назначать не будет?

[ax_mct]

Цитата:

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

Стесняюсь спросить, но откуда тогда разработчик должен брать задачи, если ему их никто назначать не будет?

Такое бывает когда еще нет конкретных задач но девелоперский член в команде уже должен быть. Часто в самом начале проекта.

"Keep calm and invoice on".

Другое дело что удаленного работника никто не видит что он сидит в офисе 9 - 17 и как-то надо грамотно списывать время.
Типа читал аксапту начиная с класса A*, через неделю планирую дойти до классов начинающихся с B

[macklakov]

Цитата:

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

Стесняюсь спросить, но откуда тогда разработчик должен брать задачи, если ему их никто назначать не будет?

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

[Bobkov]

Цитата:

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

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

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

[pitersky]

Цитата:

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

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

Вообще-то задача консультанта, как я её понимаю - не собрать и передать хотелки (это и сам разработчик может сделать), а грамотно перевести эти хотелки на язык архитектуры аксапты, чтобы разработчик не занимался игрой в угадайку. Если же разработчик всё делает сам (и задачи сам ищет, и интервью пользователей сам проводит, и ТЗ сам составляет), то в чём смысл существования консультанта? Быть испорченным телефоном?

Цитата:

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

Поэтому, я не могу согласиться, что встреча с таким деятелем - это невезение. Надо просто уметь им управлять

Сразу вспоминается бессмертное "Я не люблю кошек! - Ты просто не умеешь их готовить"(с)

[ax_mct]

Цитата:

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

Вообще-то задача консультанта, как я её понимаю - не собрать и передать хотелки (это и сам разработчик может сделать), а грамотно перевести эти хотелки на язык архитектуры аксапты, чтобы разработчик не занимался игрой в угадайку. Если же разработчик всё делает сам (и задачи сам ищет, и интервью пользователей сам проводит, и ТЗ сам составляет), то в чём смысл существования консультанта? Быть испорченным телефоном?

Тогда это архитектор. А их считай что нет в природе.

Консультант он консультирует клиента а не разработчика.

Когда консультант начинает играть в архитектора (неважно функионального или технического) то жди беды.

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

[Bobkov]

Цитата:

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

Если же разработчик всё делает сам (и задачи сам ищет, и интервью пользователей сам проводит, и ТЗ сам составляет), то в чём смысл существования консультанта? Быть испорченным телефоном?

Навскидку:
К такому консультанту можно отправлять людей, которых надо успокоить.
Такого консультанта можно отправить на бессмысленное совещание.
Такой консультант может собирать циркулирующие в компании слухи.
Такой консультант может втереться кому-то в доверие и поспособствовать следующей продаже.

[macklakov]

Цитата:

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

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

Мне они тоже нравятся, когда они не запарывают внедреж напрочь и тем не портят рынок
Но я-то здесь, мне не сложно выйти напрямую на пользователя, stakeholder, SME или как там их еще называют. А вот у аутсорсера могут быть сложности, если он будет рассчитывать на консалтера. Т.к. такой консалтер суть замаскированный сейл. Здесь большая часть "архитекторов" это, по сути дела, продавцы-консультанты, разбирающиеся в том, чем торгуют. Соответственно, что ты можешь узнать у сейла? Что клиенту в бульдозере понравился веселенький желтый цвет, который он любит с детства? Информация ценная, спору нет (я серьезно). Но ведь клиент по умолчанию пологал что этот бульдозер не хуже других годится для его нужд. Нужно вызнавать желаемые ТТХ. А вот этого наш консультант-ковбой сделать не в состоянии. Ибо это натурально стареющая девочка-блондинка, которая вот всеми этим противными железяками занимается исключительно чтобы пополнять коллекцию обуви.

[Bobkov]

Цитата:

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

Соответственно, что ты можешь узнать у сейла?

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