小编导读：本文是作者对攻城师做的一个调研，攻城师期望的产品经理是什么样的。虽然调研用户数不多，但也有一定的参考性，你是攻城师期望的产品经理吗？

【前言】：

从交互设计师转做产品经理不知不觉两年了，虽然角色并未完全转变过来，但是心态和做事方法已经发生了不小的改变。最大的心态转变就是：owner心态（主人翁）、目标驱动、没有借口。产品经理一定是个主动的角色，他不是任何人的资源，他没有任何的权力，但是又要统筹各种资源，让各种角色因为目标聚集在一起，共同完成任务，达到目标。期间，遇到的困难和挫折也不少，其中的困难之一就在于对技术的把握。

我负责的是数据产品，可能一个项目，我会同时与java开发、数据仓库开发、前端开发以及app客户端开发打交道，被他们提需求，或者想需求去虐他们。然后就是被各种术语围绕——架构、集群、java、jquery、hbase、缓存、模块、js、调用、服务器、接口、CDN、数据库、MySQL、JAR、代理、内存、分布式、语义、数据挖掘、Hive、Hadoop、反向代理、流式计算、离线计算、即时查询、PHP、变量、参数、join、流join、实例……太多了。

某日我站在我们部门的书架前，下决心去学点技术知识，可是又发现技术涉及到各个方面，无从下手。

于是我就见了开发就问：嘿，你觉得我应该学点什么技术知识呢？

他们的回答也是迥异的——

有的说：你什么都不用补充，只管考虑商业层面，以及把你的需求描述清楚，剩下的事情交给开发。

有的说：恩，作为一个天天与技术打交道的产品经理，你是应该好好学点技术知识，比如……然后就听到一大堆名词出来……

平时也经常听到攻城师评价产品经理，如果产品经理的只要职责是专门想需求的人，可是，攻城师们的思维也很活跃，也很超前，也很有创意，只是没有给他们机会和时间去想，是吗？那PD的想和程序猿应该有哪些不一样呢？或者除了“想”，攻城师对产品经理还有何种期待呢？

所以，我向诸位攻城师们做个简单的调研，了解一下他们是怎么看产品经理，他们认为好的产品经理是什么样的？什么样的产品经理却让他们头疼？他们认为产品经理的专业性主要体现在哪些方面？他们认为产品经理要补充哪些技术？

问卷仅向攻城师发送，邀请了几十位我有过接触的攻城师，有架构师，有开发工程师，有测试工程师，也有数据开发工程师……层级不等，但是期待相似，尤其是建议篇，字字珠玑，读之阅之，引人深思。若分享之，有幸帮助别的产品经理同样进步，岂不快哉。其实，整理此文最大的目的是：自勉，给自己树个镜子，经常照照。

问题1：什么样的产品经理会让你认可乃至佩服？

另外选择了其他选项的，有三位开发同学，他们分别补充了三点：

1. 有对未来市场的把控和预测

2. 善于规划和整理的

3. 独立的、冷静的

【点评】：在开发GG们看来，产品经理主要要负责把事情想对，想明白，沟通清楚。剩下干活就是开发的事情了。昨天也听一个大产品经理讲了一下我挺认同的话，他说，市场部门和产品经理是最费钱的，市场就是拿预算砸效果，而一个不靠谱的产品经理，想一个不靠谱的需求，折腾了一群人（设计啊、开发啊、测试啊、运维啊、运营啊、市场啊……）加班加点，发布了上线了，发现不是那么回事，于是各位开发同学的心血付诸流水。开发同学更期望产品经理“想”的能力上胜人一筹——反正活是我们干，你要想出花样才行啊……。另外，光想出创意和想法来是没用的，好的产品经理还得能够顺畅地将想法具体化下来，让各色人物都明白你到底在想什么，不管是巧舌如簧也好，讲故事也好，画图也好，总之你得让开发GG们知道怎么编码，让交互设计师知道如何设计，让视觉设计师知道风格向什么方向走……

