需求采集为小公司敏捷开发中的用户服务

网页制作Webjx文章简介:最近也许是因为大家面试很多,讨论用户需求采集的话题越来越多,好像突然大家一下子都在关注产品的这一流程。当然需求采集的方法很多,众多前辈们也都总结了许多,完全可以参考甚至搬到自己的项目中来实现。这些方法用到大公司大项目上,只要把握的好,数据分析工作做

最近也许是因为大家面试很多,讨论用户需求采集的话题越来越多,好像突然大家一下子都在关注产品的这一流程。当然需求采集的方法很多,众多前辈们也都总结了许多,完全可以参考甚至搬到自己的项目中来实现。这些方法用到大公司大项目上,只要把握的好,数据分析工作做的好,完全可以把产品的用户需求分析的很好。但小公司的敏捷开发中,这些需求采集,不管是焦点小组,还是阅卷调查,还是点对点访谈,想要做的很完善,很全面,并且建立准确的用户模型,需要时间,而这时间会拖慢快速产品开发的进程,而很多小公司小项目等不起产品的开发周期一再后延。

下面就说一下小公司和创业公司敏捷中的产品用户需求采集方法,共讨论。不适用大公司大项目,由于大公司大项目所面对的用户过多,角色又纷杂和庞大,需要建立一套完整的需求库,需要专门来分析总结,从而得到一个需求优先级,并且满足大多数用户。而小公司小项目产品目标会相对单一,所面对的用户群也相对单一,往往是垂直和细分的用户领域,讲究快速敏捷开发

用户需求谁最了解,在什么时间来完善?提出产品开发,提出要做某项产品的人最了解用户需求,通常在小公司里这个角色是老板。是老板在投钱做某个产品,也是老板最先看到了商机所在,也是老板对这个项目的未来产生信心。所以才会投钱来做这个项目,对项目的赢利点在哪很清楚,没有哪个老板会把钱花在一个看不到未来的产品中。通常这样的公司时间是宝贵的,项目不适合长久开发,那就没有时间也没有多余的钱来给你做焦点小组,更没有有效的渠道来让你问卷分析。

这时候你的需求应该首先应该从项目的发起人那里得来,但并不是从发起人那来得来的需求就是完善的, 或者是合理的,项目发起人往往只会关注产品中的某个点,或者某几个点,而这几个点恰恰是产品的核心所在,也是赢利所在。会从产品的形式一直到市场赢利都会想的很透彻和明白。得到需求后产品经理应该首先验证这种需求的,并且在验证的过程中完善它,从而把产品的所有需求给架构完整,需求完整了,随之而来的产品架构也就完整了。验证已有的需求,本身就是需求的采集,只是更有目的性,更有针对性,也会让需求的采集更加准确和快速。验证需求比采集需求要简单的得多,这时候不管是做焦点小组还是在做用户访谈,都更加快捷有效,快速完成需求采集,这时候得来的用户需求还是需要在产品开发中一直不断地验证。

上次看到一个专访,是访谈抓虾的老总,说他在一次不经意间发现了现在女孩子们爱美,并且爱分享美,于有创建了分享类网站“美丽说”,是项目发起人先有了这个核心点,分享美丽,这个时候交给产品经理,产品经理先有了这个核心需求点,再围绕着这个核心点现寻找外围的附加需求和设计出这些需求的具体表现方式,是用图片呢,还是用文字呢,如何来体现其中的分享呢,如何让用户常回来并且能常发现新东西?这些是产品经理需要实现的,但实现这些功能点又得考虑是不是目标用户群所能接受的,于是又会产生众多的小需求。有兴趣的同学可以google下这篇访谈,当中谈到了小公司小项目的成败经验,对小公司很受用。

于是你得保证可用性/易用性测试会贯穿整个产品周期。只有产品原型的时候可以给用户看原型,甚至在纸上画的草稿都可以用做可用性测试中来。至于用户,你可以找你熟悉的目标用户,朋友,同学甚至新来的同事都可以做。“5个可用性测试发现80%的问题”,这个很实用,简单方便,又不需要什么成本投入。这样边做边校正,直至开发出来的产品越来越接近完美。

