解决方案部规章制度_第1页
解决方案部规章制度_第2页
解决方案部规章制度_第3页
解决方案部规章制度_第4页
解决方案部规章制度_第5页
已阅读5页,还剩168页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

****科技有限公司解决方案部规章制度科技有限公司目录TOC\o"1-2"\h\u179861解决方案部组织架构 1191372售前技术支持部 1262082.1部门职责 1168012.2岗位设置 2269342.3岗位职责说明 2151972.4工作理念 6192992.5技术支持工作类型 692922.6技术支持部制度 7269632.7技术支持部流程 20109923技术研发部 24297463.1部门职责 24280493.2研发理念 25173333.3研发类型 26300673.4岗位设置 2748433.5岗位职责说明 27299173.6研发制度 33267913.7研发流程 5598143.8附则 69123694项目实施部 73242524.1部门职责 73281834.2岗位设置 74125784.3岗位职责说明 7445704.4实施理念 79150044.5实施类型 79179924.6实施制度 8075174.7实施流程 102179235运维支撑部 131117325.1部门职责 132201675.2岗位设置 132106705.3岗位职责说明 133191755.4维护理念 137204525.5维护保证 137193605.6维护类型 138108175.7维护制度 1407845.8客服流程 14771665.9行为规范 164第21页解决方案部组织架构科技有限公司解决方案部规划四个子部门,分为售前技术支持部,技术研发部,项目实施部,运维支撑部。解决方案部解决方案部售前技术支持部技术研发部项目实施部运维支撑部售前技术支持部阅读对象:公司领导商务拓展部售前技术支持部本部门人员。部门职责配合公司商务拓展部完成相关项目的售前技术支持。负责所有的售前技术支持工作,包括与用户的技术交流、技术方案编写、整理、技术方案宣讲等。配合公司商务拓展部完成相应项目的投标。标书的技术应答、系统软硬件配置、公开技术报价等工作。配合公司渠道人员做好与合作伙伴、原厂商等的技术交流工作,共同完成项目。积极完善行业解决方案,分析竞争对手产品动态,持续更新售前技术文档知识库。协助商务拓展部人员,以对公司销售业务发展方向提供咨询。岗位设置具体工作包括售前技术支持、技术方案编写整理、参与技术谈判、协助本公司内其他部门等相关工作,设置以下岗位:岗位备注售前技术支持主管组织安排售前技术支持工作技术支持工程师技术资料编写、更新、参与技术谈判技术资料员技术资料的收集、整理、传递岗位职责说明售前技术支持主管职务名称:售前技术支持主管直接上级:解决方案部总监直接下级:技术支持工程师本职工作:组织安排售前技术支持工作岗位职责:1.业务职责(1)制定、修订技术支持部的工作程序和相关的规章制度的实施细则,并组织实施;(2)负责本部门员工之间或本部门与其他部门之间工作的协调;(3)监督检查、处理反馈下属员工的工作程序、规章制度、技术支持细则的施行情况;(4)根据商务拓展部反映的问题,向技术部门提出产品改进意见;(5)负责技术支持档案管理,整理完备相关项目文档、技术文档等资料,对技术资料和方案进行审批;(7)配合公司销售人员完成相关项目的售前支持。负责所有的售前支持安排工作,协调技术支持部内部资源,积极跟进商务拓展部的项目;(8)在项目跟进阶段,跟踪、检查小组内技术支持人员的工作质量;(9)完成公司领导交办的其他工作;2、管理职责(1)组织建设:参与讨论本部门岗位设置;发现本部门岗位设置或岗位分工不合理时,及时向上级部门汇报,提出调整意见;(2)人员招聘:提出本部门岗位的用人需求,并编写该岗位的岗位职责及任职资格,提交给人力资源部门,并呈报总经理确认。面试:进行本部门岗位的初试;组织参与面试人员;(3)不合格员工处理,提出部门不合格员工的处理建议,提交总经理确认;(4)培训:提出本部门培训计划,提交总经理确认;协助公司其他部门的培训;(5)绩效考核:提出直接下级的绩效考核原则,提交管理部;根据总经理确认的绩效考核原则,与管理部商讨并确定绩效考核方法;对下级进行考评,并进行考评沟通,将考评结果提交管理部;(6)工作沟通:汇总工作报告,并与部门经理进行信息沟通,同时将这些信息传递到直接下级;负责将公司的政策规章等信息快速,清晰,准确的传递给直接下级;以书面的交付式的工作制度与下级进行沟通;(7)激励:制定本部门下级人员的激励原则和激励方法;负责落实本部门下级人员的激励方法。工作报告定期将自己的各项工作及下级人员的工作以书面的形式向上级领导报告;(8)领导能力:指导,鼓励,鞭策下级,使下级能努力工作;有办法提升下级的工作效果和工作效率;能为直接下级描绘公司的战略意图和远大前景;3、权限开展部门内部工作的自主权,对商务拓展部售前、过程及技术问题处理办法的建议权及执行权,部门内部员工考核、违规行为处罚的权力,部门内部员工雇用、解聘的建议权,要求相关部门配合工作的权力,向上级领导提交改进工作并获得答复的权利。技术支持工程师职务名称:技术支持工程师(项目组负责人)直接上级:售前技术支持主管直接下级:无本职工作:负责商务拓展部各项目的技术交流工作。岗位职责:1、承担项目的技术交流职责;2、与客户进行技术沟通,与商务拓展部技术人员沟通;3、配合售前进行技术方案的编写、投标书商务部分的编写,直至项目进入实施阶段;4、负责向技术支持主管反馈遇到的问题及工程进度工作;5、完成公司领导交办的其他工作;技术资料员职务名称:技术资料员直接上级:售前技术支持小组主管本职工作:负责技术资料的编写、收集、整理、传递。岗位职责:1、参与售前技术资料的编写工作。2、参与售前技术资料的收集工作。3、参与售前技术资料的整理工作。4、及时将售前所需资料整理传递到商务拓展部。工作理念宗旨为保证日常工作正常有序的进行,让售前技术支持过程中各个环节更紧凑,更可控,需要尽可能实现售前技术支持管理的正规化,工作过程的流程化,以便提高签约沟通效率,达到配合商务拓展部尽快完成销售的目标。要成功的完成每一个项目,需要销售人员、售前人员、项目实施人员(开发人员)、售后服务人员等密切协作。本章主要从售前技术支持人员的管理角度,针对公司实际情况,对售前技术支持的工作流程进行描述,提出了各环节的应该注意的要点,希望能对售前人员的工作有一定的帮助。技术支持范围支持公司内部由商务拓展部发出的所有技术支持需求,完成各行业技术方案的整理和编写技术支持工作类型行业解决方案的制定积极与技术研发部,项目实施部沟通,进行公司产品解决方案的编写,汇总,矫正。积极与业内各合作商沟通,了解各行业解决方案,并整理、收集、汇总。配合售前工作参与招投标到实施整个项目周期内的技术售前支持工作。技术支持地点配合商务拓展部人员全国范围内机动。技术支持部制度总则售前技术支持是公司非常重要的工作,一方面,支持具体销售活动(例如产品演示、客户沟通、需求获取等),并提供各类销售技术支持(例如参与建议书编写、技术方案编写、标书制作以及演示文档、典型案例归纳等工作)。另一方面,售前技术是公司产品理念的开创者、公司产品设计的领军者,肩负着产品发展方向、产品设计等重要工作。岗位考核制度采用综合评价方法进行绩效考核。绩效考核方案拟定原则以公司技术职称等级为基础,采用综合指标考核相结合的综合考评方法。具体考核办法以公司技术职称等级划定基本薪酬体系结构在建立售前技术经理基本薪酬体系结构过程中,要充分考虑售前技术经理在本行业从业年限及行业经验积累、IT技术能力,主要按照能力付酬,而不能仅按照销售业绩付酬,不能过分强调薪酬的变动性,而应当建立一套以公司技术职称等级标准为基础的薪酬体系结构,从而实现公司售前技术经理向售前顾问的角色转换,将售前技术经理以售前工作重点的模式,向产品战略、产品设计方向等工作重点转变。进一步来说,对于售前技术经理的激励重点不是考核,而是能力提升,只有售前技术经理具备充分的能力,才可能使售前技术经理成为企业实现技术营销、顾问式营销的关键点。技术职称等级划定基本薪酬体系结构标准为:序号技术等级职称薪酬标准1高级技术职称2中级技术职称3初级技术职称基于综合指标的评价方法综合绩效指标是用于衡量部门人员工作绩效表现的量化指标,可以使部门经理明确部门的主要责任,并以此为基础,明确部门人员的业绩衡量指标。同时,评价考核过程中,要强调销售部门对售前技术经理的评价,评价的重点是工作态度和工作效果。具体考评办法:综合评价表编号考核项评价指标权重评价标准得分1产品规划50产品规划建议专业产品需求说明书产品模块功能需求说明书季度竞争对手分析报告2售前支持30工作进度文档质量参与售前项目数量销售培训3能力提升15团队活动参与培训经验分享文档质量专业资格证书获得4人力资源考核5劳动纪律工作态度文档管理制度为保障公司技术文档安全不至于泄露,明确售前技术文档的控制管理流程,特制定此管理办法。本制度适用于所有涉及接触售前技术文档的各部门各岗位、所涉及部门都必须严格执行本管理办法。文档直接控制管理部门为解决方案部。本制度管理重点在于控制售前支持文档的完整性,不被非授权获取,不被非授权复制和传播。本制度所指文档不仅限于公司技术人员自行编写的文档,而且还包括从各合作伙伴、各渠道收集的文档等文件。文档评审制度公司提供给客户的正式文档如技术方案、报价等需要评审。内部的技术方案、产品方案也需要评审。项目需要经过用户需求、技术方案、测试方案、验收方案等评审,根据项目规模大小可选择进行。评审根据文档的重要性和项目规模可划分为部门级评审和公司级评审。部门级评审负责人是部门经理,针对普通的文档和20万以下的项目开发。原则上至少3人参加。对评审意见需要签字备案。公司级评审的负责人是公司副总或总经理,针对投标文档、报价文档和重大技术方案。原则上至少5人参加。需要签字备案。对于未提交配置库和没有评审报告的文档,商务不能加盖公司公章。不能提交给客户。文档的完整性保障文档文件均必须及时加入到指定的文档服务器中的指定文件夹中。文档的授权访问公司所有方案文档,必须存放到公司的配置管理服务器上统一管理,原则上只要更新后就必须提交,防止出现因个人电脑故障造成方案丢失或个人离职带走方案,并且通过版本管理进行追溯,便于工作。所有提交给客户的文档(包括技术方案、用户需求、商务报价等)都必须从配置管理服务器上获取,禁止员工之间直接发送,保证将来客户手里有的东西在公司服务器上都能找到。文档服务器对于共享的文档库的访问建立操作系统级的,基于身份和口令的访问授权。在文档库中设置用户,并为不同用户分配不同的,适合工作的最小访问权限。要求连接文档库时必须校验文档库中用户身份及其口令。在文档库中要求区别对待不同用户的可访问权、可读权、可写权。曾经涉及、触及文档的计算机在转作它用,或者离开技术支持部门之前必须由网络管理人员全面清除计算机硬盘中存储的文档。如果不能确定,必须对计算机中所有硬盘进行全面格式化后方可以转做它用或离开技术支持部门。文档的复制和传播文档向技术支持部门以外复制必须获得总经理的授权。并必须记录复制人、批准人、复制时间、复制目的、文件流向、文件版本或内容。文档以任何介质形式进行存储的备份,必须由专人负责保管。对于这些介质地借阅,用于技术支持部内部使用的必须获得技术支持经理的授权,对于用于技术支持部门以外使用的必须获得总经理的书面授权。文档的借阅、复制必须进行详细的登记,必需记录借阅人、批准人、借阅时间、借阅目的、文件流向、文件版本或内容、归还时间。任何纸质材料的借阅都必需记录借阅人、批准人、借阅时间、借阅目的、文件流向、文件版本或内容、归还时间、对于因合作需要,需要向外复制、传播、分发文档的,不论是全部还是部分文档和资料,均必需和对方签订技术、文档的保密协定,明确对方应承担的对文档保密的责任和义务。知识产权保护公司员工做出的职务成果,其知识产权利益均属于公司所有,保护公司知识产权是全体员工的义务,公司的员工应自觉遵守国家法律法规、遵守公司保护知识产权的规章制度,认真履行保护公司知识产权的义务,维护公司的合法权益,同时不侵犯外单位和他人的知识产权。公司对侵犯员工知识产权的行为进行追究。为增强知识产权意识、明确责任义务,公司所有员工均应与公司签订《《保密协议》》。定期进行知识产权如软件著作权的申请。入职人员签订竞业限定,关键核心人员在离职后给予竞业补偿,竞业限制。售前技术支持例会制度1.定期召开由公司的领导、商务拓展部门以及技术支持人员参加的技术支持例会,协调解决商务拓展技术支持过程中出现的问题。2.每日召开技术支持组内例会,总结当日的工作情况及进度,协调解决商务拓展技术支持过程中出现的问题。3.每周召开技术支持组内例会,总结本周的工作情况及进度,协调解决商务拓展技术支持过程中出现的问题。4.每月召开技术支持组内例会,总结本月的工作情况及进度,协调解决商务拓展技术支持过程中出现的问题。能力达标制度基本能力宣讲能力:必须为普通话,或当地人员能顺畅交流的语言(如粤语,四川话,上海话),但推荐以普通话为主,语言应平顺自然,有亲和力,不应生硬,卡顿。建议每分钟为70-90字幅度,不应过快或过慢,需要至少在15分贝以上,在30人以上的场合需要适当增加。行为仪态:至少需要带领的服装,深色裤子以及皮质鞋类;禁止无领背心,裤衩,拖鞋运动鞋等着装。正式场合着正装(正式场合如:公众讲座,客户多人中小型会议,推荐首次拜访也着正装)。头发指甲等仪态仪貌需符合公司员工标准。站立和坐姿需端正,不得背对客户宣讲,不得只看PPT宣讲,需要有目光交流,手势交流,语言交流以及流程控制。写作能力:需至少具有500字/天方案的编写能力,建议具有1000字/天方案的编写能力(不外出的情况下);需要熟练使用Office软件(PPT,Word,Excel,Project,Visio);原则不允许出现错别字,最低要求是不得超过5%。不允许出现同一段落内无故串行,字体不一致,表格排列混乱等基本文章排版问题。归纳能力:能够根据PPT提示给予讲解(预先讲稿或临场发挥均可);能够听懂客户所述语言,并给予解释。沟通能力在项目前期沟通上应该首先自身产品出发满足客户需求,如无法满足则可以使用自身或者销售熟悉领域的产品或方案满足客户需求。推荐方案时,需要与销售先行洽商,制定大致的宣讲范围,尽可能先行了解客户需求(如销售也不清楚,或者第一次拜访,则最好了解销售推荐过哪些方案,或者直接与客户联系一下,了解客户的主要需求,以先期进行材料准备。)需要了解客户组织架构,以针对不同的岗位人员有不同的宣讲方法和沟通手段针对技术人员(工程师级别)就要尽可能多做产品特点和技术的售卖工作;针对中层人员(科长,处长级别)则要突出产品易维护性和性价比高(性价比高非价格便宜)的特性;针对领导则要切中要害,准备在有限时间内(一般为10-30分钟),突出我方最大优势(公司优势,产品优势,品牌效应,成功案例),并需要有充分互动以能够实现一锤定音的效果。见客户领导,必须有销售主管以上同事配合协同。产品熟悉能力售前技术支持工程师需要在3个月以内,至少了解并能宣讲10款产品的介绍或方案。售前技术支持工程师需要在6个月以内,能够完整沟通并了解1个行业客户的成功案例,包括组织架构,系统架构,产品对应需求点,解决了何种问题,后续的拓展等。售前技术支持工程师需要在6个月以内,至少参与过3个10万以上的方案编写。方案熟悉能力售前技术支持工程师在2个月以内,需要至少了解并能编写1套完整的客户解决方案,该方案至少涉及3款以上产品(单纯的产品介绍不算)售前技术支持工程师需要在6个月以内,至少能够编写1套针对自身行业客户的成功案例解决方案模板,该方案需切合行业特点,针对该行业的问题是用对应产品加以解决。沟通与反馈制度技术支持人员所做的任何技术支持工作,如销售未在场,在沟通完成后,无论沟通结果如何,建议立即发送汇报邮件给该项目的主销售。邮件标题为:客户沟通-XX项目-技服人员名字。如果技术支持人员认为电话可以交代清楚,并且认为电话交代不会引起问题的,也可以采用电话向销售汇报的形式。某项目的主销售,一旦发现技术支持人员与客户沟通后,没有发送汇报邮件也没有电话说明的,则可以发投诉邮件给技术支持部经理,抄送商务拓展部负责人;邮件标题为:投诉-XX项目沟通问题。商务拓展部负责人接到技术售前的电话汇报,如果认为技术售前支持反馈的问题需要邮件说明的,可以要求技术售前支持补发汇报邮件。某技术支持每收到2次投诉邮件,当月绩效工资扣发1级;每收到4次投诉邮件,绩效工资永久降1级。汇报邮件正文应按如下内容填写:沟通结果“成功/问题遗留”、项目名称、沟通人、沟通方式、沟通的具体问题(不得写“解决了技术问题”这样的笼统语句,而必须写成“解决vista下远程控制网络参数设置”这样的明确语句)、遗留的问题描述等。售前技术支持立项制度所有技术支持过程的启动,必须通过《技术支持立项单》事先进行项目立项、确立技术售前。立项时须由申请人详细填写技术支持内容要求,以利项目进行。完成立项后,销售保留《技术支持立项单》存档,以备查询。技术售前填写《项目跟踪表》。根据立项要求,销售与责任售前须紧密配合,明确需求、明确支持内容。技术支持人员一旦介入某个项目的支持工作,如果该项目没有立项,则介入项目的技术支持人员应该督促项目销售尽快走技术支持立项流程。如果售前技术工程师履行了督促任务(例如邮件等方式提醒),销售依然没有走技术支持立项流程的,技术支持人员可以停止对此项目的支持,项目出现延误等情况由销售自己承担责任。流程图如下:技术支持立项单编号接单人申请单位:项目名称:时间需求:申请支持内容工作描述完成情况确认客户拜访:文案编写:项目询价:图纸绘制:项目介绍申请部门审核:编制:日期:售前支持中心审核意见:日期:离职制度员工离职申请公司员工因故离职时,应向直接主管提出。直接主管应该进行谈话,确认离职后,向解决方案部总监报告。向解决方案部总监报告受报告内2日,与申请离职员工谈话。确认离职后,明确向员工表明可以办理离职手续。该员工得到明确答复后,向人力资源部索要《离职申请表》,办理离职手续。离职管理规定离职员工按照《离职申请表》项目内容及顺序办理离职手续。离职手续必须由交接人签字认可,否则将不予离职,并追究相应法律责任。员工在办理离职手续时,可以向人力资源部咨询。员工离职工资按照离职当月实际工作时间核算。员工工作到未发放奖金时间前离职,将失去奖金评定资格,公司将不予发放奖金。离职审批员工填写离职申请表后,按照离职审批程序进行审批。离职审批完成当天,由人力资源部通知IT管理部门,取消员工公司内部网络的账号及电子信箱账号。如果由于人力资源部或IT管理门未及时处理出现的问题,则追究相应的责任。工作移交员工应该在离职审批完毕3日内移交工作,并必须经过直接主管签字确认。技术支持部流程总则技术更新日新月异,技术支持工作永无止境,除了支持商务拓展部的日常各项目情况外,还要进行日常技术方案的储备,做到养兵千日,用兵一时。售前技术支持人员应该是项目开发人员与业务销售人员的桥梁。在销售人员面前,售前人员是技术人员或技术专家的角色;而在项目实施中的开发人员眼中,售前技术支持人员是专注技术的销售人员;在用户眼中,售前技术支持人员是代表公司技术水平的技术专家。流程内容解决方案准备售前技术小组负责人组织和安排工程师对现有和新产品的功能、性能、技术参数、配置清单及产品所具备的优点、特点等销售活动所需的产品技术资料进行整理。售前技术小组负责人对所有提供的技术资料进行审核。技术研发部,项目实施部对所有提供的技术资料进行审批。技术资料员对所有提供的技术资料进行整理、并汇编成册,提供给市场部;对改进的技术资料进行及时更新。售前支持1.商务拓展部门提出服务请求发起服务请求,填写技术支持立项单1.商务拓展部门提出服务请求发起服务请求,填写技术支持立项单2.根据项目需求技术部门安排相应工程师响应服务请求,配合商务拓部门的设计或服务工作2.根据项目需求技术部门安排相应工程师响应服务请求,配合商务拓部门的设计或服务工作3是否需要对客户进行现场服务(现场勘察)3是否需要对客户进行现场服务(现场勘察)是 否3.2由销售方提供客户需求报告3.1进行现场勘察,记录客户需求,填写调查报告3.2由销售方提供客户需求报告3.1进行现场勘察,记录客户需求,填写调查报告汇总所有的项目数据,开会对项目情况进行讨论汇总所有的项目数据,开会对项目情况进行讨论进行解决方案的设计与制作进行解决方案的设计与制作技术支持部、技术研发部、商务拓展部对方案可行性进行讨论、确认。技术支持部、技术研发部、商务拓展部对方案可行性进行讨论、确认。制定施工预算制定施工预算8提交设计方案书给销售部门8提交设计方案书给销售部门8.1对甲方技术问题进行现场解答8.1对甲方技术问题进行现场解答9签定合同书9签定合同书10根据项目施工方案确立项目施工组织计划,并提交审核10根据项目施工方案确立项目施工组织计划,并提交审核11进入项目实施阶段11进入项目实施阶段2)工作流程说明1、根据商务拓展部门提出的服务请求由销售代表填写技术支持立项单,在服务请求表格中详细填写以下信息:用户详细信息、服务请求类型、服务内容、服务时间等等信息。2、售前技术支持部受理人员将销售或业务部门的服务申请单提交给部门主管,由部门技术主管结合当前的工作安排以及申请服务的技术类型,合理的安排相应的技术人员受理该项服务。3、根据销售部门对整个项目的了解情况,以及技术部门对方案设计数据的需求情况决定是否需要对用户进行上门调研。需要项目上门调研。由售前技术支持部指派响应的技术人员上门对客户的情况进行了解,填写项目调研、现场勘察的各种表格。不需要项目上门调研。销售方已经充分了解了用户的需求,由销售方填写用户需求的表格。4、将项目调研的各种数据进行汇总整理,结合项目的需求开展项目讨论,成立项目小组,根据项目的类型指派相应技术人员进行方案的设计,相关销售人员配合,填写方案设计报告表。5、技术人员在方案设计报告表要求的时间内设计解决方案,在设计过程中充分结合销售部门人员,出现设计目标不明确或数据不清楚的情况及时联系甲方负责人,进行项目补充调查。6、方案设计完成后,由方案设计人员发起,技术主管主持、相关技术人员以及相关销售人员参加的项目设计方案讨论会,着重对方案的可行性、先进性、设备选型、造价幅度等情况进行审核,最终确立技术方案,由技术主管、销售主管、商务主管签字确认。7、将设计出的方案提交给商务部门,由商务部门制定项目设备预算报价,销售部门制定自己的投标报价。8、将设计的方案书与投标报价提交甲方。9.根据甲方的要求,我方技术人员到达用户现场解答用户提出的各种问题,对设计方案进行现场的技术讲解。10、签订合同。11、商务主管、售前技术主管、技术研发部主管、项目实施部主管组织相关人员开展项目组织会议,成立项目实施小组,安排负责人,根据合同工期要求编写施工组织计划与施工方案。项目推进到项目实施阶段,交由项目实施部门负责。技术研发部部门职责根据公司产品路线的战略规划,市场调研的结果和客户要求制定产品开发方向,对新产品的可行性进行论证并组织实施。公司未来的业务发展的预研,如产品预研和技术预研。制定研发规范,推行并优化研发体系。规划组织现有产品的改进、制定项目开发计划。部门的团队建设、岗位定义、岗位职责要求、员工考核、资源调度。评估产品研发的可行性。监控每个研发项目的执行过程。组织研发成果的鉴定和评审。汇总每个项目的可重用成果,形成内部技术和知识方面的资料库。分析总结研发过程中的经验和教训,提高研发质量。制定并实施研发人员的内部培训。组织对售前和运维人员进行新产品的培训。研发理念研发宗旨形成公司有竞争力的产品和从技术层面上辅助提高项目开发速度、质量。研发范围项目研发职责主要负责公司产品研发和重点、疑难项目的研发,目标是形成公司有竞争力的产品和解决方案,支持市场和项目立项工作;技术研发职责主要是对公司基础平台和框架的研发,以便提高项目开发效率,形成公司技术积累和技术储备。研发类型产品开发基于市场调研、客户需求、诸多项目研发经验等多方面信息源,总结、归纳、提取行业规范、模式、流程等,整合适于行业的各环节、场景,在技术层面上形成行业的通用解决方案。项目开发基于客户需求,通过需求调研、需求分析等手段细化需求;结合需求文档、概要设计、详细设计等环节将需求转换为具体的子系统、业务功能模块等。通过制定具体的开发、测试计划,细化开发工作和测试工作,保证开发和测试任务在既定时间内如期完成。最终通过测试用例和完整的测试报告,对项目完整度、性能、安全性等全方位评估,并完成开发交付。技术调研依据市场、项目、客户等反馈,结合当前流行或技术栈未涉及的技术、产品、方法论、模式等,进行技术性验证。收集、整理相关资料,结合实践对调研目标进行分析、论证。对调研目标所产生的影响、关键性因素、前后置条件等,进行归纳总结,形成有说服力的调研报告。通过可行性、适用性等多方面分析、研究,辅助决策者对调研目标有深刻认知。岗位设置岗位备注研发主管主管研发项目经理研发工程师分为初、中、高级测试工程师需求分析工程师岗位职责说明研发主管职务名称:研发主管直接上级:解决方案部门总监直接下级:研发工程师本职工作:公司产品、技术发展规划,研发部门及团队管理。岗位职责:根据公司战略规划,制定研发计划和研发预算,并组织实施;负责整体技术管理以及资源协调,控制研发方向和研发过程,确保研发计划的达成;处理研发过程中出现的技术、质量问题,组织人员对关键技术、质量问题的攻关;组织技术人员为售前、实施团队提供产品技术培训及指导;与售前、实施团队沟通,跟进产品的市场反馈信息,了解客户的使用状况;技术团队的日常管理及人员培养工作;研发项目经理职务名称:研发项目经理直接上级:研发主管直接下级:研发工程师、测试工程师、需求分析工程师本职工作:研发项目管理,开发进度管理,团队成员管理岗位职责:根据项目范围、质量、时间与成本的综合因素的考虑,进行项目的总体规划与阶段计划。组织项目所需的各项资源。设置项目组中的各种角色,并分配好各角色的责任与权限。定制项目组内外的沟通计划。安排组内需求分析师、客户联系人等角色与客户的沟通与交流。处理项目组与其它项目干系人之间的关系。处理项目组内各角色之间的关系、处理项目组内各成员之间的关系。保证项目组目标明确且理解一致。创建项目组的开发环境及氛围,在项目范围内保证项目组成员不受项目其它方面的影响。提升项目组士气,加强项目组凝聚力。合理安排项目组各成员的工作,使各成员工作都能达到一定的饱满度。制定项目组需要的招聘或培训人员的计划。定期组织项目组成员进行相关技术培训以及与项目相关的行业培训等。及时发现、处理项目组中出现的问题。保证项目在预算成本范围内按规定的质量和进度达到项目目标。在项目生命周期的各个阶段,跟踪、检查项目组成员的工作质量。定期向领导汇报项目工作进度以及项目开发过程中的难题。对项目进行配置管理与规划。控制项目组各成员的工作进度,及时了解项目组成员的工作情况,并能快速的解决项目组成员所碰到的难题。不定期组织项目组成员进行项目以外的短期活动,以培养团队精神。研发工程师岗位职责:参与制定并执行研发工作标准,明确研发流程与方法,建立研发工作规范;完善、升级、维护公司基础开发框架,并且在基础平台上创新、整合新技术;根据公司需求,掌握本领域技术动态,制定预研计划,提前做好技术储备;根据组织研发战略,制定项目研制方案及实施流程;负责与项目经理共同进行客户调研、业务流程分析设计;负责系统的总体技术方案与系统设计,系统的质量控制;负责并参加项目全面的研制和开发,完成难度较高的项目鉴定、开发等工作,从而保障研发任务的顺利开展;负责开发团队人员的分工并协调他们的工作,实时掌握控制研发进度,预见可能出现的问题,提前做好预研和准备工作,及时汇报项目进度及设想;负责指导团队人员开发,识别并解决项目开发过程中出现的问题,攻克技术难点;组织进行软件测试,Bug列表核对,Bug修复工作分配,Bug修复进度跟踪;分析总结研发过程中的经验与教训,制定并执行工作改进计划;培训下属人员并随时更新知识,以提高员工的专业素质;中级研发工程师:参与系统需求分析、评审和设计;根据系统的设计要求,负责主要功能模块的代码实现、BUG修改、单元测试;协助测试人员完成集成测试和系统测试;指导初级开发人员完成系统设计和开发工作,能够根据团队要求对其他人设计和开发的内容进行把关并提出意见;参与相关开发管理制度和规范的制定,并负责应用到日常工作中;完成研发经理或者上级领导分配的其它工作;初级研发工程师:独立完成功能模块开发;根据需求和设计文档进行编码、调试和单元测试;配合中级、高级研发工程师完成开发工作;根据项目需要进行相关文档编写;测试工程师岗位职责:负责功能测试、确认测试和系统测试等测试工作;负责将缺陷编写成正式的缺陷报告,提交给开发人员进行缺陷的确认和修复;缺陷报告保证缺陷的重现;根据测试结果来分析软件质量,包括缺陷率、缺陷分布、缺陷修复趋势等;给出软件各种质量特性包括有功能性、可靠性、易用性、安全性、时间与资源特性等的具体度量;负责制定测试计划,包括有测试资源、测试进度、测试策略、测试方法、测试工具、测试风险等;设计测试用例,形成测试用例报告;学习并使用自动化测试工具,测试人员需要学会使用自动化测试工具,编写测试脚本,进行性能测试等;根据实际情况不断改进测试过程,提高测试水平;需求分析工程师岗位职责:负责客户需求调研及需求反馈的分析;需求细化,编写输出详细需求规格说明书;系统规划,进行前期调研和产品设计工作,编写调研报告和项目解决方案;参与系统功能验收工作及用户手册、新增产品功能、培训资料的编写;配合测试人员编写测试计划、测试用例、测试报告的编写、问题缺陷的发现及跟踪、产品用户手册编写等;协助项目经理等项目组成员对需求进行理解;研发制度总则为规范本公司研究开发行为,明确研究开发中涉及的审批权限,加强对研究开发业务的监督与控制,防范研究开发业务过程中的差错和舞弊,特制定本制度;以软件工程要求建立质量管理体系,严格控制产品的设计和开发的策划和过程,确保新产品满足市场要求。质量检查制度系统质量保证活动统一由质量管理员进行管理、检查与汇报,公司相关部门经理及研发项目中的项目经理、程序经理、测试经理、产品经理、测试经理、是质量保证活动中的第一责任人。研发项目负责人每天要检查成员的工作完成情况,特别是新员工的工作进展;工作抽查制度:不定期的进行抽检,并将检查对象、检查时间、检查内容、检查结果反馈给被抽检人。内部审核制度:针对业务需求、概要设计(功能界面、数据库)或疑难问题组织评审会,提出意见或解决方案。测试的规范制度所有的缺陷必须全部记录在BUG管理工具(JIRA);测试完成标准必须有实施经理和测试经理的确认;测试用例执行覆盖率应达到100%(功能测试用例均已执行);测试需求执行覆盖率应达到100%(业务测试用例均已执行);测试规范是根据开发规范而制定的测试标准,测试规范也是后期测试用例编写的重要依据。性能测试必要性和指标根据需求情况而决定;源码和文档管理制度为保障公司源代码和开发文档安全不至于泄露,保证源代码的完整,明确源代码控制管理流程,特制定此管理办法。本制度适用于所有涉及接触源代码的各部门各岗位、所涉及部门都必须严格执行本管理办法。源代码直接控制管理部门为解决方案部。本制度管理重点在于控制管理源代码的完整性,不被非授权获取,不被非授权复制和传播。本制度所指源代码不仅限于公司开发人员自行编写或购买实现功能的程序代码,而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其他支撑库等文件。源代码完整性保障所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。系统运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。源代码的授权访问源代码服务器对于共享的代码库的访问建立操作系统级的,基于身份和口令的访问授权。在代码库中设置用户,并为不同用户分配不同的,适合工作的最小访问权限。要求连接代码库时必须校验代码库中用户身份及其口令。在代码库中要求区别对待不同用户的可访问权、可读权、可写权。曾经涉及、触及源代码的计算机在转作它用,或者离开实施部门之前必须由网络管理人员全面清除计算机硬盘中存储的源代码。如果不能确定,必须对计算机中所有硬盘进行全面格式化后方可以转做它用或离开实施部门。代码文档的版本管理1)版本标识方法为了使工作规范化、统一化,各项目组实行的版本标识管理方法分为:正式版本和特殊版本。正式版本公司在市场上发行的正规版本。以“V”开头,版本号放后。V前面增加项目名称,版本号分3节:主版本号,次版本号和内部版本号,每节之间以小数点(.)间隔。如V2.0.1表示主版本号为2,次版本号为0,内部版本号为1。研发部控制主版本号和次版本号,各项目组控制内部版本号。例如:一体化平台-荣耀版v1.1.1,一体化平台为产品名称,荣耀版为版本名称(荣耀为具体项目名称),v1.1.1为主版本号+次版本号+内部版本号。2)目录结构由于各项目组的实际情况不同,目录结构很难统一,但为了能更好地管理各项目组的文档,建议可将被管理的配置项分为三大类:文档类、源码类及安装盘类,这样存放比较清晰,有利于版本管理。至于二级目录是以版本划分,并根据制定的目录结构给出文件级目录清单(先给出源程序及文档的文件级目录清单,安装盘的可以后再执行)。现以电商平台1.0的目录结构举例如下:根目录一级目录二级目录三级目录对应配置项备注产品名称一体化平台版本号源码核心源码包jar源码存目录前正在修改的内容Class文件扩展源码包源码sqlSQL文件版本变动说明文档需求文档用户需求记录版本号在文件名上标识概要设计文档总体设计文档按版本号依次类推数据库设计详细设计文档测试用例测试记录版本号在文件名上标识用户手册用户使用手册产品说明书项目计划项目计划实施手册实施手册月度计划月度计划安装盘REL_SRC产品盘或发布文档SETUP发布文档表示正式版本及特殊版本的目录按以下原则定义:正式版本:以“V”开头,版本号放后,主版本号和次主版本号之间的“.”去掉,明细版本号之前加“-”。举例如下:版本号目录名V1.0V1.0V1.1V1.1V1.0.1V1.0.1V1.1.2V1.1.23)文档的存放当前版本和历史版本的存放对于源码文件,特别增加了一个Current目录,存放当前正在开发与维护的源码文件,当前未发布版本的所有数据都存放在\CURRENT\下。一旦当前版本正式发行,则当前目录被修改为相应的历史目录。历史版本是指已经发行的版本,存放在相应的版本目录之下,一般不允许改动。开发文档的存放根据各项目部自己的情况,将系统用户需求记录、总体设计文档、详细设计及数据结构文件、测试记录、用户手册等放入相应的目录下。源代码的存放源代码包括如:java,jsp,BMP,ICO等相关文件,是未经编译处理的、不能直接交付使用的产品文件以及编译产品所需的文件;联机帮助文件HLP在未生成HLP文件之前的DOC,RTF等格式的文档也视为源代码。各子系统当前的程序源文件放入相应的目录下。对于一个子系统又分多个分子系统的情况,应在该目录下分别建立几个相应的目录。SQL语句的存放各子系统SQL文件放入…..\\SQL下,对于不同的数据库,分别建立不同的子目录,如oracle、sysbase、db2等。公共SQL文件直接放入…\SQL下即可,不同数据库的特殊SQL分别放入对应的子目录下。发行文档的存放发行文档是指产品交付用户使用所必须的文件。包括:产品可执行文件,用户使用说明书,联机帮助(HLP);资源文件(BMP,ICO等),环境配置文件等。以上文档作为制作发行盘的素材,放在RELEASE的REL_SRC目录之下,制作好的发行盘放在RELEASE的SETUP目录。4)权限控制管理为保障文档的安全性,一致性,以及防止意外修改,必须对不同的文档设置不同的访问权限。文档权限类别:只读权限,读写权限。文档类别:设计文档,源码,发行文档。用户类别:开发人员、测试人员、分析设计人员、项目经理、配置管理员、安装盘制作人员、问题及需求管理人员、用户文档编写人员等。为了控制不同的使用权限,根据要求在服务器上分别建立不同的用户,针对不同的配置项所在目录分配不同的权限。为了便于管理,应以表格的形式列出人员与管理对象的访问关系(用户权限清单)。5)更新管理版本升级原则版本升级应严格纳入版本管理的控制之下。应当谨慎地控制版本的升级,保障高版本的向下兼容性,或提供严格定义的升级方法。在下面几种情况下,进行版本演化和升级:1、当产品发生重大修改和改进时,主版本号加1。重大修改和改进包括:平台迁移;开发工具的迁移;体系结构的变迁。2、当产品发生较小的改进或修改时,次版本号可以加1。3、对于改动量比较少的,如修改产品的错误,可增加内部版本号。内部版本号对用户来说是不可见的,只对项目部内部版本控制有用。4、记录版本升级过程。每次版本升级,都要填写版本升级记录表,记录表样例如下:版本升级记录表版本号发布日期修改文件问题简要描述发布责任人批准人备注说明:版本号:记录当前发布的版本。发布日期:该版本批准发布的日期。修改文件:版本修改记录文件,一般为版本修改日志。新版本的发布新版本的发布包括主版本号和次版本号的升级,一般不包括内部版本号的升级。流程如下:根据项目进展情况,或者根据用户需要进行发布准备。在指定目录中,根据本次发布的版本号建立相应的子目录,将current下的所有内容拷贝至新建目录下。可在新建目录下建立readme.txt,并加入相应的内容。readme.txt文件是记录该版本与上一版本的不同,做过哪些改动。格式样例如下:增加或修改功能涉及源文件改动原因6)研发部统一管理阶段性版本阶段性版本的提交到研发部当各项目组更新了新版本以后,如果次版本号发生改变,各项目组配置管理员经项目经理批准后要把次版本修改的内容(提交的内容分为修改的源码、新的文档和安装盘)提交给研发部版本管理人员。阶段性版本的发布到公司网站上产品新版本发布以后,及时在软件演示环境中进行更新。并且新版本的特色和特点要在公司网站上进行发布,描述新版本特色的文档要由各项目组进行提供给项目部,经项目部保存后,文档提交给公司网站管理人员进行发布,以便供其他项目组和公司营销人员进行了解。各项目组新版本内部及时备份。研发部负责进行所有产品版本的管理,但各个项目组也要自己进行备份。备份管理为了保证文档的最大可恢复性,要随时及定期地进行备份工作。随时备份:开发人员每天都要将自已当日修改的源文件在本地机器上进行备份。开发负责人每天要将所有源文件在本地机备份。建议备份采用循环备份。定期备份备份形式为硬盘备份和光盘备份。硬盘备份时,要备份在独立的硬盘上;光盘备份时,要将光盘存放在可靠的地方。备份周期视各产品部、事业部的具体情况而定。如果处于开发阶段,每周应对所有的源程序项进行备份,一般为每周周五;如果处于其它阶段,根据具体情况而定,但周期不能超过两周。备份要由版本管理员负责,备份原则应是保证文档的最大可恢复性。对于历史版本或某用户的特殊版本,如果无特殊原因不再进行修改的话,建议用光盘进行备份,而且应有备份盘说明文件BACKUP.TXT。该文件应该记录以下内容:本次备份时间,备份内容,执行人。各项目组提交文档及源码以及规则各项目组需要提交的文档名称成果描述立项申请书写明此项目的价值、所需人力资源及费用、可行性分析、成本-效益分析、风险分析立项评审报告评审结论、评审建议软件需求说明书目标客户、业务流程、系统中的角色、子功能模块介绍、质量要求、界面要求系统设计说明书系统约束、开发环境、数据流程图、用例图、模块之间的关系图、类函数文件变量等命名规则、系统安全设计说明、性能分析数据库设计说明书所有表名、表设计、表ER图、生成库的sql语句、存储过程等。表及字段命名规则。用户界面设计说明书系统界面设计说明、原型图模块设计说明书编程的接口、主要的数据结构、主要算法测试用例用例名称、用例描述、输入值、希望输出值缺陷报告Bug名称、bug状态、bug紧急情况、bug处理人等测试报告界面测试报告、性能测试报告部署说明书部署环境说明、初始化的数据、注意事项、数据的迁移等安装和使用手册安装过程描述、各模块使用手册、FAQ手册软件源代码源代码、开发工具、API详细说明、代码注释、编译后程序系统维护记录问题描述、问题解决情况技术评审报告评审内容、评审结果、评审人系统安装程序打包程序、打包工具、打包完以后的安装程序源代码复制和传播源代码向实施部门以外复制必须获得总经理的授权。并必须记录复制人、批准人、复制时间、复制目的、文件流向、文件版本或内容。源代码以任何介质形式进行存储的备份,必须由专人负责保管。对于这些介质地借阅,用于实施部内部使用的必须获得实施经理的授权,对于用于实施部门以外使用的必须获得总经理的书面授权。源代码的借阅、复制必须进行详细的登记,必需记录借阅人、批准人、借阅时间、借阅目的、文件流向、文件版本或内容、归还时间。任何纸质材料的借阅都必需记录借阅人、批准人、借阅时间、借阅目的、文件流向、文件版本或内容、归还时间、对于因合作需要,需要向外复制、传播、分发源代码的,不论是全部还是部分代码和资料,均必需和对方签订技术、源码的保密协定,明确对方应承担的对源码保密的责任和义务。知识产权保护公司员工做出的职务成果,其知识产权利益均属于公司所有,保护公司知识产权是全体员工的义务,公司的员工应自觉遵守国家法律法规、遵守公司保护知识产权的规章制度,认真履行保护公司知识产权的义务,维护公司的合法权益,同时不侵犯外单位和他人的知识产权。公司对侵犯员工知识产权的行为进行追究。为增强知识产权意识、明确责任义务,公司所有员工均应与公司签订《《保密协议》》。定期进行知识产权如软件著作权的申请。入职人员签订竞业限定,关键核心人员在离职后给予竞业补偿,竞业限制。凡欲申请软件著作权的,发明人或设计人应按要求和完成期限撰写《源代码》、《软件说明书》、《事务委托确认书》。发明人均按知识产权规划完成期限发送《源代码》、《软件说明书》、《事务委托确认书》邮件至质量管理部,并备注按正常时限申报还是加快申报,如需加快说明加快理由。完成审批后质量管理部应组织本公司发明人、相关技术人员或代理机构代理人进行讨论,确定最佳保护范围和方式,委托事务所代理。软件著作权申请工作需要经过申报-受理-证书,中国国家版权局根据审查情况将会做出通过或驳回审查结论,这一过程的时间一般为:3-6个月左右。专利申请制度专利申请人对在日常工作、研发中形成的独创性工作成果,形成书面材料,向技术研发本部负责人提交《专利申请书》。内容包括发明专利/实用新型专利/外观专利的名称、发明人或设计人的姓名、申请人的姓名、相应专利的技术说明书等;经技术研发本部负责人及总裁室通过的专利申请,由技术研发本部负责人联系选择合适外部代理机构进行申报,并与代理机构签订协议,按照代理人要求收集准备齐全相应申报材料,指导公司内部申请人撰写详细技术资料;相关资料提交外部专利代理机构后,由代理进行申报,技术研发本部负责人与代理机构保持充分联系,及时补充相应资料。若国家专利局审批通过,则专利代理机构与技术研发本部负责人联系。成果转化与保护制度企业应当建立严格的核心研究人员管理制度,明确界定核心研究人员范围和名册清单,签署符合国家有关法律法规要求的保密协议;企业与核心研究人员签订劳动合同时,应当特别约定研究成果归属、离职条件、离职移交程序、离职后保密义务、离职后竞业限制年限及违约责任等内容;企业应当建立研究成果保护制度,加强对专利权、非专利技术、商业秘密及研发过程中形成的各类涉密图纸、程序、资料的管理,严格按照制度规定借阅和使用。禁止无关人员接触研究成果;研发活动评估制度,加强对立项与研究、开发与保护等过程的全面评估,认真总结研发管理经验,分析存在的薄弱环节,完善相关制度和办法,不断改进和提升研发活动的管理水平。研发周报管理制度各项目组每周向研发部提交周报。周报具体的格式如下:项目周报报告名称所属项目报告人报告日期本周工作汇报1.任务进度情况

