這一次的經歷和以前一次的項目經歷有些相似,全部就打算記錄下來,首先是引起一下本身的思考,二來是做爲交流之用。前端
座標齊齊哈爾市的一家大學生創業公司,此次的客戶是一家房屋安全鑑定公司。程序員
開發一套工做流程化在線 B/S系統web
後臺基於角色的控制訪問權限算法
訂單入庫安全
動態生成 word搜索引擎
利用高拍儀上傳編碼
主要說一下這個項目是如何開展的。設計
在一次電視臺採訪過程當中,老闆將這個項目下發下來,剛開始的需求就是一張工做流程圖,沒錯就是一張簡單的流程圖,上面包括了前臺接單一直到出示房屋安全鑑定報告的全部流程,而後就在也沒有其餘的了。索引
老闆與對面的負責人(主任)進行了一次探討,並無留下紙質文檔,而後回來告訴咱們需求,項目經理(因爲是大學生創業沒有經驗)通過一個星期的分析,給了我12張圖片。圖片
設計大哥根據12張圖片作出了效果圖,前端切圖作 HTML 發給我以後開始作,因而顯而易見,第一個版本被 PASS。
在項目開發過程當中,我按照圖片作出初版後交給對方負責人審查了一次,中間悲劇了,因爲這個公司並不是其負責人一我的說了算,出錢方介入(畢竟如今有錢的都是大爺),對整個系統進行了全方位立體式的解讀,獲得的答案是幾乎全部模塊進行重寫。
在項目初始過程當中,沒有與客戶進行有效溝通,沒有問出根本需求,通過三次溝通後才確認下來,原來該公司只是爲了不員工私自蓋章出示報告避免未來出現法律糾紛。
在整個軟件研發項目中,需求分析我我的認爲應該是重中之重,這直接影響了項目可否順利落地,以及往後的工做進度。
因爲沒有完整地需求分析,在研發過程當中,在研發過程當中就會形成開發進度緩慢的問題,如下是我列舉出的我所遇到的問題:
多餘思考大於編碼
功能模塊沒法肯定致使大量返工
沒法準確判斷工期
這三點互相依賴,應該不須要過多的解釋。
沒有需求文檔,程序員將進行獨立思考,影響開發進度,我在開發過程當中基本上碰到一個需求問題就會發問,這期間影響了三我的的工做時間:我、產品、對方負責人。
問題的解決途徑:
搜索引擎
社區
文檔
聯繫技術人員
因爲惰性思惟,首先想到的是搜索引擎,惋惜最終發現大多時候經過搜索引擎進行解決問題的效率並不怎麼樣。因爲百度的推薦算法會將一些權重較高的文章排在前面,因此不少文章的時效性並不強,大多都是幾年前的,因此用處不大。
經過搜索引擎解決一些基礎性的問題還好,可是若是所使用的庫是國外的,那就很糟糕了。
正所謂有人好辦事,這一句話放在那裏都通用,可是卻不能將其高估,由於全部的問題都是有侷限性的,由於經過社區發問帶有一絲運氣成分,你不知道你的問題是否有人碰到過,就算是碰到過是否跟你目前所在的處境是否相同。
這一點很重要,文檔纔是人們最終的歸宿,因此在咱們選擇庫的時候,首先要選擇擁有良好支持,文檔健全的庫,要否則碰到問題只能本身去查看源代碼。
這個就有侷限性了,若是是開源做品,因爲一些簡單問題去打擾做者是一種浪費彼此時間的事情。
當遇到問題的流程,我認爲的順序應該是:文檔->社區->搜索->做者。
做者的博客:www.maksim.website