CSDN资讯

这里,有作为技术人必须知道的业界大事。

女生天生就是产品经理

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/csdnnews/article/details/86542180

640?wx_fmt=gif

640?wx_fmt=jpeg

作者 | 李辉
责编 | 郭芮

大蒜,牛油果,西葫芦,包菜,鸡蛋,西红柿,鸡腿,三文鱼,土豆,洋葱,黄瓜,杏仁干……这是我买菜前在手机里列出的购物清单。我觉得我已经比很多相信自己脑子记得住、却常常丢三落四买了酱油忘了醋的理工男靠谱了。毕竟我买东西都是一样不少买回去的,但是每次回家还总是被老婆数落,这个不对那个不满意的。

有一天我终于忍不住爆发了,说那你给我个购物清单吧,到底要买什么?!然后她的清单发来了:

大蒜一挂,要 Bio(有机)的;

西葫芦一根,注意不要破损的,指甲印太多的;

鸡蛋一盒6个装,黄壳,不要白壳;

西红柿Bio 650g 8个装那种,买前捏一下,软的不能要;

两个鸡腿,500g左右盒装,盒子上要标“非转基因”;

三文鱼200g,不要冷冻,要冰鲜的,去鲜鱼柜台买;

洋葱一包,白皮圆形大个的,不要红皮;

小脆皮黄瓜,9cm左右的买6根;

杏仁干,250g一袋,碳水含量低于4%;

……

PS: 所有上述食品都要看保质期。

你可能要问:土豆不就一种吗,不就是马铃薯,洋芋?那你太天真了,德国是个有200多种土豆、能把土豆吃出花来的国度。

我在超市里盯着这个采购清单,突然无比后悔刚才的冲动。本来作为直男,采购的速度是以光速计算的,只要找到货架位置,刷刷刷把东西扔进购物车就行。现在我必须一个个按规定检查,在一排排同类但不同生产商的货中挑出符合规定的东西,还要看保质期。采购速度直接翻了五倍,本来一刻钟左右我就应该出现在收银台的,现在快一小时了我还在干果区找碳水含量低于4%的杏仁干,最后抓了一个路过的店员一起找了半天才在零食区发现。

好不容易采购完毕回家后,心想这次总该不会不满意了吧。结果棋差一着,还是被抱怨了:那盒鸡蛋有一个蛋破了。我按习惯是打开盒子,扫视一下外壳的,但我万万没想到,那个蛋底部破了。所以今后清单上又多了个标注:鸡蛋检查盒子底部,看有没有蛋液渗出。


640?wx_fmt=png

回归正题


男人的思维方式,大多数情况下是直线式、收敛式、简单式的,他们天生排斥“不必要”的修饰和麻烦。我敢打赌,99.999%程序猿的购物单和我一样。那些各种各样的“细节”和“形式”,在女人看来无比重要的细枝末节,在多数男人看来,只是浪费时间和吹毛求疵的表现。

这和软件开发有什么关系?如果把这份购物清单看做客户发给你的产品需求,或者一份软件设计文档呢?


640?wx_fmt=png

产品需求分析


因为工作领域关系,经常有朋友找我咨询一些软件项目的问题,比如:

  • 开发一个教育类App多少钱?

  • 做一个网店多少钱?

  • 我想做一套在地图上实时显示数据并且分析的可视化平台,开发周期一般多久?

  • 我需要一套采购物流系统,开发周期一般多久?

我的回答一般都是以这句话反问:

我问一下,你所在城市房子多少钱一套呀?

别人一般回答:

这要看房子大小,朝向,哪个区买的,差别很大啊。

我会接着说:

做软件和买房子一样的,按软件实际的需求和开发构架的差别,开发周期和费用也是有很大的变化区间的。

然后再一步步细问对方的实际需求,最终可以得出一个大概的项目开发预算和时间预估。


640?wx_fmt=png

需求设计文档


我平时习惯在谈项目初期,先做业务和构架需求分析,但还是时不时一个方面没考虑到,就入了坑。曾经有一个做产品经理的朋友找我合作一个项目:客户要做一个电商系统,项目第一版的要求很简单,只要能运行正常购物流程即可:

  • 电脑和手机可以访问;

  • 用户可以邮件注册,也能微信注册;

  • 有产品列表展示,购物车,订单,用户扫二维码支付即可;

  • 用户界面自己决定,以后可以换模板;

  • 管理员后台能管理产品,批量上传订单,上传上传图片,查看客户订单。

