做开发已经有一段时间了，期间也遇到过一些情况。下面是我的一些个人总结和心得。
项目在签订前期怎么跟客户谈，这个地方可以多多点缀一下，给客户一个很好的期望。在项目签订之后，做需求时跟客户指定一个人来进行接触这个人可以没有多大的权利，但是他至少能把公司所有的流程详细的叙述，知道公司所有的流程，能够和公司所有的部门（项目中会涉及到的部门）进行有效的沟通。在项目开发过程中公司与客户的沟通都有他来进行，中途换人会给项目的开发带来意向不到的麻烦。
前期需求了解基本完成后，需要开始写需求文档（项目完成后能做什么？）。这个地方在制定的时候一定要边想边做，不懂的或是模糊的千万要搞清楚，要不然开发到后期再进行变更难度就可想而知了。到时候可能会搞得客户跟开发人员精疲力竭。
需求文档制作应该把如何验收也写进去，让客户的领导在你开发之前就能知道后期是怎么验收的，什么是验收合格。这里也能让开发人员知道他开发完成后是什么样子的，客户是如何验收的。
需求文档，我个人认为是一个很仔细的东西，包括所有的东西都要罗列到里面。可以没有界面，但最好是有一个。项目开发完成后到底是具有哪些功能，详细的向客户展示出来。当客户有异议的时候，充分了解客户情况之后，再将更新好的需求文档（包括验收的文档）给客户，确认无误后，要求客户进行签字盖章。（这一步是将客户从他的幻想中拉回到现实中来）。然后要直白的告诉客户若是项目开发中遇到需求变更的话，需要客户现将变更需求以word文档的形式提出来，一旦进行变更工期的延长，开发的成本将提升，同时有些需求可能会增加他们的开支。一旦客户提出的需求我们同意进行变更，则需要客户进行签字盖章。（注：只要是客户提的需求都要进行签字盖章，以保证客户随意进行变更或是为了自己一小点的便利进行大的改动）。
项目需求完成后，进行项目的开发规划。如：项目总共分为几个模块：每个模块之间如何进行数据的交互。（如：订单商品人工更改少了两个，但是仓库记录的批次还是三个的，那么财务看到的出售商品利率就不会准确，同时销售总利率也就不准确了）。这时应该让每一个项目组的人员参与进来，需要大家用头脑风暴的方法给出一些客户没有想到的或是项目需求中没有提到但是实际完成后一定会存在的问题。最主要的是产品是由项目组成员来完成的，让他们先把大的框架了解清楚，要比每个人只顾及自己开发的那个模块要好的多。
开发大致规划完成后，需要将每个模块分配到项目组成员手中，让他们知道自己需要完成哪一块的工作，做完后大致应该是个什么结果。然后自己将自己的模块逐步的细化（这里只细化到功能点就行了），将细化好的整理成文档，项目组成员经行讨论与分析。（避免有些功能点，遗漏或是重合，让他们知道自己的模块会与别人的模块在哪些地方有重合，在哪些地方的数据需要收集，交互）。
进行命名约束，包括数据库表的命名规则，文件的命名规范，类的命名规范，方法的规范。（开始的严格要比项目中人员的流动造成项目开发延期的损害小的多）
数据库设计。项目组成员将自己用到的表在word文档中表现出来，包括表用来做什么的，每个字段的含义（可能后期会增加字段、有些表要废弃或是新建一些表）包括每增加一个表要将表的信息记录到一开始的文档中。（注：这个地方开始可能会慢一些，但是这样能保证每个人在任何时候都能从别人的表中找到自己想要的数据，也便于后期项目的维护和多次开发）
将每个项目成员规划的功能点 都一一列出，让项目组成员进行项目开发进度规划。每天做什么，项目每天或是每周做到什么程度。
每天或每周查看项目的进度，每个人开发的实际进度。保证项目最优先级的进行。一旦发生变化，可以及时的进行调整。
项目做到一定阶段，提给客户查看。将问题消灭在最初阶段。
项目进度控制时，尽量不拖延时间，尽量不要加班到很晚。员工在保证自己进度的情况下进行的开发，可以按时下班。摆脱开发就是要加班的恶性循环，记录每个员工的加班工时。管理首先要把公司的利益放在第一位，但是公司没有了人，就什么都不是。
每个人开发完成一个模块应该自己进行测试。至少逻辑方面不能出现错误。
项目完成后提交个用户进行测试，验收通过客户进行签字。若有问题，以最快的速度进行修改，然后再提给客户。
项目完成后，每个人将自己的实际开发进度进行重新详细的整理，便于以后的开发进行合理的规划。
针对项目开发过程中人员离职的情况，有时候项目组成员直接就走了，没有留下进行交接的时间，这样的话就应该尽快招聘新人。让他了解系统，将原来人员的所有的文档让他进行学习（上面的文档和约束就显得更加重要了）。招人要迅速但是要给他充足的时间来了解系统，了解自己接下来的工作，切记求急，要不然后期处现数据方面的大漏洞就得不偿失了。
以上是我做开发这段时间的一些不成熟的记录和总结