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

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

Губочкин АлексейА вот на то, чтобы сделать заполнение экранных форм удобным (а они при рассчетах зарплат вообще довольно громоздкие), иной раз уходила куча времени - cделал, поработали - неудобно - переделал - поработали - неудобно - переделал, поработали - удобно.Если бы вы хорошо знали данную область бизнеса (предметную область) и имели опыт реализации аналогичных систем с первоклассным юзабилити, может не пришлось бы переделывать ?

Хотя такая ваша оценка проделанной работы типична для позиции стороннего разработчика.

Губочкин АлексейВ данном случае имеет место ситуация, когда пользователи сами до конца не знают, что им нужно и как оно дожно выглядеть. Кроме того, программа пишется в итоге для них и поэтому всё должно быть сделано так, как им удобно исходя из технологического процесса. Отсюда и переделки.Более чем знакомая ситуация.

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

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

iscrafm...
Как я заранее говорился, вопрос это весьма и весьма дискутируемый.

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

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

Так что можно сказать, что моя точка зрения относится к аналитику-разработчику, всеми силами играющему на стороне самого заказчика.

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

iscrafmВ изучении конкретного бизнеса в процессе создания системы нет ничего предосудительного, с этого проекты начинаются.Я понимаю вашу точку зрения.

Мы опять возвращаемся определениям терминов. Позволю себе привести аналогию.

Вам надо сделать ремонт в своей квартире. Возможны два варианта развития событий.

Бригада (или фирма) в лице бригадира во время КОРОТКОГО интервью о ваших предпочтениях берет на себя работу под ключ. Поскольку они занимаются только ремонтом и таких ремонтов они уже переделали не один десяток, то проведенной беседы о тм, что же вы предпочитаете им достаточно. Они способны понимать ваше неопределенное мычание и шевеление пальцами в воздухе. Более того, они заранее способны предугадать подводные камни, которые вам даже в голову еще не приходили и выбрать оптимальный способ их преодоления.

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