Android DVB 项目经验总结

1.团队成员隐瞒重大错误（影响其他成员开发），发现问题后偷偷修改。
  弊端：降低合作效率，其他人也在使用和查找原因，如果已经修复却不通知其他成员，会浪费人力去查找问题。
  正确做法：出现重大错误应该及时通知处理结果。
 
2.系统模块化，责任化后的真空地带，即便发现了也无人处理
  弊端：项目不可能完全划清不同模组界限，如果真空地带没有负责人，问题将一直保留。
  正确做法：指定真空地带的责任人（需要很有责任心，因为边界很难认定）。
 
3.执行力不足
  弊端：成员懈怠心态导致工作效率低下
  正确做法：找出懈怠的原因再处理。
  现象：总是重复要求和命令、每个计划基本都要延期、对工作量估计总是不准确、下属顶嘴，答应的事总是拖延。
  可能的原因：
  1）大多数命令都没有检查结果，做好做坏都一样，久了就散漫惯了，偶尔一两次的检查也不能改变大局（即便是在员工入职阶段也这样处理）；
  2）全团队15个人都只对经理一个人负责，经理事无巨细，很容易忘记和漏掉一些事情；
  3）员工本身态度，个别人都是平时散漫惯了，工作如此，但只是个人人，因为员工在招进来的时候就把了关的；
  4）制定的计划、问题的处理决定太随意，一般很难达到预期的效果，言而无信、遗忘、遗漏都可能丧失权威和执行力；
  5）领导本身态度，领导本身对工作不上心，自然领导不能征服下属；
  6）公司制度缺陷，不能尽量做到公平、不能进行系统性的/精确性的管理项目。
 
4.代码质量低下
  表现：重复的修复同一类问题、可读性很差、冗余代码很多、堆积代码、debug信息随意而混乱、没有必要的注释。
  弊端：写代码不按照规则来也不提出意见，随心所欲，员工基础知识不足就直接进行代码的开发和维护会直接增加代码的维护成本。
  正确做法：
  原因：除了QA提出bug，再无固定而有效的机制对代码质量负责。