前任和依赖关系的工作方式不应该不同吗?

BSADK

这不仅适用于Smartsheet，也适用于我见过的所有项目规划软件。依赖项有四种类型，它们是这样工作的:

完成到启动(FS):“正常”类型的依赖项。这将开始日期设置为前一个结束日期的第二天。您可以调整持续时间或结束日期，但不能调整开始日期。如果编辑start，它将删除前导。如果您编辑完成，它会自动调整持续时间。如果您编辑持续时间，它会自动调整完成。[定义:“前任完成后开始”]

从完成到完成(FF):这允许并行工作，但你在同一日期完成。这将完成日期设置为等于前任的完成日期。您可以调整持续时间，但不能调整开始或结束日期。如果您编辑开始，它将删除前导，根本不允许编辑完成。如果编辑持续时间，则会调整开始日期。[定义:“在前任完成的同时完成”]

从开始到结束(SF):这就像一个反向依赖。这将结束日期设置为前一个开始日期的前一天。您可以调整持续时间，但不能调整开始或结束日期。如果编辑“开始”，它将删除前一个，根本不允许编辑“完成”。如果编辑持续时间，则会调整开始日期。[定义:“在前任开始之前完成”]

从开始到开始(SS):这允许并行工作，但你在相同的日期开始。这将开始日期设置为等于前身的开始日期。您可以调整持续时间或结束日期，但不能调整开始日期。如果编辑start，它将删除前导。如果您编辑完成，它会自动调整持续时间。如果您编辑持续时间，它会自动调整完成。[定义:“与前任同时开始”]

以上描述是我对发生的事情的描述，但定义和Smartsheet文档/措辞来自这里:https://help.smartsheet.com/articles/765727-enabling-dependencies-using-predecessors

我可以看到，对于一个程序员来说，这使得程序很容易设置。你让一种东西严格等于另一种东西，然后让任何东西调整。对开始日期的任何更改都会删除前一个日期。对他们来说很方便。

但是对于用户/规划者来说，它不是那么方便——而且它不能反映项目工作的现实。特别是对于科幻小说来说，“前身”的定义并不符合英语中“前身”一词的含义——事实上，它恰恰相反。抛开词的语义不谈，真的有人觉得SF依赖有用吗?为什么不直接在另一行使用FS依赖呢?

使用延迟/前置时间会有所帮助，但效果有限。当你投入一个滞后/前置时间时，它是固定的。所以它和前驱体完全一样。前代移动3天，后代移动3天，以此类推。但是如果我有一个FS前任，并且我有3天的延迟-如果前任延迟1或2天，我实际上会保持相同的开始日期，而不是移动它。当我更新我的工作表时，现在我也必须去编辑所有相关的延迟时间。这很耗时。

现在，我意识到FS/FF/SF/SS依赖关系的实现现在基本上是一个标准，所以如果有一天Smartsheet只是因为一些随机用户(例如我)的请求而改变它们的意思，它可能会让很多用户感到困惑，更不用说让当前用户感到不安，他们的表单可能会突然改变行为，完全破坏他们的表单。我的建议将是一个更灵活的版本，所以为了清楚起见，我将在它们前面加上一个“F”，表示灵活。将这些实现为新的可用的前身函数(可能通过选择“刚性”与“灵活”模式)，而不是替换现有的，这样可以保持向后兼容性。

以下是我的建议:

灵活的从结束到开始(FFS):这将设置开始日期的最早可能日期，等于前一个结束日期的第二天。默认情况下，它会将其设置为前一个结束日期的第二天，但是如果需要，您可以将开始日期调整为更晚的日期，但不能将其设置为更早的日期。如果您调整开始或持续时间，则会自动计算结束时间。如果您调整完成，持续时间将自动计算。如果尝试将开始日期调整为早于前任的完成日期，则会拒绝更改。[定义:“前任完成后开始”]

灵活的从完成到完成(FFF):这将设置完成日期的最早可能日期，与前一个完成日期相等。默认情况下，它会将其设置为前任的完成日期，但是如果需要，您可以将完成日期调整为更晚的日期，但不能将其调整为更早的日期。如果您调整开始，持续时间将自动计算。如果您调整结束，持续时间将自动计算。如果您调整持续时间，将自动计算开始时间。[定义:“与前一个项目同时完成或晚于前一个项目完成”]

灵活的从开始到结束(FSF):这将为结束日期设置最早的可能日期，该日期等于前一个开始日期的第二天。默认情况下，它会将其设置为前一个开始日期的第二天，但是如果需要，您可以将结束日期调整为更晚的日期，但不能将其调整为更早的日期。如果您调整开始，持续时间将自动计算。如果您调整结束，持续时间将自动计算。如果您调整持续时间，将自动计算开始时间。如果尝试将完成日期调整为早于前任的开始日期，则会拒绝更改。[定义:“前任开始后完成”]

