我确实认为行业中大多数团队都能开发出可运行的系统，不过其中只有非常少数的项目满足了目标、时间进度和预算的要求，并且能够被市场接纳。真正的项目试试过程中我们更多的时候是一个接一个淹没在奇怪的坑里面，表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当需求相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。
人是程序员，月是时间，如果1人干10个月的工作就觉得可以10人干1个月完成，那就成神话。
在这边其实我更想从自己的角度去谈谈产品的那些事，首当其冲的是产品经理和程序员长期被用于调侃需求和开发之间的矛盾。我想强调并且声明我的想法：如果【产品经理不懂技术乱XX提需求自己也不知道要怎么做】 的情况出现了，我想你可能遇到了一个假的产品经理。我知道确实有很多时候产品会出现而且长期出现以下三种问题，但是如果你的产品比我说的更恶劣，只会给你画个原型提提用户体验告诉你说按着这个原型来做，没有任务分解也没有评估交付时间，那么恭喜你真的遇到了假的产品经理。
1）过分追求完美
2）产品线没有规划，工作分解不到位
3）对缺陷不是发散的跟踪，而是收敛和拖延
实际工作中，产品经理应该负责的工作应该
1）理解需求，结合当前系统进行产品原型设计
2）评估需求，评估开发进度人月
3）沟通对话，一方面根据工期与客户进行沟通；另一方面把原型设计转化给设计师以及程序员
4）工作分解，根据客户沟通成果对开发计划进行有成效的优先级调整
5）测试跟进，对于每个阶段交付的任务进行测试并反馈结果
6）资源协调，对开发过程中的资源，包括人力、物力、技术指导、硬件购买等工作及早的进行安排，避免影响开发计划
所以产品经理要懂啥，想了一下也没多少。
面对客户和开发人员，懂点心理学、沟通技巧。全面贯彻我待需求如初恋的态度。
面对需求，懂点逻辑学、并全面理解客户的工作（按我个人说法是你调研完了之后你应该能到那里应聘上班了）、有点文字描述能力，能好好写出人能看懂的需求文档。
面对原型设计，懂点色彩搭配、培养出美感、还得要对每个需求要有多套的方案（没有的话手机里下载100个应用自己好好学习去）
面对程序，要懂得你的公司采用的是什么前端技术、什么后端技术、什么数据库、什么操作系统，你至少得知道浏览器书签用的ico而不是png，知道px和安卓的dx还有ios的@2x是什么鬼东西。必要时那你要知道你们的系统是如何部署的，如何启动程序，如何连接数据库查看数据，还得了解下IIS、tomcat、weblogic、resin、还有其他什么apache、nginx是什么东西。你不懂写代码没什么关系，如果你连跟程序员沟通的基础都没有，如何定位bug也不知道，也怪不得别人鄙视你就是个提需求的。再说白了，提需求的也罢，连数据库统计都不懂， select 是什么，leftjoin是什么都不知道，凭什么理直气壮的说我这个需求是代表用户习惯提出的，你懂个毛客户习惯，你数据都不会统计好伐，你的用户习惯数据哪来的呀，瞎提不如不提。
所以我们不需懂什么东西，懂我们应该懂的，懂我们刚刚好需要懂的，懂那些能跟开发人员好好沟通传达需求的东西就够了。
以此自勉
