伯度空间

Clarity是一个貌似好帮到手的工具，你在上面break好task，填好planned schedule，然后只要每日‘按实际花在每个task的effort去填’，这样就能知道每个task乃至整个project的actual effort与进度

但同时Clarity又是一个用来同user收钱的工具。不明白者可能会问，为什么就不能按actual effort去收钱？但只要深入想一想软件项目的过程就知道，这不可能。

做一个项目之前要估数，估下整个项目要用多少钱，然后user agree了那个数字，接下来就是在项目完结前每个月去收一定的数，总之到最后那个总数要跟当初的总价接近。

在实际项目开发过程中，到某一个月去收钱的时候，有可能出现了3种情况：

1. actual跟plan很接近。这实在是太完美了，夫复何求，即使按实际去填也没关系，安心睡大觉去了。

 

2. actual大于plan。这可难为了PM，按实际的填会导致项目超资，这不是找死吗？这时一定会痛恨自己当初为什么不报点。但米已成炊，还是按原来的plan去填吧，胸弟们的辛劳白干了

 

3. actual小于plan。这……这也算是个问题吗？实际结果比预计的好，这不是最好的结果吗？如果做项目只是一个单纯的工作，那的确是。可现在商业活动，要用最少的effort赚最大的钱！你填的数少了，user会感谢你，会高兴，但同时会让你老板不高兴。明明可以不劳而获，你居然让煮熟的鸽子飞走了？所以方案只有一个，填假数赚钱。

 

以上的假设是项目的level上看的，但实际每个项目都会被break成独立的task，然后为每个task估算一个价格，然后要记下每个task的actual effort。具体到task level，每个task都可能出现以上三种情况。但是面对task level的情况，却应该有不同的做法。

 

是什么原因导致project level和task level遇到同样情况时有不同的做法？一个最重要的原因就是，你跟user收钱是按project去收钱，不是按task收的，user根本不关心你把一个project割成多少个task，怎么做每个task，他只在乎你做了整个project的多少就收多少钱。所以面对task level的情况我们有了更大的自由： 每个task不必担心varience，只要project level的总数looks fine就行了。

但人类是一种非常复杂的动物，越是有自由，选择就越多，反而变得不知所措。那到底每个task的effort该怎么填？按actual？按plan？按actual的话还要担心总数的问题，这个task做多了，只能从其他task拿数，烦啊

于是就诞生了一种最简单的方法，按plan，task level按plan，project level自然是跟plan一样。首先是每周把所有数都填到unbillable，到了月底就按原来的plan把clarity adjust一下吧。

无论用什么方法，在Clarity上填的数是本身就是个充满虚假信息的数字，但还要反应到PSR上，结果老板看的这堆数字也不过是人类的加工结果。