用户需求

1.MSF开发模型从传统的瀑布模型和螺旋模型发展而来，并且MSF对敏捷和CMMI支持，那么，我们可以认为MSF模型是目前最好的开发模型吗？ 2.什么项目适合敏捷开发？敏捷开发对比MSF开发有哪些值得学习的地方？ 3.目前，获得用户需求的方式有焦点小组、深入面谈、卡片分类、用户调查问卷、用户日志研究、人类学调查、眼动跟踪测试、快速原调查、A/B测试。那么，在我们真正的软件开发中，在获取用户需求方面，我们主流的获取用户需求方式是什么？ 4.项目经理人才的主要来源是来自于哪里？作为计算机专业的科班生，我们具备一定的专业能力，那么，我们刚去一家公司，可以担任他们的项目经理职位吗？ 5.由于软件测试阶段可能检查不出产品的所有BUG就把软件交付给用户了，那么，我们可以认为软件测试是软件开发中容错率最高的环节吗？ 来源： https://www.cnblogs.com/zhhzsc/p/11578790.html

我选择说的三种软件分别是游戏，操作系统以及工具软件。 没有软件开发者找我，并不全是盈利，有的是吸引用户群有的是赚钱。 有需求就会去找，一般都是下载。 游戏会有Bug，操作系统和工具软件都相对来说比较稳定，很少遇到。有的时候停服务更新，有的时候用户在使用时更新。 很多软件出现时间我并不知道，在网上也没有查到。 软件和硬件最大的不同，就是软件虚拟的，存在于电脑中的，而硬件是实体，可以用手去触摸到的。软件具有很多特性，可以复制拷贝扩展和修改。 我第一次用的软碟通（制作系统镜像文件）是很早之前了，因为电脑系统炸了我需要一个系统映像，所以我要使用，正版且可以免费使用，企业使用收费。 依然在用，方便快捷，免费使用，坏处可能说功能局限性，只能做Windows的系统镜像，做不了Linux的。 应该还会存在，因为他对个人用户一直保持免费的姿态。 来源： https://www.cnblogs.com/meiweimin/p/11524359.html

第一阶段：目标解读 　　在建立用户画像前，首先需要明确用户画像服务于企业的对象，根据业务方需求，未来产品建设目标和用户画像分析之后预期效果； 第二阶段：任务分解与需求调研 　　经过第一阶段的需求调研和目标解读，我们已经明确了用户画像的服务对象与应用场景，接下来需要针对服务对象的需求侧重点，　　　　结合产品现有业务体系和“数据字典”规约实体和标签之间的关联关系，明确分析纬度； 第三阶段：需求场景讨论与明确 　　在本阶段，数据运营人员需要根据前面与需求方的沟通结果，输出《产品用户画像规划文档》，在该文档中明确画像应用场景、最终开发出的标签内容与应用方式 ，并就该份文档与需求方反复沟通确认无误。 第四阶段：应用场景与数据口径确认 　　经过第三个阶段明确了需求场景与最终实现的标签纬度、标签类型后，数据运营人员需要结合业务与数据仓库中已有的相关表，明确与各业务场景相关的数据口径。在该阶段中，数据运营方需要输出《产品用户画像实施文档》，该文档需要明确应用场景、标签开发的模型、涉及到的数据库与表，应用实施流程； 第五阶段：特征选取与模型数据落表 　　本阶段中数据分析挖掘人员需要根据前面明确的需求场景进行业务建模，写好HQL逻辑，将相应的模型逻辑写入临时表中，抽取数据校验是否符合业务场景需求。 第六阶段：线下模型数据验收与测试 　　数据仓库团队的人员将相关数据落表后，设置定时调度任务

同事问了一个问题，当拿到一个需求后如何做，以下是我们两个人的交流，说不定哪天面试会用上，记录一下，如果能帮到你很开心。 我：先和用户交流，弄清一点需求后，然后实现一个poc,实现poc后拿给用户看，用户看到poc后肯定会给出意见，可能是他想要的可能不是他想要的，然后进一步和用户沟通，进一步确定需求 ，这个过程重复，直到实现用户的需求达到用户的满意度。poc达到用户的需求后就正式开发，这样的好处是在poc代码开发中不用考虑代码优化和可能存在的bug,主要是实现用户的需求。 jayden : 结合下我们薪薪乐的情况，poc 其实已经达成了，是由 Jocky 达成的（他的原型稿即 poc）。然后就到达我们这边，我们这边会讨论下 poc 中的实现并估时。然后就是直接开发了。从实际上来说，新功能按 poc 实现，或者我们自己决定实现，或者反馈 Jocky 重新讨论后实现。原有功能的修改，除了上述 3 种，我们还得依赖于既有功能来实现（这个实现和 poc 有可能不一致）。 具体开发阶段，新功能比较容易，把界面，交互和接口返回的数据按 poc 的要求组合起来就成了（套路说起来非常简单的一句话，编码起来可能要和接口的兄弟各种讨论了 ） 如果有旧有功能修改的，这个情况就比较费脑一些，有时新的修改依赖于既有功能较少，那就干脆重新实现了，就像新功能一样 . 有时反过来，又有比较深的依赖，咋办呢 1.

