本文是《IT研发中心管理思路、策略和制度》专题的一部分。
不能被体系约束，但是又不能没有体系
跨组、跨部门协作：
比如，要做一件重要事情，但是关系到多个部门的人，怎样 既能有效的把事情做完，又能把对他人正常工作的影响降到最低。
我认为，绩效不能局限于本职工作，响应跨组织的协作应该是高优先级的事情。
临时事务或新想法的落地：
比如，临时遇到一个重要需求或事情，或者想到一个很好的idea，到底要不要做？其实完全可以逃避或者敷衍，事不关己高高挂起嘛，即使不做，对自己的绩效也没影响嘛，何况很多公司连绩效也没有。
要避免这种事情发生，就要有相关的政策引导，让大家只管把事情做好，不要有后顾之忧，而且做好了就有加倍的奖励，而敷衍的人会被发现和被淘汰。绩效不能只体现在日常工作，还应关注创新和服务工作，有的时候，服务工作和创新工作优先级要高于日常工作，甚至可以全职做。
实施方案（引导政策）：
1、个人的工作安排，允许有足够灵活性和自主性，也就是说，除了上级领导安排的工作外，可以自己增加临时的、必要的工作项以及调整工作优先级，如果对重要事情的优先级有疑问，可以找领导商议。
2、跳出本职工作，及时响应跨组织的需求和协作。如果人有找到你，表示需要你协助，你必须及时回复（一般不超过1小时）：如果这件事你能做，就应该优先安排时间完成，如果你做不了或者排不上优先级，可以向对方解释清楚。
3、工作中，有好的idea，可以随时找人商议，形成一些比较成熟的想法后，可以上报给领导，如果建议被采纳，可当场奖励。另外，鼓励你站出来领导和推进这个idea的落地实施（甚至可以全职投入），如果idea被成功执行和落实，将有更丰富的奖励。
2、扁平化管理
压缩“金字塔式”多层职能部门和机构，使企业的决策层和操作层之间的中间管理层级尽可能减少。
打破跨层级的阻碍，建立起 跨层级反馈机制 和 跨层级跨部门的虚拟组织，使整个组织紧密联系在一起（整个组织不再是金字塔结构，而是数学上的图结构，点与点之间可以连线，形成最短路径），严禁拉帮结派，避免出现许多各自为营的小团伙。
3、权力和责任成正比，明确权力和责任。防止滥用权力，有效监督。
（略）
4、以考核 驱动 正向积极的工作，避免 错误/消极 的工作。
个人一个深刻的经验：服务工作的考核一定要加上客户评价！
举个例子，许多公司有 “客户服务部”，接收客户的投诉和建议。其实工作中，许多岗位也肩负着服务性质的工作，如果这些工作做得不好，会是公司工作效率低下的源头。给服务工作人员的考核加上客户评价之目的，就是为了督促各岗位员工，忠于职守，热情高效的服务。
哪些岗位存在典型的服务工作，举几个例子：行政，网管。还有很多非典型的岗位，例如运维。其实可以这么说，权力和责任是对应的，有管理权力，很多时候就有服务的责任：行政掌握了物资，就要有提供物资申请的服务，运维掌握了服务器，就要提供服务器申请的服务，等等。
我待过不少公司，1.有的公司有类似于月度绩效考核的东西，直接影响当月的工资以及各种奖金。2.有的公司没有月度考核，只有季度汇总和年度考核，这只会对奖金有影响。3.还有的公司，没有正式的考核。这些都是些我的亲身经历。
第1种公司，考核确实是他们很好的一种管理手段，解决了很多问题。但是做考核挺麻烦的，规则也相当复杂，没有一两年的经验积累，很难做好考核。但是话说回来，利远远大于弊。
第2种公司，年度和季度考核，做得很粗，换句话说，很不准确，而且时效性低（比如有可能 某人这个月做得好，但是下个月做得差，这种情况在粗粒度的年度考核中很难体现），另外一点，对员工的约束力有限，因为这个只在年度才会有影响，平时根本就不用在乎， 或者有约束力 但是往错误的方向引导，因为打分的粗犷，让人认为只要讨得打分的人的欢心就行了。
第3种公司，没有正规的考核，全凭自觉，或者主管的约束力，这种只适合 员工都很优秀 自觉，主管有很强的管理能力，这样的公司。否则从上到下一团乱。
经验总结：
1、建立稳定的绩效考核机制（一定要稳定，不能一年半载就变更），与研发人员的薪酬、奖金挂钩
2、建立稳定的晋升奖励机制，惩罚机制。
3、人性化管理：管理者制定基本规则，保证规则的正确性和稳定性，细节任由下属人员自由发挥。
管理技巧：
Re-Organization - 换组
One on One - Manager每周带一个成员
个人OKR和Performance - 绩效与职级、薪酬挂钩
5、组织的组成和划分
根据我的经验，针对垄断型产品，产品设计和研发有三个“首先”原则：
首先解决功能有无的问题，再解决用户体验问题;
首先解决用户核心需求，再解决其他需求;
首先快速上线，再根据用户反馈调整研发计划。
(此处的垄断型产品，指的是“该产品具备固定的市场和使用范围，在这个范围内，用户没有别的选择”)
应用这个原则，有如下一些方法：
快速原型法，快速收集真实反馈
测试先行法，开发测试，不完美测试，最小化测试
后端Mock法，屏蔽临时障碍或难点
最小功能，最简UI，甚至无样式、全部手工输入
在传统企业，很难做到这些方法，因为它需要产品、开发、测试三方融合，共Team、共患难，
如果没有这样的团队，就会出现下面的情况：
产品只管写文档，文档出来了，你们照着做，至于为什么要做成这样，产品说这个你别管，就是这样设计的;
产品到研发末期才验收，发现怎么做成这样，这里那里都不对，不符合预期，头大。
测试对开发说，我先写用例，等你们做完完整功能，并且通过自测和冒烟测试后，我们再正式开始介入测试。
测试发现，这里那里好像不对，找开发讨论，甚至找产品确认。
开发说，产品和测试都是死对头，恨不得在桌子底下放把菜刀，谁敢提bug、改需求就把刀拿出来，辛辛苦苦把功能做出来了，发现测试提了很多bug，产品需求也改动很多，时间也紧张，快要崩溃了，产品做出来好像也有些不对劲，怎么看都没有感觉。
我的建议是，one team, one dream，产品、测试和开发，互帮互助，相亲相爱，朝着共同目标奋斗。
6、研发团队的绩效考核与奖励制度
基层研发团队按部门、产品线、项目组划分。如果公司小，可以不分部门和产品线，只分项目组。
项目组成员根据需要动态配备，一个研发项目组实线 可能包括产品人员(非必须)、开发人员(包括前端、后端、移动端)、测试人员(非必须)，他们共同组成一个team，可以由他们自己选出一个组长。公司所有基层研发人员，包括产品/测试/开发/运维/设计等，都在人力资源池中，需要组建项目组时，就从中调取。
比如，公司根据需求，要成立三条产品线，五个项目组，
分别为：
1、基础数据服务-产品线
下辖：数据平台组、开放平台组
2、应用APP-产品线
下辖：某某APP组
3、基础技术服务-产品线
下辖：基础平台组、OA项目组
一种管理思路案例（仅供参考）
其中，OA项目组是短期项目，预计2~3个月工期，其他项目组都是长期项目。每个项目组，有公司管理层的粗略的规划，设立了一些关键目标，并给出了初步预算，不过，这些后期都可以调整。
这些项目拟定后，就开始招募和选拔人员，
首先，自由报名，由公司 “产品技术委员会” 和 项目组内成员共同审核，通过则加入到项目组。
例如，数据平台组为重点项目，公司开出了10人*10万/年=100万/年的奖金，并按季度发放，张三 李四等10人都报名，经过委员会评审，决定张三 李四，第一批加入到该项目，然后后面8人，由张三、李四和委员会共同审核，最终5人入选，人员结构为 Java开发4人 产品1人 测试2人。那么这100万的奖金，将由这7个人分摊。如果中途有人加入或者退出，奖金额度不变。
虽然，这7个人组成了项目组，但是他们3个月后发现，测试貌似只需要1人就够了，另外需要一个前端工程师长期支撑，以及一个Android工程师临时支撑——大概需要高级开发-30人/天。要减掉一个测试，需要组内所有人都同意并且报委员会审批，如果另外6个人都同意那个测试离场，且委员会审核通过，那么那个测试将会出局，回归到人力资源池中。减掉的那个人，奖金会计算到他离场的时间点，并且按最高绩效A等核算。在人力资源池里面暂时没有项目组的同学，只计算基本工资(全额工资的1/3，且无奖金)，且如果3个月都没有项目组收留，公司就会与其解除合同。
需要增加的前端，他们有两个选择，1是找个短工，签6个月(大约需要花费5万元的奖金)，2是找个临时工，让其他组的同事加班支持，事情按时做完了，给与丰厚的酬劳(按一周加班16个小时算，共支持40天，每天给予1000元奖金，共支出4万)。
上述产品化方案的问题
运维怎么搞？
研究组怎么搞？
架构组怎么搞、虚拟组织怎么办？
人力变动工作怎么交接、团队怎么管理？
这些问题按上述方案去做，很难解决，所以还是不要自行选拔人员，而是由管理层去调度。
首先，人数、工期和预算，管理层统一规划，比如，上面说的数据平台组，定义为“重要，紧急度一般”，预期第一版工期2个月，一期绩效预算20万，初期按开发4人 产品1人 测试2人来规划，平均每人每个月绩效开支1.4万。注意，只是公司层面的预算，而不是每个人的收入。
后面1个月后，发现测试有大量空闲，但是缺少一个前端工程师，那么应该是项目经理向上级申请、或者管理层根据数据分析发现这个情况，主动调整队伍组成，将测试抽调到其他地方，再调来一个前端支援。
整个产品、预算、工期、人员，都是研发管理层决定的，团队成员无需知晓预算是多少，他们的薪酬也不因项目的不同而有明显差别，不论在哪里，做好他们眼前的事情就可以了。
项目奖金方案的升级版（最终版）：积分和荣誉勋章
积分方案，在业界早有实践，据说来源于游戏中的DKP（Dragon Kill Points，屠龙积分），起初用于分配战利品的方案，后来逐渐用于公司治理，特别是项目奖金、绩效奖金分配，现在很多中学、大学里也用这种方式来发放绩效工资。
我在之前的公司也早有实践，如今我又结合多年的经验重新优化了一遍。
积分具有现金价值，姑且按：1积分=p*1RMB计算（p为公司整体效益系数，正常=1，根据公司效益好坏可在0.5~2之间波动）。不再单独发年终奖，年终奖就是用积分兑换现金。比如某个人一年获得了4万积分，那么他年终正常可兑换4万元。
将原来以年为单位，发放绩效奖励的方式，转变为每个ORK考核周期（暂定为双月）根据工作成绩发放积分。这样的奖励时效性更强，也能提高大家的积极性，同时也能及时对绩效低的同事做绩效辅导。
参与公司急推、悬赏的重要任务（重点项目赶进度、产品研究创新、技术攻关、临时紧急任务等），以及对项目、部门或公司有重大贡献，可以获得额外的积分奖励甚至荣誉勋章（可以看做：额外鼓励金或者加班补贴，但不强制加班，也不强制做高难度任务），以资鼓励、及时鼓励那些勇士和奋斗者。
荣誉勋章是完成重要项目或任务，付出重大努力和贡献之后获得的奖章；奖章虽然没有现金价值，但是会体现个人对公司的价值，一个满载荣誉勋章的员工，没理由不是公司的骨干员工，后期升职、调岗、加薪都会重点照顾，对于特别核心的员工，可能还会有其他特殊福利（比如期权、弹性打卡、特别关怀等）。
积分的本质是从每个人的年终奖中抠出来的，然后以虚拟货币（积分）的方式来支配，通过绩效和奖励的方式再发放给个人，年底才能兑现，取之于民、用之于民。
基础绩效积分，可以按员工的年终奖（以中位数为基准，1.5个月）来作为全年奖励的中位数，浮动在1~4个月之间。
基础的绩效积分，按ORK考核周期发放，按考核成绩的SABCD档次系数给与每个人稳定的积分（按双月ORK算，基数是“1.5倍月薪/6”，最高的S，可以获得2*基数的积分=3/6=0.5个月工资，最低的D，保底获得0.5*基数的积分）。
额外的奖励积分怎么评估？理论上积分的发放完全可以由管理者“拍脑袋”决定，但是我提出了一种科学的方案：既便于估计成本和积分发放量，又能从算法上保证不超支。即提出了“奖励积分参考单位/基数”的概念，基数的作用是为了便于管理者评估发放积分的数量，跟人力成本挂钩。
如果是急推项目、悬赏任务，可按投入时间来评估积分，积分按参考单位40分/天计算投入，比如达成一个有额外积分奖励的项目的里程碑，耗时3个月，投入了约20人，总共投入人/天为：20*(3*21.5)（剔除了周末），发放积分约：38*(20*21.5*3)=5万积分。 如果是对于重大贡献的奖励积分，也可以依据40分/天的单位，按节省的投入、提高的效率酌情给予，比如400~2000不等。
积分评估的参考单位“40分/天”是怎么算出来的？明白一点，积分的发放最终到人，积分池也是变相从年终奖中抽出来的。所以简单的计算方式为：把公司员工的平均年终奖（拿一部分，比如0.5个月）除以全年工作日，得到以人/天为单位的奖励中位数。比如按2万，0.5个月算，平均到每个工作日，大概就是38元/天。这是一个估计值，大概就行了，不需要很准确，四舍五入，就按40元/天计算。由于是从每个人的年终奖中抠出来的，所以理论上每个人发放40元/天也只是达到中位数，况且不是每个人都能拿到，所以不会超支。
40积分/天，这就是一个“奖励积分的基数”，所有员工都一样（有人说对高薪员工不公平，但实际上积分是对事不对人的，一律平等的。给一个机会，让低薪员工通过努力，也能得到更多回报，当然，理论上高薪员工的能力更强或更稀缺，自然能获得更多奖励积分）。
所有重大的奖励积分（比如5千以上的）由公司负责人审批，小额积分也可以直接由一级部门经理审批、并接受不定期监督。奖励积分可以以一级部门为单位根据事情发起。积分最终直接发放到做事的团队或个人，如果是发放到做事的团队，则可以由该团队的负责人在部门的监督下自行分配积分给其他成员——这体现了权力下放、扁平管理的精髓，可以调动基础管理人员的积极性。
7、缩减会议，提高办事效率
集体会议效率是很低的，浪费的时间也很可观，比如一个15人参加的会议，1个小时，总时间成本就是15小时，相当于2人/天的成本了。
关键是，会议期间，大多数时间，只有很少一部分人在认真的参与，其他参与者大部分时间处于无关状态，这样算下来，一个会议15个小时的成本，浪费可能有80%，而且通常效果还不好（举个例子，一次上线评审会，各个岗位，约有15人参加，最后会议通过了评审，但是后面执行人员真正准备去执行时，才发现之前评审通过的流程居然漏洞百出，而当时他还在评审现场，也没发现有这么多问题。这是个真实的例子，其实很正常，评审的时候，并没有用心去看流程，所以到了真正执行时，才会仔细去检查）。
综上所述，其实想说明一个道理，很多会议，不但浪费时间，而且效果并不好。真正高效的是，小团队沟通，1对1，或者3人，但不要超过4个人，否则效率会大幅度降低。
IT研发团队，有哪些集体会议是可以省略的？
各类评审会议，部门日常会议等。
产品研发的流程是什么，在这个流程里，产品、设计、测试、开发（包括前、后端等）应该如何配合？
这个我专门有个PPT来总结分析，此处只补充一些：
我将产品分为多种类型，比如偏业务的产品，偏技术的产品，偏UI和用户体验的产品，各种不同的产品研发，侧重点不一样，主导权也不一样。
偏技术型产品：开发经理主导，产品经理辅导；开发主导测试，测试辅助测试。
偏业务型产品：产品经理主导，测试经理和开发经理辅导；测试主导测试，产品辅助测试。
偏UI和用户体验产品：产品经理主导，前端开发经理和测试经理辅导。
当开发和测试过程中，有任何争议，应该由产品的主要负责人们来定夺（如果各个负责人也无法达成一致意见，可以采取投票制）。
举例如下：
某测试提了一个BUG，级别为“3级-严重”，但开发认为不是BUG，可能的原因是，1.测试人员的用法不对，2.需求描述不清楚，每个人的理解不一样，3.本来设计就是这样的，可能设计不算合理，但开发就是照着设计做的。
遇到这种情况，双方沟通无法达成共识，怎么办？解决办法如下：
开发否决BUG，并且备注原因。被否决的BUG，流转到对应测试人员那里，测试人员接受则关闭BUG，不接受，则提交复议，复议人员组成根据项目特性来决定，通常包含产品经理、开发经理、测试经理，复议人员发表评论，再由测试经理根据讨论结果，采取进一步操作：否决、重新打开（可以重新设置BUG级别）、下一期处理。
这个主题，还包括IT团队各个岗位的设立，单独一篇文章论述，参见：《研发中心各个岗位的设计和配合》