开发小结-团队管理类

Code Review

Code Review 颇有必要，在Code Review时，要按既定的原则与目标进行，不炫技，不挑刺，找出代码的缺陷和需求理解不到位的地方，相互学习代码设计与思路。

要作到对每一个人的每次提交都作严格的code review机制，这须要一个强大的制度流程保证和团队leader的主力推动。不然很难在实际工做中推行。

关于这点，我有一个思路，在每周四下午，进行集中式的code review，抽检范围为上周四至本周四，对提交记录中随机挑选3条，先由对应提交者讲解，而后你们针对本次提交，提出各自的观点见解，具体可从如下几个点来展开：

• 判断提交类型，是Bug单、需求单仍是优化单？
  • 如果Bug单，则要理清Bug的产生链条，修改的思路和影响分析
  • 如果需求单，则须要讲解本身对该需求的理解，完成需求的任务分解和基本解决方案。
  • 如果优化单，则要讲解优化的动机、具体手法和影响范围。

其余同事可对讲解者的当前作法提意见，若没什么意见，老员工可就业务流程进行一些适当的延伸，无论是技术原理讲解，仍是业务规则梳理，均可以。总体时间控制在1小时左右，每一个commit平均分配20~30分钟便可。

每两周一次业务分享，能够是新技术研讨，也能够是现有架构介绍：团队按期进行新技术的研讨，保持对新技术和新业务的敏感度，业务分享须要提早一周肯定分享主题。这个能够和code review每周交替进行，一个月四周，两次code review，两次业务分享。

团队协做

当使用他人提供的接口或者模块时，若是现有功能不能知足本身的须要，即便能够看到他人的具体流程（有源码的状况），也不能去贸然去修改，要将改动的动机以及本身的见解经过邮件或者QQ截图传达给原做者，让他去评估是否作修改。回到本身的工做上，能够本身组合接口基本功能，提供函数来知足本身的需求。

不是全部的Bug的最终走向，都以修复为结束，对于那些暂时不予修复的Bug，须要和产品、测试沟通肯定后，将结果落在Bug单中，以备查验。

接收其余部门发来的设计文档、接口文档等原始文档，必定要归入本地的版本管理系统。归入版本管理后，才能走下一步。
必定不能去改动原始文档，由于一旦有修改，那么该文档的有效性就由其余部门转给你身上，之后由该文档的错误致使的问题，也会归责到你身上。若是以为有必要将分散在各个文档的零碎信息汇总到一块儿，那么，本身应该在本地创建汇总文档，不要将自用的汇总文档覆盖原始的接口文档。

跨部门的协做，若是别人经过群发邮件来咨询问题，当本身知道解决答案时准备回复，须要群发回复，让每个接收者都知道该问题已经获得解决，以防其余人浪费精力解决已解决的问题。

在实现功能时，有一些细节地方，在需求文档里面没有明确指示的，在A作法也行，B作法也行的时候，必定要向产品经理提出疑问，等待反馈后，将获得的反馈到JIRA需求单例去，根据JIRA需求单来作,作到凡是修改要有记录和可回溯性。

在团队合做中，做为基层员工，你只须要对你本身负责的模块负责。在平时开发工做中发现其余模块的坏味道时，不要想着本身发现别人的问题，而后尝试偷偷地去解决这些问题。这里犯了大错，错在不通知他人的状况下，擅自改动他人代码。
本身的贸然改动，修好了，没有人会知道你的劳动成果，修的很差，一旦发布后出去问题，层层追责后定位到是此模块的问题，这就会你带来没必要要的麻烦，即使出现的问题不是由于你的修改直接形成的，但因这其中有你的改动，就很差说清楚因果关系，本身曾经犯过这类错误，之后必须时刻谨记，谨记。不要自做聪明。好心办坏事。

从开发者的角度来看待改动，除非改动的影响范围极其有限，不然是没法拍胸脯保准本身的修改不会带来任何问题，就算是增长一行空行，也没法确保。
对于测试人员来讲，开发的任何修改对他们都是黑盒的存在，是不可信的，即便开发说本次改动只影响某个模块。在团队做战中，自测是对开发人员最为基本的要求，除了自测以外，还要让测试人员知道咱们所作的修改影响的模块或者范围，不能闷头作事，本身提交代码一时爽，测试人员两行泪。

