国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

背景：

我們公司有一位COO，Yahoo過來的，做產(chǎn)品經(jīng)理出生。下面有2個SVP，一個技術(shù)，一個產(chǎn)品經(jīng)理。技術(shù)的SVP性格比較溫和，不強(qiáng)勢，最看重的是make things done。產(chǎn)品經(jīng)理的SVP性格強(qiáng)勢，是COO從Yahoo招過來的。

網(wǎng)站的流量也不大，一個站點(diǎn)16臺應(yīng)用服務(wù)器就搞定了，不是那種技術(shù)要求非常高的公司。

以上的背景就決定了，我們公司文化并不是工程師導(dǎo)向。很多事情，還是PM話語權(quán)比較大，公司策略，開發(fā)資源調(diào)動，主要是由PM來驅(qū)動。甚至有時候需要多少開發(fā)人員，也是PM那邊直接給建議。

　　我們出現(xiàn)過的一些問題：

1. 我們有一個頁面，是網(wǎng)站最重要的頁面，因為長期在這個頁面添加各種功能，這個頁面的代碼已經(jīng)非常復(fù)雜，每次做一個小改動，開發(fā)人員會不經(jīng)意間弄壞其他功能，而QA測試跟bug修復(fù)的時候都要幾周。

2. 我們有個功能很獨(dú)立的組件，作為本地代碼放在我們網(wǎng)站應(yīng)用里面，于是出現(xiàn)了這個組件跟整個網(wǎng)站的代碼耦合很深，代碼互相牽扯。屢次想花時間把這個組件分離成單獨(dú)的web service，但是總是因為business需求的緊迫性，這個項目分不到人手。

3. 諸如此類的，以上種種的技術(shù)負(fù)債，就導(dǎo)致了我們有時候會在正式環(huán)境上出現(xiàn)一些很嚴(yán)重的技術(shù)問題，或者有一些簡單的需求卻花費(fèi)了巨大的開發(fā)代價。而最終為這些問題買單的，還是技術(shù)部門。

4. 有些PM會給一些所謂的“完成”的需求文檔，或者以我們要agile為借口寫一些不夠詳細(xì)的文檔。在開發(fā)過程中，開發(fā)人員花了很大的精力來討論這些需求，導(dǎo)致項目不斷拖延，開發(fā)人員因為工期拖長，出現(xiàn)人員變更，而新來的開發(fā)人員又帶來了更多的bug，于是更加拖延了項目，結(jié)果就是，項目合作很不愉快。

去年美國那邊來了一位技術(shù)副總，在Oracle跟Collabnet呆過，我跟他一同負(fù)責(zé)Platform的開發(fā)工作。經(jīng)過大半年的合作，經(jīng)常可以在跟他的談?wù)撝?，感受到他一些對我們很有用的想法?/p>

　　1. 技術(shù)需要marketing

我的部門除了有Platform開發(fā)的團(tuán)隊，還有一個團(tuán)隊是負(fù)責(zé)架構(gòu)的，跟Platform不一樣的是，架構(gòu)要做的項目都是技術(shù)部門自己催生出來的，所以經(jīng)常PM端，COO都不太了解我們做的項目。不知道為什么做這個項目，有什么好處。我相信在一個工程師驅(qū)動的公司，這樣的問題并不是大問題。但是問題是我們是業(yè)務(wù)型公司。

比如我們最近在做的一個組件化的項目。

于是有一回，這個VP在跟我打電話的時候，談到這個組件化項目，他說，”XXX，你知道，你們現(xiàn)在在做的這個組件化項目，很危險!“

我說，”怎么講?“

他說，”你覺得XXX(Platform的PM，是個VP)知道你們在做什么嗎?“

我說，”他應(yīng)該知道一些，我有跟他說過?！?/p>

他又說，”你覺得XXXX(我們的COO)知道你們在做什么嗎?“

我說，”他應(yīng)該不清楚，這個太技術(shù)了?！?/p>

他又說，”那你覺得XXXX(PM的SVP)知道你們在做什么嗎?“

我說，”他應(yīng)該也不清楚?！?/p>

他說，”那如果你這項目出現(xiàn)一些問題需要幫助的時候，或者說需要resource的時候，你覺得他們會幫助你嗎?“

我說，”看來不會。“(我心里想，肯定不會，現(xiàn)在就出現(xiàn)問題了。)

他說，”如果有其他項目需要人，你覺得他們會第一個從你這個項目中抽調(diào)人手，還是從其他他們了解的項目抽調(diào)人手。如果現(xiàn)在他們發(fā)現(xiàn)開發(fā)部門的開發(fā)資源不足，他們第一個challenge的項目是哪個?“

我沉默。

他又接著說，“我們都是XXXXX(技術(shù)的SVP)的人沒錯，但是說白了還是XXXX(COO)的人，你現(xiàn)在拿COO的人，在做一些他不懂你們在搞什么的事情，你覺得這樣是不是很危險?”

我說，“嗯?！?/p>

他說，“我可以幫你。首先，你應(yīng)該以PM能夠懂的語言，解釋這個項目能給他們帶來的好處。你說說，你這個項目可以帶來什么好處?”

我倆Balabalabala了一陣子。

(用XXXX代人名太痛苦了，之后我還是直接用職位吧。)

然后他說，“所以你這個項目，F(xiàn)ront End的PM VP，Platform的PM VP都可以從中帶來這個益處對不對?“

我說，”是的?！?/p>

他說，”所以你現(xiàn)在不用他們的人手，卻在做對他們有好處的項目，對于這樣的好事，他們歡迎還來不及呢，對不對?“

他又說，“如果COO知道了，哇，原來架構(gòu)組還做一件對公司這么有好處的事情，那很好啊，這個組很棒!”

他繼續(xù)說，”可是，現(xiàn)在沒有一個人知道這件事情，所以，很明顯，你們做的marketing不夠?！?/p>

他說的很對。只要稍微懂技術(shù)的人都知道架構(gòu)的重要性，但是以前我們一直沒有固定的人員去做我們架構(gòu)組自己想改進(jìn)的東西，直到去年，我才說服我們技術(shù)的SVP，騰出固定的人員做架構(gòu)自己的項目。而如果我們有人能夠為我們架構(gòu)的項目做好marketing的話，我相信業(yè)務(wù)負(fù)責(zé)人會主動為我們增加改進(jìn)架構(gòu)的resource，支持我們的項目而不是像目前這樣睜一只眼閉一只眼的不管不問。而且也不會出現(xiàn)，個別PM以他一知半解的技術(shù)知識，把我們網(wǎng)站的架構(gòu)錯誤的描述給公司的業(yè)務(wù)負(fù)責(zé)人。

　　2. 處理技術(shù)負(fù)債

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

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

而這位VP的做法是這樣子的。把處理技術(shù)負(fù)債的項目加到PM的roadmap進(jìn)去。

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

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

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

　　3. 約定大家都接受的規(guī)則，然后大家嚴(yán)格按照規(guī)則來做事

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

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

每個backlog都要有acceptance criteria。還要有對應(yīng)到PRD的地方。這樣開發(fā)人員就可以直接去了解他要做的任務(wù)。

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

這樣大家都有了清楚的，自己要達(dá)到的標(biāo)準(zhǔn)，做得好，做不好，也很清楚。

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

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

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

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

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

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

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

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

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

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

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

VIA:難得簡單