艾伟也谈项目管理,需求分析之六大原则

  需求分析的六个原则(一)

  1、需求分析第一个原则:永远不要显得比客户更聪明。
  聪明反被聪明误,这样的事情太多了,我们产品经理都是有智慧的人,而不是耍小聪明的人。
  2、原则第一点:了解需求,而不是去批评客户。
       产品经理不是批评家,心理上要重视客户,行动上要尊重客户,平等对待每一个客户。
  3、原则第二点:客户比你更熟悉业务的环境。
  产品经理熟悉的仅仅是产品本身,但是,产品经理要做的却不仅仅是产品本身。
  4、原则第三点:真正的问题只有客户知道,我们要做的就是让客户愿意说出来。
  客户会给你反馈,但是这些反馈有些是真实的,有些是敷衍的,你希望真实还是敷衍,请参考原则第一点。

  需求分析的六个原则(二)

  1、需求分析第二个原则:尊重用户的现实选择。
  产品是客观的,用户是客观的,使用是客观的,需求也是客观的,一切都是现实的。
  2、原则第一点:客户永远是对的。
  客户不是我们的敌人,客户不会害我们,客户提出的需求看似在为难我们,但本质上是为了让客户自己更好的使用产品,因此,客户不会为难自己。
  3、原则第二点:提供最合适的解决方案,而非最好或最贵的方案。
  我们能够做的不一定是最好的,我们不想做的有时候往往是客户最需要的,找到最合适客户的,而不是最合适我们的。
  4、原则第三点:不要把客户当傻瓜。
  这个世界上没有傻瓜,自以为对方是傻瓜的人才真的是傻瓜,不要忽悠客户,不要欺骗客户,如果非要在这个前面加上一个期限的话,我希望是“永远”。

  需求分析的六个原则(三)

  1、需求分析第三个原则:第三方也是我们的客户。

  只要是对我们的产品和业务提出需求,就是我们的客户,应该一视同仁。

  2、原则第一点:第三方一般会把自己想象成设计者。

  他们对产品或许很熟悉,但是对整个业务可能不熟悉,因此,他们成不了设计者。

  3、原则第二点:第三方可能会遗漏或补充一些额外的需求。

  每个人都期望产品能做好,这种强烈的成功心理容易让人们产生日晕心理,从而影响我们对需求的筛选。

  4、原则第三点:对第三方的自由发挥不应抱怨和生气,而是将其视为客户。

  客户是第一位的,而他们又是我们的客户,因此,我们应该心平气和的对待他们的想法,无论这些想法是出于公还是出于私的。

  需求分析的六个原则(四)

  1、需求分析第四个原则:客户和用户要区别对待。

  客户是客户,用户是用户,有时候一致,有时候分离,这是我们首先要搞清楚的。

  2、原则第一点:产品为最终用户设计,需求的功能转换为最终用户的使用要求而确定。

  用户决定产品,我们需求工作基于用户,始于用户,归于用户。

  3、原则第二点:为客户寻找价值上的需求。

  客户是多样的,价值导向也是多样的,我们的产品能否承载多样化的客户价值决定了产品能否实现最终的交换。

  4、原则第三点:用户的利益高于一切。

  产品的最终价值是通过用户来体现的,脱离了用户的产品,就是“皮之不存,毛将焉附”。

  需求分析的六个原则(五)

  1、需求分析第五个原则:用最简单的文字工具记录需求。

  客户并不麻烦,需求也不复杂,麻烦的是我们把一切做的太复杂了。

  2、原则第一点:所有人都能懂的东西,最不容易出错。

  没有人喜欢复杂的东西,需求也不例外。

  3、原则第二点:不需要再学习的东西,最不容易出错。

  产品是需求的表现,没有人喜欢复杂的产品,要做到这一点,就从需求开始吧。

  4、原则第三点:不要希望客户能花更多的时间来了解需求转换后的原型。

  我费些事,客户就可以省些事,客户省事了,我们最终也就省事了。

  5、原则第四点:保持沟通的通畅,是了解需求的保障

  要实现需求的清清楚楚,就要做到沟通的反反复复。

  需求分析的六个原则(六)

  1、需求分析第六个原则:天下没有免费的午餐。

  要得到就一定要付出,付出的量并不一定和得到的量相等,作为产品经理来说,就是要让客户尽量少的付出,尽量多的得到,但永远不会是免费的。

  2、原则第一点:客户从来没有不合理的需求。

  客户的需求都是现实的,都是合理的,因为这些需求都是客观的,但我们通常习惯于用主观去看待客观。

  3、原则第二点:客户的要求都是可以实现的。

  没有不可以实现的需求,只有我们了解的不够深入的需求。

  4、原则第三点:我们能做这事-这是所需的费用。

  成本第一还是需求第一,客户把这个问题交给了我们,我们就用用我们的智慧去解决这个问题。

时间: 2024-09-20 07:45:20

艾伟也谈项目管理,需求分析之六大原则的相关文章

需求分析之六大原则

需求分析的六个原则(一)永远不要显得比客户更聪明 1.需求分析第一个原则:永远不要显得比客户更聪明.聪明反被聪明误,这样的事情太多了,我们产品经理都是有智慧的人,而不是耍小聪明的人.2.原则第一点:了解需求,而不是去批评客户.产品经理不是批评家,心理上要重视客户,行动上要尊重客户,平等对待每一个客户.3. 原则第二点:客户比你更熟悉业务的环境.产品经理熟悉的仅仅是产品本身,但是,产品经理要做的却不仅仅是产品本身.4.原则第三点:真正的问题只有客户知 道,我们要做的就是让客户愿意说出来.客户会给你

