本文来源于:https://yq.aliyun.com/articles/14578?spm=5176.100238.yqhn2.14.Lcie4Y
摘要今年整体带了几个项目。我本人不是专业的PMP培训出身,落文的目的主要是为了把所积累的一点点经验分享给大家,所以项目管理的术语和措辞上的不专业,希望大家谅解。 其中一个项目落地非常快,质量和效果产生也非常快的一个项目,落地到产生效果就一个月,所有项目成员都不是全职做这个项目,受到研究...
今年整体带了几个项目。我本人不是专业的PMP培训出身,落文的目的主要是为了把所积累的一点点经验分享给大家,所以项目管理的术语和措辞上的不专业,希望大家谅解。
其中一个项目落地非常快,质量和效果产生也非常快的一个项目,落地到产生效果就一个月,所有项目成员都不是全职做这个项目,受到研究员高度认可并取得对应成果的项目。
另一个项目历经小半年,横跨多个部门,最终取得了所有主链路全部达到秒开的水平,并被开发部申请了技术部牛气冲天奖的项目。
第三个是无线测试发声最多,体现最专业的一个项目,在项目的整体流程推进上,风险把控上,需求控制上,测试方都付出了不少的努力,运营和PD方纷纷回复邮件给测试团队点赞。
下面我就从自身的角度来讲讲我带项目考虑的几个方面:
一、整体规划
1.1需求管理
整体规划里,我比较关注的是需求列表和时间节点2个部分,首先将需求分类,大致分为强风险性需求、强需求性需求、普通需求、可删减性需求几个部分,如果非要划一个优先级,按照我的理念我会关注强需求性需求>强风险性需求>普通需求>可删减性需求。强需求性需求这种需求可能是导致本次版本更新的核心诉求,这种需求资源优先保证,所有风险性问题优先考虑,保证强需求性需求能够上线,这里不考虑强需求性需求不满足时间排期的情况。然后是强风险性需求,这种需求需要提前去沟通了解风险点,并且提前准备好备案,强风险性需求面临着可能多部门合作,进度问题,或者技术难点问题,时间问题等,分析出强风险性需求的瓶颈点,线下单独沟通,并准备好预案,如果该类需求在最后的节点仍然不能够达到我所期望的目标,那么因为我已及时沟通到各合作方,各合作方也有心里的预期和准备就更好容易处理一些,可删减性需求,这类需求可以按照当前的计划,时间,资源等条件因素选择性的提取,如果资源等情况充沛和全部接过来,否则最好在立项阶段就要对需求进行合理删减,不要出现当初承诺完成需求,在项目快结束时才周知相关利益人此需求无法完成的情况,这点对于其他人来讲是相当的讨厌的。
1.2时间节点
关注时间节点的原因是,当前阿里的大部分项目都是倒推的,每一个部分在什么时间完成都是有时间标准并且是可衡量的,例如需求沟通,PRD产出,视觉&交互的产出,开发开始时间与结束时间,项目提测时间,项目测试完成时间,项目灰度时间,项目小渠道发布时间,项目全渠道发布时间,在一个项目里,大部分的时间节点,在项目开始计划的时候就已经产出了,作为PM需要管理时间节点的风险,要经常和主要的责任人沟通相关项目的进度,不紧张的时候各合作方发周报通报内容,紧张的时候各合作方发日报通报内容,甚至当前沟通,建立项目的多种沟通方式,例如项目1推进每周一次的碰头会议,邮件组,旺旺群,钉钉,周报,日报等。PM不能想着到时间节点就要东西就好了,这不是一个好的PM,一个合格的PM应该时刻的关注每个节点的进度,质量,风险等情况,尤其是快到接近每个节点产出的时候,如果时间上发现已经delay,那么应该和相关的业务方沟通提高进度产出,加班等手段,把节点的产出和敏捷项目的管理相配合,这样就可以尽量保证每个时间节点都达到项目计划的规划目标。
二、沟通
2.1 人与人的沟通
人与人的沟通就是P2P,单点对单点,这种沟通的内容一定是该内容仅涉猎你们2个人的,例如某一个问题一直挂在某一个人上长期没有解决掉,作为PM要了解情况进行沟通,沟通的时候多从对方角度考虑问题,多从共赢的角度上考虑问题,不能说你作为PM你有这个权利怎么怎么样,这种沟通一般都对在对方心里产生抵制的效果,了解到可能是因为该责任人被安排了其他任务,还是说这个问题有难度不好解决,还是说人家准备要离职了,把影响项目进度的节点问题解决掉,沟通时可以先采取先邮件沟通,再旺旺沟通,最后当面沟通的方式,一般的阿里人到达第二步旺旺沟通的层次基本都会有响应了,如果旺旺都不行,那你一定要当面去沟通,不要怕,有的PM就不知道如何当面进行沟通,当面沟通预约好时间,不要先入为主,先把问题提出来,看看对方怎么说,然后你根据了解的情况再去有策略性的推进这个事情,前几步也都没有,直接当面质问,这个问题怎么还不解决,这个时候我都想骂他,我手里有更重要的事情好不好,你过来嘚瑟个屁来着。当然如果这个事情非常非常紧急,P1故障,那直接去找好了,这种问题没什么顾忌其他人感受的了,影响到我们的线上用户那是一等一的大事,还要什么面子。
2.2 合作方的沟通
与合作方的沟通,一定要让对方的leader知道并了解支持此事,这一点尤为重要,即使对方leader没有时间,那么也需要在旺旺或者邮件内抄送一下,避免最后因为各种理由,这个项目支持到中间半途而废了,再临时叫老大的老大的老大从上到下来压这件事情,按照我的话来说,就是这事办的不够漂亮了。对方老大知晓同意这件事,那么需要拟定合作方需要沟通的接口人,对方的团队毕竟是对方更熟悉,也更能说的上话,你在人家团队里,碧池碧池的说100句,可能不如人家在内部团队里嘻嘻哈哈的一句话,项目合作推进的事情一定要交付给接口人做,你作为PM不能把合作方团队也一并管理了,再说,真正项目做起来后,你也没有那份时间和精力的,定好接口人,这个接口人一定能把有效的信息传达到团队内,并落地执行,这样的接口人才是有效的,不要随便指定一个,哦,张三,你是接口人,结果张三自己在团队里什么都落实不掉,最后你说是张三的责任,还是你的责任,你俩都有责任,但最主要的可能还是你的责任,知人善任,作为PM,运营团队、PD团队、开发团队、测试团队,哪个团队都有哪些人非常适合做PM接口人,或者自己团队的PM,你至少平时工作中要多和合作团队了解,即使你不了解的团队,也最好侧面打听打听,要人的时候直接要指定的负责人,那办事效率杠杠的,沟通起来相当的丝滑,再提醒一点,与合作方的沟通一定要有礼有理有句有据,意思是一定要有礼貌要尊敬人家尊重人家的意见,你说的话一定要有道理,有理由能站得注脚,能经得起推敲,有句你说的话一定要清晰易懂有逻辑有重点,有据你说话一定要有根据,有事实,有数据,让合作方得知道你这个人要办的事情靠谱,人家才会非常愿意和你合作干项目,要不然背后说不定指着你脊梁骨骂,靠,什么鸟人,这个项目一点前景都看不到。
2.3 自己团队的沟通
自己的团队就是亲人,是最亲最亲的人,能自己上的,都不会让自己团队的人顶,所以项目的任何风险或者进度情况等对自己的团队就是实话实说,提前帮自己的团队多考虑一些事情,善意的提醒他们一些注意的事情,关键的节点等等,今天可能你是PM,明天可能就是别人就是PM,能把自己的经验传递给大家的就share给大家,多从团队方面考虑问题,也需要帮助其他人从团队的角度考虑所有事情,而不是个人角度,因为不管是项目,还是任务,没有任何一件事是属于指定的某个人的,你可以任何时候离职撂挑子不管,所以不管是自己团队还是别人团队,大家一起能参与这件事,一起做这个项目,你心里就要报有感激的心态,多去赞美别人,即使别人做错了,做的不好,也要懂得如何婉转的提醒给他,让他有面子的同时达到项目的目的,也许就是我的做人之道吧。每个人管理项目的手段都是不同的,人的不同就会导致风格的不同。
三、专业
什么是专业,就是把自己份内的事情做到极致,我认为这就是专业,一个PD需求写不好,一个运营页面都不会搭建,一个测试连Bug都不会跟踪不会提,这可能都是不专业的体现。在项目中,你是PM,或者你是其他角色都必须要做到够专业,测试的PM就要整体把控测试的进度,提测时间点,业务的风险点,测试完成时间,业务上线时间,把该暴漏的问题要尽早的暴露出来,很多测试PM总是怕得罪人,问题暴露出来了,这个问题是某某个团队的,某某个人的,人家会不会觉得我事多,记恨我,以后是不是合作上就有问题了,其实我觉得如果这个问题藏着掖着上线了,最后被爆出个P1\P2故障出来,我想人家更会记恨你,提前发的预警信息,风险邮件,加班邮件如果能把问题暴露出来,大家都应该感谢你的,测试PM都是从整个项目的质量上来考虑整个项目的,大家应该都能理解,你是测试PM,你要对这些事情负责,项目的周报定时的发送,让整个大促合作方都知晓测试的进度,项目时间紧时,要把风险性的问题及时发送邮件或者旺旺消息,让大促的总PM知晓,不暴露出来解决掉问题,就意味着时间不够用,要带bug上线,这种事情是必须全部周知才可以,否则凭什么你让业务带问题上线,是我,我这东北人的性情我就不爽。
专业的人做专业的事情,PM同学管理好项目的人与人的关系,业务的进度,风险,时间点等等,消息传达和沟通要尽量协调好,做一件事情要多考虑一分钟,想想是不是遗漏了什么,让大家都觉得很顺,很爽,下次做项目还愿意跟着你干,这不仅仅是项目的成功,也是你的成功,每个人身上都被其他人贴上了不同的标签,而你自己就是你的品牌。
四、回馈
什么是回馈,按照我的想法,就是付出就必然有回报,虽然大家做项目不是给你做的,说白了你也是给公司做的,那么作为PM这件事情的带头人,你有理由,有责任给与参与项目的人给予感谢,请大家吃个饭,来个下午茶,为大家申请加班倒休,为大家申请酒店住宿等加班条件,这都是PM需要考虑的事情,我又想抱怨一下,看过很多项目,做完了就做完了,作为PM连封感谢的邮件都没有,心里真是不爽啊,中国这个社会还是一个人际关系的社会,认识你喜欢你的,你没说话,事就给你办了,不认识你的不鸟的你,你天天求着人家,人家都不愿意给你办事,这事情就是这么个事情,我觉得非常简单,但是还是发现有很多人不是很明白这个道理,一定要多赞美人家,不要害臊,当面赞美,例如:这个模块,做的很牛,Bug非常少。给与开发同学实力上的肯定。这个需求写的非常清晰,我一看就懂了,多谢多谢,给与PD赞美,人家从内心上肯定你,后面还会坚持这么做,否则,今天我写的很好你不吱声,明天我写的不好你也不吱声,好,那下次我不写了,省事谁不会呢?
这个回馈方式有很多种,有大有小,你要变通着来,这样大家才原因跟着你干这个项目吧,否则要是我,我都觉得这个PM脑子是木头的....
总结:最后我想说,其实我嘚吧嘚吧这么多,也没有把自己所有的体验全嘚吧出来,也没有把项目的整体流程啊,目标啊什么的给大家说一遍,那是因为我觉得处在什么环境下,哪个所谓的流程啊,目标啊,标准啊什么的,都不是一成不变的,作为PM要考虑当前的环境,以前项目的方式等等因素和大家好好配合,有句话怎么说来着,树是死的人是活的,我觉得作为PM能够变通着做事情,让各位尽可能的满意,对项目满意,对你满意,对结果满意,又达到了项目的目标就“齐活”了。
时间: 2024-10-07 22:42:05