今年年初进入了乐信。为了能证明自己，在今年为可以说，做了不少的努力。但是效果并不太好，甚至怀疑同事的能力。
如果今后还是这样的状态的话，继续留下去的意义就不大了。这几天工作不忙，也静下来看看同事的表现，发现还是有很多可圈可点的。
比如，部门内负责另一条独立线任务的团队，就感觉做的是事情就非常的高效，而且效果也不错。
为对他们的理解，首先团队每位成员的表现并不突出(应该说没有个人英雄主义)，但是团队成员在做自己的事情时，能够保证做自己的事情时不会犯错误，即使发生错误时，也能够及时的反馈出来。
在核心问题上，大家都有自己的发言，进行讨论。这样问题首先大家都较为了解，在做事情的同时也会想办法兼顾。比如，一个系统最高效的开发方式是，通过小版本快速的迭代。先收集需求，规划哪些功能点比较重要，优先开发。等项目上线后，通过收集用户的需求，再次规划项目的优先级。而在各自的开发中，因为考虑后期版本的扩展问题，也会在代码中留出足够的扩展。
回顾本人。平时做事时，考虑的问题太多，导致每件事情都想兼顾，可是兼顾的效果都不太好。出现这样的问题，主要还是对项目团队的其他成员不够信任，每件事都想亲力亲为，也从中得罪不少人。我的这些行为，可以说在IT行业中还是很典型的，个人英雄主义。
项目是一个团队的事情，单打独斗做出来的东西，只能是毕业设计水平。
如何打造一支好的团队。
分工明确
首先，团队需要分工明确。分工明确不代表，自己只需要完成自己的任务，更不是主动帮别人完成任务，而应该是一种互相促进的过程。
项目前期产品经理已经收集到足够的需求后，需要对需求进行模块划分。然后通过数据分析、市场调研和团队讨论的方式，对需求进行优先级的讨论。
我觉得这个阶段非常的重要，首先，业务角度、产品角度和技术角度在面对同一个问题时，给出的理解和解决办法是不一样的。完全符合任何一方的要求，都是不可行的，所以在这个时候就需要各方通过讨论达成一致。同时这个过程也可以让各方了解彼此，为自己的未来规划设定方向。
等需求定下来后，就可以进行项目团队内对各项细节的讨论。讨论的内容应该囊括，UI设计、交互细节、技术细节和排期。
排期非常重要，这是保证项目正常开发的核心。根据排期，各自才能完成对自己的任务划分。
抛出问题
在完成期间，如果遇到问题要及时抛出来。如果是技术问题，可能有些自尊心比较强的程序员就不太愿意抛出来，认为这样是对自己技术威信的一种伤害。
应该鼓励开发人员及时抛出问题，这样才能及时解决问题。但是从管理的角度，就要注意平时面对问题的态度，比如成员在暴露问题后，直接问责，或者问责不清。好的团队的一定是成员把团队的事情当作自己的事情，能主动承担责任。问题发生时，即使责任明确也要先予之沟通，让其自身充分认识到问题的严重性。如果对方认知清晰，就需要进行鼓励，让其安心完成接下来的工作。记住追究责任，对完成任务没有任何帮助，认清责任相互促进才是解决问题的方式。
技术方案评定
技术方案非常的重要，这是日后项目正常运行和低成本维护到基础。
关于技术方案的问题，开发人员在开发时，如果遇到问题，千万要将问题抛出来，千万别自己使用一种非主流的方式去解决问题。这个对于日后的开发，绝对是灾难，而且不利于你个人的能力成长。
灰度测试
项目上线后，如果发生问题，可能收到是损失非常的严重。通过灰度测试，随机对一部分用户开放新功能，这样的测试才是充分的。
项目预备方案
项目预备方案，是对思维的一种挑战，因为大部分人只会想到正常的流程，而对异常情况却知之甚少。如果影响面可能非常大时，应该积极考虑这方面的问题，在事前就设定方案，将影响面降到最低。
及时解决问题
程序员一般都比较耿直，在出现问题时第一反应是从日志和代码中找到问题，然后解决。
但往往等问题定位到时，时间已经过去了，造成的影响已经非常严重了，所以在发生问题时，应该积极提出临时解决方案。寻求同事的帮助，比如，让一部分同事帮忙从架构和服务器的角度，设计解决方案。让一部分同事帮助你完成一些临时方案的实现。而你自己有足够的时间进行问题的正真定位。
充分尊重其他成员的意见
每个人的思维方式不同，关注点也不同，别人的意见你可以不认同，但是不能不听。同时自己在说明问题时，应该做到不要啰嗦，将问题通俗易懂的讲出来，或者就事论事，不要过于抽象。
定期会议
定期会议是提供一个大家反馈问题的途径，确保项目进度。
敏捷开发工具
一个合理的工具非常重要，可以大大降低团队成员的沟通成本。
网友评论