从竞价小白到营销总监，这5年我都收获了些什么_SEM_小蚂蚁站长吧
您的当前位置： >
从竞价小白到营销总监，这5年我都收获了些什么
他和你一样,从0开始进入竞价领域,坚守医疗行业多年,一路从小白到营销总监,有辛酸，也有欢乐。
艾奇菌曰&&
他和你一样
从0开始进入竞价领域
坚守医疗行业多年
一路从小白到营销总监
有辛酸，也有欢乐
他会给我们带来
怎样的心路历程
现在的你，或许是曾经的他
但他坚信，未来的你，一定会超越他
艾奇SEM：SEMer除了学习SEM技能之外，还需要额外掌握哪些方面的知识？
郭剑楠：SEMer除了SEM技能过硬之外，对的理论知识也要熟悉，例如数据分析的基本流程、如何收集数据、清洗数据；什么是PEST分析法、逻辑树、4P理论等等。
此外，对用户行为理论也要知道。
还有就是你所在行业的专业知识，比如做医疗的，你所在科室有什么病种，哪些症状是容易混淆的，有些外行人的所谓常识其实是错误的，作为SEMer，一旦被这些&常识&误导，就容易发生方向性错误。
SEMer不单单需要SEM技能过硬，需要掌握的东西很多，以上只是简单举例，还有比如代码，要稍微知道一点，另外一些EXCEL知识，也要掌握一点的，等等等等。
艾奇SEM：现在各家搜索平台都出很多新产品，面对这些新产品如何来跟进学习？
郭剑楠：最基本的，无论做哪一行，除了面对自己的日常工作之外，必须要了解这个行业内的一些动态：有什么新产品出现？的算法有没有改变？对的遮蔽有什么变化？等等。
我的方法就是多关注一些业内的公众号，收藏夹里放一些业内的网站，时不时打开看看，第一时间了解学习新产品，然后与同行交流，看有谁做过、效果如何等等。
新产品往往还不会有系统化的知识体系出现，所以前期只能了解一点碎片的知识，等产品成熟之后，你的碎片知识就会结合你的经验，加上业内大牛的经验分享，形成你自己的系统化知识体系。
总之，碎片化知识，最终需要形成系统化的体系，不然容易&一叶障目，不见泰山&，知识不够系统化，操作起来，容易跑偏，学习的过程中，这一点一定要注意。
艾奇SEM：有什么书籍或者影音视频可以推荐SEM从业人员额外学习的？
郭剑楠：入门书籍，最早我看的是百度的官方教材，现在这些东西在艾奇SEM上已经非常系统且精炼，并且大部分是免费提供。
新入门的同学，参考艾奇SEM的知识我觉得就够了；深入学习的，艾奇SEM也有进阶的知识；数据分析的话，入门的我推荐一下《谁说菜鸟不会数据分析》，文字轻松，结合案例，图文并茂，不会那么枯燥，其他的都比较细，就不一一推荐了。
艾奇SEM：一个新手SEMer如何快速进入行业？
郭剑楠：最快的办法就是找一个项目做，边做边学，有人带更好。新入行，不要怕吃苦，不会出现你某天在楼道里抽烟，天上掉下来一本&SEM大法&修炼之后突然就成神了，比别人多付出是正常的，没有捷径。
我新入行的时候，一天要工作十几个小时，两三个月不休假，没有人带，全靠自己摸索，但是我知道没有什么所谓捷径，想快速入行，只有拼命学习，拼命工作，才可能会早一点被这个行业接纳，在业内生存下去。不懂就翻资料，多虚心请教别人，但不要照搬别人经验，自己要会消化知识，提炼成自己的东西，进步才会快。
艾奇SEM：当领导下发的任务过重，感觉很难完成，你是如何对待的？
郭剑楠：仔细看一下任务，结合同比，环比的数据，再结合一下单位的政策和行业，然后把任务分解，看是否可以有突破。
一般定任务，都会比现有的状态，稍微提高一点，目的就是让团队昂扬向上，但是如果搞&大跃进&，乱弹琴，就得找领导谈一谈了，把数据和自己的分析跟领导沟通好，有理有据，不要让领导觉得还没开始，就没信心了。怎么跟领导沟通，职场里的规则，这些都是另一门学问了。
艾奇SEM：你是如何给自己做职业规划的？
郭剑楠：最开始就是基础岗位，操作账户这些，然后有经验了，能力提升了，可以做个部门主管。这除了需要专业技能过硬之外，对团队管理、为人处世，都有些要求，达到这个要求了，可以做个部门主管。再向上发展，多是一些管理和决策岗位，这需要有足够的经验和判断力，最后甚至可以自己投资创业，都是可以的。
SEM一般的晋升道路就是SEMer-竞价主管-网络总监-营销总监-经营-总经理。前面三步比较好走，营销总监需要掌握的东西比较多，很多人到这里就遇到了瓶颈。经营和总经理，要求更高，不要急，这些都需要学习和积累，技能，人脉等等。
厚积薄发吧，有些时候也需要机遇。&
艾奇SEM：你是如何来策划一个账户的，账户搭建的思路？
郭剑楠：我目前是按照用户行为来搭建新账户。按照用户行为，把关键词分为，痛苦期-兴趣期(把价格细分出来)-对比期-决策期。例如医疗的症状词，属于痛苦期；怎么治、病因，属于兴趣期；其中治疗XX多少钱，这类属于兴趣期，但是意向较为强烈，我是单独分出来做； 例如哪家医院好，属于对比期； 竞品词和品牌词分为决策期。
艾奇SEM：新接手一个账户如何快速开展工作？
郭剑楠：先了解该账户表现，之前的数据怎么样，如果数据理想，或者可以接受，切忌大动。有些人接手新账户，只看账户结构，不看着陆页，直接按照自己习惯进行大改动，甚至直接导入自己的账户，这对数据影响非常大。先观察，可以新建测试计划，进行交叉对比。
如果之前的账户实在烂到不行，那就尽早换自己账户，或者重新搭建。
我学开车的时候，老司机教我，想快太简单，踩油门就行，想开的又稳又快就需要技术了。一开始，不要只图快，先求稳，不然容易翻车。等你成了老司机，也可以又快又稳了。
艾奇SEM：日常维护有哪些重要的工作点？
郭剑楠：添词否词屏蔽IP，这些不必说了，一切优化的基础是数据，不要凭感觉，不要照搬经验。要充分认识到数据对于SEM的重要性。目前占用我时间最多的点就是整理和分析数据。
艾奇SEM：平时操作账户都有哪些重要的细节点？
郭剑楠：操作账户都是细节，没有什么不重要。
比较容易被人忽略的是着陆页的数据。很多SEMer只关注账户的计划，关键词，却忽视了着陆页。这是直接面向用户的东西，尤其重要，却最容易被新人忽略。着陆页打开速度、内容质量、格局设计，都直接影响到最终转化，而大多SEMer的重点是在账户上，而忽略了着陆页。这个很重要。
艾奇SEM：SEM如何与其它渠道配合让效果最大化？
郭剑楠：目前我们没有做， DSP因为行业限制也没有做，只做了几个第三方网站，这一块不好说。
但是有一个感受就是，SEM转化效果和品牌有很大关系，尤其是三四线的小城市，线上和线下是相辅相成的。很多企业觉得SEM难做，其实跟品牌包括口碑有很大关系。SEM不只是SEM团队的事情，更是整个企业的事情，SEM也只是企业营销中的一个渠道。没有整合的营销思路，单靠SEM一条腿，跑不远也跑不快，成本也降不下来。
艾奇SEM：目前一线二线三线城市的SEM的操作思路差异？
郭剑楠：一线城市屈指可数，这些地方多是面向全省甚至全国；二线城市多是省会或省内经济较好的城市，但因为是省会，所以有天然的优势，覆盖面也可以比非省会的二线城市大一些；三线以下的城市多是普通的地级市，一般面向本地市场的居多。
城市不同，是否是省会，人口规模，地理位置都有差异，账户搭建和只针对地级市的搭建思路不一样，另外多账户配合的思路也不一样，产品也不一样，如果单从城市级别来区分操作思路，太笼统了。
艾奇SEM：遇到节假日你是的推广策略是什么？
郭剑楠：这个跟行业和当地市场有很大关系，我所在的医疗行业，属于刚性需求，节假日投放和平时区别不大，春节期间会有收缩而已。
艾奇SEM：你怎么看待移动端的竞价推广？
郭剑楠：现在很重要，以后会越来越重要。但是移动端不少是碎片时间，这对投放思路和内容质量要求更高。不能按照PC端的思路来做。
艾奇SEM：你觉得调价软件有必要用么？
郭剑楠：没有必要，某一类词在某一市场价格基本是相对固定的，浮动不会太大，手动就可以了。
3、个人成长篇
艾奇SEM：在SEM从业生涯中，最让你有成就感的事情是哪件？
郭剑楠：一手搭建了这个团队。从一开始大领导天天过问，到后来大领导说你自己看着弄，需要啥跟我说就行了，感觉一直以来的辛苦没有白费。
艾奇SEM：你就做个简单的职业介绍呗~
郭剑楠：一个医疗SEMer。
艾奇SEM：你学什么专业的？
郭剑楠：电子商务。
艾奇SEM：你怎么进入这个行业的？
郭剑楠：学的电子商务，这个专业比较宽泛，毕业后从事过很多行业，同学介绍了医疗SEM岗位，了解了一下觉得前景不错，就一直做到现在。
艾奇SEM：你个人性格是怎样的，你觉得性格对工作有影响吗？
郭剑楠：还算沉稳，比较保守，不喜欢冒进，遇事还算冷静，脑子不容易热，但不是安于现状，属于厚积薄发那种，不喜欢忽悠别人，也不容易被人忽悠。
艾奇SEM：进入行业你是怎么学习成长起来最后做到现在这个牛逼的岗位的？
郭剑楠：奉行王阳明先生的心学，&知行合一&。
做事情，&事上练&，每做一件事情，都当做一次锻炼。不管成功还是失败，大事还是小事，都能学到东西。
处处留心皆学问，遇到东西，喜欢问为什么。
不安于现状，喜欢挑战，但不冒险。
艾奇SEM：你在职场有犯过错误吗？能否说说，另外得到过什么教训？
郭剑楠：刚工作的时候，不够灵活，胆子小，怕犯错误，太守规矩了。单位规定不许越级管理，也不许越级汇报，违者要罚款甚至开除。
有一天，董事长点名要我去总部做总经理助理，因为是口头传达，并且是总公司的人给我打电话，我也不认识是谁，再加上惊喜来的太快，我有点懵逼，就问了我直属上司，上司告诉我公司这种级别的人事变动，是有调令的，没有调令不用理他。再加上一直以来公司都不允许越级，我只能问我的上司，上司这么说，我就没理会了。
直到半个月后，总公司老总直接到我这分公司，通知我办离职。我问为什么，老总说，董事长不喜欢&抗旨不尊&的人，难得董事长器重我，我却没把人放眼里&&我百口莫辩，而我的上司去就任总助了。我特么才明白被阴了&&只怪自己图样图森破&&
艾奇SEM：你觉得怎样的领导算得上是好领导，如何处理上下级关系？
郭剑楠：老好人当不了好领导，好领导，也是个好榜样，做事有原则，不怕得罪人，有方法，不去得罪人，明白人人都有尊严，人人平等，不拿官阶去压人。
艾奇SEM：你觉得竞价的精髓是什么？怎么样做好竞价。
郭剑楠：是对数据的掌握和分析能力，以及对全局的洞察能力，做好竞价，不能只盯着账户，格局要大一点。
艾奇SEM：你平时的工作有哪些？哪些比较关键。
郭剑楠：就是一些日常的工作，比较关键的就是看数据，然后对数据做分析，另外了解企业和行业的动态。
艾奇SEM：你所在行业发展前景如何，对比之前从事的行业可以展开说说吗？
郭剑楠：医疗企业本身行业准入门槛就比较高，越来越规范之后，会更高。但是这个行业是刚性需求，受经济因素影响不大，不像有些行业，经济稍微不景气就面临倒闭的风险，是一个比较有前景的行业。不过医疗的SEM人员良莠不齐，什么人都有，以后会淘汰掉一大批人，所以要求我们需要不断提升。
艾奇SEM：你是如何选择广告投放渠道的，能否展开说说。
郭剑楠：性价比高的。
艾奇SEM：你有考虑过接下来职业生涯规划吗？可否谈谈你未来的职业规划。
郭剑楠：下一步想学学整合营销、策划和企业管理，争取早日出任CEO，走向人生巅峰。
艾奇SEM：你是如何带下属成长的？
郭剑楠：构建一个竞争和学习型的团队，注意取长补短，团队内部公平竞争，每个人都是学生，每个人都是老师。
艾奇SEM：对于新人你有什么话跟他们说？
1、三人行必有我师，择其善者而从之，其不善者而改之。
2、时刻保持学习。
3、做个有品德的人
4、知道做不到，等于不知道。
上一篇： 下一篇：
相关文章推荐：
热门阅读推荐：
图文精选：
下面将为你介绍一些设计高效着陆页的关键——可以将浏览者变成真正的买家，...
作为一名SEMer，面对日渐减少的业务量带来的重重压力，面对老板的质问很多话...
当家装行业遇到高绩效词，是否能擦出美丽的火花？也许，会产生一场爆炸。...
很多人投放搜索引擎广告之前，是抱有巨大期望的，但是一旦效果没有达到预期...
本文通过象限法对转化率（CVR）和点击率（CTR）二个维度指标进行分析，分析出...
今天聊一下增长黑客。 增长黑客是近年来国外很火热的...
3月14日晚，“十点读书”粉丝数正式突破 1500 万。2月1...
站群，一个在SEO界躲在灰暗角落的词。提到站群，很多时候会想到链轮。在那时，操作链轮，很多人都……
进行了2个多月的APP大改版即将结束，为此产品技术团队真的是尽心尽力，猛追...
互联网的发展瞬息万变。人口红利终结、移动互联异军突起、视频化进展迅速、...
据国外媒体报道，谷歌在Project Glass上采取的透明产品策略有助于该产品在市场...
增长黑客整本书最主要的内容就是围绕AARRR转化模型介绍...
这次带来的是Adhithya的一系列的关于思考车内人机交互的...
在谈“如何防止活动用户大量流失”这个话题之前，我必须先把一场活动的前前后后说清楚。……
虽然用户体验的定义只有一句话，但是如何才能让用户成本降至最低需要花费很...
在 Web/iOS/Android 等旧平台成熟稳定、VR/AR 等新平台尚未全面兴起，设计标准化成...
用户价值是用户体验的前提，没有用户价值，用户体验就是空谈。 1用户体验与...
一、运营产生数据，数据支撑运营 数据分析这件事情，...
一份优秀的网站分析报告是什么样的？The Action Dashboard（...
“以用户为中心”的理论要求网站不断优化改善用户的体验，进而提升用户的满意度，当用户的预期不……
受访页面报告提供了访客对您网站内各个页面的访问情况数据。通过这个报告，...
百度统计为网站接入者提供了多维度的数据报告，其中一些报告是用户经常使用...
成为数据科学家很有意思的一点是我们会被要求预测未来。...
6月21日，新华社微信公众号发布的《刚刚，沙特王储被废...
作为移动端APP产品运营最重要的运营手段，消息推送(p...
作为移动端APP产品运营最重要的运营手段，消息推送(push)被越来越多的APP厂商所重视，在信息泛滥的移……
在未来1-2个月里,每周二、四,你可以在三节课微信公号看到这个连载,遇突发事件...
今天亮哥飞深圳,明天要在华为开一场单口相声,正好,后台有同学问到了社区运营...
互联网产品是满足网络用户需求的工具，产品的分类有很多，以终端划分可分为...
产品都有生命周期，比如种子期、成长期、爆发期、衰落...
用户获取的成本越来越高，用户获取越来越困难，不妨使...
用户获取的成本越来越高，用户获取越来越困难，不妨使用落地页，轻松实现用户增长。……
本文作者希望通过显性需求和隐性需求的讲述，帮助大家如何快速分析出目标用...
策划一个优质的活动，需要运营人员具备两种素质，一种素质是策划活动的能力...
上周小贤给我安利了有一位非常具有成长代表性的运营朋友（冷威龙）。他从大...
　在做内容运营时，内容审核是一个绕不开的话题。运营...
在微博刚兴起时，由于其带来的价值有限以及各初创团队...
通过分析测试确定早期的内容方向之后，接下来面临的问题就是持续地输出内容...
自媒体成了新的淘金蓝海，大号们争先恐后开展内容电商（据新榜 2016 年数据统...
热门关键词如何进行用户需求分析_百度知道
如何进行用户需求分析
我有更好的答案
建议解决方法和附加信息.需求分析的任务开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口.了解相关质量属性的重要性.商讨实施优先级的划分、评价、编写文档等所有活动.需求开发活动包括以下几个方面、特性或属性,使得用户能完成他们的任务,从而满足了业务需求.在软件需求规格说明书 (SRS)中说明的功能需求充分描述了软件系统所应具有的外部行为、测试、质量保证、源代码和测试用例联系起来以实现跟踪.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话.这种合同都包含在编写的需求文档与模型中,即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生.目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题.对于商业最终用户应用程序.需求的类型下面这些定义是需求工程领域中常见术语的定义.软件需求包括三个不同的层次:业务需求,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述.结果这个小组只好手工抄写源代码文档以供代码检查,需求并未编写成文档;错误跟踪系统&quot、产品高层次的目标要求,它们在项目视图与范围文档中予以说明.2.用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务.系统的分析人员说:&我们想与你谈谈你的需求.&客户的第一反应便是:&我已经将我的要求都告诉你们前任了.对一个大型系统来说.4,当他们开发完这个工具后; ;.百事通而实际上,UGGs、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集.这说明那怕需求明确无误并构思准确,如果我们没有编写文档.评审提出的需求变更,这在使用实例(use case)文档或方案脚本说明中予以说明.3.功能需求(functional requirement)定义了开发人员必须实现的软件功能.有些需求分析专家拓展了这个概念.2,现在我要的就是给我编一个系统&quot.业务需求(business requirement)反映了组织机构或客户对系统.它描述了系统的行为:图4-1 需求工程域的层次分解示意图需求开发可进一步分为:问题获取.近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是.使当前的项目计划与需求一致.1.将所收集的用户需求编写成文档和模型.客户的接受仅是需求成功的一半,开发人员也必须能够接受他们,并真正把需求应用到产品中.了解实际用户任务和目标以及这些任务所支持的业务需求,那完全是自欺欺人.需求的另外一种定义认为需求是&用户所需要的并能触发一个程序或系统开发工作的说明&、业务规则、质量属性,因此新的分析人员不得不从头做起.在整个项目过程中跟踪需求状态及其变更情况.以上几点说明是我总结了成功实施项目后系统分析人员的经验,同时也根据国内外的其他系统实施的相关成功经验:确定产品所期望的用户类别.获取每个用户类的需求.同时这也是一旦做错:定义需求基线(迅速制定需求文档的主体).分析源于用户的信息以区别用户任务需求、功能需求.这些定义强调的是产品是什么样的,这种承诺具体体现在项目解决方案上.让每项需求都能与其对应的设计、项目管理以及相关项目功能中都起了重要的作用,进行了总结:&quot.软件需求规格说明在开发、评估每项变更的可能影响从而决定是否实施它.以一种可控制的方式将需求变更融入到项目中.他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误.事实上,需求文档在开发过程中一直起指导作用.3.需求分析过程可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适.通常的需求管理活动包括;外部界面的具体细节,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的,是在开发过程中对系统的约束,你就确信你已明白用户的需求,而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性:需求是指明必须实现什么的规格说明;中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件;从系统外部能发现系统所具有的满足于用户的特点、功能及属性等&,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能,如图4-1所示.估计变更需求所产生影响并在此基础上协商新的承诺.从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的&需求&术语存在、规范和合约.但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们如何知道项目于何时结束?而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢?然而,这个人们主要是指客户,但一般情况下,真正的&需求&实际上在人们的脑海中,因为另外一些可能属于子系统(或软件部件).作为功能需求的补充,软件需求规格说明还应包括非功能需求,它描述了系统展现给用户的行为和执行的操作等.它包括产品必须遵从的标准,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难,软件功能需求也许只是系统需求的一个子集.评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明之前将问题都弄清楚.需求管理需要&建立并维护在软件工程中同客户达成的合同&quot、用户需求和功能需求(也包括非功能需求),软件达不到期望目标也只能是咎由自取了.相反的情况,我曾见一个要集成到&quot1.概念需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求.关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起;性能要求;设计或实现的约束条件及质量属性.所谓约束是指对开发人员在软件产品设计和构造上的限制.质量属性是通过多种角度对产品的特点进行描述,从而反映产品功能.多角度描述产品对用户和开发人员都极为重要.下面以一个字处理程序为例来说明需求的不同种类.业务需求可能是:&用户能有效地纠正文档中的拼写错误&,该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器.而对应的用户需求可能是&找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词&.同时,该拼写检查器还有许多功能需求,如找到并高亮度提示错词的操作;显示提供替换词的对话框以及实现整个文档范围的替换.从以上定义可以发现,需求并未包括设计细节、实现细节、项目计划信息或测试信息.需求与这些没有关系,它关注的是充分说明你究竟想开发什么.项目也有其它方面的需求,如开发环境需求或发布产品及移植到支撑环境的需求.尽管这些需求对项目成功也至关重要,但它们并非本书所要讨论的.5.需求分析的原则不重视需求过程的项目队伍将自食其果.需求工程中的缺陷将给项目成功带来极大风险,这里的&成功&是指推出的产品能以合理的价格、及时地在功能、质量上完全满足用户的期望.下面将讨论一些需求风险.不适当的需求过程所引起的一些风险:1. 无足够用户参与客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫,开发人员可能也不重视用户的参与.究其原因:一是因为开发人员感觉与用户合作不如编写代码有意思;二是因为开发人员觉得已经明白用户的需求了.在某些情况下,与实际使用产品的用户直接接触很困难,而客户也不太明白自己的真正需求.但还是应让具有代表性的用户在项目早期直接参与到开发队伍中,并一同经历整个开发过程.系统人员在实践过程中,也有些感觉,在实施一家公司的项目时,若无足够的用户参与,系统人员获得的需求是片面的,不完整的,这样系统在需求之初就埋下风险.2. 用户需求的不断增加在开发中若不断地补充需求,项目就越变越庞大以致超过其计划及预算范围.计划并不总是与项目需求规模与复杂性、风险、开发生产率及需求变更实际情况相一致,这使得问题更难解决.实际上,问题根源在于用户需求的改变和开发者对新需求所作的修改.要想把需求变更范围控制到最小,必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明,并将此说明作为评价需求变更和新特性的参照框架.说明中包括了对每种变更进行变更影响因素分析的变更控制过程,有助于所有风险承担者明白业务决策的合理性,即为何进行某些变更,相应消耗的时间、资源或特性上的折中.产品开发中不断延续的变更会使其整体结构日渐紊乱,补丁代码也使得整个程序难以理解和维护.插入补丁代码使模块违背强内聚、松耦合的设计原则,特别是如果项目配置管理工作不完善的话,收回变更和删除特性会带来问题.如果你尽早地区别这些可能带来变更的特性,你就能开发一个更为健壮的结构,并能更好地适应它.这样设计阶段需求变更不会直接导致补丁代码,同时也有利于减少因变更导致质量的下降.3. 模棱两可的需求模棱两可是需求规格说明中最为可怕的问题.它的一层含义是指诸多读者对需求说明产生了不同的理解;另一层含义是指单个读者能用不止一个方式来解释某个需求说明.模棱两可的需求会使不同的风险承担者产生不同的期望,它会使开发人员为错误问题而浪费时间,并且使测试者与开发者所期望的不一致.一位系统测试人员曾告诉我,她所在的测试组经常对需求理解有误,以致不得不重写许多测试用例并重做许多测试.处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍.仅仅简单浏览一下需求文档是不能解决模棱两可问题的.如果不同的评审者从不同的角度对需求说明给予解释,但每个评审人员都真正了解需求文档,这样二义性就不会直到项目后期才被发现,那时再发现的话会使得更正代价很大.4. 不必要的特性&画蛇添足&是指开发人员力图增加一些&用户欣赏&但需求规格说明中并未涉及的新功能.经常发生的情况是用户并不认为这些功能性很有用,以致在其上耗费的努力&白搭&了.开发人员应当为客户构思方案并为他们提供一些具有创新意识的思路,具体提供哪些功能要在客户所需与开发人员在允许时限内的技术可行性之间求得平衡,开发人员应努力使功能简单易用,而不要未经客户同意,擅自脱离客户要求,自作主张.同样,客户有时也可能要求一些看上去很&酷&,但缺乏实用价值的功能,而实现这些功能只能徒耗时间和成本.为了将&画蛇添足&的危害尽量减小,应确信:你明白为什么要包括这些功能,以及这些功能的&来龙去脉&,这样使得需求分析过程始终是注重那些能使用户完成他们业务任务的核心功能.5. 过于精简的规格说明有时,客户并不明白需求分析有如此重要,于是只作一份简略之至的规格说明,仅涉及了产品概念上的内容,然后让开发人员在项目进展中去完善,结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明.这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况.但在大多数情况下,这会给开发人员带来挫折(使他们在不正确的假设前提和极其有限的指导下工作),也会给客户带来烦恼(他们无法得到他们所设想的产品).6. 忽略了用户分类大多数产品是由不同的人使用其不同的特性,使用频繁程度也有所差异,使用者受教育程度和经验水平也不尽相同.如果你不能在项目早期就针对所有这些主要用户进行分类的话,必然导致有的用户对产品感到失望.例如,菜单驱动操作对高级用户太低效了,但含义不清的命令和快捷键又会使不熟练的用户感到困难.7. 不准确的计划据统计,导致需求过程中软件成本估计极不准确的原因主要有以下五点:频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析.对不准确的要求所提问题的正确响应是&等我真正明白你的需求时,我就会来告诉你&.基于不充分信息和未经深思的对需求不成熟的估计很容易为一些因素左右.要作出估计时,最好还是给出一个范围.未经准备的估计通常是作为一种猜测给出的,听者却认为是一种承诺.因此我们要尽力给出可达到的目标并坚持完成它.6.需求分析人员和用户的合作关系优秀的软件产品是建立在优秀的需求基础之上的.而高质量的需求来源于客户与开发人员之间有效的交流与合作.通常,开发人员与客户或客户代理人,如市场人员间的关系反而会成为一种对立关系.双方的管理者都只想自己的利益而搁置用户提供的需求从而产生摩擦,在这种情况下,不会给双方带来一点益处.只有当双方参与者都明白要成功自己需要什么,同时也应知道要成功合作方需要什么时,才能建立起一种合作关系.由于项目压力与日渐增,所有风险承担者有着一个共同的目标这一点容易被遗忘.其实大家都想开发出一个既能实现商业价值,又能满足用户需要,还能使开发者感到满足的优秀软件产品.软件客户需求权利书列出了十条关于客户在项目需求工程实施中与分析人员、开发人员交流时的合法要求.每一项权利都对应着软件开发人员、分析人员的义务.而软件客户需求义务书也列出了十条关于客户在需求过程中应承担的义务.如果愿意,可以将其作为开发人员的权利书.客户有如下权利:1:要求分析人员使用符合客户语言习惯的表达需求讨论应集中于业务需要和任务,故要使用业务术语,你应将其教给分析人员,而你 不一定要懂得计算机的行业术语.2:要求分析人员了解客户的业务及目标通过与用户交流来获取用户需求、分析人员才能更好地了解你的业务任务和怎样才能使产品更好地满足你的需要.这将有助于开发人员设计出真正满足你的需要并达到你期望的优秀软件.为帮助开发人员和分析人员,可以考虑邀请他们观察你或你的同事是怎样工作的.如果新开发系统是用来替代已有的系统,那么开发人员应使用一下目前的系统,这将有利于他们明白目前系统是怎样工作的,其工作流程的情况,以及可供改进之处.3:要求分析人员编写软件需求规格说明分析人员要把从你和其他客户那里获得的所有信息进行整理,以区分开业务需求及规范、功能需求、质量目标、解决方法和其它信息.通过这些分析就能得到一份软件需求规格说明.而这份软件需求规格说明便在开发人员和客户之间针对要开发的产品内容达成了协议.软件需求规格说明书可以用一种你认为易于翻阅和理解的方式组织编写.要评审编写出的规格说明以确保它们准确而完整地表达了你的需求.一份高质量的软件需求规格说明能有助于开发人员开发出真正需要的产品.4:要求得到需求工作结果的解释说明分析人员可能采用了多种图表作为文字性软件需求规格说明的补充.因为如工作流程图那样的图表能很清楚地描述出系统行为的某些方面.所以需求说明中的各种图表有着极高的价值.虽然它们不太难于理解,但是你很可能对此并不熟悉.因此可以要求分析人员解释说明每张图表的作用或其它的需求开发工作结果和符号的意义,及怎样检查图表有无错误及不一致等.5:要求开发人员尊重你的意见如果用户与开发人员之间不能相互理解,那关于需求的讨论将会有障碍,共同合作能使大家&兼听则明&.参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间.同样,客户也应对开发人员为项目成功这一共同目标所作出的努力表示尊重与感激.6:要求开发人员对需求及产品实施提供建议,拿出主意通常,客户所说的&需求&已是一种实际可能的实施解决方案,分析人员将尽力从这些解决方法中了解真正的业务及其需求,同时还应找出已有系统不适合当前业务之处,以确保产品不会无效或低效.在彻底弄清业务领域内的事情后,分析人员有时就能提出相当好的改进方法.有经验且富有创造力的分析人员还能提出增加一些用户并未发现的很有价值的系统特性.7:描述产品易使用的特性你可以要求分析人员在实现功能需求的同时还要注重软件的易用性.因为这些易用特性或质量属性能使你更准确、高效地完成任务.例如,客户有时要求产品要&用户友好&或&健壮&或&高效率&,但这对于开发人员来说,太主观了并无实用价值.正确的应是:分析人员通过询问和调查了解客户所要的友好、健壮、高效所包含的具体特性.8:调整需求,允许重用已有的软件组件需求通常要有一定的灵活性.分析人员可能发现已有的某个软件组件与你描述的需求很相符.在这种情况下,分析人员应提供一些修改需求的选择以便开发人员能够在新系统开发中重用一些已有的软件.如果有可重用的机会出现,同时你又能调整你的需求说明,那就能降低成本和节省时间,而不必严格按原有的需求说明开发.所以说,如果想在产品中使用一些已有的商业常用组件,而它们并不完全适合你所需的特性,这时一定程度上的需求灵活性就显得极为重要了.9:获得满足客户功能和质量要求的系统每个人都希望项目获得成功.但这不仅要求你要清晰地告知开发人员关于系统&做什么&所需的所有信息,而且还要求开发人员能通过交流了解清楚取舍与限制.一定要明确说明你的假设和潜在的期望.否则,开发人员开发出的产品很可能无法让你满意.客户有下列义务:1:给分析人员讲解你的业务分析人员要依靠你给他们讲解的业务概念及术语.但你不能指望分析人员会成为该领域的专家,而只能让他们真正明白你的问题和目标.不要期望分析人员能把握你们业务的细微与潜在之处,他们很可能并不知道那些对于你和你的同事来说理所当然的&常识&.2:抽出时间清楚地说明并完善需求客户很忙,经常在最忙的时候还得参与需求开发.但无论如何,你有义务抽出时间参与&头脑风暴&会议的讨论,接受采访或其它获取需求的活动.有时分析人员可能先以为明白了你的观点,而过后发现还需要你的讲解.这时,请耐心一些对待需求和需求的精化工作过程中的反复,因为它是人们交流中的很自然的现象,何况这对软件产品的成功极为重要.3:准确而详细地说明需求编写一份清晰、准确的需求文档是很困难的.由于处理细节问题不但烦人而且又耗时,故很容易留下模糊不清的需求.但是,在开发过程中,必须得解决这种模糊性和不准确性.而你恰是为解决这些问题作出决定的最佳人选.不然的话,你就只好靠开发人员去正确猜测了.在需求规格说明中暂时加上待定(to be determined, TBD也可采用汉语拼音略写&DQD:待确定&)的标志是个不错的办法.用该标志可指明了哪些需要进一步探讨、分析或增加信息的地方.不过,有时也可能因为某个特殊需求难以解决或没有人愿意处理它而注上TBD标志.尽量将每项需求的内容都阐述清楚,以便分析人员能准确的将其写进软件需求规格说明中.如果你一时不能准确表述,那就得允许获取必要的准确信息这样一个过程.通常使用所谓的原型技术.通过开发的原型,你可以同开发人员一起反复修改,不断完善需求定义.4:及时地作出决定正如一位建筑师为你修建房屋,分析人员将要求你做出一些选择和决定.这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等.有权做出决定的客户必须积极地对待这一切,尽快做处理、做决定.因为开发人员通常只有等你做出了决定才能行动,而这种等待会延误项目的进展.5:尊重开发人员的需求可行性及成本评估所有的软件功能都有其成本价格,开发人员最适合预算这些成本(尽管许多开发人员并不擅长评估预测).你所希望的某些产品特性可能在技术上行不通,或者实现它要付出极为高昂的代价.而某些需求试图在操作环境中要求不可能达到的性能或试图得到一些根本得不到的数据,开发人员会对此作出负面的评价意见,你应该尊重他们的意见.有时,你可以重新给出一个在技术上可行、实现上便宜的需求,例如,要求某个行为在&瞬间&发生是不可行的,但换种更具体的时间需求说法(&在50ms以内&,但若没有准确的技术分析不能轻易下结论),这就可以实现了.6: 划分需求优先级别大多数项目没有足够的时间或资源来实现功能性的每个细节.决定哪些特性是必要的,哪些是重要的,哪些是好的,是需求开发的主要部分.只能由你来负责设定需求优先级,因为开发者并不可能按你的观点决定需求优先级.开发者将为你确定优先级提供有关每个需求的花费和风险的信息.当你设定优先级时,你帮助开发者确保在适当的时间内用最小的开支取得最好的效果.在时间和资源限制下,关于所需特性能否完成或完成多少应该尊重开发人员的意见.尽管没有人愿意看到自己所希望的需求在项目中未被实现,但毕竟是要面对这种现实的.业务决策有时不得不依据优先级来缩小项目范围或延长工期,或增加资源,或在质量上寻找折衷.7:评审需求文档和原型正如我们将在第1 4章讨论的,无论是正式的还是非正式的方式,对需求文档进行评审都会对软件质量提高有所帮助.让客户参与评审才能真正鉴别需求文档是否的确完整、正确说明了期望的必要特性.评审也给客户代表提供一个机会,给需求分析人员带来反馈信息以改进他们的工作.如果你认为编写的需求文档不够准确,就有义务尽早告诉分析人员并为改进提供建议.通过阅读需求规格说明,很难想象实际的软件是什么样子的.更好的方法是先为产品开发一个原型.这样你就能提供更有价值的反馈信息给开发人员,帮助他们更好地理解你的需求.必须认识到:原型并非是一个实际产品,但开发人员能将其转变、扩充成功能齐全的系统.8:需求出现变更要马上联系不断的需求变更会给在预定计划内完成高质量产品带来严重的负面影响.变更是不可避免的,但在开发周期中变更越在晚期出现,其影响越大.变更不仅会导致代价极高的返工,而且工期也会被迫延误,特别是在大体结构已完成后又需要增加新特性时.所以一旦你发现需要变更需求时,请一定立即通知分析人员.9:应遵照开发组织处理需求变更的过程为了将变更带来的负面影响减少到最低限度,所有的参与者必须遵照项目的变更控制过程.这要求不放弃所有提出的变更,对每项要求的变更进行分析、综合考虑,最后作出合适的决策以确定将某些变更引入项目中.10:尊重开发人员采用的需求工程过程软件开发中最具挑战性的莫过于收集需求并确定其正确性.分析人员采用的方法有其合理性.也许你认为需求过程不太划算,但请相信花在需求开发上的时间是&很有价值&的.如果你理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术,那么整个过程将会更为顺利.尽管去询问分析人员为什么他们要收集某些信息,或参与与需求有关的活动.系统分析人员在开发过程中可能会遇到以下问题,一些很忙的客户可能不愿意积极参与需求过程,而缺少客户参与将很可能导致不理想的产品.故一定要确保需求开发中的主要参与者都了解并接受他们的义务.如果遇到分歧,通过协商以达成对各自义务的相互理解,这样能减少今后的摩擦.7.需求文档需求开发的最终成果是:客户和开发小组对将要开发的产品达成一致协议.协议综合了业务需求、用户需求和软件功能需求.就像我们早先所看到的,项目视图和范围文档包含了业务需求,而使用实例文档则包含了用户需求.你必须编写从使用实例派生出的功能需求文档,还要编写产品的非功能需求文档,包括质量属性和外部接口需求.只有以结构化和可读性方式编写这些文档,并由项目的风险承担者评审通过后,各方面人员才能确信他们所赞同的需求是可靠的.你可以使用以下三种方法编写软件需求规格说明:用好的结构化和自然语言编写文本型文档.建立图形化模型,这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系.编写形式化规格说明,这可以通过使用数学上精确的形式化逻辑语言来定义需求.由于形式化规格说明具有很强的严密性和精确度,因此,所使用的形式化语言只有极少数软件开发人员才熟悉,更不用说客户了.虽然结构化的自然语言具有许多缺点,但在大多数软件工程中,它仍是编写需求文档最现实的方法.包含了功能和非功能需求的基于文本的软件需求规格说明已经为大多数项目所接受.图形化分析模型通过提供另一种需求视图,增强了软件需求规格说明.
为您推荐：
您可能关注的内容
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。