研发管理_研发管理工具 - 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. 很多时候明明已经对全部人交代了,但很多人还是要单独确认,同样的话总是要翻来覆去的说。推出一个新的流程,自己要先试试,然后写清操作规程,接着是普及和推广。然后运行的时候各种低级错误依旧层出不穷。
    展开全文
  • 研发管理流程(一)

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

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

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

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

    Step1

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

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

    内容:

    1)商机预览

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

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

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

    对应项目管理知识点:

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

    Step2

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

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

    内容:

    1)商机概览;

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

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

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

    对应项目管理知识点:

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

     

     

    展开全文
  • 分享一个公司规模近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行业管理方法
  • 20年研发管理经验谈(六)

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

    本文继 20年研发管理经验谈(五)

    如何进行产品研发业务外包?

      进行产品研发业务外包的方式没有绝对的标准。行业分析师指出,理解其中的差异通常与一家公司管理层的成熟度有关,而不是与公司本身规模或者存在的历史有关。最佳的方式是把产品线和研发分成两类:一类是构成该公司未来竞争力的核心要素,另一类是非核心要素,把非核心的部分外包。

      许多情况下,OEM公司倾向于将自己无力承担的工作外包出去,即使是系统中的关键部分。“许多厂商将软件开发外包给印度和其它地方的软件设计商,这并不是因为它们不是核心业务,而是因为这些厂商不具备这样的开发能力和团队。”市场咨询公司Pittiglio Rabin Todd & McGrath(PRTM)欧洲创新业务主管David Percival表示,“没有足够的人手导致了许多公司将软件开发这种核心的研发业务外包。”

      比较适宜的做法应是充分利用自己的内部资源来定义和制订产品规格,监督第三方合作伙伴开发,然后在内部进行测试和验证。Percival认为,这可能要求OEM厂商的开发队伍重新进行技能训练。

      另一个厂商经常犯的错误是将一些比较先进的开发工作外包。因为他们老产品的技术档案太糟糕和复杂,只有他们自己内部开发人员才能维护这些文档。“结果导致公司宝贵的研发资源和团队被禁锢起来,公司依赖外部伙伴来开发新的和令人激动的产品,而这些产品正是其竞争力的来源。”Percival说。

      比较适宜的做法是多花点时间进行正确地设计、调试和对当前设计建立文档,然后再外包,将内部资源集中用于新产品的研发上。Percival强调说:“在你将产品中独特元素外包的同时,你将利润也外包出去了,最后剩下的只有一个空壳。”

     

    产品开发流程的七要素

      引言:PACE在产品开发过程中的应用和扩展是一种实实在在的挑战,而那些成功运用PACE方法论和工具的企业也必将从这种挑战中得到显著的回报。

      产品开发流程可以分为七个相关要素,每一个要素都有其常见的不足之处。PACE提供了各种方法、技巧和手段,以克服每一个要素的不足之处。下文对这七个相关要素作了介绍,对一些常见的不足之处进行了总结,并针对每一个要素简单介绍了PACE的解决办法。  

      在以后的章节里,将进一步详述PACE的每一个要素。

    决策

      所有的公司都有一个新产品决策流程,尽管他们有可能并没有认识到这是一个有明确定义的流程。在决策流程薄弱的公司,因优柔寡断造成的延误很普遍。例如,如果某个实际流程是顺序性的,要求许多经理一一确认某产品设计概念的优劣,那么,起动就会延误。我们看到,许多良机的错失只是因为产品先驱们不知道如何运用这种不正规的决策流程。

      我们曾经帮助过的一家电脑公司有一个效率低下的决策流程,可以说它是我们所见过的许多流程当中的典型。在这家公司里,项目评审已沦为一系列面向不同听众的冗长的汇报。参加的人很多,提出的问题也很多,但这些汇报会并不是决策会议。评审并没有在开发流程的适当时机进行以促使决策,合适的信息也没有提供出来以推动决策。高层管理人员回避了评审,并且没有其他机制来推动适时决策。

      然而,并非所有明确定义的决策流程都是有效的。有些流程要么设计得很糟糕,要么实施不当。在这些情况下,一个正正规规的流程实际上对产品开发构成了管理障碍。花费大量时间,却收效甚微,这样的决策流程早已不能推进产品开发。

      在产品开发评审中,我们发现因决策流程不当会引发下列问题:

    ·由于高层管理人员不知道应该由谁来作出决策,或者需要什么样的一致意见,所以他无意识的延迟决策或修订决策。
    ·信息不够充分或细节不清楚导致决策质量低劣。
    ·没有及时解答疑问。
    ·未定义决策控制点,以至在适当的重要阶段又出现了评审工作。
    ·需要投入的资源过多,以至无法按期完成任何事情。
    ·授权审批和设定优先顺序的人没有明确批准给予产品开发项目的拨付资金。
    ·决策太迟——经常是在产品已经设计出来之后。
    ·没有用周期指导来证实项目进度。
    ·高层领导没有作出战略决策,却由开发人员在无奈中作出这种决策。

      在PACE流程中,新产品决策是通过阶段评审流程进行的,这种阶段评审需要在开发流程中具体定义的点上作出决策。一个产品开发项目必须在预定时间内达到明确定义的目标,才能获准进入下一阶段。

      产品审批委员会(Product Approval Committee, PAC)是指在一个部门或一个公司内负责主要新产品决策的高层领导小组。PAC有权在开发周期内的具体决策点通过给新产品拨付资金或修改新产品的途径来批准或拒绝新产品。PAC负责通过产品开发活动实施公司的战略,因此,他们具有资源分配权,以推进新产品的开发。

      PAC一般通过阶段评审流程来作出决策和进行资源分配。没有这样一个流程,高层领导就难以有效地引导新产品的开发。然而,只有一个评审流程(或类似的一个流程,如把关流程或阶段开发流程)是不够的。定义不清、实施不当或与开发流程中的其他必要要素不协调,都可能使评审流程效率低下。

      阶段评审流程在产品开发中还扮演着另一个重要角色。通过它,PAC可以直接明了地授权项目小组分阶段地开发产品。项目小组为产品制定详细的建议,提交产品开发计划,并申请下一阶段所需的资源。如果PAC批准工作小组的各项建议,它会赋予项目小组以权力、责任以及实施小组计划的下一阶段所需要的资源。

    项目小组构成

      在评审中我们发现,尽管大多数公司有正规的项目小组,但多数并不成功。总的来说,由于这些项目小组的构成、角色和责任没有明确的定义,结果使沟通、协调和决策效率低下、纷繁混乱。

      有这么一家很典型的公司,不计其数的经理们只在他们有空的时候或是有什么特别原因使会议变得最优先的时候,他们才参加产品开发小组的会议。由于这种方法产生的效果差,所以公司曾尝试用不同的方法来改变这种状况。他们建立了专门的项目管理www.hi-blue.com部门,负责监督进度和任务的提交,以明确由谁去做什么以及事情做了没有。后来,每个部门都给每一个主要项目指定了自己部门的项目经理。但这些方法效果并不理想,只是增加了毫无价值的劳动,而这种劳动已经太多了。

      许多公司建立了项目小组的组织形式,但大多数效果不佳。针对这些不成功的案例,我们发现以下典型原因:

    ·如果项目小组和职能部门的责权不明确,将造成困惑。
    ·项目小组没有得到明确授权去实现目标,因而效率低下;在某些情况下,他们只被赋予了责任,却没有相应的权力和资源。
    ·缺乏并行工程,一些职能和技能无法和谐地融入到项目小组中去。
    ·项目领导工作效率低,这源于几个因素:项目领导人没有经验;对项目领导人角色不明确;培训不足;项目领导人更换频繁;或者项目小组的组织有缺陷。
    ·项目小组缺乏项目实施所需的人手和技能,因而无法实现目标;各种资源在项目小组间调来调去,缺乏明确的决定。
    ·由于没有明确定义项目小组和职能部门之间的协作方法,两者之间便有冲突和困扰。
    ·小组成员任务分配造成的困扰使整个小组效率低下:比如说,小组成员把自己看作职能部门的评估者或记录者,而非真正地帮助进行实时决策。

      项目小组构成是产品开发流程的一个关键要素。一个高效的项目小组能极大地增进沟通、协作和决策。在评审初期,我们就发现许多广为接受的项目小组模式效率低下,而低下的原因与上文所述颇为相似。我们开发了一个新的模式。这个模式既能发挥项目小组这种组织形式的最佳方面,又能克服上述缺陷。我们把它称之为项目小组构成中的核心小组模式(Core Team Approach)。

      核心小组是有权开发特定产品的一个小型跨部门项目小组。一个典型的核心小组有5—8名成员,有权力也有责任管理所有与开发该特定产品相关的任务。这些特定任务分配到核心小组的每个成员身上,每个成员都利用相应资源完成这些任务。小组成员们为指定给他们的工作确定方向,与职能部门打交道,并作为核心小组的一员参与集体决策。PAC则在开发工作的每一阶段通过阶段评审流程赋予核心小组责任和权力。每个核心小组都有一个指导和引导小组工作的领导人。该小组在执行每一开发阶段时遵守与PAC签定的有关重大项目目标以及可变动的范围的“合同”。

    开发活动的结构

      开发活动是开发新产品的实质性工作。在PACE中,结构化的开发流程明确了应做什么开发工作、相应的先后次序、其间的关联性以及用于开发项目的标准术语。在评审流程中,我们发现,开发活动的结构中往往存在三类普遍的缺陷:(1)没有任何明确的产品开发结构的公司;(2)有具体流程手册但并没得到遵循的公司;(3)有结构化的流程但并不能改进或加快开发进度的公司。

      对第一种情况来说,公司必须在产品开发流程中不断地“重新发明车轮”,即重新定义产品开发流程。每一个项目小组都定义其要遵循的流程,结果,每个项目小组即使在执行相同的或相似的任务时,开发流程也迥然不同。这种模式延长了开发周期,且整个公司的项目小组都易犯同样的错误。

      对第二种情况来说,流程被文档化了,但是并没有得到执行。典型的情况是,某个职员在程序手册里定义开发流程,然后把手册散发出去,天真地期待每个人都会遵守它,结果当然是他们并不遵守。多数情况下,他们不遵守反而好一点。项目小组又各自将自己的那一套流程搬了出来。

      对第三种情况来说,开发流程已得到明确和遵守,可惜这个流程天生就效率低下。令人吃惊的是,许多公司在规范流程时,只是简单地将他们现有的做法写成文件,哪怕这个流程效率低下,其结果自然是把问题制度化了。

      在评审开发流程时,我们发现普遍存在下列缺陷:

    ·无章可循的开发活动导致产品不断更新。
    ·由于对必须完成什么样的开发活动及何时完成有误解,因而造成项目计划不周及准备不足。
    ·缺乏通用术语以及由此引起的理解问题,导致开发工作不理想。
    ·产品开发定义过于详细,尤其是缺乏结构化的定义,使得开发效率不高。
    ·每一步都需要多个签字盖章的官僚流程延缓了开发工作。
    ·缺乏并行工程,因为它没有被设计到结构化开发流程里。
    ·缺乏开发活动的周期时间指导,导致项目进度不准确。
    ·由于没有将责任落实下来,导致未能不断地改进产品开发流程。

      在PACE方法中,核心小组用结构化开发流程开发产品,这将确保一致性,并避免小组创立各自的流程。基于一个通用的结构化流程,就可以使用通用的周期时间指南并为持续改进打下基础。

      按照PACE的方法,一个结构化开发流程包括几个等级。在阶段评审流程所提供的框架中,一般有15—20个主要步骤来定义一个公司的产品开发流程;每一步又分成10—30项任务,规定每一个步骤如何在公司里得以实施。这些任务又为每一个步骤定义出标准周期时间,因此可以根据这些基本步骤编制进度表、预估资源需求、制定计划及进行管理。

      每一项任务还可进一步细分成各种各样的开发活动。根据任务的性质,每一步骤的开发活动数量从几个到30或40个不等。总的来说,各步骤与任务永远适用于各种项目,而开发活动则因项目不同而不同。

     

    展开全文
  • 研发管理工具

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

    千次阅读 2018-07-09 12:58:44
    我来介绍一下我所找到的,好用的敏捷工具:国内的「Leangoo(中文名:领歌)」Leangoo是一款基于看板的项目协作工具,Leangoo是由国内最权威的Scrum中文网精心打造,融入了先进的敏捷管理思想。我们可以使...
  • 在此,总结下本人在数年研发管理过程中的一些经验,供参考,先列一些关键点,后面会不断完善。 目标 保证高效率、高质量地完成项目的研发和上线工作,并保证软件在线上运行过程中的高性能和安全性。 保证项目进度...
  • 研发管理之规范管理

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

    万人学习 2018-10-22 21:38:02
    项目管理就是一个大坑,什么都可以放进去! 项目经理就是这个坑的坑主,他需要具备周身刀,并且把把锋利。 本课程为你分享项目经理需要掌握的N多技能。
  • Git实战视频教程

    万人学习 2018-11-02 11:15:35
    Git作为实战型比较强的一门技术,光看书学习效果一般不是佳。Git视频培训课程通过深入浅出的内部机制解析、实际操作、动画演示、使用场景模拟等教学方式,让你提升Git技能,知其然知其所以然,大大缩短您的Git学习...
  • 带你玩转SVN

    万人学习 2019-06-26 11:58:52
    SVN是版本控制利器,团队协作工具之一。本课程主要面向开发人员,帮助初学者意识到版本控制的重要性,掌握SVN环境的搭建,以及SVN客户端工具的使用。
  • Linux Makefile工程实战视频教程

    万人学习 2018-10-25 11:48:38
    Makefile工程实战视频培训课程,该教程介绍Linux环境下开发软件编译Makefile的基础知识、项目构建、一步一步从零开始写一个模拟MP3项目的Makefile。
  • 项目管理工具是团队研发过程中不可缺少的工具,有助于团队协作,大大提高开发效率,这里对几个项目管理软件进行了对比。 1.TOPO 适用于重点关注任务、缺陷、文档及代码的研发团队。支持多项目数据汇总对比,完整的...
  • Jmeter性能测试从入门到精通-全程实战 全程实战,每个知识点通过实际项目演练讲解 理论实践结合,既会做,又知道为什么这样做 讲解时同其他工具做对比,加深理解,了解区别 分享技巧,用起来事半功倍 ...
  • Robot Framework 自动化测试框架

    万人学习 2019-11-29 15:16:52
    Robot Framework 自动化测试框架,包括接口测试、数据库测试、Web测试、App测试。
  • 团队项目管理工具:Maven3入门实战

    千人学习 2019-10-18 09:55:18
    Maven+SVN是目前团队项目开发,使用多的项目管理工具。 学习并掌握Maven与SVN,是JAVA开发人员必须的技能。
  • Python自动化测试之Selenium

    万人学习 2019-11-29 15:18:02
    本课程详细介绍了Selenium Python版本的自动化测试方法和实践,通过本课程的学习你将掌握如下内容:Selenium 测试环境搭建单元测试、生成测试报告、定位元素、WebDriver属性和方法、WebElement属性和方法、操作form...
  • 软件测试入门视频教程

    万人学习 2019-06-25 10:59:08
    软件测试入门视频培训教程:该课程将带你走进“软件测试”的大门,具体内容包括软件测试环境搭建、软件开发模型、产品模型、CMM模型、测试用例、等价类划分、边界值划分、白盒测试、单元测试、bugfree搭建、系统测试...
  • 《QuickTest Professional》原书作者授课,书籍配套视频,QuickTest是测试领域的一门重要的专业技术课程,其属于测试领域中课程。课程讲授当前HP旗下主流自动化测试工具QuickTest Professional。
1 2 3 4 5 ... 20
收藏数 243,199
精华内容 97,279
关键字:

研发管理