程序员的进化路线图

我身边的一些朋友常常问我，干了这么多年程序员真的有些累了、倦了、没意思了。虽然干了一个又一个的软件项目，但其实没有什么差别，就是写程序。当程序员的出路何在？每次我总是抑制不住自己的情绪想说，其实不是做程序员没意思，而是你还始终站在一个层次上。人是一种奇怪的动物，总是不进则退，程序员也是一样。它分为了许多的层次，刚毕业是一个层次，干了几年是一个层次，经历多年磨砺又是一个层次，经过几多磨难化茧成蝶将是另一个层次。这就像游戏，当你到了一定级别就应当升级转职了，而如果你始终拒绝升级转职，剩下的时间就是在索然无味地重复了；但当你完成升级转职，你就将进入另一个令人兴奋的世界。做程序员也是这样。OK，我们来看看程序员进化转职的路线图吧。

当你毕业刚进入软件行业时，当然毫无疑问是去编程了。每次项目启动以后，经理们就会给你一大堆需求，上面定好了你的程序应当实现什么功能。剩下的时间就是照着编写程序啦。但是，当你编程数年后，经历数个软件项目以后，你有没有想过，这些需求是怎么定出来的？那么变态，那么奇怪。有时候，我们为了客户一个变态的需求绞尽脑汁，最后客户还不买账。这些需求合理吗，客户真正的是要什么样的功能。当你开始思考这些问题，开始提出一大堆问题来质疑需求时，你的思维就开始从程序员进化为需求分析员。当项目经理发现你有需求分析员的潜质，OK，你的职业生涯开始升级了。你开始转职为需求分析员。

有人说，需求分析员就是需要那些不懂技术的人来做，我是绝对反对这样的看法的。需求分析员的作用不是那个记录员，记录客户的需求。需求分析员要记录客户的原始需求，然后分析整理，进行技术可行性分析，最后拿出客户满意而又技术可行的产品需求规格。不懂技术，就不能提前发现技术风险，为软件开发扫清障碍。所有有那么多人说需求分析员就是酱油，不懂技术的记录员当然就是酱油啦。但是，当你经过一番精彩的需求分析，却看到项目经理就这样直接交给那些稚嫩的初级程序员时，相信你的心都凉了。

从需求到实现，中间的距离也许有数百英里远，特别是那些大型管理系统。数百项业务功能，大大小小的模块，而流程与数据又错综交织。如果就这些直接扔给程序员们，就如同没有经过城市规划的房地产开发：小区是修好了，一会儿自来水管刨一遍路面，一会儿宽带刨一遍路面，好端端的路面变得丑陋不堪。现在城市建设都有专门的规划部门了，但软件开发依然延续着这种序乱。模块与模块之间没有接口调用，它们不是相互协作而是各自为政；共有的功能本应提取出来，但因为没有统一的规划，你写一遍，他又写一遍；没有技术架构和设计规范，程序员们按照各自喜好编写程序。终于有一天，你实在看不下去了。凭借多年的经验与资历，你开始着手规划系统，制订编程规范，并要求所有人遵守。这时候，你开始向系统架构师挺进了。

其实有许多人都十分疑惑，系统架构师是怎样一个角色。简单的说，他就是一个中间人，一个十分重要的中间人，联系业务需求与技术实现的中间人。需求分析员是那些精通业务需求的人，但是由于长期脱离技术，他们对技术的认识在退化，而做需求不能脱离技术。系统架构师可以与需求分析员一道分析需求，哪些是可行的，哪些是不可行的，怎么能够提出更可行的方案，满足用户的需求。同时，尽早确定技术架构，验证技术架构，攻克技术难题，对规避项目风险至关重要。毕竟，搞不定早点儿提出来嘛。

一旦需求定下来，开始开发了，系统架构师的工作并没有结束，因为程序员总趋向于各自为战，他们之间需要一个协调人。这个协调人要事先将他们各自的功能划分清楚。然后是相互之间的接口调用，这是一种协作的体现，系统内聚的体现。最后，系统除了横向的功能划分，还应当定义纵向的层次划分。应当划分哪些层，采用什么技术，每一层按照怎样的规范编写。总之，系统架构师就是那个规划师、协调人。当然，系统架构师还是那个技术牛人，因此技术难点的解决方案也归他来处理啦。

去理解和把握业务需求是需求分析员的工作；统领全局，将需求转换成技术是系统架构师干的事儿。但不论谁，都是在被动地接受需求。客户需求来了，搞一搞；客户需求不来呢？正所谓态度决定一切，试想，比尔盖茨开发windows，是因为一位客户跑来找到他：hi，比尔，我提个需求，你给我弄个windows吧；乔布斯设计ipod，是因为另一个客户跟他说：hei，我在地铁上太无聊了，你给整个ipod吧。这是否让人感觉滑稽可笑呢？软件发展的动力来源于技术的创新。每当新技术出现的时候，我们应当有这样的意识，怎样把它们转变成用户的需求。这就是主动发掘用户需求的意识。当你拥有这样的意识，并最终将胜势转变成胜利时，你又升级了，你将成为市场总监甚至是BOSS。当老板的并不一定是各方面能力都很强的人，而是那些具有开拓精神，从无人走过的荒草中开拓出道路的人。

在游戏中，我们完成一个并不算困难的任务就可以升级转职，但在现实中却并不是这样。每升一次级需要我们付出的是太多的辛苦与努力。怎样才能在适时的时候成功转职呢？管理学中的一句话道破了天机：在成为一名管理者之前，先做一位无名的管理者。什么是无名的管理者呢？没有管理者之职，却做管理者之事，这同样适用于其它职业。试想，当你还没有成为需求分析员时，努力去用需求分析员的思维，去完成需求分析的工作。当你一次次出色地完成需求分析的工作时，公司自然就会提升你为需求分析员。同样，当你开始运用系统架构师的思维去完成系统架构设计时，系统架构师还离你远吗？

