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

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

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

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

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

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

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

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

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

要想弱化开发人员的“不可替代性”，就要从根本上消除开发工作带有创造性的部分，也就是把所有的设计工作从开发人员身上移走。这样的话，负责设计的人又成为“不可替代”的了。

文档，作为对思维的描述，跟人的表达能力关系很大，所以不能期望过高。

统一的资料进行培训，只能做到统一编码规范，而不能做到统一开发水平。

“统一思想”“统一意识”“统一……”之类的描述，是完全不了解开发工作的表现。宣扬这种观念的 BOSS，完全不知道软件开发是怎么一回事。

将设计和开发完全抽离，有点儿外包的感觉了，这种做法倒是蛮附和一些公司代码保密的想法的，实际操作时也容易掌握，只是如上面所说，这种硬性的分层只能将开发变成机械的手工劳作，没有解决负责关键工作的关键人的不可替代性，一旦负责某一业务的设计人员因故离岗，空缺依然难以补充。



将文档的写作规范和行文严格要求，可以减少不同成员之间表达能力的差别，此处考虑文档只做为归档资料以备复查，平日的知识共享还是体现在结对编程，代码复审以及例会沟通上。



确实无法统一开发水平，关于开发水平的论述暂时考虑不要放在此处进行讨论。



请考虑将“统一思想”作为更高层次的理解，从人文角度宣扬知识共享与团队至上论，在此考虑软件开发也是团队合作的一种，以提升团队凝聚力为目标的思想统一还是必要的，或者我们直接把这种做法说成“企业文化”吧。

另附：首先，弱化“缺一不可”不等于“从根本上消除这种差异”。我们的起点在于通过弱化“不可替代性”来减少因此可能导致的重大问题，例如：“因某个项目成员病事假导致岗位其负责的代码无人接手，导致项目延误”，“因某个成员的时间计划出现误差，代码和知识没有共享，导致难以通过加派人手的的方式加快开发进度”，等等。

再邪恶一点儿的话，如果团队中某人因为某些原因无法与团队其他成员进行良好的协作，如果他潜意识中认为自己进行的工作是无可替代的，很可能会因此产生敌对意识，项目成员都可以清楚认识到自己只是项目的一部分，而非致命要害时，可以避免一些人产生不利于个人发展的想法，某种程度上从心理层面起到稳定团队的作用。

只能在某种场景下才能实现人员的完全可替代，人事变动必然与再培训再适应相关联，任何时候我们都应当以保证人员的稳定为前提，在此是为了避免因为人员的不稳定导致的问题而发起的讨论。

好的方面：公司从上向下看，不希望因为人员变动对整个项目造成不利影响，员工从下向上看，共享资源扩大了自我发展的空间。

坏的方面：公司必然为此付出巨大的管理成本，员工少了要挟老板的筹码。

对底层员工来说，他们的利益与公司的利益是不同的，不可能要求员工向老板一样去看待问题（否则老板也是可替代的了）。

另一方面当项目出现问题时，底层员工也是最容易被牺牲的，他们动辄被迫通过加班等方式为混乱的管理买单。这种情况下对员工妄谈什么“思想统一”、“企业文化”，无非是进一步的剥削罢了，还指望得到认同？

从纯利益方面考虑，如果公司倒闭，老板和所有员工都没饭吃，这一点上公司上下的利益时一致的，在不考虑打入我军内部的间谍和妄图改朝换代的弄臣的情况下，通常公司上下在大方向上的利益是一致的。

如果项目出了问题，底层员工被迫买单的情况是因为社会中的弱势群体不懂得团结起来保护自己的利益，探讨弱势群体如何维权的话题已经超出了本文的访问，还是暂且打住吧。

如果公司方面只懂得一味的剥削，而员工还能够忍受的话，我们也只能认为这也形成了一种企业文化，而且企业内部的员工也认同这种企业文化，我们经常可以看到全公司上下无怨无悔不计报酬的每天加班，这就是一种“思想灌输”的成果，虽然个人完全无法理解为什么会有这么多人能够忍受“加班企业文化”，但是现实证明了为数众多的程序员都有过如此的经历。

从统计数字上来说，“加班企业文化”也占据了相当大的份额。由于人们的逐利倾向，当没人有反对这种氛围，而是选择默默忍受时，也就决定了其他同种公司会照搬这套经营方式，如果出现了很多反对声音，“加班文化”也很难有立足之地，因此那些“基于各种情况”可以忍受加班的员工也是实际导致“加班文化”大量出现了另一面。

在博弈双方互相试探的过程中，某一方选择了退让，另一方就会立即狂追猛打，相反也会产生同样的效果，只是员工觉悟尚未成熟的情况下，很难把握住这种机会。随着时间的推移，经验的积累和教育水平的提升，遥远的未来可能有一天会发展成相对的平衡。

“如果公司倒闭，老板和所有员工都没饭吃”、“通常公司上下在大方向上的利益是一致的”？太天真了吧。真这么想的话还担心跳槽么？与其搞什么“插件化”还不如把这些成本用在改善员工待遇方面，更容易形成良好的公司文化，效果也会好得多。

  你的这种说法和前不久那个核心成员可替代如出一辙。所以问题也是一样。看似很美，但是不考虑客观的实际。
  即使没有感情的代码，你要达到插件化，有时候也需要花费很大的成本。和力气。而且并不是每一个程序员都能够写出好的松耦合的代码。这也就是为什么那多框架产生的原因。
  当要处理比代码复杂的人的时候，你难道奢望能够建立一套体系，用之四海皆准么？

先把自己插件化吧。。。。

又一个读了一些软件管理，软件工程类的书之后发表纸上谈兵感言的主。

多写点代码，用切身的体会来表达问题的时候，就有说服力了。

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