2014年3月中旬離開了自己奮斗三年的公司，這是一家海關政府公司，三年里無論是做項目需求分析、項目開發、項目測試、項目上線實施、項目上線跟蹤、收集反饋、做項目版本修改，我和我的團隊都在一個有非常明確目標、有非常明確思路的過程中，大家齊頭并進，團結一致的去為了滿足客戶需求而奮斗著（當然也是在為工資奮斗著，哈哈！）。對于項目中的每個環節，我的項目經理是一個資深海關業務項目的開發人員，團隊中一個決策的關鍵人物，對于技術的把關、業務的把關、我們都是需要向他匯報，同時也是問題解決的關鍵者，在這個團隊中我們有3個開發業務后臺（系統交互）、4個開發業務前臺（c/s界面） 兩個領導分別把關后臺和前臺，當年我們開發人員內部也是經常交流和盤問對方的狀況，談不上結對編程，但也是每周會有個內部例會來把我開發進度、問題等。對于這個狀態3年里一直貫徹和執行著，所以項目非常有效的進展并最終上線，一個歷時開發1年多的項目終于交付客戶使用也是我成長和鍛煉最為開心的一年。

來開這家公司后，我進入一家依托SAP B1做軟件代理開發的公司，起初對于這個還是模糊至極，但是后來發搜集了好多SAP的資料和新聞后頓時覺得要有很多新的技術挑戰和好玩的東西來等著你。然而后來發現我錯了，進入公司4個月，我決定今天總結下這5個月了自己犯過的一些錯誤和看法來提供給博友們希望大家歡迎討論。

我是3月底進入這家公司，公司第一天就趕上SH的一個同事來講我們開發的東西頓時覺得有點小激動，開始介紹例會內容時，他的定位是我們要開發一個產品（待會分析下和項目的不同），這時我們是3個人，我（激進派、追問派（后來發現這樣不好，不利于產品開發））、一個架構師（學術派、理論派）、一個開發（懶散派、表象派），對于這位演講的人提的需求我簡單描述下如圖

對于這個需求簡單描述下，因為不能透露更多，但是從這個需求中分析，我們的使用客戶是面向不區分語言、不區分人員機構、不區分機構人員組成結構、不區分機構人員的操作行為的，因為就是什么都要靈活配置。開始我覺得不太可能，但是我看到SAP B1之后發現原來是有這個可能，好吧下面輪到我們技術人員了，描述下我這個苦逼技術人員的開發歷程。

我們的產品是一個基于B/S Web的項目，對于這點呢，我主導了項目解決方案的主要搭架（不是有架構師么？我只能呵呵了）解決方案采用了還是比較裝逼的三層吧，業務邏輯層，視圖層、數據訪問層、對于業務層和試圖層提取一個抽象工廠來提供視圖層所需業務類的調撥，對于幾個比較關鍵的技術點是界面語言切換問題，我大概用了一周多時間開發完（第一次么，都沒有經驗你懂得 哈哈！），對于可以實現自定義字段么？我只能呵呵了 這個實在是太難了？我只能做到配置，但是配置完的數據綁定顯示到頁面還是困難重重，現在還沒不會做，字段配置只需要一個存儲就可以了，然后提供一個維護界面。對于系統交互么，我是開發了三年的WCF，我提出了我的解決方案，但是最后開發完demo之后，項目領導說去開發業務去吧。這個解決方案的過程大概持續了一個月將近，其中最浪費時間的是與幾個同事的配合吧！因為技術他們只能說是你要給他培訓了，我覺得我用的這些，asp.net mvc 4 、entity framework 4、jquery 、jquery easy ui、ztree 、jqgrid、fastreport?這些東東不是有太多技術含量吧（博友們說呢）？

好了進入5月份后開始完數據庫的討論（哎 這個是那個架構師搞得 被他玩慘了），我覺得一個好的軟件系統，三個方面1、好的數據庫設計2、好的需求設計3、好的團隊開發實現，

這個數據庫的設計我羅列以下幾點吧，

1、表最好不要用聯合主鍵提供一個單一主鍵，操作和維護都方便，用代碼層次控制數據的唯一和校驗

2、表數據字段如XXX代碼，最好有編碼規范，不要讓用戶亂維護（雖然是產品但是我們也有點話語權吧）如現在一個問題公司和部門子父級結構他們的代碼隨便填時

公司0001 ? 部門0001 所屬公司 0002?

公司0002 ? 部門0002 所屬公司 0001

這個遞歸，你們看看！

3、設計的數據庫最好有個體現需求的描述文檔，每個需求體現在哪張表上，不然像現在一樣，有些需求通過之前的表設計，串不起來了哎，有些表可以廢掉，有些表需要加，有效表需要加上字段

就這樣我們就開始開發了，沒辦法還！

數據庫將近半個多月設計的第一版后開始6月份，這時這個架構師hold不住了，開始走人了，我也是想走過，但是之前做的代碼努力還是不甘心覺得需要在努力挑戰下，于是接手他所有手里的活（當然也沒什么活，大哥一行代碼沒寫，文檔呢也是斷斷續續），后來我開始了新成員的組建，這樣6月中旬找齊了新的兩個開發一個測試，繼續下面的任務的開發。

把前期需求，產品規劃，現有代碼結構通過EA畫的用例圖、組件圖、類圖用兩天的時間描述完團隊進入開發階段。8月中旬開始完這個第一版吧。但是公司又來了個架構師，一個想轉java平臺的架構師，只是說我們的界面不好看（這怪我么？）、（我們的有些需求不能串起來）、這個框架不能滿足10月份交差的需求、確實是他拿了自己以前做的東東給老板看了，那是什么東西（一個集團公司開發了2年的東西來和我們這個3個人開發兩個月的東西比，我靠有可比性么？）。

就這樣我覺得我失敗了，對于失敗的總結我如下分析吧

1、技術不是裝逼用的，是滿足客戶需求的，滿足客戶想要的就行，他不關心你用什么技術。

2、產品不是你一個人能管理把控的，而是一個市場、團隊好多人需要共同努力的

3、不要在沒討論完需求的情況下去開發只會傷害自己

4、數據庫設計前一定要求需求模型或文檔（需求上的內容描述、字段描述和需求數據間的關系描述）除非你是一個懂需求的人

5、不要應用你不熟悉的技術領域去開發產品（除非你有些好的同事共謀）否則只會坑掉你自己

6、其實有很多裝逼人搞技術，你要么別跟他合作、要么早點揭穿，否則最后拍拍屁股走人，還是坑你

7、產品是階段性的項目過度設計和過度挖掘不利于開發和實現

8、技術積累隨時要總結和完善這樣才有利于技術的成長

?

轉載于:https://www.cnblogs.com/qianthinkover/p/3946213.html

總結

以上是生活随笔為你收集整理的谁动了我的产品的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。