这个文章是接前一个文章的,本来是一起的,但是贴不下,就另外开一个文章了。这篇是讲一些技巧的,虽然不是严格的规则,但是使用这些技巧将让你从合格转向优秀。
<!----><!----><!----> <!---->
工作技巧
1.
及时回复
及时的回复向你寻求帮助的人,可以给人一个好的的印象,同时也可以减少一些不必要的麻烦。
例如:有一次
Lucky
发邮件要求所有
team
leader
协助她检查
FRD
,
FSD
和
DSD
之间的
gap
。结果邮件发出后,只有
Hikelee
回复了她的邮件,告诉她会尽快完成任务。事后
Lucky
曾多次公开赞扬
Hikelee
的这种良好的行为习惯。
Winter
在负责督促检查
Document
任务完成情况前,也没有觉得及时回复别人
To
给他的邮件有多么的重要。直到他负责了这项任务没人回复他的邮件后,他才深切的体会到原来及时地回复邮件是多么的重要。这不仅是个礼貌的问题,可以减少很多的沟通成本。
此外,及时的回复邮件还可消除发件人的顾虑,避免一些不必要的麻烦。
Andrew D
有一次要求我帮他增加一项
Filter Service
的功能来演示给他给客户看。当时我因为工作忙,没有在立即回复他我们已经在讨论
Solution
,
Impact
和
LOEE
了。结果
4
天后,他开始向我的领导们抱怨我没有受理他的请求。可见及时回复邮件的有多么的重要。
2.
消除或减少不必要的
Wait
和
Rework
我们的
Team Leader
应该学会发现和总结我们的组员在哪些方面或什么情况下容易造成不必要的
Wait
和
Rework
。
Case by case
的教导他们主动沟通,分清轻重缓急和如何提高工作效率。
逐步建立和完善现有制度和流程,把我们的流程和经验记录到
wiki
中。
下面有些实际例子以供参考:
例
1
:如果讨论一个问题时,在场的人没人能够最终拍板时,应该在问题得到澄清后立即停止。找到有仲裁资格的人裁决,而不是无休止的争论。
例
2
:最近一段时间每天早晚都有很多人等着在
VSS
里录入
bug fix
计划和
bug
完成情况。等着别人
check in
或时时惦记着去检查是否可以都不是最好的办法。
此时,我们可以先发邮件
TO
给主管
bug fix
的
Saul
,
CC
给
PM
和自己的组员,尽早通知到所有相关人员。然后在一个比较空闲的时间再去更新
bug
tracking sheet
。
3.
提供机会锻炼组员的表述能力
我们应当多提供一些机会锻炼组员的表述能力。例如让组员自己讲解
DSD
,自己做
Demo
,自己准备一些
training
给大家。
但是事先应当提前告知,让其做好充分的准备。以免达不到效果,还让组员觉得我们是有意刁难他们。
4.
要请别人帮忙就要站在对方的立场上来考虑问题
例如:最近有一个
Abu
Dhabi
的
ASI Table
Share Drop Down
的
feature
。
Jerry Lu
认为现在的
solution
不好,要求我们
roll back
已完成的代码,并在当前版本内按照新的
approach
做。
我经过细致的分析和比对发现
Jerry
Lu
的
solution
的确比现在的
solution
高明的多。但是因为临近
release
而且重构的代码改动量比较大,所以最好是推迟到下个
release
从做这块的代码。
为了说服
Jerry Lu
同意我的观点,我首先站在他的角度去想他可能会问到哪些问题,如果不同意他的主要顾虑是什么,他需要知道哪些信息才可以去说服其他的人?
带着这些问题和预先准备好的答案,我晚上找到了
Jerry Lu
。先告诉他旧的
solution
的弊端有哪些,新的
solution
好在哪里,
Jerry
表示这正是他决定弃用旧的
solution
的原因。然后我告诉他要按照新的
solution
我们做需要做哪些方面的工作。这时
Jerry
意识到现在改代码的风险较大,但是他又担心如果不按新的
solution
做,旧的
solution
又不能满足客户的需求,而这个功能又必须要在
6.7.0
提供。我告诉他旧的
solution
也能满足客户最基本的需求。
听到这里
Jerry
说他已经同意
postpone
了,但是还需要想办法去说服
Andrew D
。我就告诉他,不用担心,我们有办法可以在后续版本中删除旧
solution
的代码,同时还可以将旧的
solution
自动切换到新的
solution
中。这样我就帮助
Jerry
找到了合适的理由去说服
Andrew D
。
分享到:
相关推荐
华为java编码军规,经典编码风格规范。极大提高你的编码能力
2. **注释规范**:良好的注释能够帮助其他开发者理解代码功能。华为规范要求每个类、接口和公共方法都应有注释,注释应简洁明了,描述功能、用途和使用注意事项。 3. **代码结构**:代码应遵循一定的组织结构,如...
华为 Java 编程军规 华为 Java 编程军规是衡量代码本身的缺陷,也是衡量一个研发人员本身的价值。该军规共十条,涵盖了编程中的各种细节,旨在提高代码的可读性、可维护性和可靠性。 军规一:避免在程序中使用魔鬼...
征服英语的33条军规 征服英语的33条军规 征服英语的33条军规 征服英语的33条军规 征服英语的33条军规 征服英语的33条军规 征服英语的33条军规
SQL类军规则是数据库开发中最为具体的一类,涉及到SQL语句的编写技巧。这包括了避免使用大事务、大SQL语句和大批量操作,因为这些都可能导致数据库性能下降,甚至造成灾难性的后果。在SQL类军规中,还提到编写高效的...
这三十六条军规主要围绕数据库的高性能、稳定性以及开发者的实践操作,涵盖了核心军规、字段类军规、索引类军规、SQL类军规以及约定类军规五个部分。在详细介绍这些军规之前,有必要先了解下MySQL数据库开发的一些...
2. **使用CDN(内容分发网络)** - CDN可以通过在全球范围内分布的服务器节点来缩短用户与服务器之间的物理距离,从而提高资源的加载速度; - 实现方式包括但不限于镜像、高速缓存和专线连接等。 3. **为文件头...
十大军规培训.pptx
2. 字符集选择: - 必须使用UTF8字符集,特别是UTF8MB4。UTF8MB4支持所有的Unicode字符,无需转码即可避免乱码问题,并且可以节省存储空间。 3. 数据库对象命名规范: - 数据表和字段应加入中文注释,避免未来...
这份军规的内容涉及核心军规、字段类军规、索引类军规、SQL类军规以及约定类军规等多个方面,现在我们来详细解读这些知识点。 核心军规强调的是实战经验的重要性,指出背后的教训是用血的代价换来的,要求实用而非...
### 移动APP测试的22条军规 #### 一、设备和平台 1. **操作系统**:针对不同的操作系统(如iOS、Android),需要确保应用程序能够在这些平台上正常运行,并且能够兼容各种版本的操作系统。 2. **设备硬件**:考虑到...
mySql36条军规 主讲Mysql规范和优化对程序员很有帮助。
无论对于新手和高手,都必须知道的军规。真的非常不错!!
#### 2. 网络与数据库优化 - **具体措施**:以PostgreSQL为例,确保网络带宽与WAL文件、Slony复制、快照技术等数据库功能相匹配。 - **实践指南**:通过调整网络配置或选择适当的复制策略,确保数据库性能不受网络...
Java开发军规 Java开发军规是一份详细的编程规范,旨在统一团队的编码风格,提高代码的可读性和可维护性。以下是该军规的详细解释: 一、避免使用魔鬼数字 使用魔鬼数字会使代码变得难以阅读和维护,将数字定义为...
2. 测试类型与分类:移动APP测试的类型包括白盒测试和黑盒测试。测试的分类则有冒烟测试、功能测试、探索式测试和回归测试。 3. 网络连接测试:测试需要考虑不同网络连接(WIFI、3G/4G/LTE、EDGE/GPRS、飞行模式等...
### Java编程军规详解 #### 引言 Java作为一种广泛使用的编程语言,在软件开发领域扮演着极其重要的角色。为了确保代码质量,提升程序的健壮性和可维护性,制定一套行之有效的编程准则显得尤为必要。“Java编程...
这份文档详细列举了数据库开发过程中的关键原则,涉及核心军规、字段类军规、索引类军规、SQL类军规以及约定类军规等多个方面。下面,我们将深入解读其中的部分核心知识点。 ### 一、核心军规 #### 尽量不在数据库...