精华内容
参与话题
问答
  • 研发管理心得整理

    千次阅读 2019-02-20 12:34:36
    研发管理心得整理 在现在的公司工作了快5年了。陪伴着公司从创业初期一直走到现在, 公司业务也从0发展到注册用户5000W+、月流水4000万,年流水5个亿。 研发团队从我一个人的单打独斗扩张到现在几个团队。一路走来...

    https://www.toutiao.com/a6658151816229814791/

     

    2019-02-16 11:37:55

    研发管理心得整理

    在现在的公司工作了快5年了。陪伴着公司从创业初期一直走到现在, 公司业务也从0发展到注册用户5000W+、月流水4000万,年流水5个亿。 研发团队从我一个人的单打独斗扩张到现在几个团队。一路走来,从高级研发到架构师,从架构师到项目总监的转型,临时接手大数据组种种的经历。接下来以个人的经验来总结下技术研发团队的管理心得。

    研发管理心得整理

     

    经历几个阶段:

    第一阶段: 对于我们这样一个创业公司来说,刚开始人不多,而且要求产品赶快上线进行第一轮验证,因此以产品灵活、响应快、研发与产品配合度高的情况就体现出来了。但这种模式是以产品快速响应用户需求为导向,对研发质量的不重视也为后来埋下了巨大的隐患。无论是代码规范性、性能的要求都缺乏足够的重视,导致后来很多代码无人能接手,很多技术瓶颈完全无法解决,最终没办法只能重构。

    第二阶段: 是纯粹的直线职能制的流程化开发模式,按产品出需求、研发实现、测试验收的流程化进行的。这种模式的好处是各司其职,每个部门把自己的事做好就行,而且各部门在质量上都有提高,无论是产品的需求完整度,研发的代码和架构质量以及测试对细节的把控都有很大的提高。但也不是没有问题。这种模式对市场和用户的响应程度上就明显慢很多,而且没有人对整体项目的结果负责,产品也缺乏真正的核心功能和亮点。还有一方面是在团队协作上效率极低,相互推诿,相互攻击,不利于团结的情况时有发生,对公司整体团队氛围也影响很大。

    第三阶段: 项目制度的模式,由产品发起需求,进行需求评审确定功能有价值进行研发,评估研发成本后,从各个部门调配研发、设计和测试人员资源。整个项目成员属于一个团队,每个人对自己负责的工作负责。产品做为对整体项目的结果负责,会把好最后的验收关。团队协作上的效率得到提升,大家目标一致,为了最终的项目交付积极努力工作。

    做为研发管理者的总结了如下几点:

    • 技术架构(技术视野)。技术能力仍然是基础,但是要格局更宽阔、视角更全面,既要能关注到未来的技术发展方向和趋势,也对公司的技术储备和路线心中有数,能够进行技术的落地和创新。公司什么阶段该用什么样的技术,哪些新的技术需要引进来,在不同的阶段,引入什么样的技术力量,这些都是技术管理者的职责。
    • 建立公司主营业务中技术框架和实施模式
    • 建立技术体系标准
    • 流程制度(管理能力)。在技术岗上,你的成功就只是决定于你做得有多好;在管理岗上,你的成功决定于别人做得有多好。成为管理者,一定要有这个思维方式的转变,重点是让团队做好,而不是自己亲自动手。而想让团队具备高战斗力是需要很多「道」与「术」的,比如打造团队文化、团队激励是「道」,沟通技巧、考核方式是「术」,而这些如果不想在实践中通过各种挫折来走弯路,那就一定要多学习和了解一些行业大拿的成功经验。
    • 建立高效率的技术团队
    • 建立健全的项目管理体系
    • 建立员工能力发展体系
    • 知识体系
    • 知识库管理体系,技术培训和分享体系
    • 视野&执行(商业嗅觉)。其实这考验的是对于业务和公司战略的理解程度,作为技术管理者一定要明白,技术最终还是要通过业务来产出价值,想要制定技术战略,首先要了解企业战略,了解行业趋势,了解公司在行业中的位置和地位,然后再去考虑技术团队如何支持和配合公司的战略,在这个过程中,优秀的技术管理者要学会跨界,跳出技术人的思维,从产品、市场甚至CEO的视角去思考问题,从而培养自己的战略思考能力。
    • 具备技术前瞻性、战略落地能力

    题外话:

    当我还是个单纯直男癌程序员的时候,觉得做技术应该是最复杂的,时不时想要搞个客户端技术,网络、SQL、架构设计、Java,操作系统, 什么都要懂;Python,Js, shell要学的东西很多;还不断的有新的东西出来,今天 React Native,kotlin ,明天又大数据,后天人工智能,区块链等等。。学无止境呐。

    在看看那些高管和老板们,不参与具体的版本开发,不需要找bug,天天就是开开会,发发邮件,今天跟测试撕逼,明天和产品讨论版本计划,后天和项目经理讨论人力安排,半年来个总结汇报,多轻松啊。

    只有当我做了leader后,有些事我才真正开始明白

    1. 决策者永远比执行者累,要负的责任和要做的事的大小的影响都是完全不同的概念。
    2. 想要招聘个心仪的下属,不知道要花掉多大的力气还有运气才行。
    3. 管理方法是可以学的,但是责任,担当,格局这些内在是需要修炼的!
    4. 下属能力不够,有leader来带;自己能力不够,自己想办法去弥补。
    5. 公司失败了,永远是老板的责任,老板不会说公司失败了是因为招了一堆垃圾员工,因为招什么人的责任也是老板自己来背。这个原则向下同样适用于任何管理职位。
    6. 从来不会因为某个技术问题发愁,让人累的都是人的问题
    7. 很多时候明明已经对全部人交代了,但很多人还是要单独确认,同样的话总是要翻来覆去的说。推出一个新的流程,自己要先试试,然后写清操作规程,接着是普及和推广。然后运行的时候各种低级错误依旧层出不穷。
    展开全文
  • 浅谈软件研发管理体系建设

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

    展开全文
  • 在此,总结下本人在数年研发管理过程中的一些经验,供参考,先列一些关键点,后面会不断完善。 目标 保证高效率、高质量地完成项目的研发和上线工作,并保证软件在线上运行过程中的高性能和安全性。 保证项目进度...

    目录

    前言

    目标

    自我管理

    智,能谋略通权变,任智则贼。

    信,能明赏罚,号令一也,固守信则愚。

    仁,能附众得人心,遍施仁则懦。

    勇,能果断,恃勇则暴。

    严,能立威,过严则残。

    大局观

    自省能力

    谨言

    向上管理

    主要目的

    具体技巧

    希望管理

    leader管理

    人员管理

    选择人

    了解人

    要求人

    激励人

    培养人

    评估人

    淘汰人

    向下沟通

    项目管理

    迭代需求把关

    进度管理

    项目资源协调

    团队管理

    自管理能力(自驱)

    建立很好的汇报机制,包括进度、风险、问题

    建立很好的向下传达、周知机制

    团队优化

    跟进线上问题、及时通报周知处理结果

    绩效管理

    文档沉淀与积累

    团队对外技术影响力提升

    决策链梳理

    会议质量&效率  

    技术管理


    前言

    在此,总结下本人在数年研发管理过程中的一些经验,供参考,先列一些关键点,后面会不断完善。

    目标

    保证高效率、高质量地完成项目的研发和上线工作,并保证软件在线上运行过程中的高性能和安全性。

    保证项目进度可控,风险可控。

    保证研发团队良好、合理、稳定的梯队。每个角色及其不同职级,都有良好的成长、晋升路径和机会。

    团队内有良好的技术氛围、创新氛围,并且保持激情,有很强的战斗力和进攻力。


    自我管理

    在此,先列举管理者必须具备的基本素质。

    孙武曰:将者,智、信、仁、勇、严。曹操曾批注:将宜五德皆备。有谓:偏施智则贼;固守信则愚;重仁则懦;持勇则暴;令过严则残。

    智,能谋略通权变,任智则贼。

    • 技术能力;
    • 逻辑思维能力;
    • 悟性、学习能力、举一反三的能力;
    • 能化繁为简,去伪存真;
    • 不非黑即白,做到一分为二,分析&权衡利弊;
    • 不盲从,有原则;
    • 不死板,知应变;

    信,能明赏罚,号令一也,固守信则愚。

    • 信用
      • 言出必行;
      • 兑现承诺;
      • 对下:不立法不杀人,先立法再杀人,若立法必杀人;
      • 对上:凡事有交代,件件有着落,事事有回音;
    • 威信
      • “打成一片”并“保持距离”,度很难把握,但每一件事情尽量考虑到这一点。
    • 自信

    仁,能附众得人心,遍施仁则懦。

    • 公正
    • 双赢
    • 量宽,量宽足以得人
    • 爱护下属,用心对待,必要的心理辅导,保护隐私
    • 为团队争取利益,甚至护犊
    • 谦恭进取
    • 乐于助人

    勇,能果断,恃勇则暴。

    如果你想拥有从来没有拥有过的东西  那就要去做从来未做过的事

    • 坚毅果敢,有担当
    • 敢于面对自己的不足,不回避
    • 敢于开始
    • 向弱者低头,向强者拔刀
    • 直面恐惧,依旧前行
    • 拒绝平庸
    • 有被别人讨厌的勇气

    勇能鼓舞士气

    是否有一颗强者之心,一颗超脱平庸的心,是平庸与出众者的分水岭,勇是强者的重要素质。人只是会思想的苇草,最高贵的就是会思想。有了一颗拒绝平庸的心,终有人会从你眼中的坚定,从你不俗的谈吐与紧握的双拳看出你的不凡。即使结果还是不尽如人意,即使会有“心比天高,命比纸薄”的诋毁,即使“零落成泥碾作尘”,仍会有“香如故”。

    严,能立威,过严则残。

    • 自律,律己足以服人
      • 自己不断学习 不断成长
      • 身先足以率人
      • 慎独,表里如一
      • 始终如一
    • 有合适的机制,法令严,严格的纪律
    • 赏罚严

    大局观

    自省能力

    谨言


    向上管理

    老板,以及老板的老板,也是自己管理的对象,不容忽视。

    据说,升职,就是让老板的老板看到自己的亮点,让老板的老板发现老板因为关键人物“你”超出预期。所以,站在老板的视角思考问题,非常重要。

    主要目的

    下情上达

    掌握一线信息

    锻炼思维,提升自己

    自我呈现

    具体技巧

    参见:研发团队管理--向上沟通


    希望管理

    • 宏伟&现实的组织愿景(内部、业界)
    • 良好的组织梯队,晋升机会
    • 树立身边的榜样,不吝鼓励
    • 善于创造机会,或争取机会
    • 传达公司&上层的好消息、好资讯,鼓舞士气

    leader管理

    • 建立信任,并推动其和下属建立信任;
    • 明确职责,并让其梳理自己的职责、及其下属的职责;(待完善)
    • 明确职责边界,且弱化边界(即清楚边界,不冒犯,但不自扫门前雪)
    • 提升其自主决策力,明确哪些该请示,哪些自己决策,放权放事给leader;
    • 每周定期汇报:项目、团队;

    人员管理

    做为管理者,需要扮演好以下四个角色:

    3~10人团队,有前面三种角色,基本可以较好应付,10人以上团队,机制和规范就显得尤其重要。

    并且加强自己的影响力:

    如果缺乏其中某种,可以想办法补充。

    选择人

    • 明确每个岗位的职责,这里的明确,是角色*环节的方式去细化明确;
    • 把关键的人放到关键的位置;
    • 合适的人放到合适的位置;
    • 招聘|简历|面试

    此处,除了技术和一般能力之外,还有一点非常重要。

    人分为三种类型:自燃型、点燃型、阻燃型。

    自燃型:无须借助外力,自己燃起来;工作上自我驱动力强、积极主动做事,是企业渴求的人;

    点燃型:像火柴一样一点就着,通过别人的点,就会燃起来;是企业重点培养的人;

    阻燃型:怎么点都不燃,陶瓷材质;一直不燃就会被淘汰的人;

    阻燃型的人,不管是在面试过程中,还是既存团队中,都推荐将其淘汰。除非你真需要一个默默无闻重复无脑工作的职位。

    了解人

    • 员工的生活与家庭背景
    • 员工的性格和诉求
    • 员工所处的阶段
    • 定期面谈(组长+抽选员工)

    要求人

    • 有效授权

            WHY:说明目的与背景;
            WHAT: 提出目标与要求;(时间限制)
            HOW:  明确步骤与方法
            ACTION:明确行动计划
            将责任与权力一并授予
            SUPPORT:表达信任与支持;
            CHECK:授权后的跟进

    激励人

    • 赞赏

            赞赏要具体,要有针对性
            赞赏要及时
            善始善终,结尾不要批评对方
            赞赏要当众(批评要私下)
            赞赏要真诚

    • 绩效|升职|加薪|年终|期权|股票

    培养人

    •     事和诉求的匹配
    •     对每个成员的成长负责
    •     员工的上升渠道
    •     团队技术培训和提升
    •     骨干培养

    评估人

    •     日常考勤请假
    •     绩效考核
    •     述职、定期总结
    •     异常成员跟踪

    淘汰人

    这一点比较难跨出去

    招聘时的看走眼,或者接手新团队的成员,都有可能出现无能、懒散、老白兔等。

    如果不及时淘汰,积累下来,难免会影响团队氛围、士气、公平,需果断将其淘汰。

    因为一些不可描述的因素,实在不能全部淘汰,尽量保证占比较低。

    向下沟通

    具体参见:研发团队管理--向下沟通


    项目管理

    建议实施看板敏捷,若1.0项目或重大重构项目,可以酌情选择小瀑布。

    项目管理最推荐的方式就是通过机制,帮助项目组建立起良好的自管理能力。

    敏捷过程参考:基于story的敏捷分享

    迭代需求把关

    • 下迭代需求范围
    • 下迭代需求质量
    • 下迭代需求是否按时保质提交

    进度管理

    项目资源协调

    • 沟通

    参考:   研发团队管理--向上沟通      研发团队管理--向下沟通

    • 外部资源协调(运维,DBA,兄弟团队)

          确定目标一致性

          避免认为对方一定懂自己的专业

          尊重对方的技术权威及主导权

          双赢,考虑对方的利益点

          说服关键人员或意见领袖

          具体参见:研发团队管理--跨部门沟通    

    • 内部资源协调(产品,测试,研发,前端)

       

    团队管理

    自管理能力(自驱)


    建立很好的汇报机制,包括进度、风险、问题

    上线内容预告

    上线结果通知

    线上问题汇报 :线上问题管理----记录、复盘、追责

    进度(delay)风险预警

    里程碑设置及汇报

    项目结项、成果呈现汇报

    新人日报、日常周报

    建立很好的向下传达、周知机制

    例会通报

    邮件周知,抄送规则、机制

     

    团队优化

    跟进线上问题、及时通报周知处理结果

    •     监控报警
    •     日常工单
    •     大工单
    •     紧急线上问题
    •     资损

    绩效管理

    •     团队目标制定
    •     团队成员目标拆解与制定
    •     组织绩效自评|考核|排名
    •     绩效面谈

    文档沉淀与积累

    团队wiki搭建,首页集成分区,类似hao123

    需求、管理机制、测试环境、工具、入门文档、新人入职例行事宜、线上问题、分享ppt等

    文档积累列入KPI考核


    团队对外技术影响力提升

    团队外、公司内影响力

    业界影响力


    决策链梳理

    (上线?回滚?升级再上线?时间?)

    会议质量&效率  

    参考:会议纪要模板


    技术管理

    新涉及技术选型

    团队技术栈

     

    展开全文
  • 项目管理,项目经理必修课,IT行业管理方法
  • 研发管理工具推荐

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

    软件开发的项目经理一枚!大家都知道,一个好的敏捷工具对开发项目可以起到推波助澜、事半功倍的做用!

    我们做敏捷开发,如何敏捷?当然敏捷工具的选用也是非常关键的因素,对我们也起着关键的作用!

    我来介绍一下我所找到的,好用的敏捷工具:


    国内的「Leangoo(中文名:领歌)」

    Leangoo是一款基于看板的项目协作工具,Leangoo是由国内最权威的Scrum中文网精心打造,融入了先进的敏捷管理思想。

    我们可以使用Leangoo可视化地进行项目需求、任务、问题和文档的管理和协作,随时随地跟踪团队工作进展!

    它核心是看板,通过看板共享和实时同步团队工作以实现高效协同, 团队工作体现为卡片,内容可以是需求、任务、问题等。Leangoo看板上的主要元素包括列表和泳道,列表管理工作的不同阶段或状态,泳道实现任务的分组对应,从两个纬度让团队的工作高度可视化、一目了然。

    Leangoo提供永久免费的在线版本,企业、个人或其他组织在线注册之后即可免费使用。Leangoo的数据传输采用了最新的https/ssl数据加密技术,用户数据存储在和支付宝同级别的阿里云服务器上,并且经过了加密存储,以保证用户数据安全。Leangoo也提供商业化的私有部署版,私有部署版本可以部署在企业私有云或者企业内网。

    非常的简洁,轻量,上手也很快!




    产品Backlog的管理以及Sprint Backlog和Bug管理

    下图为产品Backlog管理示例图:


    Sprint Backlog示例图:


    Bug管理示例图:



    我们主要用leangoo来跟踪:

    一,定制开发内容并跟踪开发进度

    二、对人员的工作分配及时间安排一目了然

    三、缺陷管理

    四、测试用例的管理

    大致就这四点,它完全可以满足我们的需求 ,希望对更多新加入的开发者有所帮助!


    展开全文
  • 20年研发管理经验谈(六)

    千次阅读 2019-06-10 15:12:34
    本文继20年研发管理经验谈(五) 如何进行产品研发业务外包?  进行产品研发业务外包的方式没有绝对的标准。行业分析师指出,理解其中的差异通常与一家公司管理层的成熟度有关,而不是与公司本身规模或者存在的历史...
  • 研发管理(2)---七个工作法则

    千次阅读 2018-03-29 11:02:26
    管理混乱;缺少关键技术;研究开发落后;资金短缺;经营不善;产品积压;竞争力差等。机会,是组织机构的外部因素,具体包括:新产品;新市场;新需求;外国市场壁垒解除;竞争对手失误等。威胁,也...
  • 研发管理流程(一)

    千次阅读 2019-08-19 15:11:53
    目前的研发管理流程,分为4部分: step1:是否跟进项目 step2:是否参加项目招投标 step3:是否签订合同 step4:确定项目验收及回款 Step1 描述:是否跟进项目,组建项目团队,一般是销售+方案+项目经理。 ...
  • 最近一段时间,我一直在反复思考一个问题:我们的软件研发管理体系应该是怎样的?在不断思考的过程中,结合对公司近几年在软件研发方面的主要做法,逐步有一些粗浅的认识,在此将这些认识记录成文字,并期待能够与更...
  • 软件研发管理之版本管理

    千次阅读 2014-01-21 19:11:57
    版本管理是软件研发管理中比较容易忽视的一环,这当然是比较好理解的,因为版本管理毕竟和具体业务关系不大。其实,版本管理是很多更高级管理制度的基础,如果版本管理做得糟糕,类似代码审查一类的工作就很难高效...
  • 分享一个公司规模近200,研发占一半的创业公司 Worktile 在研发管理方面的玩法,仅供百人左右研发团队参考~ 什么是研发团队,简单的说,就是由你熟悉的那帮穿格子衬衫程序员为核心组成的团队,就是研发团队。本来,...
  • 研发管理总结

    千次阅读 2016-04-20 17:14:55
    我的研发管理之路已有两年,在此总结一下经验得失   1 团队文化 我觉得团队建设一般由几个过程:茫然混乱,强制规则,自觉习惯,主动创造。 茫然混乱阶段,靠工程师自我素质,道德束缚,靠个人英雄完成任务,走...
  • 老曹眼中的研发管理二三事

    千次阅读 2017-01-18 20:53:43
    研发管理既需要道的指引,又需要实战的方法,以及那些看似微不足道的雕虫小技。作为一名基层管理者,既需要培养团队的ABC,又需要管理你的老板,保持团队的新陈代谢,因为一切都是人的竞争。 总之,研发管理是面向...
  • 研发管理学常用定律与思考

    千次阅读 2014-10-04 16:17:33
    管理学上有很多您听说过或没有听说过的定律,这些定律虽然看上去很简单易懂,但...本文从研发管理学的角度出发,谈谈对一些定律的理解和思考,包括帕金森定律、康威定律、布鲁克斯定律、手表定律、木桶定律和墨菲定律。
  • 如何管理好一个研发管理团队

    万次阅读 2017-02-10 10:53:01
    如何管理好一个研发管理团队  很多管理人员都存在一个错误的认识,认为团队建设中,平常只要抓技术建设就行了,特别是研发部门团队,比如抓团队用什么架构,框架,具体的技术,抓培训,抓绩效就足够了,很多时候,我们可以...
  • 研发管理 - 流程篇

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

    万次阅读 2019-01-16 14:39:14
    研发管理核心五点谁应该看人可以少 但流程不能少任务要有负责人,执行要有计划明确绩效和惩罚措施,及时对研发进行激励建立研发人员的成长引导、能力培养和人才选拔机制。建立良好的团队文化 谁应该看 1.非研发...
  • 我们的管理:定制研发管理

    万次阅读 2013-11-18 15:11:46
    我们的管理:定制研发管理一、组织结构我们先按照客户规模分类,行业500强之外属于非战略客户定制研发中心,行业500强属于战略客户定制研发中心。在战略客户定制研发中心又细分为核心战略客户定制研发团队和非核心...
  • 从事研发管理的心得

    千次阅读 2019-07-31 16:29:11
    从事管理工作的心得 前言 职业生涯中,从技术走向管理似乎已成为普遍并达成共识的职业规划套路,但要完成这样的转变过程是需要一定的思考的,它肯定不会也不应该如同开关切换一样简单,因为在技术与管理之间肯定...
  • 本人2000年就在华为印度所参与CMM的实施,后续帮助10多家企业实施CMMI体系,总结下来发现,一定要以项目为主线实施CMMI,通过项目主线将CMMI的各个过程域穿插在项目具体活动中,这样实施的直接好处是项目管理团队拿...

空空如也

1 2 3 4 5 ... 20
收藏数 248,673
精华内容 99,469
关键字:

研发管理