現在正在開會,這是一個跨部門的會議,這表示不只是組織裡頭會有許多部門、單位的人會來參加而已,參與會議的人會有不同的專長、態度,而且也會有許多不同類型的議程。這種跨部門會議的性質就隱含了會有專案經理人的參與,而她很有可能將自己定位成翻譯溝通的角色。

瞭解了嗎?好的專案經理人能夠以公司各部門裡頭的專有語彙來進行溝通,因此,當工程部的人說「弄好了」的時候,他們就會馬上跳進來並做出說明,「是比較急迫的那些功能測試、產品測試及最終文件的複查工作做完了,」所以產品管理部門並沒有向銷售部門說,「都弄好了,」而讓他們開始賣實際上還沒有弄好的東西。

在這個各方戮力參與,並使用多重語彙的會議裡頭,需要做出一個決策,這個決策是每一家獨立的軟體公司在這種時刻都會面臨到的。它並不是一個真正的決策,它反而比較像是協調,不過它就被攤在會議桌上,參與會議的人都很緊張,因為這個決策受到很大的關注:

產品管理部:「要如何才能讓這個功能落實?」

程式管理部:「他問的是…」

工程部:「安靜,我知道他問的是什麼。答案是,時間、品質或功能,你要犧牲哪一種?」

程式管理部:「他是在…」

產品管理部:「沒錯,我聽過這種論調,但我還是要三者兼顧。」

不停地交談。不停地翻譯溝通。該做的事一項一項被分配指派了,這讓每一個人都有一直有進度的錯覺。接著我們會回到各自所屬的部門裡頭,等待再開一次同樣的會議,然後彼此可以試著進行更有效率的溝通。不過當我們需要瞭解是誰做出這些決策時,我們實際上做的也只是安排些會議而已。

該死的三角形
時間、品質與特色。通常以三角形來描述這三者,某種程度上它代表著你產品的狀態或者你要的功能。這個三角形是完美、平衡而且似乎是靜止的,但我相信這種想法只有在理想的或遙不可及的世界裡頭才存在。要花多少時間、追求什麼樣的品質標準,以及產品要搭載的功能三者間會達到某種平衡。

在現實中,這個三角形永遠不會靜止的。它不停地變動,而且,嗯,我不認為它真的是個三角形。它是一個簡單的心理模型,剛好讓你能夠用它來撒謊。對話聽來就像底下的情形:

產品管理部:「我們需要讓這個特色有競爭力。」

工程部:「沒問題。那這樣需要再給我們另外四週的時間來把這個功能弄好,因為它是新加上來的,你太晚提出要求了。」

產品管理部:「日期不能再延了;我們之前已經談好了。」

工程部:「我們也一樣。聽好,有些東西是需要取捨的。你增加了更多的功能或特色,這就代表我們需要多一點的時間,或者,如果你真想要的話,讓品質降低一些。做個選擇。」

這種非黑即白的爭論是沒辦法成事的。這種用三支簡單的槓桿來代表一種功能或一個產品的想法,就像是專業上看似積極其實是被動的荒謬現象。整個團隊可操作的槓桿太多了,要瞭解這些槓桿,你得要去瞭解那些實際上在製作軟體的人。

位元、功能與真相
我們來做個演練。我要你想著現在正進行的專案,如果你的專案很龐大,我要你想著你正在開發的功能。我要你走到離你最近的白板前畫出與這個產品或功能相關的三個大圈圈:

現在為每一個圈圈取個名字,它是你團隊中一個特殊角色的名字。這些角色有著比較傳統的名字,叫作工程經理、產品經理或程式經理。不過我不要你習慣性地被這些頭銜限制住,我要你想想誰最有資格在位元、功能與真相上做決策。

位元
誰是對位元最有影響力的工程師?有一些人看來很有影響力,但誰是大家有問題的時候就會跑去問他的工程師?放上你經理的名字可能是最省事的,但有「經理」的頭銜並不代表他們知道事情會怎麼演變,或者我們要朝哪個方向走。我要你寫下誰會在半夜發生位元方面的緊急狀況時接到電話,而且也是可以決定與位元有關的重大決策的人。我要知道那些只要說不,爭論就馬上停止的那些人的名字。瞭了沒?好,繼續。

功能
定義產品或功能實質內容的人是誰?這個人應該是不斷地要求更多,而不管成本的人。這個人應該是可以滔滔不絕但非常冷靜地用比「如果有…這不是很酷嗎?」更強有力的論述來解釋這個功能的必要性的人。

