Консалтингу не выгодна разработка

[Pustik]

Цитата:

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

Не в том дело чтобы отказывать клиенту в разработках, а в том чтобы делать их как можно меньше особенно на этапе запуска.

Мне кажется, что цель состоит в том, чтобы обеспечить клиента полноценно работающим функционалом на определенный срок, без вызова стороннего программиста, который будет исправлять баги, выявленные в процессе ОПЫТНОЙ эксплуатации.И отговорки "нам за 2 часа работы в САП платят больше, чем здесь за 2 дня" должны инкреминироваться как не качественное выполнение работ.

[ax_mct]

Цитата:

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

Мне кажется, что цель состоит в том, чтобы обеспечить клиента полноценно работающим функционалом на определенный срок, без вызова стороннего программиста, который будет исправлять баги, выявленные в процессе ОПЫТНОЙ эксплуатации.И отговорки "нам за 2 часа работы в САП платят больше, чем здесь за 2 дня" должны инкреминироваться как не качественное выполнение работ.

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

[ax_mct]

Да и консультант должен не ставить задачи а решать их функциоанально. Программирование как открытая операция на сердце - последнее средство.

Все доехал до клиента (5 часов сидя в поезде), ушел в ненавистное программирование... Главное руки потом помыть

[veps]

и не только консалтингу, бизнес тоже считает деньги.
После покупки компанией Heineken завода Амур-Пиво в Хабаровске и последующего тиражирования проекта SAP, на заводе закрыли линию по производству бутилированной питьевой воды, т.к. в системе отсутствовали номенклатуры, не были описаны и проработаны алгоритмы расчета себестоимости в SAP и понадобилось бы программировать :-)

[Pustik]

Я не понимаю, блин, почему никто не говорит о специфики предприятия? Или аксапта такая крутая , что может вот так просто влится в предприятие и при этом там жить полноценной жизнью без модификаций?.Сомневаюсь , что это так.

[Ivanhoe]

Цитата:

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

Я не понимаю, блин, почему никто не говорит о специфики предприятия? Или аксапта такая крутая , что может вот так просто влится в предприятие и при этом там жить полноценной жизнью без модификаций?.Сомневаюсь , что это так.

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

Изначально тема - про Консалтинг (и даже не совсем про Ax, про Ax условие появилось позже).

[Pustik]

Цитата:

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

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

Если вырезки, которые связаны с темой,превращать в отдельные ветки, то потом можно запутаться, Вы со мной не согласны?

[Ivanhoe]

Цитата:

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

Если вырезки, которые связаны с темой,превращать в отдельные ветки, то потом можно запутаться, Вы со мной не согласны?

Не согласен. Общий подход форума - обсуждать не все подряд, а создавать отдельные темы. В отдельной теме с удовольствием поделюсь своим видением отраслей, применимостью AX и т.п.

[Pustik]

Цитата:

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

Не согласен. Общий подход форума - обсуждать не все подряд, а создавать отдельные темы. В отдельной теме с удовольствием поделюсь своим видением отраслей, применимостью AX и т.п.

Соглашусь и спорить не буду.

[fed]

Цитата:

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

Я не понимаю, блин, почему никто не говорит о специфики предприятия? Или аксапта такая крутая , что может вот так просто влится в предприятие и при этом там жить полноценной жизнью без модификаций?.Сомневаюсь , что это так.

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

Ну и надо помнить, что есть отрасли на которые Аксапта в принципе не становиться с разумным уровнем доработок (типа непрерывки например). Конечно можно ее переделывать, но скорее всего это ничем хорошим не кончиться. Лучше такому клиенту просто не продавать аксапту (опять таки - лучше в долгосрочной перспективе. В краткосрочной перспективе - лучше продавать кому угодно, а потом валить из фирмы-продавца с премией полученной за продажу ).
(Дисклеймер - про процессное производство в DAX2012 - знаю. Лично не внедрял. Уверен что до DAX версии 8, оно будет малость кривоватым и лучше с ним не связываться...)

[NetBus]

Цитата:

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

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

Не совсем тактичный вопрос всем. Можно указать, например ссылкой, проект внедрения, который развалился из за большого объема реализации потребностей клиента (допиливания)?

[sukhanchik]

Цитата:

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

Не совсем тактичный вопрос всем. Можно указать, например ссылкой, проект внедрения, который развалился из за большого объема реализации потребностей клиента (допиливания)?

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

Можно поискать по пресс-релизам компании, у которых внедрение делала одна компания, а довнедрение / доделки - другая компания.
Это не значит, что проект был развален или не был развален. Но факт по смене подрядчика есть.
Это означает, что как минимум клиент решил доверить допработы не тому, кто внедрял.

[driller]

Цитата:

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

Не совсем тактичный вопрос всем. Можно указать, например ссылкой, проект внедрения, который развалился из за большого объема реализации потребностей клиента (допиливания)?

Рискую сесть в лужу, но если у кого больше информации пусть поправит.
Проект OXS в Енисейской ТГК-13, не яркий ли тому пример?

