项目流程管理
近期在做的项目一期的任务折腾了一个月终于发布上线了。中间的过程很有意思，如果思考一下，其实可以学到很多东西。
技术上其实没什么难度，问题在于对项目的理解和对问题的沟通上。
其中暴露出来的一个比较明显的问题是，客户和这边的团队有两套不同的UI。这边按照自己的ui开发完进行交付时，和客户的基本上完全不一致，大部分都推到重新进行开发了。
第二个问题是在对于某些业务逻辑的处理上，缺少相应的人员能够作出对应的决策，每次都需去问客户，她们到底想要什么。没人能够特别清晰的理解客户的具体需求，或者说能够决定哪些需求是真正的需求，哪些是伪需求。
第三个问题是，对于项目的规划其实没有做到位，包括界面的交互逻辑，展现形式，很多都是在交付的过程中，不断的去试错，然后进行修正，浪费了不少时间。很多东西如果事前能够做个简单的考虑的话，其实可以节约不少时间。
以前总结的项目管理流程其实就是三点：事前规划，事中跟进，事后复盘。如果能做到这三点，真的也就那么回事儿，毕竟我们做开发都这么多年了。
对于客户，我们需要倾听她们的话，去理解她们真正的需求。有时候客户天马行空的思想，技术上实现起来不一定容易，这也需要我们耐心对她们进行正确的引导，不一定所有的事情都必须按照客户提的需求来开发。
我们需要做到中庸。
前端工程化
近期一方面忙着这个项目，另一方家里忙着搞装修，所以对于技术的关注少了一些。但是前几天在看的一本书觉得非常值得一读，这里推荐给大家《Sass and Compass Desiginer's CookBook》。
这是一本讲sass的书，推荐读英文原版，讲的非常详情。我们也许在开发过程中都用过sass或者stylus，亦或是scss。但是真正对sass中的变量，函数，指令掌握的非常熟练的，我想人也不会很多。
前端时间总是刷到一些文章说什么前端工程化。大抵就是告诉你，开发一下项目要做技术选型，制定项目规范，做测试，部署什么的吧啦吧啦。
在我看来，那些只能称作是项目流程标准化，并不能称作是工程化。
因为项目是工程的子集。一个工程中可能包含多个项目。只有多个项目叠加在一起的时候，才能成为工程。一个项目可能随便换个人都能进行快速迭代，但是一个工程，如果你随便换个人可就不一定能够快速迭代了。因为它涉及的面比较广，工程里的项目可能用的技术栈不一致，也可能某些地方特别复杂，需要专业的知识才能解决。
好比我们做装修，装修本身是一个工程。工程里面包含贴砖，吊顶，批灰，门窗安装，柜子定制等多个项目，并且每个项目的工种都不一样。但是我们需要用一种合理的方式将这些项目整合起来，成为一个装修公司，才能称其为我们把装修这个事情做成了工程化。
当然，工程化需要我们对项目的流程有深刻的理解。但是更需要我们对每个项目的细节进行把控。贴瓷砖要对缝，不能产生空鼓，出现空鼓的情况需要重新注浆进行处理。
同理，在前端的开发中，我们也需要对各个技术细节有一定的理解，框架原理，组件开发规范，sass的各种指令等等一系列的技术以及它们适用的场景。甚至我们也需要对经常出现的错误有个全局的把控，这样，我们才能从全局出发，去思考如何做好工程化。
前端工程化，绝对不仅仅是代码规范，和git的提交规范。单个简单的项目，我们可以用规范来保证开发质量和交付质量。但是复杂的工程，更多的需要我们自身的技术有一定的深度和广度，同时有一个全局的眼光去管理，开发和维护。
工程化需要的不仅仅是一个人定制一个规范，它需要整个团队的技术有深度，思想有层次才行。
