公司的IT部門

IT不是超然於世的部門，而是運作於公司的一部分

甫加入公司的時候，已經有一個又一個的專案在進行著，有著現有的平台需要維護，有著現有專案要處理，因為我的號召，現在又多了一個新平台要開發，在初期，我犯了第一個錯誤，為了sprint而sprint，略知皮毛，就開始構築起表面規則，所有工程師都得同時處理日常業務(Business as usual, BAU)和開發業務，而BAU又時常越線，需要更多時間處理，有更急的時限，想當然，講求commitment的sprint永遠都無法達標。這時候，我憑了我自己的想像，用google sheet兜了一個需求管理介面，其功能就只是簡單規範與紀錄需求，並沒有直搗核心問題，同時，也讓IT團隊又只能沈浸在BAU中。這時候，因為要開發新平台一事，備受關注，被期待所發揮的槓桿效應，也就壓上了時限，這個時限當然也蘊含了我天真的浪漫，而且以營運的腳步，本來也沒辦法讓我們用slow motion緩步進行，部屬們當然反彈了，這一次，我重新把團隊切分成BAU的小組和開發的小組，這樣的確也解決了部份問題，但也製造了下一個問題，BAU小組的人工作變得無趣也常收到需求單位的隕石要求，開發的人正式更遠離需求單位，更不了解需求單位的需要，所以，這一次的重啟，大家壓力大、我的壓力大、需求單位繼續痛，所有問題都沒有被解決，再一次宣告失敗。在這過程中，並非毫無可取之處，但就是因為這樣士氣才會被打擊的嚴重，工程師所做出來的東西，是花心思的，設計師對於功能想像，是有巧思的，但問題是，無法解決需求單位的問題，即便完成超mega平台，也是徒勞。IT是公司的一部分，每一個部門都有其運作方式與特性，如果單就一個部門來看，可以很簡單想像其所具備的文化與管理方式，但是，當要多部門運作時，就不是傾向某部門設計，就能得到好結果。再加上公司運作是需要具備市場競爭力的，更不可能有機會讓我們慢慢來，一切就變得更加艱難了。

從深入瞭解開始

好的部門合作，不是依存某個部門主角，而是用好的想法相互影響

產品經理一個必備技能，就是掌握所有利害關係人，也需要搭建好的溝通橋樑，讓好的經驗可以互相流動，這樣也能讓每一份工程師之力，妥妥地與需求單位的痛串接起來。因此，再來一次，我向主管與團隊表示，我想從暸解需求單位開始做起，也讓IT團隊不要急於新平台的開發。我做的第一件事是，讓每一件BAU可以被記錄下來，讓我可以了解需求單位的痛與IT團隊的需要，這裡有兩個很重要的思維，一個瞭解自己擅長之處，另一個則是確保讓大家願意配合。當下我知道，需求單位為求快，所以不願意有個表單紀錄細節，只要透過通訊軟體或是口頭敘述，就要讓工程師開始動工。資工出身的我，我很清楚這樣的行為已經踩了無數個工程師地雷，我心中已經盤算好，規格和時間掌握是我首要任務，以此為前提，我投身於需求單位，傾聽他們的需求，將他們不願意填寫需求表的原因，一個個詢問出來，同時傳達工程團隊需要的元素，讓第一個基礎橋樑被打造出來，這張需求溝通表，現在是我很重要的迭代基礎，陸陸續續被改了好幾次版，每一次都是將IT團隊需要的、需求單位想要的做一次串接，力求將雙方的溝通差距縮小，在這張表裡面，我可以拉出許多數據觀察，更重要的是讓IT和需求單位好的思維：像是運營所需的節奏、對於開發所需預留的緩衝概念等相互影響。過程之中，產品經理扮演相當重要的權衡角色，就如同之前有提過的，沒有所謂的best practice，只有最適合這個團隊的方式，產品經理需要掌握三大元素：使用者、技術、利害關係人，能知曉如何配置三大元素，並讓其可以流動，才有機會可以打造IT文化，因為IT團隊不是獨立運作的部門，而是公司的一部分！