吐槽
一年前我跳槽来到现在所在的这家公司的时候，其实是带着满满的期望以及boss对未来发展的承诺，但是事到如今，我却是一腔的不满，一身的疲惫。回顾从业3年来，大大小小的项目也做了一些，但是除了刚开始的小项目做的比较顺利之外，后来的项目没有几个是成功的。当然这肯定要归咎于自身的无知和不知上进，然后另外的小部分的原因实在是公司对于软件过程的无知和放任。
自从离开第一家公司之后，我觉得自己再没有技术上的重大突破。其一是平时积累学习太少，其次是公司没能在技术上给予规范和发展的支持，这点可能很多公司都是这样，boss的关注点不会在于软件的实现过程，他更关心结果。作为一个开发者或者说项目的实施者来说，我觉得软件过程比软件结果更重要，这将直接导致一个软件的质量，以及它能否作为一个产品而存在。
我所理解的软件过程
这里的软件过程，指的是需求、设计、开发到实施上线，大部分小公司对这些过程都是没有明确分工的。这也直接导致了项目管理的混乱，造成项目质量和风险的不可控。在日常的工作学习中，我对软件过程形成了自己的理解，可以概括为需求详细、设计明确、开发保质保量、计划实施。那么这四点立足于我的工作又该如何展开？
需求详细
这四个字的意思，其实不需要过多解释，就是一份详细的需求文档。然而开发人员这么简单的诉求，往往很难得到满足，为什么？首先，需要去追究项目经理的责任问题。项目需求作为一个项目的根基和功能依据，它的存在是必要而不是可要的。如果没有一分详细的需求去确定咱们的产品的需求（功能）边界，那么产品如何实现？闭门造车式的空想，屁股决定脑袋式的拍板...这些大概都太常见了，正因为如此造成了一个项目开发人员无从下手，甚至今天做了这个功能明天就不知道做什么功能了。我遇到一个项目经理竟然跟我们说“这个星期我都不知道做什么”，我去了，真是让小伙伴们惊呆了。其次，咱们要来看一份简单的需求，只包含了蜻蜓点水的功能概述。这样的需求，无论是谁都没法做到对接下来要做的内容了然于胸了，这样的情况不得不让我们的开发反复的在开发时去重新明确需求，这是何等的浪费时间！所以，一份详细的需求文档，应该包含了对业务的分析，以及功能的详细描述为系统设计框定边界。
设计明确
详细的需求面前设计人员应该站在系统的实现角度，用开发的角度去设计系统，大到硬件方案，小到每个代码模块的接口设计，都应该做到明明白白。这点我觉得不是浪费时间，因为好的设计是对后面开发的一种规范和约定，在没有任何约束的开发状态下，必然导致了反复的重构，冗余的代码和没有效率的功能实现。试想如果拿到需求咱们就进去模块开发，逐个功能进行开发，一个人开发还好，如果是2个、3个甚至更多，那么大家的代码必定缺乏统一性，我们的开发效率和系统的效率如何保证。不断的回头改代码的经历我想大部分开发都经历过，多么痛的觉悟！！
开发保质保量
说到开发实在是要吐槽一番，我也是开发，但是首先吐槽的是自己有点懒。测试用例总是不高兴写完整，前期拖拖拉拉后期加班加点，质量得不到保证不说，弄的自己身心俱疲。不过公司没有对开发作出规范和约束也是造成这种现状的原因之一。开发和测试是并行的，虽然大公司都是不同的人分开并行的，但是我想一般的都是开发自己在做。不过单元测试确实是开发的职责了，如何在开发开始阶段就更进测试环境的搭建，测试用例的梳理和安排，这些都是后期开发质量的保证。如果都在前期做了很好的安排和计划，那么程序猿们，咱们按照计划来进行还会加班么？当然boss总是不会让咱好过，压缩下开发时间也是常事，不过良好的计划依然是开发阶段需要保证的，这样能有质量的保证。
计划实施
这个点跟咱计划生育一样，要计划好了，出生前营养充分忙前忙后，要出生了自然不能松解了。在实施上线之前，务必要所有人进行确认，确保需求得到了实现，以及所有的肯能风险和意外都是有对策的。否则出了差错我想又是要苦逼的团团转了。不过这里我想要说，错误日志和邮件提醒真的很重要啊，实施上线了以后谁每个日志，谁不是每天看邮件...难不成还拿数据来debug下么？
Summary
对于以上的理解，可能在大公司的成员来看真的是小菜，然后对于众多中小型的开发公司来说，我想谁参与谁明白了。软件像种粮食，没有很好的过程保证，那么还会有丰收季么？