对于提升团队研发效率的思考

数据，通常也会视为“研发部门”的一部分，自然也面临需求交付效率、数据质量、稳定性等一系列问题，其实在研发眼中，一切问题的根因似乎可以总结为“需求多、压力大”，有充分的时间，是可以解决掉质量相关的问题。

但事实上，大部分的公司，都是在业务的狂奔中去做需求，一旦业务发展停滞下来，要么意味着要人员优化了，要么意味着没什么需求可以做，程序员可以打酱油了，这都不是一种健康的发展状态。

因此，解决业务高速发展情况下的研发效率问题，是我们的一门必修课。在本文中，我试着把一些做不好的问题进行分析，挖掘共同的规律，并找到一些可以尝试解决的方法。

首先是原因的分析，我们很自然的会想到，业务在高速发展的阶段，创意是层出不穷的，不论是需求的可行化定制，还是人员配比的不合理（如研发对接多位需求方），都无法形成固定的分析思路，因此“更快的响应，更快的烟囱式开发”，就成为了这个阶段的主流。尽管我们可以参考Kimball的建模、阿里云的开发工具，但依旧无法形成有效的“质量沉淀”，时间久了，模型也就变得越来越差。

进一步分析，我们会发现，其实大多数情况下，我们的产品，服务化能力是比较弱的，换而言之，就是“抽象的不够充分”。本以为做一个平台，可以支撑很多的需求，但往往定制化的问题解决不了，又引入了产品和中台这两个概念，来同时兼顾一些特定的开发规范，反而加重了研发的工作量。况且，即便遇到一些合理的产品诉求，也往往因为优先级的问题，被挤压到比较靠后的阶段来做，当我们能够做通用功能的时候，一些历史包袱，就很难被甩掉了。但当我们会看为什么产品设计不好的时候，原因又往往出自于最前端的业务，也就是业务其实就没想好怎么做，或者是规则传递的非常模糊，导致产品不得不适应这些规则化和标准化很弱的场景，产生了“抽象能力”不足的问题。

如果数据能够和业务搞好关系，其实你会发现更多的原因。最典型的，就是目标没对齐，业务有自己的业绩导向，产品有自己的平台导向，研发有自己的价值导向，面对一个需求，我们很难纯粹的从领域建模的视角来做这个事情。有一句俗话讲：“开着飞机换引擎”，当不同业务方的利益、业务传到的压力、中台引擎的能力交织在一起时，做好一件事情，往往就变成了“艺术”，这也是绝大多数数据研发无法更进一步的“根因”。

讲到项目管理，我们往往会想到三种典型的方式，一种是“项目制”，一种是“职能制”，最后一种则是“BU制”。

在业务的初创阶段，往往业务、产品、研发等角色都是在一个团队里的，专门为了支撑某个业务而启动，这种情况下，组织的效率是最大化的，因为每个人的目标和方向都是一致的。这就是“项目制”的阶段。

但是随着业务的扩张，不论是2C的用户方向，还是2B的客户方向，业务需要服务的群体越多，业务线也就会逐步扩张。但为了提升支持的效率，业务扩张的同时，往往又不可能同步的增产品、研发的规模，因为成本是很高的。因此横向的支撑，就成为了这个阶段的选择，也就是产研团队与业务团队分开管理，研发虽然都编在同一个组里，但需要支撑横向的很多不同业务线。

这时候技术架构就需要讲“应用方向”的故事了，比如电商的怎么做、流量的怎么做，以及流量的要配备A/B实验平台等内容。尽管业务线在变多，但总归是有共性的一些应用需求，因此做通用方案就是这个阶段最强烈的诉求，而“降本提效”也就成为了最常见的考核方式。这个阶段，可以称为“职能制”。

但业务总会增加，平台会越来越复杂，到达某个平衡线之后，两者的模糊地带就越来越多了。可以讲，因为需求持续的个性化和系统功能持续的复杂化，很可能业务和产品都搞不懂产品的定位和具体逻辑了，研发在这个阶段人员会变动频繁导致留下一个不大不小的坑，这时候势必技术团队要更加精细化的分工，否则损耗的就是各个团队之间的信任感。