重构时必定要有边界，作什么，在哪里提交，分几回提交，在哪里记录，在哪里反馈等等，在这里，不谈具体重构手法，而谈谈重构的一些注意事项。

当本身发现其余人代码（亦或是本身的代码）中一些坏味道、腐朽的迹象时，内心动了重构的念头，此时，有三种心态：

心态一：本着多一事不如少一事的原则，发现这些坏味道，只要不影响本身负责的模块，就不提出。但在本地有记录，此处能够如何如何改进，等之后告知相关模块负责人。

心态二：本着精益求精的原则，也能够说是程序员洁癖，看到一些不合时宜的代码，则要对外抛出，主动给本身或其余人找事作。

心态三：本着投入产出比来讲，要看状况抛出。好比，重构这块代码可以带来显著的效果，而且本身已有一套重构方案，那就能够提出，若是这块代码不痛不痒，而当前有更重要的工做要去作，那就视而不见。

这三种心态，没有绝对的对错，不一样人有不一样的见解，执行不一样的选择吧了。

这里面抛出的意思时，把准备要改动的范围提出，改动带来的好处和可能的影响也一并提出，至于具体要不要完成，不是重构实施者来决定，而是有团队小集体来决定。

本身的体会，写代码是创造，改代码是修补，读代码是吸取。咱们的大部分时间都花在了读代码和改代码上。产品人员提需求，开发人员提重构，测试人员提Bug。

当发现现有软件的Bug时，整理清楚问题复现的路径和环境，告知测试人员，让他们推送Bug的产生。若是发现问题出如今本身负责的模块，那么理所应当要修复它们，这里不是指的立刻修复，而是将可复现的路径告知测试，提Bug单后，照单修复。作到在SVN上的每一次提交，都有对应的Bug单、需求单或者重构优化单，这些单才是开发对接产品、测试和运维的依据。

针对关键组件，能够由老带新，以结对编程的方式，传承经验。

对于重要的修改，能够用patch的方式先作作code review，确认无误后再提交。

每一个具体模块都要有模块责任人，每一个人对本身的模块负责，当其余模块出问题时，直接告知对应责任人便可。可将每一个人与负责的模块汇总成表格，给测试或者是其余团队成员来查看，方便测试人员快速对接问题的开发人员。

周报管理

在每周的工做总结，不只仅要写已完成的工做内容，哪些未完成的工做，遇到棘手问题的工做内容更加有记录价值的。本身针对该问题和哪些人有讨论，分析遇到的问题，这是对本身工做的总结。

一项任务进度的描述，不能只有未开始和已完成两种状态，在汇报任务进度时，先要将任务分解为若干子任务，目前已经完成了哪些子任务，还剩下哪些子任务待完成。

在指定年度工做计划时，我的工做目标须要和团队（或者说是部门）的目标一致。
好比说，部门目标是注册用户量过20W，天天交易量要保证是5亿，那么对于负责交易模块的同事，要围绕上述目标来设计。工做内容职责范围均以此为依据，对于其余技能的提升，也要结合当前工做职责来描述，为了更高效地完成工做任务而学习，不要脱离工做职责范围而去胡乱学习，切记写些我的爱好学习之类与工做不相关的内容，这会让审阅者认为你在游手好闲。记住，公司不是请你来学习的，而是要你来解决问题的。

在梳理工做小结时，须要有逻辑条理，不能一上来就写你完成了什么功能，还有那些功能没有完成，让别人一会儿进入太具体的工做细节描述，很容易绕晕的，很差从更高层次看清你目前工做的全貌。能够按照总分总的逻辑顺序来整理工做内容和工做完成状况。

放权问题

合理放权是很重要的。通常来讲，一我的可在直接高效管理6我的，对每一个团队成员可以很好管控。随着团队规模扩大到12我的，事必躬亲就略显吃力，各个员工管理起来开始困难，当规模快接近20人时，若是管理者还想着天天和20我的都有技术和项目的交流，几乎是不可能的。因此，管理者要善于发现下属中是否有职业规划走技术管理、项目管理的员工，有的话，注意及时给与机会成长，这样一来，既能够创建层级梯度团队，又能够留下优秀员工，同公司一同成长。

