摘要： 项目Kick Off 【转】 说一下项目Kick Off会议（简称KO）的作用，会有人觉得这很形式化，但我认为很重要，其实KO只需要15min左右的时间，我通常会安排在需求评审（参加人与KO基本重合）之前，成本很低。在这15min内，需要传达的信息有如下几点。Ø 项目的背景与意义我们在哪里？说过去，做项目之前的情况，为什么要做这个项目（以让听众痛心疾首为终极目标）。Ø 项目的目... 阅读全文

摘要： 说说评审会【转】 评审就是项目相关的几个小团队的人坐在一起，一方讲，另外几方听并确认，统一认识，消除误解，防止偏差没有及时发现而随时间放大。这个过程不做，往往问题到很后才暴露，然后是谁的责任纠缠不清，与其亡羊补牢不如之前就在流程上预防，防病优于治病。项目过程中，比较大的三方面是PD、开发、测试，所以派生出三次评审，按照项目阶段依次为：Ø 需求评审，俗称UC评审，在需求完成以后，是PD说给... 阅读全文

摘要： PD的几种文档【转】从产品的抽象到具体主要产出的文档有BRD、MRD、PRD和FSD。BRD：Business Requirements Document，商业需求文档。这是产品生命周期中最早的问的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是和老大们过的ppt，所以也就比较短小精炼，没有产品细节。MRD：Market Requirements Document，... 阅读全文

摘要： UC（用例）写作【转】2009年1月20日 2 条评论 UC（use case，用例）是需求人员写给开发人员看的一种最基本的文档，在和其他公司合作做项目的过程中，发现双方的文档规范差异很大，造成了沟通成本的提高，所以感觉在一个长期合作的团队中，文档与规范的统一真的是非常必要的（我强调的是“统一”，并没有强调要一定要用“某种格式”）。查了一下资料，早期... 阅读全文

摘要： 简单的需求流程【转】2009年1月19日 3 条评论 接着上一回说网店版的日常小需求的发布流程，本篇是一个日常需求的提出到发布的流水账，后面有图有真相，对于小公司应该比较实用。大到功能模块级的需求自然是要起一个项目的，不再讨论之列，但原理上也是相通的。需求人员是产品变动的发起方，所以前期的需求相关会议会比较多，我觉得可以用三个会议来概括。这里不要理解成严格的会议室里几个人正襟危坐，更多的是两三个人... 阅读全文

摘要： 产品设计体会【转】2007年秋，一次PD交流会上，一位同事聊了PD如何与工程师合作的话题，很有共鸣，所以也整理了一下自己的想法，并且通过一个需求采集的练习，让各位开发、测试、PD、UI把对合作沟通的期望提了上来，整理如下。第一，综合大家的需求，权重最高的居然是一个很大的话题：“流程”,但仔细想想就一点都不奇怪，一群超级理性的人很明白“没有规矩，不成方圆̶... 阅读全文

摘要： 需求，分析什么【转】听到过一个说法，说需求分析与技术分析的最大的不同是思路的本质差异，技术分析是“树干——树枝——树叶”的任务分解过程，技术人员很适应并乐于用这种方式思考，可以把大问题分解成小问题，发现难点逐一攻克。很多做需求的人都是开发出身的，所以开始往往会用这种思路做需求，听到客户提到的功能点，直接想怎么做系统设计了，有时... 阅读全文

摘要： 有一个比喻，你找裁缝做一件衣服，对于裁缝来说就是一个项目，而服装厂要做一批成衣，那就算一个产品。现实一点的例子，阿里旺旺的E客服功能是一个项目，而阿里旺旺就是一个产品；网店版子帐号模块是一个项目，而阿里软件网店版就是一个产品。项目是定制的，个性化的，为了满足一个或一批特定的客户需求；而产品是服务一个用户群的，通用的。这就意味着，项目要服务好那个特定的客户；而产品不能为了个别用户的需求去定制，必须考... 阅读全文

摘要： 产品设计体会（1001）初探用户需求[转]第一，要听用户的意见，但不要照着做。有的用户会对一个功能提出意见，会抱怨，但没有说希望怎么做，所以我们也没法照着做。而更危险的一种，用户在提意见的同时还说你们应该做成什么样子，这个时候作为PD一定要头脑清醒了，用户提的解决方案往往是站在自己的立场上的考虑的，比如快递单打印用户会提出要添加一个他经常用的小快递公司。更有甚者，用户给出做法的时候根本没有经过大脑... 阅读全文

摘要： 推荐--jQuery使用手册[转]翻译整理：Young.J官方网站：http://jquery.com jQuery是一款同prototype一样优秀js开发库类，特别是对css和XPath的支持，使我们写js变得更加方便！如果你不是个js高手又想写出优 秀的js效果，jQuery可以帮你达到目的！ 下载地址：Starterkit （http://jquery.bassistance.de/jqu... 阅读全文