一旦组织需要独立的产研团队来单独进行平台或者某项业务的建设时，中台也就会被抽象出来，以支撑更加复杂化的需求机制。

但这个阶段对于一线研发是不友好的，因为交互的关系又多了一层，即“中台”。而且提给中台的需求，往往又需要排期很长的时间，导致前台团队需要设计一些“反人类”的模型，虽然规模的成本降低了，但其实协作的成本却大大增加了，属于转移了矛盾注意力。

“BU制”是中台环境下的一种解法，但目前并不是最优解，因为跨BU的协作，其复杂性是最高的，一次性搞定太多关联方的利益，几乎是不可能的。

以上文章提到的这些问题，在公司发展到一定规模的时候，几乎都是必然碰到的，因此相对而言，也会有一些粗略的应对方法，本文仅阐述目前一些常见的做法。

最常见的应对方法，是以大促为代表的定期评审 + 需求冻结机制，也就是每年在关键节点前收集需求、统一评审和集中开发。这种情况的好处，是可以把整个需求的链路摸排清楚，并给出详细的解决问题排期，并且在关键节点保障质量的问题，并且，因为需求范围确定了，技术的价值更容易讲出来。但这种方式的弊端也比较明显，也就是需求的变化基本不会考虑在内，并且收集上来的需求，并不一定都能够完成，通常会进行一些讨价还价的会议，减少工作量。

第二种是推广OKR的使用，在前文描述中讲到过，各种矛盾有一个很重要的“根因”，就是大家的目标没有对齐，产生了很多不必要的内耗。因此通过OKR的方式，将O一层一层传递下去，拆到每个人的KR上，也是一种保障业务重要目标优先完成的方法。

第三种是通过工具来支撑，比如以Jira为代表的的项目管理工具，来有效的收集、组织和交付需求。这种模式通常需要PM的介入来保障各个项目之间的资源协调情况，会有一定的人员冗余，但相对于浪费的人力成本来说，还是很划算的一种方式。

但以上三种方法，又有一些的局限性，应对复杂协同还是多少有些力不从心，但在更完善的方法论被提出前，这几乎是研发团队“必然”形成的自组织方法，还是能够适应一定阶段的开发。

之所以想到用“数据”来衡量研发阶段，也是根据之前的文章，有关数据驱动建模发展的一些方法的引申。因为数据是应对“复杂性”的一种解题思路，尽管少有人做的成功，但并不妨碍更多人朝着这个思路来探索更多可能性。

在PMP中，绩效的汇总一共有三级，分别是绩效数据、绩效信息和绩效报告。对应到研发过程，就是研发行为的数据采集、研发行为的建模统计和研发行为的报告解读。

对于一线小二而言，因为通常工作都比较忙，因此数据的采集需要尽可能少的侵入到日常研发动作，所以在一些项目管理工具上做数据的记录，是更合适的，因为每个团队多少都会有自己管理需求的工具，本身需求状态的更新就是需要时间来 *** 作，这里记录是更合适的。

当研发行为被统计上来后，我们就可以针对常见的研发过程，进行流程的梳理和每个阶段的数值统计，例如A阶段 - B阶段的平均用时，每个需求的平均交付时间，个人完成的需求数量等一系列的统计指标。最终讲这些指标在数据分析平台上可视化出来之后，一些关键的卡点问题也就能够清晰可见了。

最后就是针对指标结果做的分析报告，例如需求是否和业务的OKR有强相关性，分阶段的工作量是否存在不平衡的现象，以此解读部分不合理需求，并调整项目的资源排期，就是一件行得通的事情。

但数据来驱动业务发展，并不建议作为“KPI”，因为有人的地方就有江湖，而研发行为的数据造假，是一件很容易的事情，大力会出反效果。

闺蜜老公，某国有银行IT部门，在编，年薪30万+，谈谈他和一般修“996福报”的程序员的异同。

1、加班也是有的，但是属于正常能承受范围的加班，周末一般是可以不加班的。

2、工资30万+，对比阿里、腾讯这些大厂的，算是一般，而且每年的涨薪幅度也是有限的，好处就是旱涝保收。

3、部门里的晋升也是有限的，一个萝卜一个坑，要么有背景，要么极具能力，要不就慢慢熬着吧。

