1.弄清楚前期的基本需求

一个需求往往在开始的时候是不可能想到后来那么具体和精炼的。甚至有些需求是吃力不讨好或者无法实现的。原因：搞需求的人不懂开发，只是按照他的视角去规划需求

开发要做的是什么？ 不光要搞清楚需求提的需求，更要及时的去反馈哪些啥吃力不讨好，甚至没法实现的。这个过程往往会产生分歧，其实不一定是某一方有错，只是大家的

立场不同，没必要去争论。

2.接着就是着手开发

程序员打消了对需求中有排斥的地方的心里后，开始编写代码。

3.随着一个软件的雏形出现后，需求开始各种的指指点点

看不到东西的时候，需求就是自己在找资料，找参考去拼凑一个需求，质量可想而知。现在经过一段时间，需求做成一个东西了。他看到了，他对需求了解也更透彻了。这个

时候，他通常也不会推翻自己以前的设计。他通常会让你加点新的功能，这样业务逻辑会更完善。的确更完善。不过这个时候的一个难题是时间。老板等着要东西。这个时候

老板就会各种抱怨，通常老板也不懂技术，只知道这个东西，我规定你什么时间交给我，你没交给我，你就有问题。于是要么扣钱，要么加班，最极端就辞退。

4.最终程序还是完成

不过这个时候，程序员已经受了太多委屈。感觉自己身体被掏空。而程序本身的质量则直接与程序员的最后一点责任心有关了。

讲到这里，我想说的是做好软件，需求是非常重要的一环，不要马虎，多和程序员一起花点时间讨论，中间有变动也要如此，需求在项目上有3成的责任。

另外还有一点，项目多架构也是很重要的，这通常跟项目的始作俑者---项目经理有很大关系。一个项目能否成功，项目经理至少有4成的责任，这其中还有对程序员的指点和管理等等。

一个好的架构，可以让程序员思路更清晰，开发更有效率。一个不好的架构，程序员开发起来费劲，代码写的非常的臃肿，写到最好很难维护，这个项目要么死掉，要么重构，这要浪费更多

的钱和精力。

最后是程序员，不管别人怎么看，不要瞎想了。干好自己的工作，写代码多点责任心，会写的更好，同时爱惜身体。程序员的责任有2成。如果需求和管理做的不好，就只有0成，没有意义了。

最后1成给销售，老板总是看中销售，因为他们让老板直接看到了客户的订单。不过酒香不怕巷子深，产品不好，销售再会说，项目迟早是失败的。

我眼中的程序开发