技术与业务
作为一名开发人员，在技术与业务的选择题面前，很多初学者都很茫然，特别是比较内向和钻牛角尖（强迫症）的人。
甚至于在开发与非开发工作前，很多人都很抵触（我也不例外）。
那么到底该如何选择呢？ 我从我自己的经验，谈谈我的观点。
1 项目的流程
刚刚出道的时候，我甚至不知道怎么搞一个项目，甚至我接触的第一个项目是口述需求、然后上代码。然后的然后，我就认为项目就是这么流程。现在，三年过去了，再回首，只能捂脸！
现在我了解的整个软件开发流程，是如下的（隐去商务部分）：
- 客户提交需求
- 需求分析
- 系统设计
- 软件开发
- 测试
- 发布
- 运维
比较幸运的是到目前我几乎参与过所有的环节（虽然有的部分只是简单参与，但仍受益匪浅）。不但对自己的定位有了清晰的认识，而且对以后的系统设计、管理有很深的帮助。
先解释下每个环节：
客户提交需求：这里的需求一般指招标需求。非常粗糙的需求，甚至有的只有一个大致的想法，也就是一两句话。
需求分析 ：面对于客户粗糙的需求，需求人员需要先理清流程，然后确定简单的业务约束规范，也就是大体的关键性数据指标。然后画出界面原型，通过界面原型与客户进行沟通。在多次沟通确定无疑义后，将成型的需求文档提交架构。
系统设计 ：系统设计，总的来说就是架构选型与数据模型设计。很遗憾的是很多公司的可选架构并不多，一般都是自己封装好的成型架构。为了降低学习成本和安全性，有的甚至几年不更新换代。所以更多的是数据模型设计。说的直白点就是建表，设计代码表、参数表、业务表及页面主体流向和数据变更过程。
软件开发 ：开发人员在界面原型与业务需求下进行软件开发。在整个开发过程中，开发、架构、需求、客户之间会不停的进行互动。
测试 ：这里的测试分为自己内部测试和客户测试。因为涉及不多，所以不加赘述。
发布 ：测试环境发布与生产环境发布（这里隐去了环境搭建步骤）。
运维 ：在系统正式上线后，用户会提交部分问题，这部分问题会交由运维人员处理。依问题的难易程度向上流转。
2 沟通的重要性
从整体流程来看，需求从客户提出到最后到运维手中，经过了至少6个层级。如果有某个约定或者需求点，没有明文解释或者描述不清，那么最后一环的人将一头雾水。为了确认这个问题，可能会一个一个问题一一询问，也可能需要6到7个人，在一起共同讨论，这个在项目控制中就是沟通成本。
抛开其它环节，单以开发来看，有的时候我们会遇到简单的需求，有的时候我们也会遇到很难的需求。遇到简单的需求的时候，如果不能正确的解读，直接上手开发，甚至于自作聪明的磨时间到交付日期前一周才提交。这种情况下你只能为自己的小聪明买单，准备24小时加班吧！
遇到复杂的需求，如果不能理解清楚，直接上手，那么在开发过程中会困难连连！
到底是什么原因导致这种现状呢？
1 针对于新程序员，往往他们不知道自己该做什么？老程序员又不会告诉他们。这就会导致很多新手在开始的第一个项目中，遇到难题不知道如何处理就自己在那钻牛角尖，然后就等着快到了工期仍然不能完成任务（新人的培养成本是很高的，这或许就是很多大的公司不愿意招萌新的原因吧）。如果你的项目有健全的沟通机制你或许能减少这部分的问题，但仍不能完全避免！
2 针对于老的程序员，很多都是技术宅。他们不愿意与人沟通，还有的甚至沟通不清楚。
归根结底就是管理机制、主观态度、自身的沟通能力和理解能力问题。
如何解决沟通问题和降低沟通成本成了项目的一大难题：
1 在招聘时将沟通理解能力作为一个重要指标（基础影响高度）；
2 通过详细的文档来搭建沟通的基础，在这里的文档主要有两部分（需求文档与界面原型）。需求文档，将需求细化到步骤和每个数据项的输入输出规则。界面原型，展示页面布局及操作流程。通过这两份文档基本能解决百分之80的问题；
3 开发负责人参与需求分析（或者是主要开发人员），减少会议的成本；
4 在项目内部管理上，定期汇报成员的进度、提出自己的难点，按照进度表有序的推进。
3 沟通什么
在日常工作中除了聊天扯淡之外，我们沟通最多的应该是两个方面（业务需求和技术知识）。
什么是技术？
世界知识产权组织在1977年版的《供发展中国家使用的许可证贸易手册》中，给技术下的定义：“技术是制造一种产品的系统知识，所采用的一种工艺或提供的一项服务，不论这种知识是否反映在一项发明、一项外形设计、一项实用新型或者一种植物新品种，或者反映在技术情报或技能中，或者反映在专家为设计、安装、开办或维修一个工厂或为管理一个工商业企业或其活动而提供的服务或协助等方面。”
什么又是业务？
从广义上来说，业务有很多种定义。但是在软件开发中一般认为，需求方提出的业务主体的一系列需要处理的事务为业务。这些事务相关的约束条件为业务规范。
很多时候，遇到技术问题，大家热情似火；但是遇到业务问题，就有很多人不情愿，甚至抵触！
在工作中，甚至很多人在规划自己的发展的方向时，选择纯技术 或者 技术性管理（开发经理），而不愿意去当纯管理（例如项目经理）。这样的想法没有对错之分，只是每个人的选择不同罢了。
我想说的是，你的选择没有问题，但是你需要正视一个问题，然后才能让你的选择不后悔！
这个问题是：技术和业务的分界线是什么？两者真的有区别吗？
在我看来两者是以软件开发这个行业为分界线的。但我不认为两者真的有区别！
比如，在很多人看来一件货物的生产、包装、销售、售后 是一种业务流程。那么，对于架构师来说，一个对象的定义、创建、注入、销毁 何尝不是一种业务流程？
oracle 是技术吗？
对于oracle 的开发人员来说这也是一种数据存储的业务！
所以在我看来，技术也就是软件行业内部的一种特殊业务罢了!
说明这点并不是为了剥下技术那光鲜的外衣来丑化它！而是为了提醒大家，如果你连软件行业之外的简单业务都无法沟通清楚，那么你怎么有勇气去与别人讨论更加抽象虚幻的技术（软件行业内部的业务）？
结合实际而言，每一种技术的出现，都是为了解决实际生活中的某种业务（有可能是行业内的，也有可能是其它行业的）问题！所以，我们沟通的都是业务！技术是为业务服务的！离开业务的技术毫无意义！
4 总结
技术与业务是对双胞胎！只学了技术，你可以拥抱工作；只学了业务，你也可以拥抱工作！但是如果作为开发人员的你想要更好的提升自己，那么你应该同时拥抱技术与业务！每种工作都有它存在的意义！如果你明白了你的工作岗位的意义，那么你便可以考虑换个岗位提升自己了！（仅代表个人观点）。
希望以后的初学者可以在刚开始就不抵触业务，少走弯路！
