项目开发总结(DSP)

外部因素问题

---

1.需求不明确

前期各种调研，查找资料，只能自己瞎想需求，猜想需求。最后在截止日前3天，才看到一个可以说明确的需求，但时间紧迫完全不可能面面俱到。

2.老板态度模糊

老板经常说这是公司以后一个很重要的部分，也经常拉项目成员集体开会讨论。但是讨论完了之后，项目启动后，没有后续跟踪，给人感觉，项目没必要继续开发下去了，整个项目就此进展缓慢。

3.沟通中的问题

第一次负全责开发系统，没有很好做好外部和内部沟通

外部沟通：需求没有很好了解，导致内部项目进展缓慢，尤其是没有清楚的认识到影响项目风险的存在【需求不明确，项目截止日不明确，项目中的其他变故】

内部沟通：部门内部资源没有很好了解利用，系统搭建，常用功能的复用都没有使用，资源没有利用，浪费了时间。

开发中的问题

---

1.项目进展缓慢

需求不明，导致不停的重复返工，讨论，再次明确需求的过程。

2.各阶段时间节点没有

在传统行业中有需求阶段，项目编码阶段，测试阶段，复测阶段。这里完全没有，经常按照老板要求，更改各种时间节点，大家积极性在一次次更改节点中丧失。

在互联网行业需要明确一个观点，只有编码是需要充分考虑的，其他都不是必不可少的。

3.没有复用成熟功能模块

Redis 工具,权限系统等，都没有复用，自己重新开发，耗时长，问题多，还不好用。

4.观念问题

以前认为在充分时间开发条件下，开发人员开发的东西会问题少，充分满足需求，现在发现要有约束性，大家完整的按照紧凑时间节点开发，如果没有大的架构变动，项目反而更好。

5.人类本性问题

组员，因为相互之间主观以为是大家都是多年的老开发人员，充分信任，当局者迷，很多功能没有考虑清楚，也没有细思细节，导致做出的东西粗糙。

没有约束导致进展缓慢。。

6.各阶段没有很好的完成介入

项目开始编码时，没有很好完成启动准备。项目使用技术路线[基本框架，权限框架，系统用户分层]没有充分讨论，仅仅一笔带过，把引进新的技术和开发看得太乐观。

编码开始和中途，应该介入代码评审，没有进行，后来因为维护成本放弃。

解决办法

---

复用成熟组件，谨慎引入新技术，前期迅速开发，加快开发节奏，直接开发出一个半成品，让boss知道东西做的如何，给boss信心，后面可以跟进。让使用人员和需求人员知道东西是怎样的，可以根据他们的意见进行改进。哪怕一个错误的展现，也比空口白话更有说服力。

哪怕前期经常加班，后期悠闲，也比后期加班在deadline前也赶不出东西强。

PS:MD不用手写，老别扭了