PMP

寫軟體技術文件有哪些可遵循的原則?注意 4 個重點,幫助你寫出一份好閱讀的產品 / 技術文件

每一個職業都有值得學習的地方。在軟體開發產業,工程師將寫高品質的程式碼技術傳授給其他人的秘訣,是經常總結可遵循的「哲學」與「原則」。但多數人只看到工程師打著複雜指令的一面,卻沒看到軟體設計背後的巧妙思維。

拯救失控專案:談管理機制導入前必要的診斷

某天其他部門的同事跑來詢問我 : 「聽說你們的專案執行得不錯,可以給我們WBS參考嗎?」起初我有點一頭霧水,一問之下才知道原來是主管的指示,要他們前來取經,而且特別指名要看WBS。據我所知,他們的專案範疇大、協作單位多,一直以來是個燙手山芋,卻又是公司轉型階段不得不執行的任務。雖然和我之前的專案有些相似之處,但畢竟團隊不同,產品的屬性也有差異,想用同一招打天下頗有難度,於是我開始思考,專案管理強調的Lessons Learned ( 經驗傳承 ) 精神,要如何落實? 

新任PMO主管該做的三件事(上)

PMO在這幾年其實變成一個新鮮的議題。我身邊還滿多讀者或是朋友,因為公司突然決定要成立一個PMO,而被長官指派要負責這部門的營運。可是因為公司過往從沒做過類似的事情,專案管理在目前又還不像會計有法規上面的要求,所以任何的開展方式好似都說得通:好像什麼都能做、又好像什麼都不能做。若負責PMO的人政治敏感度不夠,缺乏組織變革所需要的知識與經驗,很可能花了很多心力卻碰到大家的抗拒。抗拒下做不出結果,慢慢老闆對此就失去興趣,最後往往就變成一個被冷凍的部門了。

為何某些PMO會夭折?

我在這裡打算分享的,是想很務實地告訴大家一些你在別處不會看到的「小建議」——哪些事情會讓你迅速搞爛這個部門;如果你剛巧接手或是即將接手這樣一個部門,又不希望自己做錯事情,那你實在該好好看完這一篇! 

你需要一些志同道合的朋友

這篇是針對「PM的成長途徑」所發表的第十篇文章。 到此為止,我提出的建議包含從熟讀專案管理知識、培養工具應用及動態排程能力、歷史資料累積、軟實力的培養,還有專案經歷的增加等事項。 最後這一篇,則建議大家若想要在專案管理這領域走得久,你不能只靠自己奮鬥。 並不是只要自己懂很多知識、念很多書、考很多證照,就能在這領域闖出一片天。 因為管理的效果,其實必須得是一種「眾人的共識」。 唯有很多人理解管理手法,用相同的方式行事,價值才會倍增。

擴大你的專案視野

我在專案管理雜誌之前寫了八篇文章,談的都是PM的「成長途徑」。 在那些文章中,我有建議大家除了PMBOK中的知識外,也該學習一些其他的知識,包含以軟體排程分析、規劃控制、以及舉證的能力,此外歷史資料的累積,還有軟性技能的培養也很重要。