标签： 需求
【译论】如何询问用户的痛点？
我对保健/医疗领域很感兴趣，想找到一个值得研究的问题。我正在运用 YC 方法，尽可能多地询问医生他们的痛点是什么。
进展并不顺利。我只是在 LinkedIn 上搜索并试图建立联系，结果只有 25% 的联系率和 1% 的访谈率。
软件开发最难的不是编码，而是需求，你认同吗？
编码并不是最困难的部分，而是需求的定义。作者通过自己的经验和例子，强调了需求的不明确、不一致或错误是导致软件问题的主要原因
大开眼界：“根据手机壳换APP颜色”不过是小意思【视频】
对于乙方来说，甲方有时候好像真的是活在另一个世界，彼此说的是不同语言。这次用夸张的情境，将甲方与乙方沟通的困难淋漓尽致地展现了出来。前几天因要求app跟随手机壳变色的需求导致程序员怒打产品经理的事情虽然搞笑，但不乏寓意。下面还有一个视频，也是通用的搞笑，笑完后后让人深思。
[视频]产品经理要求App随手机壳变色被程序员暴打
昨天朋友圈被刷屏了。据说，事情是这样的：一个产品经理给研发提出一个产品需求：要求app的主题颜色可以随着用户手机壳颜色改变而变化，然后就干起来了。
程序员如何理直气壮的拒绝乱改需求
一如代码深似海，后面从此有无数的跟句：从此妹子是路人，从此代码是节操……或许，许多写代码的程序员每天应对的就是写不完的代码和改不完的bug。
程序员天天说“这个需求做不了”，我该不该信这个邪？
我接触过的最优秀的程序员会在一开始就对问题进行全面的评估，经验告诉他们，看起来再简单的事情，平静的海底下依然可能暗潮涌动。
需求：我只是想在页面上加个链接
需求：我希望在页面上的这个位置放一个链接。
从“项目经理让程序员买包烟”这个需求说起
比如这个需求：一包中华45元，产目经理给你50元，让程序员去买包烟把找的5块钱拿回来。产品经理觉得非常简单，一句话的事。而对于程序员而言：
「需求」到底是什么？
知道「需求」更准确的定义后，有什么好处呢？首先，当然是让我们对「需求」有了更深的认识，而不再是浆糊一片；更重要的，就是能帮助我们更深入地分析「用户需求」，能做出更好的产品，否则就只是在一个比较浅的层次做产品。没记错的话，张小龙也说过类似的话。
提需求的正确姿势是什么？
在论坛、知乎上经常看到一些「年轻的」项目经理发的引战帖，大意是：「开发大哥，我代码写的少，你可别骗我，这么简单的需求，明明一下午可以搞定，你跟我说一个星期？如果让我来的话，巴拉巴拉巴拉…」。看到这种论调，一些没耐心的程序员就会一笑了之，甩下一句「You can you up，no can no bb」
一个项目从开发到完成需要多久
程序员，尤其是刚毕业的新手，没经验，又老实。 盲目地自信，加上领导给点压力/鼓励，想提高productivity. 看了几个高优先的功能就估计出个时间，其实坑了自己也坑了队友。
折磨程序员的五类需求描述
张大胖一边心猿意马地Coding， 一边听着领导在电话里“卑躬屈膝”，”奴颜媚骨”地讨好客户 ： “好的，李总，我明白你的要求了！ 下周一上线？ 嗯…. 没问题 ， 我们开发人员的素质绝对一流，请您一定放心！“
客户需求何时休？
我想看到这种标题。对于每一个搞软件的朋友来说，肯定是非常有兴趣的。由于这已经成为每一个软件开发人员的心头大患，客户需求在软件这个独特的行业里。体现着最独特的含义，由于需求是软件项目存在的意义所在。而需求的变化让软件最后撵手不着，我们大家都会有“客户需求何时休？”的体会。
需求的两个思考：用户是真的想要一匹很快的马吗？
不是强迫的喜欢，没用的，反而会让自己陷入误区，因为你不是在用一种自己不喜欢的角度去看待这个产品，你只是在用一种第三方的眼光去思考，去做这个产品，和真正喜欢这个产品的用户的诉求是不一样的。
项目经理必须知道的5大需求工具
需求工具要活学活用，知道每个工具制作背后的原理或者方法论，如果不理解，就是拿到工具，估计也不太会使用。工具或模板往往浓缩了知识、方法论的精髓，悟性高的项目经理往往能自己制作工具或模板，这才是将学到的东西提炼到一定的高度，继而提高工作效率，让自己能懒出境界。
让技术更好地理解需求？产品经理先做好需求分析和评审吧
所有问题其实都可以归结为人的问题。规则是死人是活，不同人在不同情况，对事情往往会有不同的处理方法。但在此就不展开讨论了，遇到问题想办法解决就是。
优秀的程序员如何调研需求
我经常在Stack Overflow上看帖子，见过不少各式各样的求助帖，有些帖子写得好，回复的也切题有些则不知所云。我觉得，优秀的开发者/程序员必须学会如何“在最短的时间内获得最好的答案”，下面是我总结出几个写求助帖提问交流的技巧。
产品经理如何不被程序员们嫌弃
最近有位刚做 PM（产品经理）的小伙跑来跟我控诉，说公司技术部的 RD 们（程序员）个个不给力。需求过了千百遍还是理解错，或者就是简单回一句 “做不了”，表情如死灰。
程序员的生产效率源于需求，而不是工具！
你确定你真的知道到底是什么促使一个程序员高效率的吗？是因为使用了 VIM 和 Emacs 这些强大的编辑器，还是因为应用了最新的 Haskell Web 框架，抑或是你最喜欢的 NoSQL 数据库？
也许你不该问用户想要什么
用户并不一定知道自己想要什么
成为更优秀的程序员：退后一步看问题
是客户真的需要“一个会躲避鼠标点击的闪光的按钮”吗？还是他们需要的是另外一个功能——他们不了解的功能，需要你去帮他们定义的功能？这种事情同样会发生在你自己身上！你真的需要用程序打开一个文件，往里面写入一些信息吗？还是，你真正需要的是一个日志系统？