要能够做到这两条，产品经理不就得不断开拓眼界，不断尝鲜，不断丰富自己各方面的知识和能力吗？所以如果你没有太好的创意和想法的话，不妨业余和非业余时间，都提醒自己不能固步自封，一定要尝鲜，多看看国外的设计、网站，最新的趋势，数据，不要想出一个早就被攻城师看烦的产品和方案出来……因为攻城师们可是经常流连前线论坛和网站的……

问题2：什么样的产品经理会让你郁闷乃至拒绝合作？

【点评】可以看到，攻城师同学最不喜欢产品经理没有长远规划，总是提一些短期小需求。这种事情是没技术含量了对不对？作为产品经理，是不能忽视短期小需求的，因为产品的整体体验就是一环扣一环，不解决一些刚性的短期小需求，怎么去谈产品长远的健康发展。但是向程序猿们提需求的时候，如果动辄提一个需求，然后跟进下进度，再提下一个。彼此的需求，让大家看不出关联、分类，也无法去知道这些需求的解决与产品长期的发展目标是什么关系？那么程序猿就会认为你失去了做产品经理的价值，或者仅仅是一个功能性产品经理罢了。

攻城师们希望你带来明确的目标感和方向感，需要你画产品大的蓝图，比如2014年，我们的产品发展的目标是什么方向，围绕这个方向，我们要做哪些，要放弃掉哪些？围绕这个方向，我们要做哪些大项目，这些大项目里，再会分成若干个小阶段的项目，而哪些小需求分别是为了实现那个方向的目标。虽然这些长远规划，就像画饼一样，无法作为能够开发开工的PRD(产品功能需求文档)，可是它很重要。

另外，不要以为攻城师们对产品没有归属感——他们是不是只是沉浸于写代码的快感里？你错了。你的一个小需求，对他们来说，可能是加班加点的几万行代码，每行代码里可能都有纠结，有些代码可能是饿着肚子，瞪着惺忪的睡眼敲出来的。结果做到一半，你说，因为种种原因，不做了。或者发布了，你不给去好好推广，让用户来用，后来忙别的就忘记了这个产品。管生不管养，有时连程序猿都恨不得出来作为对外的维护接口人呢。

当然，攻城师们希望产品经理交付的需求是自己考虑周到的。这点就像“狼来了”的故事一样老生常谈。今天你交付了一个需求，说已经确认。明天突然被抓住一个漏洞，赶快想替代方案，然后又确定，后天又自己发现有点不对劲，唯唯诺诺去找开发要改需求，长此以往，攻城师们对你的“已确定”就不敏感了。你们可以在正式交付前多争论几次，多评审几次，但是请确保你此时的文档是0.N的版本而不是最终版。并确保最后提交一份基本不会再变更的需求确认文档。如果一旦程序猿开始设计了，开始编码了，你突然发现遗漏了某个需求或者某个需求的逻辑有问题，你就等着被贴一个不靠谱的标签吧。

当然，依赖于你和你小伙伴的彼此信任，你可以告诉他，让他好好看看文档，或者在编码过程中一旦发现有疑问，随时找你沟通。因为形式所迫，天天加班开会并周转于各个项目中的产品经理也难免会糊涂很多的。

攻城师也会鄙视天天拿老大当挡箭牌的产品经理，如果你告诉他这个需求就是老大要做的，那么你已经离“好产品经理”又远了一步。在专业人士看来，单纯的执行以及监工角色，是最没技术含量的。。所以有时产品经理就是夹心饼干，老大把你叫小黑屋，告诉你要做什么，争论了没用，心里不认同，后续一定要做的话，还得人格分裂为自己特别拥护认同的需求。。当然，坚持自己原则敢和老大们叫板的产品经理也是有的，我们叫他叫“偶像”。

问题3:你认为产品经理的专业性主要体现在？（最多3项）

