前言
最近跟了一个大项目，随着项目的1.0版本提测提测，这一块的工作也告一段落。因为也来公司一年多了，领导想让我独立负责下这个项目。最终也算是按时完成，期间也有过很多做的不好的地方，也获得了很多经验。特此整理了一篇文章来和大家分享。
先磨斧子再砍树-熟悉需求
时间拉回开完需求评审会后，实际的工期给到我们的并不理想。以前做比较赶进度的项目总是拿到手就做，往往最后总是做出来的与需求不符或者做出来的东西思考的不太全面。这次我根据原型图重新绘制了一遍流程图。这样做有两个好处：
1.如果作为项目负责人我可以更全面的知道整体的流程。
2.方便我将系统拆分并合理评判出工期。 有人可能就要说了，不是看原型图就能理解产品需要的结果了么。绘制自己的流程图是以开发角度对项目进行理解。在绘制完成后往往还要跟产品对一遍，一方面检查我们的理解是否一致，另外一方面检查产品逻辑是否还有可优化的地方。
使用自己熟悉的领域减少风险
在架构搭建初期我也考虑过使用一些新的技术，新的组件。但如果这个程序交给其他人去维护或者去合作，往往会需要学习更多知识。这无外乎增加了入门成本和维护成本，我也不是一个很爱冒险的人。最终敲定架构采用与老系统一样的方案，在此基础上减少以前多余的代码，简化配置。
举个例子，之前需要一个一个引入组件，现在采用全局引入的方式。无须在指定的vue中 import我搭建架构的思想是简单，可维护性高，尽可能使用少量的代码。
正确的进度评估对项目进度的重要性
1.工期评估
在项目开始前，组员们对自己的所需要的工时无法给出明确的数字。
先将前端的和后端的任务分为三个模块: 管理端开发、前台展示开发、后端与其他服务对接
再根据设计稿计算出一共有多少个页面：
以往的经验来看前端的工作一共分为三个部分：
静态页编写(40%)、后端接口对接与页面逻辑调整(50%)、自测(10%)
以最终交付时间为截止时间，就可以得到每个阶段该做什么和是否延期。
2.进度跟进
制定完计划后就可以跟进进度了。目前我是通过每天开早会的形式去同步组员之间的完成情况。组员们需要每天更新进度文档：
进度文档包括：剩余时间、剩余百分比、每天所做内容和风险与难题。
在关键的节点也需要组员们演示一下成果，一方面可以方便组员之间熟悉各自的流程，另一方面大家一起评估一下是否还有可以优化的地方。
没有问题才是最大的问题
在早会上没人暴露风险大家都很开心，但这往往会是最具有风险的。在早会结束时我会强调大家还有没有什么问题或者还有什么需要协调的。我已经见过太多因为没有及时暴露风险而造成的项目延期或上线出问题。
有句老话说的好“每一次严重的事故背后，必然有29次轻微事故和300起未遂的先兆以及1000起事故隐患”，风险和问题在第一时间暴露并解决往往会使损失降到最低。
我也在没天的日志中提醒大家要及时暴露风险。值得庆幸的是，组员们都很积极，每天也有新的问题暴露。在解决问题繁忙的同时，我也感到了实实在在的安全感。
最后要说的
经过了这一次的项目管理使我学到了很多东西。管理项目并不是单打独斗，最重要的是及时听取组员的反馈。组员之间也各有优势，正确分配才能发挥每个人最大的价值。