艾伟也谈项目管理,解读敏捷需求分析五大关键因素

大多数学计算机语言的人都会有过这样的感受,过去一直认为编程和架构是整个软件生命周期里最了不起的部分,但实际工作后才会发现在商业产品里,需求分析才是一个商业软件成功与否的关键. 放眼望去,在当今软件工程领域出现的许多问题,诸如缺陷及资源运用不当,都源于需求的不清晰,甚至有软件人戏称:"需求变更乃万恶之源",一时也获得了颇多响应.时至如今,业务IT间需求分析过程中存在的问题主要有哪些?什么是敏捷需求分析?产品级和项目级需求有何异同?敏捷需求分析方法论中的五大关键点是什么?就以上热点话题,雅

艾伟也谈项目管理,我也发软件开发团队的思考(侧重点是人员)

//上个月给我们老板的mail.洋洋洒洒6000多字. //为了方便公开,改了一下.以致可能有些地方前言不搭后语. //不管他同意不同意,先在我们组实行了再说. //请多大家多提提意见,日后看有没有机会找老板当面交流 经历的几个项目,项目的进度老是不尽如人意.更重要的是市场的开拓因为这些项目拖住了后退而无所作为. 我们现有的情况是:项目期限和最开始的保守估计都相去甚远,最后提交给客户的产品60%都是最后一个多月开发出来的,还有20%左右是以前就固有的固定模块.这几个项目我参与了编码,我对整个系统

艾伟也谈项目管理,我的项目管理观点

    公司要我给项目经理做一个培训,关于项目经理的做事情的方法和观点方面.我就采用了Workshop的方式,Workshop不是会议模式,而是侧重于交流会谈的一种模式,毕竟大家都是项目经理,并非说我的做法就是对的,所有的一切都是自己的经验之谈,所以我只是说大家彼此分享经验,交流心得.我把我所要分析的内容大概做了一个讲义,也希望更多人能够参与到这个Workshop中.项目经理好做吗?      项目经理好做吗?好做!项目经理好做吗?不好做.不同的人.不同的态度.不同的方法,其结果也就存在有极大的

艾伟也谈项目管理,关于项目管理的一点体会

这段时间,一直在负责一个项目的管理与开发.在时间短.任务紧,而团队人员又大部分是没有经验的菜鸟的恶劣情况下,我带领接近40人的团队,终于在客户规定的时间范围内如期交付产品.这其中,经历了需求变更.人员变动(因为其它任务,先后有近10人离开团队)等诸多问题,项目仍然取得成功了,不能不说有几分侥幸,但此外也有一些经验与教训可以与大家分享. 一.项目开发方面 需求 项目应以需求为核心.一个项目是否能够成功,对需求的准确把握在成功因素中要占上60%的比例.不管系统的架构设计.团队管理有多么的成功,如果需

艾伟也谈项目管理,Richard Durnall谈系统管理和从外向内的组织结构

InfoQ中文站:能给我们介绍一下"系统管理理论"(System Management Theory)么?能不能跟我们分享一下您在实际应用中的经验? Richard Durnall:系统管理理论是过去五十年里出现并逐步发展而来的.它与传统的那种基于管理和控制方式的科学管理理论有很大的不同.首先让我们回顾一下管理科学的历史来了解系统管理理论. 在19世纪工业革命之前,商业规模通常不大,从业人数十分有限.19世纪30年代的技术革命中出现了大规模的工业企业.与传统的村镇工业不同,这些企业开始

艾伟也谈项目管理,敏捷实施中的常见错误

一些评论员写下了敏捷实施中一些常见错误和反模式.他们贴出了"Top X"列表,列出了需要避免的事项和他们曾在各种组织实现敏捷时见过的错误. Target Process的Michael Dubakov写了两篇博文:"10个敏捷实施中最常见的错误"(Part 1; Part 2 ).他认为"许多公司在敏捷实施中再三犯同样的错误." 他的常见错误列表如下: 1. 从一个工具开始敏捷开发是不同的.一个工具不会立刻产生影响,不会由于这一工具的存在而解决多

艾伟也谈项目管理,我是如何带领团队开发项目的

最近有不少朋友写信问我一些关于团队开发的问题,由于这段时间有些忙,没有回复.今天写一篇这方面的文章向大家介绍一下我是如何带领团队开发工作流项目的 关于团队建设,项目管理的文章网上已经有很多了,在这里我就不谈这些理论了,直接给大家展示一个我在 项目开发方,后台服务开发方式,前台UI开发方式,后台服务与前台UI对接方式,代码文档,页面的开发文档,源码管理,单元测试,以及单元测试文档,实现思路设计文档,数据库文档,数据库设计规范,编码规范,操做数据的方法命名规则 方面的一些片断,这是一个为期6个月的工

艾伟也谈项目管理,编程习惯

文/Alexey Radul 译/程显峰 原文地址:http://web.mit.edu/~axch/www/programming_habits.html 近年来,我对编程艺术有很多体会.过后,我发现有些体会是错的:有些体会我遗忘了但又重新感受到:而另外有些则是必然会发现的.我还完善了一套项目管理的好习惯,这些习惯包括我自己的,或者小组的,抑或是更大的,公司内部的.一方面,这些习惯对软件的成功开发是至关重要的(太小或者纯粹巧合的不算),另一方面,这些习惯也不是什么高深莫测的东西,较小的篇幅就可