【点评】之前在某个旺旺群里，一群同学在聊想法（下文中的PD为产品经理的英文缩写），A同学说：你有这想法，直接找几个开发和设计一起搞啊。B同学说：没资源啊。A同学说: PD要不要？B同学说：PD哪都不缺，一抓一大堆，要那么多PD干嘛？我没有转产品经理之前，也认为产品经理是一个没有专业性的工作，他的很多工作精力花在了沟通、协调、把握进度上，他看似什么都会一点点，但是什么都不会太精通，对于一心要有点“专业建树”的人来讲，选择产品经理真不是一个好行当。毕竟，做一名优秀的产品经理需要太多的机缘巧合天时地利，产品要能够发光生热，产品要能够有影响力……那怎么样才是一位专业的产品经理呢？产品经理要从什么方面提升专业性呢？

而在下面的5个选项中，“能想”——商业意识、眼界以及长远规划，再次占据优势。其次是要把天马行空的想法落地，能够周全地想清楚，不要把攻城师们带到沟里去，要表达清楚，消除各角色的误解。至于其他几个方面，虽然也很重要，但是分工细的团队里，还可以让更多人一起做。

这个问题大多数攻城师们果不其然选择了：以上都要。加油吧，少年。

PS: 补充了一个其他的答案的是一位数据界的高级技术专家，他的答案是：在未来的数据世界，你必须要懂数据。懂得会用数据，会看数据，确实能够让产品经理更加能想，能加周全……

问题4:你目前与产品经理合作中的最大障碍是什么？（最多3项）

这个问题，Heidi失策，问题选项没有设计好，结果让大多数人选择了其他。我们先看看看对其他各位的补充答案：

没障碍。

目前还好。

信息传递的时候可能有误差。

暂无

目前合作还不错。

好久没看到产品经理了。。

沟通缺乏，不能将自己的思路很好的表达给开发以求认同，对于工程师的意见不能认真思考

没想法、只为了完成某项任务的

没啥大障碍。

需求不明确

产品的想法无法持续

无

我没有产品经理，我就是技术产品经理

现在的产品经理很好啊，没啥大问题啊

【点评】其中几个写无障碍的是我们对口的攻城师，Heidi窃以为，如果本投票变为匿名投票的话，几位同学会不会变更答案，哈哈。。

结合其他与大家的选项，可以发现：争取攻城师对需求的认同以及明确沟通，减少信息遗漏和误解，是让项目顺利进行下去的关键。

对于需求的认同，要区分清楚攻城师是不认同需求还是不认同解决方案。

我们平时常说的需求其实是指产品经理交付的产品功能需求文档所承载的内容，对于攻城师来讲是需求，但是其实是为了满足某种用户或公司的需求而提供的最终解决方案。攻城师有时不认同需求不是不认同用户或者公司的“need ”，而是对解决方案有很多疑问。

产品经理直接省略掉了对于用户需求、公司需求的挖掘分析，直接交付解决方案，即使解决方案里会阐述项目背景、项目目标，但是可能依然会造成理解的断层，无法让攻城师从内心真正地认同为什么要这么做。作为产品经理要谨记一点：程序猿是我们的战友，小伙伴，是伟大的实现者，绝对不是给产品经理打工的，也绝对不是机器，不是系统——只要输入指令就可运转。在需求的前期，就尽可能要让程序猿了解，参与（他没时间参与就是他的事情了），从而能够让他们与你一起了解需求的背景，了解涉众的需求，从内心认同这个需求。

而，在认同需求的层次上，解决方案并不是产品经理一个人想出来的，如果攻城师更早参与，他能够为解决方案贡献建议并被接受，你们就少了很多沟通解决方案的成本。

问题5:你觉得产品经理是否是开发背景重要吗？（单选题）

【点评】大部分攻城师认为得分情况，比如：

