这近4个月，我见到了大海。
有幸能和这个行业最优秀的一群人共事过。团队大多都是P7的大佬，各个方面的能力都非常强。
在这段时间里，自己最大的提升就是软技能方面。如何写日报，如何写周报，如何写系分，如何有效的沟通，如何把控自己的任务进度。大佬们的言行，对自己技术观和自我认知都有很大的帮助。做一名工程师的提升，眼界的提升，人的提升。
关于日报
写日报对很多人来说是件很痛苦的事情，而且容易出现写着写着就记流水账了，那这样意义不是很大。
我所在团队的日报模板：
任务 xxx: 简要的描述任务事项(名称要达成一致所有人看得懂).
整体进度: 设计中/编码中/测试中/已完成
风险: 无/ 低: 风险描述 / 中: 风险描述/ 高: 风险描述
- 任务分解1: 分解的任务细项, 比如: 熟悉技术资料, 预计 1 日, 实际 1 日, 已完成.
- 任务分解 2: 分解的任务细项, 比如: 方案验证与详细设计文档编写, 预计 1 日, 进行中, 遇到 xxx 问题, 需要协助.
_
做了什么不重要，重要的是做这件事情的结果是什么？是否符合预期的产出结果。做这些事情的感悟，遇到的问题。产出结果最好可以量化下。
总之日报对于阅读的人来说（一般是同事，领导），可以让他们了解你现在的进度，有风险是否需要介入进行帮助。应该少用模糊词，例如：应该，可能，大概之类的。
切记不要流水账！
关于周报
摘自 @玉伯 对周报的看法：
说下我的想法，无论做产品还是写周报，都需要能站在用户视角去思考，比如写周报，要思考周报的阅读者是谁，我的周报能给读者提供什么有价值的信息，怎么样让读者有收获，这是最重要的。
回到具体例子，对于写在这个语雀讨论区的周报，读者就是大团队的同学，由于很多同学都是在不同业务线做着不一样的事情，这时，项目进展如何，修复多少个缺陷等信息，并不能给除了 TL 之外的同学带来帮助，反而是如何解决某个问题，如何思考某个技术点，这些偏专业思考分享总结的东西，会让更多读者收益。
因此，建议大家写周报时，可以有两个视角：
写给 TL 看的：言简意赅说明事情进展、风险等情况就好，这时采用 @早弦 总结的突出重点、结果优先、惜字如金是非常非常好的，写给 TL 看的一定要简单清晰，一语中的就好。这其实就是周报的 “本周工作” 部分。
写给同学看的：同学同学，就是共同学习。这时的写法，尽可能过程优先、分享思考优先，惜字如金也挺好的，但更重要的是思考总结，甚至是情感化表达。
这一块，就是周报里的“想说的话/感想思考/墨者修齐”等部分，可以多写写，愿意分享的人，自带光环。
另外还有：
- 可以写做了这件事对于整个任务的意义所在，例如做好了xxx，可以和xxx进行联调了
- 风险要在日报中暴露出来的，周报应该是风险的跟进情况
- 自己遇到的问题，出现的错误点在哪里，也可以分享，给其它同学作为参考
- 下周要做的事情，这个倒是可以记下流水账，越详细越好
做任何事情带着做产品的思维，人人都是你的用户，想别人之所想，这是高手思维。
需求系分
原来都没有写过系分，更不知系分是何物。在写过几个系分后，在我看来系分的意义在于：
- 体现自己的设计思路，让组员或 TL 可以看到，一起 review 下有什么漏洞缺陷；
- 文档记录是可以沉淀下来的，可以给后人作为一个参考
- 减少很多的沟通成本
- 对于时间的预估也有好处，工期可以预估的更准确
明确了系分的意义所在，那么围绕这几点写可以了。具体的细节有很多，但这几点是必须且重中之重。
- 本次系分的需求是什么？需要描述清楚
- 可能出现的问题，对现有业务的影响
- 设计详细方案，精确到方法级别
- 质量上有三点：灰度，上线监控，代码回滚
关于沟通
少废话，直接说问题，直接要结果。
其他一些点
- 对于需求, 梳理的越完整越清晰越准确, 也可以在早期对焦并暴露风险;
- 留出 buffer, 初期 buffer 可以留的稍微大一些, 相比时间消耗长, 时间不准确的影响更大;
- 拆成小的里程碑, 不断迭代, 走走停停, 逐步改善;
- 和人沟通要温和，情绪不能解决问题，负面情绪沟通，用文字来表示，语言沟通反而让人情绪高涨
- 不用高高在上的眼光看人，要尽自己最大的能力多去帮助别人，因为你们是一个team
- 谋定而后动，先写好计划系分文档，可能遇到的困难挑战，最坏的结果是什么，再去做这件事情
- 领导是lead，而不是leader，是带领的作用
若有收获，就点个赞吧
0 人点赞