4、因为有编制，所以如果你不离职，一般也不会被裁员。35岁的互联网程序员的危机，基本不会发生在他们身上。

5、晋升有限，工资涨幅也是慢慢的，属于一眼看到头的那种。所以在部门里，有些过了40岁，觉得自己晋升无望、干多干少都一样的一些职员，就开始了养老日常。

稳定、旱涝保收、也有周末时光，闺蜜老公时常自嘲说：“这工作，比较适合他们这些居家型男人，有雄心壮志的好男儿不太适合。”

我作为一个工作了几年的程序员，对于银行 科技 岗的一些看法是：1银行 科技 岗要求的技术能力并不是很强，但是业务能力要有一定的经验，这样就会导致一些想要提升技术的程序员待不下去，而对于业务能力，大多是要在一个岗位待够一定的时间，慢慢熬出的经验，这就要求那些比较有耐心的程序员，对技术没那么有追求，对体制的一些规则承受能力比较强的可以待下去。2和家庭背景有很大关系，对于农村出来的，没有任何银行关系，而且现阶段急需挣到钱的年轻程序员。大多要去互联网公司，因为相比较而言互联网公司的工资给的比较高，虽然加班多，但是确实能拿到不错的工资，而银行的程序员现阶段工资还可以，但是随着程序员体量的庞大，技术低的银行程序员的可替代性更强，导致工资会越来越低，当然那些家庭条件好的年轻人，有不喜欢加班的就可以待下去绿。3和个人规划也有很大关系，都知道程序员到35岁会有职业危机，虽然说在银行工作会稳定，但是职位也不好晋升，基本三十岁以上的都是一般的小组长，不会有更大的职位，但是如果从年轻的时候多去一些互联网公司历练，能积累很好的技术和经验，大多可以当一个项目的小领导，即便不是领导，但是如果你的技术够强，也会在部门里面收到尊重！

资深程序员来回答一下这个问题：

1现在程序员最大的第一个工作弊端，就是加班严重，要么996，要么007，没有生活质量，没有时间陪家人，银行 科技 岗位是不怎么加班的，保证稳定性就可以了，解决加班长的最大矛盾。

2第二大矛盾，就是现在程序员有些吃的年轻饭，35岁以后就面临被辞退被裁员的情况，银行 科技 岗位不会有被裁员的情况。

3银行 科技 岗工资也是相当可观的，时间越长积累的技术经验越好，银行系统轻易不会变动和更新，所以时间长技术也不会过时和被替代。

所以说银行 科技 岗是程序员最好的选择，也是有一定的道理的，大部分程序员还是愿意从事银行 科技 岗的。

谢谢！求关注！

这个问题的本质就是择优选择。

首先程序员到了35岁，在家庭跟身体的双重压力下，精力已经严重入不敷出，那么退路是什么就跟关键了。

最好的选择就是继续重拾你熟悉的技能，那么 科技 岗位就是不错的选择

接下来就是为什么从传统IT公司出来，加班压力太大，精力不支是关键，又想熟悉，又想工资高还加班少

最优的就是银行科级岗位了。

我在一家股份制银行做了一年的技术外包，接触了不少行内 科技 岗的正式员工，谈一谈我的看法吧。

行里一般是业务驱动型，重安全和稳定，所以技术迭代比较慢，对业务的理解能力大于对技术的要求。如果你对新技术有极大的狂热与追求，那银行 科技 岗肯定不适合你，因为这边很难得到技术的提升。

然而对于不太想撸代码的人来说，行里 科技 岗简直不要太幸福。

首先，随着时间的沉淀，很多之前行里的程序员都慢慢转业务岗了，平时就做做需求收集分析和项目管理，不参与实际开发，说实话对业务很熟的话基本就没有什么35岁被裁员的危机了，相当的稳定，因为业务需要沉淀，很难一个新人进来就可以替代胜任。

其次，行里基本都是朝九晚六，下班就走，不用像互联网公司一样996加班，可以有更多时间陪伴家人，做自己想做的事情。

最后谈谈工资，每月工资普遍不高，但绩效，年终奖及平时福利加起来一般不会比非一线互联网差太多，但要是换算成时薪，甚至都比一线大厂高。

