ASK MO第37期 | 末位淘汰制下，如何保持与队友的无间隙配合？

所以，我们在系统的整体架构方面，我们需要有一位架构师去规划能支撑起未来业务发展的系统架构，一般系统架构都是基于业务场景来规划的。比如与产品方面进行沟通，看看现在的业务量是多少。然后做一个估算：

未来业务会发展到什么样的程度？

我们的用户数量会达到现有的几倍？

关键服务目前能满足多少用户同时访问？

两年之后多少用户同时访问系统还能支撑得住？

根据这些数据来设计我们整体的架构，也就是说架构至少能支撑未来两年。在这个架构前提下我们再来去设计我们的产品。

并且每半年我们要思考一个问题，基于我们的业务的发展情况，我们目前的架构是否还能支撑未来两年的发展？如果不行，那我们就要提前开始做一些重构工作。把这个事情提个日程，并告知产品，在每一个迭代当中我们要加入5%到15%的重构功能。

所以这个是个平衡的艺术，既要考虑现有的业务，又要有超前的架构设计。这个责任是要落到系统架构师这边，最好是CTO能够知道并且了解这个事情的重要性，支持并主持系统重构。

“傻”的状态就是自己的代入感太强了，觉得公司就是自己的公司，自己就是这个公司的老板，把员工的离职看成对公司的背叛，对自己的背叛。员工每次的离职都是对自己的伤害，我觉得自己又没有做错什么，哪点对不起你了，你为了那点工资就跳槽到其他公司去，至于吗？我们不是要一起奋斗，一起发展的吗？

后来经过的事情多了之后，包括自己也离职过后，慢慢对这个事情，其实就看开了。其实员工离职，如果有好的地方去，真的不需要挽留。

1、不要把工作看成人生的全部，其实生命当中还有很多美好的事情等着我们去发现，去追求。友情、亲情、爱情，这些比工作本身更有意义，人生苦短，我们要追求的，并不是能挣多少钱，有什么样的体面工作，获得其他人的认同，而是自己的人生是否活出精彩，活得有意义。自己要去追求的同时，不要让别人放弃追求的权利。

2、离开的同事，特别是去更好公司的同事，和他们保持联系，他们有更多的资源，说不定什么时候就会用得上。这对现在处于创业期的莫老师而言特别重要，因为谁也说不准你哪天可能自己创业。这个时候你的社会资源就会变得相当有价值了。站在资源交换的角度上来说，请善待每一位离职的同事。

举个例子，莫老师有一位下属离职，我领导叫我留他，我压根没有留，因为我知道他去了更好的平台，工资也比现在高很多，推心置腹地和他聊起了天，以自己在大公司的经历，告诉他今后在大公司的发展方向。到现在我还和他联系，当我想了解他们公司情况的时候，他也把他能知道的情况都一一告诉我，这就是很好的资源互换。对于我现在创业是非常有帮助的。

跨团队的项目，如果需要进行需求模块估算，那么唯一能解决的问题还是要选择共同的基准点，以求对每个故事都能有统一的故事点估算。这个的确是比单团队估算来得复杂。但是这个是不能避开的一个问题。需要各敏捷团队的SM一起讨论，如何定出来这个基准。

比如对单个表的增删改查设为一个故事点，大家达成一致之后，可以看这样一个需求，有对多少张表进行过这样的操作，在历史工作量的时候，是一个什么情况，就可以大概定出一些功能的故事点来了。

ROI就是投入产出比，这个通常用钱来量化比较具体，通常我们做一个需求，要投入多少人天的工作量，而我们公司的平均1人天值多少钱，那么这个需求我们可以评估一下，他可以为公司创造多少收入。或引来多少新的客户（客户获取成本可以算出来），或提高效率之后，为公司节省多少人力成本（这个成本也可以按人天计算）。

还有一些无法计算的，比如这个需求可以减少客诉，提升用户体验的。可以计算的我们称之为直接收益，无法计算的我们称之为间接收益，通常在敏捷团队当中，我们优先完成直接收益的需求，再完成间接收益的需求，直接收益里的需求优先级排序就看收益有多少。

最后需求上线之后，PO通过数据分析，分析出本次上线后的收益是否和预估的一致，帮助团队在一次次的迭代当中关注价值，敏捷就是价值驱动的。

老铁，没毛病。