真相
這也許是最難定義的,因為他可以是這棟大樓裡頭的任何一個角色。雖然要很多年才能明白這個道理,我相信應該為這個過程負責的人就是最有可能保有真相的人。

在任何一個工作小組當中,總是會有一些資訊起起伏伏地在傳遞著。早晨才做出的重要決策,可能需要幾個小時或幾天才能夠傳到這棟大樓裡頭的其他部門。資訊可能會有意地被隱匿起來,資訊可能被精簡,接納,也會被誤解。

真相是這棟大樓裡頭各種資訊集合的匯集,誰可以不斷地得到這個匯集,誰就是真相保有者。你認識這個人;他就是當你有「這裡到底發生了什麼事?」的疑慮時,會去找的人。他就是那個瞭解政治及參與其中的人,他們知道產品進度延遲的真正原因,而這就是通常這是專案經理的職責的原因。

我所聽到的大多數對專案經理的抱怨與對經理的抱怨是相同的:他們一天到晚都在幹什麼?他們真正擁有什麼?實際上,他們所擁有的關於產品的最重要部分就是時程,但他們比較大的貢獻則是資訊管理。

沒錯,我知道你這個新手相信沒有專案或進度管理也可以把事情做得很好。你相信這類的人會用他們安排的議程與待辦事項的清單把你的進度拖慢。關鍵在於:別因為你的團隊中沒有這種頭銜的人,你就認為沒有這類角色的存在。在任何成員不只一個人的團隊裡頭,有個人就是會扮演真相保有者的角色,而這個人所具有的主要技能之一就是為資訊而爭論。他們會不斷地從團體裡頭蒐集資訊,加以組織、轉譯,有時甚至會將這些資訊強制地灌輸給那些忙著欺騙自己的傢伙。

我:「我們還有六個禮拜的時間才需要繳交成果,我們這邊的情況還算不錯。」

保有者:「功能在兩個星期前就已經制定好了,而我們還在寫程式。」

我:「這個團隊已經啟動了,連週末都在工作,而且…」

保有者:「史帝夫與雷恩從明天開始要休假兩個禮拜。」

我:「噢。」

一位好的專案經理人關心專案與產品,不過在專業上他們也會有說不出口的矛盾心理。他們必須要如此;他們總是得揭開那個最慘的情況,然後設法存活下來。這種揭開的過程讓他們對產品的整體狀況瞭然於胸。他們這種讓自己存活下來的能力讓他們可以鎮定下來──他們不會慌張,因為他們經歷了許多狀況而且知道總是可以找到出口的…無論如何。所有的這些經驗正是何以他們總是可以安排自己行程的原因。在我們開始分析之後,我會解釋何以如此。

所以,在你的團隊裡頭,誰是這個沈默、務實而又消息靈通的人?誰是你要瞭解組織裡其他部門的狀況時會去找的人?他們極有可能沒有專案經理這類的頭銜,但他們就是會在那兒。

可勝任範圍
在我開始分析你的圈圈時,我要你再完成一項測驗,請你問自己兩個問題。

好,在每個圓圈裡頭都有個名字。也許兩個圓圈裡頭的名字是相同的。待會我們會再多談談這些。我的第一個問題是:就每一個名字而言,這個人的可勝任範圍是什麼?

你可以把雷恩放到位元與功能兩個圈圈裡頭,不過,他的心思擺在哪裡?他的專業背景是什麼?在哪一個圈圈裡,他可以發揮本能展現最佳的效率?就每一個圈圈而言,如果你覺得就某些人的天性而言有更合適的圈圈,請將名稱寫在他們的圈圈底下。

我的第二個問題是:你挑了負責帶隊的人了沒?看一下位元的圈圈。你放在圈圈裡頭的是這棟大樓裡頭最耀眼的工程師的名字,任何時候有任何人需要別人解釋架構,他就是那個會在大樓裡頭跑來跑去的傢伙,不過,由他來帶人合適嗎?他能夠為產品的方向做出決定嗎?對於產品的發展方向,他有很強烈而且似乎有很多人認同的意見,但當要把這些付諸實行的時候,他是那個人選嗎?不是?好,那誰是?

領導者需要有他們圈子裡頭相關事務的豐富經驗。這些經驗不會是放肆無禮,也不會是捏造事實;它是由日常的工作當中所培養出來的專業知識與分析技巧。因為你可以走到他們面前,提出一個困難的問題,而且你可以得到很即時的、周延的,並讓你感到安心的答案。這就是要擺到圈圈裡頭的名字。

