大型ERP廠商都有自己的自定義報表開發(fā)工具，它用來滿足客戶自定義取數生成報表的需求，用戶既可通過它寫一個SQL語句生成一張報表，也可通過它組合某幾張單據的資料生成一張報表，還可直接更改某張單據的表結構生成另外一張報表。這段時間我也在重構我一年前在公司寫的自定義報表開發(fā)工具，通過這次重構我對程序員的價值，軟件工程，項目管理的認識更加深刻了：
一、需求分析：
企劃給出的需求很簡單，即可以讓用戶通過如上幾種方式新增一張報表，然后掛到主菜單上。受限于知識面我們的用戶（即企劃）不能提供更多的說明了，不像業(yè)務功能他們可以想得很清楚，所以能根據他們的大概想法做出讓他們滿意的東西就是我們最有價值的地方了，其實軟件開發(fā)就是這樣，很多時候用戶只能給你一個大概的想法，有些他們可能還想不清楚，這時候作為一個項目經理或者是設計者你要做的就是先幫他們理清思路，然后做出他們想要的東西，這才你的價值所在，試想如果一個東西別人什么都幫你想好了，你的價值怎么體現？
二、系統(tǒng)分析：
一開始看到這個功能我粗略地評估了一下，沒什么難度，就是定義一個結構，讓用戶選擇一些表，然后設置關聯方式，查詢字段，排序分組，過濾等條件就OK啦，所以我預計一個月綽綽有余，但是最后做下來我花了兩個多月的時間（截止目前還有幾個功能未實現，當然有些需求也是陸陸續(xù)續(xù)提出來的），系統(tǒng)分析出現這么大的偏差我覺得主要有以下幾個原因：
A、方向有錯：
因為這里面涉及將自定義報表的這份描述結構轉化為機制已有結構（這樣自定義的報表的取數，排版，權限控制，掛接菜單就能與現有功能完美結合，非常統(tǒng)一），但我將這份描述結構理解錯了，導致最后利用SQLBuilder產生語法的時候才發(fā)現自己搞錯了，導致重工，所以現在指導別人或自己做的時候我都會先將整個思路理清楚，有疑問一起討論，而不是盲目動工，始終相信磨刀不誤砍材工。
B、細節(jié)太多：
能用跟好用是有很大差別的，只有做出來的東西好用，易用才能得到別人的認可，否則就是劈天蓋地的口水（最常見的就是“哇，這什么垃圾啊，這么難用”），如果你辛辛苦苦做一個東西被別人罵你心理肯定不是滋味，但從用戶的角度看你沒有做出他想要的東西，他不認同你是理所當然的。但是要做好一個東西也沒那么容易，很多地方你需要精雕細琢，精益求精，也就是我們平常所說的追求完美，而這些都是很耗時間的，所以這里面就涉及溝通的問題了，作為管理者我們應該知道組員時間花在哪里，為什么花那么多時間，做出了什么成果，碰到了什么問題，如何解決，是否需要協(xié)調行程，作為組員呢我們就是在適當的時機反饋這些問題，最后達到有效溝通，公司利益最大化。
C、溝通協(xié)調：
行程緊，當時看到這個功能DELAY了好久，自己也著急，作為資深人士一直DELAY我覺得面子上過不去（其實只要能給出合理的解釋這些都不是問題，品質才是最重要的），所以將一個半成品給提交上去了，結果可想而知。其實這里面涉及到一個溝通協(xié)調的問題，如果資源不足或預計哪里有出問題，應該及時跟主管及相關負責人溝通，提出自己碰到什么問題，要DELAY多久，是否需要支援，而不是將所有重擔都自己扛著，真的沒必要，我們是一個團隊，通過借助團隊的力量來解決問題是才是最好的解決方式。
三、編碼測試：
相對來講只要前期將系統(tǒng)分析做好了，編碼測試就是按部就班，當然實際開發(fā)過程中肯定會碰到一些奇奇怪怪的問題，如果這些問題影響項目進度或自己不確定方案則應及時跟相關負責人商討，而不是按自己的想法搞下去，如果一個人搞下去到最后出問題了你就是“罪人”（到時候別人會說你當時沒反饋過這個問題?。瑳]