fundebug 2019-03-29
摘要: 如何提高团队战斗力
越来越能体会这句话「管理大部分时间都在沟通和协调」,一个项目涉及很多人,包括业务、产品、设计、后端开发、前端开发、测试等,他们对同一件事情的理解可能不同,过程中也会有各种问题,需要不断协调和沟通才能达成一致,如果还划分为不同的组,沟通和协调会更困难。
最近负责了2个大的需求开发,过程中遇到了很多问题,导致了项目延期,给别人和其他小组带来了不好的印象,有些是自己的问题,有些是他人的问题,为了能在以后项目中进行改善和避免,一并总结下。
我们组有一个同事,大家都觉得他技术很强,自己负责的任务也能不错的完成,但只关注别人提到的点,过程中遇到问题也不能很好的沟通,有很大的风险。
技术好不代表能力强,刚开始会把一些重要的事情交给你,但如果缺乏责任感,会辜负大家的信任,慢慢地脱离团队。
领导会把重要的事情交给他最信赖的人去做,他会很放心,也不会过问很多,时间到了,便会得到一份满意的答卷,这就是信任。
项目开发是一个团体行为,应站在团队整体利益的角度去考虑,对自己的任务负责任,对整个项目负责任,重视与他人的沟通和配合。
多做一点,多想一点,对项目负责任,会赢得大家的信任。
先说下我们现在的开发流程:
看似完整的流程,还是遇到了一些问题,好多人缺乏对整体功能的了解,一些细节做得也不到位。
产品需求文档太散,没有把功能串起来,大家理解起来有一定困难,如果一个文档需要大家反复揣摩才能理解,那是不合格的,会大大增加沟通成本。如果有一个视图,把功能按场景串起来,理解起来会容易很多,一些细节也能给产品正反馈。
原型、交互也不够细致,这样会导致每个人的理解不统一,甚至会缺少一些功能,影响的不光是后端开发,还有前端开发、测试,业务验收时也会反馈相关问题,大大增加了返工率和人力成本。
开发和测试也有问题,没有详细分析产品需求文档,慌慌忙忙去参加需求宣讲会,等于浪费大家时间,没有对功能点及实现进行详细分析,大致评估开发时间,会让进度一再延期,处处有风险。
关于需求文档、原型、交互,以后会时刻促进产品做的细致点、易理解一点。
关于需求宣讲,要提前通知到位,让每个人有足够时间去分析、梳理,更好地参与需求宣讲会,这点我做的不好。
关于功能分析和时间评估,我就不要自以为是了,交给开发负责人去评估,需要做的就是辅助他们分析,从整体上进行把控。
前期的重视和投入,会产生1+1>2的效果,减少沟通成本。
仅在线客服这一块,就有8-9个工程,还有很多其他依赖的服务,一个新需求可能涉及很多工程,而且部署了4套环境,要不断的处理线上反馈的问题。
目前仅有3个人来处理这些,最近这段时间,我开发的也少了,可想而知,任务的并行和突发会经常发生,要协调好。
真是辛苦他们了。
在评估工时时,需要考虑这些,可以按照比例大致评估下,预留一些buffer,免得项目不断延期。
这段时间,前端同事老是抱怨提供的接口无法走通整个流程,因为后端调用链条比较长,需要完成很多工作才能真正调通,这是我的失误,没有考虑到前、后端任务的依赖性。
一方面,可以让前端晚点介入,减少不必要的投入。
另一方面,可以给后端评估多点时间,先做一些伪接口,先让整个流程能够跑通,前后端各自开发,互不影响,这样后端开发也会更清晰。
无论哪种,要提前协调好。
题外话:接口一定要自己验证,特别是关联度大的接口,不要让前端帮你找问题。
项目管理中,进度把控也是比较难的,每个人的水平、想法、性格不同,过程中会穿插其他一些事情,有些实现效果也是未知的,所有这些因素,都会影响项目的整体进度。
针对重要项目或一些人,需要每天对下进度,把问题和风险尽早发现,如果进度特别紧,可以临时协调其他人加入开发。
对于我,要重视别人反馈的问题,不拖延,加强沟通和协调。
不要因为我的忽视影响整体进度。
如果涉及的工程比较多,评估工时时,要预留足够的联调时间,每个人开发各自的模块,有些问题可能在联调时才发现,需要时间去修改。
这点,我忽略了。