做项目负责人的总结

之前一直是做游戏开发，虽说也算是项目负责人之一吧，但是基本只是负责后端架构和后段逻辑，只要做到两点，1：服务器可以承载一定用户量，2：逻辑没有问题就好了，剩下的诸如流程交互页面画风之类的，全部在自己的考虑范围内，对，还有进度，也不在考虑范围内，因为一般都是客户端是瓶颈，服务器不是瓶颈，甚至有点闲。
来到新公司之后，既要负责技术，也要负责项目，前两三个月有点吃不消，也有点不适应；因为要统筹安排美工和程序协调开发，并且要保证业务逻辑流程的顺畅。难免要经历一个难产期，或者阵痛期。索性，索性，坚持过来了。

说一说刚开始时候的不适应吧或者说刚开始时候做的不好的地方吧。
首先说说写需求：
1：首先是总是丢需求，这一点也是总监跟我说了n次的地方，可是仍旧是在这里犯了n-1次错误；拿最近这个商城来说，因为是基于微信，所以需求中要体现对微信的接口和约束；更要体现如果去管理微信公众号，这块确实是被我忽视了，的的确确的被忽视的，完完整整的丢掉了；而没有这块就无法接入微信，切记切记；后来在读一本书的时候，提到了约束，如果丢掉了约束，可能就会导致最终的产品进行大返工，切记切记。
2: 需求不完整，一些活动的需求，无法形成闭环，或者说有疏漏的地方，这里确实要再文档成型之前，对每一个模块，每一个功能，每一个需求，每一个流程做一个头脑风暴；虽说无法避免疏漏的地方，但是一定要避免无法形成闭环，无法形成闭环，无法形成闭环，重要的事情说三遍，切记！

说说整体架构这块：
1：首先是一定要多视图；因为利益相关者不同，架构设计文档要给到程序，运维，老板，其他架构师等不同的角色看，所以架构设计要从不同的视图来体现，比如给程序的，要从模块划分，层次划分的角度来；给运维的，要从不同机器之前联系的角度来，等等，总之要多视图
2：抛出难题，或者说风险控制，总之把风险全部抛出，分析那个风险最大，那个所需要考虑和投入设计的精力也就最多
3：考虑扩展，考虑分布，考虑负载
4：考虑客户端，这块一直是疏漏，总监也总是提醒我，要多关注些客户端，客户端不可太大，否则加载会很慢，考虑压缩，考虑框架的选取，以轻，稳，简为原则，这块的的确确是疏漏的

我们再说说做计划：
1：可能是对这种javaweb的项目不熟悉，所以最初也就是贾哥给了一个泛泛的计划节点，就是demo版本的deadline；现在熟悉了，切记切记，要做计划做计划，分解计划，做到周计划。
2：根据开发进度调整计划，在实际的开发过程中，常常发现缺界面，丢逻辑之类的事情，虽说可以通过前期需求和设计避免，但是这样又需要在需求分析和概要设计上花费太久时间，所以需要补充的功能之后，要调整计划，调整计划，切记狂加班消耗开发热情。
3：美工的计划要早于开发，工程师在开发任务的时候，切记切记，美工已经把界面给到，这样就需要保证美工的计划要早开发一个星期左右的时间，这样才能保证开发顺畅的进行。

年前写的文章，写了之后一直不肯发布，是因为觉得错误犯的有点低级。年后虽说旧项目还在维护，也同时开启了新项目，现在再做需求基本能做到完整完善，并且使用面向对象的方式，做设计也能考虑的比较全面了。就不必藏着掖着，就把这篇文章发布好了。