談談我對軟體開發專案管理的理解
首先宣告一下，我並不是一個PM，也從未做過與專案管理相關的工作。作為一個每天都偏安一角靜靜地寫程式碼的程式猿，本不應該發表與專案管理相關的觀點。無奈，以個人的角度和眼光，鑑於工作中出現的一些問題，還是想在這裡以“關二爺繡花”的立足點聊一聊軟體開發專案管理相關的問題。
先簡單地從個人經歷說起吧。我工作過的第一家公司是一家在國內外牛逼哄哄的網際網路公司，我在的那個部門也是有幾百號人來開發一款產品，我入職的時候該產品開發已經接近尾聲，其時該專案已經走過四五年的光景。工作期間，感受最大的東西就是流程，每做一件事情都有一套有章可循的流程。與之相關的就是工作臺系統，與工作相關的內容都有一個明確的工單。到最後，產品版本嚴格控制的時候，要提交一行資料甚至修改一個標點符號，都要經過以分級而定的
後來，我到了現在的公司，一個軟體外包公司，在此感受到的就是另外一種截然相反的專案管理方式了。因為外包的性質，也就是給客戶做產品寫程式碼，所以好像一切都變了。首先，每個專案的人數變少了，少則幾個多則幾十個，這要視具體情況而定，而且還是變化的，一個人可能身兼多個專案，可能這段時間在做一個專案，過一段時間又在做另外一個專案。其次，因為每個產品客戶都催的很急，每個開發每天都在加班加點甚至到了用第六感在寫程式碼，所以流程神馬的都成了浮雲。於是，客戶每天在瘋狂地下達需求、開發每天在瘋狂地造程式碼、測試每天在瘋狂地測測測測、運維每天在瘋狂地發版本和緊急搶險。在這種情況下，工作臺和工單系統不能得到有效使用，個體有什麼疑問就只能靠嘴皮子去來回打聽；出了問題的時候，就成了一窩蒼蠅，翻來覆去查
以上介紹了軟體開發過程中流程化和非流程化兩種專案管理方式。前者穩健，後者精簡，也各自基本上符合以上兩個公司的實際情況。但綜合來看，一定範圍內的流程化還是有益的。以下分幾個方面說明一下哪些做法可能不僅就過程而言還是就結果而言更值得參考。
①.工單系統
什麼事都提交工單，可能會比較繁複，就眼前來說可能浪費時間拖慢進度。但長遠來看，完整的工單讓工作明確明瞭、可追蹤可查詢、質量有保障風險有控制，是完全有必要採用的。
②.線上版本控制
線上發版需要走一套成熟穩定的流程，這包括固定釋出時間和釋出週期、明確的直接釋出人員和相關人員、有預先計劃的完整發版內容以及經過系統地預發環境測試。
③.序列管理優先
每個員工儘量只由一個leader（組長或其他）分配任務，可以把任務分配給leader再由leader轉分配。如果這種箭頭亂點的分配情況較多並且長期存在的話，會很讓人凌亂。
④.專職專用而非一職多用
一個職位只負責一類工作，跟產品寫程式碼測功能做運維的職位是瘋狂而又冒險的。
⑤.一人一事而非人人都做“全科醫師”
這跟上一條有些重複的嫌疑，但上一條是就職位而言，這一條是就具體的人而言，重複的部分就當是強調了。術業有專攻，工作分工不僅僅存在於實物生產加工工廠，軟體專案開發中也越來越實現技術細分，即每個人只負責一小部分工作。因為時間差的原因，某些職位的某些員工可能暫時工作空閒，然後就會被調去做另外的事情。好的方面是給員工提供擴充套件其他能力的機會，但也很容易產生尷尬的境地。比如，能找到物件的男青年越來越少男科也越來越蕭條，而因為“二胎”政策來婦產科就診的婦女越來越多，就把男科醫生拉到婦產科打下手，於是生的娃越來越多了，兒科又缺人手了，就又去婦產科拉人……最後，就會形成拆來拆去的局面，一個人在自己不熟悉的位置上做另一個人熟悉的工作，而那個人則在自己熟悉的崗位上。
⑥.適應和習慣每個人的溝通方式
有的人喜歡什麼事都口頭溝通、有的人喜歡打電話、有的人喜歡用聊天工具、有的人喜歡發郵件，而同時有的人不喜歡甚至忌憚這其中的某些溝通方式，這是需要留意的。另外，每個人都有屬於自己的下班生活，能不打擾儘量不要打擾。
⑦.惡語傷人六月寒
不論是專案管理人員（PM或組長等），還是普通人員，當然主要是管理人員，說話表達應該要像寫程式碼一樣理過一遍後再講出來。這不得不讓我想起老“征途”有個叫“家族管理員”的NPC的一句歡迎語——“管理是一份高尚的職業”，管理者應該對得起“高尚”二字。當然這是從感性出發的。如果從理性出發，管理也應該是需要技巧的，可以稱為管理的藝術。這種藝術就是應該要調動每個人的工作積極性，忘我的工作；而不是讓員工失去對工作的熱愛，放下對自己所堅守崗位的敬意。
作為一個運維，可能比軟體開發中的任何其他崗位都能感受到一套適宜而行之有效的專案管理體系是多麼的重要。畢竟，這是一個背鍋又補鍋、吃力又操心、救世界於水火而又總被忽視的職位。如果專案管理得當，運維就會幸福一點。因此，這篇文章就談談與之相關的東西。最後，當然再次強調，本文並非有章可循的學術成果或者經驗之談，而只是個人的感想，想到哪寫到哪。