灵活的从开始到开始(FSS):这将为开始日期设置尽可能早的日期，与前一个开始日期相等。默认情况下，它会将其设置为前身的开始日期，但是如果需要，您可以将开始日期调整为更晚的日期，但不能将其调整为更早的日期。如果您调整开始或持续时间，则会自动计算完成日期。如果您调整结束，持续时间将自动计算。如果尝试将开始日期调整为早于前任的开始日期，则会拒绝更改。[定义:“与前任同时或晚于前任开始”]

请注意我的建议:

1.FFS, FFF和FSS的前身将非常类似于现有的FS, FF和SS的前身-只是有一定的日期约束的前身，而不是完全固定。这允许更多的灵活性。事实上，FFS实际上比当前的行为更符合现有的定义，因此我没有改变其定义的措辞。

2.由于我上面描述的原因，FSF的前身将与SF的前身完全不同。这个定义使它成为一个真正的前身，并且可能对规划更有用。

3.不需要“滞后”时间条目。“延迟时间”将由用户输入的依赖项的实际开始或结束日期暗示。这实际上会使条目更简单，不那么复杂，因为不需要数字修饰符。

4.乍一看，根据我的定义，“提前”时间似乎是不可能的。对我来说，如果有“前置”时间，那么它就不是真正的前身。但是，如果它是前身，则可以更改类型以创建与交付时间相同的效果。代替带有前置时间的FFS前身，您可以使用带有隐含滞后时间的FFF、FSF或FSS。特别是，使用FSF或FFF，您可以根据需要将开始日期向后设置，而不受限制。或者你可以做FSS，只受前作开头的限制，而不受结尾的限制。

5.在所有情况下，如果前导更改，它可能会或可能不会根据以下内容更改依赖行:

a.如果前任中的关键日期(FFS和FFF的结束日期，或FSF和FSS的开始日期)被更改，使其违反上述规则，则从属行将自动更改为符合规则的下一个最接近的日期-然后它遵循上述更改规则。

b.如果密钥日期的更改没有违反上述适当规则，则从属关系中没有任何更改。

对我来说，这些不仅更符合逻辑，创造了真正的“前身”定义，而且更适合现实世界的场景。

BSADK

对不起，我太啰嗦了，所以我不能把所有的东西都放在原来的帖子里。我把它写得类似于软件需求说明书，以便更加具体和清晰。我还想添加以下现实世界场景，但没有足够的空间:

下面是一个常见的现实世界的例子，我认为这将是非常有用的(发生在我身上，无论如何):

在原型构建完成之前，测试不能开始。可用的第一天(由于在您的项目中没有特别跟踪的所有项目中可用的测试中心资源)是在最初计划的欧宝体育app官方888构建结束后5天。在当前的系统中，您将设置一个具有5天延迟的FS前身。在我的建议中，你会设置一个FS前任，然后直接在表格中设置5天后的受抚养人的开始日期。

现在让我们假设某些东西将构建延迟了2天。在当前系统中，当您更新构建计划时，测试也将移出2天。但这并不能反映现实——你仍然可以在原计划的那天开始测试，它不必改变。现在你必须将所有延迟时间从5天改为3天。不需要的额外工作。如果你忘记做，那会造成混乱，因为每个人看时间表可能没有意识到考试日期实际上并没有改变。在建议的系统中，测试日期不会改变，它保持在原来的位置，因为日期仍然比前一个日期晚。

如果构建被延迟了10天，那么当前系统将自动将计划的测试推到整整10天之外。拟议中的系统只会将测试推迟5天。假设资源可用，这是欧宝体育app官方888可取的。如果它们不可用，那么你必须在两种情况下验证可用资源并手动更新……欧宝体育app官方888在不检查的情况下，你也不知道10天内它们是否可用，所以这两种情况都需要干预。

总的来说，灵活的方法将节省更多的时间计划，需要更少的人工调整时间表。

想法吗?我当然希望看到其他人支持这个想法，但我也特别有兴趣听到现有功能更好/更理想的例子，因为我自己真的想不出任何例子。

一个伊丽莎白

假期是另一个例子，你可以在其中添加延迟，但如果计划推迟，那么假期(和延迟)可能就不相关了。或者，您可以将假期作为任务，添加依赖项，然后监视需要对这些依赖项进行更改的计划更改。

有没有变通的办法?确定。它们中的大多数需要更多的人工维护和大幅如果你没有抓住变化或调整你的滞后/领先/依赖，就会增加人为错误。这是我试图用SmartSheet这样的工具来消除的手工修补，这真的很令人沮丧。