游戏开发团队并非蚂蚁协作（2）：开发者做事的倾向-CSDN博客

本文链接：https://blog.csdn.net/u013412391/article/details/141984631

在这里插入图片描述

开发者做事存在倾向

上一篇说到，在这样一个大项目大团队中，PM无法安排开发者所有事情，这让开发者拥有了一定程度的“自主性”。这一“自主性”体现在，在没有其他因素影响下，开发者会先做喜欢做的事情，而不喜欢的的事情会放到后面做，甚至有可能会被永远放在后面。也就是说，开发者做事会存在一些“倾向”。

下面列举一些倾向。（这并非是对这一问题的准确划分，只是列举一些方面反映了“倾向确实存在”这一现象）

倾向1. 可体现绩效的

薪酬一般分为了“合同中明确的固定薪资”和“绩效所对应的薪酬”。虽然后者在不同团队的情况不同，但一般为了激励，都不会一点也没有的。此外，就算绩效没有反应在薪酬上，也会反应在晋升或其他方面上。所以这一部分所讨论的倾向是普遍存在的，只是程度上有差别。

“绩效”是一个抽象的概念，没法用具体且客观的东西来体现。虽然我们有“单子”，但显然它不会真正成为衡量绩效的凭据，只能作为参考。真正衡量绩效的，还是靠管理者来主观判断，那具体怎么判断就属于我不知道的领域了，毕竟我不是管理者（笑）。

不过，虽然不知道绩效具体被怎样衡量，但大多数开发者是能感觉出的——显然不是每件事情都能体现绩效，或者说体现的绩效有高低之分。举些例子：

作为程序员，“写代码” 比 “和别人沟通” 更容易体现绩效。
非开发流程（比如填单子，申请提交文件权限等）无法体现绩效。
调查BUG可以体现绩效，但如果是重复类型的BUG则不好体现绩效。此外，BUG的根源也有关系，如果BUG的根源属于是设计上的严重问题，则能体现绩效，但如果只是因为别人的失误而制造的偶然问题（比如漏传一个配置），则相对不容易体现绩效。
如果你在为其他开发者写工具，那么写成的工具在团队内使用面越广，就越能体现绩效。如果没有人用，就不容易体现绩效。
对代码的“重构”或是其他对于开发者的优化，很难体现绩效。
“分散的小事情” 不如 “成系统的大事情” 更能体现绩效。
重复又简单的事情（比如写一个配置）很难体现绩效。
不属于职责范围内的事情不容易体现绩效，比如作为程序员，却像QA一样去测试一些问题，像PM一样去联系别人沟通和推进问题，像策划一样维护一些玩法配置，等等。
。。。

开发者肯定喜欢做能体现绩效的事情，因为这样才能得到更多的利益，这无可厚非。

倾向2. 可提升能力

提升能力更有利于在团队中争取到跟多的利益，也有利于以后脱离团队时能更有可能寻求到更好的机会。

开发者可以较清晰地认识到，做的有些事情是提升不了能力，或提升很少的。

其实，大多“体现不了绩效”的事情同时也“提升不了能力”，比如“重复地修改类似的一些配置，重复地为别人解释同一个事情”等。这些事情是大多数开发者努力想避开的“垃圾事情”。不过也有些事情，虽然不体现绩效，但是会提升能力，比如：

在做一些相对没经验的领域的任务时，会预留时间查阅学习一些文档，研究别人做的相关工作等。这些体现不了绩效，但是绝对是会提升能力的。
一些有一定复杂度与难度的“效果”或“工具”或其他开发，就算最后没有派上用场，不能较好地体现绩效，但却可以让自身获得能力提升。

很多开发者，尤其是更年轻的开发者，会非常在意这一点。

倾向3. 不易于犯错的

有些事情是不容易犯错的，例如：写一个界面，目的是可视化某项数据统计。它与现有的结构没什么关联，不会对之前的结构有任何修改，几乎没有任何犯错的可能性。

但有些事情是容易犯错的，例如：做一项优化，减少一类贴图的尺寸来获得性能上的收益。它的问题在于，实施起来容易，但却必须要验证：确保做了这项优化后，相关的效果没有受到太大影响。而难点在于，这可能并不好验证，因为你可能无法验证到所有相关的地方。可能在你的测试场景中它没受影响，但在某个角落却造成了毁灭级的影响。更可怕的是，如果这个受影响的效果相关的负责人，你在优化的时候并没有通知他，而在未来一个“不合适”的情境下暴露出来并让他发现，那么一场“战争”恐怕在所难免。。。

开发者肯定不希望犯错，所以肯定更倾向于做那些不容易犯错的事情。

一般而言：

