职业规划就是对职业生涯乃至人生进行持续的系统的计划的过程。一个完整的职业规划由职业定位、目标设定和通道设计三个要素构成。
一下子就跨到了新年，时间真快呀！言归正传，今天谈谈项目问题。
我们常听到同行说自己做过什么项目，说某某做过什么项目。一谈到项目就会眉飞色舞，兴高采烈。而不少新进单位的新大学生、一些编程新手，往往不知道什么项目，不知道项目与自己成长的关系，有的甚至声称编程好几年了，还都没有做过项目的经历。情况确实如此，只有参加过项目的程序员才是真正的程序员。那些没有做过项目的虽然自己编制了不少程序，虽然得意过自己的程序，但是，毕竟和做过项目的程序员有很大的差别，这些差别主要在于：
1、 程序的价值
没有做过项目的程序员，编写程序的目的主要是学习，通过编程来提高自己的编程能力，编啥、怎么编都由自己主观决定，自己能做什么不能做什么都不是太清楚。至于程序能否被别人使用，程序能否卖出价钱，程序员并不太关心。
做项目的程序员则不一样，他编写的程序不是用来学习的（尽管他是抱着学习的态度参加项目的），而是作为商品的一部分出售的，编出的程序要投入日常运行的。他别无选择，必须完成程序功能。程序员的价值通过程序出售的价格以及程序使用来体现。
2、 程序的时间要求
没有做过项目的程序员，编写程序的时间长度是由自己决定的，自己高兴什么时候编好就什么时候编好，遇到其它事打搅，拖个十天半个月也无所谓！
做项目的程序员则不一样，他必须在规定的时间内完成编程，只能提前不能延后，否则整个项目进度就会被它拖后腿，而由于项目延期不能按时交付给客户，其结果就有可能因延误被罚款，甚至取消项目。
3、 团队
没有做过项目的程序员基本上是单枪匹马地编写程序，程序功能相对简单，一个人多花点时间也能完成。
做项目的程序员则成了项目组的一个成员，他只是负责整个项目的一个部分，或者说只编写其中的一段程序，而不是全部。因此，他的程序必须要和其他人编制的程序对接、他的程序必须读别人的数据，他的数据也可能被别人读。这里的每一个环节都不能出错，一个地方出错就会影响整个项目。所以，他必须和团队的其他人很好协作共同来完成自己的程序。
4、 学习氛围
没有做过项目的程序员学习靠自学，靠网上google去学，学的内容随意性很强，学好学坏没有人监督。
做项目的程序员不但靠自学、靠网上google去学，还必须向项目负责人去学、向项目组其他人去学、向客户去学。而且学的东西都有针对性。向项目负责人去学习程序设计详细方案、向项目组其他人去学习程序接口、数据接口、向客户学习业务及需求等。程序的好坏要通过测试环节和用户使用加以验证。
所以，通过参加项目程序员可以克服自以为是的错误观念，树立为客户编程的思想，以软件销售价值来衡量自己的价值；树立团队意识，把自己融入到团队之下中，以团队荣为荣，以团队耻为耻；在项目中学会从大局看待程序设计、学会评判程序难易之处，学习更加实用的程序方法和算法。
那么是什么项目？这里所指的项目可能和一般的项目定义侧重有所不同。这里的项目一般是指客户提出需求，软件公司或企业内部项目小组按照需求进行设计、开发，投产、维护等工作的总和。它只包含软件相关的费用，其他硬件、网络、软件环境费用不在此考虑之列。
项目是有大有小的，有的大的项目以亿为计，有的小项目以千而计，千差万别。由于没有标准，不同的人对项目的大小定义是不同的。例如，有的企业把一百万以上的软件称之为项目，把1千万以上称之为大项目。有的小企业把1万元以上的软件称之为项目，把5万元以上称之大项目。这些项目大小主要取决客户对资金管理范围和等级，一般而言，项目越大，需要单位或企业越高的领导层批准。
zc530.com推荐
今天，根据自己的体会，我来谈谈项目经理的初始化阶段。
新人工作一段时间后，或长或短，可能一至两年后，有可能出任项目经理。此时，考验你能力的时候真正来临。项目分很多类，如基础研究项目，大型综合性项目。这里我们选取小的商业应用型项目为例。
刚开始，我们是没什么经验的，好在有热情。但这是项目，是一个讲究人与人之间配合的技巧性的活，光靠热情是难以持久的。退一步说，你是能力很强的聪慧之人，什么都拿得起放得下，那你充其量只是个精兵，而不是一个好的管理者。管理者的目标让整个组织的效率更高，管理者是没有那么多时间老是冲锋在前的，请深刻体会这一点。 因此我们得掌握一些基本的技术，讲究一些策略，力求避免未做勇士，先做烈士。
需要先补的课程是，项目的三要素：时间、成本、范围。
第一：时间
如果三峡项目做得很漂亮，质量很高，专家也很满意，惟一不足的是项目比预期推迟了两年半，那么这个项目的考评可能从A+会直降到C-甚至D-。因为这样一个大项目群，耽误一天便产生数以亿计的成本损耗。我们的项目虽然小，但道理是相通的。所以在执行项目之前。项目的时间至关重要。
客户有个时间表，老板有个预期的时间表，每个项目成员都有个时间表，作为项目经理，必须把这些协调起来，达成一个各方满意的结果、按照利益相关方的优先级别排序。这里有个分析的小技巧：请注意，老板说是下月底完工，你得有两手准备。一方面：alpha版一定要在下月上旬先给老板看下，给他一个初步印象，避免到时心里落差过大，情绪失控，万一有错，也来得及修正。另一方面，不要做得太细太完善，既浪费时间，又不给领导提意见的空间，领导只会怪你不会做事。于是，你得留一些简单的易于完成的小破绽给领导。是不是很委琐？！我相信这 样做，对项目组有利。当然，看具体的人，看性格。
第二：成本
项目花下去多少成本，预算时要心中有数。多大的西瓜多大的秤。这个成本包括时间成本、人力成本、费用成本等。在项目中间要勤计算挣值 。这是一个很关键的指标。投入与产出必须有一定的正相关系数关系。人有多大胆，地有多大产的教训在我身上太深刻了，记住，什么事都不要拍脑门，项目中没有任何板上钉钉的事，特别在公开会议上，要控制自己的情绪和言行。 有时候，一时不必要的斗气，让项目成员苦不堪言。
第三：范围
有了时间、成本的到位分析。范围就是一件简单的事了，简单的说，范围就是项目需要完成的程度。时间长、成本允许，可以内外兼修，各环节都做得漂亮，各方满意，自己也挺有成就。这是理想中的理想，基本上在实际中属于空想的范畴。所以，如何控制好范围，而又保持好项目成员的积极性，是一门学问，水很深哪！项目经理的一个基本观念是：项目是独立核算的，项目的考评是本项目完成到什么程度，而不是为了别的项目组或者为了下一次项目做了多少。如果这个项目可能为了别的项目组做出一些牺牲或额外努力，请尽量避免！如果必须得做，也需要在项目组 会议上言明，为自己项目组争取既得的回报，不一定非得物质的，比如领导的心知肚明，客户的理解和感激等，这些会帮你加分。千万不要偷偷摸摸的干，把项目成员的暗中努力不当回事，我是雷锋我怕谁已经不能用来唬人了，这是个讲究科学、兼顾效益的商业社会。
有人会问，在这三者冲突的情况下，如何取舍。建议很明确：先砍功能，也就是范围，把一些能推到项目二期的先往后推，向范围要时间。所以，在项目开始之前，要给项目孵出20%左右的可压缩时间，这个只有项目经理自己清楚，不必言明。
最不可取的就是项目经理挥刀自宫，让整个项目组在低成本下高速运行，这样的项目最后成败我们先不说，在项目成员的眼中，你基本上与黄世仁无异，甚至不用等到项目结束，就已经牺牲了。所以在第一次项目中一定不要让项目成员感觉跟你就是为了体验雪山草地，他们配合你，一是出于利益，二才是看你这个人值不值得跟。都看着你呢。所以，遇到不顺事先忍着，抓重点，回头再总结。这就是前文所说的做人、做事的原则：为什么级别的事情，就得付出什么级别的代价！
其实，第一次，不要将成败看的太重，教训要自己书写。有人说，哪怕只打一次仗，一个兵才会淬火成为真正的军人。谁没有第一次呢？做人，要经得起失败，但得明明白白地失败。
有人说 程序员的人生有三重境界。第一重、见山是山，见水是水。刚入门的程序员基本只能看到表面的东西，由于各种原因，没法了解更深入。第二重、见山不是山，见 水不是水。成长并有经验后，看到的表面现象渐渐有头脑中成型，犹如行军详细地图已经了然于胸。第三重、见山亦是山，见水亦是水。大悟之后，举重若轻，外松内紧，处事看似笨拙，实则暗藏玄机，惜语如金，然字字珠矶。此时，胸中亦有各种框图，然表面内敛以藏拙，见人说人话，见鬼与鬼语，谓之通灵也。
要想修炼到气定神闲的第三重境界，那就用心和智慧体验吧！
职业规划是对职业生涯乃至人生计划的过程，职业生涯规划的好坏可能将影响整个生命历程。感谢您阅读《项目经理眼中的合格程序员》内容，职场资讯网小编向您推荐一些职业规划知识，欢迎参考，希望能帮到你。
一、合作与团队精神及计划性
服从分配的工作，并在保证质量的前提下尽快完成任务。如果接到的新任务没有给出工作量估计，首先估计出完成任务所需要的工作量，并有责任向领导说明其估计的合理性，如果接到的新任务已经给出工作量，除非能提出充分的理由，否则必须接受该工作量估计。提前完成任务时，应该及时通知上级。在同时承担几个模块任务时应能根据优先级的变化及时调整自己的工作时间分配。
二、需求理解能力
在开发过程中，要在需求细节不明的情况下，有责任设法搞清楚，积极学习编程思想和方法，并在设计、编码工作中自觉应用，对有一些复杂程度的设计，主动申请设计审查。并能在开发用户界面之前，尽可能使用界面原型方法获取用户的确认。
三、测试意识
在工作负担允许的情况下，采用测试驱动的编码方式，及时把完成编码的部分提交测试，并及时排错。不断通过自己的测试来驱动程序质量的提升。
四、规范化，标准化的代码编写习惯
良好的文档是正规研发流程中非常重要的环节，作为代码程序员，25％的工作时间写技术文档是很正常的。缺乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇到极大的麻烦。
对正规的企业，会有完整的编码规定，代码的变量命名，代码内注释格式，甚至嵌套中行缩进的长度和函数间的空行数字都有明确规定，良好的编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。代码具有良好的可读性，是程序员基本的素质需求。
五、总结与全局观
以项目全局为重，采取尽可能简捷的解决方案，把完美方案的设想提交设计人员，有问题时首先向同事们征求解决办法，不鼓励花大量时间解决难题，并鼓励给同事提供技术支持。项目结束，做出个人小结，以利个人和集体的改进。
1.从程序员到PM,是一条脱变的路，事实上程序员走的路最终不应该是项目经理。首先有一点需要明白的就是，一定规模的项目中，项目经理不需要太懂技术，他可以是一知半解。项目经理的任务不是在技术方面，技术相关的应该交给SA去做。项目经理更多地是做管理，沟通等工作，你如果可以的话到书店查看一下关于项目管理的书籍，你就会明白。当然对于小项目来说，有可能是PM,SA是同一个人，而这样的项目经理更多只是SA加上一些管理工作。要做项目经理，你就首先告诉自己不再去碰技术细节了。程序员并不是一个培养项目经理的好环境。所以没有什么从Coder到什么developer再到SA然后是PM的路，这是一条比较悲哀的路。在大公司，SA下一个目标不是PM,而consultant,然后是seniorconsultant,PM走的是另一条路，所需要的技能不是技术，技术给PM带来的能力提升是很少的。在项目中你最后能分清楚PM与SA的关系及各自在项目中的分工与用途。
2.其实我蛮同意gzlucky（Lucky）的看法的，确实是我们公司不少项经理就是不很能跟得上现在的一些技术，因为很多人都快年近四十，儿子都上高中了，要他们再学新技术真的难度比较大，他们的工作基本上就是天天找手下的程序员，布置这个任务，询问那个任务做的怎么样了。不过我的头倒是和我一样编程，他手下写代码的就我一个人，他自己也会ASP和JSP,但是可能对。NET不熟，就由我来主负责了。我觉得项目经理还是像他这样的好，自己也能懂不少技术，可以服人。但是我的头儿好像在沟通这一块不是非常出色，当然也有可能是俺太内向，不太与他沟通，所以他也只是在交待任务后就不再多询问，而不像别的项目经理天天追程序员后头问。我想问问各位，你们看哪种项目经理才是比较好的，像我的头儿这样的，还是像某些喜欢追程序员后面问进展的。
3.原来在一个小公司做过半年的DM,一年的PM,后来为了让自己的技术更扎实一些，离开了原来公司，现在在大公司做程序员，开始后悔了，在大公司里很难接触管理方面的东西，也很难晋升，个人认为在小公司做DM,PM,有经验后直接找大公司的PM,这样也是一条路。
或者考PMP之类的证书，然后直接找管理的工作。
希望过来人能给予更好的意见和建议，我也现在想往管理层发展。
技术很硬了再去做PM,这种想法是错误的，我就犯了这个错，边搞好技术（为了生计）边学管理知识（为了将来）,慢慢向管理发展，不能等。有句话说的好，机会是属于那些有准备的人的。利用业余时间多学些管理方面的东西，所谓人的差异在业余时间。
要走向管理层，英语一定要学好。
沟通很重要，要做好管理者，先学会做人。多跟下属沟通，多为下属着想，而不要去巴解讨好上司。体谅下属，把项目计划做的尽量合理，不要让下属加班，给下属发展和晋升的空间，这样才能是下属有干劲，才能把项目做好，你才有更高的升迁机会。
只有把自己知道的不断的让你得力下属知道，只有提拔起一些得力的下属来，你才有时间和精力去向上爬，不然你抱着不放，就没有升迁的机会。
管理不是喝酒抽烟那么简单，那只是过去的那种不思上进，耽误自己前程。
吃尽苦中苦，方为人上人。
做PM不是混，是要把项目做好，这跟做人是一个道理，这也就是为什么做管理要先学会做人的道理。
pm的整个工作重点是什么？如果做为一个PM,技术不高怎么对付组里的牛人
我们经常会因为公司里的顶尖人才、个性化太强，不能与其他人合作而感到棘手，要解决这一问题其实也是有法可寻的。
一、在肯定其价值和优势的前提下，明确地制定改进的目标；
二、顶尖人才能够面对中肯的，明确及一对一的批评作正面反应，所以要加强与他沟通的力度；
三、可以根据具体情况调整考核目标，加强与其他员工合作的内容；
四、把顶尖人才调到相对能独立发挥其才能的岗位，减少与别人发生矛盾的机会。
本人普通院校，非计算机专业本科毕业。从毕业到现在也工作有五年了。回忆起程序人生，也颇有一翻滋味。
本人是从大三上学期开始学习计算机的，因为那时电脑突然一下比较普及，本人家里也有能力买台电脑。买了电脑后，最先看的是C语言的数据结构。用电脑调试书里面的各种程序，那时第一次看数据结构，我接近全力去看，但是没看懂多少东西。只是把书里面的代码敲了一遍，运行后看看是否和书里面说的结果是一样。但很多时候，第一次都是没通过调试的，发现不是这里抄错了，就是那里抄错了。通过不断的查找，最后才能运行正确，那时心里就会才生少许的成就感，感觉自己写的程序调通了（虽然只是照着抄了一遍）。看完数据结构（其实有很多东西还是不懂），我去找了本计算机组成原理来看。结果看得自己更加模糊。因为这本书里没有代码，只有一些抽象概念，当时好像只记得CPU有几个寄存器寻址，还有些补码，反码什么的。那个书又厚，硬着头皮翻了一遍后就没看了。接着买了本操作系统原理来看。也是很难看，都是些概念的东西，又没代码调试。比如什么GDT，虚拟内存分段，分页，实模式，保护模式，中断等等。也是硬着头皮翻一遍，能懂多少是多少。看完后，接着就看那个编译原理，因为网上都说懂编译原理的人都很牛，我也希望变成牛人所以也去搞了本回来看。结果发现，能懂编译原理的人，确实比较牛。里面涉及到自动机的概念。属于用计算机来做人工自能的范畴。我也很想成为牛人，硬着头皮看，结果还是有心无力。经过这样一个过程，虽说很多都不懂，但却使我对编程从一无所知到有了一种模糊的认识。大概懂得了什么叫做内存分配，还有程序的那些字母符号是怎么被计算机执行的。这时回头把原来的数据结构翻出来再读一遍，突然发现这本书比起其他三本都容易，也很好懂。明白了什么叫做算法，并且可以尝试去实现自己想的一些算法。当时的自豪感油然而生。感觉电脑可以按照我的想法去工作了，非常兴奋。虽然那时我并不懂得多少C语言，对指针也只大概知道是什么东西，实际中还是不会应用。但至少可以利用我所知道的，来实现我所想到的。在当时一股冲动之下，写了几个自己记忆由心的算法：
1，从1到100，每数到7的时候，把该数字提出来，剩下的数字继续循环，问最后剩下的一个数字是多少。我记得好像是50。
2，任意输入数字，和+ - * / （ ）几个符号组成一个算术表达式，计算出值是多少。
3，记得看过计算机组成原理里面有个磁盘调度算法，用的是现在电梯常用的电梯算法。感觉这个算法很好，就去用C语言实现了一遍。
刚开始写程序，都是一个main函数全部搞定。慢慢的，在算法实现的过程中发现，如果一个算法太大，一路写下去，代码会很长，并且很容易想了前面就忘后面该怎么写，或者写到后面，忘了前面写的是什么。 这时，就产生了一种想法，就是刚开始设计算法的时候，想好哪几步，然后每一步用一个函数代替。main函数中只是分步函数的流程控制。这样main函数的代码就大大的减少，逻辑变得非常清晰。然后可以像填空一样把每个分部函数完成。接着在子函数里面还可以分成子函数，分到后来，发现很多函数可以被其他的函数调用。达到重用的目的。记得当时发现这个方法后，也是异常的兴奋。这种方法居然被自己想到了，感觉自己真是个人才。因为自己是非计算机专业，想找编程的工作，起码要有一个东西证明自己是学过计算机的。所以在这期间报考了那个高级程序员（高程），因为要考试，所以学习了一些汇编之类乱七八糟的东西。考试好像分为笔试和上机，但是现在已经忘记是哪一个没过了。郁闷！没过之后，不甘心，就去报了个计算机等级考试（3级，互联网技术），结果不出意外，将证书收入囊中（不过现在想想，一点都没用上。拿回来后，从来都没给人看过，现在都不知道放到哪里去了）。
搞完这些，自己大三也差不多结束了。自己也知道到了大四要开始找工作，所以不能自己专门去研究什么算法。那个东西当不了饭吃。所以要搞一些比较流行的东西，起码需要混到一个工作。所以那时就搞了一本C#入门经典。因为那时听说。NET比较流行，好找工作。并且对于一个新的东西，我比较喜欢找一些名字上有入门两个字的书（这样的书里面一般都会很详细的告诉你如何搭建调试环境）。因为程序这个东西，你首先要能够搭建一个调试环境，光靠看是看不出什么东西来的。后来感觉这本书还不错，不枉费我100块大洋。从中学到了一些。NET的基本用法。并且对面向对象讲得比较详细。面向对象那一章我也很认真的反复看了好几遍，因为那时03年面向对象非常热门，网络上面到处是面向对象几个字，感觉编程高手都是会面向对象。我也想成为高手，所以我就抱着一种不搞懂不罢休的气势去看。结果，只是记住了面向对象的语法。书中和网上举得例子也很简单，多半是些动物是抽象类，然后，分什么鸡，鸭，鹅之类的去继承，然后动物都有吃饭的接口，鸭子有游泳的接口， 此类等等的例子。看了半天，也没弄明白这些对于我写程序有多大的作用。后来，从书上抄了一份网站购物车的程序，认识到了WEB的开发流程，感觉自己也可以上路了。因为当时才大四上学期，也没有到处发简历。只是在网上留意一些招聘信息。当时也是在CSDN里面，看到一个本地的公司在招人的帖子，公司很小，刚起步。我想应该不会要求很多，我也就去应聘试试，希望自己能够应聘上，这样至少能够证明自己有资格成为程序员。应聘的时候，老板问了一些问题，多半是WEB开发方面的技术问题。由于那时我对WEB只是刚刚接触，懂的不多。好像当时有一半以上都没回答上来。走的时候，我把我从书上抄的那份程序放到电脑里运行出来给他看了看。大言不惭的说者是我写的。他看了看，点了点头，然后就回去等消息。我是星期五去面试的，星期天公司打电话让我星期一去上班。听到这个消息后，心里莫名的激动。请同寝室的哥们大吃了一顿。大家也都为我能这么早找到工作感到高兴。后来，就是白天到公司实习，晚上回寝室睡觉。工作后慢慢的，那种兴奋感就消失了，取而代之的是工作压力，由于做WEB开发，服务端的C#还好说一点，但是前台用到很多的是HTML和JAVASCRIPT，当时对这个知道的很少，只能一边翻书，一边做事。要达到老板的要求，每天都八点左右才能搞完下班。
感觉有些是企业环境因素，不是项目经理能力范围，以项目经理的实践经历来评估。但感觉有点抽象，没有深入探讨，与实际中应用对比起来。
1级：具备项目管理的一些基本知识，有一定的计划、控制意识，但还没有全面掌握PMBOK知识。
这一类人，在实际中较多，基本上靠自己的经验和意识在管理项目，对于系统学习项目管理体系知识还有些抗拒，认为过于理论化，实则是还没有意识到项目管理的重要性。典型的一种例子，在项目计划中，只注重开发任务，对于项目干系人的沟通计划、项目实施得不太关注。这类角色，实际还不太具备项目经理的能力，顶多是开发小组组长，但实际还是不少人担任项目经理，如果项目技术性较强，这类人可以担当，如果项目业务类较强，项目实施涉及较多干系人，则通常项目会搞得很糟。
2级：全面掌握项目管理知识领域知识，并能结合实际运用，有一定的沟通协作能力。
与第1级相比，2级的PM意识到项目管理的重要性，主动学习相关的知识，并在实践中应用。意识到沟通、计划的重要性。
已经可以单独承担6-12人月的项目。可以管理10人左右的项目团队。
3级：可以管理项目群，相当我们说的部门经理或者高级项目经理了。一般会管理几个项目的项目群。
与2级相比，这一类具有更好的沟通能力，以及教练指导能力、授权能力，以及团队建设能力。一般可以管理的团队规模在20-50人。
4级：可以管理一个团队规模在100人以上、项目规模几百人月以上的大型项目，也就是我们说的项目总监。
与3级相比，4级因为管理团队规模较大，会在市场战略分析、管理标准化和规范化（如开发过程体系、绩效考核体体系、人员培训计划）多下功夫，与公司高层、外部客户的沟通协作能力也很强。已经开始上升到高层管理角色了。
5级：应该是大型公司的GM、CTO级别了，不过这个层次的主要工作好象不是项目管理了，是企业管理了，一般已是公司总裁级别，或者是事业部负责人。严格意义上，这类角色已经是不是在管理项目，他们是在管理企业，我之所以列在这里，是从职业通道上，很多做到4级的项目总监，有希望再上一层，走到这一级。所以我将题目由项目经理的能力成熟度探讨扩展为项目经理的能力成熟度与职业阶梯探讨。
职业规划就是对职业生涯乃至人生进行持续的系统的计划的过程。一个完整的职业规划由职业定位、目标设定和通道设计三个要素构成。
我们都遇到过这种情况：一个大型软件项目的建设没完没了，好像总也完不成。事实上微软的一些大型软件项目经常会陷入这种困境，像Vista,SQL Server,XP这些大的软件项目就是如此，在项目开发的最后阶段总是不得不删减大量的功能模块，任命新的管理者争分夺秒地交付产品。在最后期限内，如果你只是不停的编译再编译，而总也完成不了产品，你就会陷入困境无法脱身。你怎样才能让一个大型软件项目脱离这种困境从而成为一名软件开发英雄呢？让我来告诉你如何办到吧
首先，让我们了解一个失败的大型软件开发项目产生的过程：为了解决一些复杂的问题，一个大型的软件开发项目被设计出来了。很好！软件就是用来解决问题的。但是从第一天起事情就朝错误的方向发展了！怎么回事呢？是这样，经理和主管决定由他们来计划整个软件项目的细节而这些细节可以说是细到了极致。接着他们任命一个项目经理来管理所有的程序员，让这些程序员独立完成各自负责的部分。就在项目交付使用的前几周，这个项目经理开始整合所有已完成的部分。这样能行吗？当然不行了这简直是一场灾难！项目被拖延了！几天、几周、甚至几个月，几年过去了项目都还没能完成交付。问题到底出在哪里呢？我们该如何解决呢？
软件开发就像是建楼房
你看过建楼房的过程吗？建楼房时是不是每个人都在各自的区域建造自己负责的那部分呢？当然不是！那么摩天大楼是如何建成的呢？首先应该是打地基，然后用升降机井建楼层，一层接一层的建，再修建内部的构架你能想象出如果每一部分都是在不同场所建造的，最后再将所有这些部分移到施工现场进行整合会是什么样子的吗？即使你有一个绝妙的整合方案，你也会遇到问题：一些部分可能不能互相锲合需要重新做，建筑师可能改变他们的想法，一些部分有可能丢失，整个建筑看起来就像一对乱麻！
完成项目成为软件开发英雄
你的软件项目正面临危险吗？或者它已经处在困境之中了吗？你准备好让你的软件项目重新步入正轨了吗？那让我们开始
你是不是感觉标题有点矛盾啊，是啊，程序员当然就只是程序员而已嘛，还会有其他什么吗？
No，No，No，如果你以前是如此认为的，那看完这篇文章后，请从此打消这个念头，因为你要改变成一个不一样的程序员（怎么还是程序员？）
虽然我工作经验也就6年左右，但经历了很多，也自己创业过，也是从一个初级程序员走起，因为看的比较多了，某些东西也普遍存在着很多程序员身上，希望自己的经验能帮助你们。
当刚踏入程序员这条路的时候，有幸为一家公司开发一个大型的电子商务网站，因为这篇领域当时还算刚刚起步，自己的编程能力还不太好，所以做起来就比较吃力，每天重复着做完PM给的工作，但是做了大概几个星期，我发觉某些地方真的不合理，但自己又仅仅是一个程序员而已，怎么办呢？我还是按照PM的任务一步一步来做，私下里我用了大量的时间去尝试着我的做法，在接下来的几个星期，我试着跟我的PM进行沟通，他也发觉不错，所以一并写了方案提交给上级领导，很好的是，我们的领导发觉建议还不错，所以改变了原先的策略，对我们的网站原先的设计进行了彻底的推翻，一套新的理念就此诞生了。
这只是一个小例子，并不是炫耀自己的能力，我只是想说，程序员，你其实不仅仅是worker，更应该是Ideaer。当你选择程序员这条路时，如果你仅仅为了工作而选择的，我想你的人生真的很灰暗，为什么这么说呢？我面试过很多人，大多都是从培训中心出来的，虽然我也是从那里走出来的，不过我当时是为了学习编程而去培训，但现在更多的人会为了工作而去培训。其实如果你是真正的选择程序员这条路，我想你的思维能力一定不错，因为一般程序员大多是理科出生，理科靠的就是你的思维能力，在某些时候或许你的思维还不够敏捷，但我知道，每个人在接受了一段时间的工作后，就会产生各类的想法，或许某个想法你会改变你公司的命运，可为什么提出观点的人就寥寥无几呢？
我想可能是因为性格吧，因为很多程序员都是内向型，因为我们需要花一定的时间，去沉醉在代码中，因为这是一个奇妙的世界，无法自拔，所以很多时候就忽略了沟通，因为我们打交道最多的是abcd。如果你正是如此，希望你快点走出来吧，分清楚何时沉醉，何时交流才是最好的。我的偶像-唐骏，我看过他的访谈，他在大学时还是一个不会沟通的人，只是偏执于技术，而且和大多人一样，都会觉得自己什么都会，什么都行，是个天才，但在他大三的时候，他意识到了错误，花了几年的时间去学习交流、沟通，在宁愿委屈自己进入微软做程序员，再到无数次发意见给Bill，一步一步成就了这位打工皇帝。
所以，我们每个程序员要做的是，技术和沟通并行提高。在唐骏的话中，我会学到很多东西，他能从容应对每一次挑战，当时有幸成为唐骏的下属，见证过他的能力，虽然他当时只是个技术总监，但他的想法、创意给盛大带来了无比的利益，我不得不佩服他的胆大，不得不佩服他的能力。从他身上还学到了专一，其实很多程序员会在编程的道路上三心二意，这是很正常的，不过我相信一段时间以后你会学会专一的，因为程序真的很美，带来的不仅仅是工作和薪资。
我这里又不得不批判一些年轻程序员了，他们仅仅看中的是工资、福利等，没错，这是考虑工作的一点，但你要知道，有些时候，你第一点的工资，或许你会学到更多的东西呢？我经历过很多，经历过1年工资翻几番，又经历过折一倍，又经历过小公司，又经历过大公司，各种各样看的实在是很多，但我不会说我自己半途而废，因为每次我会把事情做的觉得自己可以了，我才会选择更好的发展前景。我面试过一些人，工作也就2，3年，做过的东西也很多偏向于OA、ERM等项目，就觉得自己很了不起了，工资也是漫天要价，可真正面谈的时候，我才得知，你仅仅是其中的一个小模块，但当我问其项目的整个运维的时候，就会楞个半天，最后来一句，这个模块不是我负责的，敷衍了事。那好，我问你自己负责的模块，如何具体写的，用了何种方式等，基本都会回答，三层架构，什么什么，My god 三层架构是你一个模块就能体现的吗？那好，既然你说三层，何为三层，三层的优点，缺点在哪里？诶~~~~~前几天首页那篇批判大学生的文章，我觉得写的太好了，你们这是在沉醉吗？如果你不喜欢，你为什么非要选择程序员这条路呢？
工作渐渐展开之后，就是平静如水的生活，每天上班，吃饭，睡觉，日子也过得很快。刚开始，由于懂得东西少，所以每次任务下来后，都是积极的去完成，因为害怕自己做不完。但是渐渐的，当自己清楚该怎么做的时候，人会产生疲倦，因为每天都做一些差不多的劳动。慢慢的，做事情就喜欢拖拉了。当分配一个任务后，自己先估量一下这个工作自己大概需要多久，一般老板给的时间会多很多。所以喜欢把工作先放着，去看看网页，逛逛论坛什么的，等到剩下的时间差不多了，需要开始工作了，就懒洋洋的进入工作状态，但是往往完成工作质量都不怎么好，很多提交后会有些BUG。不过我也没怎么在意。因为和老板关系好嘛，像我这样，再怎么说也属于元老级别的。就这样慢慢的工作了几年。因为小公司什么都要做，技术也积累了很多。包括各种主流数据库的用法，。NET，CSS,JAVASCRIPT,PHP,JAVA,perl,FLASH, 等等，其间，自己独立开发项目的时候，总想找出一种架构，加快自己下一个项目的开发进度。但是每次开发完后，发现上次设计的架构真垃圾。开发过很多项目，每次都想了一些新的架构方法。到现在沉淀下来的还值得用的架构思想也没多少。记得在做JSP的时候，感觉JSP里面服务端代码和HTML混在一起，很难看。不如。NET的事件驱动好用。就去写个模块，让JSP也实现事件驱动的模式。结果写到后来，也没得到什么好处，并且感觉有点不伦不类，后来项目慢慢做大了，才渐渐明白面向对象的用意。当一个项目很小，逻辑很简单的时候，用面向对象的方法设计用处不大，反倒是组件用处更大。因为项目小，基本上都是建几张表，改改HTML的工作。但是项目一大，逻辑变复杂了，如果你要理清楚逻辑，这里就需要一种方法论。我一开始写算法的那种方法有点不适用了。原来那种是从顶层开始，向下细分。是一种至上而下的设计方法。而面向对象不是，它是一种由点及面的设计方法。面向对象是先找出一个个对象点，然后再找出每个点之间的关系。在实际的项目中，你很难从上至下的设计。因为项目需求往往刚开始很不全面，很多项目后来改得都是面目全非。从上至下的设计不适合这种平凡的修改。并且当需求很大时，他涉及东西太多，你也很难从一个俯视的角度去全面的看这个系统。所以从上至下的设计不能满足要求。打个比方，记得一个项目已经做了80%，结果客户觉得用得不方便，要改一下。很多原来做的功能都不需要，并且提了几个新功能。但这几个功能也只是对原来的功能稍加改动。但是逻辑上看却是大相径庭。人脑不是电脑，如果想着这个代码，去改那个代码，势必到后来让自己也搞糊涂了。所以需要抽象出几个对象出来，是按照客户的思维方式。然后抽象出来的对象里面包含原来的功能。这样做起来就事半功倍。
在工作的磨练中，慢慢的发现了普通的程序员与优秀的程序员的一些差别：
1, 普通的程序员遇到问题喜欢张口就问别人，问之前没经过大脑想想。这是一个不好的习惯。其一，自己都没仔细想想，就算别人帮你把问题解决了，你自己不多久就会忘记。下次遇到，照样是不会。因为这个问题你没有经过大脑。其二，能够回答你问题的人，多半是有一定经验了。他们或许很会安排好自己的事情，管理好自己的时间。如果时常去打断他们，他们会觉得你很烦。
优秀的程序员多半会先到网上查找一下相关问题，看看网上有没有相关解决方法。经过一翻查找，他会把这个问题记得比较牢。
2，在一个项目的合作开发中，普通程序员往往只了解自己开发那方面的东西。项目做完后往往对整个项目有哪些功能都不太清楚。可能会有人抱怨，自己工作都做不完，哪有时间去了解整个系统。但现实多半是，花大量的时间去网上闲逛，却不愿花时间去增进知识。 如果总认为项目的设计是设计者的工作，自己没必要去了解。那么这样的程序员只能是手工劳动者。
优秀的程序员会对整个项目有认识，对一些自己感兴趣的功能会去做一下了解，更优秀一点的，会去对整个项目的架构设计做一下了解。自问如果他是项目设计者该怎么做？ 去学习项目设计的优秀之处，去发现设计的不足之处。触类旁通，把优秀的地方用在自己将来的工作当中。
3，普通程序员往往有很大的惰性。不能自觉的去学习知识，增进能力。所以每天耗费大量的时间在一些消遣状态中。所以时间往往白白的浪费掉。
优秀的程序员往往会安排好自己的工作和学习。在工作中学习，在学习中工作。能够感觉到自己每天都向着自己的目标在前进，状态佳，动力足。他们因为每天工作情绪很高，所以研究的东西也多，时间比较宝贵。因此他们会善于利用一些工具来操作自己的电脑，大大来的减少琐碎的电脑操作时间。更有胜者，会开发一些符合自己的操作习惯的小程序，来提高自己的效率。说不定这些小程序放到网上共享，可能还会有意想不到的收获。
我现在做项目管理，看着手下的程序员，时常也让我想起原来做程序员时候的坏毛病。比如，上班迟到啊，工作时间上网闲逛啊，交上来的程序BUG成堆啊！看到这些，我时常都是会心的笑笑，可以理解！ 不过我也时常提醒他们，如果你们想将来成为IT界的精英，而不是等到30岁感觉自己无路可走，那么请你们珍惜自己的时间。如果你们自己都不珍惜自己的时间，那么别人更不会去珍惜你的时间。
今天花了两个多小时，写了一篇短篇自叙。感觉值得，把自己五年多的光阴回顾了一遍。从前的故事历历在目。写下来过五年后再来回顾一下，说不定会是另一番感受。
怎样评定一名软件开发人员？这是一个颇为奇怪的问题。现在已经有了很多的理论和形式来做这件事，人力资源部门也试着帮你管理和反省自己的行为。然而，怎样才是一个伟大的软件开发人员，在今天，你该怎样发展你的职业生涯？以下是我评定团队中软件开发人员的军规.按照这些技巧和规则，你可以改善你的现状，由一个优秀的程序员，成为一名伟大的程序员。
1、时间花在写精彩的代码上
这里说的不是数量，而是质量。对此，一种歪曲是：要数量，也要质量。你也许会很多次的遇到以下的两种情境：
情境A:你有一个发疯似的能写代码的程序员，事情似乎在进展中然后，Bug开始不断出现，你们也不知道为什么，好像永远补不完。补完十个，又出来五个，现在你手里的，就是一大堆代码
情境B:你现在有一个看起来很聪明的程序员，你面试他的时候，他似乎无所不知，能把理论说的头头是道。然而，你留给他三个任务，三个星期以后，他还在做一些三天就该干完的事。这下该你困惑了，他这么聪明，他知道generics（详见备注）,多线程的一切事情，甚至还能给祖母级的人讲解什么是指针，让老太太兴奋的想去编程。可是--怎么什么都没完成？
于是，在梦境中--你写出了堪称伟大的代码，--伟大的代码是伟大的程序员写出来的，他睿智，明白代码的真正品质所在。写代码就像托尼？霍克在玩滑板一样自然优美，看上去就令人愉快。这些程序员以让你眼花的速度搞定一切，他们知道每个问题应该处理多长时间，也不会追捧寻觅所谓的世界最好解决方案，弄很多线程很多层来写一个简单的游戏。他们写的程序没有Bug,因为写的时候自己测试过了，在睡觉时也在写代码说的就是这样的人。这些程序员太宝贵了。
2、阐明问题
可以明确的是：即使有问题暂时处理不了，还有成百上千的方法去解决。有些人反应很迅速，很快就能提出多种解决方案。然而，一个伟大的程序员应该在做出行动以前清晰阐明问题--创建文档或用白板表达出来。他们写邮件给项目的管理者，这样表述：我想和你说说我是怎么理解这个问题的，我们能这样处理吗？然后他们就会动手给你多种方案。
对，这些人明白自己看问题和阐明立场的方式，而这理解方式大概不会是问题创建者所想要被理解的。请牢记这就是关键所在。一名伟大的程序员在尝试解决问题以前，一定要完全的理解它。你百分百搞明白了吗？没有？百分之九十九？--回去再多问些问题，确保百分之百理解清楚了。
3、怎样着手解决问题
那一搞明白了问题，就开始动手写代码？错！一个伟大的程序员应该按照规划，开始思考面临的多种选择，基于问题开始考虑最好的解决方案。我觉的这像一场国际象棋比赛。你知道每个棋可以怎么走，知道所有的游戏规则。但是你会马上走棋吗？不，你要审时度势，制订计划，紧盯对手，分析其通常的做法。和这一样，在你coding解决问题以前，你也要这么做。
看看问题，计算出需要怎样的结果，你的时间能怎么安排，预期的质量，你必须用的工具，好了，开工吧！
在面试一些新程序员的时候，当问他为什么选择.net方向时，经常听到一些这样的回答：记得曾经我的老师对我们说，当你在开发语言和工具方面不知道怎么选择的时候，那么你只要跟着微软走就行了。所以最终他选择了.net。我想大家都曾有过类似的经历。当经历过数年之后，一些人在.net的某方面成为了专家，有些人精通数据库方面，有些人精通web界面设计，有些人精通系统架构。还有一些人是什么都会，但不管哪一方面都算不上精通。当然还有另一些人，他们没有选择.net，他们选择了java，在若干年之后，他们说：java程序系统比.net系统更稳定之类。既然大家都是.net阵营，暂且对他们不予讨论。
结合自己的亲身经历，对准备成为。net程序员和已经成为。net程序员的新人一些快速成长建议：
1.选择研究方向后不要动摇
对.net好还是java好的问题，我一向的观点是：它们都好，它们都是软件开发领域的杰出工具，它们都能够做出非常出色的系统。评价一个系统好与不好的标准不在于开发语言，而在于系统本身，更多地在于这个系统的开发者-程序员本身。只要你是一个出色的程序员，你完全可以用你擅长的开发语言开发出高质量的系统，而不管这种开发语言是.net还是java。而如果你过度地徘徊在研究它们到底谁更好的时候，甚至不断地在二者之间辗转的时候，你损失的将是宝贵的时间。
2.尽量缩小研究范围
.net只是一个大方向，你应尽量将自己的研究范围缩小，比如专注于数据库，专注于xml方面，专注于ajax，只要你专注任何一个区域深入研究，当你成为专家之后，都不会愁饭吃。反之如果你什么都会，而没有一样真正精通，那么你可能永远只能做一个普通程序员。
3.找到正确的入门方法
不管做什么事，方法很重要。特别是入门时的方法。正确的入门方法将大大加快你学习的进度。了解语言本身和前提技术是最先要做的事情，比如你选择c#方向的asp.net，那么你必须先学习c#基础语法，和asp.net基础知识，并实际写小程序测试你学习的成果。当学会基本语法后马上找到asp.net的官方入门指导。微软做得很好的一个地方就是他的帮助系统做得很好。新人容易入门，建议首先从入门教程开始，这个东西就在你的机子上，在Framework SDK的菜单里面。强烈建议把这个教程全部学会。
4.多看别人的成果（源代码）
这个很重要，如果你是一个团队的新成员，那么看他们写好的代码将是非常好的学习途径，因为那些都是成功的代码经验。如果你还没有加入团队，是自学，那么找一个好的学习网站，多看上面的源代码也是很好的方式。另外一个强烈推荐的途径：仔细研究微软的.net StarterKit，个人认为这是.net入门学习途中最大的收获。
5.敢于接受新项目挑战，敢于尝试
主动承担公司的开发任务，敢于在项目中尝试你最新的研究成果将对你自身技术水平提高带来非常大的帮助。记得当初我在做一个建站平台项目时有过这样的经历，之前公司开发的项目大都在原有技术积累下面用成型的框架做开发，那时我也正在学习asp.net，不过那个项目我是主程序员，因此在开发上有很大自主性。于是1.0时我尝试将所有用户文章保存在web服务器的xml文件里，而不是像传统项目那样保存在数据库里，以希望减少web服务器和db服务器之间的数据传输。结果1.0系统实际运行时确实达到了我的目的，虽然随着数据量的大量增加，最终导致了IO瓶颈。但通过后来对IO瓶颈的优化解决，我在文件系统、服务器进程、xml应用、代码规范和性能优化等方面学到了很多东西，倘若当初按原来的模式写程序，将错过学习这些知识的很好机会。
6.不断推翻自己，敢于重构
这是对程序质量的要求，我认为只有不断地优化和改造自己的程序代码，才能最终写出高质量的程序，做出高质量的系统，最终使自己的技术水平提高。通常我会把实现一个功能的代码量作为衡量代码质量的标准，代码越少，越精简，同时又具有良好的可读性，就越理想。重构需要几个前提：首先是项目时间允许，然后是确实找到更好的代码组织逻辑，如一种很好的结构模式，更合理的面向对象调用方式等等。只要找到更好的解决办法，那么勇敢地推翻原来的程序框架，重构它，经过不断地重构后，有一天你回过头去看之前自己写的程序时会有一个感叹：哇，怎么以前我的程序写的这么烂阿。
7.跟上技术更新的脚步
软件技术更新速度有时真的让人很郁闷，经常听人说，刚学会.net1.0，马上就出了1.1，1.1刚完成一两个项目，又出了2.0，用2.0不到一年已经出了3.5，但现实就是这样，你必须得跟上脚步，当使用asp.net的时候，你就不能再像以前用asp那样去写程序，当使用.net2.0的时候，你要敢于使用masterpage，skin去代替原来的usercontrol模式，原来的网站皮肤实现模式。而现在出3.5了，你必须马上学习vs2008，学习Silverlight。只有跟得上技术更新的步伐，你才永远保持自己的技术领先地位。
以上几点建议，希望能给一些新加入的.net程序员们一些参考。
我和大部人从事IT的人一样，毕业后第一份工作刚开始也是从事软件开发，说得简单点就是程序员，因为刚从学校出来，对这个行业都不懂，但是听社会上工作一两年的人都说，做it要有职业规划。要先做程序员，到转到管理，于是我心里在想，所以我也有一个想法，就是以后要转向做管理。
后来我自己也从项目Leader,做到项目经理。
以前做程序员的时候，认为做项目经理或者项目主管只要在这方面做的时间长，经验丰富，别人遇到问题能解决就可以了，可是真正当我一步一步走上时，我才发现，原来并不这么简单。
刚做项目管理的时候，真的不知道要做些什么，因为我服务的公司不是一个很正规的公司，所以这方面的培训，也没有说教你说做项目主管应该做些什么，或者做项目经理应该做什么，后来我只有从网上找，朋友问，但是这些旁听来的消息，也不知道是真是假，半信半疑。
后来我也卖了一些这方面的书来看，想从中取经。
现在想想刚开始那段时间还真有一点难受，甚至有一段时间我在心里就想不做这个项目主管，让我做个程序员就可以了。
后来慢慢的，我们老总也给我很多帮助，也感谢公司里。net团队和flex团队的两位资深项目经理，他们也不断给我鼓励，给我帮助，让我慢慢的找到正确的路，让我慢慢知道项目经理应该做些什么，怎么样才算是一个好的项目经理。
现在回想起来，做一个项目经理应该具备以下能力：
1.用一句比较常用的话来说：上得了厅堂，下得了厨房。因为做项目经理的时候，难免会与客户打交道，也有可能与合作伙伴打交道。有的人出了公司，见了客户就发虚，底气不足，说话都很抖，让人爱给看扁了。有的甚至一见面就是哦,晕倒,哇靠之类的词就出来了，这样有个客户都会被你吓跑。有的也会很私文，气势都被对方压倒。我本人是07年毕业，到现在才两年多的时间，到现在为止面试的人员差不多有近百了，里面有研究生，有工作很多年的，我记得有一个工作九年的项目经理，能说会道，我和他面谈也很顺利，到面试完后，我才给他说，其实我是07年毕业的，他说真的看不出来。所以作为项目经理，在和自己组员打交道可以 随便点，但是和客户谈话，要注意分寸，有进有退，保持立场。
2.做事要目标明确，抓信问题的关键。不管和客户打交道，还是和程序员打交道，都要能快速的找到问题的关键。很多程序员遇到一个问题，不知道如何下手，其实只要点博一下，找到问题的关键所在，就能很快找到解决问题的办法。在有些场合要与客户谈判或者协商事情的时候，更要注意，更要能够快速找到关键的那一点，比如说人有时候都喜欢来两套，桌面上一套，桌面下一套，有些事在办公室谈不好，说不定到酒桌上就能谈好，但是要看对人，才能使对招，只有这样才能事半功倍。
3.项目经理要有推动力，也就是说你在你的团队，或者在你的谈判中，要能起到推动作用，把事情不断往前推进。让事情向前发展。这就和开会一样，一般来说开会都是遇到什么问题，需要开会来讨论，大家提会提出一些解决问题的办法，大家提出办法后，大家都在那里争论分析几种方法的优缺点，每种情况都有可能失败，都有可能带来损失，大家都不愿承担责任，如果让这种情况一直下去，我敢说他们会讨论几天都可以，这时就需要一个决策者来下结论，决定采用哪一种方法，然后快速的执行下去，而不是在那里无休止的分析。
4.要能承担压力。人遇到压力的时候，都会焦虑，而且有压力的情况下，思路可能会变得不清晰，有时候还会进到死胡同。这时候就需要一个临乱不乱的人，来支撑场面。如果头都乱了，那下面的人一定会乱。我个人认为我本人这一点是没有做好，以前有时候，项目收尾的时候，面对各种压力，比如客户的压力，程序员本身也有压力，还要面对老板的压力，要做到临乱不乱还是有一点难。
5.要有良好的回报心态。不管是在哪一个行来，不管在哪一个公司，也不管在哪一个职位，都要有一个良好的习惯，那就是回报.回报的意思，就是说你要向你直接领导报告你的实时情况，让你的领导随时能够了解你的进度情况，这样就算出了什么事，你的领导多少会有所准备。但是这都是在你回报的情况属实的情况下，我遇到的一个程序员就是每天给你回报说OK,可是真正当项目测试的时候，才发现什么都不OK,让我一点准备都没有。所以回报也一点属实。
以上是我自己的一点心得体会。其中也有些是我没有做好的，我也会在后面的工作中学习，改进，也提升自己。
没错，我还是一个程序员，每天还是坐在位置上书写着代码，收获着无聊。 四五年来我我一直保持这样一个坐姿，从每天的早上8点半开始，准备下班回家时结束。
我读的是机械设计制造及其自动化专业，因为迷上网络游戏就干脆转为学习计算机。当时的计算机专业可以说是一个热门专业，很多不怎么样的学校在这时候都开了这个专业，招生时要分数要得不低。这样的决定让我吃苦不少，我要一边保证自己的专业少挂科，以保证自己可以顺利毕业，一边又要保证自己的计算机水平足够在毕业后可以找到一份还行的工作。相比其它同学，我跟图书馆的计算机图书一样另类。他们谈恋爱的时候，我在试着把asp网页连上数据库。他们玩游戏的时候，我在网上到处搜索apache跟php整合的相关材料。
幸运的是，我的专业大部分考试都有六十来分，2005年下半年好歹毕业了。没有计算机背景，企业不会要一个只会把asp连上数据库的人，也不会要我来帮他配apache+php.终于有一家小公司要我进去做软件维护工作，我想都没想就去了，连我要做网页还是客户端软件都没问清楚。零工资实习三个月，外带1个月的试用期，最后才知道自己是来做软件实施的。老总告诉我，所有来这企业的人都得做1年的软件实施，这样才能知道客户需要什么样的软件，以后开发出来软件时才能更好的理解客户的需求。为了理解所谓的客户需求，我在不同的地方安装相同的软件整整安装了一年半，Oracle, Sybase, Sqlserver各种各样的商业数据库我都在上面瞎整过，我后来很佩服hibernate,它居然可以为很多种数据库提供同样的HQL语法，做过的人会知道其实各数据库之间的差异还真不少。还好老总善解人意，在一次公司尝试转型的大背景下，我被调到网站运营部负责网站运营，网站运营跟网站开发是两码子事，在一个小公司里，网站运营就是到各大论坛发垃圾贴子，公司这样做第一可以省去在google上做推广的钱，另外，在我发贴发到手酸的时候，老总还可以跑过来说，累了吧，那放松一下，去把公司网站改下背景颜色。换换思路嘛，脑子就不会打结。这半年里，所有的论坛都有我的ID号，很多论坛的ID被坛主封了又开，到现在，如果我要到某个论坛去下载一个附件，当提醒需要登录时，我网址都不用看直接输个ID和密码进去就行，成功率很高。公司终于又要转型了，因为他们发现发了这么多垃圾贴，还是没人来买他们的软件。我被派到公司的开发组，帮忙做些开发。终于可以称自己为程序员了。
在这半年的时间里，我一直在帮着其它程序员干着繁重的体力活。用HTML和javascript实现着客户们奇怪的网页效果。偶而写一点点JSP的页面，比方说写一个界面将查询结果显示出来等等，当然这也是我为什么现在是从事Java行业的主要原因。
07年初，我决定离开这家企业，在跟老总离职面谈时，他终于想到要为我这么个员工提一下有关工资的问题。他终于想到曾经进入这家企业时，我要求过企业在一定时间内将我的薪水涨到什么样的水平。我并没有接受他开出的更优越的条件，尽管在当时，这些薪水对于一个只会JSP的人来讲应当还行。从职业的发展角度来讲，我需要一个更好的空间，你要知道，在我离开这家企业之前，我还不知道CVS怎么用，Code Review是怎么回事。
相关文章
最新更新
