需求分析，产品经理绕不过的第一个门槛
——“我有一个价值十亿的idea，就差一个程序员了。”
这句话在创业圈火，在产品圈也是一样。每一个产品经理都想做出一款特别的，甚至可以改变世界的功能或者是产品。这些功能和产品往往是从一个或者几个简单的需求和idea开始，越做越大。但是，用户真的需要么？最终的产品和功能真的解决了用户的痛点么？
前些天看了孙继新老师的文章《产品方法论之：菜鸟做加法，高手做减法》，颇有感触。结合着这两天搭个人博客和公众号以及以前的一些经验，简单来谈一下产品初期对于需求取舍的看法。
Insert：大而全让你寸步难行
踏雪的第一个产品，应该是大学时的第一次创业。当时美团外卖和饿了么还没有出道，踏雪瞅准学校里外卖横行，却没有一个统一的平台将他们整合在一起，于是就打起了这个主意。
踏雪的执行力还不错，当即拉来几个小伙伴就商讨着做这件事。一边向学校和老师要资源，一边就做起了产品规划。
小明说：“除了外卖，学校周边的饭店、网吧、宾馆，我们都可以做起来，统一在平台上，这样他们想要什么，我们就有什么。”
小刚：“对对对，我们还要加上地图，这样用户就知道怎么过去了！”
小红：“加上自习室提醒，告诉同学们哪里有自习室。”
小张：“对，还要有即时聊天功能，万一自习室人满了，有人说一句，大家就不需要白跑一趟了。”
( `)3')▃▃▃▅▆▇▉ 你们是认真的么！
当时作为完完全全的产品菜鸟，踏雪不停的点头，对啊，这个功能肯定有人要用，加上加上，这个也对，加上加上。于是，产品的原型就变成了彻彻底底的四不像。
这个例子，很简单，大家一眼就能看出，很多需求是伪需求，比如聊天室，真的会有同学在聊天室里喊一句，自习室满了么？地图，有多少人需要在自己学校也看地图呢？自习室提醒，用软件吃喝玩乐的同学，会是经常去自习室的同学么？最后，我们最初的想法，不应该是整合一个订外卖的平台么？这已经离我们的初衷越来越远了。
这个例子看起来很傻，但是很多做产品的同学，在一开始做产品的时候，会犯下同样的错误。不自觉的往产品中添加功能，而这些功能，往往变成了产品的负担，让产品越来越臃肿，自己的思路越来越混乱，最终导致偏离初衷，走向失败。
踏雪在做产品的时候，每每见到新的需求或者想到新的功能，会这么做：
1.问自己这个功能是否真的需要，和产品相辅相成。需要，进入下一个问题，不需要，记录到自己的idea库。
2.问自己这个功能在现在是否真的需要，优先级有多高，是否立马就要做出来。还是需要，立马加到计划列表并高亮，不需要，记录到自己的idea库。
即便是这样，踏雪有时候还是会犯下添加不需要或者优先级较低的功能，那么——
Delete：开工之前，别忘了再删一遍需求
这次，拿新搭建的博客举例。
踏雪原来是做开发的，又不喜欢某浪等blog提供的模板，于是选择了购买域名和服务器自己搭（用的WordPress，套了主题后修修改改，没有那么复杂）。
在选择服务器的时候，众多服务器厂商的众多套餐晃的踏雪眼花缭乱。怎么挑选？
踏雪用做产品的思路去选择。首先，博客的定位是这样的：个人博客、产品经理相关。那么博客算是个小众博客，再加上踏雪是个新人，没有什么人气，一段时间内流量不会太大，那么买流量大，储存量大的服务器，显然没有必要，这个需求，删掉！
服务器和域名搞定，安装wordpress。自己写主题？显然“敏捷开发”（套用主题）更适合，那么自己写主题这个需求也删掉。
接下来挑选主题：踏雪的内容以文字为主，可能会有一些图片。那么播放音乐和视频的功能就完全没有必要，删掉！
文章会有评论，但以交流为主，头像这种社交性偏强的东西没有必要，删掉！删掉！
于是，博客的雏形就有了：
不大的服务器，准确易记的域名，文字和图片为主的内容，以及交流为主的评论。
于是半天的时间，踏雪的博客就搭好了，剩下的就需要花时间，一点一点的填充博客的内容了。
所以，在产品真的开工之前，我们需要对产品的每个功能和需求重新进行一次评估，只要不是真正立即需要的需求，统统砍掉。
那么问题来了。
“蓝翔！”
(╯' - ')╯︵ ┻━┻
┬─┬ ノ( ' - 'ノ) {摆好摆好)
(再TM的掀一次} (╯°Д°)╯︵ ┻━┻
踏雪要问的是：“如果砍掉的需求需要，或者没砍掉的需求不需要，再或者没砍掉的需求不够准确怎么办？”
Update：迭代中完善，改变世界也要一步步来
迭代更新这个事，需要大量的数据和用户反馈来支持。踏雪也没有发现一个特别共通的特点。
简单的举个踏雪遇到过的小例子。
踏雪做过的一款APP里，有一个发表话题的功能。这个功能在APP里是必须的，但是很多用户对这个功能的作用并不够清楚和了解，于是踏雪对它进行了一个小的改动，收到了很好的反响。
在发送话题前，弹出一个小框，引导用户选择是提问题还是分享经验或照片。
简单的功能升级，或者说需求升级，引导用户做出更规范的行为，即让用户知道他可以干什么，也让后台对内容的管理更加方便，数据统计也更加清晰。
很简单，却很有效。
<(￣）￣)/赞\ (￣）￣)>
那么对于迭代更新，大家一定要谨小慎微。千万不要把添加功能当作迭代，千万不要没有条理的去满足用户需求，真正的解决了用户痛点，才是一个好产品一个好功能。
增删改的基本要求
至此，踏雪浅入浅出的讲述了一下自己对“增删改”功能和需求的一些看法。重中之重，便是谨小慎微。
而增删改的基本要求便是：大胆猜想，小心求证。
转载请注明出处。
踏雪的博客地址：
踏雪Monkey写字的地方
