怎样做事才算令人放心.docx

怎样做事才算令人放心.docx

《怎样做事才算令人放心.docx》由会员分享，可在线阅读，更多相关《怎样做事才算令人放心.docx（8页珍藏版）》请在冰豆网上搜索。

怎样做事才算令人放心

怎样做事才算令人放心

在我们的日常工作中，小到回复一个mail，大到负责一个topic甚至多个topic的工作，这些工作做起来怎样才叫让人放心呢？

过程顺畅，结果质量高。

我们每一个工程师都应该具有做好事情的工作习惯和技术能力，千方百计地完成自己所负责的工作，并对做事的过程和结果负责。

工作习惯

从工作习惯来讲，我们每一个工程师都应该具备良好的工作习惯

1.工作意识：

对工作中应该具备的各种意识：

流程意识，质量意识，时间意识，沟通意识等有良好的理解，并时刻体现在日常工作中。

2.主动负责（什么是自己所负责的工作）

凡是与我负责工作相关的事情都在视野范围内。

包括问题追查,解释，模块相关的开发，测试，上线，运维，相关的沟通，技术解决方案，技术共享等。

比如，我负责mc模块，那么mc的上游，下游，运维，出现的bug，其它同事对MC的疑问，MC的设计文档，运维文档，MC的测试以及与mc一切相关的事务都属于我负责范围。

注：

主动负责并不是所有的事情都由我来做，而是负责将这个事情放在正确的人手里去做，我可能是一个桥梁，也可能是一个负责人或者是交与其他人，我只是其中一个参与，需要多人合作完成。

比如有人报一个bug给我，我一看应该是前端的工程师应该负责的，那么我把这件事情转交给前端的同事，请注意这里要确认转交，即前端的同事接招了才算完。

严禁出现：

1.这是OP的事，跟我没关系。

2.我没时间。

3.负责到底,不能不了了之。

严禁出现：

1.我回复了要处理，结果因为没人催，一直没有做。

2.我已经给xx发过邮件了，他没回。

4.主动通报。

不需要指导人/经理/同事经常询问，即自己所负责的工作不需要其他同事来follow。

5.主动沟通。

对疑惑，不理解，需要其他人帮忙，或者有争议的事情要主动沟通。

严禁出现这种情况：

这件事情是xx负责的，我不知道他什么时候能做完。

6.有优先级意识。

不是所有的事情都需要立即处理。

判断为优先级低的事情先给出时间点即可。

7.善于总结

不论是做事方法，还是技术能力，都是在不断地总结中进行的。

在同一个地方跌倒两次是让人不放心的表现。

8.open的合作态度

本着解决问题，做成事情的原则与人合作。

9.对于AOS组的所有同事来讲，产品意识是很重要的。

即：

我所做的东西是要给用户使用的，那么从不同用户的角度讲，这个设计，这个描述，这个解释是否合适？

从用户的角度出发考虑问题。

10指导人

负有培养被指导人的责任，并对被指导人所做的工作负有全面的审核责任。

那么对指导人来讲，能够培养好被指导人的工作习惯，工作方法，提高被指导人的技术能力，同时指导人和被指导人有良好的工作产出，那么在指导方面可以是放心的。

做事的方法：

1.明确目标和资源限制

1.目标分析：

从全局的角度考虑项目的目标，即要做成什么事情，在整体目标中处于什么位置，优先级如何。

2.资源限制分析

人，都有哪些？

时间限制是什么？

指南：

资源，我的经理，我的指导人，组内同事，我自己，以及与我一起合作的其他组的同事，甚至公司内其他部门的同事。

有时候是hr。

所谓有问题及时提出，其实就是把经理，指导人做为资源的一种行为。

2.对事情进行分解，直到包含的每一件事情都有人可以完成。

i.

ii.分解到什么程度

1.分解到每一件事情有合适的人来做这件事，而且能保证质量，按时做成。

哪些地方需要注意

1.模块之间的接口

2.关键事宜：

需要提前沟通确认的地方

3.关键技术点分析:

预研和评审。

注：

不仅仅关注本身要完成的事情，还要跳出这件事情本身，看这件事情在更高层次的意义与目标，

4.最后，给我的资源是否够用，为什么？

时间，人。

--》确认。

在事情分解完成后，进行对比分析，目标可行性，资源限制的可行性，对目标和资源限制进行确认。

沟通：

1.对他人，其他模块的影响2.过程的影响---》过程是为事情的质量服务的，一方面要遵守流程，另一方面不能让流程成为瓶颈。

制定milestone

iii.

iv.

v.

3.执行

1.

2.

3.

4.

5.

6.计划与排期，要有可执行性强的计划。

优先级划定

沟通与确认

过程,保证已经分解了的工作的完成。

反馈与帮助或求助

迭代分解。

4.总结

适时总结，问题是什么，好的经验是什么，等。

什么地方觉得做得不顺畅，关键原因是什么？

给出改善，提出问题。

在以上几个阶段中，分解阶段主要集中在技术负责人身上，而执行阶段则更偏重于项目负责人，即管理角色，但执行阶段项目负责人一旦发现因为技术问题推进不下去，则需要技术负责人的帮助，以便顺利进行，在一般比较小的项目中，技术负责人和项目管理负责人可能为同一人。

在大型项目中，会有专门的技术负责人，这样管理负责人和技术负责人都有责任分清各自的角色，发现任何问题都进行必要的沟通并协调解决。

而非等后期问题集中爆发后才发现。

每个阶段，负责人都本着一个原则：

