《人月传说》第四章《贵族专制、民主政治和系统设计》中阐述了互联网开发中结构师和一线开发之间的民主问题。
针对”结构师是否是新贵？创造性活动是否都被这些精英单独占有，实现人员被告知该如何工作？“等问题，《人月传说》的作者Frederick P. Brooks Jr.认为
- 并非只有结构师才有好的创意，但系统的概念完整性决定了其使用的容易程度。不能与系统基本概念进行整合的良好想法和特色，最好放一边不考虑。如果出现了很多非常重要但不兼容的构想，就应该抛弃原来的设计，对不同基本概念进行合并，在合并后的系统上重新开始。
- 结构师的工作产物的生命周期比那些实现人员的产物要长，并且结构师一直处在解决用户问题，实现用户利益的核心地位。如果要得到系统概念上的完整性，那么必须有人控制这些概念。这实际是一种无需任何歉意的贵族专制统治。
- 因为外部技术说明的编制工作并不比具体设计实现更富有创造性，它只是一项性质不同的创造工作而已。在给定体系结构下的设计实现同样需要同编制技术说明一样的创造性、同样新的思路和卓越的才华。实际上，产品的成本性能比很大程度上依靠实现人员，就如同易用性很大程度上依赖结构师一样。
这部分内容让我联想到实际工作中pm与其他同事，rd、ui、qa等之间的关系。
“人人都是产品经理”的论调让很多非产品经理的同事质疑pm的工作，认为自己也能做pm，自认为有理地强烈抵制pm的观点。
针对这种现象，首先我们应该在团队中明确产品主导的文化，明确由pm实行贵族专制！对此，pm不需要有任何歉意，但是pm可以选择做较为民主的贵族，可以做允许言论自由的贵族专制！
pm在团队里是有能力也有责任承担贵族专制的。
他们专职负责了解用户需求，服务用户需求，实践以用户为中心的价值观。开发和设计师同事倾向于用易于实现或者酷炫的方案，运营同事倾向于能制造噱头热点的方案，商业推广同事倾向于能放更多广告的方案……连用户都不清楚自己的真正需求究竟是什么，而不同职位的同事也会有不同的侧重点，这就需要pm来排除噪音和干扰，抽离出用户真正的需求，坚守住用户的核心地位！
需要确保，所有的需求最后都由pm产出。其他同事可以在最终决定前给出各种各样的充分意见，但是如果pm已经确定了最终方案，则实现时大家都应该全力支持，服从pm的专制；pm也应该有魄力坚持方案，推动方案最终落实！
当然，对于实现过程中发现的问题，则需要pm都认真跟进实现过程，及时调整方案。不过这是另话了。
但是，pm的贵族专制需要允许言论自由才能持久。
虽然pm在产品方面经验较为丰富和专业，但是好的方案和创意并非只有pm能产出，设计师往往有优秀的交互方案，开发和测试同事往往对一些边界条件考虑得更加严谨，运营同事往往更容易听到用户的声音……这些都可能让pm的方案更加完善或优化。虽然最终方案由pm确定，但是pm应该尊重其他同事，在方案制定过程中多听其他同事的意见，选择性地从中吸取建议。在方案制定过程中pm不要太过自负，不要担心四面八方袭来的意见，要善于撷取自己所需为自己所用！
最近在看Bill Buxton的《用户体验草图设计》，很喜欢里面的一句话“设计中没有愚蠢的提问，也没有被视为疯狂的想法。有想法就提出来，即使是不成熟的想法，说不定它就会引发有意义的内容。”
我想pm应该牢记这句话以吸取好的建议，团队里其他所有同事也应该牢记这句话以勇敢提出建议！
之前看过一个很有意思的pm的不同性格的图，我是“中立善良”型的，即对于各方面的意见会说“恩，我明白”，与对方真诚讨论后，认真思考，最后对自己的方案加以适当的调整优化或者最终还是坚持自己的正确观点。
现在想想这其实就是允许言论自由的pm贵族专制了。
后记：
或许因为我是由程序猿转为产品汪的，所以比较理解其他职位的辛苦。在我心里，各个职位只是职能分工不同，不过都需要创造性和专业能力，无论什么职位都一样的有价值，并无高低优劣之分。
本篇可能有些人看了不以为然，但我在实习期间，与各位开发、设计师、测试们闲聊时，经常听他们说起遇到过的各种不尊重其他职位的pm。我认为pm目前还是一个硬实力很难衡量的职位，因此与团队的沟通和谐能力作为软实力，是需要pm重视的。
大家发挥各自才能齐心协力把一件事情做好，难道不是最美妙的体验吗？！