精华内容
参与话题
问答
  • 研发管理流程(一)

    千次阅读 2019-08-19 15:11:53
    目前的研发管理流程,分为4部分: step1:是否跟进项目 step2:是否参加项目招投标 step3:是否签订合同 step4:确定项目验收及回款 Step1 描述:是否跟进项目,组建项目团队,一般是销售+方案+项目经理。 ...

    公司的一切流程都是为了提升交付质量,提高市场竞争力,形成核心竞争力。

    目前的研发管理流程,分为4部分:

    • step1:是否跟进项目
    • step2:是否参加项目招投标
    • step3:是否签订合同
    • step4:确定项目验收及回款

    Step1

    描述:是否跟进项目,组建项目团队,一般是销售+方案+项目经理。

    思路:判断客户想做这个事情的确定性,评估赢下项目的可能性和所需的预先投入,从而决定是否继续跟进;

    内容:

    1)商机预览

    2)我们为什么要参加?从商务层面和战略层面

    3)我们能否胜任?从解决方案分析、交付能力分析、竞争力分析、风险评估分析、下一步计划安排分析。

    参与决策人员:销售经理、项目部经理等

    对应项目管理知识点:

    • 销售或者需求分析工程师 需要出具商业价值分析PBA、干系人登记册、需求跟踪矩阵
    • 技术负责人需要编写初步的建设方案
    • PM要编写初步的项目预算

    Step2

    描述:是否参加项目招投标.

    思路:判断客户想做这个事情的确定性,评估赢下项目的可能性和所需的预先投入,从而决定是否继续跟进;

    内容:

    1)商机概览;

    2)我们为什么参与:战略层面分析、商务层面分析;

    3)我们能否胜任:从解决方案分析、交付能力分析、竞争力分析、风险评估分析、下一步计划安排分析。

    参与决策人员:销售经理、项目部经理、总经理、产品经理等

    对应项目管理知识点:

    • 需要通过步骤2,参与招投标,需要编写投标方案
    • 更清晰的客户需求列表
    • 更清晰的建设方案

     

     

    展开全文
  • 浅谈软件研发管理体系建设

    万次阅读 2018-12-08 21:40:52
    最近一段时间,我一直在反复思考一个问题:我们的软件研发管理体系应该是怎样的?在不断思考的过程中,逐步有一些粗浅的认识,在此将这些认识记录成文字,并期待能够与更多的伙伴碰撞,进一步完善这种认识,并逐步...

    最近一段时间,我一直在反复思考一个问题:我们的软件研发管理体系应该是怎样的?在不断思考的过程中,逐步有一些粗浅的认识,在此将这些认识记录成文字,并期待能够与更多的伙伴碰撞,进一步完善这种认识,并逐步上升到理论高度,从而有利于指导具体实践。

    1. 对软件研发管理体系的一些概念认知
    1.1. 研发管理是什么
    关于研发管理,百度百科中这样定义:研发管理就是在研发体系结构设计和各种管理理论基础之上,借助信息平台对研发过程中进行的团队建设、流程设计、绩效管理、风险管理、成本管理、项目管理和知识管理等的一系列协调活动。

    也就是说,研发管理首要一点就是要根据公司业务的发展确定相应的研发体系结构,之后按照这种研发体系结构组件一支高水平的研发团队,设计高效合理的研发流程,借助合适的研发信息平台支持研发团队高效工作,以绩效管理调动研发团队的积极性,以风险管理控制研发风险,以成本管理使研发在成本预算范围内完成研发工作,以项目管理确保研发项目的顺利进行,而知识管理使得研发团队的智慧联网和知识沉淀。

    纵观各类软件企业,由于自身所处环境不同,因此其软件研发管理模式也不尽相同,这其中有基于CMMI能力成熟度模型指导下构建的研发管理体系,也有基于IPD集成产品研发框架指导下构建的研发管理体系,当然也有一些目前不少小企业、互联网企业推崇的敏捷研发管理体系。不同的研发管理体系其实都会有相应的交叉部分,最终追求的目标都是能否适合企业的发展,给企业带来市场和财务上的成功。

    1.2. 基于CMMI的研发管理
    CMMI能力成熟度模型相信大家都不陌生,从一级到五级,覆盖了22个过程域,一般能达到CMMI3级别的基本上可以理解为各类流程、过程规则等已经达到一个较好的水平。当然,这里主要是指企业能够确实按照CMMI模型去实践,这种实践其实更适合于以瀑布式开发为主导的项目开发及产品研发模式。然则,实际上,大部分企业尤其是国内企业并不会严格按照这个模型去做,因为如果每一个过程域都不打折扣地执行地话,需要非常标准化的流程和强大的资源支撑,在这个讲究快速响应变化的时代其实是很难做到的,通常这个时候都会进行相应的裁剪,甚至会结合敏捷迭代等方面的模式,从而逐步形成自己公司的研发管理体系。

    1.3. 基于敏捷模式的研发管理
    在这个快鱼吃慢鱼的互联网时代,对用户和环境越来越要求要快速响应。敏捷研发是当前不少互联网企业、中小企业推行的研发管理体系,主要理念就是敏捷迭代、小步快跑,快速改进、拥抱变化,用户参与等等。目前这方面也有不少公司除了有相应的敏捷研发体系之外,还有相应的成熟工具做支撑。例如,腾讯的TAPD敏捷研发平台就是其中的代表。通过对用户故事的层级拆分,实现对需求的有效管控和分解,从而确保持续迭代上线。

    敏捷研发管理在当前我们以业务为导向、项目为主的情况下,要全面实施尚有较大困难,当然并非是完全不能做,主要是当前所处的环境、所面向的业务、项目开发模式、人员结构等可能较难满足敏捷模式推行的需要。

    1.4. 基于IPD的研发管理
    之前有简单了解过IPD产品研发管理体系,我认为其中的核心就是“四四四”模型,四四四代表了四大团队、四个流程、四个支撑体系。

    四大团队建设包括建立集成产品管理团队(IPMT)、建立产品市场团队(PMT)、建立产品开发团队(PDT)、建立技术开发团队(TDT)。

    四大流程建设包括建立产品战略流程、建立需求管理流程、建立产品开发流程、建立技术开发及平台开发流程。

    四个支撑体系建设包括建立项目管理体系、建立质量管理体系、建立绩效管理体系、建立成本管理体系。

    个人感觉,基于IPD的产品研发管理从整体上来看是一个相对重量级的体系,要落地执行往往需要从整个公司层面去整体考虑和推动。

    IPD的理念和敏捷开发理念在本质上是基本一致的,比如以市场需求(用户价值)为核心,将产品开发看成一项投资(商业价值),通过CBB—公共基础模块和跨部门的团队准确、快速、低成本、高质量地推出产品(各评审点的多团队参与和决策、通过各种技术改进提升产品开发效率和降低浪费、持续交付)。

    从理论上来讲,IPD研发管理体系是一个较全面的体系,在当前我们的现状下也可能容易出现水土不服的情形,当然其中有一些好的做法是值得借鉴的。

    2. 什么样的软件研发管理体系适合我们的发展
    从项目及产品的研发角度来看,发展到一定阶段的传统IT企业在研发管理上多数都是基于瀑布型的传统研发模式,由于项目的特点及人员的组织结构等因素,项目开发及产品研发的周期往往较长,较难适应市场快速变化的需要,也较难做到对客户的需求进行快速响应。而大部分的互联网公司及一些大厂,推行了敏捷研发模式,或者是在标准化项目管理和敏捷迭代两者融合上进行了相应的实践。

    那么,针对当前我们所面临的一系列问题,究竟什么样的软件研发管理体系在未来一定时期内适合我们的发展?我们需要重构我们的软件研发管理体系吗?我们有必要重构我们的软件研发管理体系吗?带着这些问题,我想主要思考几个方面的问题。

    2.1. 能否快速适应未来业务的发展变化
    技术是为业务发展而服务的,因此在考虑软件研发管理体系构建时,第一个要考虑的问题就是我们的软件研发管理体系能否快速适应公司未来业务的发展变化。特别是在传统IT业务与互联网新兴业务加速融合的大环境下,信息化能力是越来越多客户的第一选择,因此在业务的快速发展方面需要更加强有力的技术支撑,而这个支撑的背后就是需要我们能够有一套能够快速响应变化、敏捷高效的研发体系,特别是能够有一定的前瞻性并支撑到老业务的快速转型和新业务的拓展。

    2.2. 在业务出现较大波动时能否弹性伸缩
    另外一个问题就是,业务在发展过程中,受大环境等诸多因素的影响,定然很难一直都是呈现直线上升的发展趋势,这当中必然会有波峰波谷,只不过这个波峰波谷是大是小的问题。而我们面临的问题则是,当出现较大的波峰波谷的时候,我们的研发管理体系应该如何适应?特别是在软件业务处于相对低谷时,既能够继续保持对技术研发的持续投入,又能够在应用开发等方面有一定的可伸缩性,从而正确地处理好软件生产效益问题。这里面可能会涉及到中高层次软件人才的相对稳定和低层次软件人才的灵活流动等问题。特别是在我们业务多样化的背景下,不同业务单元的发展会有不同的发展路径,对软件研发能力的诉求也有所不同,那么这里面首先涉及到的一点就是如何有效平衡基础研发能力和行业研发能力。

    对于基础研发能力,个人认为应该是一个软件公司最内在的核心技术能力,往往很多时候基础研发工作很难像做行业应用开发那样立竿见影,但这项工作干得不好往往又容易成为行业研发能力的掣肘,这也是我们当前在人工智能、区块链等新技术潮流背景下总感觉难以发力的原因之一。

    对于行业研发能力,个人认为应该要从两个方面去考虑,一个是产品化的能力,其二才是应用开发能力。应用开发能力很好理解,就是目前我们这么多年以来一直在做的各种类型的项目开发,而这里面大部分的项目开发其实都是偏应用层面的开发。而产品化的能力则是最近一两年以来我们重新关注的一个内容,不过这条路上我们尚开始起步,还有很长的路要走,也还有不少坑要踩。个人认为,产品化的能力能否真正发展起来,其中很重要的一点就是要考虑如何与基础研发能力做充分融合。产品化不等同于应用开发,应用开发更多是定制化的开发,是客户导向的软件开发,通常面向的是一个或少数几个的客户;而产品化则是要综合行业、市场、客户群体、新技术等多方面因素的研发,是市场导向的软件开发,面向的是一个或多个的客户群体,甚至面向的是一个市场或跨界市场。

    2.3. 新技术研发及成果转化能否跟上业务变化
    最近几年,新技术层出不穷,在软件架构的发展方面也非常迅猛,历经了单体架构、垂直架构、SOA架构、微服务架构的演化。从我们公司目前的技术研发实际来看,我们有少量的项目/系统采用了SOA架构,然则大部分的项目/系统仍然采用的是单体架构和垂直架构。单从这一点来看,我们在技术领域的持续跟进及成果转化方面已然有落后趋势,这方面需要我们奋起直追才行。当然,出现如今这种局面固然由众多因素催生而成。比如,已有开发框架前端兼容性的问题最近一两年以来常常被诟病,诚然有它内在的好处,然则最近一两年以来,用户对系统的用户体验要求更高了,不再是单纯地满足于功能实现层面,而是开始追求良好的人机交互和界面展现。因此,这方面势必对新技术的要求更加迫切。最近几年,当不少团队都在往前后端分离走的时候,我们至今的绝大部分软件项目开发仍然停留在前后端分离之前,对不少用户界面展现要求高的软件项目而言,难以快速有效响应变化,同时对一些相对比较成熟的软件产品而言也难以做到接口自动化。

    因此,能否在新技术的研发上抓住正确的方向并加快研发成果转化,为业务的快速变化提供强有力的技术支撑,是一个摆在我们面前急需解决的课题。从当今新技术的发展趋势来看,研发架构方面,我们虽说不能完全抛弃传统的单体/垂直架构,但我们必须要往微服务架构方向迈进,除了与最新技术接轨之外,更重要的是如何进行业务解耦,沉淀行业积累,并反向推动人员组织层次的变革,提升软件生产效率,提高软件质量。

    除此之外,对于人工智能、区块链等新领域,也是需要综合业务应用场景打造适合我们自身发展的技术+业务融合之路。

    2.4. 在标准化和敏捷迭代之间如何平衡
    标准化的软件研发道路固然有不少好处,有严谨的流程、规范的体系、固定的套路,当然更多的则是瀑布开发模式,虽然最近几年也陆续有迭代开发的模式,但更多的是被动式响应,而且这种迭代开发模式基本上是大阶段的划分,在每一个大阶段里面依旧是一个典型的瀑布开发模式,即历经需求分析、交互原型设计、UI设计、Web前端开发、程序开发、系统测试、部署实施等步骤,横跨周期往往较长,一旦发生需求变更,变动的代价过高。

    敏捷开发强调以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

    那么,问题来了,既然标准化项目管理模式下存在太多流水线作业及效率低下等问题,那么我们能够直接转向敏捷迭代模式呢?世界上万事万物都是对立统一的,个人认为不论是标准化项目管理模式还是敏捷迭代项目管理模式都有其擅长的一面。一方面,在现有的以项目为主导的软件开发体系中,标准化模式是我们一直以来的主要做法,也积累了不少经验做法;另一方面,采用敏捷迭代模式对于产品复杂不断有新需求加入等场景是比较适合的。所以这里面更多的是考虑如何更好地平衡标准化项目管理和敏捷迭代两者之间的关系。基本的思路就是结合标准化项目管理和敏捷迭代的优缺点进行适度裁剪,既能提高软件质量和软件开发效率,也能够保留一定的规范性和软件过程文档。例如,针对项目管理,通常是五个过程组:启动、规划、执行、监控、收尾,那么我们其实可以结合实际将规划提前,将监控贯穿于执行过程,这样就势必要求在启动时也要做好项目计划相关工作,在执行过程中抓住关注点并定期监控其执行情况,在收尾阶段做好项目回顾总结。

    不论采用何种模式,我们的根本目标就是达到更低的成本实现更快速、更可靠的交付。近年来比较火热的是DevOps。DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

    因此,我们的软件研发管理体系中是否应该引入DevOps,进而改善公司组织文化、提高员工的参与感、提高交付效率,我想这也是需要重点关注和考虑的。

    2.5. 组织过程资产能否持续积累并盘活
    组织过程资产指一个学习型组织在项目操作过程中所积累的无形资产。组织过程资产的累积程度是衡量一个项目组织管理体系成熟度的重要指标,项目组织在实践中形成自己独特的过程资产,构成组织的核心竞争力。

    组织过程资产主要包括但不限于以下内容:项目组织在项目管理过程中指定的各种规章制度、指导方针、规范标准、操作程序、工作流程、行为准则和工具方法等。项目组织在项目操作过程中所获得的经验和教训,其中既包括已经形成文字的档案,也包括留在团队成员脑子中没有形成文字的思想。项目组织在项目管理过程中形成的所有文档,包括知识资料库、文档模板、标准化的表格、风险清单等。 项目组织在以往的项目操作过程中留下的历史信息。

    经过多年的软件开发,我们做了大大小小形形色色的软件项目和产品,也逐渐积累了一些行业化的软件项目,但总的来看,能够形成规模化效应的软件产品尚较为匮乏,更多的是以定制化开发为主的软件系统,当然也积累了不少项目经验。在这过程中,也积累了不少标准、规范、流程、模板等各类软件过程资源。然而,从目前掌握的情况来看,这些资源是分散的,不够体系化的,还谈不上真正意义上的资产,至少在价值的发挥上还不充分。况且,软件行业这几年的人才流动率明显加快,人员更替的速度以及未能体系化的过程资产积累,加剧了组织过程资产的盘活难度。

    那么,构建一个相对健全的、动态的、能够适应未来业务发展的组织过程资产库就显得尤为重要。这既是软件研发管理体系的一个重要组成部分,也是公司层面应该给予充分重视的。在组织过程资产库构建的过程中,其中很重要的一点就是如何让研发知识与经验成为公司的宝贵财产,这里就要充分考虑研发知识管理。知识管理把“隐形知识显性化”,是一项涉及知识库、过程资产、环境和交流等元素的整合过程,所管理的知识将作为一个团组织中过程资产的重要组成部分。对于软件研发而言,我们需要考虑怎么把业务人员和技术人员脑中的蓝图转化为显性知识。

    3. 构建我们的软件研发管理体系应包含哪些内容
    软件研发管理体系的建设离不开几个关键要素:人员、技术、过程、资源,并在此基础上配以相应的管理手段。进一步来看,要构建适合我们自身发展的软件研发管理体系,需要着重考虑几个能力体系的建设,即:人员组织能力、技术研发能力、过程管理能力和资源建设能力。

    前面也有针对“什么样的软件研发管理体系适合我们的发展”进行了一些相对粗浅的探讨,那么在考虑如何构建适合我们发展的软件研发管理体系之前,我想这里首先要明确一下我们期待构建的软件研发管理体系。我们公司的业务涉及众多行业客户,一直以来主要以定制化项目开发为主,同时也涉及运维服务,而在产品研发等方面则处于起步阶段,且在一段时期内项目、产品、服务将会长期并存,因此,个人认为适合我们的软件研发管理体系应该至少经历三个阶段,包括初期的标准化软件研发管理体系、中期的标准化与敏捷相结合的软件研发管理体系和后期的敏捷化软件研发管理体系。

    基于上述这样的考虑,正常来讲我们当前应该在标准化的软件研发管理体系中要做进一步强化,而考虑到市场的快速变化、技术的日益进步,个人认为我们当前就需要开始考虑标准化的与敏捷相结合的软件研发管理体系。为什么还需要考虑标准化的软件研发管理体系呢?主要是传统的定制化的软件项目开发依旧占据主体,且目前在这方面仍然有非常大的改进提升空间,然而标准化的模式常常是过于强调标准、规范、流程,开发模式过于线性化,因此需要引入敏捷开发模式。所以,我们又需要考虑敏捷的软件研发管理体系,这主要是为了更好地适应市场变化、更快速地响应客户需求,更好地提升软件开发生产效率。

    3.1. 人员组织能力
    关于人员组织能力,个人认为有两个关注点:一是团队的发展,二是个体的发展。这两者是相辅相成、互相融合促进的。综合来看,人员组织能力的建设主要包括设立与公司战略、业务、技术发展相适应的组织架构,并配以构建相对完整可行的岗位体系和对应的人员考核体系,同时在团队建设等方面持续改进与提升。

    关于组织架构,当前的组织架构虽然解决了一些曾经的主要矛盾,但依然存在不少问题,突出的一点就是核心薄弱,即核心技术能力不强,仍旧需要投入大量的人力到各行业的应用开发中,当然这与我们一直以来承接定制化的软件项目开发不无关系。这是当前乃至未来一定时期需要解决的。

    同时,最近几年来的组织架构主要是以职能型组织架构为主,产品线为主导的研发模式尚不成熟,针对项目及产品的团队构建主要是以项目经理来驱动,在项目团队的组成方面固然与互联网的项目团队截然不同。在团队建设方面,需要进一步打通团队之间的壁垒,强化团队的整体协同作战能力。

    在岗位体系方面,特别是对人员的绩效评价方面,需要在已有的岗位体系基础上进一步考虑如何更好地执行落地,确保个人绩效目标与团队绩效目标的一致性和顺利达成。

    3.2. 技术研发能力
    结合我们的实际,我认为在技术研发能力方面要考虑四个方面:一是技术预研,二是技术开发,三是产品开发,四是定制开发。

    关于技术预研,通俗来讲就是:预研=预先+研究。这种预先研究通常来源于几个方面,例如来自外部竞争对手的迫使、来自客户或市场的需求、来自公司高层的决策等。为什么要做技术预研呢?这是扫清前行障碍的过程,这为后续展开总体设计、详细设计指明了方向,也是持续积累公司技术能力、保持与新技术同步而不至于脱离轨道的方式之一。

    关于技术开发,其实这里主要指与基础平台、公共组件、关键技术等方面的技术研发。另外一个方面来理解,技术开发是技术预研的延续,是在技术预研成果经论证的基础上开展的一系列能促进公司发展、业务发展、技术发展而开展的技术研发工作。

    软件产品是指向用户提供的计算机软件、信息系统、套装软件或在提供计算机信息系统集成、应用服务等技术服务时提供的软件,是通用的产品应用于某一行业领域而不是像软件项目一样为某一需求或者单位定制开发。

    软件项目主要为特定企业开发或者部署实施一套专用的系统,在进入项目开发之前需要与用户进行具体的交流和讨论,了解用户心中对于软件预期的样子,后经过招投标,签订合同,实施交付。

    关于产品开发,这方面我们尚处于起步阶段,尚缺乏一套完整可行的产品研发流程及最佳实践,需要摸着石头过河,也需要长期坚持不懈地努力。

    关于定制开发,当前主要是基于客户需求的软件项目定制开发,后续还会包括基于产品衍生出来的定制化开发。前面的这种方式是我们当前最熟悉的模式,主要面临的困境是两个:一是如何实现快速交付,二是如何实现成本可控,从而提升软件项目的利润。

    做项目侧重于在最短的时间内,按照客户的需求开发出操作敏捷,用户体验良好的软件。而做产品则侧重于市场驱动,时间相对充足,但要开发出有竞争力,有自身特色,且受客户欢迎的产品,要求功能响应速度快,操作简单,界面美观。

    技术预研+技术开发是强化内核的内在需要,定制开发是现阶段的生存根本,产品开发则是为未来发展铺路。

    3.3. 过程管理能力
    过程管理能力主要包括项目管理、开发管理、质量管理和配置管理等几个方面,需要一套完整合理的流程贯穿整个过程。

    在项目管理方面,我们需要梳理当前项目管理体系的标准、规范、流程及相关实践,建立以过程为核心、以度量为基础、以人为本的可裁剪、受认可、能执行的信息集成项目管理体系,进一步规范公司的项目管理,提升项目群管理能力。结合项目管理的五大过程组(启动、计划、执行、监控、收尾),并结合敏捷迭代的思想,形成标准化项目管理与敏捷迭代相结合的具有实际指导意义的方法体系,同时将这套方法体系以指南性文件、规范性文件等形式传导到相关人员,确保可落地执行。此外,为加强过程管控、资源共享、工作协同,组建PMO团队,实现对项目群及重大项目的统一管控与决策支持。

    在开发管理方面,一是要落实统一的软件开发规范,包括架构规范、设计规范、UI规范、编码规范、测试规范等。强化设计及开发关键环节的评审,包括对需求、概要设计、详细设计、UI设计等的设计方面的评审,对测试用例等方面的评审,对代码的评审检查(例如利用SonarQube进行代码的自动检查等)及发布评审等。同时通过试点+逐步铺开的方式着力推进CI/CD的落地。

    在质量管理方面,进一步强化项目质量审计,逐步改进软件过程生产效能。而在配置方面,则加强对配置项的识别、配置空间的管理、变更控制等,规范软件开发过程,确保构建正确的系统。正确应用软件配置管理是开发高质量软件所不可缺少的。软件配置管理的过程是软件开发过程中质量管理的精髓。

    综合来讲,在过程管理方面就是要形成一套适用的软件研发管理流程,并配以相应的节点管控,让不同开发角色之间即各司其职又相互融合促进,从而促进软件开发自组织能力的逐步提升,充分调动软件开发人员的主动性和积极性。

    3.4. 资源建设能力
    简单来讲,资源建设是软件研发管理体系中的支撑体系。资源建设主要包括了一系列的制度规范、工具、模板、过程资料及交付物(例如项目文档、源代码等),以及相应的经验、知识沉淀等。一是要适时梳理相应的制度、规程、标准、规范、文档模板等,形成标准化资源库;二是要对不同行业历年来的项目资料及源代码分门别类做好规划和归档管理,形成静态库(归档库)和活跃库,同时做好数据安全管理;三是要对软件研发人员及工作中的一些隐性知识转化为显性知识,并逐步构建软件研发的知识图谱,促进知识经验的持续积累与转化,并通过链条式、网状式等方式实现知识分享与传播,形成经验知识库。

    展开全文
  • 项目研发管理

    千次阅读 2018-03-14 14:07:45
    1、研发管理定义规范好一系列的工作流程,规范好各个岗位的工作职责,让工作更加协同,让效率更加高效。2、研发管理过程2.1、三个阶段首先我认为研发工作分为设计、开发、测试三个阶段。如果项目迭代周期为一个月,...

    1、研发管理定义

    规范好一系列的工作流程,规范好各个岗位的工作职责,让工作更加协同,让效率更加高效。

    2、研发管理过程

    2.1、三个阶段

    首先我认为研发工作分为设计、开发、测试三个阶段。如果项目迭代周期为一个月,那么我会把时间均分为三个十天。阶段性的验收项目成果,对滞后的工作,好及时作出调整,保障项目进度平稳的向前推进。 
    研发管理三阶段

    2.2、 四次设计

    在产品原型和需求到达开发人员手上时,我们要做的第一件事是设计。 
    1. 前端后接口设计(接口定义json文档、controller方法、请求实体类、响应实体类) 
    2. 服务端接口设计 (service方法、业务实体类、参数实体类) 
    3. 数据库表设计 (数据表设计pd文档) 
    4. 测试用例设计 (测试用例文档)

    2.3、 四次评审

    每次设计都需要一次评审来验证合理性,让设计者走出思维的死角。 
    1. 前后端接口评审 (前后端开发评审http接口是否漏定义,接口的请求和响应数据结构是否合理) 
    2. 服务端接口评审(后台开发评审service接口定义和业务测试测试代码是否符合业务流程) 
    3. 数据库表评审 (后台开发评审表的命名规范、类型规范、字段规范、约束规范) 
    4. 测试用例评审(测试内部根据原型和需求文档评审测试用例设计的是否合理)

    2.4、 三次测试

    测试是工作阶段性验收的标志,测试通过的功能才能说开发完成。 
    1. 自动化业务测试 
    2. 手工增量测试 
    3. 手工全量测试 
    自动化业务测试主要是验证代码的业务逻辑是否正确,其次是验证代码的语义是否正确。 
    手工增量测试主要是验证本次迭代开发的新功能是否正确。 
    手工全量测试主要是验证本次迭代对系统的影响是否正确。

    2.5、 三次发布

    发布是一个持续的过程,是一步步前进的过程,这样做主要是减免线上环境的发生问题的概率。即上一步没有成功,绝对是不能走到第二步;第二步成功了,第一步可能是成功的。例如下面的发布流程: 
    1. 发布开发环境 (失败) 
    2. 发布开发环境 –> 发布测试环境 (失败) 
    3. 发布开发环境 –> 发布测试环境 –> 发布线上环境 
    开发环境采用自动化发布,让问题及早的暴露。开发环境发布ok后,通过手工发布到测试环境,保证测试环境的稳定性。测试全部通过后,最后才手工发布到线上环境。

    3、研发管理的意义

    采用分模块设计结合集体评审的制度,是放权的有力保障。分模块设计有利于个人专注业务,集体评审有利于个人对系统有整体的认识。设计可以提前暴露产品设计逻辑性和可行性。设计是一次自我方案评估的过程。评审可以磨合团队的成员的设计和开发理念,是规范顺利推广的提前。

    展开全文
  • 软件工程项目研发实施管理流程,专业经验汇总,能为从事IT行业者提供最切实际的帮助,内容图文解说,一目了然,是不可多得的实战经验,欢迎下载,欢迎评论。
  • 项目管理之敏捷开发总结

    万次阅读 2018-04-11 23:27:05
    瀑布模型:简单说就是先定好需求和相关文档,然后构建框架,然后写代码,然后测试,最后发布个产品一旦文档...需求如同接力棒从业务方传递给产品经理,再从产品经理传递给研发团队。信息每经过一次传递都有损失,研...

    瀑布模型

    简单说就是先定好需求和相关文档,然后构建框架,然后写代码,然后测试,最后发布个产品

    一旦文档需求确定,开发人员就按文档开发,直到产品开发完后,才会拿出来给客户。不过这种方式基本不适应现今快速发展的市场现状了。

    弊端:

    1.接力棒的协作模式带来信息差:瀑布模式下,业务、产品、研发三方很少共同参与讨论。需求如同接力棒从业务方传递给产品经理,再从产品经理传递给研发团队。信息每经过一次传递都有损失,研发团队不了解需求背后真正的业务诉求,业务方不了解技术方案背后的权衡。

    2.难以响应变化瀑布模式下,所有的需求分析和设计工作在开发前完成,并假设需求不会改变,研发过程只需遵循最初的项目计划和范围。事实上,对需求的发掘和理解,应该是一个持续的过程,需要不断地反馈。”


    敏捷开发:

    敏捷(Agile)作为一种开发流程, 目前为各大公司所采用, 敏捷流程的具体实践有XP 和Scrum

    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征


    Scrum:

    目的

    1. 适应变化。Scrum 的一个基本假设,就是外部需求模糊而难以理解。Scrum 对此的理念是:让客户直接看到半成品,他们才知道自己要什么。很多 Scrum 的原则都是围绕如何解决这个问题的:比如每个 Sprint 结束时由 Product Owner 为客户进行展示,又比如任务细化一般不超过一个 Sprint。理解了这一点,才会理解为什么 Scrum 似乎总在变化,因为需求总在变化。
    2. 快速迭代。Scrum 的另一个基本假设,是团队生存在一个快速变化且充满竞争的世界。如果自己一年半才能发布一个新版本,而竞争对手半年就能发布,那么几年之内,我们就会被对手甩得远远的。Scrum 对此的理念是:发布即 Milestone(里程碑),宁可每次发布二十个功能发布五次,也不要在内部搞五个 Milestone 然后一口气发布一百个功能。理解了这一点,才会理解为什么 Scrum 会认为发布时砍功能是一种正常情况而非一种失败。
    3. 我们作出的决定中, 50% 都是错误的。早早失败,早早学习。因为发布周期缩短,团队没有能力保证作出的每一个决定都正确,很多开销都必须花在试错上;快速发布实际上导致 Scrum 团队的抗风险能力弱于瀑布模型团队,因为一个人的离职或病假都可能对单一功能的进度造成影响,不利于短期频繁发布。

      Scrum 对此的解答是:不要试图不犯错误,而是保证小的错误能被尽快发现从而不会酿成大错

    流程:

    1.首先我们需要确认一个 PB ( Product Backlog , 即按优先顺序排列的一个产品需求列表) ,这是由 PO(Product Owner) 负责的

    2.ST(Scrum Team) 会根据 PB 列表,进行工作量的预估和安排

    3.有了 PB 列表,我们需要通过 Sprint Planning Meeting( Sprint 计划会议)来从中挑选出一个 Story 作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog

    4.Sprint Backlog 是由 ST 去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成)

    5.在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)

    6.做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员

    7.当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消)

    8.最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中


    极限编程:简称XP

    思想:交流、简单、响应和勇气:加强交流;从简单做起;寻求反馈;勇于实事求是


    敏捷开发的特点

    1)敏捷开发中更加强调沟通,沟通频率可能比以前更高,沟通时间可能会比以前更长,占用更多的个人工作时间,反而可能因此导致实际开发时间起过原来开发出某个功能的时间; 

    2)敏捷开发是从用户视图出发,可能会要求工程师成为所谓“全栈工程师”,使开发人员反而感觉工作量增加了,短时间内会表现出开发效率的下降,而且要求所有开发人员对需求的理解能力也要求更高了,所以很多人会感觉敏捷开发对人员的要求更高,其实是因为对人员要求的改变导致现有开发人员能力木桶效应现象发生。 

    3)快速的迭代使重构工作量增加,会感觉功能不断被修改导致了很多浪费。这种感觉如果不能正确认识,不仅会误以为影响了工作效率,而且会使程序员很受伤,因为他们认为是在不停地返工。 

    4)信息的透明性要求较多的数据收集,敏捷成熟度越高,收集的信息就越多,收集这些数据会占用一定的精力,如果不能够正确的理解这些数据的价值,会让程序员感觉浪费了很多时间在做无用功,反而降低了开发效率。 


    敏捷开发的流程:

    需求评审:

    (1)首先,一个story被PM提出时,需写好用户故事卡片和详细描述;

    (2)接着,PM会找RD、QA的leader进行讲解,并交review,review人提出问题及改进意见;

    (3)然后,PM和负责具体开发RD、测试QA进行讲解和讨论,RD、QA提出问题、疑问,PM解答,并对详细描述进行修改。

    (4)最后,所有参与者觉得没有问题后,PM辅助QA补充详细的验收标准,RD对其进行review,并作为自测和自动化case编写的参考。

    (5)此外,在开发和测试的过程中,若发现新问题,PM随时响应,答疑解惑,修改设计的不足。


    敏捷开发的思想

    1)拥抱变化:各种因素都会影响计划的执行,所以计划要短,及时调整才能响应一切变化导致的计划的不可行性,避免走弯路。 

    2)快速响应:市场环境的变化,越来越要求产品、服务的响应及时。比如按照传统方式,规划半年一个版本,一旦需要调整需求,后面所有的计划都得改变,会为项目管理带来极大的挑战,变化的成本奇高,多数情况下会因为多数人的反对而不了了之。响应变化胜过遵循计划

    3)快速将功能推向市场变现:迅速占领市场更显得尤其重要,这是在向时间要效益。比如做个用户系统,按照程序员的想法,一次性把用户注册登录、修改密码、忘记密码、记住密码、登录验证码、注销等功能设计完,而如果按功能逐版本开发而不是一次开发完成,而是放在不同的版本里,可能需要更多天数,因为里面会有重构、修改界面等,但是应用可以在第3天就上线。争取了15天上市时间,有哪个系统因为没有验证码在上线后第3天就就被恶意注册?有几个用户会在6天后就忘记密码?有几个人会在9天后就修改密码?有几个人会因为登录频繁因为没有记住密码功能而不在使用?,讲到这里,那位朋友想起他们在上一个版本中的一个功能,如果这个功能按照敏捷的方式开发,可以早3个月推向市场,每个月有上千万的收(上线后的效果统计数据),这才是敏捷真正的价值所在。 

    4)做最值得做的事:什么事最值得做,什么事就优先级最高,也就是ROI最高,ROI是评价需求优先级的唯一指标。其实ROI是一个综合指标,非常复杂的综合指标,它与开发工作量、市场需求迫切程度、技术关联性、市场价值等因素有关,需要全方位评估。


    敏捷开发的误区

    1)敏捷开发不是用来管理开发人员的,不是用来提高开发人员的工作效率的,而是企业全面提升团队绩效的方法

    2)瀑布开发模型是以文档为驱动的,把需求文档写出来后,根据文档进行开发的,而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。 

    3)在敏捷开发中每次迭代都被成为一个sprint,中文意为“冲刺”,可见其速度与效率

    4)尽管对敏捷开发的变通运用,可以带来巨大的效益,但现实情况是,多数变通能力需要经历学习曲线的规律。当人们和组织在学习的过程中,在经历阶跃变化前,交付能力可能还会下降,当经历这个转变后,才开始获得交付能力的提升。

    5)当敏捷开发被大爆炸式地应用于大型项目、方案或整个组织时,存在一个显著的风险,即一个敏捷开发模式的好处可能不会被意识或理解。组织及其员工常常会继续着他们一直在做的事情,却自认为已经使用了一个“敏捷”方法。转变能力是一个长期的学习和改变的过程。企业在发展,同时执行业务最好的方式也在不断转变。因此,执行一个大爆炸式的“敏捷”转型后,想当然地认为进一步的改进不再必要,是一个错误认识。

    6)没有MRD,如何管理好需求?使用story模式来管理需求,将庞大的MRD划分为一个个可独立交付的story(通常每个story能在1~5天内完成,包括设计、开发、测试),需求清晰明了可节省大量的需求评审时间。

    7)项目一开始,XP 就强调通过对软件的不断测试来获得反馈,程序员尽可能早的把软件交给客户,并实现客户对软件需求提出的变化,有了这些基础,XP 程序员就可以自信的面对需求和软件技术的变化。从这里可以看出通过一个个短小的迭代周期,我们就可以获得一个个阶段性的进展,并且可以及时形成一个版本供用户参考,以便及时对用户可能的需求变更作出响应。

    8)敏捷是万能的么? 我上学的时候老师教我们 “形式化的软件开发方法 (Formal Method)”,  “里程碑式的开发 (Plan-driven development)”, 它们都被淘汰了?  答: 不是, 和任何武功和战术一样, 敏捷有它最适用的范围, 我借着酒劲, 画一个表:

    客观因素\最适用方式敏捷 (Agile)计划驱动 (Plan-driven)形式化的开发方法 (Formal Method)
    产品可靠性要求不高, 容忍经常出错必须有较高可靠性有极高的可靠性和质量要求
    需求变化经常变化不经常变化固定的需求,需求可以建模
    团队人员数量不多较多不多
    人员经验有资深程序员带队以中层技术人员为主资深专家
    公司文化鼓励变化, 行业充满变数崇尚秩序, 按时交付精益求精
    实际的例子写一个微博网站;开发下一版本的办公软件; 给商业用户开发软件开发底层正则表达式解析模块; 
    科学计算; 复杂系统的核心组件
    用错方式的后果用敏捷的方法开发登月火箭控制程序,  前N 批宇航员都挂了。用敏捷方法,  商业用户未必受得了两周一次更新的频率。敏捷方法的大部分招数都和这类用户无关, 用户关心的是:  把可靠性提高到 99.99%,  不要让微小的错误把系统搞崩溃! 

    专有名词:

    PB: Product Backlog , 即按优先顺序排列的一个产品需求列表,只能有一个产品backlog

    poProduct Owner产品负责人

    Sprint Backlog有了 PB 列表,我们需要通过 Sprint Planning Meeting( Sprint 计划会议)来从中挑选出一个 Story 作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog

    sprint backlog和Product Backlog的关系


    每个矩形都表示一个故事,按重要性排序。最
    重要的故事在列表顶部。矩形尺寸表示故事大小(也就是以故事点
    估算的时间长短)。

    sprint每次迭代都被成为一个sprint,中文意为“冲刺”

    story:翻译是故事,本意是产品的功能,backlog中包含了许多story,故事中包含了如下字段

    1、id

    2、name,也即功能名

    3、重要性,越高越重要

    4、初始估算,该故事所需工作量,单位是故事点,3个人需要4天时间,就是12故事点

    5、如何做演示,测试规范

    6、注解

    例如:



    注意点:

    1、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品

    2、Scrum 对此的理念是:发布即 Milestone(里程碑),宁可每次发布二十个功能发布五次,也不要在内部搞五个 Milestone 然后一口气发布一百个功能。理解了这一点,才会理解为什么 Scrum 会认为发布时砍功能是一种正常情况而非一种失败。

    3、sprint计划会议:

    内容:

    (1)制定Sprint目标

    (2)团队成员名单

    (3)Sprint backlog(Sprint中包括的故事列表)

    (4)确定sprint 演示日期

    如何做:

    创建索引卡,放到墙上,这种用户体验比计算机和投影仪好得多。


    每个故事下面有多个任务,任务只会存在于故事下面,而不会存在于product sprint中


    4、们已经完成了 sprint 计划会议,应该创建 sprint backlog 了。它应该在 sprint 计划会议之后,第一次每日例会之前完成,这样规划:没做的,正在做的,已经做的,和燃尽图


    经过每日scrum后变成这样:


    最后变成这样:


    对于燃尽图:


    5、每日例会,时间15分钟,每个人都会一边描述昨天已经做的事情和今天要做的事情,一边移动任务板上对应的即时贴,如果他讲的是一个未经计划的条目,那他就新写一张即时贴贴到板上。如果他更新了时间估算,那就在即时贴上写上新的时间,把旧的划掉。

    如果有人不知道今天干什么,解决方法

    (1)请人添加更多的即时贴上去。接下来我就会对觉得自己没事可干的人说,“我们已经过了一遍任务板,你们现在对今天要做的事情有想法了么?”。希望他们有点儿概念了。

    (2)如果他们还不知道该干什么,我会考虑他们是不是可以去跟其他人结对编程。

    (3)从任务板右下角的“Next”区域中拿出一两个故事,放到左边的“not checked out”列中。接下来重新进行每日例会。告诉产品负责人一声,你已经把一些条目加进了 sprint

    6、对于大部分的团队sprint长度为三周,一个sprint包含10个故事左右

    7、对于故事的任务量估算需要每个成员都参与,每个故事的估算,需要每人给出一个故事点,如果两人故事点相差太大,要讨论为什么,直到把所有工作估算完

    8、Sprint 演示(有人也叫它 sprint 回顾)是 Scrum 中很重要的一环,且所有的 sprint 都结束于演示

    9、Scrum 注重的是管理和组织实践,而XP 关注的是实际的编程实践。这就是为什么它们可以很好地协同工作——它们解决的是不同领域的问题,可以互为补充,相得益彰

    10、测试驱动开发(TDD):测试驱动开发意味着你要先写一个自动测试,然后编写恰好够用的代码,让它通过这个测试,接着对代码进行重构,主要是提高它的可读性和消除重复。整理一下,然后继续

    11、把测试人员放到 Scrum 团队来提高质量。如果团队在做 TDD,从第一天开始,大家都会花时间来编写测试代码,此时测试人员应该跟编写测试代码的开发人员一起结对编程。

    12、多项目一起进行,那么两个项目的sprint应该是同步的


    同步进行的 sprint 有如下优点:
    可以利用 sprint 之间的时间来重新组织团队!如果各个sprint 重叠的话,要想重新组织团队,就必须打断至少一个团队的 sprint 进程。
    所有团队都可以在一个 sprint 中向同一个目标努力,他们可以有更好的协作。
    更小的管理压力,即更少的 sprint 计划会议、sprint 演示和发布

    13、团队构建:




    参考资料:

    1、https://blog.csdn.net/nocky/article/details/51236848

    2、https://blog.csdn.net/xinxing__8185/article/details/46708439

    3、https://blog.csdn.net/baynkbtg/article/details/52402727

    4、https://blog.csdn.net/liyangbing315/article/details/5387129

    5、https://blog.csdn.net/ostrichmyself/article/details/5375223

    6、http://www.cnblogs.com/xinz/archive/2011/04/27/2031118.html

    7、https://blog.csdn.net/b0Q8cpra539haFS7/article/details/79245096

    8、https://www.zhihu.com/question/19638322

    9、scrum and xp chinese version.pdf


    展开全文
  • 项目研发管理流程

    2020-02-25 09:48:43
    之前公司我除了带架构和业务研发团队,PMO也在我这边管理,对于200多人的研发团队,下面介绍下整个研发管理流程,瀑布式开发模式,虽然比较慢,不过很稳,适合传统企业。 1、立项阶段 发起人提出需求(公司...
  • 敏捷开发项目管理流程

    千次阅读 2017-08-30 15:21:43
    前段时间给大家整理了敏捷开发的流程,最近在整理敏捷开发项目的流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际...
  • 项目开发和管理流程(持续更新)

    千次阅读 2018-05-12 11:49:42
    我们要找到符合自己项目开发和管理流程,而不是对一般流程照搬,并通过同类项目问题的根因分析来不断优化流程 需求阶段 需求工具:axure 需求来源(业务团队原始需求、客服备案的用户问题(迭代)、研发对实现方案...
  • 项目管理,项目经理必修课,IT行业管理方法
  • 研发管理 - 流程

    千次阅读 多人点赞 2018-12-18 17:51:29
    研发管理(管理篇) 标签(空格分隔): 项目管理 ##情况介绍 2011年至2014年主要致力于国内某个大型企业的财务公司的内部资金结算系统,由于系统主要业务是对公、对私、代理资金划转交易,交易金额少则几万多则亿...
  • 研发管理流程(二)

    千次阅读 2019-08-19 15:44:36
    对应项目管理知识点: 合同类型:总价合同、工料合同等类型 项目立项: 过程 说明 立项 召开项目启动会:将总体的计划、人员安排、例会安排、下一步的工作等信息同步给大家 设计 ...
  • 项目管理研发项目经理为何难做

    千次阅读 2016-07-03 10:30:08
    作者:德通咨询 任传宏...项目管理者联盟项目管理者联盟 记得毕业参加工作后,就进入一个项目,主要是跟这一些有经验的工程师学习,帮领导做一些杂事,比如帮他们做一些简单的测试、整理一些测试报告,偶尔也写一些...
  • 研发管理工具推荐

    千次阅读 2018-07-09 12:58:44
    我来介绍一下我所找到的,好用的敏捷工具:国内的「Leangoo(中文名:领歌)」Leangoo是一款基于看板的项目协作工具,Leangoo是由国内最权威的Scrum中文网精心打造,融入了先进的敏捷管理思想。我们可以使...
  • 研发管理心得整理

    千次阅读 2019-02-20 12:34:36
    研发管理心得整理 在现在的公司工作了快5年了。陪伴着公司从创业初期一直走到现在, 公司业务也从0发展到注册用户5000W+、月流水4000万,年流水5个亿。 研发团队从我一个人的单打独斗扩张到现在几个团队。一路走来...
  • 青铜器研发管理软件RDM_IPD+CMMI+Scrum一体化研发管理解决方案, 1、IPD确保方向的正确性,强调市场驱动、投资回报,将市场、财务、竞争、技术有效融合为一体; 2、CMMI强调规范化、精细化管理,将IPD的策略落实为...
  • 现在这 时代越来越浮躁,什么都要快,互联网 唯快不破。 快要需要有趁手的工具 和 规则滴....
  • 在 TGO 鲲鹏会南京分会成立当天,苏宁易购 IT 总部执行副总裁、TGO 鲲鹏会南京分会导师乔新亮带来《研发管理十条经验》,以下内容根据当天演讲整理,有部分删减。 苏宁的 IT 研发体系大概有 8000 多技术研发人员、...
  • 新项目研发是企业可持续发展的必须途径,但研发活动投入大、期限长、风险高,因此,实施科学有效的研发项目管理十分重要。门径管理流程为企业提供了标准化、系统化的项目管理方法。北京低碳清洁能源研究所运用门径管理...
  • 嵌入式研发项目管理的方法论

    千次阅读 2016-05-22 14:59:02
    将嵌入式研发项目的一般流程予以总结,以达到:减少走弯路,减少产品缺陷,保持清晰的头脑,不迷茫,提高生产力。
  • 产品研发管理流程

    2012-01-19 14:18:02
    产品研发管理流程 威科姆公司 PPT课件 七个阶段: 立项 项目计划 需求开发 设计&实现 测试 发布 结项 三类过程: 管理过程 研发过程 支持过程
  • 产品研发项目管理软件哪个好?

    千次阅读 2019-04-12 11:36:16
    在没接触研发项目管理软件之前,我只是一个懂得埋头苦干的产品狗,整日苦恼于如何提高研发项目成功率,进行项目质量与成本控制,在信息反馈、流程管理、资源配置、报表统计等一系列问题中挣扎,不断面对难以控制的...
  • 华为研发项目管理方法核心五法则 时间:2day 课程背景 某位学员咨询樊老师:PMBOK看了很多遍了,PMP的证书也拿到了,但还是不知道如何管理一个项目。 樊老师:PMBOK就像一本项目管理的字典,把字典背下来就会写文章...
  • eIPD研发管理平台所创建的流程管理涵盖企业研发管理过程中涉及到的各种流程,可以规范产品开发全过程管理,实现产品开发输入(需求管理)、产品开发过程(项目管理、绩效辅导)、产品开发输出(文档管理)以及持续...
  • 从事研发管理的心得

    千次阅读 2019-07-31 16:29:11
    从事管理工作的心得 前言 职业生涯中,从技术走向管理似乎已成为普遍并达成共识的职业规划套路,但要完成这样的转变过程是需要一定的思考的,它肯定不会也不应该如同开关切换一样简单,因为在技术与管理之间肯定...
  • 软件研发管理之版本管理

    千次阅读 2014-01-21 19:11:57
    版本管理是软件研发管理中比较容易忽视的一环,这当然是比较好理解的,因为版本管理毕竟和具体业务关系不大。其实,版本管理是很多更高级管理制度的基础,如果版本管理做得糟糕,类似代码审查一类的工作就很难高效...
  • 研发管理总结

    千次阅读 2016-04-20 17:14:55
    我的研发管理之路已有两年,在此总结一下经验得失   1 团队文化 我觉得团队建设一般由几个过程:茫然混乱,强制规则,自觉习惯,主动创造。 茫然混乱阶段,靠工程师自我素质,道德束缚,靠个人英雄完成任务,走...
  • 在《中国制造2025》中,医药...近年,在我国对医药企业研发创新药的大力倡导下,医药研发投入快速增长,但总体研发投入仍处在较低水平,2018年仅占收入的5%左右,远不足发达国家的19%。对于医药研发企业来说,药物...
  • 研发管理人员如果没有良好的理论素养和全局观,把握好改进方向,而是同其他人员一样陷入技术或经验的泥潭,或是被动接受大家的处理意见,就不能与高层领导产生良性互动,从而逐步找到解决问题的突破口,打破困局。...
  • 我们的管理:定制研发管理

    万次阅读 2013-11-18 15:11:46
    我们的管理:定制研发管理一、组织结构我们先按照客户规模分类,行业500强之外属于非战略客户定制研发中心,行业500强属于战略客户定制研发中心。在战略客户定制研发中心又细分为核心战略客户定制研发团队和非核心...
  • 分享一个公司规模近200,研发占一半的创业公司 Worktile 在研发管理方面的玩法,仅供百人左右研发团队参考~ 什么是研发团队,简单的说,就是由你熟悉的那帮穿格子衬衫程序员为核心组成的团队,就是研发团队。本来,...

空空如也

1 2 3 4 5 ... 20
收藏数 249,229
精华内容 99,691
关键字:

研发项目管理流程