PM溝通小工具:如何善用文字、通話、截圖與影像?

技術的管理隨著時代的快速進步,工具也開始五花八門,專案管理工具,從以前古老的Redmine、Basecamp,到越來越新的Jira或者是Trello。而溝通工具,也從最早以前的Email、Skype,演進到現在最潮的Slack。然而,不管工具怎麼變,管理的本質是永遠不會變的,作為一個良好的管理者,記錄與追蹤是必須的,良好的紀錄跟追蹤習慣,不但可以讓營運、業務端不會亂開需求,也可以針對工程師的工作做一個簡單的風險管理,也因此希望寫下這篇文章,讓大家知道如何良好使用工具去做好管理的工作。

技巧一:務必養成寫會議記錄的習慣



很多剛踏入門的管理者,最常發生的故事,就是每次開完會,大家都是講了一大堆,然後最後真正把事情做完的時候,人家就開始怪東怪西,因為很多事情都是”當初早就講過”的事情。說話的特性是來得快也去得快,常常事情發生後,死無對證,所以這時候文字就發揮了他該有的效益,畢竟白紙黑字跑不掉啊,也因此,如果你很常跟大家開會,請務必開完會,習慣做個文字紀錄,並且務必發信給大家做一個簡單的紀錄,這樣才不會被人家呼隆。

技巧二:有文字後,還是要追,通話是最快的追法


 
承接上面的情境,很多人都覺得已經有了會議記錄,理論上所有的團隊成員應該都會按照進度好好去做,而且大家的認知應該都是一致的。但是,現實生活中的情境永遠不會如你所願,文字是強烈的紀錄沒錯,不過文字的描述,對大部分人來說,都有不同的想像空間,這也是為什麼看小說跟看電影還是有些不同的原因。因應這種狀況,身為一個管理者,需要根據重要的事項,去逐一追出成果,也因此有時候簡單通個話,了解彼此的認知,也許只需要花上三到五分鐘,就比寫一封落落長的信,來得更有效果。更好的方法,還可以在通完話之後,替對方簡單摘要後,發給所有與案件有關的相關人士,這樣對於團隊資訊的平衡,有非常大的幫助。



技巧三:測試軟體的時候,善用截圖與影像


 

身為管理者,一定都會遇到要”驗收”成果的時刻,而出現Bug在做軟體的世界裡,是百分之兩百一定會遇到的事,而在傳遞Bug訊息的時候,除了文字與說話外,一定要養成良好的習慣,”有圖有真相”,甚至是做到”有影像有真相”,讓團隊成員可以很快得知你的問題。依照我過去的經驗來說(我是用Mac),Shift + CMD + 4的按鈕做影像截圖,利用Quick Time Player做螢幕截圖,是非常簡單的方法,如果是App的話,除了用螢幕截圖外,可以用另一支手機直接錄製操作過程的影像,都是非常實用的方法。除了利用截圖跟影像外,回報問題的時候可以附上你用的手機型號、手機系統版本,如果是網頁的話,則是回報電腦系統版本、用哪個瀏覽器、瀏覽器版本,這些資訊都會大大的提升開發工程師解決問題的效率喔。


技巧四:Email與通訊軟體的使用方式


 

在現在的世代,使用通訊軟體的速度已經遠大於Email,但是Email還是有他”正式”的一面,也因此如果你需要大量與人溝通的時候,一定要學會個別使用。Email大多用在會議相關訊息或是重要訊息的傳遞上,而且大家請務必要知道一件事,如果有一天真的很不幸的,你因為工作的事情而上了法院,Email的訊息是絕對具有法律參考價值的,而通訊軟體較為沒有參考價值,所以,如果你考量到這點,Email在某些時刻,絕對扮演一個重要的角色。反過來說,通訊軟題則代表了速度與非正式,很大的原因是大家已經習慣通訊軟體裡面都只有分散或是片面的資訊,所以可以自由問問題,也可以順便加個貼圖,來讓氣氛和緩。還記得我剛開始工作的時候,大多使用Email,往往一天跟客戶最多來回的次數就是兩次,而用通訊軟體,則是不下數十個甚至數百個對話紀錄,資訊的量差異非常大,不過這點卻也提醒了大家,在快速的同時,千萬別忘記永遠需要摘要重要的資訊,發個”正式”通知,不然到最後吃虧的還是自己唷。
 

技巧五:線稿、Flow chart與user story


 

再來講個更深入的使用情境好了,現在做軟體服務,不管你是傳統的PM要開Spec也好,還是一個scrum體制底下的Product Owner,需要開出Product Backlog,我都很建議大家一定要有線稿、Flow chart跟user story。原因很簡單,在需求描述的時候,越詳盡越好,而這三者基本上大概可以描述一個服務的世界觀。這三者如果要做的很細,當然還可以用像是Prott或是Marvel App這樣的工具做出Prototype,這樣更能具象化整個服務未來的樣貌,讓團隊所有成員的資訊更能對等,並且一同成長。

 

結論:團隊的引導永遠需要”資訊平衡”與”持續更新”


 

作為一個團隊的管理者,尤其在軟體的技術管理者(PM)身上,一定要讓團隊的每一個成員保持資訊的對等,避免大家做出錯誤的事情還渾然不知。像是我過去就有遇過工程師做的功能,跟實際上營運端需要的完全不同,也因此不管是文件也好,討論的過程也好,一定要著重資訊的平衡。

而持續更新則是軟體產業一個很大的特性,尤其是平台的開發,往往沒有停止的那一天,就好像蓋大樓一樣,永遠持續往上長,也因此,持續更新、持續成長,才是服務長大的關鍵。因應這個環節,做管理者的更要能夠讓所有的資訊是持續更新的,而且隨時可以回溯過去的發生的問題原因跟解法,以作為未來做事的參考依據,我最常遇到的問題,就是有些團隊往往會一直在某個問題上原地打轉,而且不斷在嘗試過去用過的方法,一直想突破盲點,卻忽略過去的資料,這就是我所謂的”持續更新”最重要的功能。

希望以上的技巧對大家能有幫助,如果有更多更新的方法或工具,也隨時大家一起來分享。

想了解更多 -->