2.项目成本情况

3.项目质量情况

4.客户情况

5.存在的问题和对策各个项目组提交最新的project文件。Project文件中包含各任务完成百分比,任务分配人,资源情况。研发例会制度定期召开由公司的领导、技术总监、项目领导、业务部门领导以及技术研发人员参加的项目研发例会,协调解决研发过程中出现的问题。每周召开研发项目组内例会,总结本周的工作情况及进度,协调解决研发过程中出现的问题。每月召开研发项目组内例会,总结本月的工作情况及进度,协调解决研发过程中出现的问题。项目研发里程碑会议制度在项目研发达到重要的里程碑阶段,召开项目里程碑会议,对上一阶段的工作做出小结和评估研发进度及成果,并动员部署下一阶段的工作。每一份交付物将是整个系统开发过程中的『里程碑』。所以里程碑的建立必需连带交付物,而这交付物必须明确。进行项目启动集会时,项目经理应明确地指出项目过程中所产生的交付物的重要性,同时更应该清楚地说明交付物在没有确认前将不能够开展下一阶段的工作,在没有确认一个阶段的交付物时,继续开展下一阶段的工作对项目会带来莫大的风险,因为任何的不确定性因素,可能变成废物,或需要不断进行修改。这不但浪费组员的时间及士气,更严重地延误项目的进度,延误项目的最终交付,导致项目的超时、超支。项目里程碑如下表序号里程碑名称子里程碑序号任务名称输出技术文件类别缩写1项目论证1市场调查调查记录2技术预研3编制立项报告立项报告4立项报告评审评审记录5编制立项通知书开发项目立项通知书/升级开发、定制项目立项申请和通知书2项目策划1项目管理计划编写项目计划、CM计划、QA计划2管理计划评审评审记录3需求开发1用户需求调研用户需求2需求分析、编写系统需求规格说明书系统需求规格说明书SRS3需求评审评审记录4编写验收、系统测试规范验收、系统测试规范STC5建立需求基线标识需求基线6建立需求跟踪需求跟踪矩阵4系统设计总体、概要设计1编写总体、概要设计总体、概要设计SGD2总体、概要设计评审评审记录3集成测试规范编写集成测试用例ITC4集成测试规范评审评审记录5进行需求跟踪需求跟踪矩阵详细设计1编写详细设计详细设计SDD2详细设计评审评审记录3单元测试用例编写单元测试用例UTC4单元测试用例评审评审记录5进行需求跟踪需求跟踪矩阵5系统实现编码1编码代码2代码走查走查记录3代码静态分析代码静态分析报告单元测试1实施单元测试单元测试记录2BUG修改V&V记录3进行需求跟踪需求跟踪矩阵6产品集成产品集成1集成计划、方案编写集成计划、集成方案、集成步骤2集成环境准备3进行集成集成记录集成测试1编写集成测试计划集成测试计划ITP2集成测试计划评审评审记录3实施集成测试集成测试记录4BUG修改V&V记录5集成测试报告编写集成测试报告ITR6集成测试报告评审评审记录7进行需求跟踪需求跟踪矩阵系统测试1实施系统测试系统测试记录2BUG修改V&V记录3系统测试报告编写系统测试报告STR4系统测试报告评审评审记录5进行需求跟踪需求跟踪矩阵7系统验收验收测试1编写验收测试计划验收测试计划2验收测试计划评审评审记录3实施验收测试验收测试记录4BUG修改V&V记录5验收测试报告编写验收测试报告6验收测试报告评审评审记录7进行需求跟踪需求跟踪矩阵B版发布1B版发布软件版本发布单2CM审计CM审计报告3QA审计QA审计报告4安全审计安全审计计划安全审计报告5安全评估安全评估报告临时版本发放1变更管理设计变更单2更改结果核查单3临时紧急补丁发布管理临时版本发放申请表4基线管理临时版本基线登记表工程试用2工程试用工程试用报告产品状态变更申请表正式版发布1正式版发布产品发布单2CM审计CM审计报告3QA审计QA审计报告8项目关闭1项目开发总结开发总结报告2配置管理总结CM总结报告3质量保证总结QA总结报告9产品维护1跟踪产品缺陷产品缺陷记录2BUG修复BUG分析单项目里程碑评审报告里程碑名称进度工作量计划完成日期实际完成日期偏差值(天)计划完成日期实际完成日期偏差值(%)缺陷数缺陷率缺陷关闭率产生偏差的原因解决措施NO项目预计风险风险级别缓解措施应急措施1234研发流程确立设计开发项目根据市场调查、技术发展或市场需要提出新产品立项或重大改进需求的由指定专人进行可行性调研,编写《立项报告》,申请立项。根据立项申请,由研发总监组织相关人员(必要时聘请专家)进行评审并对结果进行记录。设计开发的策划由技术研发本部成立专门的项目小组对已立项的新产品编制《设计开发需求》,然后开始系统设计,以此作为项目组成员进行设计开发活动的依据。应阐明设计项目的输入和输出要求、设计的进度要求、人工预计、任务描述、设计验收的时机等活动的安排,并规定实施这些活动的职责。技术研发本部在系统设计完成时形成设计文档,由项目小组进行内部评审,形成记录。然后开始进行程序代码开发;项目负责人的选定要求其具有相当的能力和经验,项目组成员的选定也要求遵循资源优化的原则,有利于提高效率,避开矛盾,使资源得到合理的配置。项目开发计划可随设计的进展作必要的修改。项目组长对开发组织各技术接口所交流的信息进行管理,以确保设计开发过程有效。设计开发输入设计开发输入包括:《立项报告》、《设计开发需求》相关客户需求资料及竞争对手资料还有国内国际法律法规以及行业标准,包括公司内部的设计规范。设计开发输入是设计开发验收的重要依据。在设计完成之时和进行之中,应对设计输入进行适当的评审,尤其对设计输入中不完善、含糊、矛盾的要求,应提出并会同提出者一同解决,并对其进行记录。设计开发输出项目正式开始进行,设计人员开始系统设计,输出系统功能模块的形态设计文档。设计输出文件必须经设计验证评审通过后,由技术总监或总工签署后才能提交到技术管理中心备案,开发部则按照设计文档进行下一步的代码开发。研发人员在每个开发、测试阶段完成之后将产生功能模块的源代码、软件各功能模块的说明书、测试报告,评审小组评审后写出评审报告,通过的话表示这个阶段的完成。设计和开发的评审按照《立项报告》、《设计开发需求》由技术管理中心在适宜时机对产品在设计开发进行时组织人员进行阶段性的评审,评审方式以会议讨论方式进行,评审主要由技术副总和开发部人员和公司技术骨干参加,主要评价开发满足设计的要求和开发满足《质量保证计划》的能力,识别开发过程中出现的问题,评审中应提出解决办法,并作好记录保存。设计开发的验收在设计完成时,需由评审小组对设计进行验收,主要评审功能形态设计及其设计过程产生的文档,通过后将提交到技术管理中心。产品开发完成后,提交所有的开发文档,由项目验收小组进行产品验收评审,以保证输出满足输入要求的软件产品。设计开发的确认技术研发本部应根据所策划的安排对已完成的样品进行验证。以验证样品的要求符合设计输入的要求。并将验证的结果给以记录。当客户有要求或需要时就按照相应的产品标准对样品进行测试,作为验证方式的一种。记录并保存好有关的测试结果。验证的结果及任何必要措施的记录将给以保存。设计更改在设计开发过程的各个阶段,如需要较大的更改设计,相关的提出部门或设计人员应确定修改的内容,提出设计更改建议。针对不同类型的设计开发项目,设计更改建议需在经过不同的相关负责人和/或技术委员会以及其他相关人员的确认,保持相关记录,转交回设计人员手中,同时作为项目文档保存。在更改实施前必须对其进行验证、确认,以保证不会因更改而造成新的问题。对设计更改的内容应予以记录,并及时传递到有关部门和场所。合作单位与其他单位合作进行研究的,技术研发本部应当对合作单位进行尽职调查,签订书面合作研究合同,明确双方投资、分工、权利义务、研究成果产权归属等。技术研发本部加强对研究过程的管理,合理配备专业人员,严格落实岗位责任制,确保研究过程高效、可控。技术研发本部应当跟踪检查研究项目进展情况,评估各阶段研究成果,提供足够的经费支持,确保项目按期、保质完成,有效规避研究失败风险。研究项目委托外单位承担的,应当采用招标、协议等适当方式确定受托单位,签订外包合同,约定研究成果的产权归属、研究进度和质量标准等相关内容。软件测试测试计划根据项目的需求文档,按照测试计划文档模板编写测试计划。测试计划中应该至少包括以下关键内容:测试需求,明确需要测试组测试的范围,估算出测试所花费的人力资源和各个测试需求的测试优先级;测试方案,整体测试的测试方法和每个测试需求的测试方法。测试资源,本次测试所需要用到的人力、硬件、软件、技术的资源。测试组角色,明确测试组内各个成员的角色和相关责任;里程碑,明确标准项目过程中测试组应该关注的里程碑;可交付产物,在测试组的工作中必须向项目组提交的产物,包括《测试计划》、《测试报告》等;测试计划如下表:测试阶段任务工作量估计人员分配时间测试环境搭建搭建测试环境,包括:硬件环境,BUG管理工具,项目安装。编写测试用例并评审通过根据需求说明书,概要设计说明书,编写出测试用例。功能测试测试功能和业务流程是否达到设计要求提交测试报告根据项目进度计划,编写阶段性的测试报告压力测试测试系统在特定硬件环境中的性能,稳定性等指标是否达到要求。风险管理,列举出测试工作所可能出现的风险。测试计划编写完毕后,必须提交给项目组全体成员,并由项目组组中各个角色组联合评审,直至通过评审。按阶段设计测试实例,并将测试结果记录,未通过的反馈给开发人员调整。完成测试文档、操作手册、安装维护手册的编写。测试计划评审意见表如下:致:(建设单位)抄送:(监理单位)我方根据合同的有关规定完成了项目测试计划的编制,并经项目经理审查批准,请予以审查。承建单位(盖章)项目经理(签字):日期:年月日监理单位意见:总/专业监理工程师(签字):日期:年月日建设单位意见:项目代表(签字):日期:年月日一式三份,签字单位各持一份存档测试方法页面链接检查:每一个链接是否都有对应的页面,并且页面之间切换正确。相关性检查:删除/增加一项会不会对其他项产生影响,如果产生影响,这些影响是否都正确。检查按钮的功能是否正确:如update、cancel、delete、save等功能是否正确。字符串长度检查:输入超出需求所说明的字符串长度的内容,看系统是否检查字符串长度,会不会出错。字符类型检查:在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错。标点符号检查:输入内容包括各种标点符号,特别是空格、各种引号、回车键。看系统处理是否正确。中文字符处理:在可以输入中文的系统输入中文,看会否出现乱码或出错。检查带出信息的完整性:在查看信息和update信息时,查看所填写的信息是不是全部带出,带出信息和添加的是否一致。信息重复:在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作做出正确处理。检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理。测试种类及测试标准测试种类测试活动涉及到界面测试、逻辑功能测试、易用性测试、兼容性测试、业务测试和压力测试。具体要进行的测试包括:系统集成后的功能性测试;

