快好知 kuaihz

作为产品负责人,我是这么管理团队的

笔者从传统项目经理转型互联网产品经理,在工作中总结了一套自己的管理团队、推动项目的方法原则,和大家一起分享。

笔者年轻时候是做传统项目经理出身的,那时候管小型团队,每天开会讨论业务细节,督促大家交日报、周报,像个监工一样,受累还不讨好……

随着时间推移进入互联网圈子,有了一个高大上的名字:产品经理,想着以后终于不用和进度和风险管控打交道了。没想到来新公司后因为创业团队人少,不得不肩负产品和项目双重负责人的重任,想重新拿起项目经理那套办法。

却发现现在做项目管理可不比当年,当年的员工都是80后的同龄人,都是受父母言传身教,对工作压力和制度都比较默许,但是现在带的都是90甚至95后,个性十足,一言不合就敢辞职撂挑子,如果还按方抓药那最后肯定是两败俱伤,但如何既能提高效率又能保持团队的士气?

笔者总结了以下若干敏捷项目管理经验:

不要教条,不要刻意的模仿

做产品也好、做技术也好,如果只能模仿,不能创新、不能升华都是死路一条。

项目管理也是,不能因为别人公司敏捷了,而让自己也学着去敏捷,肯定是因为项目有这样那样的问题,才需要敏捷开发模式的。

敏捷模式较传统模式的区别就是:敏捷像是水,项目哪里有坑就补哪里,去适应去弥补;也像是圣经的教义,不同的国家(企业)可以按照自己对教义的理解,创造出自己独有的宗教(敏捷管理方法)。

所以最好的就是结合自己公司,或者更小一些,根据自己团队的特点来定制自己的敏捷管理流程。比如我们公司位置比较偏远,如果沿用晨会站会方式,每天都会让大家非常奔波,所以我们把站会改成了午会,中午12点开始,开完吃饭,这样因为吃饭的刚需,让大家也不会站着一说就说太久。

不做司机,做教练

以前我经历过监工、独裁者、团队救火队员等多种项目管理者的身份,无论哪种都不是最好的选择,要么不讨好,要么累的要死。

最后,我发现如果真要成为敏捷团队,一定是要尽可能把每个人的潜能最大限度的发挥出来,才能称作敏捷团队

一个有战斗力的团队,一定是狮子带着狼,而不是狼带着一群咩咩叫的羊群。后者数量再多也没有战斗力,所以你更像是一个驾校教练,你只是坐在副驾的位置,确保车还能前进。

平时你只是观察,对于团队中的工作内容和边界随时调整,对于队员的不足就引导他针对性的补足,对于团队内的不和谐因素或者负面情绪要及时发现和处理,保证团队这部机器能自己运转,让队员在自己本职上精英化,并且切分边界的信息,明确权责的归属。如果需要你的时候偶尔救救火,但不要常态化。

慎重对待加班

也不知道从什么时候开始,互联网公司都被打上了996的标签,冷静地想想自己也是从互联网公司出来的,深知加班是一把双刃剑。

虽然短期内感觉上是提升了开发效率,但是是在牺牲团队士气的基础上的,而且每天晚上吃完饭回来大都是休息一会,然后溜溜号,真正干活的效率一点都不高,就是为了凑时间好到点打车走人。

所以在吸取了以往经验后,我们在双周迭代中,根据目标完成的情况,动态地决定是否加班(其实我也是后来接触OKR之后才发觉,其实跟我们现在做的大体差不多嘛)。双周过半时,在周五晚上组织一个传统的项目进度评估会,会上就是过测试用例和云效上开发任务的开发进度,如果这周未能完成一个阶段目标,就组织周末加班,一般这时候让大家加班还是比较能被接受的,毕竟有理有据。

建立完善的闭环的开发流程,调动大家的积极性

以前团队人少只有前后端开发人员,为了提升效率,我们完全把测试工作给了用户,还好是企业内部使用,有点怨言但是也没法爆发。等后来测试到位后,开始建立测试用例先行的制度,在开发初始就把要测试的内容细化出来,而细致的程度要能让产品和技术刮目相看,往后我每天就是看测试发的日报,根据测试就能知道项目进行的进度大概情况。

多使用互联网工具来管理团队

工欲善其事必先利其器。

作为互联网人,如果你还在用excel和word来管理团队和日报,那显然有点说不过去。我们现在原型通过墨刀,敏捷迭代以及任务管理通过阿里云的云效,并和钉钉打通,所有bug和Exception都可以自动发送到指定人的钉钉上,文件管理用石墨,接口和测试用例使用yapi,基本上所有原来线下管理的方式,都搬到了互联网上,充分体现互联网公司的特性。

善于总结,善于变化

每个双周迭代后,固定会启动项目总结会,总结会也不会拘泥于客套的寒暄,而是让每个人一张纸条,总结这两周迭代过程中他自己认为最好的,和最不好的三件事,匿名扔到桶里。大家集体唱票,并根据优先级一起找出对于最棘手问题的解决方案(当然因为人少,这个工作一直是我自己来担当)。

时刻把握核心流程开发

在产品开发过程中很有可能会收到来自老板,来自同事或者用户的各种需求,这时候作为产品经理也好,项目经理也好,一定要保持定力,脑子里一定要清楚什么才是主线核心业务流程,任何需求可以接受,但是优先级一定是你来确定,不能谁说一句着急就乱了方向。

多组织一些活动

比如知识分享、午餐,甚至电影分享会,在不忙的时候我们都会组织一些分享会,比如《敏捷团队》《学习力》。

甚至当新员工入职后,会让前端、测试轮流负责给新同学培训业务。一方面让他们加深对业务的理解,一方面也是锻炼一下演讲力。即使是周六加班,我们也会组织一个电影分享会,让大家在周六中午边吃饭边看会电影,降低周六加班的疲劳度也增进团队的凝聚力。

上周参加一个培训,老师还介绍了一种分享方式,就是谁也不说,看网上培训视频听别人说,大家来点评和讨论,也是一种不错的选择。

对队员多鼓励,不要当面批评

现在的90后不比80后,没有房贷和孩子的困扰,所以也不会有什么顾虑,经常一言不合就拜拜了(我就遇到了两个,最短的一周就走人了)。

所以在遇到问题时,一定要先鼓励和肯定,然后转折一下再把话题引到待提高的方向上去说,大会上一定是多表扬、多夸奖,如果有些问题必须要当面说,也尽量不要直接把人家众目睽睽下叫出屋,而是搞成定期的沟通会,与每个人保持定期沟通,在沟通过程中开诚布公的说出自己的看法,避免误会。

最后分享一个这我心目中的完美团队,虽然遥不可及,但是至少目标在那。

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:负责人  负责人词条  作为  作为词条  团队  团队词条  这么  这么词条  管理  管理词条  
产品

 「Google 医学界社区」产品...

这是本人在两年前,初入产品岗时面试一家健康医疗公司产品专员岗位,撰写的一篇作文文章。一.目标『医社区』的理想,建立一个医学界的Google,用户在一个屏幕中,便...(展开)

产品

 互金行业:你需要了解的基础知识

本文适合想转行互金产品的小白同学可以参考学习的知识,本人刚入行互金产品,如有错误望大家指出。未来随着学习会陆续补充。一、图流自己第一天做互金产品的时候理的一个脑...(展开)

产品

 Android适配的那些P事

声明:本文从设计角度说明设计稿及倍图适配问题,不含前端技术,码农慎入首先我们看看百度搜索引擎上常见的认识入手:图1:屏幕分辨率和常见屏幕密度关系我们知道屏幕密度...(展开)