外部因素问题
1.需求不明确
前期各种调研，查找资料，只能自己瞎想需求，猜想需求。最后在截止日前3天，才看到一个可以说明确的需求，但时间紧迫完全不可能面面俱到。
2.老板态度模糊
老板经常说这是公司以后一个很重要的部分，也经常拉项目成员集体开会讨论。但是讨论完了之后，项目启动后，没有后续跟踪，给人感觉，项目没必要继续开发下去了，整个项目就此进展缓慢。
3.沟通中的问题
第一次负全责开发系统，没有很好做好外部和内部沟通
外部沟通：需求没有很好了解，导致内部项目进展缓慢，尤其是没有清楚的认识到影响项目风险的存在【需求不明确，项目截止日不明确，项目中的其他变故】
内部沟通：部门内部资源没有很好了解利用，系统搭建，常用功能的复用都没有使用，资源没有利用，浪费了时间。
开发中的问题
1.项目进展缓慢
需求不明，导致不停的重复返工，讨论，再次明确需求的过程。
2.各阶段时间节点没有
在传统行业中有需求阶段，项目编码阶段，测试阶段，复测阶段。这里完全没有，经常按照老板要求，更改各种时间节点，大家积极性在一次次更改节点中丧失。
在互联网行业需要明确一个观点，只有编码是需要充分考虑的，其他都不是必不可少的。
3.没有复用成熟功能模块
Redis 工具,权限系统等，都没有复用，自己重新开发，耗时长，问题多，还不好用。
4.观念问题
以前认为在充分时间开发条件下，开发人员开发的东西会问题少，充分满足需求，现在发现要有约束性，大家完整的按照紧凑时间节点开发，如果没有大的架构变动，项目反而更好。
5.人类本性问题
组员，因为相互之间主观以为是大家都是多年的老开发人员，充分信任，当局者迷，很多功能没有考虑清楚，也没有细思细节，导致做出的东西粗糙。
没有约束导致进展缓慢。。
6.各阶段没有很好的完成介入
项目开始编码时，没有很好完成启动准备。项目使用技术路线[基本框架，权限框架，系统用户分层]没有充分讨论，仅仅一笔带过，把引进新的技术和开发看得太乐观。
编码开始和中途，应该介入代码评审，没有进行，后来因为维护成本放弃。
解决办法
复用成熟组件，谨慎引入新技术，前期迅速开发，加快开发节奏，直接开发出一个半成品，让boss知道东西做的如何，给boss信心，后面可以跟进。让使用人员和需求人员知道东西是怎样的，可以根据他们的意见进行改进。哪怕一个错误的展现，也比空口白话更有说服力。
哪怕前期经常加班，后期悠闲，也比后期加班在deadline前也赶不出东西强。
PS:简书MD不用手写，老别扭了