我自己手头有一套完整的基于Spring的CMS开发框架,包括前端API模块、后端管理模块、用户权限模块、数据持久化模块等等,所以上面这些按估算很容易搞定。第3点里的产品,购物车、订单分成三个小模块,做个二维码支付也不是大问题。而且第一版只要基本功能,不用考虑任何的分布式,大流量,并发抢购等今后做大了要考虑的问题,无需过度设计。

我这个朋友也是个资深程序猿出身,所以我也很放心他作为客户传话筒,所有需求遵循KISS原则,但保留基本的模块扩展性。讨论过后,这第一版的构架图简单如下图所示,我也写了个相应的需求列表。

640?wx_fmt=png

我们这边技术层面一切OK,客户那边看起来也很佛系,对于我们写的第一版的基本需求列表没有异议,事情似乎向着阳光的方向发展。我想到了所有技术和构架上能想到的点,却单单漏了一点:

朋友是个男性产品经理。

所有该谈的事情谈定了后,最终朋友从客户那里得到了一个产品需求细节文档:

用户分级别,享受不同折扣率;

产品含品牌属性;

产品归于相应的一级和二级目录;

产品由不同供货商提供;

产品含颜色和大小等属性;

产品分官方价格和折扣价格,订单扣费按当天折扣;

支付和交易需要后台管理;

产品按重量和大小分不同的物流渠道以及关税申报登记;

订单最终价格是折扣后价格,加上动态计算的物流价格;

订单表含发票和发货模块,同时扩展物流模块;

发票模块需要调用一个第三方发票在线生成系统;

支付模块并不和支付宝直接对接,而是和一个境外第三方支付机构;

特价,打折模块;

官方Blog模块;

若干其它模块......

如果真正做过电商系统的朋友,看到第5点可能会心里一颤,这个就是要做一个完整的SKU系统啊!SKU是大型电商系统的基础,复杂度不言而喻。按之前的开发预算和时间预估,这么多关联模块根本不可能完成。

把朋友电话里暴揍一顿后,按客户的产品需求,产品构架思维导图变成了这样。

640?wx_fmt=png

我得到的教训就是:

在没有客户的详细需求设计文档之前,绝对不要做任何项目估算,更别提动手开发!

看到这,各位是不是很容易联想到你们的男性产品经理或是项目经理,和客户开个会后,就急冲冲地列出一份新的Feature所需大致功能,然后马上发邮件或者口头传述给开发团队,程序员直接就开始开发。

这里可没有性别歧视,我工作中遇到的男性产品经理或程序猿在做功能设计文档时,常常没有女性产品经理那么细心和耐心。这种文档不明确就开发的做法,看似敏捷快速迭代,但做出来的功能往往和客户所需相差甚远,最后返工付出的代价难以计算。


640?wx_fmt=png

分析细节标准


我们公司有个客服系统,客户在使用产品遇到问题时,会邮件或者电话给客服,客服录入系统后会分配给相应研发团队。这是一个常见的一问一答流程,我们的反馈会通过客服发给客户。

客户:我App突然登陆不了。

研发:请问您用的系统版本是什么?App的版本是什么?登陆时发生什么错误?

客户:我的系统版本是xx,App版本是xxx。输入用户民和密码后,登陆界面跳转到浏览器,然后就没反应了。

研发:请问浏览器里显示什么,有没有错误代码,是什么时候登陆的?

客户:浏览器里显示“Request Error”,时间是xxxx。

研发:请尝试清空App的缓存,以及浏览器的缓存。步骤如下……….

…….

有没有感觉这样的沟通成本其实很高,客户提供的信息模糊,研发问得也不尽清晰。这里和产品需求文档类似,到底细节的标准在哪?

我建议我们程序猿在做需求分析时,先向你的女朋友或妻子学习如何分析细节,比如分辨下面这些:

640?wx_fmt=jpeg

呃,好吧,当我没说……

我的建议是需求也业务拆分尽可能详细,考虑周全,最好能覆盖今后绝大部分的测试用例。

比如需要开发一个用户注册登录的功能,从某个男性产品经理嘴里说出来可能就一句话:给我开发一个用户系统,能注册,能登录,三天够不够?

从女性角度,她们习惯把一件简单的事情变的复杂化——如果这里的简单并没有你想象的那么简单呢?

如果你足够细心,就需要和客户做仔细沟通后达成共识,最终交付给研发团队的应该是如下一份需求Kickoff列表(只是举例,考虑并非100%全面):