領導者做出決定。有時只憑一點點的資料就得做出決定。有些決定是很大的決定,有些決定則沒什麼用處,不過為了要進行這個圈圈的練習,你得要分別找出三個適合當位元、功能與真相的領導者。

圈圈分析
好,我們手頭上有什麼?我們來演練一下不同的圈圈情境。

某個圈圈是空的
我們並沒有進行專案管理,我們也沒有任何產品經理人。又來了,別被頭銜卡住了。你的公司沒有聘用這些人並不代表不需要做這些工作。有些人決定功能,有些人設計流程。事實上,如果你的公司真的很小,則很有可能三個圈圈裡頭寫的是相同的名字。我們來談談這種狀況。

名字都一樣,三個圈圈裡頭的都一樣
艾格是男的。他是我們的一步決定機。這太酷了。當我看到你很快而且很熱切地就寫了下來,其實我有一點擔心。

我相信每個有效率的團隊都需要把這些角色清楚地定義出來,而且由三個不同的人來扮演。蘭斯,品管在哪兒?設計的部分怎麼辦?銷售呢。這些都是企業的基本元素。這些圈圈在哪兒?這個模型並不是在描述一個有效率的企業;它所描述的是一個有效率的團隊。銷售、設計、品管、市場、客戶服務支援 ── 還沒列完。要做生意,你得要考慮這些,而且,沒錯,他們會把一些重要的資料灌輸到產品裡頭,不過,我認為你會將米其爾這名字放在功能這個圈圈裡頭的其中一個理由是,他與設計團隊有穩固的關係;他瞭解他能做出的重要貢獻之一就是在設計方面。

三位領導者。一位做出與位元有關的決策,另一位則負責功能,最後一位則專注在真相上。整個想法是這樣子的,因為他們能夠對某一個圈圈裡的問題,依據他們的專業做出決策,所以這些領導者就會在這些圈圈裡頭做好決策,而這就會讓大家團結起來為目標前進。

專案管理部常認為工程部永遠沒辦法搞出產品來,產品管理部常認為沒有他們就不會有產品,而工程部則認為其他人都沒啥用處,因為他們不知道如何編寫程式。聽來彼此之間非常具有敵意,這就得要靠三位頭頭來處理了。瞭了沒?除了決策的權力之外,在圈圈裡的這些傢伙與他們的夥伴之間也會面對正向的緊張關係。

我將這種正向的緊張關係切分成有不同看法的勢均力敵的兩邊:

●首先,這邊是與大樓裡大部分的人有同樣的主觀看待現狀的想法。這種想法是在大樓裡頭我的工作是最重要的,而且一旦我不在了,公司就會四分五裂。這是一種我們不會跟別人說的隱藏在心中的想法,不過它是沈靜的而且強烈的想法,能讓許多人有自信去做決策。我是個專家,我很優秀,而且我是對的。

●其次,特別就屬於相同圈圈的人而言,比較傾向較不信任其他圈圈的人與其專業。就上述的想法看來,這是種脆弱的安排,不過在圈圈裡頭的領導者有權對大多數人的決定再深入思考,然後指出,「他比我更瞭解這些。」

整個想法背後所隱含的是每一項劃分這些領導者的條件,如能力、技巧與經驗等,其根本特性都不相同。一位有七年程式設計經驗的工程師與有 MBA 學位的產品經理,對功能與產品會有著非常不一樣的看法。

你可以假裝 ── 一位工程背景的領導者可以對一項功能或一個產品非常有熱情 ── 不過多年的開發經驗並不能賦予你定義、解釋或調整一項功能的技能。

如果你又重新畫那三個圈圈但裡頭寫的還是同樣的名字,那我得問你兩個問題:

他們代表一切嗎?
他們可以持續不斷地做出與位元領域相關且考量功能並有彈性地與真相達成平衡的決定嗎?真的行嗎?如果這情況發生在只有你們兩個在的車庫裡頭,我可以理解,不過如果這是在有 100 個人的公司裡頭,若只有一個人負責這三個圈圈的全部,我敢打賭,他們一定是將自己調適在某一個可勝任範圍裡頭,然後對其他的圈圈視而不見。

他們在與誰爭論什麼?
功能與位元間如果沒有正向的張力,在功能的發展方向與技術面的現實間就不會有爭議。看法上的差異讓任何想法都可以有發揮的空間,當然,希望可以因此讓這些想法變得比預期好。當我們檢視其他兩個圈圈的配置時,就可以看到許多關於上述情況的一些很好的例子。

