研发管理_研发管理工具 - CSDN
  • 研发管理心得整理

    千次阅读 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. 很多时候明明已经对全部人交代了,但很多人还是要单独确认,同样的话总是要翻来覆去的说。推出一个新的流程,自己要先试试,然后写清操作规程,接着是普及和推广。然后运行的时候各种低级错误依旧层出不穷。
    展开全文
  • 分享一个公司规模近200,研发占一半的创业公司 Worktile 在研发管理方面的玩法,仅供百人左右研发团队参考~ 什么是研发团队,简单的说,就是由你熟悉的那帮穿格子衬衫程序员为核心组成的团队,就是研发团队。本来,...

    什么是研发团队?简单的说,你熟悉的那帮穿格子衬衫,以程序员为核心组成的团队,就是研发团队。

    本来,你以为格子男们是很乖很闷骚的那种,管理和协作起来比销售和业务简单很多,而实际情况是,格子男们并不那么容易管理,面向代码世界的复杂度,可能远比面向财物世界的复杂度还要高。

    作为致力于团队协作的公司,我们研究了很多国内和海外牛逼公司的研发模式和研发管理,例如OKR在谷歌、Facebook的应用,Uber的高效会议制度,阿里的绩效体系,腾讯的产品流程。

    除了在自身团队做了N次不同的试验和反思,我们也想将很多不错的经验分享给用户。要谈清楚方法,就先了解清楚问题,研发管理之所以令人头疼,核心的问题无外乎以下一些方面。

    研发管理的典型问题

    图片 0.png

    1. 难以KPI化和考核

    任正非有句名言:钱分好了,管理的大部分问题就解决了。我对此深表同意,可问题是,怎么能分好钱确实非常考验能力、经验和智力的。研发之难,恰恰难在无法KPI化工作本身,所有那些试图KPI化工程师和码农的做法,最终结果都啼笑皆非、面目可憎、吃力不讨好。

    在我过去经历,还有客户实际的研发管理里,试图KPI化研发工作一直是不同团队努力的尝试,包括和不限于以下方式:

    • 解决Bug数
    • SLA
    • 功能完成度
    • 加班,007就比996牛逼,996就比955更值得奖励
    • 营收捆绑
    • NPS

    这些看起来可以数字化的指标,除了证明研发管理者通过偷懒的方式做绩效考核外,可以说毫无价值,也无法给公司和组织带来正向的激励。

    2. 离代码很近,离用户很远

    另外一个现实且无奈的问题是,工程师和产品经理好像是在象牙塔里做产品和研发,和用户往往离得太远太远。这种问题带来的伤害可能远比其他事情来得更加彻底,但本质上这是研发规则上没有解决好的问题,导致工程师本身并没有任何的目标和动力去贴近用户和客户场景。

    我们常常说要做用户喜欢的产品,但那些反人类智商的产品,往往是产品经理和工程师合谋的结果。如果说研发管理的目标是提高效能,那么首先同步研发团队朝着统一的目标,就是效能管理最重要的第一步。

    因此,以什么样的制度去驱动研发抬起头来看客户场景,是一切研发管理的核心工作之一。

    3. 跨部门战争频发

    因为低头干活,所以往往研发团队的目标和业务团队的目标并不是一致的,研发体系和业务体系的跨部门战争,简直罄竹难书:

    • 业务认为,怎么这么多bug,一个小问题需要花这么久的时间才能修复
    • 而研发认为业务的智商不够用,这么好的产品就是无法准确传达给客户
    • 业务面对客户点头哈腰;而研发觉得客户是业务的客户,不是研发的客户
    • 业务对需求排期是12345;而研发对需求排期往往是54321
    • 业务给客户承诺就像谈恋爱,把星星摘下来也敢接着;
    • 研发认为你承诺的,你去写代码实现吧
    • 业务认为研发高工资吹着冷气,自己天天跑在外面晒太阳;研发认为,业务提成那么高,这产品是我做的,我咋没提成呢

    这种剪不断、理还乱的关系,是很多公司的普遍现象。因为跨部门的不理解,必然带来团队之间的内耗,信息的折扣和效率低下自然产生。而更重要的影响是跨部门战争造成对客户服务与理解的偏差与推诿,没有任何公司或者团队能在一个不流畅的环境下成就对客户的100%满意度。

    那么如何解决以上问题呢?

    从研发管理全景图说起

    下面的研发全景图,是我们团队过去几年逐步形成的研发管理经验,其中主要包括以下内容:

    • 研发管理的的核心是构建一个开放、自学习、自驱动的组织文化和仪式感,这是打造高效研发团队最内核的基础。
    • 左边是工具和方法,主要包括:以OKR驱动的目标管理,基于Scrum的敏捷,和逐步完善的DevOps。
    • 右边是制度和规则,核心包含:研发团队的绩效和考核、跨部门合作、其他仪式感驱动的各种规则,尤其是构建自学习的环境与分享机制。

    图片 1.png

    打造开放与竞合的组织架构和文化

    一个组织要焕发活力、自驱动、使命必达的信念,开放而透明的文化是绩效管理的核武器。总体来说,不管你的方法和制度多么丰富和完善,无论如何也不可能驱动僵化、死板、没有活力的团队产生极其高效的价值。

    所以,我们在谈研发效能的时候,注意力总集中在别人家的团队是符合管理的,而忽略了团队激活的核心首先是塑造超强自由度、透明度和使命感的团队文化。

    从效率这个角度去看,没有透明度的提效都是打折扣的,在一个组织里效率低下的首要原因并不是执行力,而是透明度。需要层层审批和报备的组织,设定层层关卡和信息围墙的团队,效率一定是非常低下的,单点的执行力提升并不改变整个团队的低效基因。

    所以,打造开放与竞合的组织架构和文化,至关重要。

    1. 特种部队

    如何设计研发团队的组织架构,是个大大的思考题。我们团队经历过好几次不同的组织形态,也经常性的将研发团队进行组织调整,简单说,一个研发团队的角色主要是以下几类:

    • 产品经理
    • 设计师
    • 服务端工程师
    • 前端工程师
    • 测试
    • 其他

    以什么样的组织方式调配以上资源,是个非常考验团队管理的事情,例如很多公司会将设计团队作为完全独立的部门,其他团队和项目按需调配设计资源,设计团队就像公司的乙方角色,通过资源调配来匹配执行。

    而另一种形态则是广泛存在于Facebook等互联网公司的方式,设计、产品经理、开发、测试组成短小精悍的特种部队,在研发团队中以小组形态组合,就像一个研发业务的接口一样,有清晰的输入和清晰的输出,有清晰的目标和清晰的边界。

    显然,打起仗来,特种部队方式的小组,从执行到目标都是超级强悍的,也同时能方便研发组织绩效考核的落地与激励。
    image.png

    特种部队的另一个好处是,每个小组的职能和目标是固定的,在产品研发大架构下执行一个精确的目标和单元。但小组成员可以转岗或者调配到其他小组,从而避免了研发人员的枯燥和无挑战的问题。

    2. 仪式感

    仪式感是团队管理的调味品,也是必需品,就像你吃饭离不开盐一样。研发团队管理者,例如CTO角色的人,需要有意识的在团队中设计有价值的仪式感,来增加团队磨合、默契与调味。好的仪式感,就像宗教仪式一样,能不断加强团队目标的执行、文化的塑造以及阶段的激励。

    例如,我们自己团队就有很大仪式性的东西在执行:

    • OKR的阶段同步
    • 把重大版本发布变成研发团队的阶段激励
    • 管理层的固定One One访谈
    • 研发人员的每月访谈,同步到公司月报
    • 花心思的团建
    • 每月的产品考核
    • 师徒制
    • 走出去,参加各种外部的技术大会
    • 。。。

    还有很多其他的仪式和规则,并且以上几乎每个规则都值得拿出来说道说道。

    3. 用户体验委员会

    在Worktile团队,我们建立了组织架构之外的一些虚拟组织,虚拟组织的设计可以很好解决跨部门沟通与信息同步的问题,以用户体验委员会为例,将公司里研发、设计、产品、销售、客户成功的同事组成一个虚拟委员会。

    委员会主席本质上就是这个组织的秘书,通过定期的会议或者讨论,将解决用户体验上的问题作为核心目标来解决。委员会的茶话会,每次都能高效推进很多方面的事情:

    • 就用户体验的重大问题充分讨论,产品和研发从不同视角收听意见,销售和客户成功更多代表了来自一线用户的建议。
    • 促进跨部门的彼此理解,很多时候跨部门的战争,来自于互相的不理解和看不起。例如,我们在某次茶会中,就一个很久以来的核心需求做了讨论,销售端原本以为是一个简单的需求,结果讨论下来发现,这个简单需求其实在客户方也有非常不同的理解,完全推翻了产品已经草创的设计方案。反过来,销售同事也完全理解了为何产品方案是如此之难的原因。
    • 指定行动方案,快速驱动产品研发落实改进方案。用户体验委员会不是只讨论,更重要的是驱动行动方案,快速解决用户关心的体验问题。

    4. 技术委员会

    同样在研发团队,我们通过技术委员会来实现跨研发团队的技术沟通、分享和技术选型。技术委员会保证了公司始终以科技驱动商业的基础不被稀释,汇聚团队中技术能力最强的圈子更加自驱动的投入技术贡献,主要的工作目标包括:

    • 公司级的技术方案
    • 前沿技术研发小组研发岗的职级评审,技术委员会承担对技术能力的职级评估
    • 驱动公司技术进步和学习,例如组织黑客马拉松、技术分享、对外技术输出
    • 向市场和销售输出技术内容研发下乡

    5. 研发下乡

    就是让研发走向客户,贴近客户需求,了解客户状况,然后回来完善产品以满足客户需求。Worktile本身是企业服务产品,客户需求在B端是及其复杂而多样的,憋在办公室是无法做出好产品的,所以需要从制度上驱动研发、产品和设计走向客户,而不是待在象牙塔。

    研发下乡给了每个研发人员固定的指标,需要下乡到客户现场,所以销售和客户成功有了正当的理由要求研发同事完成指标,从另一个方面也加强了研发和业务部门的配合与协作,因为双方有了共同KPI的时候,大家绑在一起去做好一件事的动力就变得很强。

    6. Polish Week

    Polish Week是来自硅谷的流行文化,让研发团队在一个紧张迭代之后,有足够的时间可以休息一下,然后集中火力解决来自客户的需求或者问题,这种制度设计是非常高效的方法,可以短时间集中兵力解决遗留问题。

    7. 技术分享和走出去

    5年下来,我们技术团队每周分享已经正常进行了几百次,研发团队中的每个人都或多或少完成过对于所在部门的技术分享。新人来到团队,可以从过去数百次分享留下来的知识收获非常多的遗留知识。

    image.png

    (在研发体系共享的技术分享池)

    另外一方面,Worktile 的核心客户本来就是研发团队和工程师,市场维度需要研发人员能够不断共享有价值的技术内容,而技术分享机制恰恰提供了驱动工程师内容创作的土壤。

    每次内部分享的内容,其实完全可以继续优化成外部可以传播的内容,通过市场手段实现二次传播,同时也能够将团队中有活力和分享精神的小伙伴,推到前台去技术大会或者公司组织的技术分享大会分享。

    基于OKR和Scrum的研发管理

    源于业务关系,我们在N个不同的客户场景做过测试,就是把团队老大的目标在公司群里做个调研,比较打脸的现实是,99%的情况下老大想的目标和执行层理解的目标不是一回事,而且大部分时候差别都非常大。因此,回到在研发团队或者公司层执行OKR,本质上要解决的核心问题是:上下同欲。

    俗话说,上下同欲者胜。如果目标这件事都没法达成一致,那么一切效能和效率的优化都是无稽之谈。因为你效率越高,但方向不对,可能偏离方向跑的更远,这不是很尴尬的事情么?

    因此,我们可以通过了解OKR来在团队形成一个基本的能力,这就是战略同步和战略沟通,从而实现目标统一这件事。(OKR的基本知识,推荐去Worktile OKR专题页了解)

    图片 6.png

    (OKR是战略同步和战略沟通工具,服务于团队的使命和愿景)

    1.写好O和KR是执行OKR最难的第一步

    在研发团队落地OKR,本身并不是一件特别容易的事情,Worktile 团队经历了将近3年的反复尝试才逐渐找到OKR执行的感觉,而所有难点中,在开始阶段是如何写好你的O(目标)和KR(关键结果)。

    image.png

    (一个典型的研发O和KR定义)

    所以,开始阶段需要不断在形式上保证OKR的执行,这个是非常必要且需要坚持的事情,然后不断打磨每个周期里的O和KR的定义。下面是一些OKR模板大全,看看优秀团队OKR是如何定义的:

    2. OKR + Scrum的方法论

    本文并不能将Scrum展开来讨论,因为这实在是一个大大大的话题,在我们团队实施Scrum有个大图景,其中包括了:敏捷开发、代码托管、持续集成、持续部署和持续发布。

    下面这张图是以最基础的敏捷开发为例,从如何开会、如何定义团队规模、如何角色划分、如何迭代、如何测试,有非常专业且详细的管理细节。

    图片 8.png

    不过,回到落地Scrum,同时又关注OKR的研发团队来说,Scrum + OKR是一个及其有价值的组合工具,我们自己的经验是以以下方式结合的:

    • 部门级OKR驱动 + 部门内敏捷驱动,OKR不到个人层级,但团队中的牛人可以OKR驱动

    • 迭代与OKR周期匹配,Sprint Meeting和OKR Review Meeting结合

    • OKR辅助优化产品Backlog的优先级

    • Scrum Master 参与 OKR Master 目标修正

    我们总体在公司层将OKR执行的单元控制在部门层级,并没有强制个人制定个人的O和KR,所以回到研发团队管理上,部门的大方向和大目标靠OKR保证。而部门内的迭代,Product Backlog和Sprint Backlog则以敏捷的周期和原则执行。

    大方向由OKR保证,并且影响优先级,小迭代和任务计划,基于敏捷的原则执行,简直是完美配搭。

    3. 会议制度

    我们推荐以Sprint Meeting和OKR Review Meeting为核心的复盘和计划会议。

    Worktile研发团队,通常会定期在每周五的上午有一个非常长的同步会议,核心内容是基于Scrum的一个Sprint迭代来复盘进度和异议解决,产品和研发在一起高效沟通当前版本的进度和问题,并快速协商解决方案,指定执行人。

    而另一方面,我们会在例会中共同复盘和更新研发团队的目标树,投影将打出两个页面,一个是迭代的故事板,一个是OKR的目标树。

    对研发团队而言,通过OKR例会和Scrum例会,很好的规范了每次会议的核心内容,效率自然非同反响。

    image.png

    (例行的Scrum会议,同时复盘迭代的进度和OKR目标达成)

    4. 每日站立

    每日15分钟的站立会议,是敏捷型研发团队的必修课。快速交流昨日进展和问题,快速商议解决,然后快速计划今天的工作安排,每天花很小的时间复盘,这才是小步迭代。

    当然,如果对着Worktile的迭代故事板去讨论,就免去了在墙上贴一大堆的标签,感觉很爽很到位。

    image.png

    (每天发生的短小精悍的站立会议)

    5. 落地OKR的各种坑

    执行OKR,一些坑是初次体验的团队常常犯的问题,总结下来主要是以下方面:

    • 和绩效考核挂钩

    • 一上来就全员执行

    • 变成目标分解工具

    • HR负责,而不是团队老大

    image.png

    OKR不是灵丹妙药,更像一个二把刀大夫,你信就能行,你不信就不行。OKR提供了基本的方法论、仪式、流程和规则,能够为团队构建基本的目标同步框架,实际落地需要公司决策层有坚持走下去的决心,尝试一次不行,要再调整然后接着来。我们自己团队从开始接触到今天,OKR的尝试上已经是第三次才逐渐找到感觉。

    谈谈研发绩效

    纵横江湖这么多年,知名的外企,头部的公司,小而美的海外企业,特别官僚的国内公司,包括我们一起共建和共创的客户,我经历和了解的公司至少上百家以上。

    但是讲真,在研发绩效管理上做的好的,凤毛麟角。本身而言,研发的绩效、目标、管理和奖惩,从来都是一件难的事情,不要试图以过于简单的方案来解决。

    我曾见识过一家500人研发团队的公司,为了指标化研发的KPI,将研发工作细分成几千个指标,然后通过几千个指标的动态结果来指导绩效和方向。这种尝试骨骼清奇,但我从过往经验里表达了深深的怀疑。我们所认识的那些牛逼闪闪的公司,没有一家是这样做的,更多的方式还是停留在人类智力可以理解和共识的方式上:

    • 360度

    • 职级

    • Peer Review

    • 项目制奖惩

    • 分级考核

    下面,将我们自己在运行的绩效和奖惩方法,做一些浅尝辄止的分享。

    1. 360度

    我们在研发绩效制度上,主要实行360考核,每半年一个周期,年中考核占30%的权重,年底考核占70%权重。包括了自评、同事、直属上级、HR和老板,考核的核心是以个人对公司影响力作为最重要的标准。

    因此考核前的述职过程对每个人至关重要,因为你需要说清楚我在这个周期里,做了哪些有价值的事情,带来了哪些有意义的结果,存在哪些问题,以后如何避免和解决。

    我们的部门考核,直接由部门总监的360度结果来代替,所以这意味着部门总监的个人考核结果,就是部门整体的结果,会影响部门整体的系数。

    有考核就有奖惩。360考核是决定一个个体和团队一年的奖励或者惩罚,做得好的和做的不好,都由这个结果来评定。

    奖金由结果决定,我们通常会定义公司、部门和个人三级系数,不同的系数代表了不同的含义,然后加权出来的结果代表了你能拿到多少奖励:

    • 公司系数:基本由公司的总体营收和整体目标达成情况有关,决定了公司总奖金池和调薪池的多少。

    • 部门系数:也就是部门总监的个人系数,决定了部门在公司多个部门的排序,以及该部门总的奖励系数。

    • 个人系数:就是个人的考核结果,决定了个人在所在部门的排序,以及个人总的奖励系数。

    这三个因素加权到一起,基本就为每个人和每个部门定义了一年的收成。

    image.png

    360度或许不是最佳的绩效方案,但这是当下普遍执行的规则里最有效的办法和方式。当然,执行360度考核有很多执行的细节,这些是施行过程中很重要的平衡,每个考核结束都要复盘做哪些调整。

    总体而言,奖励和惩罚也没有永远的绝对公平,只有相对的。但是在规则定义上,如何实现按照影响力评价,就能最大程度的保证能者多劳这一基本常识。

    2. 职级驱动

    职级体系是研发型团队最有价值的工具,职级体系是一个职业序列,可以方便的定义一个人对公司影响力的评级和序列,而不是职位序列。所以,对于资深的工程师或者架构师来说,他的职级可以比自己的部门领导高,但职位可以略低。

    职级体系同时定义了薪资范围和期权范围,从而让职级成为一个程序员向上通道的必经之路,原因是职级可能定义他在公司维度下薪资的上限,必须职级提升才能突破某个薪资瓶颈。

    职级的价值在于:它是清晰定义的透明规则,包括薪资范围、期权、附加福利、评级标准。这样的透明标准能够最大程度上调动每个人向上成长的积极性。例如,职级对应的附加福利中,我们会包括你每年可以参加外部培训的额度,这对学习型工程师都是非常好的小福利。

    image.png

    (职级体系)

    职级体系不是一个简单的工具,需要考虑很多细节和适配不同公司的规则,例如如何评级职级,技术委员会对研发岗位每个人的技术能力定义,职级评价的周期,每个职级的要求。

    总体而言,职级是个有效工具,能够好的驱动那些有向上野心的团队成员,以最透明和公平的方式在向上的通道前进。

    多说一句,我们在研发团队是以OKR+ 360度 + 职级体系来建立相对完善的管理体系,而在业务团队,包括销售、客户成功、市场团队,则更加突出KPI的导向性,所以KPI也不是毒药,KPI要善用到合适的地方,以及以合适的方式。

    3. 分级考核

    分级考核是我们在逐步尝试的方案,还没有完全落地,只是一个探讨阶段的东西。实行分级考核的原因是,任何组织和团队,都常识性的遵循2-7-1原则,一定有20%的牛人来长远的带来公司前进,也大概率上有70%的执行层需要靠规则和优秀的角色来影响前进。

    image.png

    所以考核的方式上不能实行统一的规则,否则要么对牛人定了太低的标准,要么对一般能力的人定了太高的标准。

    另一方面,分级考核也能够从规则上驱动70%的小伙伴,有努力向20%提高的动力和标准。当然,我们还在考察和尝试,这里仅仅抛砖引玉。

    4. 总奖励和总营收挂钩

    这一条本来是一个常识性的结论,只是这个时代太多融资了的公司并没有很好的理解奖励的本质,很多时候拿融资的钱奖励,是不道德的。所以,让总营收和总奖励挂钩,是最合理,也最理直气壮的方式。

    这一条在我们的逻辑里,就是由总营收来影响绩效考核的公司级系数,这个系数由核心管理层来定义即可。

    工具化

    工欲善其事必先利其器,这是真理。工具的核心价值,不是仅仅通过工具提高效率,更重要的是,利用工具能够为团队修好水渠

    研发团队本身的管理、绩效、工作流程有很多可以水渠化的事情,所以用一个好的工具能够最有效的帮助研发团队修好水渠,然后达成团队的目标。

    当然,主要推荐的是我们自己在用,并且很有效的自家工具:Worktile。核心原因是对研发团队而言,Worktile能够帮助解决的主要是以下两个方面:

    • 基于敏捷的全流程项目管理

    • 基于OKR的目标工具

    1. 通过Worktile项目管理(Scrum和Kanban)驱动敏捷研发全流程

    目前已经有几十万团队通过Worktile协同工作,其中研发团队占比是最高的,源于我们提供了对敏捷全流程的完整工具链支持,以及更好的产品体验:

    • 支持Scrum和Kanban两种敏捷实践方式

    • 基于敏捷方法论的完整迭代、故事板、需求、任务和缺陷管理

    • 丰富的报表和数据统计,对研发决策管理一目了然

    • 打通研发和业务,更好的跨部门协作支持

    image.png

    落地敏捷,需要能够支撑全流程的简单工具,Worktile为你提供了所需的一切。

    2. 通过Worktile OKR工具落地OKR的执行

    Worktile是国内首家将OKR落地到工具化的产品,为团队执行OKR提供了更好,更方便,更数据化的支持,主要包括:

    • OKR的执行全流程管理,从启动、周期、打分和评审

    • 基于公司、部门和个人分级的O和KR管理

    • 一个基于目标体系的目标树

    • 基于目标执行的自动化运营分析,同统计报表告知团队OKR执行和更新的情况

    • 自动目标更新提醒

    image.png

    (在Worktile以更有效的方式定义OKR)

    OKR是个简单的方法论,工具本身并不复杂,但自动化方式显然好过Excel共享方式带给团队的价值。这些都是Worktile已经修好的水渠,你只需将水引入即可。

    总结

    好了,这是一篇汇聚研发团队,从管人到管事的一些点滴经验,背后投射的是一个百人规模研发团队在过去成长之路上不断迭代的经验和方法。

    每个团队都是独特而与众不同的,所以经验和方法也不一定适合所有,只是希望一些可能的思路,能带给你的团队一些转折和启发。

    程序员群体,也是独特而与众不同的一群可爱的家伙,他们有自命不凡的习惯,也有改天换地的雄心,他们不会循规蹈矩,更不会一直被996束缚手脚,驱动这群难搞的人不是一件容易的事,需要站在开发者的视角去理解他们的工作和乐趣,然后共创出能够执行、能够激励、能够数字化的方案,这是我们Worktile在试图努力的方向,也是我们自己献给自己工程师们的礼物。

    欢迎你贡献你们团队的经验,私信我,或者留言,咱们看看还有什么更好的办法,解放天下程序员。

    Worktile官网: https://worktile.com/

    本文作者:Worktile CEO Anytao
    文章首发于「Worktile官方博客」,转载请注明来源。

    展开全文
  • IT研发管理人员大多是从公司内部的技术人员提拔的,在快速发展的公司里,这样的机会更多。然而这种“半路出家”的转型也给我们带来了很多挑战,其中最关键部分在于思维方式的转变。   1、 从个人成就到团队...

      IT研发的管理人员大多是从公司内部的技术人员提拔的,在快速发展的公司里,这样的机会更多。然而这种“半路出家”的转型也给我们带来了很多挑战,其中最关键部分在于思维方式的转变。

     

    1、 从个人成就到团队成就。无论是做管理或是做技术,成就导向是一个优秀员工的基本素质。只有有很强的成就导向意识才能把事情做得超预期,才能追求卓越。刚刚上任的管理人员的思维方式往往还处于个人成就导向阶段,他们希望向外界发出一个明确的信号,团队之所以取得这样的成绩或是解决某个难题,是因为我的组织、领导。然而这种信号被团队成员多次接到后,会产生功劳都被头头拿走的感觉,从而导致团队的向心力下降。这时候的好的做法是:要保护团队成员的成就导向,并且进行鼓励,从而刺激大家的积极性。例如:和某个团队成员共同解决了某个难题后,要弱化自己,而重点表扬这个团队成员对这个问题的贡献,这样这个团队成员下次再遇到某个难题时,才能保持一样或更高的激情。只有将自己的成就感定位在团队成就上,才能站得更高,避免和团队成员产生直接竞争,从而有效的领导自己的团队。

     

    2、 上下同欲的氛围。兵法有云“上下同欲者胜”,一个团队能够健康运作的基础就是有“上下同欲”的氛围。要想达成这种氛围,必须处理好两件事情:发言权,信息透明。

    发言权:每个人都希望发表自己对于一件事情的看法,尤其是关键事情,并获得聆听,这也是人们的基本权利。如果管理人员屏蔽这些,所表达的就是一种不尊重。当然不是所有的意见都要被采纳,这里需要合理的决策,但是要让大家有发言的机会。

    信息透明:这里的信息包括一切可以公开的信息,上级期望,项目进展等等。保持这些信息的透明度,能够提高团队成员对团队绩效的关注度,荣辱感。当大家都站在团队的高度上思考问题,能够节省很多内部的协调工作。

    转型到管理岗位后,就要求管理人员要花很多时间来考虑团队建设的问题,只有氛围没有问题,团队才能机会产出高的绩效。

     

    3、 合理计划,要事第一。面对刚刚转型的管理人员,往往可以从他们听到一些类似这样的抱怨“杂事太多,不停被打断”。这种情况发生的很大部分原因是因为计划不够周全或是缺乏例行沟通机制。例如,每日站立例会往往可以消除很多这样的杂事。同时因为管理人员面对的工作干系人变多,所以日常处理的事情也会变多,这点非常不同于技术人员的专注性。这时就需要我们要有非常合理的计划,保证要事第一被处理。这里需要注意的是,时间的急迫性往往会夸大事情的重要性,如果一个管理人员总是习惯将任务拖到最后的截止时间里处理,则将会打乱这种优先级,导致做事失去计划性。

     

    4、 培养人才,用人所长。杰克·韦尔奇说过“在你成为领导之前,成功只同自己的成长有关。当你成为领导之后,成功都同别人的成长有关。”作为管理人员要把培养下属作为一件重要的事情对待,只有团队里的人才层出不穷,团队才有能力去不断挑战比现在更高的目标。用人所长则指在工作的安排过程中需要多关注下属的长处,不能过度放大他们缺点,正所谓“用人所长,天下无不用之人;用人所短,天下无可用之人”。人事任命则需谨慎考虑,用对一个人,省心很多事;用错一个人,则要操很多心。将合适的人放到合适的位置,是管理人员必须面对一个难题。

    展开全文
  • 项目管理,项目经理必修课,IT行业管理方法
  • 给技术人的管理课20讲

    千人学习 2020-03-11 14:36:19
    1.针对工作2年以上的技术人员,快速提升个人领导力,拓宽职场道路,成功踏上从技术到管理的转型之路。 2.本课程立足于中华文化“经世致用”的思想精华,结合西方管理哲学,提出管理者修炼的“三板斧”:正心、...
  • 研发管理(2)---七个工作法则

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

    1、swot分析法

    掌握这七个工作法则,你的工作效率将事半功倍

    优势,是组织机构的内部因素,具体包括:有利的竞争态势;充足的财政来源;良好的企业形象;技术力量;规模经济;产品质量;市场份额;成本优势;广告攻势等。


    劣势,也是组织机构的内部因素,具体包括:设备老化;管理混乱;缺少关键技术;研究开发落后;资金短缺;经营不善;产品积压;竞争力差等。

    机会,是组织机构的外部因素,具体包括:新产品;新市场;新需求;外国市场壁垒解除;竞争对手失误等。

    威胁,也是组织机构的外部因素,具体包括:新的竞争对手;替代产品增多;市场紧缩;行业政策变化;经济衰退;客户偏好改变;突发事件等。

    SWOT方法的优点在于考虑问题全面,是一种系统思维,而且可以把对问题的“诊断”和“开处方”紧密结合在一起,条理清楚,便于检验

    在完成环境因素分析和SWOT矩阵的构造后,便可以制定出相应的行动计划。制定计划的基本思路是:发挥优势因素,克服弱点因素,利用机会因素,化解威胁因素;考虑过去,立足当前,着眼未来。运用系统分析的综合分析方法,将排列与考虑的各种环境因素相互匹配起来加以组合,得出一系列公司未来发展的可选择对策。


    用内部和外部交叉的矩阵,来找到应对的策略:



    2、pdca循环规则

    掌握这七个工作法则,你的工作效率将事半功倍

    pdca循环规则

    如上图所示:PDCA原则只有四点,分别是:计划,执行,检查,处理(plan、do、check、action)。

    它的基本原则是,凡事都需得规划,然后执行,执行完了以后需要思考和改进。事实上,我上文中说的我那位打dota的同学,就在不知不觉中就使用了PDCA的原则打游戏,我就按照他玩游戏的过程来梳理下:

    1、plan:做计划前,我们需要了解的是,我们最终的目标是什么?我同学的目标很简单,赢,不断的去提高竞技水平。

    2、Do:其次就是,我们如何去拆解和去执行我们的目标?他一般来说,他大概6分钟出xx装备,十分钟出xxx装备,二十分钟出xxx装备(拆分计划),把计划进行拆分,目标就是可执行的了。

    3、Check:如何去检查我们目标的完成?根据自己的目标检查自己的视频,看自己是否达到了目标,然后客观的进行记录。

    4、Action: 如何去修正我们执行过程出现的问题?思考自己没有达到目标时候是因为哪些客观的原因导致的?怎样对自己的过程进行修改,才能更快的完成目标?比如说:在对战的时候,没有处理好操作,导致没有达到最初设定的目标,然后对自己对战的过程进行刻意练习,有了相对性训练以后,会更好的让自己达到目标。


    PDCA 改进:
    P(Planning)——计划职能包括三小部分:目标(goal)、实施计划(plan)、收支预算(budget)。
    D(design)——设计方案和布局。
    PDCA循环
    PDCA循环(2张)
    C(4C)——4C管理:Check(检查)、Communicate(沟通)、Clean (清理)、Control(控制)。
    A(2A)——Act(执行,对总结检查的结果进行处理)、Aim(按照目标要求行事,如改善、提高)。

    应用
    1、计划阶段。要通过市场调查、用户访问等,摸清用户对产品质量的要求,确定质量政策、质量目标和质量计划等。包括现状调查、分析、确定要因、制定计划。
    2、设计和执行阶段。实施上一阶段所规定的内容。根据质量标准进行产品设计、试制、试验及计划执行前的人员培训。
    3、检查阶段。主要是在计划执行过程之中或执行之后,检查执行情况,看是否符合计划的预期结果效果。
    4、处理阶段。主要是根据检查结果,采取相应的措施。巩固成绩,把成功的经验尽可能纳入标准,进行标准化,遗留问题则转入下一个PDCA循环去解决。

    八个步骤:

    步骤一:分析现状,找出题目;
    强调的是对现状的把握和发现题目的意识、能力,发现题目是解决题目的第一步,是分析题目的条件。
    步骤二:分析产生题目的原因;
    找准题目后分析产生题目的原因至关重要,运用头脑风暴法等多种集思广益的科学方法,把导致题目产生的所有原因统统找出来。
    步骤三:要因确认;区分主因和次因是最有效解决题目的关键。
    步骤四:拟定措施、制定计划;(5W1H),即:为什么制定该措施(Why)?达到什么目标(What)?在何处执行(Where)?由谁负责完成(Who)?什么时间完成(when)?如何完成(How)措施和计划是执行力的基础,尽可能使其具有可操性。
    步骤五:执行措施、执行计划;高效的执行力是组织完成目标的重要一环。
    步骤六:检查验证、评估效果;"下属只做你检查的工作,不做你希望的工作"
    步骤七:标准化,固定成绩;标准化是维持企业治理现状不下滑,积累、沉淀经验的最好方法,也是企业治理水平不断提升的基础。可以这样说,标准化是企业治理系统的动力,没有标准化,企业就不会进步,甚至下滑。
    步骤八:处理遗留题目。所有题目不可能在一个PDCA循环中全部解决,遗留的题目会自动转进下一个PDCA循环,如此,周而复始,螺旋上升。

    3、5w2h法

    掌握这七个工作法则,你的工作效率将事半功倍

    5w2h法

     

    5W2H分析法应用程序

    检查原产品的合理性

    步骤(1)做什么(What)?

    条件是什么?哪一部分工作要做?目的是什么?重点是什么?与什么有关系?功能是什么?规范是什么?工作对象是什么?

    步骤(2) 怎样(How)?

    怎样做省力?怎样做最快?怎样做效率最高?怎样改进?怎样得到?怎5W2H分析法样避免失败?怎样求发展?怎样增加销路?怎样达到效率?怎样才能使产品更加美观大方?怎样使产品用起来方便?

    步骤(3)为什么(why)?

    为什么采用这个技术参数?为什么不能有响声?为什么停用?为什么变成红色:为什么要做成这个形状?为什么采用机器代替人力?为什么产品的制造要经过这么多环节?为什么非做不可?

    步骤(4)何时(when)?

    何时要完成?何时安装?何时销售?何时是最佳营业时间?何时工作人员容易疲劳?何时产量最高?何时完成最为时宜?需要几天才算合理?

    步骤(5)何地(where)?

    何地最适宜某物生长?何处生产最经济?从何处买?还有什么地方可以作销售点?安装在什么地方最合适?何地有资源?5W2H分析法

    步骤(6) 谁(who)?

    谁来办最方便?谁会生产?谁可以办?谁是顾客?谁被忽略了?谁是决策人?谁会受益?

    步骤(7)多少(How much)?

    功能指标达到多少?销售多少?成本多少?输出功率多少?效率多高?尺寸多少?重量多少?

    5W2H分析法优势

    如果现行的做法或产品经过七个问题的审核已无懈可击,便可认为这一做法或产品可取。如果七个问题中有一个答复不能令人满意,则表示这方面有改进余地。如果哪方面的答复有独创的优点,则可以扩大产品这方面的效用。新产品已经克服原产品的缺点,扩大原产品独特优点的效用。

    1、可以准确界定、清晰表述问题,提高工作效率。

    2、有效掌控事件的本质,完全地抓住了事件的主骨架,把事件打回原形思考。

    3、简单、方便,易于理解、使用,富有启发意义。

    4、有助于思路的条理化,杜绝盲目性。有助于全面思考问题,从而避免在流程设计中遗漏项目。


    4、smart原则

    掌握这七个工作法则,你的工作效率将事半功倍

    smart原则

    img_s_04

    目标管理是使管理者的工作由被动变为主动的一个很好的管理手段,实施目标管理不仅是为了利于员工更加明确高效地工作,更是为了管理者将来对员工实施绩效考核提供了考核目标和考核标准,使考核更加科学化、规范化,更能保证考核的公正、公开与公平。无论是制定员工的绩效目标还是团队的工作目标,SMART原则都能使目标管理达到效果。

    下面结合SMART原则和周会形式,做详细分析。

    周会形式:

    1. 回顾上周计划;
    2. 制定这周计划;
    3. 问题提出、分析、总结。

    SMART原则与这三点,环环相扣。

    一、Specific——明确性

    所谓明确就是要用具体的语言清楚地说明要达成的行为标准。明确的目标几乎是所有成功团队的一致特点。很多团队不成功的重要原因之一就因为目标定的模棱两可,或没有将目标有效的传达给相关成员。

    举个例子:

    我们周会计划中有一个目标是“学习Java”。这种对目标的描述就很不明确,因为学习Java有很多种具体做法,如看书、看视频、做APP等,具体学习到什么程度也没有明确。

    有这么多学习Java的做法,我们所说的“学习Java”到底指哪一块呢?不明确就没办法衡量、评判。所以我们最后修改为“学习《Java从入门到精通》第三章到第九章”。

    二、Measurable——衡量性

    衡量性就是指目标应该是明确的,而不是模糊的。应该有一组明确的数据,作为衡量是否达成目标的依据。如果制定的目标没有办法衡量,就无法判断这个目标是否实现。

    举个栗子:

    我们周会计划中有一个目标是“练习Android APP布局”。其实这个目标是无法衡量的,因为不知道练习布局要达到什么效果。

    所以我们最后改为“按照产品原型,将【我】页面利用布局输出”。这时,就可以利用产品原型的【我】页面来衡量布局。

    三、Attainable——可实现性

    目标是要能够被执行人所接受的,如果上司利用一些行政手段,利用权利性的影响力一厢情愿地把自己所制定的目标强压给下属,下属典型的反映是一种心理和行为上的抗拒:我可以接受,但是否完成这个目标,有没有最终的把握,这个可不好说。一旦有一天这个目标真完成不了的时候,下属有一百个理由可以推卸责任:你看我早就说了,这个目标肯定完成不了,但你坚持要压给我。

    举例例子:

    我们周会计划中有一个目标是“搭建APP后台服务器”,这是给一名应届毕业生一周的目标。经过讨论,觉得对他来说,是一周不太可能完成的目标。

    所以,我们先从简单的开始,暂时将这个目标取消。

    目标设置要坚持员工参与、上下左右沟通,使拟定的工作目标在组织及个人之间达成一致。既要使工作内容饱满,也要具有可达性。可以制定出跳起来“摘桃”的目标,不能制定出跳起来“摘星星”的目标。

    四、Relevant——相关性

    目标的相关性是指实现此目标与其他目标的关联情况。如果实现了这个目标,但对其他的目标完全不相关,或者相关度很低,那这个目标即使被达到了,意义也不是很大。

    周计划中的目标,要始终和工作的定位保持一致。

    五、Time-bound——时限性

    目标特性的时限性就是指目标是有时间限制的。没有时间限制的目标没有办法考核,或带来考核的不公。上下级之间对目标轻重缓急的认识程度不同,上司着急,但下面不知道。到头来上司可以暴跳如雷,而下属觉得委屈。这种没有明确的时间限定的方式也会带来考核的不公正,伤害工作关系,伤害下属的工作热情。

    举例:

    我们周计划目标,都是以一周为时限。在开周会时,会回顾上周计划的每个目标是否都达成。如果没达成,问题出现在哪里。是目标不合理还是个人问题?以此来不断调整周计划中的目标,达到预期中的效果。

    从一个小小的周会,就可以看出SMART原则的目标管理,可谓是博大精深。


    5、时间管理-重要与紧急

    掌握这七个工作法则,你的工作效率将事半功倍

    重要与紧急

    6、任务分解法【wbs】

    掌握这七个工作法则,你的工作效率将事半功倍

    任务分解法【wbs】

    项目是一个整体,如果想要分清项目范围,就要将项目按照一定的原则对其进行任务分解,再将任务分解成一项项工作,工作分解成日常活动。这样一级级分解下去,就可以将无法量化的项目变成可以量化的日常活动,每个活动只能由一个人来完成,一个人所需要的完成时间做为活动的单位时间,这就是WBS(Work BreakDown Structure)工作分解结构法。

    WBS工作分解的好处:

    • 可以理清整个项目结构,了解项目全貌。
    • 通过分析每个节点可以统筹整个项目所需的人力、时间、成本。
    • 细分项目范围,为项目划清界线。
    • 当提出需求时,能清晰的分辨出所提出需求为新增需求,还是变更需求,便于项目管理者管理项目。
    • 通过功能分解,便于了解及控制项目进度,规避风险。
    • 通过工作分解便于制订出合理的工作计划。
    • 对一个大的工作包往往无法准确的进行评估,当对其进行细化分解后就能评估出相对准确的工作时间与人力资源。

    WBS工作分解事前及事后流程

    从上图可以看出,通过WBS工作分解,可以得出项目预算、进度计划、人力规划、时间估算等信息。

    WBS工作分解方式是逐级细分的,从树根一直到树叶的分解方法,直至分解到无法再分解的日常活动为止。分解步骤为:项目→任务→工作→日常活动,将一个大项目分解成一个个任务,将任务再分解成可以完成的工作,最后将工作分解成一次次的日常活动。以树状形式进行表达,从树根到树叶,将错综复杂的结构梳理成一级级、一节节的可以完成的工作节点。节点分解适度以一个人日(一个人一天的工作量)为宜,这样便于工作的分配与管理。

    树状工作分解图

    WBS工作分解结构的特点:

    • 分解是从树根开始,自上而下,逐级进行分解的。
    • 对于小项目分解层级一般为4至6级就足够了,层级越多越不易于阅读和管理。
    • 上一结点为下一节点的总和。
    • 节点最终分解到一个人日的工作量为宜。
    • 相同任务只能在WBS的一个树节点上出现,不能出现工作重复的节点内容。
    • 一个树梢节点只能由一个人来完成,一个任务节点也只能一个人负责,其它人配合。
    • 分解的任务节点树,应该与实际工作情况一致,这样才能对项目进行指导。

    WBS工作分解是项目管理中非常有效的方法,它同样适用于产品管理,可以把产品的调研、需求、设计等工作用同样的方法进行工作分解。


    7、二八原则

    掌握这七个工作法则,你的工作效率将事半功倍

    二八原则


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

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

    千次阅读 2019-03-26 11:48:43
    1.teambition https://www.teambition.com/
  • 研发管理工具推荐

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

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

    千次阅读 2018-06-21 08:09:01
    成为研发管理人员已有小几年时间,记录总结一下管理经验。 规范管理 研发管理中,开发规范管理是很重要的一环。 提到规范,网上自然有很多人分享,但普遍内容太复杂,至少对中小团队来说太复杂。太复杂的规范,...
  • 浅谈软件研发管理体系建设

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

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

    千次阅读 2019-09-24 08:10:45
    在前面的文章中,我曾和大家分享了软件研发管理体系建设的一些见解,其中涉及对软件研发管理体系的一些概念认知、什么样的软件研发管理体系适合我们的发展以及构建我们的软件研发管理体系应包含哪些内容。...
  • 软件研发管理之版本管理

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

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

    万次阅读 2019-06-14 15:11:44
    最近,大BOSS要求我给集团...我当时想的不是我能不能完成,而是我要怎么结合自己这近一年的研发管理经验,来把这个PPT完成的很有料! 既然让我做,就有让我做的理由,我很忙,也没时间去想,咱也不敢说,咱也不敢问...
  • 这是产品研发管理系列文章的第三篇:产品研发过程管理。 生产型企业通过企业研发生产过程,制造出产品,销售给客户,为其提供价值,从而赚取合理利润。软件企业作为生产型企业的一种,它区别于其他生产型企业的特点...
  • 我们的管理:定制研发管理

    万次阅读 2013-11-18 15:11:46
    我们的管理:定制研发管理一、组织结构我们先按照客户规模分类,行业500强之外属于非战略客户定制研发中心,行业500强属于战略客户定制研发中心。在战略客户定制研发中心又细分为核心战略客户定制研发团队和非核心...
  • 这篇博文应该是“学习——《产品研发管理》:周辉”,因为以现在的自己的能力,不敢去说消化、吸收前辈的经验。加油,跟随成功者的脚步…..(In the end,走出自己路) 后续该系列博文全部引摘自:周辉《产品研发...
1 2 3 4 5 ... 20
收藏数 238,927
精华内容 95,570
关键字:

研发管理