技術領導人需要的一些特質(2)

　　2. 處理技術負債

　　我們技術部門跟PM有約定，在制定roadmap的時候，會給出20%的時間解決一些技術負債。但是我們一直沒有一個合理的流程來使用這20%。

　　最近技術部門在想辦法促成一件事情，就是從每個產品線的開發部門里面抽出一些比較強的開發人員，組成一個團隊，專門用來處理技術負債。這可能是一種變相的使用20%的方法。但是這件事情一直不好推進，因為從業務端來說，這個團隊做的事情對他們不透明。

　　而這位VP的做法是這樣子的。把處理技術負債的項目加到PM的roadmap進去。

　　(我們的Roadmap其實就是每個產品線的年度工作計劃，什么時間做什么項目。)

　　我們以20%的時間，算出每一年用來解決這些技術負債的人周。然后根據這些總人周，列出用這些人周可以完成的項目再制定計劃。這其實跟PM要做的項目很類似，從什么時間到什么時間，花多少人，做哪些事。但是我們在提議這些重構項目時，要清清楚楚的以PM能夠理解的語言寫出我們具體要做什么，這個項目做了有什么好處。

　　這個方法，跟前者我們提議的方法比起來，從開發管理來看，更透明，也更可控。也更容易讓業務端接受。

　　3. 約定大家都接受的規則，然后大家嚴格按照規則來做事

　　比如說在項目管理里面，他會先說好，我們用SCRUM的方式來跑，大家同意了。于是就嚴格的按照SCRUM的方式來跑。當在一些問題上有分歧的時候，就參照SCRUM流程來解決。

　　我們在準備這個spirit的時候，PM必須要提前準備好足夠的backlog給大家看。這樣我們就不用再從一個很粗略的很大的PRD去痛苦的找出開發人員要做的需求。

　　每個backlog都要有acceptance criteria。還要有對應到PRD的地方。這樣開發人員就可以直接去了解他要做的任務。

　　開發人員在把功能交付給QA測試的時候，必須運行QA提供的一些基本測試。這樣就防止了開發人員交付沒完成的功能。

　　這樣大家都有了清楚的，自己要達到的標準，做得好，做不好，也很清楚。

　　最近他還做了一件讓我很贊成的事：

　　我們很多項目都會有一些所謂的consultor的角色，他們并不做具體的事情，所以很難界定他們做得好不好。但是在說明每個project花費的時間的時候，他們又說有30%之類的時間在這個項目上。我注重實際的產出，所以我不太喜歡這樣子光說不做的角色。表面上很忙，但是具體對項目有多少的幫助，又很難說清。

　　于是我們在談論某個“consultor”要做什么的時候，他會問清楚，這一位，扮演的是雞還是豬的角色。(不懂豬或雞的，請去了解SCRUM流程)如果是豬，那就是具體的開發人員。如果是雞，卻又找不出他是雞這個角色的理由。于是最終界定，他是豬的角色，也就是要參與具體的開發。我相信，這樣就避免了前者我說的那種不喜歡的角色。

　　我經常在想，他為什么可以把很多事情推動起來，而且讓大家都認可，即使他有時候是贊同了一些人，而反對了另一些人，但是所有人還是都對他信服的。

　　我們再把上面一條一條的回顧。

　　1. 我們在跟業務溝通的時候，用擴展性，穩定性，易維護性，但是這不是雙方都能有個直觀印象的語言。做了對公司有什么好處，不做對公司有什么壞處，這才是雙方都有直觀印象的語言。

　　2. 如何處理技術負債。成立一個專門的小組去處理負債，這并不是一個雙方都能理解的做計劃的方式。Roadmap才是雙方都有個直觀印象并且都認可的做年度計劃的方式。

　　3. 需求清不清楚，這是個很不直觀的判斷，每個人判別的方式不一樣，得出的結論也不一樣，但是有沒有acceptance criteria就很明了;

　　開發人員做到什么程度才算完成呢?跑完QA提供的基本測試才算;

　　SCRUM里面有個Consultor要做什么?人們可以很容易的說，他要幫助什么……，推進什么……解決什么……，可以說出一堆一堆。直接問一下，是雞?還是豬的角色?非常的清楚明了。

　　這就是我想說明的這位VP的特質，不管跟什么人溝通，CEO，COO，還是PM，開發人員，他都是以雙方可以有直觀印象的語言來做溝通，他想知道你的意見的時候，提出的問題，盡可能的，不是給你出主觀題，而是選擇題。而要達到這個目標，我相信他在問每一個問題，每一次談話之前，都會先把思路理得井井有條。

原文轉自：http://blogread.cn/it/article/6477?f=wb