今天终于把最近出现的“技术问题”处理了差不多了，估计老婆再也不说我晚上睡觉说梦话都是这方面内容了。事业线领导投诉了技术团队，让团队气氛有点紧张，业务人员感觉在前方因为产品体验不好推动受阻，技术团队认为如果有问题应该沟通而不是投诉。更何况开会讨论后，其实真正的技术问题不到两成，大部分还是职责不清晰，协作沟通的问题。
技术经常成为“背锅侠”，这是经常性的事情，我想起三年前和今天相似的一幕，我也不会忘刚参加工作做内部信息支持时业务部门对我们的指责，更让我感到可笑的是当年动车出事故时最终的原因是程序员写错了代码。为什么技术那么“悲催”呢？因为不管是外部项目还是内部服务，技术方永远都是乙方，苦逼的乙方，你怨谁呢？在一个互联网的产品团队里，技术也往往是成本部门而非利润部门，不批你批谁呢？
所以，要想不成为“背锅侠”，就要想着不要出问题（呵呵，没有一点问题也许真是大问题）！怎么才能少出问题呢？作为技术团队来说：
1、技术能力很重要！
这里的技术能力不仅仅是有一两个出色的技术人员，而是整体的技术能力。很多问题往往都出现在团队中能力最差的那个人身上，这就是木桶效益。所以一个优秀的技术团队总是通过自己积累的技术体系来弥补人员的能力差异。特别在一个产品团队，积累非常重要，因为我们所做的不是一个短周期的项目，而是一个不断迭代的长周期产品，积累的越充分，效率越高、成本越低、质量越好！
2、重构是一项贯穿始终的工程！
重构（Refactoring）就是通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。我们因为时间、资源以及人员能力差异、变更造成代码或者软件设计的不够优秀，或者隐藏着问题。不能等到出现问题才想起重构，也更不要等到架构不适应时才想起重构，重构就是日常的一项工程，需要不断的重复它，重构是一种未雨绸缪的行动！
3、具备产品思维和用户思维！
这点非常非常重要，也不是因为我是技术转向产品才这么说。技术最终的价值不是说你写了多少的代码，而是自己开发的东西能很好的被应用。所以站在产品的角度来思考，站在服务用户的角度来思考，体验好不好，如果我是用户我会喜欢吗？所以有时候一定要跳出技术思维的框框，更上一层的去看待自己所做的东西。
4、乐于沟通，善于沟通！
对于大部分技术人员来说，总是很木纳，不善言谈。而且做技术的，说话做事都直来直去，不善于包装，经常说话得罪人。我作为技术出身的人就存在这样的问题，有时候无法控制自己的情绪，说话直接，没眼力价！这很正常，但是需要不断的加强，要乐于沟通，善于去沟通。就像这次事件一样，有些问题其实就是因为技术私自改进了产品而没和产品经理沟通，有时候就好心可能办了坏事。做技术的人虽然不会四面玲珑，八面来风（这样的技术人员也不敢要），但是要善于去表达自己的意见，去沟通问题。
5、摆脱那颗玻璃心！
技术人员都是比较内秀的人，虽然可以熬夜加班，可以通宵达旦，但是大部分都是一颗玻璃心，非常的脆弱。就像这次，一次非正常沟通，让我也控制不了情绪，有人更是想要对簿公堂。去年有一次因为一个方案沟通的失误，我批评了一下我们的技术负责人，可能因为自尊心受到伤害，导致技术负责人离职。我到现在还特别内疚，所以从此和技术沟通总是小心翼翼，生怕伤害了他们。但是从技术人员角度，我们不仅仅能承受身体疲惫，更要能承受心理的压力，多理解别人，多一些包容，这有利于我们自我的发展。
不管是对外做项目还是内部做产品，甲方和乙方，需求方和支持方都是希望能把东西做好，所以双方最重要的是保持良好的协作关系，共同去面对问题和解决问题，才是我们真正正确的做事方式。所以站在技术的角度上，我想给需求方，特别是互联网公司内的需求方提一些建议：
1、熟悉产品团队的沟通渠道
首先我们要清楚产品开发过程所涉及的岗位有哪些？产品经理、产品设计、交互设计、项目经理、前端开发、后端开发、架构师、技术经理、测试、运维工程师等等，每个团队根据规模所存在的岗位是有差别的，根据业务性质这些岗位所处的组织架构也是不同的。有的会把产品和技术全放到研发中心，有些产品部和技术部分开，有些产品人员跟着产品线，有些大点的团队技术也是跟着产品线。现在大部分团队都采用敏捷的迭代开发，只是迭代周期不同，敏捷程度不同。所以当出现问题时，我们能清晰的知道是谁的问题，问题的严重程度，当前的版本规划是否包含此问题等。如果一个互联网团队的前端业务人员这些都区分不了，那最好沟通一下补补课，这样更便于协作。实在不知道该找谁，很简单，找产品经理。大多数的产品团队，都实行产品经理负责制，由他作为统一的沟通后负责前后协调。为了更好的沟通、跟踪和责任划分，大部分产品团队都会参与协作工具来管理，所以这些问题最好要在这些工具上体现出来，否则口头交代的问题，真的很难跟踪并且划分责任。沟通建议是多方沟通，两个人沟通不清容易扯皮。比如我们用tita，我们不仅仅可以把任务指定负责人，还能引进相关人。当问题很多很杂，最好开会沟通，分析问题在哪，寻求解决方法。像这次问题出现后，一个会议全部搞定，技术的解决技术的，产品的解决产品的，设计的解决设计的，如果一开始就开一个小会，大家都愉快的解决问题了，也不至于全部让技术背锅挨批，蒙冤受屈！
2、资源不足的情况下懂得取舍
做过项目管理的人对这张图肯定不会陌生，项目范围一定的基础上，成本、时间和质量是三角关系，最多只能正向改变两个，所以这就需要平衡。不可能又想消减成本，还想缩短时间，还得保证质量，这是没法实现的。只能根据实际情况保证两个，除非改变范围，增加资源或者消减需求。所以处在项目中的各类人，大家都要懂得去平衡，如果各自都为了自己的利益去索取，必然会陷入混战的状态。对于产品开发管理更应该掌握平衡，为了保证业务推进，很多时候不是去争取，而是去放弃。前几天听的SFE的培训，其核心思想也是在资源不足的情况下，如何做市场细分，客户细分，什么都想做是不可能的，有舍才有得。
技术人员直接、不圆滑、不隐藏、有啥说啥在一定阶段是好的品质，但踩得坑多了自己还是要注意解决问题的方式。我自己做了接近十年的技术，也做了几年的产品，其实做这两件事的确是很有意思的事情，做技术可以让人专注，做产品可以让人全面，虽然也经常碰到一些着急上火的事情，处理起来不够成熟，但是我们既然选择了爱这个职业，就不能因为碰点小困难，踩点小坑就灰心伤气，把问题当成磨练自己的工具，完善自己，早日摆脱“背锅侠”！
