1. 程式人生 > >軟體專案開發過程中主要遇到的核心問題小結

軟體專案開發過程中主要遇到的核心問題小結

1、軟體專案開發合同的訂立,合同需要對將來幾個月甚至幾年需要做的事情有個明確的定義說明,限定好工作範圍、工作內容、承擔的責任、專案總費用,每個階段支付的費用都需要有明確的說明甚至付款條件等都需要一清二楚,很多東西都沒講明白是將來合作不愉快的導火索,這些都需要白紙黑字寫清楚,其實從合同上也能看出甲乙雙方的水平在什麼層次上的。

2、軟體開發過程中,往往會發生客戶不按時支付費用的事情,因為軟體開發不只是腦力活兒,也是強度非常大的體力活兒,難免會遇到不能按時交付軟體的可能性,除非遇上非常有經驗的能相對準確評估工作量、工期的管理人員,參考歷史的開發經驗、再按自身團隊的開發技術能力、協調工作效率,計劃出一個合理的工期計劃來,因為整個公司都需要考慮到資金安全、開發風險,需要有一定的水平能說服客戶及時付款,至少可以支付大部分款項的人,在開發軟體專案的過程中往往會發生需要墊資幾十萬的事情,其間需要做好防備工作需要防止資金鍊斷裂了。


3、軟體開發人員中途離職也是家常便飯,相對規範的公司,一年也大概也會有10%的人員流動性,若薪資待遇也不怎麼樣、公司管理也不規範,開發人員也學不到知識、業務也不穩定的,那估計有50%的流動性也是很正常的事情,連微軟、Google都會有開發人員離職現象,更何況一個不知名的公司,人員離職是很正常的現象,但是人員離職了就得需要有後備開發人員,公司管理人員需要在最短的時間內招聘到合適的人員,這也需要必備的技能。

4、現在已經不是單槍匹馬就能搞定中型軟體系統的年代了,一個軟體專案開發過程中往往需要N多人蔘與,客戶對軟體專案的質量要求,功能要求也越來越高,不只是需要把程式寫好,還需要有各種配套文件,測試都需要跟上,所以這些人的協調工作、及時溝通也是很大的問題,若一個專案經理的溝通能力有問題也很容易遇到很多沒必要的麻煩,也會使得專案進展會很不順利的局面,甚至到有敵對力量產生的程度,一個公司,一個專案最怕的是內耗,我們國家其實很多東西也都浪費在內耗上了,若沒幾千年封建王朝的內耗,我們應該會發展的比美國強大很多。

5、合理的安排工作計劃、有目的有計劃的做事情,很不容易,專案裡需要完成的工作NN多,需要協調的人員NN多,需要設計實現的功能NN多,做一個軟體專案並沒有學習程式設計那麼輕鬆愉快,更不項打網路遊戲一樣輸了還可以從頭再來,軟體專案開發是不允許輸了再來的,輸了就需要按合同進行經濟賠償、又要丟人、又容易吃官司、還無法在這個圈子裡繼續生存了,至少會口碑很差了。

6、進度的把控比制定工作計劃更難,我們可以制定個計劃2012年開發好作業系統、2013年開發好資料庫、2014年開發好編譯器、開發環境,看上去很美,其實更本沒那個能力實現這個計劃,計劃計劃難免會有變化,計劃目標需要不斷地調整,但是調整得太大,那說明這個計劃有問題不符合實際甚至是有些空洞的計劃瞎搞搞而已,開發專案過程中需要分工合理,有一定的穩定性,例如今天讓你ASP開發,明天PHP開發,後天C#開發,大後面又是JAVA開發,估計沒幾個開發人員不會被折磨瘋了,工作分配也是一個道理,需要有一定的穩定性。及時的驗收確認好工作安排也是需要有水平的,若開會問大家任務完成了嗎?大部分都會說“快好了”,快好了可以理解為,已經完成了10%?已經完成了90%?但是剩下10%是技術難題,超級複雜的功能,那其實這並不是完成了90%,雖然開發人員理解為90%,但是可能10%都不到而已。

7、高效的會議,解決問題需要有效率,特別緊急時需要有站立式會議,專案緊急時也需要安排每天的會議,會議不適合超過20-30分鐘,甚至10分鐘內開好會議是最理想的,例如我們10個人參加會議,會議開了1天,那其實是超級浪費生命,如何高效的指揮大家,如何開一個高效的會議,責任明確的,能解決問題的會議是需要有一些水平的,若以前參與過牛B管理人員主持的會議,那很容易有經驗了,參考別人的好處多多。

8、軟體在開發測試階段往往會有客戶的需求變更,甚至有可能會有大面積的需求變更,每變更一次需求,客戶會覺得這個是簡單的變更,開發人員會說是超級複雜的需求變更甚至會說前面的工作都白做了,這時候需要有超級強的溝通能力,一方面儘量阻止客戶發生沒必要的變更,甚至徹底想清楚了再變更,每次變更都有文件記錄,好向客戶追加軟體開發費用,其實這個除了大客戶、實際強的客戶外,想追加費用是難於上天的事情。只能是跟客戶處理好關係、下次客戶還能找你就不錯了,客戶的錢也不是飄來的,預算也是有限的,所以若不想把客戶得罪了,還只能按著客戶的變更來、頂多是把事情都講清楚,這部分變更帶來了多少工作量等等,至少按合同支付費用時,能有個協商的籌碼對吧。