总之，只有那些不安于现状、勤于思考、乐于学习，并且有一颗坚强的心的人，才能走到胜利的彼岸。


。。

评论

6 楼 sorriest-siben 2013-08-13  

说的很实在。。。。

5 楼 fangang 2012-05-26  

Iwqenter 写道

另外，下周一开始进场做需求，楼主有没有相关的需求规格说明书的案例参考一下

抱歉，这期间涉及到太多的商业机密，所以不同方便

4 楼 lwqenter 2012-05-25  

fangang 写道

如果从设计开始做应该够了，如果从需求开始做就实在太紧了。

一般，假如这是一个例行维护，或者已有项目升级，或者需求已经很清晰了（一些素质比较高的客户，需求拿到你手里的时候就已经很清晰了），半个月的需求分析加编写文档，可以拿下来。如果是一个全新的项目，从头开始做，怎么也得一个多月才能拿得下来。

如果需求已经清楚了，一个半月的工期，让我来安排计划，那么是一个月的设计开发，一个月的测试。什么什么，没有算错吧？当然没有算错。在我的项目计划里从来没有全部开发完了才开始测试。如果是两个迭代期，1、2周开发人员开始第一个迭代的设计开发，测试人员设计测试用例并搭建测试环境；3、4周开发人员开始第二个迭代的设计开发，测试人员测试第一个迭代的开发成果；5、6周，测试人员测试第二个迭代的开发成果，并最终完成集成测试，开发人员配合测试人员测试，并着手完成安装程序及脚本的制作。

开始工作前，项目经理应该安排好2个迭代期分别的工作任务，最好不要平均分配，而是先紧后松，工作尽量往前排，因为你也不知道会发生什么异常情况。分2个迭代期的目的，既是为了保证测试与开发能有一定的并行，又能保证每个迭代的测试有一定的范围，能拿出一个确定的版本。

－－－
另外，下周一开始进场做需求，楼主有没有相关的需求规格说明书的案例参考一下

3 楼 lwqenter 2012-05-25  

fangang 写道

如果从设计开始做应该够了，如果从需求开始做就实在太紧了。

一般，假如这是一个例行维护，或者已有项目升级，或者需求已经很清晰了（一些素质比较高的客户，需求拿到你手里的时候就已经很清晰了），半个月的需求分析加编写文档，可以拿下来。如果是一个全新的项目，从头开始做，怎么也得一个多月才能拿得下来。

如果需求已经清楚了，一个半月的工期，让我来安排计划，那么是一个月的设计开发，一个月的测试。什么什么，没有算错吧？当然没有算错。在我的项目计划里从来没有全部开发完了才开始测试。如果是两个迭代期，1、2周开发人员开始第一个迭代的设计开发，测试人员设计测试用例并搭建测试环境；3、4周开发人员开始第二个迭代的设计开发，测试人员测试第一个迭代的开发成果；5、6周，测试人员测试第二个迭代的开发成果，并最终完成集成测试，开发人员配合测试人员测试，并着手完成安装程序及脚本的制作。

开始工作前，项目经理应该安排好2个迭代期分别的工作任务，最好不要平均分配，而是先紧后松，工作尽量往前排，因为你也不知道会发生什么异常情况。分2个迭代期的目的，既是为了保证测试与开发能有一定的并行，又能保证每个迭代的测试有一定的范围，能拿出一个确定的版本。

-----
感谢楼主提供的项目计划思路，公司有一个产品，我们的项目是想基于这个产品进行开发，这个产品并不完善，只覆盖了标书要求的需求的30%左右，客户给的需求资料是一年前的，下周一进场，标书要求一期要在六月底上线，领导打算跟客户谈，增加一个月，下星期第一次去见客户

2 楼 fangang 2012-05-23  

如果从设计开始做应该够了，如果从需求开始做就实在太紧了。

一般，假如这是一个例行维护，或者已有项目升级，或者需求已经很清晰了（一些素质比较高的客户，需求拿到你手里的时候就已经很清晰了），半个月的需求分析加编写文档，可以拿下来。如果是一个全新的项目，从头开始做，怎么也得一个多月才能拿得下来。

如果需求已经清楚了，一个半月的工期，让我来安排计划，那么是一个月的设计开发，一个月的测试。什么什么，没有算错吧？当然没有算错。在我的项目计划里从来没有全部开发完了才开始测试。如果是两个迭代期，1、2周开发人员开始第一个迭代的设计开发，测试人员设计测试用例并搭建测试环境；3、4周开发人员开始第二个迭代的设计开发，测试人员测试第一个迭代的开发成果；5、6周，测试人员测试第二个迭代的开发成果，并最终完成集成测试，开发人员配合测试人员测试，并着手完成安装程序及脚本的制作。

开始工作前，项目经理应该安排好2个迭代期分别的工作任务，最好不要平均分配，而是先紧后松，工作尽量往前排，因为你也不知道会发生什么异常情况。分2个迭代期的目的，既是为了保证测试与开发能有一定的并行，又能保证每个迭代的测试有一定的范围，能拿出一个确定的版本。

1 楼 lwqenter 2012-05-22  

楼主，假如你现在接手一个项目，工期是一个半月，需求，设计，开发，测试各个阶段的时间安排是怎样，人员安排呢，每个阶段要准备哪些工作，哪些工作是最重要的？