项目精打细算的三个月

0 评论 2450 浏览 3 收藏 13 分钟

在互联网行业的跌宕起伏中,项目管理和资源调配的艺术变得尤为关键。当一个紧急且规模庞大的项目突然降临,如何在有限的时间和资源下,实现项目的高效执行和成功交付,成为了许多团队面临的挑战。

干劲三分热,项目七分熟。

01

在魔幻的互联网行业里,有两个比较神奇的想不到定律,怕它来又怕它乱来,有时候又希望它来,摇摆的心态与自己所处环境息息相关。

裁员与泼天的需求。

在当前的环境下,公司内部有大把的悬浮人,处心积虑的等着N+1的裁员赔偿,也有些人在努力的实现各种预制或乱入的需求,把握当下的工作也可以降低不确定的裁员风险。

当然公司也不容易,十个客户走了六个,三个说没钱,一个打款在OA审批。

这样的趋势下,普遍的降本方式都是裁员,对于大部分企业来说增效的方式都一样。

单人多岗。

迫于大环境的压力,即使在单人多岗的模式下,业务和组织结构也可能逐步形成看似稳定的局面,身处这样的趋势里,打工人经常破防是主旋律。

当单人多岗和泼天的需求迎面相撞,那就是破大防。

2024上半年,公司忽然与某个大甲方谈下了某个项目的一期研发,产品还并不是双方擅长的业务,合同中约定的周期是三个月,如果产品一期可行性被验证,就可能有二期甚至是长期的合作。

甲乙双方厌恶风险的心理,已经若隐若现。

既然这个项目的甲乙双方都知道:在当前环境下,投入到不确定的事情中风险偏大,那为什么还要决定项目第一期的落地呢?两个主流因素:要么真的是在尝试找出路,要么就是人情世故推辞不了。

传闻这两年努力扑腾的,都已老实。

作为产品研发的乙方,在这三个月的项目周期中,见识到了公司精打细算的骚操作。

02

项目既然已经接下来了,也就只能先开始,再找路,然后就是不断的调整。

乱入的需求必然会对公司的业务和组织现状产生直接的影响,如果全部投入新业务的探索,面临的风险是可见的,后续一旦新业务停摆,带来的打击会伤筋动骨;如果不舍得投入新业务,等同于间接放弃一个难得的机会,同样是不可取的策略。

面对未知的前方,不可能真正的准备妥当。

所以在权衡利弊之下,合理的思路是:先保证现有业务的核心产品正常迭代,适当的降低迭代节奏,只优先处理核心业务需求;再调整部分资源到新项目上,在推进的过程中适当的招聘人员来确保整体的进度。

成年人的世界,少问保大保小,肯定是都要。

在项目合同签下之前,确定了执行的主基调,但是今天和明天会不会在同一个公司同一个项目中,可能老板自己都没把握,最近一年见过几家小作坊公司,先离职的居然是公司的负责人,所以在很多项目的执行上都需要把握一个心里预期。

走一步,看一步;此一时,彼一时。

从本就单人多岗的团队中划分近一半的人到新项目中,在项目逐步推进的过程中,按照实际情况去判断,如何进行人力资源的补齐,最理想的就是通过内推的形式找到项目制的人员,也可能走招聘签短期的劳动合同,当然也不排除与外包公司合作。

公司的生存现状,决定了是抓考勤还是抓项目。

03

都说万事开头难,实际上项目研发这个领域里,每个阶段都不容易,特别是在甲乙双方合作的项目形式上,如果落地的时候质量和周期拿捏不好,不仅买卖做不成,甚至还有对簿公堂的可能。

老板签下合同,团队做好人员安排,这已经算是梦幻的开始了。

执行层面就看产品研发团队了,老板有门路拿到项目,这算是开源操作,到落地阶段还得考虑节流问题,从项目角度看就是高质量短周期少投入的情况下完成交付。

通俗的说:明天能上线吗?

很显然明天上不了线,在产品研发的周期内想要做到降本增效,最大的操作空间在于合理的调度人力资源,理论上完成项目需要各个角色的协作,但是实际上并不是所有时间线上都需要这么多人力投入。

增效还有个默认的答案:加班。

项目落地的三个月周期内,常驻人员总共不超过十个,实际上到了最后阶段,还有队友的全名都记不清的现象。

【一】产品角色