分析竞争对手的需求,互联网发展到现在,除非你是创造性地创造了新产品,像twitter,guoupon等,要不然你所做的任何一个产品在同领域都会有或多或少的竞争者,即使国内还没有,国外也一定有类似的产品。找出他们产品的优势和不足,从对手的产品中分析用户需求,既得到了需求,又很好地利用了他山之石,也为以后的运营打下基础,因为你了解对手。

最后说下产品经理自身产品素养,除了需要具备全面的知识,掌握应该掌握的技能,还需要有丰富的经历,从而能够扮演不同的用户角色,从而从这些扮演用户中推演出需求来。这就是所谓的产品经理拍脑袋想需求,但这种想不是毫无根据的想,而是你自己就成为用户中的一员,把自己定位成一个角色,从而去适应这个角色,得到一般性需求。我知道有很多产品经理忌讳,甚至反对批判这种方法,说这样做出来的东西不能够贴近真正的用户,最终是空中楼阁,也是产品失败的根源,这个有待再讨论,至少我觉得这样做有一定的道理,因为这时候网站目标和服务人群已经定下来了,你想的这些需求也只是可用和易用的需求,只会让产品更爽,是一个完善需求的过程,而不是创造需求。只是要在后面的流程中来验证这些需求罢了。

我自己玩户外,做为一名户外驴子,我了解这些人需要什么,想用什么,我没有做过俱乐部,但我知道现在的户外俱乐部最缺什么。我曾经是学生,我了解做为学生的时候我需要什么,我的同学需要什么。我喜欢旅游,做为旅行者我能推演出大多数旅行者的需求。我自己租房住,我身边也有一堆人租房,于是我了解租房客的一般性需求。如此等等,我们自己就是用户,我们又是产品经理,我们有理由运用专业知识来分析出用户的一般需求。

从项目发起人那里得到需求,从身边的人那里获得需求,从自己的经验中分析需求,再经过不断地可用性/易用性测试,基本上这个产品的用户需求可以收集个70%,剩下的30%在运营过程中去完善吧。

时间: 2024-10-03 16:48:16

需求采集为小公司敏捷开发中的用户服务的相关文章

独立软件测试团队在敏捷开发中的几个特别实践

最近读了<测试人与敏捷团队的五个约定>,很是赞同.但发现其并没有紧扣敏捷开发测试的特点,这五个约定在传统开发中已经早有实践,也有相关论述.哪么在敏捷开发的测试方面有没有不一样于传统开发测试的并且是有效的实践? 从敏捷团队的组建上来说,敏捷团队并没有要求安排专门的测试人员,甚至于在某些的方法中不建议清楚的区分开发人员角色和测试人员角色. 本文讨论的是已经存在独立测试团队的情况,如何在敏捷开发中进行高效的测试. 实践1:测试保护开发 通过快速的自动化测试跟进开发,保证新增和修改不破坏已经获得的成果

java开发中:用户、订单、订单详情、商品之间的关系 搞不清

问题描述 java开发中:用户.订单.订单详情.商品之间的关系 搞不清 此案例的业务关系是用户.订单.订单详情.商品之间的关系,其中, 一个订单只能属于一个人. 一个订单可以有多个订单详情. 一个订单详情中包含一个商品信息. 所以它们的关系是如下: 订单和人是 一对一的关系. 订单和订单详情是 一对多 的关系. 订单和商品是 多对多的关系. 明明人和订单是一对多,为什么说成了一对一,订单和商品又怎么是多对多的关系? 求解 解决方案 最近在oracle数据库里刚学了交易系统表结构的设计,来说说我的

利用Rational Team Concert在敏捷开发中进行持续集成

