大家下午好。我有一个关于这个主题的问题。经常出现的情况是，工作接下后，您开始工作，但后来发现，要么客户提供的作为开仓信号源的指标不正确，需要改进，要么客户在通过职权范围审批阶段后的愿望增加了，导致工作成本增加。客户对此表示同意，并准备支付额外费用，但项目 的价格是固定的，据我所知，即使双方同意也不能更改。因此，额外的付款要么要经过现场，要么要做其他工作，这并不总是很方便。问题如下--签订 TOR 后，是否仍然无法更改工程造价。在现实生活中，一切都很简单--签发一份合同附录，在附录中规定对 TOR 和合同价格的修改--双方盖上棉花章并签字，然后就可以了。但在这里，我没有找到类似的东西。也许是我找得不够仔细？)))
vadimpl: 大家下午好。我有一个关于这个主题的问题。经常出现的情况是，工作接下后，您开始工作，但后来发现，要么客户提供的作为开仓信号源的指标不正确，需要改进，要么客户在通过职权范围审批阶段后的愿望增加了，导致工作成本增加。客户对此表示同意，并准备支付额外费用，但项目的价格是固定的，据我所知，即使双方同意也不能更改。因此，额外的付款要么要经过现场，要么要做其他工作，这并不总是很方便。问题如下--签订 TOR 后，是否仍然无法更改工程造价。在现实生活中，一切都很简单--签发一份合同附录，在附录中规定对 TOR 和合同价格的修改--双方盖上棉花章并签字，然后就可以了。但在这里，我没有找到类似的东西。也许是我找得不够仔细？)))
事实上，我们所有人（管理部门、开发人员和客户）都处于服务的不同方面。每个人都会看到自己的细微差别和困难。您提到的对话框我刚刚看到了，它在为客户提供所有必要信息方面迈出了重要的一步。我列出了 99% 的客户在第一次使用服务时会问的问题。而每位客户都必须以令人羡慕的一致性和坚持不懈的精神提供分步指南和账户计算部分的链接。这种情况表明，关键问题--"分步指南 "和 "计算"--的信息量明显不足。
您好，我是 mt5.com 的新用户。我从工作部分订购了一个 EA，在一步步完成工作的过程中，我在"需求协商"步骤中遇到了困难。我和开发人员都确认了该步骤，但我无法进入下一步 "原型/模型"。需求谈判 "一栏仍然是绿色的，我无法进入下一步。有经验的人请帮帮我......
我也遇到了同样的问题，请看附图
您知道发生了什么情况吗，我们该如何解决这种情况？
大家下午好。我有一个关于这个主题的问题。经常出现的情况是，工作接下后，您开始工作，但后来发现，要么客户提供的作为开仓信号源的指标不正确，需要改进，要么客户在通过职权范围审批阶段后的愿望增加了，导致工作成本增加。客户对此表示同意，并准备支付额外费用，但项目的价格是固定的，据我所知，即使双方同意也不能更改。因此，额外的付款要么要经过现场，要么要做其他工作，这并不总是很方便。问题如下--签订 TOR 后，是否仍然无法更改工程造价。在现实生活中，一切都很简单--签发一份合同附录，在附录中规定对 TOR 和合同价格的修改--双方盖上棉花章并签字，然后就可以了。但在这里，我没有找到类似的东西。也许是我找得不够仔细？)))
到目前为止还没有这种可能性，但我们会考虑实施。
只有客户有足够的钱，我们才会向上考虑。
我们还没有这种可能性，但我们会考虑实现它。
只有在客户有足够资金的情况下，我们才会向上考虑。
我们还没有这种可能性，但我们会考虑实现它。
只有在客户有足够资金的情况下，我们才会向上考虑。
我们还没有这种可能性，但我们会考虑实现它。
只有在客户有足够资金的情况下，我们才会向上考虑。
当
1) 表演者有可能拒绝工作
2) 表演者有可能降低工作成本
3) 客户有可能增加工作成本
工作执行阶段 存在缺陷：
规则》第 3.2.7 条规定："在双方确认'批准 TOR'步骤后，订单金额将冻结在客户在支付系统中的账户上"。
原来，双方讨论职权范围，即承包商深入研究职权范围，花费时间，纠正客户的职权范围，实际上是咨询客户，结果客户有机会 "逃脱 "和/或选择另一个职权范围。因此，往往需要接受表面上研究过的职权范围，其后果是 "低估了工作的复杂性/成本/可实现性"。
批准职权范围 "应分两个阶段进行：
1.客户确认职权范围--金额被冻结。
2.2. 对职权范围进行讨论，在 "批准职权范围 "阶段确认之前，执行方应能够：拒绝 职权范围、更改费用。
或由承包商拒绝接受职权范围并更改费用，以便在 "原型/模拟 "阶段实现。
正确的情况是
1) 承包商有能力拒绝工作
2) 承包商有能力降低工作成本
3) 客户有能力增加工作成本
工程实施步骤存在缺陷：
规则》第 3.2.7 条 "在双方确认'批准职权范围'步骤后，订单金额将冻结在客户在支付系统中的账户上"。
原来，双方讨论职权范围，即承包商深入研究职权范围，花费时间，纠正客户的职权范围，实际上是咨询客户，结果客户有机会 "逃脱 "和 /或选择另一个职权范围 。因此，往往需要接受表面上研究过的职权范围，其后果是 "低估了工作的复杂性/成本/可实现性"。
批准职权范围 "应分两个阶段进行：
1.客户确认职权范围--金额被冻结。
2.2. 对职权范围进行讨论，在 "批准职权范围 "阶段确认之前，执行方应能够：拒绝 职权范围、更改费用。
或者由承包商拒绝 TOR 并改变费用，以便在 "原型/模拟 "阶段实现。
我确认，在这样的耙子上踩了好几次，嚼碎了客户自己的 TOR。你在上面花上 3-4 天时间。把它全部摊在货架上，然后他带着这个已经推出的 TOR 离开，并以更低的价格订购其执行。
做一个明智的 TOR 狮子份额的工作，这部分原来没有 保证付款的服务 "工作"!!!!。
这些都是作为承包商的风险。毕竟，当你选择冰箱时，你不会购买经理描述得非常好的冰箱。你记下了经理的故事，就可以去另一家商店买到更便宜的冰箱。而经理也不会因为他的质量故事而得到任何好处。但完全不讲是不可能的。经理明白这一点，所以每次都会冒险。
你和其他免费使用程序员熟练劳动力的辩护者一样，总是不断地混淆以下内容：
a) 销售已经生产出来的现成产品，其价格中已经包含了经理顾问的非生产性工作、店铺租金等形式的罚款、
b) 研究、开发和技术工作--在这种情况下，"审批 "阶段的目的是了解客户的需求，使客户最初模糊的任务正规化，等等。- 在这种情况下，专业人员的劳务费是值得的，当然也应该支付。
如果说在第一种情况下，经理顾问并没有创造新的价值--产品已经生产出来并准备销售，那么在第二种情况下，与客户讨论自己的职权范围的程序员则为客户创造了新的职权范围--这种劳动必须付费。
如果在你的情况下，经理肯定是有工资的，那么在第二种情况下，你认为程序员应该无偿工作的理由是什么？修订、解析 TOR 的成本并不低于编写程序的成本，而客户希望支付更少的费用，因此将程序员交给其他程序员是理所当然的。
在现实中，没有任何 KB 会在不保证付款的情况下分析问题。那么，为什么不支付（或不保证支付）分析/重审/编写 TOR 的费用应成为工作服务 的规范呢？
工作服务中的大多数仲裁情况是 "TOR 不明确"、"低估了工作的复杂性"。其原因是，在 "TOR 批准 "阶段，开发人员完全不受无良客户的保护。
papaklass：
如果你拒绝与客户一起研究 TOR，你肯定会失去他。而如果你能胜任地帮助客户起草 TOR，那么客户就很有可能把这项工作交给你，而且将来还会再找你。把它作为与人合作的成本。
不要再把程序员看作是无所事事、坐等客户和订单的失业人员。程序员有自己的主要工作，有自己的兴趣爱好和空闲时间。程序员不太可能乐意把自己的空闲时间花在只有几率发生的订单上。