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