位元與功能是相同的
所以雷恩,一位受過訓練的工程師,正為工程與功能做決策。很好。這會省掉很多煩人的為了定功能的優先順序而開的會,對吧?其他還有什麼會議也不用開了?因為雷恩以位元與功能主管的角色已做出片面的決定,還有哪些產品裡頭的功能已經不需要再討論了?

再一次,我得要當個危言聳聽,並且誇大其詞的傢伙,不過我相信你無法有效地(或不想要去)從你現在所做的事中,將自己抽離出來,讓自己能在自己所屬的圈圈外頭,做出一個周延的決策。把它想像成這樣:雷恩是客戶或他有直接與客戶接觸過的經驗嗎?如果工程師可以決定功能,必須有一個堅實的論點支持他能夠為位元與功能方面做出決策,但如果這個產品或這項功能並不是為了工程師而設計的,我們憑什麼相信雷恩可以做出關於產品或功能的周延決策?

我並不是說任何在功能圈圈外頭的人都無法為產品設想。你要的是一種可以鼓勵所有人對你所建造的產品深切關心的文化,不過,如果你正在開發一種為一般人而設計的軟體,則你需要一位一般人來指出他們需要的是什麼。

讓我們來看看另外一種版本。

真相等同於功能
東尼是可以決定功能與進度的商業人士。這是很常見的一種情況,因為一般人都知道有權為使用者決定功能的人應該也有權訂出進度。

到了五月我們需要有功能 X。癥結何在?

嗯,你手頭上有綁著功能的真相,我覺得不太舒服,因為真相必須是中立的。真相必須是不偏頗的,而且把東尼的名字放在這兩個圈圈裡頭,你會讓這個人有決定功能的權力之外還可以安排進度。在你的位元圈圈裡頭,他也許有堅實、正向的張力,但如此一來,位元圈圈如何與一位擁有內容與時間兩種控制桿的人爭論?

由三位不同領導者對你的產品產生的不同看法會營造出正向的緊張。當你有三位地位平等的,以專業的身份分別代表不同周延看法的人時,它是一種均衡的論辯,其中技術的要求與客戶的意向,以及時程上的務實都有相同的權重。當一位領導者代表著兩個圈圈的時候,他們所投下的兩票,就會將決策往他們所想要的情況推動。

讓協調開始;關於論辯
這只是另一種模型。我用這些圈圈來代替時間/品質/功能三角形。有許多方法可以用政治、新手或定義不良的功能把這個模型給搞砸或誤解。不同之處在於,我相信這個模型不只可以真實地描述出在不同方向影響產品的力量,也賦予這些力量一個正確的名字。

讓我們回到位階相等的位元、功能與真相那個無止境的爭論裡去:

功能:「我要功能 X,而且加上它之後不能調整時程。」

真相:「這需要多一點的時間,不過因為我瞭解所有的那些變動的部分,我知道其中一個功能的進度已超前。我們大概有兩週的緩衝時間。」

位元:「兩週恐怕還是不夠。我們可以刪掉這個沒有人關心而且也還沒開始做的功能嗎?」

功能:「我可以接受。」
真相:「成交。」

軟體是由人建造出來的。最好的甘特圖只能告訴你關於時程一半的真相,最完整的市場需求文件也永遠無法說明為什麼一項功能會受人歡迎,而最詳細的技術規格也沒辦法告訴你是什麼讓程式寫得這麼漂亮。這些都只是工具,它們只說明了正在建造這套軟體這些人的一點點特徵。

這些人有名字,他們之所以為人所知,並不只是因為持續不斷地在專業領域憑著經驗做出很棒的決策,他們也懂得何時應該要聽聽別人的建議。(摘錄整理自第31章)


Being Geek晉身怪傑──軟體開發者職涯應變手冊
Michael Lopp/著;陳健文/譯
碁峯資訊出版
售價:400元


《作者簡介》
Michael Lopp

是矽谷出身的工程管理經理人。工作閒暇時,他會在受歡迎的部落格──Rands in Repose上撰寫有關筆、橋樑、人物與狼人的文章。Michael也曾寫了一本名為人類管理的書,探討關於產品與工作人員的管理問題。他在書中指出,你或許可以在產品當中得到一些利潤,但卻只會因為你的工作人員而獲得成功。


Advertisement

更多 iThome相關內容