終點不會是一翻兩瞪眼的產出,而是經過一番洗禮之後的樣子
當時的我,我心繫一件事,趕快將平台完成,有平台、有功能、有準時、有正確性、有按著流程,這樣IT就能攻下第一個里程碑,寫一筆戰功。我以我的想像,列出了一系列的功能清單,然後安排著A系列功能在7月完成、B系列功能9月完成…,一路排到年底,然後跟IT成員說,每兩週產出一次,請大家務必準時,然後正確性也要顧。「這樣不可能,時間有限,我們不可能兼顧品質與準時!」「喔,那就請大家列出來距離這些目標,還缺些什麼,我們再來一一檢視」我如此回答成員的不安。後來,我們的確花了一整天開了workshop,將A系列功能們,再往下細分,對於功能上有哪些不確定,在workshop期間也做了定義,然後在尾聲排序、分工,開發看似已經沒問題了。為了達標,我天天盯著進度,對於落拍的人,一直找來詢問原因,所有人都被產出追得緊,當然我也是,每週我都得和執行長同步狀況,每一個細節必須扎實的掌握著,只要一不清楚,就是我面對執行長啞口無言了。如果一直follow文章的朋友一定知道,開發最終宣告失敗,本來期待著A系列的完成,會迎來小慶功,殊不知只是又迎來戰線拉長的消息,因為使用者的問題沒被解決,工程師也都快蒸發了。整個IT團隊,追著產出(output),只要一個產出沒有完成,整個功能也就不完整,整個表現也不被其他團隊理解,我也追著產出,所以事情是沒有止境的被衡量,只有一件又一件的產出變成成果計數器,說得難聽一些,這變成是打造一個不知道在解決什麼問題的程式產生工廠。無法累積經驗,遇事也無法取捨,就只因為我只看產出而非產值(outcome)。
愛你的問題,而非愛解方
我一直知道以終為始的重要性,可是我一直不得其門而入,直到最後我才知道是因為過於著眼於產出。產出,其實就等同於視角放在解方上,排程用解方想、目標用解方設定,這樣會造成3大問題:
能權衡重要性的是問題,而非解方,我們不會說,某某解方特別好,所以就需要優先實作,而是A問題超級重要,所以我們需要優先解決,實務上,我們在每天的運營上,一定會臨時冒出的考題,適時調整策略、步調是必然的,如果手上只有一堆功能清單,而沒有對應到的背後問題,就算開放一個擂台,直接勝者說話,對團隊都是沒有益處,也無法進行團隊補位。這個也延伸到第二個問題點,除了運營上,技術上也是會有意外的,原本以為可以使用的套件,不能使用,好一點是能找到替代方案,不幸一點,就是整個做法不可行,不論從運營或是技術上帶來的變故,如果我們著眼的是解方,就會少了變化的彈性,也會直接宣判開發無效或是需要再多點的資源了,這時候,第三點也會隨之發生,身為成熟的工作者,我們都很清楚,公司資源不是無限的,競爭對手不會停下等待,等待接棒的跨部門同事也嗷嗷待哺,以解方做為依據,注定失敗時,沒有變化的空間,最快地,就是拿個人的時間來換,這時候不用唐立淇老師預言,我可以百分百說,水逆一定發生,我們有多少時間可以補救錯誤呢?所以第一個失敗,就會影響第二個失敗,接著第三、第四,只會覺得待在這團隊才是水逆吧!
產值才是最重要的,產值代表著問題,要如何定義問題、瞭解問題是一門很深的學問,第一步,請永遠謹記問「為什麼?」,問自己為什麼?問別人為什麼?在自覺的環節中,我發現我太容易接收別人的說法,好處是我可以很快融入一個環境,可以很快速的學習常識,記得一些知識,但是,壞處是我很快就會跳到解方,然後堅持解方,經營團隊或經營一門生意,就像在玩世紀帝國一樣,往前探足才能窺見一部分地圖,在一切未明的情況下,沒有人可以確定自己的解方是最好的,也如同工程開發一樣,沒有定義好規格或情境的開發,絕對不會是好開發。挖掘問題,以解決問題做為終點,可以給自己與團隊多一點發揮的空間,在推動IT文化或管理時,自己可以更開闊的心胸接收不同的建言,以最大的資訊量成長,讓問題被解決。
你想像的樣子與我想像的樣子一樣嗎?
今天是第5天的文章,我們從自己出發,瞭解自己擅長與不擅長,然後找到面鏡子可以拯救我們的弱項,掌握整體公司運作的時候,我們需要的就是一個目標。這些我認為是成為產品經理的入門功課,過去運作的時候,我有極強的問題解決能力,哪邊缺了什麼,我就去哪邊補位,可以說是完美救火隊,不過就僅限於此了,惦量著手邊的資源,盡一己之力將能補上的缺都補齊了,讓產出順利誕生,過程中,自己的能力提升了,但就缺少團隊影響力,也未促成任何流動。今天大家齊聚公司,想要獲得的不盡然相同,但一定有一個共同鎖定的項目,否則何必耗損自己與公司的資源(時間)呢?產品經理可以輔助的就是不斷地定義目標,拿著這個目標和跨團隊確認,確保我的想像、IT團隊的想像和需求單位的想像一致,大家也可以共同給予目標意見,如此,在公司裡一起合作才會有意思。當然,不是每一個公司都能有這樣的空間,可以讓產品經理有這樣的體悟與發揮機會,所以,希望以我的經歷,分享給大家,大家也可以自行拿捏怎麼套用在工作之中。