Конфликтная ситуация. Интересно Ваше мнение.

Если бы ситуация была клиент - программист. И заказчик не принимает заказ. То программист должен выполнить требования.

В данной ситуации посредник должен был:
0. организовать составление подробного ТЗ в начале
1. Подобрать грамотного качественного программиста
2. Контролировать по ходу работы и согласовывать с заказчиком
3. до принятия у программиста, сдать заказчику.

Ни один из этих пунктов не выполнен.

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

Если делать только то что умеешь - это делать только программки из учебника типа hello world. Остальные, особенно крупные проекты, бывают в первый раз. И делать их просто так от балды для самого себя невозможно, только по реальному заказу.

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

Цитата ("voral"):

Я не оправдываю программиста, но он заказ выполнил и сдал.

А я и не спорю.

Цитата ("voral"):

Да, пусть, результат не так уж хорош. Но он делает как умеет.

И с этим не спорю. Качество работы низкое, делает как умеет. Но это не причина завышать оценку (отзыв).

Цитата ("alibek"):

Цитата ("SmartDesign"):

Программисты не создают программные продукты, они пишут программы.

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

Вам когда окна/двери ставят в квартиру, откосы то же делают?

По-умолчанию, заказчик получает именно ПО(программное обеспечение — читай программу), а не программный продукт. По самым скромным оценкам создание програмного продукта в 3-4 раза дороже создания программы (при том же функционале). Вы уверены что это нужно большинству заказчиков?

Цитата ("SmartDesign"):

По-умолчанию, заказчик получает именно ПО(программное обеспечение — читай программу), а не программный продукт.

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

Цитата ("SmartDesign"):

Вы уверены чо это нужно большинству заказчиков?

Нет, многим (возможно и большинству) это не нужно. Поэтому и составляется ТЗ, в котором определяется объем и содержание работ.

Насчет дверей и окон — да, делают.

посилання
Цитата:

Программное обеспечение (Software) - набор компьютерных программ, процедур и связанной с ними документации и данных (ISO/IEC 12207).

Таким образом, программное обеспечение - это не просто программа. Это еще и документация и руководство пользователя.

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

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

Для скептиков добавлю, что это не самодеятельность INTUIT, это определение из учебников.
На самом деле фраза "Таким образом, программное обеспечение - это не просто программа. Это еще и документация и руководство пользователя." даже не точная. Для ПО существует ряд характеристик, позволяющих оценить качество программного продукта, и эти характеристики — не только документация.

Приведено определение програмного продукта:
Цитата:

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

По этому не относится к делу.

Смотрим посилання

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

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

На счет окон — стараются не делать. Т.к. у заказчика могут быть свои требования.
Если делают бесплатно, а я буду говорить: "что вы делаете белые прямые откосы когда у меня даже потолок зеленый, нужно зеленые и в рельефный цветочек?" — пошлют и правильно сделают.

Спасибо за дискуссию.

Я не только посредник, но и сам пишу программы. Программы, которые можно продавать сразу, на завершающей стадии, а не мусолиться потом с интерфейсом.
Часто нельзя описать весь интерфейс до каждого пикселя и глупо было бы описывать как выглядит счет-фактура или накладная.
Концептуальные понятия как работает та или иная функция и как должен выглядеть тот или иной выходной документ должны присутствовать.
Так же, как и gomer66 считаю, что специалист никогда говно делать не будет, если на это не было спецзадания. Фраза вида "ну раз не сказали как, значит буду лепить говно" подходят людям без опыта.
Здесь я ошибся в выборе исполнителя, который заявил адекватную стоимость, сделал оценку, однако затянул сдачу проекта по срокам в 2 раза и отказывается доводить всё до ума без дополнительной оплаты.
В моих ТЗ никогда нет описания как должна работать авторизация и распределение прав доступа, как должны формироваться документы (их внешний вид), если они типовые, нет описания как должны выглядеть журналы и сколько компонентов можно поместить на одну экранную форму и т.п. Если ты создаешь конечный продукт, то это должно быть продуктом, а не жалким подобием.
Собственно поэтому я особо и не смотрел что там и как. Важные вопросы по логике программы решались нормально, без задержек. Интерфейсную часть и логику в связях объектов я не смотрел, т.к. был уверен в том, что человек, если не сделает лучше, то по крайней мере не хуже, чем делаю я. Энштейн рулит!

Цитата ("gomer66"):

Если берешься за какую-то работу, будь ты програмист или каменщик, значит автоматически берешь на себя риски - риски невыполнения, риски сделать говно, риски заболеть и т.д.

