有时候，墨非成功定律还真准。往往自己太在意的东西，会给自己带来很多麻烦，也回带来很强的挫败感。
自从换了工作，一直以来就非常认真地对待。新的工作向我提出了很多新的要求， 比如需求分析，比如编程。我对这份新的工作充满了期待，因为慢慢意识到，我的工作量从某种意义上说，决定了其他人的工作量。自动化是一项艰巨的任务。从长远来说，完善系统是终极目标，一方面它要保证业务顺利进行，另一方面，还要降低成本，提高工作效率。对于我，一个从来没接触过业务的人来说，提出的需求可能会脱离实际，可能荒唐，也可能超越一般套路的东西，甚至是引发一场彻底的变革。不管怎样，量变的积累是需要时间的， 而质变的发生，运气，毅力，技巧等等，由多方面的因素决定。
所以提需求的过程通常不会一帆风顺，提交给上级的方式应该是温柔而循序渐进的。大的改变通常会引发一系列的问题，因为对业务的理解远远不如人家在这个领域里工作了好几年的，考虑得不够周全通常就意味着这个方案的否定。但是，循序渐进也不见得是好事， 实现起来可能相对容易，但出发点一旦不是从系统整体的角度出发，以后的工作会比较难进行。|
分销的解决方案，尤其是应收账款的处理，感觉在市场上不多见。SAP或ORACLE应该具有一定的代表性，但它们毕竟是软件提供商，不同于自己开发的系统，参数不多，要求业务与系统处理完全一致。再加上美国与中国的分工，还真有点管中窥豹的感觉，所以这几点都不可避免的会进一步加大需求的难度。
业务的进展困难，让我不得不把注意力考虑得近一些，现实一些。基于我们的工作模式，首先想到的就是在office里使用程序。我不太愿意写程序，因为它太具体，没有错误或误差的余地，再加上没实际经验，我开始有些犹豫。是同事的辛苦，成日的加班让我做了决定。写程序的过程还算有意思，没人指导，也没人纠错。 我一点一点的尝试，加变量，猜想语法，幸运的是，几乎每个我想实现的功能，都能想尽各种方法让它实现，效率以及准确性则可能会打点折扣。我想我算是也体会到了写代码的酸甜苦辣，也曾牺牲休息时间拼命工作，也曾为自己做出的成绩激动万分。程序确实伟大，如同互联网一样，似乎没什么不能实现的。于是我写下了“while there is rule, there is program(有规则，就有程序）”。写程序也要承担与之而来的各种风险。一旦发生错误，就要追根刨底，研究是手工还是程序的问题，有时真的很难分辨。我不愿意一遍一遍的去检查自己的代码，这似乎是所有编程人员的痛苦。开发部门的同事不赞成我们在系统以外做大量的工作，因为这些工作应该是通过程序在系统里实现，这样才能完善系统的功能。然而从公司的角度说，聘请开发人员相比而言，需要相当的时间和成本，那么就必须衡量完成这项工作到底是开发系统功能合算，还是通过人工数量手工完成划算，这同样也成为我工作的一部分。
从公司的角度说，让我一个来做这份工作，也充满着风险。也因如此，他们很谨慎，也很保守，这也是我的工作才难以加速的原因之一吧。
不能不说自己的全部精力都投入到工作中了，累。问题在于，不那么辛苦工作行吗？ 当然可以，可是，更累。所以，继续努力。