站在产品调研角度
只要产品经理做好了足够的需求调研，而且假设产品需求已经足够详细，那么只要着力于需求实现就可以了。而问题在于，产品需求没有绝对的详细，在一定程度上，我们甚至可以说今天早上用户刚提的需求，到了下午就被用户自己否决了。
那么我们该如何避免在实现用户需求中不断出现的坑，由此来纪念一下过去几个月从零开始接触用户需求调研到代码实现的过程。
首先，最开始用户自己也不知道想要怎么样的界面设计以及具体的功能实现，比如我是用户，这时候我提出了要实现上班考勤的需求，如果产品调研工程师只记了一条上班考勤需求，然后带回去通知自己的开发兄弟们说，用户今天说要实现一个上班打卡需求，让我们开始愉快地实现功能吧。扯淡呢这不是，你没被开发兄弟们打死就算不错了。因为用户只有一个模糊的功能需求，你应该用你的产品思维逐渐引导用户的具体需求。
比如上面用户提出的上班考勤功能，在记录该功能点的同时，还应该再多问几句，比如你们的考勤组是要用户自定义还是每天都是固定的时间，考勤的报表汇总是一个月一次还是一个星期一次，考勤需要设置提醒吗，如果要的话那是在考勤时间提前十分钟还是提前半个小时提醒用户别忘记打卡…总之需要问的问题还有很多，比如网页呈现效果，需要通过考勤状态这个筛选条件进行筛选吗，只显示当天的考勤情况吗。
当你掌握了以上的需求信息之后，通知你的开发兄弟们开始做这个需求，那么至少不会把你打死了，在尽力满足用户需求的前提下做一个试用版给用户体验一下，之后你就会发现比较挑的用户还是会提出整改需求，不过在有了试用版的前提下，用户就有了比较，提出来的需求就会更加明确和具体。
站在开发者角度
有时候针对产品调研的结果，开发者需要作出的判断是从一开始的能不能实现，到后来采用什么技术实现，在此过程中需要不断地评估技术难度和时间节点。对于产品经理布置的研发任务，你首先要询问自己是否真的理解了产品经理的需求。因为产品经理已经是经过用户过滤的第二道传达了，而到达开发者这边就已经是第三道了，产品需求难免会出现偏差，如果你连产品经理的需求都没有听明白，那么可想而知你距离用户的需求会出现何种角度的偏差。最终产品成效，你需要通过的第一道难关也是产品经理，只有产品经理点头了你才能下班(所以一般没几个人能正常下班)，当所有产品需求都达到了产品经理的预期，最后才有底气向用户进行汇报。
题外话
我遇到过的产品经理有一些是懂技术的，有一些是不懂技术的，现在很多人都说懂技术的产品经理才是合格的产品经理，但是从另一方面来说，从我的角度出发，我觉得未必是这样的。我见过不懂技术的产品经理能够把产品做得相当完美，也见过懂技术的产品经理最后把产品做砸了，这就要说到产品经理的个人魅力，沟通能力和理解能力了。首先需要能够和手下的开发打成一片，而不是像网上那样经常出现和开发打架的新闻，这就是个人魅力，你要信任你的开发能够按时完成你布置的开发任务，而不是经常去指手画脚地指导开发该怎么做。之后就是沟通能力，因为跟用户之间的直接沟通是要通过产品经理这一道，最后才能到达开发，所以你作为中间传递者，你的沟通能力至关重要，你要使得用户与开发之间的关系链完全打通。最后是理解能力，你要理解开发实现功能的难度和时间，也要理解用户最终想要的产品结果。
总之，我很怀念实习时光跟第一位产品经理扯皮的日子，现在才发现产品经理其实是最不容易的那一个，前提是那个产品经理是优秀的。
System.out.println("Hello World!");