标签：何事 总结 敏捷开发 校验 没有 str 基础上 stat 锻炼
最近跟一个阿里的朋友聊到关于程序员如何把事情做得更好，他提到了很多在阿里的感受，让我受益匪浅。
所谓“如何把事情做得更好”，就是跳出写代码这件事，如何把我们的工作做好，获得更多的个人成长，获得更好的绩效考核结果，并能在其他人中脱颖而出。
思维碰撞下，得到了很多有效的信息，总结为三个方面的“管理”能力，目标管理、过程管理、向上管理。
相信每个人看完都能有所启发。
所谓目标管理，分为两个阶段，提出目标 和 管理目标。
目标管理的前提，是必须先能够提出一个足够有价值的目标，然后再进行达成。
如果目标本身是没有价值，或者说价值很小的，那即使你花费了很大力气去做，然后达成了，也没有什么意义。
跟莫斯科一样，程序员也是不相信眼泪的。苦劳再多，也比不上功劳。
那如何能提出一个足够有价值的目标呢？
1）来源于自上而下的任务拆解。
经常看到有人在各种社区吐槽华为的“拉通对齐”。但实际上，抛开某些管理者具体执行层面的问题，“拉通对齐”本身是非常有价值的。
公司的管理者在更高的位置，利用更多的信息进行决策，然后获得明年公司的发展目标和方向。然后就是将目标拆解到各个部门，各个部门需要相互合作达成目标。作为个人，也会承接到部门内的子任务，这个时候，可以提出自己的一些想法进行讨论，在充分沟通的基础上，应该达成一致，然后坚决执行。
那么这时候你的目标，就是跟部门目标是一致的，跟公司的大目标也是一致的。
如果你能很好得达成目标，或者说超出预期，那么你对部门和公司的价值就是越大的。
2）来源于自下而上的问题发现与解决
经常可以看到各种社区有人提问，每天CRUD怎么才能提高？
其实这个问题的一个解决思路是，在工作中发现问题，并给出解决方案。
我举一个我们公司的真实案例。
一个后端开发同学，发现自己组内的业务需求经常会有很多离线任务要做。有的人直接使用spring的Async注解，有的人自己新建申请一个线程池塞任务，有的人利用redis的blpull/blpush来做队列来进行生产消费。
没有统一的方案，有很多重复劳动，而且容易因为种种原因造成故障（比如没有资源隔离）。
因此，他提出了一个目标，做一个分布式的统一任务调度框架，解决组内的这些问题。
目标达成后，还在全公司进行了推广。
后面的结果大家应该能猜到了，升职加薪走上人生巅峰。
有人说，你这个肯定是小厂啊，大厂各种工具都很成熟了，没啥要做的。这话说对了一半，大厂的成熟工具和框架确实很多，但也是其他人发现并且实现的，而且我相信没有任何一个公司或者部门，在任何事情上都已经做到完美，总会存在问题和不足的地方等待解决的。
已经有了一个很有价值的目标了，我们该怎么达成呢？
这时候，我们就需要对目标进行管理。
我个人认为最好的方式是“倒排时间”的milestone(里程碑)模式。根据目标deadline来往前倒排时间，拆分不同阶段的里程碑节点，然后按期检查当前进度，最终达成目标。
其实也不是什么新鲜玩意，很多公司都有在做，但是落实到具体部门、小组、个人上，就不太一样了。
尤其我想说的是个人和小组上。
在我担任敏捷小组的SM（scrum master）期间，发现很多同学对于这种方式的计划能力都有所欠缺。
主要有两个方面的问题。
1）估时问题
如果今天只是一个写sql的任务，很多同学能准确的估计大概要花费几分钟。但是如果是一个半年或一两个月的项目，让你以月或周的粒度进行拆分，很多同学就比较难把握了。这个其实不是什么大问题，主要是经验不足，无法深刻了解到项目中的模块拆解粒度与技术难度。
那怎么做呢？有三个建议
2）进度意识
有了明确的里程碑和时间后，我们还需要在执行过程去及时检查进度。
比如以周、月为单位，来检查自己或者跟进合作者的完成进度。
如果发现有延期风险，那么就需要提前进行风险暴露，想办法解决问题，加快进度。正如上文提到的，如果估时有一定buffer，那么更加容易转身，否则，只能通过加班来达成目标了。
以前在做业务开发的时候，产品、前端、后端、测试等角色关联非常密切，因此在敏捷开发过程中，会需要通过每天的站会来沟通进度，及时暴露风险。
现在在做基础架构相关的工作时候，可能项目的周期会更长，比业务开发的敏捷迭代周期要长很多，因此，往往会通过周为单位的进度分享。
只有按时完成每个里程碑节点，我们才有信心按期完成整个目标的交付。
具体的实施，每个公司可能都有自己的目标管理系统，我这里做个简单的表格，更直观地反应如何对目标、里程碑进行管理。
如果说目标管理是我们完成任务的基本要求的话，过程管理可能是我们获得“超出预期”评价的重要部分。
我觉得最好的方式是，在任务DOD（Definition of Done）的基础上，你有自己独有的一套“过程性DOD”。
一般我们任务的DOD是按照一定时间要求，完成什么功能，上线什么需求。有的可能会带上一些性能指标，比如接口响应时间低于多少，线下故障数量低于多少等等。
那么如果只是完成了这些要求，那么今天你来做这个事情，和另一个人来做这个事情有什么区别呢？
甚至于如果某个项目，最终由于种种原因没有上线，或者中途被终止了，那么是不是你所做的事情都白费了呢？
所以，你必须有一套自己的“过程性DOD”。
下面，我介绍一些我的经验和我见过的大佬们的经验，大家可以按需取用（业务开发和基础架构开发还是有很大不同的，尤其在迭代压力和做事方法上，所以不能一概而论）。
1）完整的调研报告
任何一个任务，都有常规方案和优质方案。就像我上面提到的那个分布式调度系统，普通同学可能就是按照自己的理解，搞个能用的方案就行了。但是优质的方案，肯定是跳出自己的眼界范围，博采众长的结果。
因此，在确定技术方案前，最好能先去调研一下业界的主流方案，看看别人是不是已经有了比较好的解决方案了。
然后把你的调研结果形成文档，这样不仅能增长你的技术视野，还能体现你的良好技术思考力，这是非常重要的过程性内容。
2）完整的技术设计文档
在确认了技术方案后，一般需要做一个比较详细的技术设计方案。
面向数据库编程？面向SQL编程？面向对象编程？面向领域编程？
这些都是需要在技术方案设计的时候仔细思考的。
一个好的技术方案，能锻炼你的技术思考力，能指导你后期快速、高质量地进行开发，也能在你以后进行维护的时候，告诉你当时为啥这么想。
通过不断地技术设计、开发、反思，才能学以致用，快速提高技术水平。
3）问题积累与解决方案
问题一般有两种。
一种技术问题。包括开发过程中遇到的问题、线上故障解决等，你在解决这些问题后，将排查过程与解决方案进行记录，形成BP（Best Practice，最佳实践）文档。然后可以跟其他同学进行分享和推广。这样你不仅能沉淀自己的经验，还能慢慢形成一定的技术影响力。
另一种是业务问题。在做基础架构的同学，往往会觉得自己陷入运维、客服的怪圈。一种好的解决方案，是将日常繁琐的运维和客服问题进行积累记录，然后努力通过技术手段去提高效率自动解决类似问题。
举一个例子。过去我们公司的数据库升配都是人肉进行的，业务方提出工单申请，然后审批，然后去找dba进行沟通，确认升级时间。然后到时间后，大家需要再次沟通确认业务是否处于流量低峰，是否可以开始升级。然后升级完成后要进行检查，沟通确认已经完成。
后来，有人提出了自动化解决的方案，通过打通工单系统、数据库管理系统、内部通知系统，将整个流程自动化，提效几十倍。
4）方法论产出
一次项目上线后，对很多人意味着结束，但对很多人来说，只是阶段性胜利，更重要的是方案论的产出与推广。
如果一次资源的投入和探索只能产出一次结果，那性价比是不高的，但是，如果有完整的可复制的方法论产出，那么这一次投入和探索的过程可以给未来的无数次探索提供指导建议，甚至于能够快速复制，那就是极高的投入产出比。
对有些更优秀的人来说，可能产出方法论之后，还能从中找出共性和特性，沉淀为平台化的产品，那就是更加的niubility了。
举一个例子。之前公司做个一个分库分表的项目，项目上线后，项目成员写了完整的方法论指导，在公司进行推广分享。还将项目过程中使用的数据校验工具，平台化为技术产品，方便其他业务线能够快速使用类似的功能。这种就是非常好的范例。
方法论的产出，无论对于公司还是对于个人成长，都是绝佳的方式。
过程管理的产物，能很好地体现在结果上。同样一年完成了几十个需求，年底review的时候，你只完成了需求，而别人沉淀了几十篇设计文档、最佳实践、方法论，并建立了一定的技术影响力，你可能就是B，别人就是A，这样的差距就是由于过程管理造成的。
而且更重要的是能沉淀你自己的学习与思考，这是个人成长非常重要的部分。即使最终由于各种各样的原因，在结果导向上没有一个好的成绩，这些过程管理的结果都是你最重要的财富。
一个五年程序员是拥有五年经验，还是一个经验用五年？过程管理往往能告诉你怎么做。
这部分的内容不多，但是可能比上面的所有内容更加重要，也是大部分程序员容易缺失的思维方式。
所谓“向上管理”，不是说拍老板马屁。而是一种有效沟通方式，一种科学的上下级合作方式。
有了良好的“目标管理”和“过程管理”后，有的人可能会陷入闭门造车的陷阱，按照计划或迭代不断埋头做事，这是万万不可取的。很多同学容易陷入一种误区，我专心地完成手上的工作，就可以了。但其实这往往是最危险的。因为即使你全部做完了，也可能只是达到要求，没有任何亮点，甚至于由于外部的变化你没有及时获取，还做错了方向。
我们还是需要及时主动跟老板沟通，沟通自己目前的进度、困难、计划。让老板能及时知道你现在的进展情况。
很多时候，当老板来找你的时候，往往不是什么好事。要么就是你做了什么错事，要么就是他想知道你在做什么，做到什么程度了。无论哪种情况，都不好。
阿里的朋友跟我分享了一些比较好的形式。
做事的方法真的很重要，尤其是我们程序员，可能过多地与电脑打交道，而容易缺乏技术外的非技术思维。而好的非技术思维，能帮助我们更好地自我成长，更好地脱颖而出。
与大家共勉～
看到这里了，原创不易，点个关注、点个赞吧，你最好看了～
知识碎片重新梳理，构建Java知识图谱：https://github.com/saigu/JavaKnowledgeGraph（历史文章查阅非常方便）
扫码关注我的公众号“阿丸笔记”，第一时间获取最新更新。同时可以免费获取海量Java技术栈电子书、各个大厂面试题。
标签：何事 总结 敏捷开发 校验 没有 str 基础上 stat 锻炼
原文地址：https://www.cnblogs.com/awan-note/p/12637267.html