我们在确定文章页面的长尾关键词以后，剩下的就是怎么做文章质量的优化了。这里的质量包含了几个方面： 1、首先是长尾关键词的布局，文章里面怎么布局长尾关键词呢？ ①完整的长尾词的布局 理论上来说完整的长尾关键词更加有利于有关性计算，大家可以看到，如果页面标题里面完整出现某个长尾词，那么这个页面在关键词排序的时候肯定会有一些优势。但前提是不要影响文章的语义逻辑。 ②分词的利用和布局 以“文章长尾关键词布局”这个长尾词为例，如果频繁出现这么长的词，可能语义会很奇怪，还可能造成词语堆砌。 其实，即便是文章内容里面没有出现很多次完整的长尾关键词，那么“文章”、“长尾关键词”、“布局”这三个分词也足以表达中心内容，不会影响到整篇文章的相关性和质量。 2、要注意用户搜索需求，尽量让文章覆盖到更多的需求，比如说长尾关键词的用户主要需求是A，但是同时存在着相关需求的B和C，那么我们在编辑文章的时候，也可以把B和C也整合进来，这样就提高了文章内容的质量，对于文章长尾关键词的排名也有帮助。 3、要注意文章内容的可读性，只有可读性高才能让用户停留的时间长，这对于文章长尾关键词的排名也是有帮助的。 来源： https://www.cnblogs.com/djh18170512128/p/11939330.html

1.为什么决定从工程师转向产品经理? 我觉得产品相对于技术更加宏观一点，视野更加开阔一点，比如说我之前做技术的时候只是想着怎么把功能实现了，可是我并不清除这个功能是为了解决哪些需求产生的，这个需求的背景又是什么，当时我们公司也比较小嘛，流程也不正规，没有需求评审、需求移交之类的会议，prd写的也不清楚，很多事情都是口口相传的，这种感觉不是很好，并且我感觉我的性格要比开发更活跃一点，然后就转了产品。 2.拥有技术背景的最大优势是什么?最大的劣势又是什么? 优势是和技术沟通起来会更加方便一点，并且因为懂技术，所以在验收的时候我有时候也会考虑性能的问题，比如这个页面卡顿，我首先会通过抓包看是后台接口有问题还是前端绘制的时候有问题，产品上线之后的前几天我会每天登录bug搜集平台，看各个端的稳定性，会不会有一些线上没测出来的bug遗留，如果有问题给具体有问题的端的技术负责人沟通协调解决，根据bug搜集平台还可以做一些预测，比如说最近要发布iOS13.0，因为很多人安装的有测试版，我们就可以通过bug搜集平台看看最近新出了哪些bug，是否和13.0相关，防止13.0发布以后才发现bug。 当然这也是缺点，劣势很多事情会站在技术的角度考虑问题。以至于很多可能比较耗时耗力的需求，就不太愿意开发 3.在工程师向产品经理转型的过程中最大的收获是什么? 有什么是你希望你在工程师的时候就知道的事情?

当前，人工智能已成为席卷全球几乎所有行业的创新大潮。在中国，人工智能的发展也如火如荼。而在众多行业中，酒店业无疑拥有大量的人工智能使用场景。 未来酒店将变得越来越智能化，短时期内，酒店行业将出现以下趋势： 酒店需求继续强劲。随着中国居民的收入增长、旅游业在近年来保持30%以上的增长，大量的需求会推动酒店业的发展，我们可以从一些景区看到、到旅游季节的时候，“一床难求”的现象时又发生;消费主体已经从“60、70”变化为“80、90”以及“00”，80、90的经济基础逐渐变得稳健，而这部分人喜欢“玩”，产生对更多酒店的需求。 精品酒店引领未来。由于消费主体发生变化、消费者对酒店的要求逐渐变高，简单地“洗、息、睡”型的酒店很难满足目前的主流消费人群的需求。当前消费者是60、70、80、90共存的时代，文化需求已经不再简单的是“中式、欧式、现代”之分了;每个人的年龄段、成长背景、出生地域、成长经历不一样，而产生的需求也不一样，精品酒店恰好可以给他们形成细分有针对性的用户体验。 酒店对OTA的依赖加剧。目前市场上的酒店“格式化”、“同质化”严重，由于“信息化、数据化、流量化”的时代来临，OTA确实很好的解决了用户的方便性;大部分的酒店还没有自己的PC端、移动端的导流方式，同时缺乏与用户的互动，加之OTA操作简单直接、故而对OTA上瘾。 人工智能和微智能会逐渐广泛地在酒店中运用

