|
|
文/猴与花果山
为什么别人4个人2个月做出的产品，我们40个人20个月都做不出来？在实际的项目研发中，会有很多因素导致研发效率极度低下，这些问题通常可以归纳为一些团队的恶性习惯，作为一个团队的经营者，最重要的事情就是发现和及时改变这些团队恶习。习惯是无法消除的，但是可以被改变（Routing可以被替换）。
影响团队研发效率的恶习
爱分上下级，爱开小会
没几个人的团队，上下级分的可能比BAT都细。除了分级之外还喜欢动不动这几个人关起门开个会，过一会又找那几个关起门开会。这会带来人与人之间的距离感，距离感带来参与感的淡化，很多“低下”的人会失去自主能力，他们会逐渐认为自己是“为别人打工”，而不是在“为自己的前途而奋斗”。
工作耦合度高，互相依赖性强
这其实可以看做是一个技术问题，在安排和执行工作的时候，通常是一条线下去的，能分为多个线程同时进行的工作，非要做成单线程前后依赖的工作。最常见的就是有些人在等另一些人开发，比如策划写完一个策划案，就等程序去开发初步功能，等程序开发了一定阶段了，程序又需要测试数据了，策划再去填写一些测试数据，程序拿到测试数据才能继续工作……而本来这个过程可以是同步的，开始的时候约定数据结构，程序用约定的数据结构先行开发（自己填充假数据），策划则根据约定数据结构设计表结构和制作表转化为数据的工具，并填写数据，双方同时进行。
固步自封，敝帚自珍
喜欢用一套自以为成熟的代码反复开发（换皮），完全拒绝第三方，并认为自己写过的代码、踩过的坑就是积累（注：经验并不是积累，积累是你在这个项目做过的实体东西到任何项目都可以用）；喜欢使用一些自己习惯的软件，而不是用更符合需求的工具（如使用SVN而不用Git管理代码）；喜欢做一些事情看起来是走了捷径（建数据结构的时候不考虑逻辑依赖性，以“能解决眼下问题”为唯一目标），但悲剧的是一旦遭遇需求变化就变走远路了。其实这些行为往往是在画地为牢，而不是“项目积累”。最后逐渐发现自己能做的东西越来越少，而表的列数越来越多，程序能实现的功能越来越跟不上需求，而为此新增的代码越来越没有章法，最后无法维护。
部门感强烈
说穿了这还是一种没有把项目当做自己的事情来做的习惯，“这是策划设计问题”，“程序实现不了”等等话语，常常就是问题所在。“分工明确”通常看起来都没有问题，只要没有挑战发生，就不会面临事故。很多传统行业的工作套路已经趋于成熟，有了完整的经验来应对挑战发生，因此可以很好地采用“分工明确”的方式，但是游戏开发中，还是应该尽可能避免这种分工明确的问题。解决问题，把游戏做出来，这才是唯一的目标，不要让分工变成项目开发的累赘。更有一些实力不咋的的公司中，有能力“跨职能”的人得不到发挥，做了策划，即使曾经是顶尖的程序员也不能碰代码，何况还是Java的代码……因为“公司认为你不会写代码”，呵呵。
自我表现欲突出的人上位
这在很多企业文化含有“老员工=元老=核心员工”概念的企业特别常见，一些员工到了一定年限之后就被委以重任，出现在核心工作岗位上，公司绝对没有“尸位素餐”的设定。这对于老员工来说可能算是一种福利，可是并不是老员工就一定有能力胜任的。通常一些老员工会带来一些闭塞，使得其他员工上进心受阻，而同时产生的并发症会表现的更加明显——老员工看不得别人比自己强，尤其是同岗位的；或者容不得别人谈论自己技术范围的事情，尤其是不同岗位的人谈论。相比项目能做成，这些老员工更在意自己的表现，和自己在公司的地位。最后的结果就是他们自己个人膨胀，并导致团队严重缺乏交流，新的有能力的人即使进到团队来也没有发挥的余地。
缺乏积极交流性
这通常是之前几项恶习导致的一个延伸恶习，在一个乌烟瘴气的团队里，没有人乐意主动和别人交流，都安分守己做好自己，每个人都生活在罗生门中。有能力的新人因为资格不够得不到重用，愿意做好项目的人逐渐被磨掉积极性。
如何从“我”做起改变这些恶习？
没有小会（财务问题除外）
在项目过程中不再开小会，需要小范围讨论的，大家围坐在一起，在办公室内（或者相对透明的会议室）商量解决（至少进入会议室的时候，大家都知道这群人进去讨论啥）。需要大范围讨论的问题，大家一起开会解决。所有的信息（财务除外）对所有人透明，让每一个人都掌握项目的第一手信息。
学会分析而不是解释
很多时候沟通的最大障碍就是解释，在发生一些分歧，或者听到一些声音的时候，我们第一时间不去解释自己的理解和想法，即使自己认为已经想清楚了对方在说什么。学会分析对方的真实需求，并把他分析给对方听，让对方知道自己理解了他的意思，然后进一步分析得出结论。多听，而非多说，多分析，而非多解释。解释在很多环境下更像是反驳，更多的反驳就会带来更少的交流。
在交流群里给每个人的提议以反馈
在一些交流群（如QQ、RTX）中，尽可能给每一个发表意见的人反馈，哪怕只是一个翘起大拇指的表情，但不要不理不睬。养成习惯让更多的人关注到群的讨论，给出更多的反馈，甚至一些重要的事情可以立即转化为群体会议来讨论解决，让人有信心在交流群里发表看法的基础就是有（正面）反馈（正面反馈未必是对他的观点的支持，而是给于一种答复，比如分析对方要说的真正需求）。
和任何人讨论任何问题（财务问题除外）
不要在意跟你提技术意见的人是不是程序员，也不要在意那个给你勾出线框的人是不是一个美术，只要有人发起讨论，就应该接受“挑战”积极响应，不错过任何好的意见，我们希望团队的每一个人都是全栈式的，所以不该因为职位就直接否决了一些意见，也不该因为想法和自己不同（有时候是认同的想法没有出自自己之口）就给于压迫。
学会重构
不仅仅是重构代码，还有重构需求等，我们不能因为曾经做过解决过类似的问题，就认为那是唯一的解决方法，并且危险的去做类比，把看起来差不多的问题当做同一个问题（锤子钉子原理）。深入思考、抽象真正的需求之后进行调整。思考一个问题——让角色移动的功能，moveCharacter(tween,action,speed)真的是最好的抽象吗？那么用它能移动一个UI控件吗？
当一个团队逐渐变得Open之后，你会发现自己还有很多东西要学，而最重要的收获是，你发现项目的研发中很多耦合性的工作被解耦了，并且一些原本很头疼的问题，出现了很多自己想不到的解决思路。好的习惯，是一个团队高效开发的基础。
|
|
发表于 2017-1-23 17:11:59
发表于 2017-1-24 10:23:59