2019-09-10再次请教宝玉老师：对于一个研发部门，一次性入职300+的新员工（原来老员工近700人），可以通过哪些环节的哪些手段，来加强对新员工的研发质量管理，以免出现新员工频频挖坑的情况？作者回复: 对于大量新员工加入的情况，我建议可以从多个方面入手：
首先是人员的培训方面，有相关的入职培训，新人入职后能快速了解整体的开发流程、规范，新人入职后有指定的Mentor（师傅），在遇到问题时知道该找谁。
然后是项目的开发流程方面，多花时间在流程建设上。具体体现在：
- 整体的项目流程是基于软件工程的标准开发流程的，并且适合你业务特点的，比如说敏捷、迭代或瀑布
- 对于关键环节要有审查，比如设计方案的评审，比如代码合并前的Review
- 要有规范的代码开发流程，比如我多次提到的Github Flow，基于分支开发，代码审查通过并且自动化测试通过才能合并主干
- 要应用好工具，有一定量的自动化脚本和工具辅助，比如说Git，CI/CD的应用，日志数据的收集和监控等。如果这些工具的应用还不够到位，作为一个近1000人的团队，应该成立专门的小组去实施，去做针对公司业务的定制化，去帮助其他团队实施和推广。
再有就是团队组成上，要形成梯队，一个健康的团队，应该有资深的工程师、架构师，有中间的丰富开发经验的工程师，有新手程序员。对于资深的工程师，应该鼓励他们把一部分精力用在评审和帮助新人上，多参与设计的Review和Code Review，帮助团队一起成长，从而实现个人的成长和整个团队的成长。
最后就是对于整个组织架构和技术架构要有针对性设计，一个公司的研发团队目标是满足公司业务需求，这些业务需求又是有各个大大小小的项目组成的，这些项目之间有共同点，有不同点，需要有团队有人能站在整体去思考去设计整体的业务架构，提取公共的架构和服务，将复杂的业务能化整为零，拆分成和组织架构匹配的技术架构，或者按照技术架构去调整组织架构。简单来说就是你的技术架构和组织架构要是匹配的。
比如说你可以把整体的技术架构设计成为微服务的架构，整体组织架构也可以拆分成一个个小的业务小组，一个小组专注于一两个微服务，各自独立维护和发布。这样新人加入，不需要了解整体繁复的架构，只要先了解所属小组的服务架构，就能快速的熟悉业务，快速上手，就算挖坑了，也不会影响太大。 4
2019-05-17请问宝玉老师:
我现在遇到一些情况，需求出来了，估时的时候，通常有两种心理
第一种: 尽量压缩自己的时间，当然领导也会压缩时间， 这时心里想的是要好好表现，把时间压短一点
第二种: 尽量多一点充裕时间，当出现问题能有足够的时间来解决，不至于延期
第一种优点是，估时的自己心里畅快一点
缺点是: 经常因为特殊原因延期，，印象分就越来越不好
第二种优点是基本上不会延期，有时候还能空一点时间来做项目优化，，但是这个时候要抗住领导压时间
现实场景肯定会更加复杂，有时候紧急需求都是高一两个层级的管理直接下发紧急需求，越快越好，，这个时候时间估短了容易做不完，，长了会被质疑能力问题。（个人感觉了）
我目前主要采用第一种，但是我发现自己做的事很容易延期，为了做好，我就有了更多的加班
和我行程鲜明对比的一个同事，他估时就是第二种，尽量多一点时间，估时的时候长，，，但是整体有保证，，然后领导对他的信任程度比我高一些（我拿了年度最佳担当奖），
对于这种估时，取一还是取二还是如果在一和二之间平衡，
不知宝玉老师有什么好的建议和观点呢展开作者回复: 太紧和太松的时间估算都不可取，应该是尽可能准确的接近实际情况的时间，并且留有一点富裕应对意外情况。
时间太紧了要加班加点还要被质疑能力；时间太松了会影响以后估算时间的真实性。你同事的估算时间应该不是偏松，而是接近实际情况的时间，你可以向他请教经验。
准确的估算时间是程序员能力的一种，做好不容易，一些建议供参考：
1. 充分理解清楚需求，知道要做什么，这是基本前提，不然做着做着发现需求没搞清楚，那一定是要多出很多额外时间
2. 非功能性的需求，比如说写自动化测试、搭环境、重构代码这些任务也应该作为计划的一部分，要把时间算进去
3. 拿到任务后，将任务要分解到尽可能细，越小的任务力度估算越准确，而且在跟领导说时间进度的时候也有理有据，底气足扛得住
4. 综合考虑任务并行的情况，给线上版本修bug、开会这些时间也要算进去，想想每天真正有效的工作时间是多少？
5. 计划保持及时更新，当出现延迟或者有延迟风险的时候，或者进度提前，需要及时和项目负责人沟通，作出调整，避免影响整体项目进度
6. 留一点余量，应对突发情况
反过来，如果你是领导，在下属估算时间的时候，也要参考上面的一些建议，让计划尽可能的接近真实情况，而不是下属给一个很紧的时间就按照这个时间执行，最后得加班加点，加班是为了应对突发情况的，而不是正常情况。 4- 2019-04-29请教宝玉老师：软件工程领域，如果要“树精品意识，扬工匠精神”，有什么思路可以建议，感谢老师解答！（我们现在采用瀑布研发模式，部分条线实现了CI）
作者回复: 精品，其实核心是要小要精，所以你要考虑让产品需求需求小而精，让团队小而精。
工匠精神这已经超出软件工程范畴了：） 3 
2019-04-25非常感谢宝玉老师的每一篇文章，逐渐完善了我在软件工程方面的知识和应用。
我觉得高效，意味着自律，自律的好坏是可以通过你散发出来的气息让周围的人感受到的，比如：说话有没有条理，做事拖不拖延等等。生活自律，你会发现每一分每一秒都充满了希望和力量，用积极乐观的心态去完成每一件事，知道自己上一步做好什么，下一步才能做好什么。工作也是一样，要想高效的完成任务，需要利用前辈们总结的思想和方法，去长期实际应用，在使用的过程中就会体现出你的高效，不能说我知道单元测试，我知道CI...，很少有人讲我一直在用。
如果我们注意观察，会看到身边的同事，有的很少加班（活蹦乱跳），有的经常加班（蔫头耷脑），做了一样的事情用了不一样的时间，此时就能真正的体会到高效做事的魅力了。我不提倡加班的原因就在于此，但那是针对高效人士的，低效人士不加班，老板是不会答应的。而一般对自己的时间把握比较好的人，在估算工作时间或工作量的时候，都比较果断，不会支支吾吾，还会主动给出具体时间点和阶段性成果，让人觉得这才是真正做事的人应该有的态度。
我的看法是，积极、主动、自律是高效人士的必备素质。展开作者回复: 感谢分享！
👍自律的收益之一就是让你可以专注，比如不会经常刷个微博摸个鱼啥的：）还可以保证自己有更多时间去练习技能。
高效是个正循环，一旦开始高效起来，就不愿意低效率的做事情。 3
2019-09-21要事第一，我也尝试过，往往我忙时别人闲，我闲时别人忙。另外作计划，往计划敢不上变化，中间总有意想不到的事情发生，如何处理？作者回复: 可以参考文中“要事第一，把时间用在刀刃上”：
按照“紧急重要四象限”对事情进行分级，然后优先处理紧急重要的事，然后处理不紧急重要的事。紧急不重要的事情可集中处理。 1
2019-04-30谢谢老师分享宝贵经验！积极主动、以终为始，要事第一。和吴军老师说的“不做伪工作者”很像！作者回复: 👍吴军老师很多道理讲的特别好，比如把事情做好的三条边
1- 2019-04-26我记得有本极其经典的书叫《人件》，对如何提高效率，讲了很多方法。比如，办公室的布置。我自己的办公室就是按照《人件》的建议，在办公桌和门之间，放了一个隔断，这就可以让我在工作的时候，不会受外部的干扰。
作者回复: 没错，人件是很经典的软件工程书
1 
2019-04-25老师，有没有事情管理的工具？因为如果不记录下来，一会儿就忘记了。作者回复: 楼下的McCree同学推荐了滴答清单。
我个人的话，一般就用系统自带的记事本记一下，或者贴一个便签纸在显示器。如果时间跨度长，我就记到Calendars上，加上提醒。
工作中的任务，我则会创建成Ticket。 1
2019-04-25设置番茄钟，单次20分钟每天3-4个，关注微信、邮件通知、免打扰。
利用状态最好的时间解决重要紧急问题。
重要不紧急问题优先制定解决方案，定番茄钟解决。
紧急不重要的问题，看优先级集中解决。
不紧急不重要的问题，零散时间解决。作者回复: 👍谢谢补充
1- 2019-04-25积极主动、 以终为始和要事第一重新确立了我的工作原则，我也从中收益较多。
作为程序员，的确会经常被日常的杂事所打断，没有整片时间来专注于写代码，我们能够奢求的，就是要做最重要的事情，其他的事情不要去做！作者回复: 是的，仔细想想，一天的上班时间，其实做不了多少事情，能把最重要的事情做好就不错了
1 
2019-04-25后面互赖圈的三点也很重要，比如双赢思维特别适合，努力工作，提升自我，与公与私都是双赢作者回复: 《高效能人士的七个习惯》是一本非常好的书，值得学习。
1
2019-04-25每次开发前先想清楚如何实现；核心接口做单元测试全覆盖；作者回复: 👍是的，想清楚做什么特别重要。
除了单元测试，建议还可以配合一些集成测试来测试接口的调用。 1- 2019-12-31我以前是给每天做的事排优先级，根据难易程度，完成时间长短，重要程度，综合后排序，同时把能快速不占用太多时间的事处理完毕，集中处理其他的事，用桌面便签做记录提醒
作者回复: 👍
另外把日历提醒用起来也是个不错的方式，不容易忘事 
2019-10-01谢谢老师，时间四象限实在太棒了👏🌟作者回复: 🤝
2019-05-07最近一直在用番茄时钟，中间还可以稍微休息一下。把现在的刻意练习逐渐变成习惯。作者回复: 👍养成习惯了就容易多了。
2019-04-25楼上的，滴答清单作者回复: 🙏感谢推荐