要看产品经理的类型是系统产品经理还是业务产品经理。注：系统产品经理偏功能性产品经理, 主要要根据产品愿景、目标以及运营的需求设计出产品去支持，而业务产品经理更多是规划一块业务，比如物流中的干仓配，这块业务可能会需要设计一个产品，也可能是设计一场活动。

要看负责的项目是什么项目，纯技术类的项目还是最好有开发的背景的。但是“有一点实际上是好事情，多了就不好”

选择不重要的同学，依然认为对于产品经理来讲，最重要的是想法。

而认为比较重要的同学，基本上是认为懂点开发，能够帮助产品经理判断可行性。“产品经理如果有开发背景，能第一时间判断需求的可落地程度，不至于变成完全的空想家”，“有开发背景最好，但不是重要的，能多了解点开发知识就行，知道什么需求能做什么不能做。”

有位同学补充说：一点都不重要，“态度第一，努力第二”。不懂技术的产品经理，要记住你身边有一群技术牛人，虚心地向他们多多请教，多多交流，攻城师们都是内心单纯、善良、天真、朴素和乐于助人的。

问题6:作为一名攻城师，你觉得产品经理应该懂点什么技术能更好与你协作？（最多3项）

【点评】技术的海量浩瀚无边际，产品经理怎么补充技术知识才能够投入产出比最高呢～ 来看看攻城师们的建议吧。

网站基础架构知识最高票数（符合预期啊），网站基础架构知识能够让产品经理等非技术角色快速了解一个网站是如何建设起来的，了解网站技术架构的基础概念——攻城师还推荐《大型网站技术架构:核心原理与案例分析》这本书，对于我们这种人来说，简直可以是一本技术术语字典呀。

此外，产品经理最主要的工作是要做需求分析，然后阐述描述需求，而UML是能够帮助产品经理更好与开发沟通的语言。用例法是有效的描述用户需求的方法，这些都需要了解基本的UML知识、概念与UML用例图绘制方法。产品经理可能不要求画得很专业，但是最起码能够表达也能够看懂。

选择了“其他”选项的同学有啥补充呢？

心理学,社会学,一点画图的能力,具备相当好的画板书的能力——想起了《餐巾纸的背后》系列

淘宝系统背景知识——想起了子柳的《淘宝技术十年》系列

技术类的各方面知识都要了解下——天哪，求攻城师开个面向产品经理的扫盲班。

懂数据，能很好的认知数据的价值——这个不用说就是那位数据牛人的选项，但是我的经验也是很多公司的业务leader（人称大产品经理）都是及其数据敏感的。

开发者的思维——谁能解释下开发者的思维是指什么？

规划整理沟通能力——想起了《思考的整理术》

交互、数据分析——一手抓体验，一手抓数据，两手都要硬。。

各位攻城师们，还有啥补充的吗？

总结：

在调研的最后留了个开放题：请站在攻城师角度给产品经理一些建议？或者对以上自己的回答有啥要额外补充的？

本来也只是象征性这么一放（传统问卷不都在文末放个开放题嘛），但是攻城师们的回复真出乎意料地真诚，其中还有几位是我从来没有打过交道也不认识，冒昧发了问卷过去的……特别要精选出来，让各位都好好品读下：

注：如无特殊标注，下面的ID均为来往帐号ID。什么是来往？

