/home/wwwroot/west263zx/public_html/zx/wp-content/themes/dux/single.php 产品开发到一半,你想改个设计,怎么办?-西部数码新闻资讯门户
新闻资讯门户
互联网、云计算领域最新资讯
首页 > 互联网

互联网产品开发到一半,你想改个设计,怎么办?

今天我们来聊一个尴尬的话题——改设计。

在工作中,很多PM都可能会遇到这样一种情况:产品的文档已经交付了,产品也已经在开发了。可是,你突然发现有个功能设计有一点问题,需要做一些改动,这时你该怎么办?

这种“雷”对于几乎各种级别的产品经理都会遇到过,或大或小地都会经历一次这种生不如死的过程,有时感觉研发工程师恨不得拿刀剁了自己,可是本着对产品负责的态度又不得不提出来。这种结果往往导致团队士气低下,关系变差,产品延期,PM信任危机,等等。

那遇到这种问题究竟有没有解决方案呢,或者说有没有应对的方法论呢?

我们今天就简单来聊一聊,产品开发到一半,用什么姿势来思考“改设计”这个事。

区分真老虎和纸老虎

事情往往来得很突然。可能是和别人沟通中,可能是给技术讲解产品时,可能是自己突然领悟到,也可能是在读某篇文章时,你突然意识到,“我设计的产品功能有问题。”

此时,你的内心应该是Bi了狗了。接下来,你的内心活动可能是这样的一条路径:

产品功能有问题 → 我得修改 → 我怎么搞定我的技术 → 我死定了

没错,你这样想就是死定了。因为这只是你的内心活动,而不是客观事实。

我们很多产品经理遇到问题时,都是自己把自己给吓死的。我们太容易把客观事实、迫切程度、迭代规划、内心感受、同伴关系等问题搅和在一起来考虑,你在做判断的时候就很痛苦,自以为事情很紧急很迫切,却不知道哪个是客观事实,哪个是你臆想出来的恐惧。

我们举一个例子:

比如某个数据产品经理,他在为一个新产品设计一个新的数据分析工具,大概有条件筛选、数据排序、数值计算、对比分析等一些基本工具,他在设计时考虑了数据分析的输入是什么,操作有哪些,输出有什么,从而设计出一个比较完整的数据分析工具,我们称之为v1.0。看来看去似乎并没有太大的问题,而且也比较简单,所以产品文档写好之后就交付了。突然某天,在和技术老大碰细节的时候,技术老大说,你怎么没考虑到数据如果太大处理不了怎么办?我们在流程上是不是要首先做数据过滤啊,不然数据存在数据库里,一口气几十万条数据都拿出来,岂不是乱套了!

这个问题真够唬人了,想想还真是个大麻烦事,如果一口气几十万条数据都被导出来,那岂不是把产品得搞挂了。看来得改设计了,可是开发已经进行到一半了,这怎么办?

此时最怕的是自乱阵脚。

这个产品经理需要好好分析一下,技术老大说的这种情况会在什么场景下出现。作为技术老大,他需要考虑的很多都是极端情况,这样才能确保产品在后续迭代中不会掉到坑里,他关心的并不是产品设计,而是技术设计。能够提出这样问题的技术老大是很有经验的,但另一方面也可能印证一件事,他提出来的问题并不是眼下最紧要的,可能是将来才会遇到的。

就拿这个例子来说,大量的数据过滤是建立在数据量已经足够大的基础上,对于一个新产品而言,如果忽略了这个功能,是不是致命,下一个版本能不能弥补,是在发现问题时需要立刻考虑的,这些就是我们前面提到的“客观事实”。这个功能缺失一定是个问题,但是不是要立刻修改又是另一个事情。

所以,产品经理千万要在问题出现的时候,把“客观事实”从所有复杂的信息里摘出来,认清楚这个客观事实是真老虎,还是眼下的纸老虎。

学会评估,是处理问题的第一步

当问题被抛出来的时候,立刻行动并不意味着立刻去改,而是立刻评估。

因为此时产品已经开发过半,返工和延期都是很影响研发进度的,而且还会影响到后续功能的设计。你需要学会评估一切因素,从而做出最合理的判断。

评估迫切程度:立马做,还是以后再做

如果这个修改是不得不改的,那么它才有返工的必要,否则就应该延后到下一个版本。

如何来判断迫切程度呢?我认为只有一点即可,这个功能如果不改,当前版本用户的使用是否会出现不可控制的断点和风险。

我们举个例子:

比如一个登录功能,如果是v1.0版本,你在设计的时候忘了加验证码。我们推演一下,因为是v1.0,可以假设此时的用户量并不大,大概也就多则几万,少则几千,此时即使没有验证码,也没有大问题,安全风险也相对较低。当版本迭代到v2.0,或者v3.0时,用户量已经比较大了,验证码就必须要有了,因为有安全风险。

