国内研发团队普遍常见问题

下面是国内研发团队普遍常见问题,大家说说各个岗位怎么提高质量和效率吧。

一、产品设计

1、业务没啥清晰的战略核心主干与目标。业务需求不会解构洞察。客户提什么就做什么,业务需求和软件功能要求混在一起

2、不会建立业务模型和产品模型。客户提什么就做什么

3、不会理性需求排级,不做数据度量论证/也没有数据可度量/也不知道度量哪些合理数据。客户谁权力大谁态度恶劣谁叫的声大。就先满足谁的需求,研发团队疲于奔命赶快应付完工匆忙上线再重复填坑

4、不会增量设计。仅仅会撕开个口子强塞进去

5、场景不会分离,各种场景混合在一起

6、不考虑非功能性系统需求/也不知道怎么考虑也不知道该考虑哪些方面的非功能性需求。没给代码重构留下时间

二、项目管理

1、团队成员属于各自部门。成员受部门经理和项目经理双重领导

2、项目团队不坐在一起。測试坐在測试部、开发坐在开发部

3、不理解方案,不知道最佳方案,不知道怎样合理评估工时,出了异常问题不知道怎样做正确决策才算正确合理

4、不会资源管理、排产管理

5、推动力、协调调度、沟通说服能力不足

6、不知道怎样正确开日立会、日立会的目的和重点是什么

7、不知道怎么做合适的项目报告

三、开发

1、不接触客户。不理解需求,不理解功能为啥要这样设计

2、开发期才介入项目

3、代码不会按场景分离。产品设计人给出什么样的业务流程就做成什么样的代码流程

4、不会代码设计,流程和细节都在一个函数,功能多复杂代码就多复杂

5、不会代码增量设计,有了改动需求,就在现有代码上插代码

6、不会重构分析、重构设计、重构改动、重构測试。就会要么推翻重写要么在现有代码上改动

7、不会进行接口设计、函数输入输出參数设计、异常日志报告与记录、返回值设计。没有专人对接口设计/接口变更负责。没有接口变化检查工具。没有公司接口统一规范。

函数封闭性不强。改了A后B莫名出问题。

8、不会面向对象编程。业务逻辑怎样就怎么写代码,不会恰当构建类与类继承

时间: 2024-10-24 07:39:27

国内研发团队普遍常见问题的相关文章

中小研发团队架构实践之系列大纲

以下是中小研发团队架构实践系列的大纲,部分已链接,未链接部分我也会持续的更新和发布,期待你的支持与互动. 第一篇 开篇--照着做,你也能成为架构师 第1章 中小研发团队架构实践,附案例和代码 一.框架篇--工欲善其事,必先利其器 二.架构篇--思想提升 三.公共应用篇--业务与技术的结合 四.进阶篇--从架构到管理 五.案例参考和Demo下载 第二篇 架构篇--思想提升第2章 企业总体架构规划 一.企业商务模型 二.架构现状 2.1 功能架构 2.2 应用架构 2.3 数据设计 2.4 物理架构

产品研发团队如何融合OKR与Scrum敏捷开发?

「 OKR 」现在非常的火爆,很多公司都在使用,不仅国外的 Google.英特尔等大公司在用,国内的一线知名互联网企业今日头条和一些创业团队也都在使用. 那为什么「 OKR 」这么受欢迎呢,因为把它可以帮助团队 达成共识.加深信任.加强协同. 并且「 OKR 」这套方法,不仅可以帮助我们开展工作,还可以用它来管理个人生活.例如互联网大牛 吴军 就是固定使用「 OKR 」来管理他个人年度目标和计划的. 乘着假期,我也仔细读了两本关于「 OKR 」的书籍,<OKR工作法>.<这就是OKR&g

对话巨杉核心研发团队:分布式数据库自研之路

一直以来,数据库的核心研发团队都十分神秘,作为隐藏在幕后的隐士高人,他们对数据库发展以及数据库研发团队的看法是什么呢?本文我们就由巨杉数据库核心技术研发团队的"老司机",向大家分享他分布式数据库的自研之路. Q:作为数据库行业的"老司机",您能否先介绍一下自己?A:我叫Danny,是巨杉数据库核心研发团队的成员,是一名数据库资深工程师和架构师,有超过20年的数据库核心研发经验,曾经作为DB2 内核研发团队成员参与了DB2 ,DPF等产品的架构设计和研发工作.目前,我

