标签：bsp 响应 反馈 展开 体验 同事 会议 功能 头脑风暴
转自《用户故事地图》Marty Cagan序 http://www.tup.tsinghua.edu.cn/booksCenter/preface.html?id=06102901
原作者：Ben Horowitz（本·霍罗威茨）
个人感觉这篇文章叫<好的团队和差的团队>更好
===华丽的分割线，以下是正文。=====================================================
好的团队，有引人入胜的产品愿景，怀着传教士般的热忱在工作。差的团队，像是由雇佣兵组成的，当一天和尚撞一天钟，靠混的。
好的团队，从关键业务指标得到启发，通过观察用户的痛点和分析用户使用过程中产生的数据，不断尝试新技术解决现实问题。差的团队，从销售人员和用户那里收集需求。
好的团队，理解谁是主要干系人，干系人所受的约束，承诺引入解决方案，方案对用户和客户有用，同时也满足业务上的约束条件。差的团队，只知道从干系人那里收集需求。
好的团队，掌握大量的技术手段，这些技术手段可以快速验证哪些产品创意是值得开发的。差的团队，召集会议来制定路标和排列优先级。
好的团队，喜欢和公司内有想法的主管展开头脑风暴和讨论产品。差的团队，在团队之外的人胆敢提议他们做任何事的时候，会觉得自己受到了冒犯。
好的团队，产品经理、交互设计师和开发工程师坐在一起，对功能、用户体验、技术可行性达成一致见解。差的团队，各自坐在小格子间里，没有文档和会议安排，就不会主动响应其他人的请求。
好的团队，持续尝试新想法以求创新，过程中会注意保护公司利益和品牌。差的团队，仍然坐着等待开始尝试的指令。
好的团队，对于创造出成功产品所需的技能很有信心，比如强大的交互设计能力。差的团队，甚至压根儿就不知道交互设计为何物。
好的团队，保证开发工程师每天有时间参与产品原型的讨论，为做好产品献计献策。差的团队，在迭代计划会上展示原型，一心只为了估出工作量。
好的团队，每周直接和用户交流，以更好地理解用户诉求，并试探用户对最新的产品创意的反馈。差的团队，以为他们自己就能代表用户。
好的团队，清楚地知道尽管他们很喜欢自己在产品上的创意，但这些创意中的很大一部分用户并不见得会接受，即使有一些被用户接受了，也需要经过多个迭代的打磨才能达到预期的效果。差的团队，只开发路标上规划的内容，能按时交付，只求不出重大质量问题就阿弥陀佛。
好的团队，理解速度和快速迭代对于产品创新的价值，更知道速度来自于正确的方法，而非强制加班。差的团队，抱怨同事工作不够努力，速度太慢。
好的团队，在评估方案，确认可行并对用户和业务有实际价值后，共同做出承诺。差的团队，抱怨自己公司是一个受销售驱动的公司。
好的团队，使用工具，以便快速了解用户是如何使用产品的，并基于数据做出判断。差的团队，认为统计分析是可有可无的。
好的团队，持续集成和发布产品，因为他们知道持续的小发布能为用户提供了稳定可靠的解决方案。差的团队，在经过痛苦的集成联调之后，手工测试，一次性发布所有功能。
好的团队，专注于用户。差的团队，专注于竞品。
好的团队，在关键业务目标重大影响达成后庆祝。差的团队，在终于发布产品之后庆祝。
标签：bsp 响应 反馈 展开 体验 同事 会议 功能 头脑风暴
原文地址：http://www.cnblogs.com/Xiao-Bing/p/6593367.html
