软件工程师们每天都会遇到各种各样的问题，
我们中的绝大多数人，日常的工作内容就是把这些问题解决掉。
不论是修复一个代码缺陷，还是开发个新的功能，又或者是启动一个新的项目。
回顾多年的学校教育，无形中让我们养成了以下这样的思维习惯，
那就是，针对一个给定的问题，快速的找到答案，
这使得我们容易在考试中获得高分，以致于让我们有机会接受更好的教育。
适应环境，从而沉淀出一套最有效的思维模式，
这确实可以算是优秀人士的一种衡量标准。
然而，这种思维模式一旦被不小心用到了其他环境中，
那么带来的恶果将是惨重的，
甚至还是难以觉察的。
1. 发现问题
急着去解决问题，而不去分析问题本身，是一个最常见的思维惯性，
因为在校期间，我们遇到的问题都是严格定义的，
不太会出现问题本身出现差错的情况。
但是现实中，却远不是这样，
现实中的问题，更多是不确定的。
例如，一个想要实现工作流引擎的团队，
他们的业务场景可能并不需要让工作流可配置。
那么它们到底为什么要解决这个问题呢？
这就是典型的问题本身不明确的一个情形。
在这时候，我们就需要给“问题”下个合理的定义了，
到底什么是“问题”？
斋藤嘉则在《发现问题的思考术》中提到，
所谓“问题”，就是“应有的景象”与“现状”之间的“落差”。
1 | 问题 = 应有的景象 - 现状 |
而解决方案是否有效，完全取决于问题的定义方式。
如果团队仅仅是为了应付经常变动的业务流程，
那么首先应该考虑的是，为什么业务流程会经常变动，
而不是考虑如何用技术手段使得它可以任意变动。
此外，换一个角度，如果团队的目标根本就不是为了解决业务流程问题，
而是为了做出一个技术产品，来提高团队的影响力，
那么开发工作流引擎，也未尝不是一个可行的办法。
所以，对问题本身，我们应该有更多的考虑，
究竟是谁的预期，和现状之间产生了怎样的落差？
2. 让方案自动化
软件才出现了不到100年，但是人类社会却繁衍生息了上万年，甚至上十万年，
从这个角度来看，软件形式的解决方案可能只算是历史上的一瞬间了。
软件系统也从人类社会现存的解决方案中学到了很多，
Smalltalk的设计者之一Alan Kay，
在答复Meaning of "Object-Oriented Programming"的邮件中提到了，
I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages.
可以看出，Smalltalk中“对象”的概念，其设计动机最初来源于生物学，
这得益于Alan Kay同时具有生物学和数学的知识背景。
我这样写是为了阐述一种现状，
人们总是寄希望于用软件解决所有的未解难题，这是一个常见的思维陷阱。
因为某些问题的症结点，可能并不在软件层面，
即使该问题是人们在从事软件开发活动中暴露出来的。
例如，想要提高代码的交付质量，而编写一个自动化的测试系统，
这显然就并没有分析清楚问题的症结所在，
尤其是应用于那些难以进行自动化测试的领域中。
因为，如果将代码质量归结为测试的不够充分，
那么首先提高人工测试的投入量，才是验证“增加测试是否是有效”这一假设的最好办法，
这也是投入产出比最高的方案。
等到人工测试投入到工作中之后，
等到那些具有重复的，可被自动化执行的部分出现时，
再将这部分用软件系统来解决，
我想这才是一个软件系统被考虑用于解决问题的正规途径吧。
而不是反之，
当可重复性的工作，可被自动化操作的工作，被识别出来之前，
就先尝试开发一个软件系统，以期望它可以奇迹般的解决问题，
这样经常会得不偿失。
《计算机程序的构造与解释》中写到，
计算过程是存在于计算机里的一类抽象事物，在其演化进程中，这些过程会去操作一些被称为数据的抽象事物。
我们用于指挥这种过程的程序就像是巫师的咒语，它们是用一些诡秘而深奥的程序设计语言，通过符号表达式的形式精心编排而成，它们描述了我们希望相应的计算过程去完成的工作。
从程序语言的角度来看，
是先有计算过程，再有了这些计算过程的描述（程序）。
当我们对现实问题还没有想要一个有效的“过程”解决它时，
就冒然从事编码（程序）活动，
这显然是低效的，甚至是无意义的。
3. 信息管理
软件开发行业的从业者们，可能会抱有这样的幻想，
是我们现在这个团队，现在这个项目有问题，
必定存在一个足够优秀的团队，在那里进行开发，是顺畅的高效的，
没有各种令人分神的事情。
其实，这种幻想可能根本就无法实现。
因为每个团队每个项目都不可避免的存在自己的问题，
有其难以克服或正在想办法克服的瓶颈。
快速进行软件开发是一个不稳定的理想状况，
有任何一项不论是需求因素，工期因素，人员因素等等条件，不能符合理想标准，
都会导致开发活动慢下来。
虽然软件开发是有关编程技术的，但它的参与者终究还是人，
有人就会有目标不统一，或者沟通合作等方面的社会学和心理学问题。
关键是当其他人在兜售一个软件工程方面的解决方案时，
如果不强调它会让现状变得像童话般美妙，就没有人愿意去尝试它。
这就给我们带来了理想情况确实可以达到的错觉。
这应该是不可能的，因为在软件工程方面“没有银弹”。
软件开发的真正困难不在于如何表示一个抽象概念，
而在于如何将这个抽象概念传递给其他人。
因此，在《人月神话》提到了Brooks's law，
Adding human resources to a late software project makes it later.
即，向进度落后的项目中增加人手，只会使项目更加落后。
因为，新增加的人手会加剧组织沟通不畅的状况，
而沟通问题或许是造成项目延期的主要原因。
在软件开发过程中，如果出现了问题，
先从沟通和信息不对称的角度进行反思，
比直接寻求用一个辅助软件系统旁敲侧击，将会更加有效。
结语
既然从事了软件开发这个行当，对软件系统的威力和价值，当然是有足够的自信，
但这并不能让我们更加专业化。
所谓专业化，我认为并不仅仅是从专业领域（软件）给出任何可行的方案，
更重要一点是，从问题领域出发，指出客户方案中的不合理之处。
这样才能让方案总是直指问题的核心，确实有助于解决问题。
然而，很多情况下，都不是我们可以控制的，
在对解决方案提出质疑的时候，
他人的任何不悦，最终才会让我们意识到什么是别人想去解决的问题。
事实上，最难达成一致的是对问题本身的认知和大家的目标。
从“问题 = 应有的景象 - 现状”公式中我们也可以看到，
在大家都能理性正视现状的基础上，不同的人因为拥有对“应有景象”的不同预期，
最终会导致人们在心目中实际想要解决不同的问题。
我们想达到的预期，在别人眼里真的是个问题么？