决定项目质量和效率的因素--给原公司的最后周报

（自我完善的）氛围是公司成长的内部动力，迭代可以让项目宏观可控，（人与人交互流程的）分工可以让项目微观可控，（系统与外界、系统步骤间、系统结构间的）协议可以简化复杂度，控制节奏可以提高思考的质量和效率。

因素1：氛围
现状：
1. 出差持续时间长，出差时没有周末、晚上加班、生活单调
杀伤指数：5星！几次出差回来就找工作！
原因分析：严重不尊重员工，不懂得尊重员工，傻傻的以为时间和进度成正比。
总结尝试：员工不是奴隶，员工和老板只是合作关系，老板没有权利强迫员工加班，就算临时加班也该合理补偿。如果任务不能在7天内通过冲刺的方式完成，就该打持久战，该放假就放假，该休息休息，劳逸结合，身心协调才最有效率，状态好的时候可能是状态差的时候的效率的3倍以上，时间*效率=进度，情绪很差时，效率很低。

2. 周报、项目总结、年终总结，只是浮云，开会时没有能讨论的话题，更没法热烈
杀伤指数：4星！没有讨论何来创新，没有创新何来进步！
原因分析：忘记了初衷，抓不到本质，迷失在形式中！
总结尝试：广开言路，鼓励创新，集思广益，真理越辨越明。面对存在的问题，改变不一定立刻成功，不改变可能随着项目变多、人员流动，问题越来越突出直到引起质变。

3. 项目质量和效率的目标模糊，个人目标模糊
杀伤指数：4星！上一个项目有哪些问题？下一个项目要解决哪些问题？公司什么情况下才能给我涨1000元薪水？
原因分析：得过且过，抽象的困难的问题想起来比较累
总结尝试：只有不断总结影响项目质量效率的因素，不断尝试改善，才能提高项目能力；只有明确个人的详细目标和达到目标的利益，才能充满激情的工作。学生学习的知识分为各个科目，通过考试的分数来衡量掌握情况；对公司对个人都该有一个明确的知识库以及库中每科目当前的分数，通过每个项目每天的工作都可以提高有关科目的分数。

4. 没有企业文化，没有企业理想
杀伤指数：3星！除了项目就没有别的了。
原因分析：挣钱就行
总结尝试：缺少凝聚力

意义：氛围是公司成长的内部动力

目标：尊重和合作的人际关系，自由和热烈的沟通环境，明确和激情的目标追求
接口：愿景、知识库体系和积极主动性
原则：我为公司，公司为我，我为我自己
过程：
★ 团队、个人知识库体系、愿景、阶段目标
★ 团队沟通平台：各种总结、QQ、论坛、博客、微博

因素2：迭代
现状：
1. 项目两三年后，短信流程还要大改，之前关于短信做了多少无用功？
杀伤指数：5星！瞎忙最危险！
原因分析：把自己当成了客户！
总结尝试：没有明确做成什么样之前，就自以为是的开始做了，联调时就开始争论和重做，看到客户验收标准后又再来争论和重做。如果不清楚要做成什么样就问客户，如果客户也模糊就做个原型来讨论，进而明确做成什么样。

2. 项目中前期，工程人员不能轻松的从0开始搭建环境，然后向客户演示已完成的功能，获得用户的反馈。
杀伤指数：4星！步子不踏实，产品质量不可靠！
原因分析：对如何迭代还在凭感觉，更没意识到质量控制从开发初期就开始了。
总结尝试：分步走（迭代）是为了防止走错方向。每次迭代目标必须明确，测试用例必须明确，验收必须务实，否则下一步就可能走错方向。

3. 从项目开始到结束，不能明确每个时间段计划完成和实际完成了多少任务，出现了多少BUG，多少次变更，都有哪些原因产生。不清楚时间都花到拿去了！
杀伤指数：4星！始终在犯着同样的错！这个项目的病遗传到下一个项目！
原因分析：只要验收成功，位置就保住了！
总结尝试：既要在乎项目是否能成功，也要在乎过程，通过过程总结项目成功和效率的因素和理论。眼前的结果决定短期的利益，持续改善的过程决定长期的利益！

