Цитата:
[02.09, 16:56:05] НИ: Фуф добрался я до офиса. Убедил ты меня. действительно, чего это я без разборов выдвигаю претензий и ничего не хочу объяснять, просто прошу подождать. еще программиста за отдельный счет нанимаю, которого мне никто не компенсирует. так можно и разорится. Давай все делаем по честному. Устраиваем полную разборку задачи. просьба пришли весь расклад, на который ты рассчитываешь, с росписью - состав работ - часы. я сравню с нашими предыдущими согласованиями и с часами программиста. то что ты сделал без переделок - я приму и назову срок оплаты, то что доделывает программист я вычту поясню тебе в какие трудозатраты мне стало исправление и объясню исправление чего. так и закроем этот вопрос окончательно.
[02.09, 17:00:16] Я: На мой взгляд в этом нет ничего «честного»! Что-то делать можно много и долго: сначала одно, потом другое, потом заново. Если вычитать из первоначальных часов время, которое потратит ещё какой-то программист на какие-то доп требования - так и в минус можно уйти! Ты можешь сейчас сказать какой % ТЗ выполнен?
Различные ожидания у сторон. Обычно эти ожидания регулируются business/contract terms, то есть формулировками контракта/договора. Как это было оформлено и как звучало?
Понятно что даже при Time & Materials, когда не прописаны детально Test scripts как критерий качества, всегда можно ссылаться на неудовлетворительное качество. Но все же. Есть common sense и reasonable quality. То есть здравый смысл достаточности и разумное количество багов.
Поэтому хочется понять ожидания и одной и второй стороны.
У меня тоже пограничная ситуация. Количество "багов" мне возвращаемых сигнализирует о том что качество очень плохое, но если рассматривать это как Agile tickets то все не так и безумно.
Все упирается в совмещении ожиданий что за "проектная методология" таки используется.