Об этом я вообще молчу. Тут удивились тем, что за просрочку работ нужно выплачивать неустойку.
Исполнитель мне заявил - я ж не виноват что проект затянулся по срокам в 2 раза. У меня выходные были, мне с семьей нужно было быть и т.д. и т.п. Доказать что-то вообще не реально.
Хотя отчет по трудозатратам, предоставленный исполнителем, гласит о том что он потратил ровно столько времени, сколько было запланировано, и еще оставался бы запас в 2 недели (при условии 8ч/рабочего дня, без выходных). а тут задержка в 1,5 месяца...
До этого видел работы исполнителя, вполне сносные по качеству. а тут конфуз... Фраза - ну мне же удобно работать, или я сделал так как я посчитал нужным, а не так как говорит здоровое понимание что и как должно работать, просто убивает.... ты ж программу для других людей пишешь, а не для себя....

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

За 10 лет работы программистом я первый раз в жизни буду пытаться найти компромис между ****ом и супер****ом...

Цитата:

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

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

Я а стороне программиста.
Пользователи часто (если не всегда) не представляют, что они хотят получить и адаптируются походу. Почти всегда вспоминают, что надо обязательно еще то и это т.к. иначе нет смысла, но работа сделана и мелочь (по мнению пользователя) требует от программиста коренной переделки.
Уточнять задание заранее - значит прибавить себе работу за уже оговоренную сумму.
Здесь налицо неопытность, непредусмотрительность, хитрость, жадность и т.д. всех участников. НО! Заплатить надо! В море гавенного программного обеспечения и интерфейса неуклюжая, работоспособная работа будет выглядеть нормально. Шедевр может не сработать из-за неверного направления. Риск переплатить увеличивается.
Теперь надо вести переговоры с заказчиком и обьяснить, что "золотая работа может оказаться напрасной потерей.

Цитата ("Andreyik"):

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

Как раз задумка была задумка и основное требование - качество исполнения, которое подразумевает не только качественный код, но и удобство работы с программой конечным пользователем, т.н. юзабилити, которое у испольнителя отсутствует, по ходу даже на уровне подсознания. Я видел предыдущие работы, вроде неплохие были, но здесь тьма.
За столько лет мне впервые самому стыдно представлять проект заказчику, и если мне не удобно работать с прогой, то представлю что мне скажут завтра )))

p.s. на днях показал программу нескольким знакомым. ни одного положительного отзыва......

Цитата:

Как раз задумка была задумка и основное требование - качество исполнения, которое подразумевает не только качественный код, но и удобство работы с программой конечным пользователем

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

а если б товарищ сделал интерфейс в стиле мсофис2007? куда уж интерфейснее, а не всем привычно и удобно

Цитата ("3300101"):

Я не только посредник, но и сам пишу программы. Программы, которые можно продавать сразу, на завершающей стадии, а не мусолиться потом с интерфейсом.
......
За 10 лет работы программистом я первый раз в жизни буду пытаться найти компромис между ****ом и супер****ом...

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

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

- Детальное обсуждение ТЗ со всеми форс-мажорными ситуациями и последствиями
- Предварительные показы ПО и его обсуждения

Цитата:

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

Эта фраза говорит как раз об отсутствии у Вас опыта. В грамотных (:!: ) ТЗ расписывается каждая кнопка, ее цвет, размер шрифта, расположение и отступы от края формы. Ваше понятие "типовая форма/документ" вполне может отличаться от его восприятия таковой. Именно поэтому (уж сколько раз твердили на форуме) - чем подробнее ТЗ, тем меньше потом подобных тем "а почему он сделал не так, как я думал?". Чтение мыслей не входит в задачу кодера

Цитата ("voral"):

Цитата ("3300101"):

Я не только посредник, но и сам пишу программы. Программы, которые можно продавать сразу, на завершающей стадии, а не мусолиться потом с интерфейсом.
......
За 10 лет работы программистом я первый раз в жизни буду пытаться найти компромис между ****ом и супер****ом...

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

