关于专业性
“我觉得专业性意味着我们有能力和义务为客户提供更合理、更卓越的方案，而不是单纯的盲从客户”，这是我朋友的一句话，我很认同的。
我们在职场中，在内部晋升，在对外合作，在寻找发展机会时，都需要彰显自己的专业性，体现自己无与伦比的价值。
软件开发，算是一个专业性比较强的领域，那么我们怎么样才能体现出自己的专业性呢？
一、需求的解读
软件需求包括三个不同的层次：功能需求，用户需求，业务需求。
功能需求：开发人员必须实现的软件功能，使的用户能够完成某个任务。
用户需求：用户使用软件产品可以达到的目的（或者一些列任务），我理解为是满足用户目的的一系列功能的组合。
业务需求：通过为用户提供一系列功能，达到组织机构或客户高层次的目标要求。
我认为功能是基础，是软件开发的最小颗粒；而业务需求是目标，是最高层次的终极的要求。只有搭好底层基础，才能满足上层要求，而作为软件开发的基础，需求的解读就是至关重要的一环。
中文是“博大精深”的，有时候我们避免不了出现对需求解读的多种含义，从而导致结果偏差，那么我们应该定义一个标准、格式或者分类，从侧面辅助保证需求的明确性。比如：
- A-我饿了，我想吃饭了。
- B-请给我一份虾仁炒饭。
很明显，A像是讨论聊天，不具备操作落地条件。B更符合实现描述。作为软件这种强调逻辑性的场景，其实更需要这样能够反映单一内容的描述方式，“我要一个X；把Y改成Z”。
如果我们解读需求能够翻译成这样的内容（讨论足够细化），或者更近一步，需求方提供了这样精细的描述，那应该可以事半功倍。
二、任务的拆解
1 | 脑筋急转弯： |
把“大象放进冰箱”这个脑筋急转弯，我相信大家都听过，就是利用拆解的思维。只不过我们需要拆分的更细，不然“实施的方案”和“投入的时间”都将无法得到最优解。
我们需要知道大象的体型是多大的？大象是死是活？可以把大象切分开吗？有哪些冰箱？冰箱具体多大？
拆分任务，可以让原本复杂的任务难度下降，更易于对其不同方面有针对性地去解决，从而使得任务可以不断地被推动下去。
拆解原则：
- 拆分时不重复，相互独立，以组块化的思维去拆分工作任务。
- 拆分时不要遗漏，完全穷尽，可以参考那些知名的思考框架：5W1H模型，麦肯锡7S模型。
- 拆分到大脑可以一次处理完，分解到可以执行的下一步行为动作。
- 拆分到一个人可以处理完。
有点类似接口设计的原则，开发人员应该比较有体会，短短的描述其实要求极高
三、方案的提供
不管是大项目还是小项目，我觉得在对任务做拆解后，各个协作团队的负责人基本上都可以做到了然于胸了。大项目应该还有前期的方案调研，而小项目对于开发人员应该都是经验丰富，应该只是小细节的问题了。
如果对相关的信息都熟悉满点，如臂使指，别人提到的问题都可以对答如流，马上回复，我觉得也是专业的体现。如果同时可以考虑到其他方向，比如存在的风险，规避的方案等等，就更加难能可贵了，让客户有心理预期，或者填补未知空白。
四、时间的预估
软件开发的时间，我认为除了依赖“任务拆解”和“所选的方案”外，还在于开发的人力投入，队员之间的协作合作，以及项目进度的把控。
对外提供的时间点，相当于是团队对外的公开承诺，一个环节的拖延可能会产生连锁反应，也会影响团队的信誉评价。
我个人偏向以“低估能力”的方式预估开发时间，这样开发会有足够的缓冲时间，因为我们不能保证开发周期中没有突发状况。并且，如果在预估开发时间内提前完成需求，将会有足够的自测和完善时间，我认为白盒自测和黑盒外测应该是并行的，冲忙的开发不利于质量保证。
五、质量的保证
开发的质量，很大程度在于团队和个人专业性，包括： 技术能力，责任心，时间。
技术能力：可以在事前做好预防工作，注重缺陷预防和问题规避，而不是事后检查和修正。
责任心：高质量可维护的代码我觉得是个人责任心的体现。代码是开发人员为计算机写的诗句，同时不只是机器可读，自己可读，更应该是其他人可读。
时间：“时间是治疗伤疤的良药”，我相信时间是解决问题的钥匙，足够的时间，总是能够把弥补质量上的缺陷。
以上是软件开发过程中的关键节点，我认为每个节点都是专业性体现，只有熟悉每一步，才能像“庖丁解牛”一样做好每一步，才能对外提供卓越的软件产品。
【2019.10.20】