這個些列的文章只是把我個人的經歷記錄一下，裡面涉及到的觀點屬於個人觀點，如果不妥之處請多多指教。
續接著上篇(
一人團隊)：
草根程式設計師轉型做專案管理走過的點點滴滴之一人團隊
乙個人做完乙個專案後，按照時間順序依次是乙個三人團隊的專案；乙個一人專案；另外乙個三人團隊的專案。
第乙個專案可以說是只做了比較糙的一版就移交給分公司那邊去負責了。乙個人的專案讓我接觸了到了公司的水利主業務，積累了第乙個客戶。另外乙個三人團隊專案趕在11
年年底完活了，客戶使用了一年後在12年
12月的時候整體提了一次問題列表，還好當初跟我做專案的兩個孩子都還在。
step1：專案一開始的需求調研需要技術總監幫著一起做一下，這個過程也是自己拼命學習的地方，這個世界上不怕不會不擅長，怕的是你不去學習。
step2：專案技術架構
(姑且這麼稱呼
)，自己要有乙個總體思路，梳理清楚後，要向你的技術總監進行匯報，畢竟自己還很年輕，多需要前輩指點指點。隨後的技術架構的實現還是要由自己來完成的，確保正確了實現了自己的想法，並且盡可能使之健壯、易維護、可擴充套件。這期間可以把概要設計文件編寫完成。
step3：專案準備開始，根據概要設計向專案組人員表述需求；介紹技術架構，做進度安排
(自己也要參與到編碼過程中去)。
step4：編碼及測試，這個過程我認為是最重要的，也是最無序的。組員用程式表述的需求是否正確，組員編寫**的
review，ui
端的統一風格，整體的表現形式，操作是否更加客戶化等等，測試階段個人也要充當測試主力軍的角色，而且完全是憑個人能力在測試，沒什麼固有章法可依。這期間還有乙個特別重要的事情就是培養新人，畢竟自己是從最基層一步步的成長起來的
(有些大言不慚），希望把自己之前的學到的掌握到的關於軟體開發的正確的東西多多的傳授給他們，他們成長了我也就成長了。
step5：專案實施，培訓，專案的使用，驗收。由於一般都是公司領導的關係客戶，也經過我們幾個的努力，實施上線的時候客戶沒有提出太大的修改方案，只是為了讓專案順利驗收，我採取了幫著客戶錄入資料的做法
(感謝客戶幫我把資料準備好
)，這樣軟體系統了有了一定量的實際資料，驗收也就按部就班的完成了。
優勢：。三人團隊我選擇了三人一排坐的方式，我在中間，有什麼事情我們稍微移動下頭就可以組成乙個討論組，內部溝通很順暢，及時；溝通的同時肯定會帶來進步，三人行比我師，在培養新人的過程中我也從他們身上學到了很多。
劣勢：作為專案管理者的我那時候是最喜歡三人的工作組的模式，即滿足了我專案管理者的慾望，同時還保留了我技術熱愛著的狂熱，管理專案的同時我也積極的參與到編碼工作中去，而且樂於此，可是走過那段時光後，我也切身感受到了不合理性,
作為專案負責人，服務客戶、服務公司、服務專案組成員，讓專案以合理的節奏，順利的完成才是我的主要工作職責，不可深深的陷入到某一點，而失去了大局；還有乙個大的劣勢就是現在的工作方式顯得有些太過隨意
(雖然我個人認為三人團隊這種方式挺合適的
)，任何步驟都沒什麼章法可尋，隨便舉個例子，一旦專案人員流失了，很可能他們負責的部分就成了沒人敢觸及的地方；更主要的是公司領導也不希望有這樣隨意的工作團隊，他們更喜歡一切皆可把控的工作團隊。
隨後我會寫一篇五個人專案組的管理方法； 一篇七八個人專案組的管理方法；一篇十四五個人專案組的管理方法。 感謝陪我成長的每乙個專案。
草根程式設計師轉型做專案管理走過的點點滴滴之五人團隊
做快樂的程式設計師
1.是王。文件僅隨其後 所以，一定要和文件一致，並可以正確執行。2.測試，測試，測試。3.單元測試非常關鍵 每乙個在單元測試之後發現的bug需要開發人員雙倍的開銷。記住，我寧可增加你的薪水，也不願意把這些錢發給另乙個qa團隊然後你再修正bug。因此，如果你的 滿是bug的話，我不得不把錢付給更多的人...
專案管理之我見 程式設計師程式開發步驟
專案管理之我見 程式設計師程式開發步驟 專案遇到的問題 程式開發是專案的核心。因此缺少管理的程式開發，就不會作出成功的軟體專案。程式開發過程中，專案的程式設計師是根據已有的模組設計文件，理清思路，然後編寫程式。但是由於程式設計師編寫程式步驟比較隨心，導致可能出現對需求理解不清楚，又或者由於本身的水平...
寫給程式設計師的話 論專案管理
對於專案管理，對於初期程式設計師而言，我認為一直屬於一體兩翼。一體 以技術為根基。包括了語言 框架 平台 領域 業務等等，據具體 兩翼 一為pmp之類的專案管理階段，以及cmmi之類的標準管理 二為以工商管理碩士 mba 為首的公司管理。當個人職業達到一定地步以後，核心在於公司管理 研發 產品 市場...