竞品分析报告的目的是了解竞品情况，所谓知己知彼，百战不殆，商场如战场。作用有以下几点： 了解：了解竞品定位、产品、用户、业务、盈利、公司情况，行业趋势。 对比：对比中找差异，找行动点。 验证：竞争对手的项目或功能，能帮我们发现新的机会点，或验证需求是否成立。 竞品分析明确了目的之后，接下来就要明确要分析哪些竞品，因为竞品太多，我们只会对重要竞品进行分析。 选好了竞品之后，这个时候开始正式着手分析。但竞品分析报告，是一个工作量很大的工作，我更倾向于偏宏观的来分析。 以下是报告内容： 行业分析（市场规模、盈利情况、增长态势）； 产品定位及发展策略； 公司情况（员工数量、重要背景、融资情况）； 用户情况（目标用户、用户数据）； 市场数据（业务规模、市场占有率）； 核心功能； 产品优缺点； 运营及推广策略； 总结&行动点。 很多人会提到需要加入交互设计、视觉设计、页面框架，我倾向于不要，要也是粗略的概括一下。个人根据情况选择。 加入行业分析，是因为竞品不一定都是同需求的同类产品。 来源： https://blog.csdn.net/szdszxyj/article/details/100080065

Web项目测试流程大致包含的几个阶段：立项、需求评审、用例评审、测试执行、测试报告文档 立项后测试需要拿到的文档 1.需求说明书 2.原型图（及UI图） 3.接口文档 4.数据库字典（表的数量、缓存机制） 需求评审 参加人员：开发、测试及需求人员，由需求人员主持讲解 为了会议的有效举行，测试及开发人员需要在会议开始之前熟悉需求文档及原型，将有疑问的点标注出来再会议中一一确认，对不明确的点要督促开发及需求一并关注，对不能立马得到肯定回复的点记录在一起，会议结束后，邮件整理好发出给各位参与人员。 在项目可控的进度中，需求评审是必要的环节。当然，有些比较小的项目会忽略此阶段，个人认为这是非常有必要的环节，这不但减少了后期开发、测试、需求人员的意见分歧，还保证了项目的进度。 用例编写（同时根据开发计划编写测试计划） 用例功能类型 大致分为7类： 1.主流程：该模块实现的主要功能流程 2.备选流：不一定完成执行一个功能，而是终止了流程 3.异常流：由于某些异常原因，使流程的功能无法实现 4.业务规则：必填项，强制的要求 5.正常类：返回功能、必填项输入范围、页面按钮的切换等 6.异常类：网络异常、返回异常等 7.界面检查：针对每个页面的样式及内容检查 注：几个大类中主流程、正常类、异常类和界面检查四个大类使用的比较多，一个项目不需要涵盖所有的用例类别

软件测试基础入门知识点 一、行业前景 前言 ​ 程序员之间流传着这样一句话：有人喜欢创造世界，他们做了开发工程师，有人喜欢挑毛病，所以他们做了测试工程师。 什么是软件测试 软件测试就是利用手工或测试工具按照测试方案和流程对产品进行功能和性能测试，简单的来说就是为软件做“质检”。 软件测试的重要性 ​ bug 的经济损失： ​ 软件 bug 对我们的生活，工作都会带来毁灭性的破坏。据悉，每年的软件 bug 会让整个市场经济带来近600亿美元的损失！ 成立软件测试部门的原因 软件测试能提前发现软件存在的缺陷 社会分工越来越细 -- 要求软件测试越来越精细 专人负责，责任到位 二、测试基础 2.1、什么是软件测试 ​ 在规定的条件下对程序（App，.exe安装文件，网页等）进行操作，从而发现错误，对软件质量进行评估的一个过程。 2.2、软件测试的目的 ​ 是想以最少的人力，物力和时间找出软件中潜在的各种错误与缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患以及带来的商业风险。（注意这个问题的答案，经常会与软件测试的定义混淆） 2.3、软件测试的定义 ​ 使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。 2.4、软件测试的原则 所有的测试都应追溯到用户需求（视频网站，点击后最大化