9、採用成熟的軟體元件也會大大的促進軟體專案的開發進度,這次我們工作流自己開發了一套B/S的,在網頁上拖拖拉拉就可以設定好工作流的,自己也比較滿意的效果,但是現在想想有接近足足開發了5個月,這個開發成本算 開發人員的工資 + 公司的房租、辦公費用 +相應的管理費用 + 測試成本 ,遠遠超過了6萬以上的成本,只是這個錢沒一次性拿出,而是每個月一點點的往外付出而已。而且還花費了5個月時間,還不能確保沒任何錯誤,其實到真正穩定好用,至少要燒掉10萬了。若從專案開始開發就用合理的價格購買了一套,不用5個月時間自己開發,而是用1個月時間學會怎麼用,然後剩下的4個月時間放在核心的業務系統的開發上,專案會相對來說更輕鬆、更順利一些,畢竟戰線就縮短了很多了,可以集中優勢兵力重點突破。兵力分散乃大忌也。

10、專案經理的帶頭作用是不可低估的,若碰上一個天天吃喝嫖賭、天天遊手好閒的專案經理,那這個專案的最後的結局就是等著賠款就可以了,其他人員看到專案是這樣的人沒幾個SB會拼命幹了,大家頂多裝裝樣子,混混日子找找那裡有更好的前途了,這裡就是不是久留之地的念頭沒幾天就產生了,我自己曾經就遇到過這樣的情況,我沒到半年就跑路了,公司沒兩年就關門大吉了,因為這樣的領導不是真正幹事的,頂多就是轉了空子碰到到了狗屎運而已長久不來。

11、技術疑難為題外包,專案過程中遇到了一些WCF配置相關的疑難問題,前後解決了10多個問題,還是無法順利搞定資訊加密傳輸、電子證書SSL安全配置等等,甚至兩臺電腦之間的TCP方式通訊上也遇到了問題,由於手上有300多個付費使用者,而且他們都是開發人員,所以把這個資訊一發布,馬上就有專家響應,人家2個小時就搞定問題了,支付了500元辛苦費,錢雖然少也是個心意,我也把問題搞定了,我的付費客戶也從我這裡賺到辛苦錢了,2個小時若都能賺500元,而且是自己擅長的事情,我想也足夠可以了,有時候選擇花錢辦事比花時間辦事更爽。

12、系統架構重構上也花費蠻多時間,由於客戶是要求在分散式環境裡執行系統,開發時又往往是單機上開發除錯,又沒充足的時間慢慢勾畫、慢慢設計,工作安排往往是排得滿滿的,系統的架構有時候需要進行一些調整,若剛開始開發時就架構不明確、思路不嚴謹,到專案的中後期,整個專案就會大亂,更本經不起系統架構的重構,當然這裡的架構架構重構更多的是小調整,若真的是大調整那說明剛開始的架構就是非常失敗的,專案由於不是1個人開發的,若是一個人開發專案那還好說,想怎麼調整就調整,現在是多個人開發專案,雖然不能比喻是航空母艦,至少像個護衛艦,想怎麼拐彎就怎麼拐彎不是那麼容易的。

13、程式碼規範,程式碼質量檢查,由於專案不是一杆子買賣,往往還擔負著後期的維護,甚至部分執行工作,若專案的程式碼質量不好後期會有無窮無盡的痛苦,把一些問題扼殺在搖籃裡,總比把問題培養大了,再去消滅得麻煩、頭大,所以專案的中後期一定要安排嚴格的程式碼質量檢查工作,可以找個工作效率非常高,做事情又相對仔細認真的人,來個地毯式轟炸,從頭到尾把掃一眼,很多有SQL注入漏洞、有重複功能的程式碼、命名不合理的程式碼等等還是會被發現很多,畢竟專案開發中參與的人多,人多了就很容易啥鳥都有了。

14、成熟的資料庫設計套路,其實資料庫設計也是一門學問,看起來簡單,真正想設計好也需要有硬功夫,也需要手藝精湛、技藝高超的。資料庫基本上還是目前開發各種管理系統必不可少的組成部分,甚至現在還是穩定的管理資訊系統的基石,所以資料庫設計是否合理、至少30-40%的專案是否順利穩定的分量是有的。

15、成熟的功能設計套路、函式命名套路、窗體命名、變數命名等等,也會大大的減少專案的開發週期,專案前期需要把例子程式都寫好,適當的進行一些培訓工作,然後讓大家模仿例子程式就可以了,例子程式不適合寫得超級複雜,功能超級強大,只要能把主要核心思想都表明了就可以了,最好還是拿個投影講一下比較好,這樣大家的印象也會更深刻一些。