工作下的规则 - 页 5

新评论
 
Yedelkin:
这里有一个不同的方法来解决最后的问题 :)
没有集市。)))
 
pronych:

源头可以是一个精心设计的模板，有很多额外的功能和类，等等。它可能由一堆块组成（例如inludes），其中只有一些条件可能会有变化。你准备好在一个系统（系统，在相互作用的意义上）的十几个不同文件的源代码中付出六个月的工作（在一个简单的例子中），其中只有信号模块（一个类（文件））不同？

我明白，我们可以用标准的工具来崩溃口罩，这并不可惜。但是，如果在模板上投入巨大的努力，我们如何才能做到这一点？不，你准备好了吗？

事实证明，在这种情况下，最好将模板作为一个编译文件，而信号模块--由客户决定。这样的选择（已经被提及）是否对每个人都有效？

...但在这种情况下，"新建 "的风险被转移给了客户，而消除这种风险的保证则留给了承包商的良知。

 
Yedelkin:

这里有一个基本错误。合同是两个或更多人之间的协议。申请书只是一方的建议，其本身不能被视为合同。根据所讨论的规则的实质，只有在制定了职权范围之后才能判断合同关系的形成（缔结合同）。职权范围旨在反映双方 商定的所有工作细节。


我没有主张在我们的案例中，申请书是一份合同，我只是表示希望它应该接近于合同（也就是说，在我看来，申请书应该包含一些强制性的字段/打钩），而且职权范围应该更详细地披露工作的具体内容，并定义承包商必须遵守的某些要点。

也就是说，我确信至少有60%的非程序员交易者会忽略一半的ToR。

 
Interesting:

我没有争辩说，在我们的案例中，申请是一个合同......。

有趣的 是。

......我认为在正常情况下，合同（读作申请）......。

像往常一样，我是对所强调的 内容进行评论 :)
 
Interesting:

也就是说，我确信至少有60%的非程序员交易者会忽略一半的ToR。

这就是为什么我主张并将继续主张，在起草ToR时（根据具体规则），承包商应感到自由，主动协调工作细节并在文件中反映出来。是承包商要处理客户的投诉。草拟的职责范围如果是承包人的过错 ，只会引起不必要的争端。
 
Yedelkin:
事实证明，在这种情况下，最好将模板作为一个编译文件，而信号模块由客户自行决定。这个方案（已经提到）对每个人都有效吗？
不完全是，对每个人来说。））然而，当然，这也是一种选择......对我来说，有一个现成的文件会更方便。这使任务复杂化（读作--'成本'）但谈话甚至不是关于它的。 这样的方法分裂了思想，客户不是这些东西的主人（或主人！他们可能是不同的），虽然不是一个傻瓜）)我认为勾选 "我想要消息来源 "就足够了，在商定职权范围之前，它只是解决了大部分问题。如果对这个问题能够理解，那么我们就可以继续讨论这个问题。
 
pronych:
并非如此，对所有的人都是如此。））然而，这当然是一种选择......对我来说，准备好一个文件更方便。这使任务复杂化（读作--'成本'）但谈话甚至不是关于它的。 这样的方法分裂了想法，而客户在这种事情上并不敏锐（或敏锐！他们可能不同），虽然不是傻瓜）)我认为勾选 "我想要消息来源 "就足够了，在商定职权范围之前，它只是解决了大部分问题。如果对这个问题能够理解，那么我们就可以继续讨论这个问题。

然后呢？解决你的问题的一个可行的方案是这样的。

1.在正式方面，规则中的一个新条款。

2.在技术方面--在应用程序的表格中引入 "需要源代码 "选项，默认为 "不需要"？

 
Yedelkin:
这就是为什么我主张并将继续主张，在起草ToR时（根据具体规则），承包商必须感到自由，以协调工作的细节并在文件中反映出来。是承包商要处理客户的投诉。由于承包商的 要求规范的过错 而笨拙地起草，只会促成不必要的争端。

是的。这很有可能。因此，让我们马上想一想（悄悄地，在开发人员睡着的时候）），我们想在 "工作 "部分要求什么样的补充？但我先来!

检查盒子!'消息来源'。

:))

 
Yedelkin:

然后呢？解决你的问题的一个可行的方案是这样的。

1.在正式方面，规则中的一个新条款。

2.在技术方面，在申请表中，将 "需要源代码 "选项改为默认的 "不需要"？

正确的
 

在我看来，还有另一种可供选择的方式--在承包商和客户之间有一个调解员-仲裁员（在我们的案例中是MQ），承包商将整套材料+来源交给调解员（他根据TOR检查），之后客户会收到调解员的通知，说工作已经完成，必须支付费用。

根据工作的排他性和付款后的初步安排，客户会收到最大限度的开放源代码或只是编译后的文件。

在这种情况下，正如你所理解的那样，中间人会收到一定的报酬。

PS

虽然在我看来，MQ并不十分喜欢它......

123456789101112...20
新评论