谈软件需求

对于IT行业，要成为一个专业的需求分析师很不容易，10个开发里面估计能够成功转一个好的需求分析师。需求分析是业务和IT技术的双重结合，IT设计开发走到需求分析核心就是业务领域知识和业务建模知识储备，思维的一个重要转变就是考虑业务流程和业务数据本身而不是过多一开始就考虑系统实现。好的需求人员不一定是该行业的业务专家，对每一个业务细节都了解清楚，但是一定有全局业务思维和把控能力，具备业务建模和分析能力。而这两个里面的重点又是业务流程建模和业务数据建模，形成端到端流程意识和全局数据模型意识。

需求调研能力是需求人员的一个核心能力，而需求调研的重点一方面是行业的业务技术积累形成的经验，一方面是沟通和理解能力。这两方面的能力是基础，其它方法，工具，模板都是其次的东西。

谈软件架构

架构师我原来谈的比较多的，其核心仍然是高屋建瓴和落地实施两个能力，两个能力一个都不能少，不能落地分阶段实施就是空架构，不能高屋建瓴和至上而下就没有全局把控能力和系统思维。对于从设计开发人员转过来的架构，可以看到落地实施能力还是很强的，毕竟有多年的开发经验的积累；但是差的就是系统建模能力，需求偏业务建模而软件架构偏系统建模，而建模的重点一个是全局和自上而下，一个又是从下而上的抽象。

一件事情先开始没有计划，但是同样的事情做多了就知道如何先做计划。架构一样，一种设计和实现，做多了后知道如何去抽象，抽象完后面对新事物就变成了不需在做完后再抽象，而是可以直接高层建模后再逐层分解，这就是架构师的核心能力。但是不可能任何技术都有经验，所有面对新技术的时候仍然需要自己开发原型对架构进行验证。

当公司的基础架构或平台没有确定前，架构师往往关注非功能性需求的满足，当公司开发平台和框架基本确定后，架构师的工作重点转移到对功能性需求的关注。非功能性需求涉及到架构的方面是性能，框架，分层，公用组件封装，运行机制，日志等方面的内容；而功能性架构涉及到的是系统，子系统，模块，组件，接口，关键算法，业务交互机制等重要内容。两方面都必须关注才是一个完整的架构。

谈设计编码

架构的目的是为了保证新开发的应用或系统的概念完整性。对于已有系统的新功能或变更的开发，可以看到架构的作用往往并不会很大。而根据源代码就是设计的思想，设计和编码不用分的那么清楚，但是并不代表在编码过程中不体现设计的思想。哪些地方需要抽取为复用，哪些地方涉及到接口，算法的采用，类之间的调用，变量和数据结构的选择，程序本身的实现逻辑，后续代码的重构都将体现你的设计思路。所以我们说，同样一个功能的通用编码，仅仅从CodeReview的角度其实就很容易看出技术功底和设计的潜质。

在编码的过程中能有意识的体现设计的意识是编码朝设计转的一个重点，其次需要有面向对象的思维和掌握形式化的设计语言如UML这是基础，需要在编码过程中有重构的意识，有复用的意识。有了这些可以开始读开源的源代码，多看看和熟悉别人是如何设计和开发系统的，可以尝试由公用函数的复用转化到组件级的黑盒复用，加强在编码过程中的重构，加强对系统实现机制和底层的一些研究，而这些往往正是设计模式的基础。设计模式再通俗点就是在不同的业务场景和现实问题下采用不同的设计方法的经验。

谈软件测试

需求人员最熟悉业务，从这点上来说测试人员应该向需求人员看齐。但是区别点在于需求人员需要调研和分析业务，进行业务建模和需求挖掘等，而测试人员只需要xx理解最终的结果(需求说明书)即可。如果再加深一点，测试人员应该再多考虑下由于什么样的业务场景形成了最终的结果，只有这样测试人员才能够逐渐形成业务人员的思维。

测试工程里面虽然涉及的东西很多，包括测试生命周期中的测试计划，测试分析，测试设计，测试执行，测试评估等各个方面的内容。涉及到各种测试工具，测试方法等，但是这些仍然是工具和技术层面，而真正的重点仍然在于测试人员对某个行业某类业务的了解程度，这是真正做好测试的基础。我们始终要知道测试的持续改进目标只有一个，发现前人从来没有发现过的问题。

在设计和编码人员启用单元测试后我们看到，开发人员希望从繁重的重复测试中解脱出来。而测试人员同样需要有这种思维，即如何从重复不增值的工作中解放出来，这本身就是一种持续改进的思维。包括自动化测试，性能测试，测试模板等都是为这个目的服务。从重复工作中解脱出来你才可能有更多的时间考虑和分析业务场景，分析和准备数据。