所以个人建议，如果没有太多的技术追求，不想搞大钱，喜欢稳定，害怕35岁后被裁员，那银行 科技 岗绝对是最优选。

对于35岁以下的人并不是！

坐标上海，90的IT妹子，刚从银行出来！

对于那些没有任何经济压力的人来说，银行确实是一个好去处，可以完完全全躺平，也不用担心被裁员，只是晋升空间小，薪资稳定（涨幅很小，而且普遍低于互联网行业，除了像招行那样的金主爸爸外）

我在银行4年多，只有一次基本薪资普调了400（据说是根据KPI，200，400，600三挡），出来的时候猎头都心疼我这可怜的与市场严重脱节的薪资水平[捂脸][捂脸]

但是，对于绝大多数35岁以上的IT从业者来说，银行确实是一个好的选择，因为这个年龄阶段的IT人往往会被互联网行业所抛弃，去银行简直不要太理想！

个人觉得年轻人还是先去大厂历练一下，再去银行，这样容易要到高一些的薪资，但是银行内的勾心斗角要做好心理准备，领导马屁该拍还得拍，太高尚了可能处境会艰难[泪奔][泪奔]

这句话就是胡扯，对于任何行业都是能靠近利润中心或者权利中心就一定靠近，能远离成本中心以及辅助工种（所谓三产）就一定远离，银行IT属于彻头彻尾的身为辅助工种的成本中心

进银行做IT就两种可能，一是去分行或者总行机关（非研发中心）信息部门做机关行政工作，二是去研发中心做技术工作，第一条路代表着你彻底放弃了代码工作，也就不再是程序员，同时信息部门出身将会在未来极大限制你的内部升迁，信息部门在银行的地位类似于老干部局及地方志编纂部门在政府机关的地位，是出不来大领导的，猴子爬杆式的升职最上边的猴子爬不上去下面的也别想动，同时你也不可能通过校招直接进机关，信息 科技 管培生一样要在基层轮岗，半年-三年的支行基层轮岗风险极大，先不谈50%以上的机关竞聘淘汰率，如果当初搞这个计划的领导左迁或高升了，这一批人彻底被人事部门遗忘，作为一线营销人员呆一辈子支行基层也不是不可能

如果你能确定自己轮岗后能进分行/总行机关（比如你是招行之类股份制省分以上管培，或者部分不喜欢暴殄天物的国有行），那第二条路甚至都远不如第一条，现在各大行研发中心往往打着“总行直属机构”的名号招聘，但事实上这种研发中心在机构设置上和分行和其他业务直属机构（内审、证券子公司等）完全不同，管理扁平职位少，领导往往来自外聘或者其他部门空降（流放），内部升迁难度较业务部门高很多，可以说是前途渺茫

而升迁难只是研发中心最微不足道的缺点，就我的了解大部分选择银行IT的程序员都是为了追求稳定，然而研发中心真的稳定吗？远离权利中心又不产生利润，且和日常经营关联低、易替代的特点就决定了研发中心是银行中最不稳定的部门，改制子公司、彻底剥离独立都不是没有可能，银行高层过去、现在都没有从研发中心出来的大领导，可以说研发中心的命运从来就没有掌握在自己手里过，一旦银行业利润出现问题，又能指望着谁去力保这个部门的利益不被牺牲呢？

部分人可能认为我在危言耸听，但我以我家石油系统三代人的经验告诉你们，行业危机到来的时候，率先奖金归零工资七成的就是做劳保工服的三产企业，而研发中心在银行的作用和石油三产是类似的，全部外包出去也不会对业务开展产生实质性影响，石油系统做工服的当年还是“XX局直属企业”呢，论行政级别不亚于生产研究单位，而“XX采油厂电视台”已经从科级单位变成股级单位了，

@世界人民上议员

诸多回答里提到的东亚文官体系就是我国各类央企国企的现实，在这个体系里可以掌握自己命运的就两种人，要么进机关单位当文官，要么进利润中心为全系统的人当 bread winner，一定要记住，央企里工匠也是分三六九等的，搞减员增效从不会裁撤作为权力中心的机关和作为利润中心的业务部门，一般都是先拿最可有可无，在机关连话事人都没有的那一批工匠动刀，银行研发中心程序员就是这样一个群体

