注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

难得简单

闲看庭前花开花落,荣辱不惊。静观天上云卷云舒,去留无意。

 
 
 

日志

 
 
 
 

Why Your Team Is Better Than Others  

2014-07-09 17:23:05|  分类: 工作 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

Why Your Team Is Better Than Others

What makes your team better than others, because they have great individual skills? Or you’re working on a great process?

We’re not talking about the individual skills or process in this article. I want to talk about the 3rd reason.

Have you met following kinds of problem?

1.      Your developer completed a feature, simply tested with normal flow and looks good. It’s marked as Dev Complete and assigned to QA. QA found a critical bug, just to click Cancel button in one step of the normal flow. QA filed bug and this feature was assigned back.

2.      Your developer got a subtask, which was to develop an API, with requirement written clearly in the issue. He completed the development quickly based on the requirements. And then he started to do the integration test with the client code. He just found that the API he developed was totally different than the expectation of the developer who will call this API.

3.      Still your developer, he was assigned to fix a defect. He checked the existing code, which was ugly, very ugly with poor design. But it’s quite easy if he just wanted to fix the defect only, two lines of code changes. That easy fix won’t improve the code, which would still be hard to maintain in the future. He chose the easy fix without discussing with anyone.

4.      Your QA was testing a new feature, which was implemented 100% following the description. But the behavior was kind of wired thought it matched to the requirement. Since it’s following the requirement provided by Product Manager, the QA marked this feature as “Verified”.

5.      When we’re integrating code to trunk, everyone needed to integrate manually by issue and it always cost lots of efforts. People hated to integrate, and they knew that a simply script can help with this. But no one created that script, they tried to get used to the inconvenience and they did it.

6.      Assume a developer, in Shanghai, was working on a new feature. The QA who will test this feature was in US, with half day time zone difference. The developer still needed about 30 minutes to complete the integration test. But it’s off work time, developer decided to leave the office, and completed the feature in the second day. In this case, US QA waited for one more day to test. But no one knew this except this developer.

7.      Your UI developer made a fancy HTML prototype 100% show the UI effect wanted by UI designer. But the library used in the prototype was conflict to the existing UI libraries used in the application. Either engineer need to spend lots of efforts to refactor the code, or UI developer to refactor the prototype using a different library.  

8.      Your Product Manager wrote a long story with very detailed information before spirit planning. But Engineers couldn’t understand the requirements easily in spirit planning and they spent 2 more days to discuss the story.

In all examples above, did anyone violate the process? No, we can’t say anyone is making mistake, per the process. Unless we add more rules in the process to cover all kinds of scenarios we may meet. That’s not possible either.

But is there anything they should improve in the examples, definitely YES.

In #1, he can choose to submit the issue to QA testing right after they complete the smoke test; he can also choose to test more like a QA and try his best to make sure no bugs to be risen by QA.

In #2, he can trust the product owner and follow it completely, or take additional steps to confirm with the developer who would call his APIs.

In #3, he can choose to fix the bug ASAP, or he can choose to tell the problem of the code within the team and discuss if he can have more time to refactor the code.

In #4, he can choose to follow the product owner, or choose to think like a user and question the requirement.

In #5, he can choose to follow the original approach, or choose to advise the team to create some scripts to improve the work.

In #6, he can choose to work in regular tempo or choose to spend more time so that QA can has one more day to test.

In #7, he can choose to implement the UI effect ASAP, or choose to discuss with engineers first before implementing the prototype.

In #8, Product Manager can choose to write the long user story first, or discuss the thought with engineers first.

The ideas behind their choices could be summed up into pieces of common senses, like always consider the next step of others, think like a customer, has passion to refine everything you find, etc. Those kinds of common senses, they are not about professional skills, not about process, but indeed make up the Team Culture, which makes your team different.

A new built team normally doesn’t have consistent senses, because they have various thinking way, working approaches.

A well trained and experienced team, they have met different kinds of scenario, handled different kinds of things together, and in the end they build up many common understandings about how they think and consider about problem, how they should communicate and how they cooperate with each other.

They have their own Team Culture, which drives them to complete the communication with less time; to take reaction more quickly than others; use less iteration than others to meet the same goal; and cause less mistake to find the correct answer. That makes them much more collaborative and productive.

Team Culture is the one which makes your team better than others.

 

Who is the one contributes the most to the culture? Normally it’s the leader of the team.

If the leader can go into the every detail of the project, that shows a signal, though this is a small thing, he cares. Now that the engineering leader cares, any reason why you don’t care? Eventually, each team member would go to the very detailed thing.

If the leader always thinks the next step of current task, he tells his thought, and encourages people to think more for next step. People would think more for next step.

If the leader always thinks what action to accelerate the cycle/process, and encourages people to do that, team would think about that.

If the leader always thinks like an end user to test the product, and questions the Product Owner, team would do that.

 

So, do followings:

1.      Think through all scenarios your team has met, and try to summarize them into short keywords.

2.      Identify the keywords of the culture you want to build and share to the team.

3.      Going on pay attention to any scenarios in your team related to the keywords.

4.      If team member acts as the culture you want, encourage it.

5.      If team member acts different than the culture you want, highlight it, tell your thought, even execute by yourselves to show as example.

6.      Ask your team member to educate others like how you educate him/her.

7.      Keep refining the keywords. 

  评论这张
 
阅读(88)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017