問題的解決和完善需要心思縝密及參與者的相互配合和引導

       有一網友在在罈子裡問問題，問題題幹有些小問題，

       A首次提問：

       各位有兩個數，5,4，規則是5/4=1.25,1.25*2=2.5,1.25*3=3.75,1.25*4=5得到1,2,3,5四個數，怎麼寫

       B說：

      你應該這麼寫問題。各位朋友：有兩個數，5,4，規則是5/4=1.25,1.25*2=2.5,1.25*3=3.75,1.25*4=5得到1,2,3,5四個數，怎麼寫？否則，你的題很難理解，各位--》個位

      A再次提問：

      假如有兩個數，5,4，規則是5/4=1.25  1.25小於4乘以2,1.25*2=2.5, 2.5小於4乘以3 1.25*3=3.75, 3.75小於4乘以4 1.25*4=5     5小於等於5  得到 1,2,3,5四個數，怎麼寫

       B質疑：

      看了你第二句話，不知道你要說什嗎？你是程式員？首先，你的功能是什嗎？能詳細描述嗎？

      A給出自己的答案（此處省略A的答案）問錯誤出現在哪，B繼而說道：

      你不能先拿一個答案給人看，就讓人幫你分析問題在哪裡；我們首先看問題，在看答案是否正確。

       A稍作整理問：

        兩個整數，先整除得結果a，取整數部分，如果小於第二個數，則將結果a乘以2，再取整數部分，如果整數部分仍舊小於第二個數，則將結果a乘以3，依次類推……

       B笑答到：

       這不很好嗎？不就是個遞迴方法嗎？

       對上面的問題，我們不去看提問者要解決什麼樣的問題，也不去解答這個問題的答案，僅就這一來二回之間我們能看出什麼呢？

        解決一個新問題前需要經過反覆的討論論證來準確定性問題，探尋出最為合適的方案來解決問題，在完善一個問題時也需要同樣的過程甚至需要話費更多的心思，尤其是在問題解決者更替的情況下。在OA與BPM項目中附件是一塊重頭，在某個系統中，附件刪除功能是後添加的，即對附件功能的完善。

       附件刪除功能要做的事情是在現有系統基礎上，允許附件上傳人刪除在當前流程結點（step）上傳的附件。開始實現附件刪除功能時，我們需要瞭解以下問題：

       1）瞭解各流程結點是如何對應表單的，每條流程僅對應一個表單，還是每個流程結點對應一個表單？

       2）瞭解每個結點附件上傳過程

       3）瞭解每個結點擷取附件過程

       4）瞭解每個結點dispatch到下個結點的過程

       5）特殊對待start結點（也許它在應用程式中稱為“擬文”、“申請”等，在提交時便啟動了所對應的商務程序），其特殊性在於它沒有在已運轉的商務程序內，僅是商務程序運轉前的一些處理。

       上述問題涵蓋的是待解決問題的來龍去脈，只有知道知道附件是怎麼來的，才能懂得它該如何沒了。知道了這些解決問題便輕鬆了很多。

        附件對目前使用者是否具有可刪除性，涉及的是該使用者的許可權，使用者此時具有刪除許可權則可以進行刪除，加上許可權管理的話，我們可以在此處擷取使用者的許可權，而後在進行操作。具體是否從全域許可權的角度去做還要看具體項目和設計，此處僅用簡單的標識來表明該附件是否為曆史附件（除上傳結點以外的所有結點看到的附件都歸為曆史附件）。

       僅就解決問題中標示做簡要說明，在以往的文章中提到過不要小覷屬性為null的意義，在項目中null我們是可以賦予其業務語義的，其好處及運用方式值得思考。在解決附件刪除功能我們使用曆史標識來確定附件的可刪除性。

       第一次，我將曆史附件標識為history，而標示為null則為新添加的附件。標示為history則不能刪除該附件，否則可以對其進行刪除。簡單看上去，其邏輯蠻合理的，加上之前對上述五個問題的瞭解，能夠很快的解決問題。

      而如果我們考慮一個項目背景——項目已經上線使用了半年時間——便會發現解決附件刪除的解決思路是可取的，但標示的意義有些問題。系統運行過程中已經產生了大量的曆史資料。系統中已經存在的附件已經成為曆史附件（大略的談。多數已是曆史附件，但當前結點的附件仍舊是可以刪除的，這個問題可以通過其他途徑解決）使用null為新附件的標示，則之前系統的曆史附件將成為新附件，與事實不符合。所以應將曆史附件標示為null，而新附件標識為new。

       開始解決問題時，我們只考慮功能實現背景，姑且叫做代碼背景吧。但到這個階段我們會發現系統運行背景，它牽涉了項目資料背景。這個問題從功能角度上講我們已經實現了，但附件刪除功能的應用不僅牽涉的是審批次程序的各個結點，考慮問題之初過於集中在了結點上，導致思想不開闊，沒有考慮其他維度上的事情，應該考慮功能維度背景。

       有一次在項目上需要簡單擷取使用者姓名，在問題討論時發現交流的介面並不是同一個領域的，一個是自訂的，一個架構內建的。導致交談雙方感覺彼此分歧很大，總認為對方理解力太差，而問題的根源是彼此太過專註自己這一維度上的事情了，解決它的好辦法之一是從問題頭部遍曆到到問題出現點。就像開始時兩個人在罈子裡討論問題時所所得，要將原問題先給人看，在拿出自己加工過的內容會好很多。

       這幾個很簡單的小故事說了一件實現一個新功能及後期對其維護完善過程中方案支援者和方案實施者等角色要考慮和做的事情。而其關鍵在與彼此心思縝密的項目配合和引導。在這樣的共識下，我們將問題提出來，問題的提出者在沒有相同的背景知識時要將問題儘可能從根源起描述清晰。參與者相互瞭解，相互引導，使境況朝最好解決問題的方向發展。

       總之，問題有其過去、現在和將來，要對這些資訊進行分析整合。同時要要結合這些背景考慮不同維度上的事情。考慮需求背景，思考問題性質及待解決問題；考慮運行背景，思考資料在實現問題的影響；考慮代碼背景，思考其對後續功能完善的意義；考慮應用維度背景，不要將任何一個點（知識、問題、業務背景）看成一個點（考慮周邊及聯絡）。