4. XX天内必须要完成XX功能！
杀伤指数：3星！过高过低的估计都会令时间失控，处于被动。
原因分析：编程是创造性工作，难以量化，只能凭感觉。
总结尝试：明确完成任务后的成果，记录每天实际完成情况，通过总结出实际效率来制定规划。知彼知己，百战不殆。

意义：迭代可以让项目宏观可控

目标：持续交付，快速验证
接口：质量和进度
原则：逐步消除需求理解风险和技术风险
过程：
★ 确定迭代目标：常用的模糊的困难的功能优先，原型到具体，可用到好用
★ 测试驱动进度：通过测试用例的覆盖率来定义进度、通过率来衡量质量
★ 效率统计分析：记录、统计、分析效率影响因素，以实际效率安排计划

因素3：分工
现状：
1. 有人忙不过来，有人没事做，有事没人做
杀伤指数：5星！水桶效应！
原因分析：领导太“专心”，员工不用心。
总结尝试：领导需要有大局任务观，大局流程观！每个人就像一个CPU内核，每个人的工作就像一个线程，一个项目就像进程，既需要考虑充分利用多核的能力，也需要考虑线程间的同步，主（领导）线程要能看到每个后台线程完成任务的进度条。

2. 没有测试就去联调，测试也只是简单的基本路径的测试
杀伤指数：5星！设计、代码质量得不到保证，联调成本大。
原因分析：个人不严谨，团队也无纪律
总结尝试：必须明确定义并完成测试用例才能提交，还要审核；没有环境测试，那就创造环境测试；测试用例必须明确，必须经过上层调用方确认。

3. 不知道错，所以一直会犯同样的错！偶尔有错，能用就行！
杀伤指数：5星！有虫不除，虫生虫，虫虫乐园！
原因分析：没人审核设计、代码、测试
总结尝试：不能输在起跑线上，特别是项目刚开始的时候需要严格审核，否则可能造成批量的劣质代码和隐患。每个任务都可以分为分析设计和实现阶段，如果任务复杂至少分两阶段审核。对待虫子，审核的人和被审核的人都要向对待仇人一样，势不两立。只有1颗菜的时候找虫子，要比在10颗菜的时候找容易的多。

4. 一个模块一个人负责，一个人常常只负责一个模块，交接和出差联调都很痛苦
杀伤指数：4星！人员流动，项目交接，将来别人始终也要去负责。
原因分析：各自为战，管理简单。
总结尝试：统一规范，人与模块多对多，还可以促进技术充分交流。

5. 写好了就不愿意改了，就怕改出问题
杀伤指数：4星！设计和代码的臭味通常越来越大。
原因分析：得过且过
总结尝试：趁早重构，积极重构，享受重构。重构才是项目高质量和个人进步之道。

6. 没见过领导很诚恳的承认具体错误，主动为决策失败负责
杀伤指数：3星！领导习惯了把出现的问题推到普通员工身上，然后挥霍普通员工的时间来弥补自己的错误。
原因分析：客户应该XXX，普通员工应该YYY。
总结尝试：造成功能大偏差、严重缺陷、框架缺陷的问题，都该由领导承担。普通员工一般只该承担效率不高的责任。当前项目过程最严重的不是普通员工编码慢，而是做了（最终放弃）很多和客户最终要求的不符的编码，同时没有严谨的流程控制质量，导致分析设计和代码的质量差，始终在bug中挣扎，这些都是领导的职责。业务知识、分析设计、编码能力和项目管理这几个能力相对独立，熟悉业务不一定做出好的方案，更不一定控制的了项目。首先要职责明确，每个角色都有自己明确的应该和不应该，不在迷茫，然后奖罚分明，调动积极性。

7. BUG管理流程不清晰，效率太低。
杀伤指数：3星！不能方便、及时、准确的获知属于自已的BUG，也不能方便及时的通知别人修改完毕或者提出异议。
原因分析：得过且过
总结尝试：EXCEL的管理方式不适合多人常规开发。尝试明确流程和规范（新建，指派，请求重新指派，修复，完结），然后通过软件去管理，达到清晰的记录问题、快速的传递到下一环节、方便的统计和分析质量。对于通信系统较多的不必现的BUG，尝试通过第三方抓包录像的方式保留证据，尝试无需Telnet的方式输出调试信息。

意义：分工可以让项目微观可控

