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