完成项目的目标，对项目的时间，质量，成本以及过程进行保证。

事情分类：

日常工作中的事务包括但不限于以下几类工作。

对如何做这些工作做了一下总结，各位aoser也可以加入自己的心得，未尽事宜请参考工作习惯和做事方法。

1.BUG或问题追踪

a）目标：

定位bug，分析原因，给出改进方案，给出何时完成。

b）分解：

一般情况下有几种情况。

i.这个bug明确地是我负责的范围内产生的。

1.若不能很快定位原因，或者目前有高优先级任务，那么首先回复什么时候进行定位

2.定位后回复原因，进行影响分析，以及改进方案和时间

3.进行修复时和修复后进行通报

ii.明确是另一模块产生的

1.回复说明，并请下一位同事接招并确认负责人的变更。

iii.不确定。

1.同样需要回复目前的状态，以及计划。

2.进行follow。

2小型项目升级：

1.总则：

我负责在什么时间内完成该项任务，我的开发计划是….，预计什么时间会上线，我需要与哪些人沟通和确认……，沟通和确认的结果是什么，对项目计划有什么影响…，谁会关心这个项目，我应该什么时候进行进度的通报…..，上线的结果是否与预期相符，通报给谁…..这个项目中遇到了哪些问题…..，如何改进？

这个项目中处理得好的地方是哪些…..，如何推广？

2.目标：

项目的目标，分析这个项目在整个产品中的地位，以便从全局上把握。

3.分解：

一般来说，这种项目只涉及到一个人，这里的分解，则是分解到每一个功能点都能详细估计出时间，能够识别出其中的关键技术点，可预见的难点，以及需要提前与他人沟通的地方。

4.执行：

按照分解出的工作制定出相应的开发计划、沟通计划、测试、上线等计划，并有细化的开发计划，详细设计初稿，审核，定稿，代码，单元测试，代码审核，提交测试，书写上线单等，以及相应的沟通任务：

设计评审，测试沟通。

i.进度报告与不断调整的计划，以及对相关事宜的影响分析。

ii.沟通的mm

iii.发现的问题并报告出来

iv.上线计划

v.上线效果确认与通报

3.跨模块项目升级（跨模块，也可能跨组）

1.目标:

i.整个项目的目标是什么

ii.各模块需要做哪些工作（具体的目标）

2.分解：

（技术负责人）

i.分解到各模块的职责

ii.接口说明

iii.各模块的分解（由各模块负责人进行分解）

3.执行（管理负责人与技术负责人共同协调进行）

4.总结技术上的总结，指导方面的总结，沟通方面的总结等。

4.topic规划与推动

1.目标：

i.远景是什么？

在所有的topic架构中的位置如何？

范围内是什么？

ii.中期目标是什么？

在多长时间内达到

iii.近期目标？

iv.近期目标分解

分目标是什么？

分成各个子项目，进行每个子项目的描述，尤其注意每个子项目在全局中的位置，与其它项目的联系。

2.资源限制：

i.有几个人？

都处于什么样的水平？

能够做什么事？

要分解到什么程度才能顺利完成任务？

ii.时间如何？

怎样排优先级？

iii.周边的资源如何？

处于什么水平？

3.分解：

i.本topic内部分解：

本topic内部从目标到实现的步骤分解

1.整体上的目标分解为哪几个分目标？

各分目标优先级如何？

如何实现？

a）细分-》细分，直到有人可以完成这个目标。

ii.与其它topic交互部分的分解

iii.如何在topic的目标理解上达成一致

iv.分解到每个人每天的事情。

确保分解到该人所能做到的阶段。

v.确认关键技术点，milestone,需要提前沟通的事宜，相关topic的协助等

4.执行。

i.在执行中，把自己作为整体的负责人去推进topic目标的完成。

ii.执行是一件相当关键的事情。

要有方法还要有meet时间点的技术能力。

2.首先计划要详细到天，具体可执行性，输出需要具体化，如调研的输出要求是a,b,c,d等。

3.要具体，每天进行对比，及时meet时间点并进行及时的指导和跟进。

4.协调前进：

判断不在我周边的资源，是否能够有效地meet时间点并进行有效的跟进。

所谓有效地跟进是1.确认是否达到了进度要求2.如果没有达到，分析原因，提供相应的协助。

如果在现有技术/时间条件下不能达到要求，要及时进行调整。

5.沟通与确认

a）有效地沟通，达成一致，而不只是通知到，或者我认为如此，而是我确认如此。

……..

5.总结：

i.不断地总结是非常必要的。

在topic的计划推进中，会发现许多问题：

1.工程师协助：

环境上的困难，工具上的困难，沟通技巧上的困难，流程的困难等

2.设计能力上的提高：

第一版设计和最后一版设计有哪些不同？

与最后代码有哪些不同？

为什么？

3.计划能力的提高：

同样的，我们计划与实际的相差多少，都是什么原因引起的，经过哪几次调整？

等

4.流程上的改进：

流程是否阻碍了我们的进度，为什么？

有更好的安排么？

5.分解的细致程度……

6.优先级的判断

7.团队合作的理解

5.多topic的合作（多topic的合作在具体的操作中还是比较复杂的）

1.目标：

i.各topic的目标是什么

ii.合作的目标是什么

iii.各topic分别的职责是什么?

2.资源限制

i.各topic可以给出的人力如何，技术水平？

3.分解工作

i.目标分解后，可在本topic内部分解工作

ii.定义各topic之单的接口，接口人，职责

4.执行

i.计划-》执行->按实际情况调整（包含适时的总结）