角色：客户/项目经理/需求分析/系统分析/架构设计/模板开发/模块开发/测试
衡量：面试/入职测试/阶段性测试和评价，角色能力/进取/严谨/出差
目标：规划合理，环节务实，团队稳定
接口：流程
原则：角色市场化、过程阳光可监督
过程：
★ 每步骤顺序进行，各关联角色互审接口
★ 每步骤人员分配，主备共责
★ 每步骤阶段分离，接口与实现分开，主备互审
★ 每步骤成果提交，主备互测互调，客户和项目经理验收
★ 每步骤过程公开，团队解决问题和共享经验
★ 每步骤重构积极，事半功倍

因素3：步骤
现状：
1. XX软件交接时连（需求）协议都没有。
杀伤指数：5星！没有协议的软件或模块，对自己对别人都是悲剧。
原因分析：编写协议花时间。
总结尝试：千万不能鼠目寸光，贪这点小便宜，将来就会一叶障目不见泰山，更没法交接。协议定义了“做什么”“做成什么样”。如果一个人担当多个开发角色，必须每角色定义单独的协议。

2. 透传严重污染了协议！不少人习惯了协议从下层往上层透传，例如没用的数据、复杂的结构或多或少的透传到了PC相关软件的协议中。
杀伤指数：5星！造成了软件不必要的耦合度和复杂度，一个模块改，到处改。
原因分析：透传对部分人来说表面上带来了工作量的减少。
总结尝试：协议到底该谁来定？站在谁的角度，用谁的语言定？上层（使用服务、调用方）决定下层（提供服务、被调用方）的接口（提供的功能），下层提供可行性约束。用户在最上层，用户决定了网管要提供的功能，必须站在用户的角度订立用户和网管之间的协议，是用用户的语言定的。网管需要数据服务器提供服务，必须站在网管的角度订立网管和数据之间的协议，该用网管的语言。对网管而言，号码几乎只需ASCII编码就能满足最终客户，描述一个状态也绝不需要去解析比特。现在的情形是，号码方案的各种逻辑分散在交换机内部各模块，也扩散到了PC软件，号码方案逻辑一改，PC软件也要改，而PC软件对用户的服务不变。
　　
3. 我们的协议中通常只有数据格式。对协议的意义的理解不够，有形无神。
杀伤指数：4星！有些复杂功能的协议中没有流程和测试数据，太多歧义和困惑。
原因分析：简单的时候协议可以仅包含数据格式。
总结尝试：协议需要包含什么？对通信软件而言，复杂功能至少包括数据格式、流程、测试用例数据。协议是约定“做成什么样的”，仅数据格式远不能说清楚复杂的功能的执行过程。

4. 协议精神应该无所不在！
重要指数：6星！
原因分析：协议是用来化繁为简的，把复杂的系统划分成多个软件或模块，每个模块之间只关心其他模块提供的服务（接口），不关心其他模块如何实现。
总结尝试：不仅在不同角色负责的软件间、模块间需要明确的协议，单个角色负责的模块内部也需要使用协议来化繁为简，例如一个复杂的功能，你通过一个函数去完成，然而函数内部可能分成多个函数来完成。

5. 我们需要哪些内部协议？
重要指数：5星！除了外层的协议，内部实现也需要协议来规范和分层
原因分析：就像网络协议一样，一个系统、一个软件按复杂度都应该分为多层
总结尝试：实现过程也需要分层分步骤，通过每个步骤只考虑一个层面来减低思考难度，按复杂度不同可能包括的步骤包括业务建模、需求分析、架构设计、模板开发、模块开发。PC上软件目前最终代码上统一分为界面层，业务层，通信层，各司其职。

6. 其他现象
6.1 我们和别人都定义XX协议，XX协议可以这种也可以那种！
评价：货比三家！实现同类功能的协议，总可以分出个适用范围和优缺点！深度分析，为我所用！

6.2 看代码才能知道做的功能是什么样！
评价：对用户有意义的业务逻辑和参数应该在功能说明书中（需求分析），给客户的是产品功能说明书，而不是代码。

6.3 把以前项目的协议或其他环境下的通用协议不做修改的直接复制到新项目
评价：做新的项目，不能光涂省事，直接从旧项目中复制协议，既需要考虑实际环境的不同，也该问问是不是可以重构，达到优化或精简。