大型的项目需要业务经验对口的产品经理,是通过野路子搭上线并且签的是项目制的合同,手里有现成的原型稿和文档,只需要与客户和项目组保持每周1-2天的见面沟通,将新需求统筹迭代即可,其它时间都是远程协作,处理细节问题和版本验收等。

【二】研发角色

项目初期安排两个资深前后端研发,以此确保技术角色对产品和业务有全面深入的理解,并且完成框架层面的基础设计和搭建,集成系统通用的功能模块,进入业务的大版本迭代前,再招聘2名经验相对较浅的研发,以此来实现业务版本的快速推进。

至于保障产品质量的测试,在项目的开发周期内全部由产品、项目经理、技术同学测试和修改,在项目最后的一个月从外包公司找测试系统性验收,保证产品交付的质量。

【三】项目角色

想要真正实现高效,有个资深的项目经理不可或缺,可以从各个方面把控节奏和进度,规划和协调人力资源进出有序,敏感的识别项目风险并提前制定解决策略,最终实现在周期内项目的高效迭代和交付。

见过一些老练的项目管理人员,不显山不露水平稳的推进项目节奏,团队虽然忙碌着但也一副岁月静好的感觉,换了个人,三个月都未必能缓一口气。

在项目周期内,虽然公司有明确的人员投入控制,但是对人员的经验和水平有要求,全程没有职场新人和小白的参与,并且核心的产品、项目、研发安排的都是资深且熟悉的人员,基本做到知根知底,这样才是确保高效率迭代的前提。

虽然团队的热情渐渐凉了,但是项目最后高低是熟了。

04

作为乙方,时间紧任务重并不是最闹的事情,如果摊上一个不好对接的甲方,不仅要看在眼里更会闹在心里;回头想想老板能拿到甲方资源,这妥妥的社会高端玩家,产品和项目经理可以游刃有余的搞定甲方,这当属天赋型选手了。

有的甲方光指点不够,还想亲自下场指指点点。

三个月周期的项目,必然是需要定期向客户汇报进度和演示产品的,在这个项目中是十天一次演示,参与人员是产品和项目经理以及甲乙双方的负责人,不要指望三个月周期一到,向甲方直接交付一个满意且完整的产品,如果对方预期落差太大,很有可能造成双方对线公堂的结果。

长周期产品开发需要将路径规划好,通常每周实现一个模块在节奏上比较和谐,先在团队内部完成验收,再向客户汇报展示,也可以让甲方明显的感知产品进度。

与甲方沟通不适合太频繁,否则容易把3-5个需求叠加到3-50个。

无论是产品还是研发或者其他的参与者,都很难准确的保证每个迭代的按时完成,在内部是每周一个迭代版本,向客户汇报是十天一次,给短周期的各个环节留有一定的缓冲空间就很有必要,如果有轻微延期的情况,也可以赶在汇报前集中资源处理。

不存在:版本提前完成的失误安排。

据项目经理说,每次向客户汇报的时候,都好像一场自我的修行,既要处心积虑表达项目的喜人进度,还要小心谨慎的描述产品功能迭代,还得敏锐的应付系统突然出现的异常,还要面对甲方对产品功能或者进度的突然发难,同时还要轻微的防守客户变更需求。

乙方的待收款,决定了做人做事的态度。

甲方的泼天需求不能直接拒绝,无理要求不能直接对线,如果给甲方客户的预期造成太大的落差,那甲方的打款进度可能永远走在OA审批的路上,甚至还有打折的可能。

如何应对需求的高开疯走?

据产品经理说,核心的功能设计是不会轻易改变的,如果客户需求提的太过抽象,那就从表面进行轻微的改造,如果客户需求在后续排期中,那就积极响应大操大办,向甲方大声反馈乙方的严谨态度和专业精神。

经验来看,很多逢场提的需求多数很难复现。

05

以项目的视角,观察产品研发的流程和周期,会对各个环节有新的理解,从时间质量成本三个要素去看,项目管理需要灵活多变的策略,任何一个因素发生变化也会导致其它因素发生倾斜。

动态平衡才是项目成功的关键。

三个月周期的项目,虽然公司层面在严格控制产品研发成本,但是人员投入算是精挑细选搭配妥当,在口头上对于质量的追求也表达的足够明显,至于时间这条红线是不能让步的,实现平衡的操作空间也就只能在成本和质量上来回操作,而且还要考虑给团队留下缓口气的余地。

最终在周期内完成研发和交付,并成功上线。

作者:半问 ,公众号:半问

本文由 @半问 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 目前还没评论,等你发挥!