个人认为，银行IT只适合两种人，第一类是十分厌恶编程的信息技术类学生，编程如上坟，最大的追求就是永远不要编程，同时资历又不够苏粤选调、人才引进和其他优质选择的标准，可以走第一条路，能利用专业优势找到一份比较好的工作，工作后也可以谋求内部调动转型；第二类是由于诸多硬伤实在拿不到其他的好offer，这类人可以去研发中心，银行IT虽然在前途上不如大厂员工，稳定上不如业务部门行员，但也比诸多小公司强的多，同时也保有了未来冲大厂的可能

实际上计算机类专业作为当今的万金油工科专业，如果不想996跳槽、追求稳定内部发展也有很多去处，比如真正的金融业和公共事业事实上都能提供比大厂程序员低不了多少的综合收入，且在前景上不一定比大厂程序员差

如果不想丢掉编程技能，做量化算法、风控模型的都是在业务一线的金融程序员，既有稳定又有前途；如果无所谓编不编程，各地的选调、人才引进都是优先选调信息技术人才，试问去苏州工业园优化营商环境，和企业家谈笑风生难道不比在银行最没地位的部门写没人看的报告、码远离业务的代码香吗？更何况前者在薪资待遇上甚至比后者还高，随着“新基建”“中国制造2025”“带货扶贫”等概念的炒作，过去和信息产业毫不相干的政策性金融机构、融资租赁都在近几年大规模扩招计算机及信息类学生，我在校招的时候这类套利机会比比皆是，甚至在某行研发中心面试时碰到的计算机大佬比待遇更好、地位更高的政策行还多，未来几年这类机会只会越来越多

写这个的原因也不是去劝退银行IT，事实上农行成都研发中心不知道比成都一众996小微企业强上多少倍，但对于真正的人才，还是希望大家一不要浪费自己的技术，二不要浪费自己的学历背景，否则到时一边看着自己大厂同学的薪资流口水，一边看着自己考选调进体制的同学的前途福利酸倒牙，而自己想两头兼顾结果什么都没有，空耗几年青春还得从头再来就没意思了

这只是相对的。成都这边有不少银行招聘it从业者了，我也见过不少人在银行做软件来来去去。但是除非是总行信息部，其他的都只是内包而已，比外包好一点，有的称为二级或三级子公司，有的在行员来说都是外包。毕竟银行的主业是金融。而这些 科技 岗怎么样呢，待遇还可以，不过加班一样的多，不可能轻松的，而且技术老旧，杂事多，也不会有成长，有的商业银行it岗一样的有末尾淘汰，压力并不小。要说最好的选择，还是公务事业单位的信息技术岗，或者比较大的外企，要不还是去奋斗吧。

我现在就在银行做软件类的工作，每天实际干活的时间没超过4个小时的。适合养老的工作岗位。

银行 科技 岗工资高，福利好，工作强度相对于互联网公司不算太大，当然好啊。

银行 科技 岗，估计年薪都在四五十万，应届生年薪30万。金融行业本来就是赚钱行业，作为发家致富的确是个好去处。我曾经的同事，进入银行 科技 岗后，月薪直接翻倍，从不到1万直接奔到2万，每天都有零食、水果供应。

而且银行年终奖高，多的甚至10几万。一般招商银行、工商银行比较高。

银行工作，光鲜亮丽。非常适合大家发展，而且比较有地位，受人尊敬。

我同学能进入银行的也是佼佼者，一般发展前途都比较大，有行业积累作为后盾，很适合长期发展。

银行工作技术都比较成型，不会有太难的技术。总体来说很稳定，不像互联网公司劳动强度巨大。

应该是舒适、安逸的，工作时间也固定，不会过劳。各大银行都在争相挖人才，对于大家是个重大利好消息。

能进银行 科技 岗，赶紧去吧，肯定不会后悔。

程序员日常开发工作，基本是上离不开阅读文档，这也是很多程序员喜欢两个显示器的原因。

项目方面

技术方面

是不是很多人都认为，如果在开发过程中，还要不断地翻技术文档，说明他的开发能力不扎实。其实不是这样的。