再举一个例子,关于用户使用断点的例子:

比如一个聊天功能,如果在设计的时候,忘了设计本地缓存。此时我们再推演一下,如果是v1.0版本,用户数量不太大,每个人手里的聊天群平均下来都不太多,缓存的确可能会影响到一些网络不好的用户的体验,但是早期用户大多是奔着核心功能来的,缓存没有并不是最重要的断点,用户是可以勉强接受继续使用的,而且产品经理、运营是可以通过人力方式设法维系用户。但如果版本是v2.0,此时用户对于没有缓存的意见就比较大了,再不做缓存的话,聊天群如果比较多,则非常影响体验,立马形成了用户使用的断点,所以就很迫切。

所以,我们评估迫切程度是要和当前的版本相结合的,然后判断用户使用是否有断点和风险。根据经验,一般能够被评为迫切程度很高的修改是很少很少的,大部分功能都是可以延后再补救的。

评估研发难度:优化和分拆设计

如果很不凑巧,你就是赶上了一个被评估为迫切程度很高的设计改变,此时你要做的事不是立刻安排人去做,而是在完成新的设计之后,评估研发难度。

为什么要产品经理评估研发难度?这是为了帮助你更好地完成这次设计的修改。

我们一般在做产品设计的时候,第一个确定的方案往往不是最佳方案,这种方案会更多靠直觉推演。当我们深入到评估研发难度的时候,我们会发现最早的那个方案可能在研发难度上需要很长时间,或者需要多人参与,所以产品经理要学会重新评估,以及分拆设计。

我们可以将一个复杂的功能分拆成若干个简单的功能,当前只去开发最重要的那些,而不重要或者复杂的,如果迫切程度不高,我们可以把它们推迟到后续版本里。如此就可以极大地节约工期。

关系的维护是一定要做的工作

一切评估结束,我们看看怎么去和你的小伙伴们解释这个问题。(其实本不是特别想写这个部分,但是想想却又是绕不过去的坑)我简单罗列几个可供参考的方法。

勇于承担责任

产品经理是产品的CEO。

勇于承担责任是必须要有的勇气和担当,哪怕主要责任不在你,也需要站出来承担责任。一个好的PM首先是一个好的Team Leader,否则不会有兄弟愿意和你一起卖命工作。错本身不可怕,怕的是甩锅怯懦的PM,这样的PM很容易失去同伴的信任。

明确分析原因

无论是通过一个小的会议,还是通过邮件,都需要明确分析产生这种修改的原因。

这种做法的目的不仅仅是将事情告知大家,而是要让所有人明白,这个是全团队的大事,通过正式的方式来通报所有参与者,显得正规合理得当。如果你只是私下里和大家说道说道,你的同伴会觉得你这个人相当不靠谱,也很不正规,他们在做这件事的时候也会不正规,最后可能又会带来新的问题,而锅还得你来背。

陈述新修改的影响

修改后带来的影响一定要提前讲清楚,这样所有人心里都有一个预期。

这里有一个小的Tips,你可以把你做优化以前的设计所带来的影响,和你优化之后所带来的影响进行对比,告诉大家我们产品经理通过努力,将影响降到了最低。这么做一方面让大家有个对比,比较容易接受,另一方面是大家会看到你这个产品经理在这个修改上很努力,很为大家着想。

好的沟通是确保未来长期良好合作的基础,千万不要充当一个只会分派工作,不会解释说明的产品执行者。

学会总结,不在同一个坑里跌倒第二次

当大家都接受了你的修改设计,并且已经开始工作之后,你一定要学会总结,以确保下次别再掉坑里了。

最好的成长来自于总结别人的错误,其次的成长便是来自于总结自己的错误。

总结一定要深刻,你需要分析你这次设计中缺失的环节,你手里的产品功能在后续的设计中还有哪些地方可能还有坑,而且还需要总结你这次处理的好不好,有没有后续的负面影响。总结并没有特别的方法论,具体问题需要具体对待。但是可以肯定的是,你总结的越细节,越能推演出前后的关系,你也就越能体会到成长。

祝愿各位年轻的PM们,在后续的工作中能够多总结,少犯错。

未经允许不得转载,或转载时需注明出处:西部数码新闻资讯门户 » 产品开发到一半,你想改个设计,怎么办?
分享到:更多 ()

网友评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

中国领先的互联网域名及云服务提供商

为您提供域名,比特币,P2P,大数据,云计算,虚拟主机,域名交易最新资讯报道

域名注册云服务器