用email注册还是用户名注册?

如果是用户名,最短几位,最长几位,允许特殊字符吗,密码最短几位,最长几位?

如果email注册,是密码一起填写注册,还是有验证步骤?

点击注册前,是否展示用户协议。不勾选显示什么错误?

如果有验证步骤,需要手机验证吗?如果要,要对接哪个API,验证码长短,过期时间?

手机验证码发送时间间隔,以及发送频率限制;

如果只需邮箱验证,发送给用户的激活链接有效期多久,过期了怎么办?

验证这个业务要不要持久化?

发送激活邮件的模板,HTML还是txt,谁来设计?

激活链接过期后,显示什么错误,然后跳转到验证邮件重发界面?

激活链接激活后,显示什么信息,自动跳转到哪个界面,比如设置密码界面?

密码设置允许特殊字符吗,最短几位,最长几位?

密码入库前采用何种加密算法,以哪个属性作为salt?

用户密码设置成功后,跳转哪个界面,显示什么消息?

用户后期允不允许改用户名或注册邮箱吗?

用户后期修改密码是否需要邮件或手机验证?

允不允许单用户多地点登录,如果不允许,显示什么错误自动登出?

支不支持单点登录SSO?

要不要开发移动端App,需不需要提供注册和登录API?

API需不需要支持OAuth2,或是Token?

登录构架是单体还是需要考虑分布式Session?

用户权限系统设计,多Role或是单Role设计?

鉴权系统设计是无状态还是有状态?

用户自己或者管理员关于权限系统的操作流程是什么?

有没有第三方SNS接口注册接入,如果接入,需不需要同步头像,需不需要同时必须新建本地账号。

第三方SNS接入的流程,回调接口,以及界面设计;

相关前端和App界面设计图,错误对话框UI;

......

需求文档越详细,后期开发与测试遇到的误解就越少,试错成本也越低。

该文档必须保持在线实时更新,有任何变更,研发团队必须第一时间得知。不要通过短信或者Email更改需求,这会使团队和产品经理陷入无尽的扯皮炼狱之中。


640?wx_fmt=png

细节的力量


如果说女性太注重于细节,是期待对方给足自己安全感。那么我们在做项目时注重细节,其实也是给自己一种安全感:减少返工。一个口碑好的软件,肯定是从用户需求分析开始就研究细节,设计时重视细节。

大部分程序猿都是非常看重技术,但从男性视角介入软件产品设计时,很容易陷入工程师思维:先考虑怎么做,再考虑做什么,最后考虑为什么做?一看到新项目,脑海里浮现的立刻是各类框架、各类中间件、高并发,恨不得立刻开机撸码。

而从女性角度介入软件产品设计时,她们往往会带有与生俱来的消费者直觉,会从第三方角度看事情。

我这里不是简单地贴职场标签,而是提醒不管是程序猿还是程序媛们,思考一下自己在设计产品时思维的盲区。

最后,女人天生都是产品经理,只不过:

640?wx_fmt=jpeg

作者简介:李辉,德国硕士毕业后,在软件咨询业工作多年,涉猎前后端及移动开发构架。现在德国博世智能家居部门任高级软件工程师。

声明:本文为作者独家投稿,作者独立观点,不代表 CSDN 立场。



 热 文 推 荐 


 Windows 7 时代即将终结!

☞ 王欣“马桶 MT”改名“MT”;任正非点赞苹果;酷派 27 岁总裁上任 | 极客头条

☞ Java 这一年都经历了什么?

“对不起,你的离职是我的错!”

 Gartner的预言:通向混合IT之旅

☞ 阿里“菜鸟”AI?

☞ 刚刚!华为又被美国盯上了!

☞ 心疼!能为程序员男友做些什么吗?

640?wx_fmt=gif

print_r('点个好看吧!');
var_dump('点个好看吧!');
NSLog(@"点个好看吧!");
System.out.println("点个好看吧!");
console.log("点个好看吧!");
print("点个好看吧!");
printf("点个好看吧!");
cout << "点个好看吧!" << endl;
Console.WriteLine("点个好看吧!");
fmt.Println("点个好看吧!");
Response.Write("点个好看吧!");
alert("点个好看吧!")
echo "点个好看吧!"

640?wx_fmt=gif点击“阅读原文”,打开 CSDN App 阅读更贴心!

640?wx_fmt=png喜欢就点击“好看”吧

没有更多推荐了,返回首页