重新理解软件研发

最近一直在和团队在做一款服务于软件研发的工具，得以有计划从理论上和实操上重新思考软件研发这件事。接下来想从软件研发本来的样子，怎样更好的开发一款软件两方面谈谈。

软件研发工作本来的样子

一个完整的软件研发流程大致包括市场调查、用户分析、产品定义、交互设计、UI设计、软件开发、测试这几个阶段。一个完整的软件开发团队通常包括项目经理、产品经理、交互设计师、UI设计师、前后端工程师、测试人员这些角色。产品经理会负责市场调查、用户分析、产品定义，交互设计师和UI设计师分别负责交互设计和UI设计，工程师负责软件开发，测试人员负责软件的测试，而项目经理则对项目的质量、成本、工期负责。当然有些成员会身兼数职，比如在敏捷研发中，产品经理通常也扮演了项目经理的角色，而交互设计的工作一般都由产品经理和UI设计师分摊。

在我看来，整个软件开发流程就像沙漏里的沙一样，先汇聚一点，再发散出去，最后落地。为什么这么说呢？首先说明汇聚的那一点代表什么，是产品需求文档。这文档算是软件开发流程中的集大成者。产品需求文档把软件开发流程切割成前后两个部分，前一部分的核心内容是研究怎么做，后一部分的核心内容就是做出来。具体来说，就是产品经理、交互设计师和UI设计师通过市场调查，用户研究，界面设计等工作，研究软件到底怎么做，输出调研报告、原型、设计图等各种文档成果，然后他们把成果汇集整理成一份产品需求文档；之后工程师和测试人员的工作就是根据产品需求文档的指导精神，输出代码、用例、缺陷等，就是在把软件给做出来。要指出的是产品需求文档只是一个信息传达介质，形式是很丰富的。

除了漏斗的形式，软件开发还有不少其他特点。首先是研发流程各阶段的关系特点。虽然流程前后各阶段有强烈的依赖关系，但后一阶段不必等到前一阶段完全完成才开始，经常在前一阶段进行到一个特定时点时就可以开始了。比如测试不能在还没有代码的时候就测试，但可以早早就开始书写用例，一旦有了可测的模块便可以进入测试；UI设计不能在还没有产品原型图的时候就开始设计，但可以在核心页面原型出了后就开始确定风格；诸如此类。

其次，软件开发项目中，对工期的预测和把控是非常困难的工作。这主要由于两个原因造成。一方面是产品经理在产品定义过程中，基本不可能考虑到所有细节，有些因为疏忽大意而漏掉，有些因为认知不到而忽略，这部分内容如果在开发过程中产生比较大的问题，可能就会影响工期。另外就是产品经理、项目管理人员不一定懂技术，和盖房子不一样，代码不像砖头那样直观可见，这样的情况下，开发工作不管顺利与否，都要等到有了成型可见的界面后，才能得到最有效反馈，这种反馈的滞后很容易导致巨大的返工成本。基于同样的原因，项目管理人员在计划工期的时候也常陷入手足无措的境地。

另外，软件研发的成员，很多时候都是多窗口并行工作，输入和输出交错进行。为了能输出正确的东西，需要输入各种不同类型的信息。举个例子，一名工程师，开发时可能要同时打开编辑器、终端进行代码编写，同时也要打开产品需求文档查看产品开发需求，打开文件管理器调用素材，以及不知道多少个浏览器标签页来解决编码中所遇到的问题，此外，还有一个或多个随身预览结果的窗口，可能是浏览器或模拟器。这就是为什么程序员通常都需要两台屏幕，只有这样才能应付这种错综复杂的工作。在这样的情况下，如果不能合理安排窗口，总是来回切换的话，工作效率很低，而且很容易烦躁。

追求更好的软件研发是在追求什么

软件研发的目的很明确，就是开发出质量上层、解决问题的软件来。和任何项目都一样，软件开发也遵从项目三角形的表述，技术、人员等客观条件一定，项目的质量受成本、范围、和时间限制。要开发更多的功能，必然影响到开发周期和开发成本；要降低开发成本，必然影响到开发周期和开发范围；要缩短开发时间也一样。要开发出高质量的软件，必须保证这个三角形的闭合。一个有经验的项目经理，面对项目三角形的时候，通常固定一边，调整一边，投资一边。但我们说这不是更好的软件研发，更好的软件研发不是去调整平衡三条边，而是让三角形整体变大，即相同的任务，现在花更少的时间和成本。而这里面又分为三块，完成常规任务的效率更高，面对高难度任务也能顺利完成，尽量少的犯错误。

项目三角形，三边分别是范围、时间、成本