edwardpro: KPI是必须的，但所有以KPI为目标设计的产品都不会成功。KPI是在大成功的前提下，均能轻松完成，否则怎么都完成不了，不管你是不是很关注KPI，总之这个真不是产品的目标。 你希望用户来使用，就必须首先做一个真正的用户，去体验分支流程和异常流程，和各种可能存在问题的场景下，去帮助无助和无奈的用户。 不要过于拘泥于技术是否能实现，最烦就是某些产品经理，过来一句，这些能做么？能不能做和你无关，你考虑的是产品的流程和目的（此非KPI目标），如果你的目标是对的，能说服大家，那么它就不可能成为绊脚石，请千万不要用这个来作为项目总结中出现的内容。 减少关注项目进度和项目细节的时间，这是技术PM的事情，而非产品经理的主要工作，要相信和你合作的同事能帮助你踩着时间节奏，而控制这个节奏并非PD所必须的一件工作，“要性”并非要用“要”来体现。不要让大家感觉像一个小监工一样，而是在过程中，来体验测试中的产品，提出自己的建议和改进点，测试并非全是测试的工作，测试永远只能帮你解决“问题”，但不能提升产品，投入到产品中，把自己变成用户才是关键。 另外不要求像真实的原型和流程图，原型图不是UED的工作，而是产品经理的工作，用简单的方式去描绘原型，让它动起来才是关键，而非精美，许多时候产品经理认为精细才是体现PD价值的时候，其实恰恰相反，美丽的故事带来的效果可能更甚。

kmygf: 我认为的比较好的产品经理应该是这样的：内在的气质、丰富的知识、果断、冷静、成熟（做事的方法上） 我最喜欢的产品经理应该是这样的：漂亮、思维活跃、需求明确（哪怕有变也变得自然而非理性）

changedi: 实干胜于空想，完整的设计优于快速实践

需求尽量细化和提前~后期改需求风险很大

多沟通，多思考

希望产品经理能带着攻城师完成的产品走向胜利的曙光，让大家的努力不会白费

最重要的是设计的产品有价值，不要让攻城师做无价值或者马上就被抛弃的活。

善于思考、沟通、相处，总是合作愉快

懂得把技术人员作为合作伙伴，而不仅仅是资源。 在阿里，一个优秀的产品经理必须要懂得商业和人性。

做的事得到工程师的认可就好办多了，需求要理明白，这样写出的文档才明白，尽量不要或者尽可能少的更改需求。。。 另外，针对文档，产品经理可以跟开发交流一下，能否做一些工具，使文档结构化。自己曾经尝试过文档即代码的概念，譬如表单校验，只要定义好文档后，就可以通过工具生成所有字段的校验规则及文案（我们国际站物流表单比较多，就是采用这个中间系统进行的）。不过这个要看具体问题域和场景了。呵呵。

长远的眼光，敢于创新，会调节项目氛围这些都很重要。

了解大致的技术架构,不需要精通.关键是要对产品有规划,不能只管生不管养除了有产品的眼光，还要考虑可行性，能放能收才是关键，对业务的抽象能力，以及抽象后的衍生创新非常重要，往往一个小的业务创新就能成就伟大的产品想法，条理，态度，创意。

其实专业与否不是决定性的，要有足够的说服力，自己独立的思考。

创意，还是创意～没啥，PRD写明确点，写详细点，考虑周全点就OK了产品经理是站在上帝旁边的人，最好具有哲学思维的产品经理是最优秀的产品经理．

有技术基础，善于沟通，眼光独到!

1、多了解阿里相关产品的系统现状和缺陷；

2、有好的想法，无需多关心技术问题，技术问题丢给我来解决；

3、有主见，能坚持，并且有理由 。

4、拒绝高层传声器式需求掌控全局,把握细节

总体来讲，攻城师们是一群可信赖的，有担当的的好伙伴，你的一句话，可能背后他需要敲上上千行乃至上万行代码。他们也是一群很有想法的人，只是很多时候没有给他们足够的空间。他们加班加点任劳任怨，他们甘当幕后英雄，他们不断研究新的技术攻克你的需求的新的技术挑战——“技术问题丢给我来解决”。“如果目标是对的，技术可行性就不是绊脚石”。他们只期望产品经理们能够想出更加靠谱、有价值的、清楚的需求，能够不断运营开发出来的产品，让它发光发热，能够给予他们所服务的产品的长期规划，让他们看得到更长远的目标。

加油吧，共勉之。

本文作者：@heidixie   来自：格物志