系统集成后的容错性测试;

系统集成后的界面测试;

系统集成后的常用控件测试;

系统集成后的接口测试;

系统集成后的可用性测试;

系统集成后的完整性测试;系统集成后的压力测试;测试标准列出经过各种测试后,软件应达到的标准(如功能测试:能够按照设计要求实现该模块的各个功能,进出模块数据流向正确,各项数据完整/准确)。【编写实例参见如下】逻辑功能测试概述:能够按照<<需求规格说明书>>和<<概要设计说明书>>要求实现各模块的各个功能,业务流程要求,进出模块数据流向正确,各项数据完整\准确。标准:利用有效的和无效的数据来执行各个用例流,以核实以下内容:在使用有效数据时得到预期的结果;在使用无效数据时显示相应的错误消息或警告消息;使用有效数据时工作流通畅并得到期望结果;参考规范:《常用测试用例表_V1.0》—常用功能部分。界面测试概述:严格按照需求说明说中的界面设计图和公司的UI标准执行界面测试,验证界面是否美观、布局是否正确合理。标准:核实以下内容:确保各种访问方法(确保各种访问方法(鼠标移动、快捷键等)都使用正常;确保窗口对象及其特征(菜单、大小、位置、状态和中心)都符合标准等;易用性测试概述:从软件使用的合理性和方便性等角度对软件系统进行检查,来发现软件中不方便用户使用的地方。标准:核实如下内容:窗口上按钮的布局要与界面相协调,不要过于密集,也不要过于空旷;界面上的字体一般为宋体,字号一般为8~12号;测试窗体在常用分辨率下的显示情况,包括800*600,1024*768等;屏幕对角线交点的上方最容易用户的位置,要重点测试;工具栏上的图标简洁美观,尽量符合其真实含义;状态栏上要实时显示操作后窗体发生的变化;兼容性测试概述:核实测试对象在不同的软件和硬件配置中的运行情况。标准:确定系统能在下列条件下正常运行:在各种所需的硬件和软件配置中;在各种浏览器下的兼容性测试;相关表格如下:检查项测试人员的类别及其评价系统能在各种软/硬件条件下运行吗?具体有哪些呢?系统支持多种操作平台吗?支持多种浏览器吗?IE6.0、IE7.0业务测试概述:能够满足系统原型的业务流程要求,相应操作时业务规则的流向恰当,并发情况下流程正常。目标:按照系统原型的业务流程验证有效和无效数据的用例流,核实以下内容:使用有效数据时工作流通畅并得到期望结果;使用无效数据时,显示相应的错误信息或警告信息。压力测试概述:这里的具体包含了负载测试以及压力测试。目标:核实下列行为下的系统行为:确定测试对象在给定时间内能够持续处理的最大负载或工作量(包括长时间处理多个用户相同的且性能最坏的业务);确定并确保系统在超出最大预期工作量的情况下仍能正常运行,并评估其性能特征,包括响应时间、事务处理速率和其他与时间相关的内容。测试用例在需求分析文档确立基线以后,测试组需要针对项目的测试需求编写测试用例,在实际的测试中,测试用例将是唯一实施标准;测试用例所涵盖的标准如下: 测试用例是用于检验对象是否符合要求的一种“示例”,基本要素为:前提条件、输入数据或动作、期望的响应,目的是找出需求、设计、实现中的缺陷;测试用例由实施人员和测试人员共同制定,然后撰写《测试用例》,责任人为测试工程师;项目经理和测试经理审批《测试用例》,如果同意,则测试人员按照该计划执行测试工作;否则修改测试用例,直到通过审批为止;编号流程目的操作步骤动作预期结果执行结果备注1键入地址—>登录系统登录成功输入地址,回车;输入用户名、密码、验证码,点击登录按钮点击“登录”按钮。登录成功,显示主功能页面成功页面样式有问题测试用例项目名称项目负责人模块名优先级别模块开发人员开发完成日期用例设计人员设计日期评审人员评审日期测试次数测试执行日提交报告在约定的测试周期完成之后,测试Leader需要总结此测试的结果,编写测试报告;测试报告包含如下内容:测试报告的版本;测试的人员和时间;测试所覆盖的缺陷,测试组在这轮测试中所有处理的缺陷,报告了测试Leader处理的缺陷和实施工程师验证的缺陷。不仅要写出覆盖缺陷的总数,还要写明这些缺陷的去向;测试新发现的缺陷数量;上一版本活动缺陷的数量;经过此轮测试,所有活动缺陷的数量及其状态分类;测试评估,写明在这一版本中,那些功能被实现了,那些还没有实现,这里只需写明和上一版本不同之处即可;急待解决的问题,写明当前项目组中面临的最优先的问题,可以重复提出;在每轮测试结束之后应尽快将符合标准的测试报告发给全项目组;并抄送给相关领导审阅;测试归档测试归档是在测试验收结束宣布测试有效,结束测试后,对测试过程中涉及到各种标准文档进行归类,存档。主要的归档文件如下:《测试计划》;《测试用例》;《测试报告》;附则本制度由技术研发本部并负责解释,修改亦同;项目申请书可行性研究方案项目设计书

附件一:项目申请书项目名称:申请单位:邮政编码:项目负责人:电话:研究起始日期:年月至年月一、申请理由及业务需求简介(该项目研发目的、意义、国内外水平概况)二、研究内容与子课题三、主要技术关键问题四、计划进度及阶段成果五、研究方法与路线六、提供成果的形式七、项目主要参加人员姓名年龄工作单位职务/职称文化程度所学专业现从事专业本项目中承担的任务八、其它参加单位及承担的任务九、经费预算(需按下列要求进行详细填写和说明)项目费用(万元)研究费(人月费用×人月数)材料费、加工费(材料名称、数量及单价)调研费(人次数×人次单价)资料费会议费其他费用(列出用途和名称)总计十、项目申请负责人意见:(公章)日期:十一、总经理意见:(公章)日期:附件二:可行性研究方案(包含但不限以下内容)项目概况项目成本分析项目市场预期项目盈利分析附件三:项目设计书(包含但不限以下内容)项目概述项目背景和意义项目目标项目流程项目框架项目关键技术项目实施部阅读对象:公司领导实施主管项目组实施人员指导各实施组有效、高质的实施服务。包括:实施理念、实施类型、实施制度等。在实施工作未开展之前,需各个实施人员认真阅读.并对实施人员进行必要的培训,使运维人员熟悉维护的流程及相关制度。在实施过程中.实施主管要严格按照此文档的流程组织维护工作,以提高、增强实施质量。在项目实施过程中,实施主管或实施人员若发现流程有缺陷或需要补充的,请及时反馈至公司,确保实施流程能够及时得到更新,以达到规范性、可操作性。部门职责负责项目的现场实施工作,制定项目实施计划。承担项目实施交付和项目管理职责。负责项目实施过程中,与客户各相关科室进行工作沟通与协调负责项目实施过程中,问题的记录与解决。负责项目实施过程中,用户提出的意见与建议的记录。负责项目实施过程中,软件的培训与工作,以及部门内部技术的培训工作。负责撰写公司项目实施手册、使用手册及相关帮助文档。负责做好实施问题处理工作。负责配合商务完成项目验收及回款工作。岗位设置具体工作包括软件实施、软件培训、协助本公司内其他部门的相关工作,设置以下岗位:岗位备注软件实施小组负责人主管软件实施工程师(本项目主管)负责项目实施,根据项目情况选取项目组负责人。驻场软件实施工程师根据不同项目和合同规定,决定驻场时间岗位职责说明软件实施小组主管职务名称:软件实施小组主管直接上级:解决方案部总监直接下级:软件实施工程师本职工作:负责公司软件实施的业务与管理工作岗

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论