咱们那个奇丑无比的APP终于重做了，而且由于接口失效，旧版已经完全无法使用，因此需要尽快上线一个MVP。虽然这个项目不是由我负责，但每次听该项目的产品经理J君和设计师妹子沟(si)通(bi)，都能感受到后者深深的怨恨——
事情说起来倒也没什么特别，由于需要尽快交付，MVP版本理所当然的砍去了大部分Web端的功能，甚至连登录都不需要，只提供最重要的资讯阅读。
照理说这种情况下多数问题已经不言自明了，但J君不断和设计总监纠结是左图右文字还是右图左文字，原因在于他认为APP应该是一套完全区别于Web的产品，而各大门户的APP都是左图右文字。
此外，直到APP提交前几个小时，J君还在找设计师妹子争论导航的icon（默默插嘴，为什么还会有导航呢）应该用报纸还是书，应该是实心还是空心，最后被妹子喷得哑口无言，惊得一旁的我一声冷汗。
J君的心思我是能理解的，做产品的人总是会对一些问题有着自己的坚持，这种坚持往往表现为某种睥睨一切的控制欲，大到信息结构，小到icon样式，前者大约是PM的本分，而后者，很多人谓之「关注细节」，就像J君那句颇为声嘶力竭却又无力的犯驳，「这是很重要的细节问题！」。
关于「细节」，KentZhu老师已经说得足够好，我无意为其增添脚注，因此打算换个姿势，说说自己对于需求控制上的反思。
刚才说J君的心思我能理解，其实是因为自己也曾干过类似的事儿，只不过当时的情景没这么急迫，我的「私货」亦没有夹带得如此明目张胆。
网站上线前一个月左右，大的功能模块基本都已尘埃落定，内部版本的发布周期也从一周调整到了1-2天，每天到公司第一件事儿就是和开发Check需求池，决定当天要完成的功能点或样式调整，顺带过一遍剩余的需求以及相应的优先级情况。同时我也会在收集到新需求后，对之前的需求优先级反复斟酌（Flag已立）。
但由于我是内容运营出身，所以斟酌时偶尔会调高和内容运营模块相关的需求优先级，甚至是在日常分析需求的过程中便拔高一些需求的重要性，又或者是觉得改个样式很容易，便临时丢给开发。这些大多来自无意识，或许因为关注，久而久之便自我催眠了，就好像说产品大师关注细节的文章看多了，也自然而然容易「关注细节」。
你很难说精通业务流程和阅读行业文章是什么坏事，但在特定情景下，它们确实会影响你的判断，因为它们已经被你内化为了某种「欲望」。这大约是产品经理在成长初期都会遇到的问题，感觉自己找到了产品的秘籍和命脉，于是便偏执起来，不可救药。
所以在我看来，控制需求首先要控制自己的欲望，毕竟对初级产品经理来说，哪个模块先上、什么时候上都是无可置喙的，而来自他人的需求，更多考验的是分析，控制则是后话了。唯有来自自己的「欲望」，往往披着需求的外衣，教人防不胜防。
不过，知易行难呐。