[Pustik]

to fed
как всегда грамотно и по делу. Очень информативно сказано, для рынка. Некоторым людям да эти слова в уши.

[gudzon]

Все таки подозреванию, что Чрезмерная разработка не есть причина развала проекта. А всего лишь симптом. Нельзя сказать, что человек умер от жара. Жар это всего лишь реакция организма на инфекцию. Так же нельзя сказать, что чрезмерный кодинг губит проект. Это всего лишь реакция на другие причины. А причины как правило разные. От действительно некомпетентности до простой политики.Сменилось руководство, а заносили другому. Как часто и бывает. Так что бестолку обвинять симптом, не зная причины.
Среди людей часто встречаются идеалисты. Для них главное качество. Затраты и сроки не столь важны. Видимо школа учит делать все на 5+ при это время не ограничено - все равно за партой сидеть 10 лет. Особенно такие встречаются среди хороших программистов. Что видно по обсуждениям на форуме. Такие люди очень гордятся своим прекрасным кодом и любят третировать менее требовательных коллег по этому поводу. Часто заказчик на приемку сажает именно идеалиста. Такие люди не понимают, что малый процент ошибок при разработке информационных систем вполне допустим. Часто на завершающем этапе начинается вой по поводу мелких багов. Хотя в этом ничего нет страшного. С увеличением требования к чистоте кода экспоненциально растут затраты. А затраты на исправление ошибки в разы меньше затрат на их профилактику. Это знают все разработчики ПО. Я бы наоборот насторожился узнав, что проект сдан без ошибок. Это говорит либо об исключительной гениальности внедренцев, либо о том, что моя компания втридорога расплатилась за команду гениев-перфекционистов. И это только одна из возможных причин развала проекта. На крупных проектах как правило клубок из проблем.
Так что не пишите категорично "Только плохие внедренцы заваливают проекты". Это как утверждать - если от мужа ушла жена, значит муж плохой. Такая логика истинна только ну на очень примитивном уровне абстракции.

[S.Kuskov]

Цитата:

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

Все таки подозреванию, что Чрезмерная разработка не есть причина развала проекта. А всего лишь симптом. Нельзя сказать, что человек умер от жара. Жар это всего лишь реакция организма на инфекцию. Так же нельзя сказать, что чрезмерный кодинг губит проект. Это всего лишь реакция на другие причины.

+1

"Консалтингу не выгодна разработка" = "Лечить больного хирургическим путём не выгодно"!

Цитата:

Женщина пришла к хирургу.
- Доктор, я упала и теперь болит бок.
- Садитесь - отвечает, а сам начинает копаться в инструментах.
- Доктор, а что вы собираетесь делать?
- Да уши вам отрежу. Женщина шмотки в охапку и ходу из кабинета. Пошла жаловаться к главврачу.
- У вас хирург странный, я ему говорю бок болит, а он собрался мне уши отрезать!
- А не волнуйтесь, хирурги все ненормальные, как чуть что - сразу резать. Я вам сейчас таблетки выпишу, так уши сами отвалятся.

[gl00mie]

Цитата:

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

Среди людей часто встречаются идеалисты. Для них главное качество. Затраты и сроки не столь важны. Видимо школа учит делать все на 5+ при это время не ограничено - все равно за партой сидеть 10 лет. Особенно такие встречаются среди хороших программистов. Что видно по обсуждениям на форуме. Такие люди очень гордятся своим прекрасным кодом и любят третировать менее требовательных коллег по этому поводу. Часто заказчик на приемку сажает именно идеалиста.

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

Цитата:

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

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

Вспоминается детский мультик про зайца: "И так сойдет!.."

Цитата:

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

С увеличением требования к чистоте кода экспоненциально растут затраты.

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

Цитата:

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

А затраты на исправление ошибки в разы меньше затрат на их профилактику. Это знают все разработчики ПО.

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

[gudzon]

Цитата:

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

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

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

[ax_mct]

Цитата:

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

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

Вот он недостаток неслужбы в армии и тем более в спецназе. То есть непонимание дисциплины и следования правилам а главное командных действий.
Перефразируя:
В Best Practices нет ничего страшного, за это только похвалят и нет никакого перфекционизма!
Все что нужно это парочка хороших сержантов (senior developers) и следование Уставу Боевой службы(Best Practices) . То есть дедовщина
То есть как минимум ревью и приемка кода.
Строить вас ботаников надо, строить
P.S. Не сочтите за оскорбление. Но плац плачет по многим

[gudzon]

Цитата:

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

Строить вас ботаников надо, строить

Да не в ту степь вы. Я ж не предлагаю выкинуть бестплактисис и отменить тестирование. Я такое никогда не прововедовал и не собираюсь начинать. Мой пост о том что люди не идеальны и проекты не идеальны. У вас что в армии все идеально служат? Каждый солдат пример доблести и чести? Каждый проект заканчивается идеально? Построить можно и баранов в ряд. Тем более пинками. Толку то.