飞机晚点了。
正好趁这个机会，整理下思路，
这些天居然以技术人员的身份杀入到产品和需求的讨论中了，
真是一个挑战。
对我来说，
之前看的一些软件工程，需求分析，产品设计的知识终于用上了。
即使这样，给我带来的改变是仍旧是巨大的。
第一次因为公事出差，
第一次说这么多话，
第一次忙的没时间写代码。
学会沟通
这些经历，让我理解到，
一开始把自己定位成一个程序的编写者，
是多么的狭隘。
也让我认识到，
软件工程师自称的不善言辞，
其实更多的是一种借口。
当我们不得不了解用户的问题，
当我们不得不修正根本不解决问题的解决方案时，
就必须学会沟通。
以身试毒
语言是思想的交流媒介，不是思想本身，
因此，即使进行再多的交流，
两个人的理解总是会有偏差的。
业务人员不知道我们能为他们做到什么程度，
技术人员不知道我们是否真的解决了问题。
这些都是需要交流的。
武侠小说中，
经常出现，神医为了解毒，以身试毒。
我现在觉得，这种胆略，才是真正想要解决问题的态度。
我做的了
当客观条件不允许时，
达不到专业的标准，是情有可原的。
正如一个软件系统，
如果工期太短，那么短期内的质量低下是不可避免的。
然而，当解决了用户的主要问题后，
剩下大把的空闲时间，如果不努力提高品质，
就是主观原因了。
经历这次讨论，让我学到无论做什么事，
都应该用专业的标准要求自己。
任何形式的『我做不了』，短期来看可原谅，长期来看就是慵懒。
成功者想办法，失败者找理由。
先活下来
最后，让我理解到的是，
软件必须首先能解决问题，能创造效益，
才有存活下来的可能。
一开始可能很丑陋，但是活下来了。
胜过一切漂亮的框架，优雅的结构。
一方面，通过分析需求的优先级，
解决真正困扰用户的难题。
另一方面，用这仅有的争取得来的时间，
提高扩展性，以适应业务的发展。
不要急躁
努力用最短的时间解决问题，是好样的，
然而，这并不能消除后期修正方案的可能性。
尤其是沟通过程中，
这很重要，
别人总是担心我们给他们看的就是最终的解决方案。
实际上，软件是活的，
事情是发展的，
业务场景，以及别人的理解也是变化的，
甚至市场氛围也是瞬息万变。
我学会了着眼于程度，
而不是判断。
如果没有完全解决，那么是否比昨天更好，
有没有进步。
逐步调整
理想中，只要切题，我们的方案一出，
用户的问题，马上就能得到解决。
它是那么有效，那么一阵见血。
然而，现实并不是这样的。
能做出什么样的改变，完全取决于目前的项目状态。
我们想的很好，
然而，能做的，只是进行有限范围上的调整。
要落到实处，方案就必须能和现有的系统接轨，
完全废弃一个系统是不可能的，
代价也太高了。
此外，我们必须能够改善现状，
才能证明我们可以做的更好。
把现在的事情做好，是证明自己能把其他事情做好的唯一办法。
团队无价
随着年龄的增长，我发现个人的作用越来越小了，
因为，同龄人是其他行业专家的可能性越来越大。
你在这个领域深入研究了10年，
另外一个人就完全有可能在其他领域深入研究了10年。
而从外表上是看，是无法区分的。
这跟学生阶段是完全不同的，
学生之间的差距更多的是同领域深入程度的差距。
因此，为了把事情做好，
我们需要各领域的专家一起交流，
这样的团队是无价的，一个人不可能面面俱到。
结语
飞机要起飞了。
先总结到这里，继续努力。