不打算从项目管理的角度来看，只从开发的角度来看待其中的一些问题。也许可以划分成下面几个部分
确定需求软件项目需求是用来解决做什么的问题，这些需求来自用户，用户指的是使用软件的人，需求整理从粗到细，做好需求文档，需求分析，图文并茂，需求整理抓住几个要点：需求提出人是谁，要实现什么功能，需要达到的目的，做需求不是仅仅记录用户说的每一句话，而是通过与用户的沟通来理解用户真实的想法，可能用户并不是那么专业，用词也许不一定准确，需求分析的目的就是为了捕捉用户的真实思想而做的工作，可以通过原型图与用户进行逐步的深入沟通来保证需求的正确性。
本人在工作过程中拿到的好多所谓的需求都是没经分析的，实际就是用户的原话，做需求分析的人实际就是传话筒，没有分析，还得靠研发人员重新电话和用户确认，这无疑是浪费时间的，整个研发效率大打折扣，而这往往并不会引起领导的关注，殊不知，积少成多，一点一点的累积会拖累整个项目进程。
有了需求之后，接下来就是归纳整理了，从需求中分析出业务模型，整理出业务流程，业务字典，明晰业务逻辑，业务分析不涉及技术问题，只需要描述出一个文档，可以让市场人员或开发人员能够根据文档描述来了解用户的业务是如何运作的，可以通过建模工具画出业务框架图或业务流程图，甚至是原型图。
规划系统模块开发人员熟悉了用户的业务需求后就可以考虑如何进行系统开发了，要考虑的问题包括系统架构设计，开发语言选择，数据库表设计，通讯模式通讯协议。如何进行系统规划呢？这很重要，好的架构可以事半功倍，要考虑好系统的健壮性，易扩展性。系统规划包括技术层面和业务层面的规划，首先根据系统的业务需求，确定需要的技术架构是B/S，C/S架构或者是混合架构，架构设计包括网络层，业务逻辑层，接口层设计等。
网络层要完成的内容是客户端连接的管理，并发连接处理，网络容错处理等等一切与业务无关的技术问题。网络层，业务层，接口层各个分层要具有独立性，而不是揉杂在一起，这样可以达到技术上的重用，以后可以把各个分层架构重用到不同的项目中去，要做好这种隔离设计可能需要用到一些设计模式来规划好各个层间的接口了。
业务逻辑层设计，首先确定有多少业务对象，所谓对象就是业务中涉及到的人和物还有可能是一个系统。其次是规划对象接口，业务对象之间的联系和通讯就是是通过接口调用进行的，每个对象实现各自的业务逻辑。每个业务对象都是独立的个体，一个对象只处理自身的业务逻辑和数据，通过接口通讯来影响其他对象的状态。业务对象有大到小细致划分，对象之间要做到低耦合，高内聚，换句话说是对象间的依赖关系尽可能低，各个模块尽可能独立，接口调用简单，大家各扫门前雪，各干各的活，完成后需要把结果告诉别人时才去打扰别人。
接口层设计，这部分也是比较关键的，每个对象之间需要接口设计，每个层之间通讯也需要接口设计，所谓接口可以是函数，对象方法也可以是调用的web的URL。对象或者各个层间通过接口调用进行信息交换，接口设计的原则是：意思明确，这个接口是用来做什么的定义清楚；业务逻辑单一，一个接口只处理同一个业务相关的事情；可扩展，接口的参数处理要兼顾可变性，随着业务改变可能会增加或减少参数，但已经确定下来的参数意义不能改变。
各个模块具体怎么来定义接口，按什么样的方式设计才能做到松耦合，高内聚呢？可以参考一下设计模式相关内容，选择一些合适的模式，包括观察者模式、工厂模式、命令模式等等。
无论什么时候都要将模块化思维贯彻到底，将模块化思维固化在脑子里形成思考习惯是非常有益的。在合作的一些项目中，有些项目代码简直目不忍睹，令人窒息，代码逻辑一团糟，不懂设计，写出的代码就是简单语句的流水式展示，甚至使用了超多的if和else判断语句来走完一个复杂的业务流程，一个函数成百上千行代码，搞的编译器都在抱怨分支太多产生了编译错误，这样的程序结构还是一位项目头头搞的，批评别人的时候，自己还沾沾自喜的问别人，看看我写的代码是不是逻辑清楚，是不是很简单，真是奇葩。随着业务流程的增加这种流水式的编程以后将会成为项目组所有人的噩梦。
设计的模块具体要怎么呈现呢？答案是使用UML建模工具来画各种模型图，类图，序列图，流程图等等，对复杂的项目UML建模工具是必须的。
代码编写梳理清楚业务流程，设计好系统模块之后的事情就是编码了，把软件看成是一栋楼的话，系统模块设计完成了整栋楼的图纸设计，编码就是要用材料把图纸内容变成现实。
代码怎么写，从哪里下手？首先要遵循之前的模块设计的逻辑，可以先定义模块类及其接口函数，然后是整个模块的业务逻辑实现的代码，这个就要非常细致了，要根据流程图来合理定义内部函数，从主流程到分支逐级展开，函数名要言简意赅，意义明确，最好达到望文生义的效果。
每个模块对象都实现之后，接下来是把全部的模块整合起来，这时可以定义一个系统控制模块，这个模块负责配置各个子模块间的接口调用，进行信息传递。
伯乐与千里马完成一个大点的项目都需要一个团队来合作开展的，作为项目的创建人花心思来挖掘相关领域的人才也是很重要的，怎么选人？会写代码不就可以了吗？如果是这么想并且这么做，以后的项目维护估计要变成灾难性事件！
什么样的人才能作为技术研发的负责人？不是光有积极性就够的，有人积极性很高，什么事都积极响应，做事领导看着开心，领导心里舒服那就他了，加工资重用，负责系统开发，这是不懂技术或者对技术认识不深刻的老板或领导的一大遗憾，这样的领导们往往只看结果不看过程，最后只要把软件开发出来就认为你是人才，这样将导致今后的项目难以管理维护，bug频出。对于开发负责人首先需要考察的是系统架构设计的能力，而不是看加班加点积极干活的态度，那是次要的，表面现象而已。想要做出来好的软件项目，作为老板不能太抠门，如果需要提高员工的积极性，主动提高待遇比批评教育有更好的效果。如果做出来架构不好的软件系统，以后的系统扩展性，健壮性都是不存在的，这将会变相的增加以后的工作难度，问题增多，继续加班干活，形成恶性循环。
总之，有眼光的老板能发现千里马，可以为自己创造更多的价值，也可以为员工带来财富，目光短浅或格局太小的老板只能埋没人才害人害己，或者依赖剥削别人来成就自己。
