寫給未來的自己看，文件逐步更新中。。。
當前國內企業都面臨的相同的問題，專案周期短、需求變化多，為了占領市場都要求專案能夠短、平、快，這樣給專案
管理帶來了很大的挑戰，從我經歷的幾個專案來看就是遇到了這些問題，也在這些問題上了很大的虧，今日得閒將之前
的經驗教訓進行一次總結。
一、正常，按照專案計畫上線的專案
1. 確定需求範圍（scope），詳細理解需求並給出需求分析文件
業務提出的需求，往往是只關注本次的需求點，他們並不關心程式系統中，因為這個需求所涉及到的開發的部分，
例如：本次需求需要增加乙個屬性（如：使用者備註）到訂單中，業務人員只會關心備註在什麼預訂環節加入，格式是什麼
但確容易忽略其他地方的影響，如果我的賬戶中訂單管理是否需要進行修改，及下訂單後對後續自動確認流程的影響等。
這些影響點都是需要了解系統和了解需求的專案管理者來進行評估，一旦這個地方沒有想到就會對後面評估工時，開發程式
造成很大影響，也許在都會影響到測試階段，這時候回頭在對遺漏的問題進行補充開發，是已經很鬱悶的事情，而且往往因為
比較緊急開發質量就會下降。
2. 通過需求分析文件，充分估計好工時，測試工時測試相關人員給出
業務需求一定要進行詳細的分析，並形成詳細的文件說明，此文件即可以以此來評估詳細的工時情況，也為設計開發做依據，
還可以為測試人員的測試用例等提供詳細的依據，一般在國內的一些公司，大的專案才有詳細的分析文件，我的建議專案無論
大小都還是需要乙個詳細的分析文件的，因為往往業務的需求文件只是業務人員在以業務運營為中心，或者已專案贏利為中心
編寫出來的文件，並不是真正能拿過來給設計、開發人員開發**使用的，需求分析文件要從系統的角度將業務的需求轉化為
設計開發使用的文件。
充分估計工時是否非常重要的，而且估計工時切忌一點就是工時估計不足，導致給後面的開發帶來很大的壓力，從我的幾個
下專案來看我自己的工時估計就是偏緊，有幾次都是把工時給估計不足，導致後面的開發加班、測試階段也要加班，到最後質量
也不是很高，也給專案上線帶來了很大風險，當然我也知道別不估底了，可是為什麼還會估計不足呢，我總結了一下，主要還是
沒有乙個詳細的文件分析，沒有把每一項開發內容都一一枚舉出來再估計工時，這就會導致一旦以乙個大目標來估計工時，一般
來說都是偏低的，因為沒有詳細分析一定會有遺漏的地方，這個是我的工作經驗告訴我。開發工時能正確評估出來後，測試要給
出合理的測試工時。
3. 制定好專案的詳細開發測試計畫
制定好詳細的開發測試計畫，詳細的開發計畫在專案管理中是否非常重要的乙個環節，這是乙個專案的控制的主線，詳細的
開發計畫給專案以很好的指導作用，那如何才能制定乙個詳細的開發計畫呢，我一般從各個環節詳細的開始，第一需求分析、
第二概要設計、第三詳細設計、第四開發階段、第五測試階段、第六部署階段。
我們重點說說開發階段的控制：
（1）分配組內成員的開發內容，在小型的系統中，或者未分層的系統中，我們都是按照乙個功能點由乙個人從前端到後端統一
進行開發，這個好處是功能和工作劃分比較明確，但是不好的地方也是挺多的，首先層次劃分會出現問題，導致分層和層次功能
不明確，有些邏輯層的邏輯可能就會到了前端展示層去了，這就破壞了層次結構，另外因為是乙個從前端到後端都要做開發，這樣
要求的開發人員的技術也是比較高，從當前的it發展來看，術業有專攻，能將層次分開，使用不同長處的人才才是比較好的開發團隊
本次我們採用mvc的架構，實現了前後臺開發分開。
（2）開發過程進行codereview工作，codereview是乙個貫穿乙個整個開發過程中的乙個非常重要的環節，他能保證**的規範
性和質量高低，codereview工作可以由負責人進行，也可以由組內成員相互進行codereview檢查，這樣也可以提高組內成員的水平，
codereview並不僅僅是找各個開發人員的開發問題，主要的還是培養開發團隊的專業水平，codereview也要抓住重點，如果在時間比較
緊張的情況下一定要對專案中重要和關鍵環節進行詳細的codereview工作，比如在系統的效能方面就要加大codereview的力度，保證
效能的質量，我們都知道實現乙個功能沒有不能完成的，但是完成的質量如何是有高有低的。所以是很需要進行codereview進行檢查的。
（3）單元測試不能缺少。
詳細內容後續。。。
4. 制定好專案的上線計畫
二、非正常，按照上線時間已定倒推上線計畫的專案
關於日誌列印的幾點建議
日誌的列印在軟體開發過程中必不可少，一般分為兩個大類 系統日誌 主要針對的是軟體開發人員 包括測試 維護人員 也就是說這部分的日誌使用者是看不到的，也就是我們通常所說的debug日誌。操作日誌相對比較好理解，使用者做了什麼就記錄什麼 而列印系統日誌則很多人無從下手，往往一般有下面幾個方面 where...
專案管理 技術人員不服專案經理的幾點建議
如果技術人員不服專案經理的幾點建議 1 如果管理者技術牛，或者懂一點技術，管理專案就容易很多。所以專案經理不僅要懂管理，還需要學習一些技術，不精通也要略懂。2 讓專案成功，就是最好的證明專案經理實力的方式。專案的成功，和參與專案的每乙個人息息相關，專案經理更是功不可沒。沒有專案經理對整個專案過程的規...
關於裁員幾點看法及建議
最近網易裁員事件引起廣泛關注，昨天網易針對此事，也發了宣告，到底誰對誰錯，孰是孰非？我們作為吃瓜觀眾實在是知之甚少，所以不敢妄下定論。身處軟體開發這個行業，近一兩年來，對於企業裁員雖早已是司空見慣，但每當看到被裁的遭遇，難免有種兔死狐悲的同情，憤懣不平之餘，我們是否可以從別人的不幸中，得到點啟發呢？...