与已有系统相关度越高越容易犯错。
与运行时相关的问题更容易犯错，纯编辑时的问题不容易犯错
易于验证的问题不容易犯错

倾向4. 对他人等其他因素依赖少的

有些任务是对他人有依赖的，比如：依赖他人提供一些测试用例，依赖他人修正某项错误，依赖他人向你解释某些事情的原理。还有可能依赖的不是某个人，而是某个事情，比如：依赖打包流水线成功产生一个新的包，依赖一个新流程实施一段时间，等等。

开发者肯定不希望依赖性多的任务，因为这不仅意味着你需要耗费更多的精力与他人交流，还意味着推进的过程中会插入很多“等待”，而又不确定要等多久，这让你的事情变得很不可控。

倾向5. 计划内的

一般而言，开发者需要连同PM以及管理者在一个周期的开始去定这个周期要开发的任务。这些任务是PM和管理者都认可的事情。而一旦有计划外的事情需要去做，那就有些麻烦了。如果你做了计划外的事情，那么计划内的任务一定会有事情做不完，所以你必须要确保这个计划外的事情优先级很高，否则之后就不好解释为什么有计划内的任务做不完。

理想流程里，当别人尝试让你做计划外的事情，首先要拉起PM去评估是否真的要插入到这个周期。但正如前一篇所说，PM可能不具有足够的时间去真正评估。更糟糕的是，有可能这个计划外的事情很小，小到“评估它的时间比实际去做的时间还多”。但是这种小事情有可能累积成一个可观的时间，这时候开发者就会陷入矛盾的境地：

如果拉起PM去评估，就是浪费了大家的时间。
如果不拉起PM，事后可能也会被怀疑优先级。
如果索性连单子都不开，自己偷偷做了，那自己的绩效又体现不了。
如果拒绝去做的话，那有可能这个事情优先级真的很高，而消耗你的时间又真的很少。这种情况下，有可能会受到“投诉”。

因此，不管事情是大还是小，只要它是计划外的事情，开发者首先都会摇头，然后无奈地思考要怎么办。。。

倾向6. 相对有经验的

这里的“经验”不仅指“自己的”经验，也指“团队”的经验。

“有经验”的情况比如说：“创作一个新关卡”。因为之前已经创作过其他关卡了，所以一个新关卡怎么做，完全有之前的经验做参考。

“没经验”的情况比如说：“开发一种新的功能”。因为之前没做过，所以完全不知道结果会怎样。最差的结果可能是，已经做了两三个月，却发现这个新功能在某方面有个致命的阻碍且无法解决。那这两三个月就白做了。

没有经验的事情，估时是不准确的，结果是不确定的，因此大家都不喜欢去做。

我的倾向 ≠ 你的倾向

由于每个人所负责的内容不同，所以每个人的倾向去做的事情显然不一样。比如：一个美术在制作中发现需要修改一个配置才能让他推进他的任务，但是修改这个配置需要另一个程序员协助完成，这时候就会出现这种情况：

对于这个美术而言，他要推进的事情是他很想去做的事情。
但是对于这个程序员而言，这个修改配置的事情，是计划之外的，有重复性质的，反应不了绩效的小事，是他完全不想做的事情。

这时候就会产生开发者之间的矛盾。

我的倾向 ≠ 团队的倾向

开发者的倾向是源于个人利益的，而这经常与团队的整体利益相违，比如：

花大量时间实现某个新系统，对你个人成长而言很有帮助，但是这个新系统可能对于团队用处很小。
团队希望某一项配置能被及时地、正确地维护，但是维护这项配置对你来说是个“垃圾事情”。
有些任务确实是充满了未知与挑战，并且容易背锅，然而却必须有人去做。
。。。

这些例子不难举出，甚至可以说，“个人倾向做的事情与团队一致” 才是少见的情况。

与个人倾向“对抗”或“引导”

每个人都拥有自然进化而来的各种“欲望”，而现代社会就是设立各种法规，用于和这些“欲望”来“对抗”或“引导”。

“个人倾向”和“欲望”一样，也是需要“对抗”或“引导”的。而最理想的情况还是要PM来解决，因为PM可以在多人利益不一致时进行协调，并且站在团队的角度去思考应该做哪些事情。所以PM对开发者做事的掌控度越高，这一问题影响就越小。

不过，就算没有PM来影响，我注意到很多人也并不一定完全按照自己的倾向去做事情。这可能来自于 “他人的舆论压力”，比如有一项事情你很不想做，但是他已经影响了太多其他人的工作了，这时你很难继续对其视而不见。另外，很多人也因为 “责任感” 去做那些自己本不想去做，但是对他人或团队很重要的事情。