产品开发过程中对技术角色有意无意的曲解和误解

1、开发

随着传统瀑布模型的淡出，开发过程的阶段性变得不那么严格和清晰。

某些非技术背景，不了解软件工程的产品/业务人员，会想当然的认为开发就是Coding，需求提交给程序员，程序员马上就可以埋头敲键盘写代码了，所以整个开发过程就是写代码，写完代码就可以给用户用了。

而实际上正确的开发过程应该是，需求原型尽早和开发人员沟通，开发人员会评估可实现性，给出合理化建议，帮助理顺需求，寻找逻辑异常；此后产品/业务继续细化需求，出页面设计图，而开发首先要做的不是编码，而是需求分析/分解，模块/接口/数据库的设计，这些是可以和产品页面设计同步的，之后才是编码，编码完成后要自我测试/编写一些单元测试以及接口测试代码，然后和其他模块集成联调，最后提交测试人员，持续修复问题和回归；上线时需要提供部署/配置支持，上线后仍然需要维护，修复问题/提供技术支持。除此之外还有配置管理/项目管理体系的引入，代码分支合并，功能/问题/支持任务的进度跟踪，风险控制，代码评审，时间管理和效率评估等日常事务需要处理。

2、测试

在一些急功近利的管理者眼里，测试是可以忽略的，因为他们只想尽快上线，不在意把真实用户当做测试人员，100%这样的产品就悲剧了。通常意义上的测试是要发现问题，但什么是问题呢? 问题包括需求偏差、功能异常、系统兼容性、用户体验、性能和安全，还有更难界定的可扩展性可维护性和可测试性。有些业务人员认为测试就是在页面上执行功能测试，很简单，甚至很多测试人员自己也那么认为，但实际上一个好的测试过程，首先在需求阶段测试人员就需要介入，从业务合理，同类产品对比，可测试性的角度提出独立意见，此后还需要把业务需求分解/组合/映射为测试需求，对应于开发设计和页面设计，测试人员需要相应编写测试方案和测试用例，在需要自动化的地方，根据接口设计，编写/录制自动化测试脚本，然后才是测试的执行工作，测试执行完成后要给出质量评估意见，后续测试同样需要对线上用户问题提供技术支持。在一个长期项目测试中，自动化的价值会更高，自动化测试框架的启动应该是和开发框架的启动相对应的。

3、运维

对于一些开发/测试人员而言，似乎运维就是发布代码，简单重复的更新。但实际上单就发布而言，那都是一个复杂工程，之所以没有看到这个复杂度，是因为好的运维人员把发布的麻烦用脚本给简化了，而且好的运维人员得有很好的配置管理意识，很多时候运维人员同时就是配置管理员，这是我认为可以紧密结合的角色。发布分为两个步骤，一个是测试环境的发布，一个是生产环境，最大的问题就是怎么保证测试环境和生产环境的一致性，这需要开发人员的配合。很多时候测试环境一切都好，发布到生产环境，出现奇怪问题，一般情况是代码不一致，数据库不一致，定时任务不一致，目录权限配置不一致引起的。所以发布的过程，不只是更新代码，一个好的可以持续的发布，源头在于好的配置管理，版本管理，除了需要发布的代码外，说明文档/脚本/权限变动项/数据变动项/命令行定时任务等都需要开发人员完整一致的入配置库，这些一致的发布物在合适的时间点需要被冻结，打上发布标记，后续的问题修改必须按补丁流程来走，并被严格管理，不能引入主干上开发的新功能。在发布时，首先需要备份数据（如果用了Git，SVN进行发布管理可以不用备份代码），检查数据变动项的规范和正确性，建立修改定时任务，迁移历史数据，检查是否需要升级环境，是否需要安装扩展包，是否需要清除本地缓存和CDN缓存，是否需要切换到维护页面，选择多个服务器的更新策略（A/B还是全部更新），是否需要重启服务等。

开发/测试/运维都不是那么简单的，都是可以在各方面持续学习和提高的。这就是为什么有些想起来看起来很简单的事，做起来不然，因为行动起来才会暴露/遭遇更多环节和细节，而细节上的一个异常，会导致整个过程的失败。

by iefreer