首先IT行业技术升级换代的速度太快，当我们大多数公司还在用Java8的时候，Java11都已经出来了。如果非得要程序员熟知每一个类、每一个方法，是很不现实的。

很多时候我们只需要了解有这么一个东西，作用是干什么的，具体的细节可以在用的时候再去翻文档，比如方法名字是什么？参数有几个，都是什么类型的？

所以我们都习惯至少两个电脑屏幕，一个屏幕写代码，一个屏幕看文档；如果豪一些的话，再加一个屏幕展示日志信息。

看文档的屏幕要买竖屏！

我们团队

我这几年也带过几个团队，对于每个团队成员，我对他们的要求是：实现需求的前提下，最好能对所用的技术有一定的了解，千万不要从网上抄过来一段代码就用，这样是很危险的行为。所以鼓励大家多找一些资料，最好是阅读框架的官方文档。

现在的团队，我已经这样要求了：代码写累了，或者觉得自己没有状态写代码，可以找点儿自己有兴趣的技术文档学习学习，这个技术甚至是可以跟现在的项目没有关系的。

首先，我不是程序员，我是一个设计工作者，不过我来说一下我的观点：很多人以为程序员像**里的一样，啪啪啪几下键盘，屏幕数据飕飕的变，其实真实情况是程序员写代码就像学生写作文，也会遇到不会的词语跟修辞手法，那这个时候就要停下来想一想，查一查，看看例子是怎样写的怎样用的，写错了还要划掉（删掉）再来，至于这个大量不大量看的情况，如果这个是个新手，那肯定是可以的，那如果是个老手，还需要大量时间查说明文档，那就说明这个项目肯定不会小，不是一两天能做完的，那一个用月做单位的项目，用一个天做单位的时间来查文档，不过分吧！程序员也是人，不是因为他的工作高端，就觉得这个人万能，他也会当机，要吃饭，要休息，也会忘记一些东西，所以请各位多多体谅，能一起工作实属不易，感恩2018，谢谢。

这个问题怎么说呢，开发过程中会遇到各种各样的问题，没有一个人是全能的，也没有人可以绝对的说自己在整个项目中不会遇到一点问题，不去查东西，自己大脑里的东西完全可以让我把这个项目测测底底的做完，并且没有任何bug。

上班的时间，也没有老板或者谁在后面一直看着你去做东西，大家都挺忙。文档是干嘛的，文档本身就是用来看的，甚至很多项目开始之前，总监都会让你去搜集一些这个项目可能会遇到的bug，可能会用到的效果，尽量在之前找到比较好用的插件，这样会节省很多时间，自己如果写代码的话不可能百分百的确定没有人和bug，但插件不一样很多插件都是前辈通过很长时间慢慢完善出来的插件，所以很多人才会用。所以你提问的可以肯定的回答你允许。

程序员上班的主要工作就是看说明文档，根据说明文档编码。如果实在没有说明文档，有时还得亲自披挂上阵写说明文档。

写接口的有API文档，写通讯协议的有协议字段说明文档，写数据库的有数据库规范文档，

总之任何一个大公司文档扮演的一个至关重要的问题，因为形不成文档，公司管理就会陷入混乱不堪的局面，当某个核心员工离职后，下一个接盘的程序员会丈二和尚摸不着头脑，一头雾水，边填坑边骂娘，有了文档就可以看文档结合代码，了解其中模块逻辑以及结构，包括哪些坑不能踩等等好处。有些公司会专门有文档工程师这个职位来专门负责整理各种文档，并且保存在服务器上。

好的文档都是程序员等人智慧的结晶，是一盏指路明灯，是一条通往光明的道路。程序员不能看说明文档等于在黑暗里摸爬滚打，有了说明文档才迎来了黎明的曙光。

说个我遇到的2个真事吧，

第一个，公司找的外包公司写项目程序，已经要交付了，发现有几个功能没做，产品经理和开发那边都找我，我一个搞运维的又不懂，只能让他们去对开发文档，我也就顺便看了看，开发文档中明确的写明怎么做，然后就让他们就重新按开发文档继续写，

