1363 2022-05-01 2022-05-22

前言：个人工作经历中，难免会遇到一些比较意外的突发事件，当时可能处理得当，也可能考虑欠妥。这里，特地趁五一假期空挡，对过往的一些经验亦或是教训，稍稍总结一下，留作纪念。

本文不定期更新，欢迎回顾。

一、与人会议时提前准备

1、什么时候

1. 当自己主持或作为重要角色参与会议时。

2、做什么

1. 提前列出会议大纲。
2. 提前30分钟，模拟会议情景（建议在两次左右）。
3. 整理出重点词组。
4. 问一句：看大家有什么问题或说要补充的。

3、有什么好处

1. 会议内容流畅完整，避免出现卡顿。
2. 组织好语言，提升自己专业素养，留下一个好印象。
3. 最后在征求一下大家的意见，留下余地给其他人发挥。

4、反面例子

• 第一个例子：面试时，面试官让你做自我介绍时，如果你没有准备，那么这个时候，临场发挥的话，就会比较尴尬。这个大家应该深有体会吧，这里就不展开了。

• 第二个例子：这个相信大家也深有体会，1忘记在会上说某个关键点（比如说问其他人要排期，有什么问题忘记拉大家一起确认）；2会上出现卡顿，语言错乱或缺乏相关专业词汇，或多或少会少点印象分。

• 第三个例子：由于准备不充分，被其他人怼（这个真的要看人，有些人直一点，我是真的被怼过好几次，关键是，人家说得还很有理，我还没办法反驳，还好多人看着，emm，丢人，哈哈哈....）。

二、预上线内容前置检查

1、什么时候

1. 进行生产变更时（包括但不限于服务代码发布、服务配置发布，数据库变更等）。

2、做什么

1. 对于要发上线的所有内容，都不要想当然，每一个细节都要确定好，提前准备（如分支合并、打包、配置改动，提交sql等），相关细节要输出文档确定好。
2. 对于域名提前在线上机器ping下，确定好是http或https。
3. 事前艾特相关人员，事后结论同步（不管好坏对错，如果有问题可以延后同步细节）。
4. 对于自己发布的内容，自己就是发布负责人（即使夹带了别人的代码），自己要为本次发布负主要责任。
5. 对于建表sql，要确认好每一个字段的信息，具体包含如字段名称、字段类型、字段说明、字段位置、字段索引（由于建表后对表结构的改造影响过大，因此需要严控把关）。

3、有什么好处

1. 减少犯错的几率。
2. 流程规范，关键事项关键节点及时同步，问题大家一起抗。
3. 责任越大，成长越快。

4、反面例子

第一个例子：这个很常见了，比如说某个配置忘记发布，某个配置内容错误，某个sql忘记发布，或发布顺序不对等，小心驶得万年船。

第二个例子：有一次发布没有在事前同步，事后同步，感觉很有问题，但已经错过了那个时机，又不好纠正，很矛盾。

第三个例子：要有owere意识，在面对问题时，要分清主次，不然容易搞不清状况，不敢承担，给领导留下不好影响。

三、仔细调研需求

1、什么时候

当产品拉开发过完prd时，开发需要对产品需求进行技术调研。

2、做什么

1. 针对每个功能点，要认真梳理出功能实现逻辑。
2. 确认好数据源，及数据源是否满足要求。
3. 确保开发过程中不存在卡点，且数据及代码逻辑是没有问题的。
4. 以上，确定好了再给排期，不要再被产品追着跑了。

3、有什么好处

1. 排期合理，开发顺畅，节奏鲜明，避免延期

4、反面例子

1. PM需求由于前期考虑不全（1漏了造数据这一关键环节；2漏了验证数据的正确性），被产品追着跑，以至于排期不合理且平白加了好多班（错误地评估了工作量），吃力不讨好。
2. 开发进行技术调研时，需要卡一下，严格把下关，对于关键问题及卡点提前暴露，例如DH-LX需求。

最后一条

学无止境，一件事，交给谁来做，其实很关键。对于不同的人来说，大概率都能做得出来，但其实交付质量可能是天差地别的。

对于正处于快速成长的我来说，我觉得下面几点是尤为重要的，也是把一件事情做好的关键：

• 向优秀的人学习，不仅仅是学习技术，更重要的是学习如何为人处世。例如如何把控项目进度，如何推进，如何沟通，如何把控代码质量。
• 勤反思，善总结。对于一件事情，从一个过来人的角度来看，我哪里做得好？为什么做得好？又哪里做得不好，下次改如何注意及改进？下次再发送了改怎么办，可以未雨绸缪吗？

总访问次数: 61次, 一般般帅 创建于 2022-05-01, 最后更新于 2022-05-22