问题的解决和完善需要心思缜密及参与者的相互配合和引导

       有一网友在在坛子里问问题，问题题干有些小问题，

       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。

       开始解决问题时，我们只考虑功能实现背景，姑且叫做代码背景吧。但到这个阶段我们会发现系统运行背景，它牵涉了项目数据背景。这个问题从功能角度上讲我们已经实现了，但附件删除功能的应用不仅牵涉的是审批流程的各个结点，考虑问题之初过于集中在了结点上，导致思想不开阔，没有考虑其他维度上的事情，应该考虑功能维度背景。

       有一次在项目上需要简单获取用户姓名，在问题讨论时发现交流的接口并不是同一个领域的，一个是自定义的，一个框架自带的。导致交谈双方感觉彼此分歧很大，总认为对方理解力太差，而问题的根源是彼此太过专注自己这一维度上的事情了，解决它的好办法之一是从问题头部遍历到到问题出现点。就像开始时两个人在坛子里讨论问题时所所得，要将原问题先给人看，在拿出自己加工过的内容会好很多。

       这几个很简单的小故事说了一件实现一个新功能及后期对其维护完善过程中方案支持者和方案实施者等角色要考虑和做的事情。而其关键在与彼此心思缜密的项目配合和引导。在这样的共识下，我们将问题提出来，问题的提出者在没有相同的背景知识时要将问题尽可能从根源起描述清晰。参与者相互了解，相互引导，使境况朝最好解决问题的方向发展。

       总之，问题有其过去、现在和将来，要对这些信息进行分析整合。同时要要结合这些背景考虑不同维度上的事情。考虑需求背景，思考问题性质及待解决问题；考虑运行背景，思考数据在实现问题的影响；考虑代码背景，思考其对后续功能完善的意义；考虑应用维度背景，不要将任何一个点（知识、问题、业务背景）看成一个点（考虑周边及联系）。