做暧暧暖免费观看网站,做一个app软件大概需要多少钱,中国建筑网官网企业愿景,网站备案号有效期#xfeff;#xfeff;三种客户类型#xff1a; 1 的确很专业。能提供基本可用的文档#xff0c;能给出要求规范#xff0c;能向你提出有价值疑问和担心。能快速回答你的问题。2 以为自己很专业。 给的文档基本没法用。没法提供规范和标准#xff0c;喜欢指指点点和挑毛… 三种客户类型 1 的确很专业。能提供基本可用的文档能给出要求规范能向你提出有价值疑问和担心。能快速回答你的问题。 2 以为自己很专业。 给的文档基本没法用。没法提供规范和标准喜欢指指点点和挑毛病。只会向你提傻逼问题。基本回答不了你的问题。 3 啥都不懂。 不给文档。能给你几个参考范例打开数个网站告诉你我要做成和它们一样的。只能等着你来问100个问题。。。 四种合作方式 1 创始人直接和你接洽交流结果的协商余地很大需求不易反复细节不会被过分追究。更容易统一想法执行力高你能对项目和产品产生更大的影响。但往往甲方会过于急进。 2 项目代表和你接洽这是非常理想的状况了。甲方有一个产品经理或IT经理能作为代表负责汇总甲方的所有需求和标准和你沟通他有过与外包方合作的经验知道危险的环节所在能承担翻译和桥梁的角色帮助你阻挡和说服不恰当的需求。能集中地承担责任也会积极地和你一起规避项目失败的风险。非常lucky 3 专业部门和你接洽IT部门或技术部门的某个高级别工程师负责和你沟通你们会比较有共同语言甚至惺惺相惜。技术方面的合作会很顺利但是涉及到产品和需求他们无法帮你挡住来自市场或内容部门的麻烦。合作开始后很有可能在技术思路上产生分歧如果在程序部分耽误了太多时间而产品端被忽视你有可能受到其它部门及上层的质疑。 4 市场部门内容部门和你接洽最好你先去烧烧香准备好最坏打算。专业和思考模式的差异会导致你们关心的问题完全不一样。你首要满足了他们关心的地方后切记留出不少时间来解决那些他们看不见但实际上非常重要的问题。另外你需要做更多的事写更多的文档主动和专业部门联系力争和决策层有沟通。 如果你面临了第3和第4种状况 请先熟悉一下甲方的组织机构。例如一般 内容型、媒体、渠道、宣传类项目的开发 需求 和 市场部门 沟通 功能 和 内容部门 沟通 软硬广告位或专题 等 和 销售部门 沟通如果是改版类广告位合同可能提前半年签订一定要和销售协调好 技术、系统、安全、统计问题等 和IT、网管、数据统计部门 沟通 某些问题 需要和 总裁助理、行政 等官僚部门沟通。 部分特别的内容 需要和 创意、美工、文案部门 沟通 当以后确定需求的时候如果发现这些部门的人没有参与请提前与之沟通。 第1和第2种状况可跳过上述步骤。 八步流程: 第一步听听客户想要什么。 以及预计工期和预算这两件事上一点都不要腼腆这是关系项目成本最重要的元素。 第二步提问。 1 项目的目的是什么。品牌、渠道、流量、广告费、用户数、VC、其它商业模式 2 甲方的优势和资源是什么。(钱内容资源人力大战传统行业优势) 3 尽量提供可视的参照及借鉴对象 。应用上有没有可解决的。界面上比较喜欢哪个站点的设计。交互上有没有可参考的对象 4 其它工程的细节问题。 比如工期上的上下限是什么 是否会需要与现有系统整合、是否需要数据迁移是否会需要甲方的工程师合作 是否有开发平台的限制 是否有代码规范及标准最终需要哪些开发文档和源码 第三步取得共识。 与甲方取得共识非常重要保证你所理解的那他们所理解是同一个东西。这一步需要你根据掌握的情况列出提纲画出草图或框架图。有参考对象的标注上哪个部分会比较像某某。 然后请甲方确认 这个框架是他们想要的。 第四步给出工程时间轴。 到了这一环节就需要你的项目经理组织所有团队成员坐下来讨论先划分功能模块然后讨论每个功能模块的可行性、难度、花费时间、bug发生率、测试耗时。再讨论一头一尾 系统搭建和系统整合的所需时间。 项目经理对工程耗时和可行性完全心里有数后画出工程的时间轴。包括并行状况里程碑节点、测试期、缓冲期等如何画工程时间轴甘特图我以后会专门写一篇。时间轴要实事求是并且预留好充分的缓冲期工程师估时*2*110%。 第五步需求做减法。 大部分情况下时间轴表现的状况都会超出客户的预期。如果客户对工期没有要求也要提醒客户考虑 项目可行性风险、市场等候成本、市场或战略变化导致的浪费。 韩磊有一篇《大褂还是内裤》的blog很形象地描述过这个问题。 所以要和甲方一起尽量对需求做减法。把整体需求拆成2~3期落实只开发最基础和最必要的一期需求。 这时签订正式开发协议。 不要忘了计算 需求文档和产品方案 的费用。 第六步撰写详细的需求文档。 《框架图》下载西乔的模版。可视化表现产品的框架、布局、细节、部分交互。 《流程图》》下载西乔的模版。理出产品的逻辑关系。 《功能需求文档》》下载西乔的模版。 罗列 功能、应用、交互上细节分离基础件作为开发分工和系统及数据构造的 基础文档。 第七步商讨需求文档 尽量召集甲方所有相关部门的负责人 一起召开这次会议商讨需求文档。 在阅读到你的需求文档之前可能甲方的大部分人都对产品没有可视和具象的理解。也从未关注到细节和逻辑关系。所以需要产品经理从全局角度和逻辑线索讲解文档。 更可能发生的状况是没有人坚持看完或仔细看过你写的文档。 所以这次会议是一场耐心和体力的考研。 文档作者需要 分别向各个部门指出他们需要关注和拍板的地方听取他们的建议将任何变动要求都分类记录。 安抚情绪。解答困惑。控制需求变动。 第八步定稿需求文档 分职能部门类建立表格文档。将会议协商中所有 分歧性意见和变动意见 都逐条写下。抄送所有相关负责人。并要求他们纠正分歧和确认变动。 所有会议中可能被提出但是未出现在此邮件文档中的 意见不会列入需求文档中。当然允许可以书面反馈补充。 根据确认过的反馈回复修改需求文档。直到需求文档定稿。 协商讨论和文档修改可能经过2~3轮。所以需要项目经理提前提醒客户注意搜集需求和文档定稿的 时间线里程碑。如果这个阶段耗时过久会严重延误整个项目进度。要求客户尽量集中地谨慎地提出建议和修改。 三种武器 需求问卷无论是面对专业还是不专业的客户交流中都有很多没考虑到的遗漏点这些他们看不到的点往往是最关键的点也有可能是被客户故意规避掉的点。 此时撰写一份需求问卷非常有效。 问卷里提出重要的全局性的问题需要客户逐条书面回答。 某些问题可以提供多个选项答案及补充区域。 某些问题 需要确凿的态度Yes或NO。 不要提出需要客户写一大段表述性文字的问题。 需求问卷精简扼要有针对性重要不要浪费客户的时间不要把写字的工作量丢给客户。 书面确认 书面确认 一方面包括 所有讨论结果、建议 和变更 都要有书面文字备查。电话和开会上说说的这些口头表达都没有效应。这一点一开始你就要声明甚至有必要写在合同里。 另一方面包括你要尽量提供书面的可视化的东西 来让甲方确认。 甲方很难完备或是提供适合工程使用的文档。所以千万不要在项目初期的需求文档上省懒。 邮件抄送 邮件抄送一种明确职责的方法。对方可能不看你的邮件但代表你告之过。 尽可能地抄送重要邮件给战略层可以能避免一些重大问题的出现。 结语 到此看起来搜集和确定需求真是一件耗时耗力的工程。 其实在理想的工程项目时间分配中1/3的时间用于确定所有需求和开发文档。 1/2的时间用于测试解决bug安全测试、压力测试等。真正用于开发的只应该占1/6。 当然web项目的开发肯定达不到这个理想状况。但是也由此可见需求阶段的重要性和工作量。这一阶段省一分力或有一分遗漏到了项目后期可能需要十分力来弥补。 转载于:https://www.cnblogs.com/hedianwei/p/5671366.html