本文将介绍如何利用 Rational Team Concert(RTC)在敏捷开发过程中进行持续集成.详细说明了如 何在 RTC 中通过采取一系列的步骤和脚本开发,来保证持续集成过程的连续性和提高整个项目的效率. 同时还阐述了每一步可以利用的工具和最佳实践,从而使开发过程更加规范化,高效化. 概述 Rational Team Concert(RTC)是 Jazz 产品中最重要的一个,是一个可以任务分解集成,源代码版 本控制,进行自动构建和报告的工具.Jazz 做为 IBM 下一代的软件交付平台,

敏捷开发系列之满足不断变化的需求

软件开发方法一直处在不断发展过程中.在诸多方法中,敏捷开发以其能持续满足不断变化的用户需求正在受到越来越多人的重视,从中小项目开始进入大型开发项目,近几年来上升势头明显.为帮助读者进一步了解敏捷开发方法,本报邀请长期在国外从事软件研发工作的专业人士撰文就此进行深入探讨. 在软件工业界,敏捷开发已成为众多高效开发团队的制胜之道.在欧美软件企业中,有近半数企业已采用敏捷方法进行开发,而近几年受软件外包和外企的带动,敏捷开发在中国也出现了日渐普及的态势,如腾讯内部几乎所有的开发团队都在实施敏捷方法.敏

创建标准化代码在VS中实现敏捷开发

标准化程序开发是敏捷开发中的核心内容之一.标准化代码不仅有利于团队之间的合作,也有利于模块之间的集成,节省时间与成本.在VS中也为创建标准化代码做出了很多努力.笔者在这篇文章中就跟大家分享一下,在VS平台中创建标准化代码的注意事项.具体的说,就是五大禁令和四大推荐. 禁令一:不要随意检查代码. 这可能跟用户正常的认识有所差异.有些开发人员可能认为在开发过程中,检查代码是必须的.不过在敏捷开发的模型中,这恰恰是禁止的.因为如果在代码的编写中,不时的检查代码,会浪费开发人员大量的时间与精力.当然,这

敏捷开发学习分享

程序员都很懒,你懂的! 敏捷不是快,而是拥抱变化(不断反馈的一个过程).                                                        简单的说,敏捷开发是一种以人为核心.迭代.循序渐进的开发方法.在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征.换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态. 敏捷原则:主张简单,拥抱变化,可持续性,

敏捷开发与项目管理实战之敏捷需求分析

问题背景 敏捷开发中许多活动都是全员参与而非专人参与.需求分析同样也可以是全员参与 的一个活动.这反映了敏捷开发的"个人与交互胜过过程与工具"的价值观.需求分析是在需 求理解的基础上进行的.因此,全员参与需求分析有助于及时发现团队成员对同一个需求理解不一致的 问题,这很大程度上避免了缺陷的引入.另外,也有助于规避人力风险.比如,一个需求的开发者突然 需要请假,其他开发者可以马上顶替他,因为其他人也参与了其负责开发的需求的分析.此外,全员参 与需求分析也有助于全体成员的能力的提升.但问题

敏捷开发中高质量Java代码开发实践

概述 Java 项目开发过程中,由于开发人员的经验.代码风格各不相同,以及缺乏 统一的标准和管理流程,往往导致整个项目的代码质量较差,难于维护,需要较 大的测试投入和周期等问题.这些问题在一个项目组初建.需求和设计均具有不 完全可预期性和完备性的全新项目中将尤为突出.本文将结合敏捷开发周期短, 变化快等特点,介绍如何通过在开发过程中采取一系列步骤来保证和提高整个开 发团队的代码质量,并阐述了每一步可以利用的工具和最佳实践,从而使开发过 程更加规范化,成就高质量的代码,减少测试的投入,并促进整个团

敏捷开发的几点建议

同步发表在:http://snowdream.github.io/blog/2016/04/07/agile-development-advices/ 移动互联网行业由于节奏快,产品迭代周期短,因此多采用敏捷开发进行快速迭代.下面我从Android客户端研发的角度,说说敏捷开发中的几点建议: 模块化 当项目开始变得很大时,需要按照主要功能进行模块化.同时对人员进行分组,每组负责一个主要模块.由于迭代周期短,任务重,可能在开发过程中,某个模块无法按照要求,在既定的时间内完成开发任务.这时,应该由产