Опыта достаточно, я начал программы писать с 1996 года, когда только начали появляться компьютеры. Был доступ к компам в то время, этим занимаюсь до сих пор.
Задача поставлена была точно, по функционалу все выполнено, только вот пользоваться программой очень неудобно. Было основное требование - качество и сроки. И сроки в 2 раза увеличены без видимых на то причин и качество на нуле.
Думаю важно было бы сказать что у исполнителя это первый коммерческий проект - отсюда и фразы - если мне удобно то должно быть и им удобно; если небыло сказано как раздавать права, сделаю через жопу; если не сказано что каждое новое окно не должно накладываться на другое, то сделаю так чтобы открывая новое окно пользователь не видел сколько окон открыто раньше - все формы отцентрирую и не добавлю таскбар в MDI приложение. и т.д. и т.п. это глупо лепить гавно и надеятся что кто-то это купит. Хотя по функционалу (в соответствии с ТЗ) всё считает так как нужно.
С таким же успехом люди могут продолжать работать на бумаге. А что? всё работает как надо, не надо никому раздавать права на конкретные операции... только вот не удобно.... :idea:

Вы не правы
Как уже не раз говорилось, удобство и "интуитивно понятный интерфейс" это ОЧЕНЬ абстрактное понятие, мне к примеру не удобно работать с некоторыми ide написаными под linux, привыкнуть можно но зачем, если сразу упадет продуктивность работы, но очень нравиться терминал и удобство использования
В обьязаности программиста входит составление документации и качество кода НО не как не ГРАФИЧЕСКОГО ИНТЕРФЕЙСА(вы хоть подумали что говоите программист и графика ) и не более того, если конечно сам кодер не согласился сделать GUI, иконки и прочую лабуду, в чем я очень сомневаюсь
В даной ситуации, вашей задачей или заказчика, было взять даже и нарисовать на листочке расположение элементов(но видимо вы поленились, и положились полностью на "телепатизм" программера) много их не нужно 1-2 листочка по 2 рисунка с головой бы хватило, уверяю вас если бы это было сделано, никакого "гавн*" как вы выразились не последовало бы, а так ...
За что боролись, на то и напоролись .... и обвинять вы можете только себя любимого
- за то что не попросили показать результат в процессе
- за то что не предоставили этой информации которая вам и так понятна, как вы говорите, сразу или в процессе

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

Бапки, бапки, бапки :P

Доброго Всем Дня!

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

ЭТО СМЕШНО! Программер работая с Delphi, например, найдёт удобным одно расположение функционала, бухгалтер, который в своей жизни ничего кроме 1С не видел, будет считать, что удобно совсем другое.

Цитата:

p.s. на днях показал программу нескольким знакомым. ни одного положительного отзыва.....

К сожалению у нас качество работ до сих пор оценивается похожими критериями. Вопрос - зачем создавать маркетинговый отдел какой-либо уважающей себя фирме? Поспрошал знакомых - и всего делов-то :!:

А вообще - ТЗ, господа, ТЗ.

С уважением, Пётр Эшед, группа DH.

Цитата ("3300101"):

Опыта достаточно, я начал программы писать с 1996 года, когда только начали появляться компьютеры. Был доступ к компам в то время, этим занимаюсь до сих пор.

Чегоооо!!!!? Когда появились компы?
Я начал заниматься программированием на станции пионеров в 1987. Компьютер Агат даже с цветным дисплеем.
В 1996 защитил диплом темой была научная работа - продаваемая программа : расчет грозозащиты объектов с графическим редактором в трех проекциях (язык TurboPascal 7 с ООП!). На полставки работал электроником в институте с парком Эра, ЕС1840 и Паккарды.
С 1996 года по 1998 работал сисадмином в организации имеющей в сети более 1000 компов (частично с мождемным соединением).
В 1995 году у нас были лабы по Архикаду, если не ошибаюсь тогда уже была версия 11! (Кстати весьма прикольно руссифицированная - от некоторых переведенных команд просто валялись под столом).
Так, что извините, но вы не застали появления компов. Ко мне в 96 уже на практику парни приходили на много продвинутее меня. А я тогда еще по привычке боролся за каждый лишний байт исполняемого файла программы.

Цитата ("3300101"):

Задача поставлена была точно.

Неверю. Лучше бы вы не говорили про свой стаж.... Или считали свой стаж более адекватно. Я свою первую прогу написал 21 год назад. Тем не менее я не могу сказать, что это стаж. Т.к. серьезным программированием (к тому же на заказчика) стал заниматься позже года с 94.
За 10 лет можно научится ставить задачи так, чтобы не возникало таких тем.

Цитата ("3300101"):

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

Нет это не важно:
1. Вы имея столь огромный опыт в программировании приняли именно такого программиста на работу
2. Именно вы не смогли проконтролировать ход работы
3. Именно вы приняли его работу в том виде в каком она не понравилась заказчику

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

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