Некоторые тут возмущались тем, что заказчик не хочет оплачивать время, затраченное на исправление багов программиста. А вот такой разговор с представителем заказчика сложился у меня. Собственно коменты с моей стороны излишни. Я просто в ауте.
Он: по поводу "работает криво" я тебе уже писал и приводил примеры как работает в MS Outlook. Боюсь, "криво" в данном случае довольно точная характеристика.
Я:
все такие вопросы описываются в ТЗ. То, что описано в ТЗ, сейчас выполнено в полном объеме. То, что это должно работать как Аутлук — это вы придумали сами. Я уже и так иду на уступки, выполняя требования, о которых не было в ТЗ ни слова
Он:
О том, что ТЗ опичсывает все требования к системе никто не говорил. ТЗ — лишь основа для понимания требовангия к системе. О дальнейших доработках и итеративности процесса мы говорили сразу.
Я:
ого, а вот это уже новость. Ты думаешь для чего вообще пишут ТЗ?? ТЗ для того и пишется чтобы избежать различий в понимании таких вещей между заказчиком и исполнителем
Я: >О дальнейших доработках и итеративности процесса мы говорили сразу
Да, и все они должны быть в рамках ТЗ
Он:
Это в теории.
Я:
это практика. Заказчик может хотеть чего угодно. Это не значит что я должен делать все что ему тольно не захочется
Он:
Такой процесс обречен на создание неуклюжих систем по окончании.
Он:
Практика — это то, что большинство систем кривые и плохо удовлетворяют потребность заказчика.
Я:
Это все слова. Весь, я повторяю АБСОЛЮТНО ВЕСЬ функционал должен быть отражен в ТЗ. Как раз во избежании таких вот ситуаций
Он:
Это невозможно.
Он:
Это иллюзия.
Он:
Он не может быть весь отражен в ТЗ, которое пишется один раз до начала работ.
Он:
Многие скрытые потребности выявляются только в процессе тестовой эксплуатации системы.
Он:
Иначе заказчик, как это и бывает в большинстве случаев, остается неудовлетворенным.
Он:
Что мы и видим в нашем случае.
Он:
Поэтому и сроки тянутся...
Я:
ты прикалываешься чтоли? ты правда думаешь что исполнитель обязан делать все вещи, которые потом напридумывает заказчик? Все, что вне ТЗ — на практике оплачивается отдельно. Но в данном случае я и иду на уступки, выполняя все это
Он:
На практике программные системы не удовлетворяют заказчика. Они не помогают ему делать его работу. Но они отлично отражают требования ТЗ.
Я:
на самом деле я ну прям в шоке. Ты представь ситуацию. Продавец продает шоколадку. Покупатель покупает, но через некоторое время приходит обратно, говоря при этом "вы знаете, мне она не понравилась, я-то хотел бублик, дайте мне еще и бублик"
Он:
Нельзя говорить об уступках в случае, когда регламент не определен.
Он:
Это не "коробочная" продукция — в этом все отличие.
Он:
Это главное отличие софта.
Я:
короче разговор неконструктивен. Давай лучше дождемся комментариев от заказчика
Он:
Это фундаментальное различие.
Он:
Я просто объясняю тебе отличие программного продукта от "бублика".
Я:
я уже сказал то, что думаю по этому поводу. Когда заказчик даст комментарии?
Он:
Я полагаю что сегодня. Если сроки сместятся, я сообщю об этом тебе сегодня.
Здравствуйте, Пятачок, Вы писали:
П>Некоторые тут возмущались тем, что заказчик не хочет оплачивать время, затраченное на исправление багов программиста. А вот такой разговор с представителем заказчика сложился у меня. Собственно коменты с моей стороны излишни. Я просто в ауте.
М-дааа... Вот против таких бесстыжих уродов и существуют сервисы типа rentacoder.com и weblancer.net, с резервированием предоплаты и арбитражом. Очень действенная мера, между прочим.
по стилю разговора представитель на бота похож
в целом конечно нельзя всего предусмотреть в ТЗ, но Use case системы определить на уровне ТЗ можно и если заказчик хочет бесплатно их добавлять, то тут ему надо объяснять что он неправ
Здравствуйте, Пятачок, Вы писали:
П>Я: П>Это все слова. Весь, я повторяю АБСОЛЮТНО ВЕСЬ функционал должен быть отражен в ТЗ. Как раз во избежании таких вот ситуаций
П>Он: П>Это невозможно.
П>Он: П>Это иллюзия.
П>Он: П>Он не может быть весь отражен в ТЗ, которое пишется один раз до начала работ.
П>Он: П>Многие скрытые потребности выявляются только в процессе тестовой эксплуатации системы.
П>Он: П>Иначе заказчик, как это и бывает в большинстве случаев, остается неудовлетворенным.
Ты неправильно ведешь разговор. Отвечать надо так:
Ты совершенно прав! Действительно, всего предусмотреть в ТЗ невозможно. Это нормальная ситуация. Действовать будем так: собираем в кучу все новые пожелания по переделки и доделки, составляем и утверждаем документ "Change Requests" (это типа мини-ТЗ), я делаю оценку времени и стоимости и если все всех устраивает, я принимаюсь за работу.
Как бы ты вежливо объяснил ему, что доработки вне ТЗ должны оплачиваться отдельно и после того как будет оплачено основное ТЗ? У меня уже слов не хватает.
Hello Пятачок,
> Как бы ты вежливо объяснил ему, что доработки вне ТЗ должны > оплачиваться отдельно и после того как будет оплачено основное ТЗ? У > меня уже слов не хватает. >
напиши что-нибудь вроде "А если у меня после завершения работ по ТЗ вдруг
личные деньги закончаться, и я к вам приду, вы меня покормите ?"
1. Не оговорен статус ТЗ и факт, что все последующие доработки, не связанные с исправлением ошибок в рамках ТЗ, делаются за доп. плату. Именно упор на ПЛАТНУЮ дальнейшую доработку и снял бы все вопросы, с одной стороны — что вы это будете делать (развивать систему) и не бросите заказчика, а с другой — это будет делаться за доп.денежку. А как договор подписывался? Если совсем непонятно что и как делать — поэтапно с возможностью внесения изменений в след. этап, но до тех пор, пока тот не начал выполняться.
2. По-моему этот представитель лоханулся на этапе создания ТЗ (в силу своей некомпетености, возможно) и теперь по-еврейски (сорру, если кого нечаянно обидел-к нац.отношение не имеет) пытается выйти сухим из воды, конечно же, за счет исполнителя и очерняя исполнителя в глазах своего руководства.
Что делать:
1. Найти в компетентных источниках определение ТЗ как документа, чтоб не было двоякого толкования.
2. Прекратить общение с этим представителем, выйти на основного заказчика, объяснить ситуацию и примерами из его же бизнеса, но без эмоций и фени, показать трудозатраты и в дальнейшем работать с ним напрямую. Таки, что-то переделаете забезплатно, точнее — в оплату за науку.
Здравствуйте, Пятачок, Вы писали:
П>Как бы ты вежливо объяснил ему, что доработки вне ТЗ должны оплачиваться отдельно и после того как будет оплачено основное ТЗ? У меня уже слов не хватает.
Так, оплаты не было ?
Ничего Вы никому не докажете.
Обозначьте свою позицию — и забудьте.
Не злите себя и других
Лучше давайте координаты заказчика — сюда,
чтоб другие не нарвались
Здравствуйте, Пятачок, Вы писали:
П>Некоторые тут возмущались тем, что заказчик не хочет оплачивать время, затраченное на исправление багов программиста. А вот такой разговор с представителем заказчика сложился у меня. Собственно коменты с моей стороны излишни. Я просто в ауте.
Это решается довольно простым путем. Заранее оговариваются ТЗ и условия приемки. Кроме того, поскольку действительно в ТЗ все не предусмотришь, заранее можно договориться о том, что заказчик получает N часов возни с его проблемами. Все, что сверх того оплачивается либо по почасовой системе, либо составляется новый ТЗ на изменения, и они проводятся, как отдельный проект с фиксированной оплатой.
P.S. Мне приходилось иметь дело с иностранным заказчиком, который пытался повесить на меня то, что поверх моей библиотеки евонные криворукие мальчики не могли запустить свою софтину. Причем ежу было понятно, что проблема на их стороне (библиотека обеспечивала транспорт данных, а у них была проблема с тем, что с этими данными происходит уже потом, после того, как они доехали). Я им некоторое время помогал, но стало очевидно, что если продолжать так дальше, я им забесплатно сделаю весь проект. Помогло только послать заказчика на ..й со словами, что если не хочет, пусть не пользуется, я без него найду, кому эту софтину продать. Минут через 5 позвонил начальник заказчика, и мы обо всем договорились.
Однако российский заказчик в этом плане хуже — он в итоге и не заплатит, и использовать будет.
Здравствуйте, Pzz, Вы писали:
Pzz>Это решается довольно простым путем.
Думаю, что не просто.
Даже на RAC,
где существует арбитраж.
Никогда не были в арбитраже?
Это у них длится месяцами
Кроме того,
покупатели все под никами.
И открыть новый счёт для покупателя —
очень просто.
А, платёж сделать через кого-то другого
или анонимно.
Как правило,
ТЗ там такие,
что их нужно дорабатывать уже в процессе работы.
Соответственно, рассчитывать
на продление срока.
Если покупатель не продлевает срок,
или ты договариваешься о 5 днях,
а он тебе фактически даёт 1 день,
или канцелирует его в середине проекта,
то кодер ничего в этом случае сделать уже не может.
По всем правилам,
если результат не передан до дедлайна,
то по правилам Покупатель имеет право вернуть себе платеж.
У Покупателя все нити в руках избежать платежа в рамках всех правил
(недоспецифицировать, не продлить, продлить, но на недостаточный срок).
Если Покупатель недобросовестный,
то от кидалово никак не увернуться.
Надежда только на добросовестность Покупателя.
Что тоже неочевидно — фрилансеров ищут далеко
не от доброты, душевной щедрости или большого ума с интеллектом.
Что я делаю?
Я изучаю проекты
и заявляюсь только по проектам,
технологии которых часто повторяются.
Есть и задачи очень похожие
Т.е., если мне не заплатили,
то я знаю,
что я заготовки и опыт всё равно смогу ещё использовать,
если не продать готовые
Здравствуйте, Она На Нас Ий, Вы писали:
ОНН>Здравствуйте, Pzz, Вы писали:
Pzz>>Это решается довольно простым путем.
ОНН>Думаю, что не просто.
Тут есть 2 простых вопроса:
1. Нужно ли заказчику то, что вы для него понаделали
2. Может ли он это использовать, не оплатив
2-й вопрос очень важный. Если может (как, например, в России), то особо давить нечем. Надо либо работать только с теми, кому доверяешь, либо не давать исходников до хотя бы частичной оплаты.
Здравствуйте, Pzz, Вы писали:
Pzz>2. Может ли он это использовать, не оплатив Pzz>2-й вопрос очень важный. Если может (как, например, в России), то особо давить нечем. Надо либо работать только с теми, кому доверяешь, либо не давать исходников до хотя бы частичной оплаты.
Плюс внедрять в свои проги блокировку по дате (демо-версия) и обфускатор сверху вешать. Это если без посредника.
Здравствуйте, Дм.Григорьев, Вы писали:
Pzz>>2. Может ли он это использовать, не оплатив Pzz>>2-й вопрос очень важный. Если может (как, например, в России), то особо давить нечем. Надо либо работать только с теми, кому доверяешь, либо не давать исходников до хотя бы частичной оплаты.
ДГ>Плюс внедрять в свои проги блокировку по дате (демо-версия) и обфускатор сверху вешать. Это если без посредника.
Только полный урод будет довольствоваться софтом без исходников и без серьезной компании, которая готова его поддерживать. А против полных уродов ничем не защитишься, в т.ч. и блокировками. На то они и полные уроды...
Вопрос тут не о том, удовлетворяет ли это его потребности, а в том, _о чем вы договаривались_. Если договоренное выполнено — а это то, что в ТЗ — деньги на бочку. О доделке "как в Аутлуке" можно разговаривать отдельно.
Здравствуйте, Pzz, Вы писали:
ДГ>>Плюс внедрять в свои проги блокировку по дате (демо-версия) и обфускатор сверху вешать. Это если без посредника.
Pzz>Только полный урод будет довольствоваться софтом без исходников и без серьезной компании, которая готова его поддерживать.
Ну, во фрилансе просто масштабы не те. Там о серьёзных компаниях речи не идёт. Как правило.
Pzz>А против полных уродов ничем не защитишься, в т.ч. и блокировками. На то они и полные уроды...
Зато есть фактор жадности. При выборе между "заплатить 80% и получить шиш в масле" и "заплатить-таки 100% и получить заказанное" выбирают обычно второе. Хотя лично у меня гораздо чаще получалось прямо наоборот: честно оплачивают и проваливаются сквозь землю. За последнюю пару лет в портфолио не добавилось ни одной серьёзной ссылки, на выброс работаю.
Здравствуйте, Дм.Григорьев, Вы писали:
Pzz>>Только полный урод будет довольствоваться софтом без исходников и без серьезной компании, которая готова его поддерживать.
ДГ>Ну, во фрилансе просто масштабы не те. Там о серьёзных компаниях речи не идёт. Как правило.
Да, поэтому у фрилансеров покупают с исходниками, а у мелкософта можно и бинариями взять. Потому что мелкософт вряд ли завтра изчеснет, в отличии от.
?
