随着互联网的普及，在国家“十四五”规划中提出“加快数字化发展建设数字中国”的战略远景，数字化成为企业发展的必经之路，数字化建设的落地一定是由技术团队来实现的。
现阶段的软件开发已经跟十几年前不一样了，我记得大学刚毕业那几年，一个人可以干完整个系统，现在软件开发过程中的职责细分、前后端开发分离等等，都明确表示软件开发是一个多角色、多岗位的流程性活动，要确保软件开发顺利进行，并且按时按质按量交付，那么完整的管理理念是必不可少的。
我们找CTO团队在过去20多年的研发管理工作经验中，提炼了一整套的研发管理方法论，可以用来指导研发团队的整体管理工作，我将会在随后的文章中跟大家详细探讨我们的经验和心得。
任务拆解
这一篇跟大家探讨的是任务拆解，软件开发是一个非常复杂的系统工程，参与的人员动辄几十人上百人，大家熟悉的Windows、Office等软件系统，都是成千上万人参与的。虽然我们日常见到的软件系统没有Windows这样复杂，但麻雀虽小五脏俱全，所有的软件开发都有差不多相同的流程和阶段。面对这么复杂的工程，只有能理解并将系统拆解开，才能按照计划进行推进。我们上学时都学过一篇课文叫《庖丁解牛》，面对一头牛，如何拆解呢？普通人估计真的无法下刀，而对于庖丁来说，就是非常简单容易的事情，原因就是他非常理解牛的身体构造，也知道应该怎样的顺序进行拆解，甚至能在下刀之前就告诉你，第36刀下去能帮你把后腿肉拆解下来。面对复杂的软件工程，我们如果也能像庖丁对牛那样熟悉，那何来延期无法交付之说呢。
如上图所示，我从三个维度来跟大家探讨一下关于拆解的逻辑。
架构设计的演进和规则
首先我们来看一下软件的架构设计，最早的软件都是单体架构，业务逻辑都写在一起，部署也是在一台服务器上。
随着互联网的发展，一台服务器的性能无法支撑业务的访问，这时候软件架构慢慢变成了分布式应用。分布式应用将相同的业务逻辑部署在多台服务器上，或者将系统划分为多个业务模块，业务模块分别部署在不同的服务器上，如下图所示。
再继续发展，业务也越来越复杂，各个拆分的业务中都会有很多相同的模块，例如都有用户体系、都需要通知体系，而这些可能相对独立的功能在不同业务模块都需要使用，在服务治理的需求下慢慢产生了微服务的架构。还记得当年加入阿里巴巴的时候正赶上服务治理的时期，有幸也参与见证了微服务框架Dubbo的早期设计。
对于微服务来说，也有它的一定规则和要求，不是拆的越细越多越好，简单来说就是每一个微服务都应该是解决一个领域的问题，建议采用单一职责的设计原则，相对独立的功能模块设计为一个微服务。相对应用内交互来说，微服务的调用成本、后期维护成本都是呈几何级数上升的，特别是多个微服务之间的相互调用，更会加大系统的复杂性。
举个我曾经参与过的案例，那个项目相对比较大，整体系统由多个ISV来承接的，各个ISV都有架构师参与，大家对整体系统进行拆分后，采用微服务的架构，总共设计了27个微服务。项目经理在对整体做规划的时候发现项目复杂度太高，而且每个微服务之间也有不少耦合的地方。我到项目组后跟几个架构师进行整体Review后，根据设计原则对已有的微服务进行分拆合并，最终仅留了11个微服务，多方多次Review之后，都一致认为拆分为11个微服务更合理，减少了过渡设计带来的复杂度和繁琐，整体系统架构清爽简洁。
项目拆解
之前的文章我们探讨过迭代开发方式，这里就不详细展开讲，强调两个关键点：
1、项目拆解的原则也是每个迭代都是一个完整的研发周期，必须能独立设计、独立开发、独立测试、独立部署交付的内容，不能因为后续还有没做的内容，导致本次迭代无法交付；
2、项目拆解后的每个迭代，建议2-4周之内能完成，太短了节奏太快团队会没有喘息时间，太长了无法享受小步快跑带来的喜悦。
个人任务拆解
软件项目的开发最终都是由参与的每个人都完成自己的任务，才能完成整体项目的交付，只要有一个人承担的模块没完成，那么整体项目就不可能交付，因此从管理的角度出发，必须让每个人都按计划按质量要求完成任务。
关于项目模块的开发时间估算，这是个经典的业界难题，任何系统工具都无法帮团队解决这个问题，只能根据开发人员和管理者共同协商得到一个估算时间，根据这些估算时间再跟业务人员、老板进行沟通协商，最终得到一个项目交付时间，只要能在这个大家认可的时间节点，交付符合质量的软件产品，那么技术团队基本就能做到符合预期的状态，后续如何做得更优秀，我们以后再探讨。
那么对于每一个开发人员，得到一个大家认可的估算时间后，是不是就可以放手让大家去干就好了呢？从管理的角度出发，这样放羊的方式，最终一定是要出问题的，没有过程管理很难得到理想的结果。
假如说张三评估了这个模块5天能干完，那我们的规则就是要求张三将5天的工作量拆分成每天干什么，至少拆分成5个子任务，因为就算不拆分，他也是每天每天去干活，没有规划脚踩西瓜皮的方式，是无法按规划得到结果的。
这时候可能会有两种情况，一种是张三能按要求拆出来，每天的任务从逻辑上判断是合理的，大小粗细也差不太多，那么从逻辑上来说，张三5天能完成任务是相对靠谱的，只需要张三每天按规划完成任务，最终第5天就能得到整体任务的交付。
另一种情况是评估时间是大家一起评的，张三说我拆不出来5个子任务，原因很简单，就是对任务里面的一些细节没有经验，这时候团队中更有经验的同学来协助任务拆解，也拆成了5个子任务，每天一个，张三也认为相对合理，对于任务123能有把握当天做完，但对于任务45不确定，这也是他无法拆解任务的原因。这时候我们就会要求张三，在没有前置条件限制的时候，将任务45提前做，而不是放到最后来做。试想一下，如果团队20人参与项目，整体项目开发周期就是周一到周五，张三在周五快下班了告知任务干不完了，是不是所有人都得陪着协助干完了张三的最后一个任务，才能做整体交付，而如果张三将可能有风险的任务提前到周二、周三来干，周三就知道可能干不完，这时候管理者有很多种办法进行协调和处理，可以确保团队整体的任务在周五及时完成并交付。
可以再举个生活中的例子，假如说我们要安排下周一到周日去北京旅游，我们可以很清楚地规划周一早上高铁去、周日下午飞机回，周三去颐和园、周四去八达岭长城等等，每一天干什么都可以规划的清清楚楚，只要没什么意外情况，整体的旅游我们可以完全掌控，心里也会很踏实。换个目的地，如果让你规划一周去南极旅行一趟，估计你就很难将每天干什么安排好，是不是心里就感觉非常不踏实，但这时候有个专门做南极旅行的导游，帮你拆分好每天在哪里做什么，是不是就完全不一样了呢。
关于个人任务拆解，我们会形成一个规范，所有任务都必须拆解到每天做什么，每个子任务最多不能超过2天（JONE系统中按8小时/天来计算），就是单个执行的任务工时不能超过16小时，每天按照规划去完成自己承诺的任务，每个人的任务列表中都清晰地展示着自己的任务，在这种情况下，所有人都是有序地干活，每天交付自己承诺的工作内容，团队也就能交付整体项目的规划内容。你想，任务分配到每个人头上，每个人又能按规划每天完成任务，项目进度就完全可控了。
JONE系统中会根据规范每天将需要完成的任务在工作台展现出来，团队所有人都可以看到，每个人只要完成跟自己相关的任务就可以，任何没有完成的任务都会有相关的提醒。完全体现我们的管理原则：任何问题风险，必须在第一时间暴露出来，越早补救成本越低，越往后成本风险越高。
