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