如何更高效的完成常规任务，在软件研发中，工作时间是可以分为两部分的，一部分用来独自工作，另一部分用来沟通。要想提高独自工作的效率，就两点，自动化可自动化的流程，复用可复用的组建。复用可复用的组建就要求每个成员在工作中注意积累和总结，因为现在很多项目都不是一锤子买卖，而是小步快跑的方式，所以这样的积累是很有价值，而且价值越来越大的。自动化可自动化的流程，就要求团队善于运用工具，有了工具，切图标志、数据分析、代码编译、版本部署等工作都可以节约特别多时间。

提升沟通效率稍微复杂一点，这要求团队建立顺畅的信息传输和反馈渠道和机制，来保证团队信息同步，需求传达准确，反馈即时有效。在我心中，最理想的软件研发是由一个人完成的：你获得了一个点子，通过问卷、访谈等方法确定了这个点子可行；接着你把看得见的和看不见的问题都想的清楚通彻了，并根据自己理解定义出了软件，还画出了产品设计图；然后你又自己把软件开发了出来，自己测试了一下，觉得没问题就上线发布了。在这个过程中，你对该产品的思考和认知一脉相承，不需要和任何人去面对面沟通、不需要花时间制作任何文档，也不需要考虑标注切图的问题，因为这一切都是你的，不做这些也不会影响你下一步的进行。然而这样的通才并不常见，况且实在赶时间的话，就算一个人什么都会，也做不过来。所以我们还得有个团队。从这个方面来想，一个人工作不涉及到的任务分配、谈话、邮件、会议、各式文档等都是因沟通而存在的。

能提高沟通效率的方式很多，仁者见仁智者见智，但这里我想给你介绍几点工作中觉得特别重要又容易忽视的几点。首先，要明确计划，虽然软件开发中可能遇到各种突发情况，甚至战略方向都会改变，但制定计划依然是必要的，有一份详尽的计划，能按照计划实行当然最好，不能按照计划实行，也能让团队成员对我们在做什么、要去哪、为什么变化了有个谱，可以更容易理解最新的信息，更准确解读接收的需求。其次，要根据成员的特点优化关键文档的展现形式，拿产品需求文档举例，产品经理可以采取各种不同的工具和叙述方式来制作产品需求文档，说不上孰好孰坏，根据团队成员的工作习惯和工作场景，选择让工作更舒服的方式最好。再次，让变更有迹可循，任何文档，当变更了，都需要记下何时何地何人做了何等变更，为什么；人和新需求，要记录何时何地何人提出了这等需求，为什么；任何回忆，也要记录何时何地何人讨论的问题和达成的成果。只有这样，思路才能是完整的，在之后做类似决策时才是有据可考的。最后，要即时反馈即时纠错，现在的软件开发已经在往这个方向发展了，所说的敏捷开发就有此意，但有时候依然不够，如果可能的话，尝试周稳定版本甚至日稳定版本都是有帮助的，毕竟问题总是越早发现，纠错成本越小。

问题越早解决，纠错成本越低

如何顺利完成高难度任务，也是个见仁见智的问题。这里就简单的介绍一下我觉得靠谱的方法。一是工作的形式上，在面对困难任务时，可以改变各顾各的形式，采用结对编程，即两个人用一台电脑编程，在思考和交流中，更容易碰撞出灵感；如果两个人都不行，那可以采用特种部队的方法，这个特种部队可以由不同类型的成员组成，从不同的思路去思考同一个问题，这样的小组专门在特定的时间负责攻克特定的任务，完成任务就可以就地解散。另一种是建立团队资源库，各种各样的问题，在哪里、找谁有可能得到答案，都可以收集起来，这样遇到问题时不至于手足无措。

怎样避免少犯错误呢？错误可分为看得见的错误和看不见的错误。看得见的错误当然有些因为马虎，有些因为确实难解决，前一种坑可以通过评审尽量避免、后一种坑则和前面说的攻克高难度任务差不多。看不见的错误主要因为经验不足，而经验不足就要努力积累经验。可以建立一个公共的的知识库，积累一整套认知论和方法论，然后再通过不断的的总结和复盘去迭代。更重要的是，这个知识库要使用优质的文档管理软件来建立，至少是方便搜索查找的，如果经验积累了却无法提取，也是徒劳。此外，即时收集反馈和纠错也很重要，不仅减少错误，也减少已犯的错误造成的损失。

结语

以上谈了对软件开发的一些理解，随着互联网的发展，这个行业已经发展得挺健全了，我所说的这些认识和方法也不是我这一家的洞察和思考，说到底，能不能开发出更高质量的软件，还得看能不能结合团队特征调节流程、找好工具、认真实行，毕竟一个几十人的团队就已经算得上一个复杂系统，和复杂系统打交道从来就不容易。