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

[Pustik]

Цитата:

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

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

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

[NetBus]

Цитата:

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

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

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

[sukhanchik]

Цитата:

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

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

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

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

[driller]

Цитата:

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

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

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

[gudzon]

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

[S.Kuskov]

Цитата:

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

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

+1

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

Цитата:

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

[gl00mie]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[ax_mct]

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

[mnt_dx]

Ещё что вспомнил по поводу оплаты: часы разработки клиент принимает охотнее за счет наличия кода/необходимости теста, а по работам консультанта может отмахнуться, например, если кк не смогла подписать протокол/акт по работам. Доработку можно забрать, а настройку/обучение уже не заберешь.

[gudzon]

Цитата:

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

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

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

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

[ax_mct]

Цитата:

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

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

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

[gudzon]

Цитата:

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

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

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

[gudzon]

Цитата:

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

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

А вот оно следствие службы в армии. Желание решить все проблемы дисциплиной и командными действиями. Ну ну.

[ax_mct]

Цитата:

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

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

Построенные бараны могут сделать работу лучше чем толпа талантливых небаранов.
Просто моя позиция что если автомат в руки барану давать то под полным контролем.
Идеального ничего не бывает но требования к кодированию и дизайну должны соблюдаться. И если про армию то это я сказал за как раз за командную работу где одним неидеальным помогают/проверяют другие приспособившиеся неидеальные.
То есть важен порядок а не талантливость. Порядок бьет класс.
P.S. А опыт у меня армии СССР. Выравнивания по нитке и воспитания через коллектив Эх, за каждое отклонение по BP весь проектный состав должен отжиматься пока оно исправляется.

[ax_mct]

Цитата:

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

А вот оно следствие службы в армии. Желание решить все проблемы дисциплиной и командными действиями. Ну ну.

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

А как вы предлагаете решать проблемы качества программирования?
Дисциплина в рамках избранной методологии. Ролевое взаимодействие в команде.
Что иначе?

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

[ax_mct]

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

Был пост но пропал про то что нельзя все мерять качеством кода и есть и другие критерии как скорость, стоимость и политика. Согласен. Руководителей проектов тоже надо строить Не вопрос

[gl00mie]

Цитата:

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

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

Цитата:

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

А вот оно следствие службы в армии. Желание решить все проблемы дисциплиной и командными действиями. Ну ну.

Дисциплиной и командными действиями не решаются все проблемы, но решается задача взаимодействия с определенным типом сотрудников, см. Ситуационное лидерство:

Цитата:

Стили лидерства

• S1 Директивный - характеризуется односторонней коммуникацией, лидер определяет роли индивидумов или групп и указывает, что, как, где и когда делать для выполнения задачи, а также следит за выполнением.
• S2 Наставнический - продолжая давать указания и следить за выполнением заданий, лидер использует двусторонние коммуникации, объясняет принятые решения подчиненному ("продает" их), поощряет высказывание собственных идей и предложений.
• S3 Поддерживающий - участие в организации процесса работы, совместное прияние решений...
• ...

Уровни зрелости сотрудников

• M1 «Неспособен и не настроен». Не хватает навыков для выполнения работы, нет желания и возможности выполнять задачу/работу или брать на себя ответственность за нее. Сотрудник этого уровня нуждается в четкой постановке задачи, инструкциях и контроле со стороны руководителя — используется директивный стиль (S1).
• M2 «Неспособен, но настроен». Не может брать на себя ответственность за задачу, но хочет ей заниматься; новичок-энтузиаст. Сотрудник этого уровня нуждается и в директивах руководителя, и в его поддержке — лидер использует наставнический стиль (S2).
• M3 «Способен, но не настроен»
• ...

[ax_mct]

Прошу прощения если под дисциплиной было понято отдавать честь и приходить вовремя а также не лениться и как грамотно нагнуть или построить сотрудника. Я как то больше про дисциплину не персональную а проектную то есть про методологию как то Agile, Step by Step и так далее. А чтобы следовать такой методологии (то есть устава службы) и нужно понимание и чувство порядка и дисциплины. И если на коленке и впопыхах можно без особого риска сделать пару кастомизаций то когда их десятки и сотни только строевой шаг может спасти.

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

[Stitch_MS]

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

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