简单与繁杂，看似相对的两个状态，往往在软件开发过程中时而相互独立，时而相互并存并协调配合。能够处理好简繁的关系，可以提高我们的工作效率， 让可以简化的工作流程简化，必不可少的工作也保持它应有的繁杂。

交流沟通一直是软件开发过程中最重要的一个环节之一。软件开发中个人英雄主义的成功极其罕见，简单的例子来说，一个人不可能完成一个五百强公司的ERP系统的开发。团体的合作使得交流沟通的效率变得极其重要。 其中沟通管理中就存在简与繁的原则。传达某件事情时候，尽量寻找最简单直接的路径。A⇒B⇒C肯定会比A⇒C效率低下且信息损失也会较大。而在与客户交流的过程中，针对原则性问题（涉及到CS，QCD）我们又往往不可以避重就轻。比如一个可能的误会，但客户已经回复”OK”的场合，继续适当的解释消除误会是有必要的。会议体的使用会提高沟通效率包括周知的效率，针对存在大量Q＆A的机能，我们会避免繁杂的往复邮件Q＆A确认，通过直接的电视会议讲解和沟通更高效。但会议的前提是提前通读所有式样，不厌其烦的洗出各种问题，准备提问的方法（包括表现形式，提案），确认的重点（特别是会议时间不足的场合）。另外还有好多，诸如替客户写定例会的会议记录，看似对我们来说是增加了一些繁杂的工作，但这个事情恰恰又会提高和客户协调沟通的效率。这些都是沟通中的简与繁。 

日常的开发工作中，简与繁的状态会更加多样化。有一种良好的工作状态就是当日事当日毕，理论上我们通过8小时内的高效工作，将当日各项工作圆满高质量完成，同时得到个人成功的愉悦。实际上，工作有持续性，关联性的属性，为了实现上述良好状态，我们又不得不通过一些流程的控制避免出现问题。例如，CDI作业，当日虽然完成了，第二日还需要对修改结果进行确认再反复，同时还有突发的式样变更，进步填写，例会，公司相关事项处理等等，为了合理条理安排工作，制定一个高效而又可能繁杂的提醒机制是有必要的。 另外，Review工作，包括DDR，CDI，UTR等，工作的原则很简单明确，就是【凡是有修改就必须Review】，这个原则绝对不会变化，且特别明了简单，目前我们的现状是恰恰这么简单事情经常无法保证。多次的变更，多次的修正消耗了我们的耐心或者对于反复修正场合的开发流程保证不够。这就需要我们认识到Review的本质，为了保证它的简和繁的协同工作制定相应可执行的流程。例如：

构成管理流程中，原则上要对Review完的成果物锁定（每一次），一旦需要修改时，填写修正台账，台账要维护每次修正的Review状态。一步步的流程【简】单明了，需要我们做的就是执行过程中，不厌其【繁】的按部就班，每个步骤不可省略。抽象来说，软件开发过程处处都有PDCA，PDCA的流程明确简单易懂，恰恰就是在执行的过程中我们无法坚持繁杂重复才会出现各种各样问题，在这个点上改进是提高我们整体效率的途径。

去年开始大连分公司花费大量精力开发社内系统，也旨在把复杂的流程简化，让机器替代一部分人为的控制，以此达到全员效率的提高。已经陆续在各项目中使用，玉不琢不成器，希望诸位同仁一定多多使用，也多多提意见改善！