作领导要合理放权，也要用于承担责任。

在此分享一篇好文章：IT小团队管理者的突围之道

技术思惟

技术思惟是总从技术的角度去考虑事情，凡事必追求肯定性，容不得半点含糊，一是一，二是二。而真实世界的事情不是if-else或者 switch-case就能够解决的，每每存在权衡和取舍。没有完美的解决方案，只有针对当前场景最适合的解决方案。好比产品经理提出了一个对用户颇有价值的事情，可是从技术角度上面去实现，会很复杂，这种状况下，若是技术人员不考虑实际用户的需求，以实现复杂性或者影响框架等做为简化需求的理由，就是典型的技术思惟，而不是产品思惟。技术人转行作产品经理的，技术是他的优点，若是摆脱不了技术性思惟，那么将会极大的制约产品的发展。

多向身边各行各业的人学习，多接触别的领域，不少时候在你没接触以前就贸然说本身不感兴趣，来不了之类的话，那只是你在未你的懒惰找借口而已，只有接触过，亲自尝试才有资格说不感兴趣。

管理者视角的指望

在工做中，我隐约感受到，若是是从领导者的视角出发，一个听话、可控的下属比一个厉害、老是作一些不可控事情的下属更加可靠。老师喜欢听话的乖孩子，医生喜欢配合的病人等等，道理都是相同的。

所以，领导不要求下属有多厉害，而是要求下属在领导可控的范围内，干明确的、可控的事情。就像都是本领高强的人士，二郎神和孙悟空就表明了两个极端。可控意味着结果可控，即便结果未如人意，领导也可以承担下来。最怕那些愣头青，不清楚影响范围的改动，会给其余人员带来极大的心理负担。

在平时的工做中，当遇到的问题时，本身要将尝试的解决方法以及各类方法的解决结果，梳理清楚，若是一两天仍是无明显进展，须要及时反馈上级，让上级知道下属当前走到的哪一步，碰到的哪些问题。做为上级，他可以给予哪些帮助和指导，让他有参与感进来，而不是让下属一我的努力完成全部工做。

在职场中，作的多，并不必定意味着作的好，如何有效的汇报本身的成果，是须要反复斟酌、思考的。要作到能力比薪水高一点点，就要事事超出老板的期待一点点. 预知或者预设老板的指望值，而后超越它，这就是向上管理中的重点。

在平时的工做中，除了完成本身本职工做外，也要善于发现现有项目、团队中一些有待改进的地方，多观察，多思考，多交流沟通。有一些工做能够先作一部分，初步整理造成可行方案，准备怎么作，预计多长时间，影响的范围有哪些，带来的好处和坏处有哪些，把这些权衡点一一分析梳理清楚后，在合适的时机向领导提出，若是领导支持，能够申请资源来协助本身进一步改进完善，若是领导暂时不一样意，那这个想法暂时按下不表，等待时机。

反思

没有总结和反思，经历永远不能成为经验，看别人的总结反思像是在看电影，看的时候很爽，看完一抹黑，能记住的很少。不少坑，非要本身跳进去挣扎一番后，跳出坑后，这些总结反思才会深刻骨髓，帮助本身之后再也不犯相似的错误。

在任何工做中，要想成为专业人士，必需要掌握一套良好的作事方法和工做习惯，而这些作事方法和工做习惯，一方面经过本身在工做中不断踩坑、反思、总结，来迭代成长，这样得到的经验教训，每每比较深入。

还有一种是有一个好的导师来带你，时不时给你的工做上给与指导，指导确定是有依据的，所以，如何提供这些依据，就显得较为重要。这里面有两个细节：

第一个细节：本身在完成一项任务时，要记录本身在完成这项任务时遇到的问题，本身尝试的解决方法以及最后采起的解决方法，将这些工做过程有条理的汇总记录，做为导师给与指导的依据。

第二个细节：在向上级汇报时，要主动将工做记录给上级过目，同时，向上级提出要求，看本身在本次工做过程当中哪些地方有改进的空间和地方。