6.4 简单的流程就可以完成的业务，却设计了多种复杂的流程。
评价：完成同一个功能，协议上支持多种实现流程，而且为了微不足道的效率（对用户体验没有什么差别）设计复杂的流程，看似牛B的协议。既需要提供给用户简单的使用流程，也需要设计简单的实现流程。

6.5 测试人员、工程人员也是使用系统的客户，需要通过软件需要满足他们的需求。
评价：现在他们可能需要记住各种各样的调试开关，需要到处导出调试信息，凭经验和记忆处理系统初始化和故障，包括手工备份还原各种数据。需要考虑为方便他们的工作编写软件，达到标准化、快捷的完成常见维护任务。需要像满足软评人员一样的态度服务测试人员，例如如果提出了当前环境无法直接测试的用例，那就写程序模拟。

意义：协议可以简化复杂度

总接口：成果模板
总原则：上层决定下层，下层仅提供可行性约束
业务建模
目标：解决现有业务流程问题
接口：旧业务流程，愿景与新业务流程
原则：理解实现价值的完整流程，包括概念、规则

需求分析
目标：分析执行者和软件的交互过程和规则
原则：用例表征系统使用复杂度，与系统内部复杂度无关
接口：
★ 用例文档
☆   执行者：在系统之外，透过系统边界与系统进行有意义交互的任何事物
☆     系统边界：责任边界，非物理边界
☆     任何事物：操作员、维护员、外系统、外部因素、时间
☆   涉众利益：用例平衡涉众之间的利益，是涉众之间达成的契约
☆   基本路径：把基本路径单独分离，凸显用例的核心价值
☆     只书写”可观测”的，说人话
☆   扩展路径：系统要处理的意外和分支
★ 用例关联：共同资源约束
★ 界面模型
★ 核心测试用例
过程：
★ 业务专家
★ 迭代交付

架构设计
目标：设计实现用例的框架
接口：实现框架
原则：消除重复、分解职责、减少歧义
过程：
★ 消除重复，提取公共
☆   识别模板用例
☆   封装底层组件
☆   选择通用组件
★ 分解职责，层次框架
★ 减少歧义，统一规范（包括代码物理分布、类设计规范）

模板开发
目标：开发精品样板，避免同类用例重复分析设计
接口：开发过程事例
原则：认识对象，划分对象，对象关联，场景模式
过程：
★ 设计阶段
☆   设计各层次间对象接口和对象层次内核心成员接口
☆   依据测试用例和层次间接口编写测试代码
★ 实现阶段
☆   实现伪代码：复杂的业务需要编写单独的设计文件
☆   实现代码
☆   自测：手动测试/自动测试/验证代码覆盖率
★重构阶段

模块开发
目标：依据模板快速开发
接口：模板下的实际作品
过程：
★ 匹配开发模板
★ 依据模板开发

因素4：节奏
现状：
1. 制定复杂的协议（业务流程）时草草了事，甚至都没有形成文档
杀伤指数：5星！对复杂的功能的设计，补了又补，改了又改！
原因分析：初步的设计在部分情况下是可行的。
总结尝试：适合部分情况，不表示适合所有情况，一叶障目，不见泰山！复杂的协议，需要三思而后行。与其痛苦的改了又改，不如设计时审了再审，还要分多个时段审，同时考虑多种方案。今天想到的绝世好方案，明天再想，可能就漏洞百出了。决定以后一定要形成文档，今天记得，一周后可能就忘了一两个分支路径了。

意义：控制节奏可以提高思考的质量和效率。

目标：分析任务所需的思维能力，总结思维能力的分布，规划高效的过程
接口：时间段管理
原则：总结完成各种任务的思维过程优化模式
过程：
★ 明确需要完成的任务，依据思维能力生理规律和思维优化模式规划一天的时间段，以及时间段内的子任务（成果、模板）
☆   分时多次审核抽象深、逻辑复杂的任务，考虑多种方案
☆   睡眠调节，上课下课，变换环境，营造清净
★ 每时间段子任务完成情况反馈（思维生理状态、成果进度、遗留问题、思绪）
★ 任务变更（原因，新规划）
★ 每日重构、总结、领悟当天的过程与成果，补充、修正知识库