合理的用户业务研发团队搭配

1.前言 用户业务指的就是面向用户的产品展示及用户操作入口,简单点说就是APP,微信,H5活动页等一系列前端展现入口的集合.用户是多变的,用户是神秘的,没有任何产品能从一开始就把握住用户的需求,任何好的产品和功能都是不断试错,不断调整出来的,所以我们需要一个能快速反应的用户业务开发团队,新需求快速上线,已有业务快速调整,响应越快才越有可能在竞争中走到别人前面,产品才有胜出的可能. 用户业务业务研发团队可以称为广义上的前端团队. 2.团队意义 用户业务研发团队(后文如无特殊说明,用前端团队简称),

微软中国的相关研发团队 交流平台

1. 微软中国研发集团服务器与开发工具事业部: http://blogs.msdn.com/stbcblog 作为微软中国研发集团的核心研发部门之一,服务器与开发工具事业部在上海和北京与总部及世界各地产品研发机构紧密配合,致力于为微软用户提供安全与访问.管理与服务.互连系统.数据平台.Windows服务器解决方案.商业在网服务和开发工具等核心产品与技术的研发和孵化. 服务器与开发工具事业部还积极与本土合作伙伴展开战略合作,分享研发管理和产品开发的经验,将创新成果带给广大用户.此外,事业部还在中国

Oracle 裁掉北京研发团队,相应职位撤回美国(收购了NetSuite,LogFire,Dyn)

根据中国日报报道,2017年1月14日上午9点09分,甲骨文北京研发团队的同事收到了来自BU老大的一封邮件.邮件上提及,由于市场变化,甲骨文开始整合各研发中心资源公司在云计算方向发力,文末单独提出了甲骨文在中国将会裁员,裁掉的员工必须在2017年3月31日之前离开.实际上,在一个月之前甲骨文就裁掉了大约十几个北京员工,当时大家都以为仅仅是因为人员冗余公司才进行精简.但是没想到这一次北京研发中心有200多人受到了这封措辞严谨的公开信,这意味着甲骨文为了整合研发业务,要裁掉云计算存储相关的整个北京研

[转]一个优秀的研发团队应该具备什么特征

一个优秀的研发团队应该具备什么特征 1.计划执行:计划安排得当,不要老加班,不要老是现实和计划不匹配.不要做到哪儿计划就推后到哪儿. 2.研发成果:成功产出几个重影响力级别的.完整成块的.有成就感自豪感的产品或项目 3.团队氛围:这个团队每个人都相处的很融洽 4.团队协作:每个人都能找到自己擅长并喜欢做的事情.团队允许发出不同声音,不打击不反击.团队允许各种性格和背景的人都能存在并融洽存在. 5.团队协作:团队不要造成老是关键几个人忙死,其他人都在等这几个关键人完成核心事情后才能工作 6.团队氛

中小软件企业的研发团队建设(一)团队的组建

在软件企业中,研发部门负责的主要的工作是软件设计与研发,都是强智力创造的活动,所以团队建设对与研发部尤其显的重要.优秀的团队是研发部门能获取成绩的根本. 我对研发团队组建的一般流程的认识为: 而中小软件企业团队建设中的有自己对应的特点: 主要的劣势是 1 招人经费不足,企业背景没有吸引力. 2 人员的稳定性先对与大企业相比很低. 主要的优势 1 部门建设灵活,可变性高. 2 老板"唯利是图",注重个人技能带来的收益,而对人情关系网比较轻视. 那么在中小型软件企业中构建团队就需要我们扬长

研发团队中引入变化的思路和模式

过程改进是研发管理的本质性工作,如果过程要改进通常意味着我们要引入变化,尤其对当前研发管理工作和流程尚不规范和完善的团队而言,引入变化是必须走的一步.但个人在实践过程中体会到引入变化有时候是一项非常有挑战的事情,如果把握不好可能反而会起到反作用.本文从研发团队如何有效的引入变化的角度出发,对思路和模式进行探讨. 关于团队引入变化,业界也有一些主流方法论,其中受Mary Lynn Manns和Linda Rising两位博士的著作<Fearless Change: Patterns for Int