团队插件化与实现可行性分析

为了避免项目中出现“无法替代”的成员，考虑将将团队实行插件化管理，淡化成员间的主观影响因素，加强功能化管理的效力。

插件化的好处，可以实现资源共享，当某位成员因为个人或外界原因无法履行个人工作时，可以尽快为其岗位补充辅助人员，避免因岗位空缺导致进度停滞。

首先管理层需要根除“与员工对立”的意识，要以公司上下一体，维持正常发展为目标的思想为导向，避免员工出现“旁边总有抢自己工作的人”，对公司产生不信任的猜测，从而降低工作效率。

* 文化方面
  * 统一思想，加强思想灌输，宣扬知识共享，最重要的是从大方面绘画出统一意识的蓝图。
  * 批评单兵作战和英雄主义，在宣扬知识共享的基础上，以群体意识的力量来抵制，孤立其他意识。
  * 侧面烘托危机意识，这一点主要以公司规章制度来规范，实现赏罚分明。

* 规章方面
  * 加强规章的完备性，加强实际中规章的实行力，以制度实行管理，有功必赏，有过必罚。
  * 弱化工作中的个人因素，消除“某个业务只有某某了解”，“某段代码是某某一个人写的”。
  * 代码共享，在不适合全员享有所有代码的情况下，实行结对或者交叉代码复审。如果非保密代码，实现代码全员共享。
  * 文档共享，业务文档一律归档管理，设置个人wiki，将每人的技术文章数设置为考评指标。
  * 思维共享，定期举办座谈会，轮流进行技术报告和业务学习报告，派专人总结会议纪要，进行资料归档。

* 工作中实际操作
  * 明确各个岗位的功能与职责，定义岗位功能接口与依赖，为每个岗位至少分配1.5个人员为常驻负责人员。
  * 各个岗位需要执行详细的工作目标与完成计划，计划时间线尽量细化，做到小步迭代，每次迭代后进行总结。
  * 上岗前使用统一培训资料进行培训，并进行考核。
  * 出现人员变动，立即使用多余的0.5个常驻负责人顶替原岗位，并补充新的人力资源，根据以上几步重新培训，上岗，负责，考虑。

* 预期问题与解决分析
  * 如果预期团队中可能出现以后会以某些核心功能要求整个公司的情况发生，应尽快从核心开发中进行剔除，如暂时无可替换，则应加入其它成员，弱化其自身的影响力，减弱其破坏性。
  * 对于技术要求过高，难以实现多人互相牵制的情况不适合。
  * 对于人员与时间要求严格的情况，以至于难以满足最基本开发流程的情况不适合。

综上所述，团队插件化只有在同等职位同时至少有两人可以胜任的情况下才能满足，而且代码与知识共享的过程会消耗一定的时间，小公司小项目的情况下，人员无法满足1.5倍冗余，时间也无法保证的情况无法适用。

其实你只要给他们开1.5倍的工资就行了

人为什么走，为什么流动，无非是待遇和钱和发展的问题

只要每个人都会写好的程序，每个人都了解整个系统，每个人都成为外科医生，那么每个人都是可以替代的

嗯，原来你宁可花1.5倍的钱保持人员冗余是因为你的手下全都是些病秧子，老病号，而不是为了提防他们走人？

何谓自身发展期望？
对打工族而已，归根到底也就是待遇问题而已，为什么大家喜欢进外资进大企业进500强？为什么那么多人要去考公务员？待遇福利问题罢了。大家出来工作，不过是被剥削，打工赚工资而已。无视抹杀员工作为一个打工者的根本需求，这种公司无非也就是那些血汗作坊而已

从老板公司的角度而言，利润是谁创造的，员工创造的，一个岗位有一个岗位的事情和责任，能够创造一个岗位的利润，一个罗卜一个坑，没有任何一个老板一个企业可能会为了你那些GP理由，制度化的去花1.5倍的钱与成本养50%的员工当做不产生利润的备件，只是为了你那些莫名其妙的老病号式理论

如果一家公司宁可花1.5倍的钱保持人员冗余以防备有人走人，却不愿意给正在做事的人提高待遇，这种公司，无非就是大家都会随随便便的走人而已