另一个，由于 历史 原因业务系统处于托管状态，只有部分参考文档可用，开发那边只能按当前已有文档进行开发参考，开发那边也一直在根据现有相关文档进行开发，杯具的是这帮子不仔细看，有问题总想着我能直接给他们答案，我也只是会用而已，开发我还真搞不来，然后和他们一起看开发文档，加密算法部分给她们指出后，问题解决了。

所以我觉得，开发团队在开发中很有必要阅读开发文档，这可以避免绕圈子，也会清楚开发文档中提供的内容。

先说观点，我认为看文档没什么问题，但是“大量”这个程度很难衡量，按照需要看文档是个非常重要的事情。

需要花费时间的情况 不需要花费大量时间的情况 小结

在工作中阅读文档其实也是工作内容的一部分，而且现在大多数互联网公司都靠KPI进行考核，平时就算你把时间都用来看文档没关系，最后KPI没完成一样会被公司淘汰。所以公司不会阻拦你花费时间看文档，最多你老板会提醒你浪费这么多时间看文档而没有实际的产出会对你年终考核造成影响罢了。

题主对文档的定义不是很明确

第一个是需求说明文档

这个是在开发过程中必不可少的文档，只有清楚了开发需求，程序员高效率的开发，程序员一天的工作时间并不是都是在写代码，而是在看文档，了解需求，理清思路，只有什么都清楚了，写代码或许只要十几分钟。

再者对于一个项目新人来说不看文档了解需求，没人给你从头到尾的在讲一遍需求，你不看文档自己发挥？进入项目是和别人共同开发，你不肯能不顾及之前的代码规范。

第二个是开发文档

就拿微信开发来说，微信开发不是每个程序员必须会的东西，但是用到了怎么办，还不是去看他们的开发文档，只有将开发文档思路理清楚了，才可以进行下一步开发。

第三个是API文档

在前后端分离的开发模式中API文档是必不可少的文档。不看API不知道数据是什么样。也就是不可能顺利的和后端进行结合。

兄dei，假设你是程序员，你在写程序时，旁边会有人守着你吗？

假设你不是程序员，你在做本职工作时，旁边会有人守着你看你怎么做事吗？

答案肯定是没有的。谁会闲着招个人去监督你，看你用什么方式去完成给你的任务。

所以，其实你看不看大量文档，没有人会在乎，关键是你自己，建议自己写东西时，不要一味的复制粘贴，要有自己的想法。太依赖文档对于自己成长很不利

当然允许看文档。

要知道，随便哪个类库，都有无数的类和方法，每个方法又有若干参数，鬼知道它们都是什么意思，谁的脑子能记得那么多内容。别说是人家提供的类库，就是自己写的代码，过一段时间也不记得什么意思了。没有注释和文档，怎么看懂代码？

如果没有需求分析文档，程序员怎么理解正在开发的这个软件的基本业务流程？

如果没有架构设计文档，程序员怎么理解软件各个功能模块之间的功能与业务逻辑？

如果没有接口文档，那么多类和方法，都怎么调用，会返回什么值，难道靠猜？

……

在日常开发工作中，不仅允许看文档，还会强迫你写文档。如果你写的文档别人看不懂，别怪领导骂你不认真。文档对于软件开发的重要性是不言而喻的。

还有一个秘密告诉你，那些经常写文档的程序员，要比不写文档的程序员工资更高。

真的！！！

迎娶白富美，从会写文档开始！

这个问题要根据具体开发的功能模块来看，不过原则来说，花大量的时间看说明文档，至少给人的印象是经验不够丰富，开发能力有待提高。

具体来说，如果是普通的功能开发，技术挑战不大，这种如果还要看文档，会被认为是开发能力问题。如果是有一定的技术挑战，公司在这方面的积累比较少，开发团队也对此有共识，这种问题看文档无可厚非，当然如果能业余时间学习相关的知识，会给团队留下开发能力强的印象。对于一些前瞻性研究，公司没有任何技术积累，或者全新的技术方向，这个看说明文档是加分的，甚至可以要求公司购买相关书籍或者在线培训，当然，自己啃下来会更NB。

以上就是关于对于提升团队研发效率的思考全部的内容，包括:对于提升团队研发效率的思考、为什么说银行科技岗是程序员好的就业选择、程序员在上班时，允不允许大量的看说明文档来帮助写程序等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！