在做項目的過程中，漸漸體會到了項目中的一些風險因素。在項目中參與了很多過程，有的還在繼續着。需求分析，數據庫設計，架構，編碼，測試，維護。也許正是參與的過程多了，在看待一個項目的時候，就不會僅僅像剛做項目那會，分得一個模塊，按照規範按時做完，提前最好。做完一個，做下一個。那時有點“目無全牛”的感覺，項目的其他人和事都很少去關注，也沒有那樣的機會。現在不同了，參與的事多了，責任大了，關注點也不可能只停留在if，else上。項目的整體把握對我來說變得日益重要了，沒選好方向，做好規劃，到了那時，會有搬起石頭砸自己腳的懊悔。這些都會成爲項目的風險因素。即是風險，可以說是影響項目目標的達成的。那我們做項目的目標又是什麼呢？也許影響目標的一個最根本因素是時間，因爲很多因素都會影響到項目的進度。在項目中遇到了一些影響項目進度的因素，如：
需求的頻繁變動，這也許算不上，因爲需求的變動也是正常的事。但這要說的是，需求的變動要是可掌握的，既要否定一些沒必要的需求，也要對變動的需求，新增的需求做出合理的安排，輕重緩急，完成時間等等。有些需求也許會有矛盾的地方，有的改動動靜大，是不是放到項目的第二期.因爲在項目中經常遇到，根據客戶新的需求做的計劃，過了幾天又要重做計劃，當然新舊計劃是有明顯不同的。甚至很多功能做到一半停了，去完成一個新加的加急的需求。需求是源頭，我們應該投入更多的關注。
架構，技術選型，這點其實和需求是緊密相關的，還有一個相關點就是技術人員的能力了。能力強的技術員，自然更能設計出好的架構，選到合理的技術原型，滿足現在的需求，也能更好的擴展，維護，去適應新的需求。項目做得越久，就會越覺得當初的設計有問題。有些甚至讓人頭痛的。在任務重，急，人手少的情況下，更能體會到那種頭痛，有很多時間話在選擇上了，是改框架，還是打補丁式的趕緊完成新需求。很多情況下，被逼的沒法。就先實現功能了，安慰自己以後抽出時間，整體改下。而這樣做出的功能，是很難保證穩定性的，而以後再加新的功能也會更難，維護也更難。在技術選型上更需要全面合理的考慮。經常遇到，在選用一種技術時，沒有進行足夠的比較分析，學習成本對比，掌握程度的對比，匆忙間選用了一些技術，組件，框架，短時間內可以滿足需求，時間一長，問題就來了。很多東西都要返工，時間精力多花了，項目進度取延緩了。這些都會使你以後花更多的時間精力去維護，去繼續項目，這也成爲了項目完成的一個風險。
成員的選用，管理，人員組成最好是合理搭配，根據項目特點選有特長，側重點的人。項目組裏希望都是高手，效率高。但這是很少有的情況，一個項目裏總會有新人。這就需要做好必要的培訓，和做好項目的規範了。特別是編碼規範，否則很難保證新人寫的代碼符合設計者的要求了，也很難與高手去溝通。分配任務的時候，不僅要根據個人的能力水平，還要考慮個人的溝通能力，承受壓力的能力，性格特點等等，有些任務需要幾個人合作完成，看見過其他項目部的人因合作有問題，而吵架。而有些人技術能力達到了要求，卻承受不了什麼壓力，一個任務急，繁瑣，他就煩躁，工作很難完成，有的甚至直接退出了。而性格也會影響開發，有的人喜歡單幹，做完了。發現不合要求，是閉門造車。當需要幾個人合作時，前期不溝通交流，埋頭賣力做，做完了發現和別人的的銜接不了，級聯不了。也許他改下更容易銜接了，但不願意改，而是叫其他人改，叫別人來配合他做的。這樣的人多半是孤傲的。這些都需要項目負責人去關注，去避免，否則會成爲不小的風險。
當然還有一些其他的風險，值得我們去關注。項目過程中總是有那麼多的煩心事，需要我們去處理，需要更多的責任感與毅力去支撐。