剛在一家公司離職，因為公司上市后規(guī)模迅速狀大，急于開發(fā)幾款戰(zhàn)略產(chǎn)品支承，公司高層對我們之前進行的一個項目非常重視，投入巨大。系統(tǒng)開發(fā)之初需求原本很明確，但新的需求總是在開發(fā)的過程中不斷地被提出，今天來了個推廣部經(jīng)理，明天來了個市場部總監(jiān)，各有各的想法，并且各個部門、分公司經(jīng)常找開發(fā)小組開會提出新的需求變更。由于項目經(jīng)理的“軟弱”，我們一般很難拒絕。因為老總總是要先看到做出的效果再提意見，所以項目做的很急，系統(tǒng)框架在剛開始設計時沒有被充分討論、簡化，感覺在后續(xù)開發(fā)中遇到很多問題，

　　現(xiàn)已離職，也無所顧忌，特談一談對系統(tǒng)分析的看法，總結一下之前的工作的經(jīng)驗，有不當之處請指正。

　　做需求分析，我覺得最重要的任務是簡化業(yè)務流程、規(guī)則、邏輯；豐富用戶體驗。

　　0. 盡量將復雜的用戶需求抽像成最簡單的業(yè)務規(guī)則、數(shù)據(jù)庫結構來實現(xiàn)。因為需求是不可能一下子就確定的，假設我們剛開始對核心需求的實現(xiàn)方式增加了一點點的復雜性，比如說多加了一個表，一個藕合字段，那么對于以后的擴展我們就有可能要去制定更加復雜的規(guī)則去適應，從而“被逼”消耗更多的工作，使用更加復雜的結構和業(yè)務規(guī)則。尤其當需求發(fā)生不斷變化時，改變這種體系所要花費的代價也會隨之幾何級上升（因為一般是不可逆的），用戶的可操作性也會隨之越低，并增加了其使用上的難度，從而不得不對其進行培訓。

　　1. 對于一個面向公共（大用戶群、非公司內部系統(tǒng)）的系統(tǒng)，要充分進行“二八“劃分；一個系統(tǒng)不可能滿足所有人的需求；要關注最廣大的80%的用戶，因為另外20%的需求很可能會使另外的80%的人產(chǎn)生困擾；一般人最容易記得7個字以內的句子，同樣大部分軟件只有20%的功能是經(jīng)常使用到的，對于互聯(lián)網(wǎng)公眾平臺來講對另外不常用的80%需求的“重視”，只會分散開發(fā)人員的注意力，使用戶體驗、易用性、可操作性下降，并增加系統(tǒng)復雜性、維護和運營成本；因此要將主要精力放到那20%功能的開發(fā)上。

　　2. 對于核心產(chǎn)品，業(yè)務規(guī)則和邏輯的設計萬不可草率，并且不要集中由“一類”人去做；要從全局的角度制定業(yè)務流程，最好一開始就將最終使用者和開發(fā)者納入業(yè)務流程、規(guī)則、邏輯設計隊伍。并充分討論精簡后完成產(chǎn)品的整體構架設計，然后進入編碼階段。綜合考量成本/效果的比例，舍棄對系統(tǒng)可能產(chǎn)生混亂的設計，并想辦法最尋找簡單的替代方案。而且盡可能一開始就確定數(shù)據(jù)庫的主體框架，而非去制定每一步的細節(jié)。

　　3. 對于功能寵大、業(yè)務復雜的系統(tǒng)，我認為用戶需求接受比在 5:3:2 左右是正常的，相當于10條需求中有5條可以完全接受的，有3條需要將實現(xiàn)方式略加改變而達目的，但一般有1~2條無法實現(xiàn)是正常的，因為可能會對系統(tǒng)造成較大的復雜性或不利于擴展，而且很有可能跟現(xiàn)有系統(tǒng)的功能產(chǎn)生沖突。不利于系統(tǒng)結構最簡化，增加系統(tǒng)運營成本的不可控風險。

　　4. 當公司的主打產(chǎn)品經(jīng)歷過數(shù)次功能擴展、升級后，而造成的構架復雜性、數(shù)據(jù)庫負載、穩(wěn)定性、可操作性和用戶友好度下降達到一定程度時，就應該考慮將關聯(lián)性不大的功能分離成相對獨立的幾個系統(tǒng)，只進行核心數(shù)據(jù)表進行共享，以此增強各個分系統(tǒng)的可重用和可靠性。從而避免只向一個大型系統(tǒng)輸出復雜性，造成可靠性下降，以及維護、運營成本的上升。

it知識庫：總結的一些系統(tǒng)分析的經(jīng)驗，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。