今天，根据自己的体会，我来谈谈项目经理的初始化阶段。
新人工作一段时间后，或长或短，可能一至两年后，有可能出任项目经理。此时，考验你能力的时候真正来临。项目分很多类，如基础研究项目，大型综合性项目。这里我们选取小的商业应用型项目为例。
刚开始，我们是没什么经验的，好在有热情。但这是项目，是一个讲究人与人之间配合的技巧性的活，光靠热情是难以持久的。退一步说，你是能力很强的聪慧之人，什么都拿得起放得下，那你充其量只是个精兵，而不是一个好的管理者。管理者的目标让整个组织的效率更高，管理者是没有那么多时间老是冲锋在前的，请深刻体会这一点。 因此我们得掌握一些基本的技术，讲究一些策略，力求避免未做勇士，先做烈士。
需要先补的课程是，项目的三要素：时间、成本、范围。
第一：时间
如果三峡项目做得很漂亮，质量很高，专家也很满意，惟一不足的是项目比预期推迟了两年半，那么这个项目的考评可能从A+会直降到C-甚至D-。因为这样一个大项目群，耽误一天便产生数以亿计的成本损耗。我们的项目虽然小，但道理是相通的。所以在执行项目之前。项目的时间至关重要。
客户有个时间表，老板有个预期的时间表，每个项目成员都有个时间表，作为项目经理，必须把这些协调起来，达成一个各方满意的结果、按照利益相关方的优先级别排序。这里有个分析的小技巧：请注意，老板说是下月底完工，你得有两手准备。一方面：alpha版一定要在下月上旬先给老板看下，给他一个初步印象，避免到时心里落差过大，情绪失控，万一有错，也来得及修正。另一方面，不要做得太细太完善，既浪费时间，又不给领导提意见的空间，领导只会怪你不会做事。于是，你得留一些简单的易于完成的小破绽给领导。是不是很委琐？！我相信这 样做，对项目组有利。当然，看具体的人，看性格。Zc530.cOm
第二：成本
项目花下去多少成本，预算时要心中有数。多大的西瓜多大的秤。这个成本包括时间成本、人力成本、费用成本等。在项目中间要勤计算挣值 。这是一个很关键的指标。投入与产出必须有一定的正相关系数关系。人有多大胆，地有多大产的教训在我身上太深刻了，记住，什么事都不要拍脑门，项目中没有任何板上钉钉的事，特别在公开会议上，要控制自己的情绪和言行。 有时候，一时不必要的斗气，让项目成员苦不堪言。
第三：范围
有了时间、成本的到位分析。范围就是一件简单的事了，简单的说，范围就是项目需要完成的程度。时间长、成本允许，可以内外兼修，各环节都做得漂亮，各方满意，自己也挺有成就。这是理想中的理想，基本上在实际中属于空想的范畴。所以，如何控制好范围，而又保持好项目成员的积极性，是一门学问，水很深哪！项目经理的一个基本观念是：项目是独立核算的，项目的考评是本项目完成到什么程度，而不是为了别的项目组或者为了下一次项目做了多少。如果这个项目可能为了别的项目组做出一些牺牲或额外努力，请尽量避免！如果必须得做，也需要在项目组 会议上言明，为自己项目组争取既得的回报，不一定非得物质的，比如领导的心知肚明，客户的理解和感激等，这些会帮你加分。千万不要偷偷摸摸的干，把项目成员的暗中努力不当回事，我是雷锋我怕谁已经不能用来唬人了，这是个讲究科学、兼顾效益的商业社会。
有人会问，在这三者冲突的情况下，如何取舍。建议很明确：先砍功能，也就是范围，把一些能推到项目二期的先往后推，向范围要时间。所以，在项目开始之前，要给项目孵出20%左右的可压缩时间，这个只有项目经理自己清楚，不必言明。
最不可取的就是项目经理挥刀自宫，让整个项目组在低成本下高速运行，这样的项目最后成败我们先不说，在项目成员的眼中，你基本上与黄世仁无异，甚至不用等到项目结束，就已经牺牲了。所以在第一次项目中一定不要让项目成员感觉跟你就是为了体验雪山草地，他们配合你，一是出于利益，二才是看你这个人值不值得跟。都看着你呢。所以，遇到不顺事先忍着，抓重点，回头再总结。这就是前文所说的做人、做事的原则：为什么级别的事情，就得付出什么级别的代价！
其实，第一次，不要将成败看的太重，教训要自己书写。有人说，哪怕只打一次仗，一个兵才会淬火成为真正的军人。谁没有第一次呢？做人，要经得起失败，但得明明白白地失败。
有人说 程序员的人生有三重境界。第一重、见山是山，见水是水。刚入门的程序员基本只能看到表面的东西，由于各种原因，没法了解更深入。第二重、见山不是山，见 水不是水。成长并有经验后，看到的表面现象渐渐有头脑中成型，犹如行军详细地图已经了然于胸。第三重、见山亦是山，见水亦是水。大悟之后，举重若轻，外松内紧，处事看似笨拙，实则暗藏玄机，惜语如金，然字字珠矶。此时，胸中亦有各种框图，然表面内敛以藏拙，见人说人话，见鬼与鬼语，谓之通灵也。
要想修炼到气定神闲的第三重境界，那就用心和智慧体验吧！
zc530.com推荐
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,技术不高怎么对付组里的牛人
我们经常会因为公司里的顶尖人才、个性化太强，不能与其他人合作而感到棘手，要解决这一问题其实也是有法可寻的。
一、在肯定其价值和优势的前提下，明确地制定改进的目标；
二、顶尖人才能够面对中肯的，明确及一对一的批评作正面反应，所以要加强与他沟通的力度；
三、可以根据具体情况调整考核目标，加强与其他员工合作的内容；
四、把顶尖人才调到相对能独立发挥其才能的岗位，减少与别人发生矛盾的机会。
第三部分，未来职业生涯规划、家庭环境分析、例如经济状况，家人期望等。感谢您阅读《大项目、小项目都是程序员成熟之道[2]》内容，职场资讯网小编向您推荐一些职业规划知识，欢迎参考，希望能帮到你。
而我今天说的项目大小是从软件项目本身来确定的，与客户对项目大小的定义没有什么太大的关系。我认为项目大小可以从以下几个维度去考虑：资金、开发人月、项目复杂度。
1、 资金
我认为在当今物价状态下，5万以上50万以下为小项目。50万以上为大项目，500万以上为特大项目。
2、 开发人月
同理，2.5个人月到25个人月以下为小项目。25个人月以上为大项目。
3、 项目复杂度
软件项目的复杂度还可以用软件的用户使用人数、数据库中表的数量、表的记录数来衡量：
软件使用人数：10-1000人为小项目，1000人以上为大项目。
数据库表的数量：20-100张为小项目，100张以上为大项目。
表中的记录数：10万-1000万为小项目，1000万以上为大项目。
此外，项目运行能够给客户带来的收益大小、项目的业务逻辑的复杂度都可以成为项目大小考量的内容。
如果项目都不能达到小项目的水平，我们这里就不把它看作项目了，因为低于小项目的项目很多是个人编程，这与项目众人参与的特点有点不符。
所以我对程序员的建议是：
1、 要主动参加项目
无论大项目还是小项目程序员都要努力参加进去，因为只有做了项目自己的能力才能提高。不要静静待在那里，等待别人挑选，而是积极主动表示加入项目的愿望。在我负责过的项目过程中，我对主动要求加入项目的程序员往往给与更多的机会，因为这样的程序员具有主动性，工作更好开展。一个项目的出现就是一个机会的出现，把握项目就是把握机会。机不可失，时不在来。
2、 不要放过小项目
程序员不要以小而不为，只有做过若干个小的项目后，程序员才能去做大项目。那些想一步就做大项目的程序员，往往会失去小项目锻炼的机会，往往参加到大项目后，感到力不从心。项目虽小也同样可以锻炼人，程序员可以有更多机会体验项目负责人的脚色。学会从整体角度上来看待编程。
3、 要积极准备参加大项目
对于已参加过小项目的程序员，一定要把握机会，积极准备参加大项目，项目越大，越锻炼人。在大项目中要学会摆正自己的位置、虚心向团队其他成员学习。要在平时没有项目的时候，要多做些技术准备，多关注可能的大项目开发内容。在项目开发中，则可以把重点放在体会不同功能模块之间的关系上。学会从关联的角度上看待编程。
根据我的经验，我认为程序员要经过5-6个小项目的锻炼才能入门，而经历了3个以上的大项目的程序员才开始成熟。当然我们不能排除程序员的天才成分，有的程序员会再很短的时间达到一个很高的水平。但是，绝大多数程序员成长是必须通过项目来催化的，尤其是大的项目催化更加重要。说白了，项目如同阳光，程序员如同禾苗，关系就是那么简单。
职业规划就是对职业生涯乃至人生进行持续的系统的计划的过程。一个完整的职业规划由职业定位、目标设定和通道设计三个要素构成。
一下子就跨到了新年，时间真快呀！言归正传，今天谈谈项目问题。
我们常听到同行说自己做过什么项目，说某某做过什么项目。一谈到项目就会眉飞色舞，兴高采烈。而不少新进单位的新大学生、一些编程新手，往往不知道什么项目，不知道项目与自己成长的关系，有的甚至声称编程好几年了，还都没有做过项目的经历。情况确实如此，只有参加过项目的程序员才是真正的程序员。那些没有做过项目的虽然自己编制了不少程序，虽然得意过自己的程序，但是，毕竟和做过项目的程序员有很大的差别，这些差别主要在于：
1、 程序的价值
没有做过项目的程序员，编写程序的目的主要是学习，通过编程来提高自己的编程能力，编啥、怎么编都由自己主观决定，自己能做什么不能做什么都不是太清楚。至于程序能否被别人使用，程序能否卖出价钱，程序员并不太关心。
做项目的程序员则不一样，他编写的程序不是用来学习的（尽管他是抱着学习的态度参加项目的），而是作为商品的一部分出售的，编出的程序要投入日常运行的。他别无选择，必须完成程序功能。程序员的价值通过程序出售的价格以及程序使用来体现。
2、 程序的时间要求
没有做过项目的程序员，编写程序的时间长度是由自己决定的，自己高兴什么时候编好就什么时候编好，遇到其它事打搅，拖个十天半个月也无所谓！
做项目的程序员则不一样，他必须在规定的时间内完成编程，只能提前不能延后，否则整个项目进度就会被它拖后腿，而由于项目延期不能按时交付给客户，其结果就有可能因延误被罚款，甚至取消项目。
3、 团队
没有做过项目的程序员基本上是单枪匹马地编写程序，程序功能相对简单，一个人多花点时间也能完成。
做项目的程序员则成了项目组的一个成员，他只是负责整个项目的一个部分，或者说只编写其中的一段程序，而不是全部。因此，他的程序必须要和其他人编制的程序对接、他的程序必须读别人的数据，他的数据也可能被别人读。这里的每一个环节都不能出错，一个地方出错就会影响整个项目。所以，他必须和团队的其他人很好协作共同来完成自己的程序。
4、 学习氛围
没有做过项目的程序员学习靠自学，靠网上google去学，学的内容随意性很强，学好学坏没有人监督。
做项目的程序员不但靠自学、靠网上google去学，还必须向项目负责人去学、向项目组其他人去学、向客户去学。而且学的东西都有针对性。向项目负责人去学习程序设计详细方案、向项目组其他人去学习程序接口、数据接口、向客户学习业务及需求等。程序的好坏要通过测试环节和用户使用加以验证。
所以，通过参加项目程序员可以克服自以为是的错误观念，树立为客户编程的思想，以软件销售价值来衡量自己的价值；树立团队意识，把自己融入到团队之下中，以团队荣为荣，以团队耻为耻；在项目中学会从大局看待程序设计、学会评判程序难易之处，学习更加实用的程序方法和算法。
那么是什么项目？这里所指的项目可能和一般的项目定义侧重有所不同。这里的项目一般是指客户提出需求，软件公司或企业内部项目小组按照需求进行设计、开发，投产、维护等工作的总和。它只包含软件相关的费用，其他硬件、网络、软件环境费用不在此考虑之列。
项目是有大有小的，有的大的项目以亿为计，有的小项目以千而计，千差万别。由于没有标准，不同的人对项目的大小定义是不同的。例如，有的企业把一百万以上的软件称之为项目，把1千万以上称之为大项目。有的小企业把1万元以上的软件称之为项目，把5万元以上称之大项目。这些项目大小主要取决客户对资金管理范围和等级，一般而言，项目越大，需要单位或企业越高的领导层批准。
本人普通院校，非计算机专业本科毕业。从毕业到现在也工作有五年了。回忆起程序人生，也颇有一翻滋味。
本人是从大三上学期开始学习计算机的，因为那时电脑突然一下比较普及，本人家里也有能力买台电脑。买了电脑后，最先看的是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，当时对这个知道的很少，只能一边翻书，一边做事。要达到老板的要求，每天都八点左右才能搞完下班。
工作渐渐展开之后，就是平静如水的生活，每天上班，吃饭，睡觉，日子也过得很快。刚开始，由于懂得东西少，所以每次任务下来后，都是积极的去完成，因为害怕自己做不完。但是渐渐的，当自己清楚该怎么做的时候，人会产生疲倦，因为每天都做一些差不多的劳动。慢慢的，做事情就喜欢拖拉了。当分配一个任务后，自己先估量一下这个工作自己大概需要多久，一般老板给的时间会多很多。所以喜欢把工作先放着，去看看网页，逛逛论坛什么的，等到剩下的时间差不多了，需要开始工作了，就懒洋洋的进入工作状态，但是往往完成工作质量都不怎么好，很多提交后会有些BUG。不过我也没怎么在意。因为和老板关系好嘛，像我这样，再怎么说也属于元老级别的。就这样慢慢的工作了几年。因为小公司什么都要做，技术也积累了很多。包括各种主流数据库的用法，。NET，CSS,JAVASCRIPT,PHP,JAVA,perl,FLASH, 等等，其间，自己独立开发项目的时候，总想找出一种架构，加快自己下一个项目的开发进度。但是每次开发完后，发现上次设计的架构真垃圾。开发过很多项目，每次都想了一些新的架构方法。到现在沉淀下来的还值得用的架构思想也没多少。记得在做JSP的时候，感觉JSP里面服务端代码和HTML混在一起，很难看。不如。NET的事件驱动好用。就去写个模块，让JSP也实现事件驱动的模式。结果写到后来，也没得到什么好处，并且感觉有点不伦不类，后来项目慢慢做大了，才渐渐明白面向对象的用意。当一个项目很小，逻辑很简单的时候，用面向对象的方法设计用处不大，反倒是组件用处更大。因为项目小，基本上都是建几张表，改改HTML的工作。但是项目一大，逻辑变复杂了，如果你要理清楚逻辑，这里就需要一种方法论。我一开始写算法的那种方法有点不适用了。原来那种是从顶层开始，向下细分。是一种至上而下的设计方法。而面向对象不是，它是一种由点及面的设计方法。面向对象是先找出一个个对象点，然后再找出每个点之间的关系。在实际的项目中，你很难从上至下的设计。因为项目需求往往刚开始很不全面，很多项目后来改得都是面目全非。从上至下的设计不适合这种平凡的修改。并且当需求很大时，他涉及东西太多，你也很难从一个俯视的角度去全面的看这个系统。所以从上至下的设计不能满足要求。打个比方，记得一个项目已经做了80%，结果客户觉得用得不方便，要改一下。很多原来做的功能都不需要，并且提了几个新功能。但这几个功能也只是对原来的功能稍加改动。但是逻辑上看却是大相径庭。人脑不是电脑，如果想着这个代码，去改那个代码，势必到后来让自己也搞糊涂了。所以需要抽象出几个对象出来，是按照客户的思维方式。然后抽象出来的对象里面包含原来的功能。这样做起来就事半功倍。
在工作的磨练中，慢慢的发现了普通的程序员与优秀的程序员的一些差别：
1, 普通的程序员遇到问题喜欢张口就问别人，问之前没经过大脑想想。这是一个不好的习惯。其一，自己都没仔细想想，就算别人帮你把问题解决了，你自己不多久就会忘记。下次遇到，照样是不会。因为这个问题你没有经过大脑。其二，能够回答你问题的人，多半是有一定经验了。他们或许很会安排好自己的事情，管理好自己的时间。如果时常去打断他们，他们会觉得你很烦。
优秀的程序员多半会先到网上查找一下相关问题，看看网上有没有相关解决方法。经过一翻查找，他会把这个问题记得比较牢。
2，在一个项目的合作开发中，普通程序员往往只了解自己开发那方面的东西。项目做完后往往对整个项目有哪些功能都不太清楚。可能会有人抱怨，自己工作都做不完，哪有时间去了解整个系统。但现实多半是，花大量的时间去网上闲逛，却不愿花时间去增进知识。 如果总认为项目的设计是设计者的工作，自己没必要去了解。那么这样的程序员只能是手工劳动者。
优秀的程序员会对整个项目有认识，对一些自己感兴趣的功能会去做一下了解，更优秀一点的，会去对整个项目的架构设计做一下了解。自问如果他是项目设计者该怎么做？ 去学习项目设计的优秀之处，去发现设计的不足之处。触类旁通，把优秀的地方用在自己将来的工作当中。
3，普通程序员往往有很大的惰性。不能自觉的去学习知识，增进能力。所以每天耗费大量的时间在一些消遣状态中。所以时间往往白白的浪费掉。
优秀的程序员往往会安排好自己的工作和学习。在工作中学习，在学习中工作。能够感觉到自己每天都向着自己的目标在前进，状态佳，动力足。他们因为每天工作情绪很高，所以研究的东西也多，时间比较宝贵。因此他们会善于利用一些工具来操作自己的电脑，大大来的减少琐碎的电脑操作时间。更有胜者，会开发一些符合自己的操作习惯的小程序，来提高自己的效率。说不定这些小程序放到网上共享，可能还会有意想不到的收获。
我现在做项目管理，看着手下的程序员，时常也让我想起原来做程序员时候的坏毛病。比如，上班迟到啊，工作时间上网闲逛啊，交上来的程序BUG成堆啊！看到这些，我时常都是会心的笑笑，可以理解！ 不过我也时常提醒他们，如果你们想将来成为IT界的精英，而不是等到30岁感觉自己无路可走，那么请你们珍惜自己的时间。如果你们自己都不珍惜自己的时间，那么别人更不会去珍惜你的时间。
今天花了两个多小时，写了一篇短篇自叙。感觉值得，把自己五年多的光阴回顾了一遍。从前的故事历历在目。写下来过五年后再来回顾一下，说不定会是另一番感受。
第三部分，未来职业生涯规划、家庭环境分析、例如经济状况，家人期望等。感谢您阅读《初中物理教师职业成长目标规划》内容，职场资讯网小编向您推荐一些职业规划知识，欢迎参考，希望能帮到你。
xx—xx年目标：
1、参加二七区课堂达标，通过第一轮、第二轮选拔
2、参加一师一优课，并获奖
3、参加立项并通过
4、各种征文大赛获得三等奖以上
5、所带班级较优秀，深受学生喜爱
6、每月看完二本书：教育类书籍和物理专业书籍
7、每周写博客、反思等材料3篇
8、累积定级材料
9、教师积分争取前十，获得优秀称号等
xx—xx年目标：
1、参加二七区课堂达标 最低目标：区二等奖，最高目标：有资格参加市级评比
2、参加一师一优课，并获二等奖
3、完满结项，并获得二等奖
4、各种征文大赛获得二等奖以上
5、所带班级优秀，深受学生喜爱，获得优秀班主任一次
6、每月看完三本书：物理专业书籍以及其他书籍，并做笔记
7、争取博客加精篇数1学期2—3篇，获得郑州博客大赛二等奖
8、符合定级标准
9、教师积分争取前十，获得优秀称号等
xx—xx年目标：
1、参加一师一优课，并获一等奖
2、参加立项并通过
3、各种征文大赛获得一等奖
4、所带班级优秀，获得文明班级称号等
5、每月阅读3本书，
6、向名师学习，力争符合标准。
7、争取博客加精篇数1学期2—3篇，获得郑州博客大赛二等奖
8、符合定级条件，积分达到定级积分，定上中一
9、教师积分争取前十，获得优秀称号等
总之，未来三年就是学习、成长、成熟，把自己的课教好，令学生满意，把班主任带好，获得管理经验，并获得一定的奖项，不留遗憾！
5年就这么过去了吗？ 这是笔者和许多朋友共同的回答。可令人诡谲的是当笔者试图回想5年前流行的IT技术是什么时却一时答不出来，矛盾点是什么？如果时间过的很快的话，那么为什么我们无法想起当时的IT技术？ 其实会有这样的情形一点也不奇怪，因为这5年来IT技术改变和进步的幅度是既深且广。
回头翻开笔者在数年前于《Borland传奇》后半部对于IT演进趋势的看法，笔者精确的提出了对象导向和Modeling技术将平民化和Web Service穿透平台的能力。不过笔者没有预料到软件工程和测试方法对于开发模式会有着这么迅速的影响力。
看看现今的IDE，几乎没有IDE不受软件工程和测试方法的影响，愈来愈多的IDE都提供了一种或是数种软件工程以及测试方法。最近再加上CMMI的影响，未来的开发工具（已经不再是单纯的IDE了）将继续融入CMMI的功能，而且一旦开发工具开始提供协助CMMI Level 3以上的功能时，代表未来的开发环境将可以把开发人员的开发效率，开发质量，开发方法都加以数量化，到时开发人员将必须进一步的提升自己的精致化开发能力，否则将很容易的在下一代开发环境中被现出原型。
软件工程和测试方法的进步也将让触发两种改变，那就是设计模型和设计架构即将像现在的程序代码一样能够被稽核和数量化，而测试计划也将提前在设计阶段即能够执行设计，模型和架构的测试。这个变化将会对设计师和架构师产生即巨大的冲击。
主流程序语言的语法和语意愈来愈像彼此一点都不奇怪，重要的是要了解程序语言本身的演变。目前宣告程序语言（Declaration Language）在。NET的主导下也逐渐的被Java所接受，而在程序语言本身融入XML原生的功能也由Java领军C#在后追赶。因此我们可以预料这两个趋势在未来数年之内会左右程序语言的发展。写到这里就不得不佩服Borland前首席科学家Chuck的睿智，Chuck在数件前即在Borland内部提出了Apollo计划，也就是目前OR-Mapping等技术的前身观念，而在2003年左右Chuck也在Borland内部着手了Z程序语言的计划，而Z就准备使用XML的数据型态做为Z的原生数据型态，并且执行流程和执行概念就以Web Service的架构为设计中心，而这正是下一代Java和C#想要实作出来的技术。更重要的是程序语言在这些新技术需求的刺激之下，已经逐渐成为一个技术融合的核心，未来当特定的IT技术成为IT的必要应用时，这个特定的IT技术就会慢慢融入程序语言的演化并且成为程序语言的核心功能。简单的说，程序语言本身将逐渐成为吞噬IT技术的多形机制。
OR-Mapping技术和对象查询语言也将会是接下来IT的重点技术，看看Hibernate的盛行，OCL的影响力日益加大，MS也会推出Object Space技术，连EJB 3.0都深受影响之下，这两个技术将成为左右数据存取技术和对象对映技术的主要力量。
那么我们应该如何面对下一个IT的5年呢？ 其实答案也不难，那就是体认开发方法和开发流程是比开发技术来得重要。尽快找到一个适合你自己或是你的团队的软件工程方法，不管是XP，RUP，MDA，FDD或是任何的方法，使用正确的开发方法提升开发效率和开发质量是目前重要的工作。接着看看你着重的IT领域是什么，再找出这个IT领域背后的主导力量，巧妙的结合开发方法和技术趋势主导力量，应该可以让你立于不败之地。此外对于每一个新的技术，语言，IT应用等等思索它们形成的背后原因，想想这些背后的原因会对你的事业有什么影响，如此一来就不会穷于应付层出不穷的IT技术。当然，要看未来的5年您还是得先回首看看自己脚下的基本功打好了没有，否则一切都是空谈。
感觉有些是企业环境因素，不是项目经理能力范围，以项目经理的实践经历来评估。但感觉有点抽象，没有深入探讨，与实际中应用对比起来。
1级：具备项目管理的一些基本知识，有一定的计划、控制意识，但还没有全面掌握PMBOK知识。
这一类人，在实际中较多，基本上靠自己的经验和意识在管理项目，对于系统学习项目管理体系知识还有些抗拒，认为过于理论化，实则是还没有意识到项目管理的重要性。典型的一种例子，在项目计划中，只注重开发任务，对于项目干系人的沟通计划、项目实施得不太关注。这类角色，实际还不太具备项目经理的能力，顶多是开发小组组长，但实际还是不少人担任项目经理，如果项目技术性较强，这类人可以担当，如果项目业务类较强，项目实施涉及较多干系人，则通常项目会搞得很糟。
2级：全面掌握项目管理知识领域知识，并能结合实际运用，有一定的沟通协作能力。
与第1级相比，2级的PM意识到项目管理的重要性，主动学习相关的知识，并在实践中应用。意识到沟通、计划的重要性。
已经可以单独承担6-12人月的项目。可以管理10人左右的项目团队。
3级：可以管理项目群，相当我们说的部门经理或者高级项目经理了。一般会管理几个项目的项目群。
与2级相比，这一类具有更好的沟通能力，以及教练指导能力、授权能力，以及团队建设能力。一般可以管理的团队规模在20-50人。
4级：可以管理一个团队规模在100人以上、项目规模几百人月以上的大型项目，也就是我们说的项目总监。
与3级相比，4级因为管理团队规模较大，会在市场战略分析、管理标准化和规范化（如开发过程体系、绩效考核体体系、人员培训计划）多下功夫，与公司高层、外部客户的沟通协作能力也很强。已经开始上升到高层管理角色了。
5级：应该是大型公司的GM、CTO级别了，不过这个层次的主要工作好象不是项目管理了，是企业管理了，一般已是公司总裁级别，或者是事业部负责人。严格意义上，这类角色已经是不是在管理项目，他们是在管理企业，我之所以列在这里，是从职业通道上，很多做到4级的项目总监，有希望再上一层，走到这一级。所以我将题目由项目经理的能力成熟度探讨扩展为项目经理的能力成熟度与职业阶梯探讨。
我和大部人从事IT的人一样，毕业后第一份工作刚开始也是从事软件开发，说得简单点就是程序员，因为刚从学校出来，对这个行业都不懂，但是听社会上工作一两年的人都说，做it要有职业规划。要先做程序员，到转到管理，于是我心里在想，所以我也有一个想法，就是以后要转向做管理。
后来我自己也从项目Leader,做到项目经理。
以前做程序员的时候，认为做项目经理或者项目主管只要在这方面做的时间长，经验丰富，别人遇到问题能解决就可以了，可是真正当我一步一步走上时，我才发现，原来并不这么简单。
刚做项目管理的时候，真的不知道要做些什么，因为我服务的公司不是一个很正规的公司，所以这方面的培训，也没有说教你说做项目主管应该做些什么，或者做项目经理应该做什么，后来我只有从网上找，朋友问，但是这些旁听来的消息，也不知道是真是假，半信半疑。
后来我也卖了一些这方面的书来看，想从中取经。
现在想想刚开始那段时间还真有一点难受，甚至有一段时间我在心里就想不做这个项目主管，让我做个程序员就可以了。
后来慢慢的，我们老总也给我很多帮助，也感谢公司里。net团队和flex团队的两位资深项目经理，他们也不断给我鼓励，给我帮助，让我慢慢的找到正确的路，让我慢慢知道项目经理应该做些什么，怎么样才算是一个好的项目经理。
现在回想起来，做一个项目经理应该具备以下能力：
1.用一句比较常用的话来说：上得了厅堂，下得了厨房。因为做项目经理的时候，难免会与客户打交道，也有可能与合作伙伴打交道。有的人出了公司，见了客户就发虚，底气不足，说话都很抖，让人爱给看扁了。有的甚至一见面就是哦,晕倒,哇靠之类的词就出来了，这样有个客户都会被你吓跑。有的也会很私文，气势都被对方压倒。我本人是07年毕业，到现在才两年多的时间，到现在为止面试的人员差不多有近百了，里面有研究生，有工作很多年的，我记得有一个工作九年的项目经理，能说会道，我和他面谈也很顺利，到面试完后，我才给他说，其实我是07年毕业的，他说真的看不出来。所以作为项目经理，在和自己组员打交道可以 随便点，但是和客户谈话，要注意分寸，有进有退，保持立场。
2.做事要目标明确，抓信问题的关键。不管和客户打交道，还是和程序员打交道，都要能快速的找到问题的关键。很多程序员遇到一个问题，不知道如何下手，其实只要点博一下，找到问题的关键所在，就能很快找到解决问题的办法。在有些场合要与客户谈判或者协商事情的时候，更要注意，更要能够快速找到关键的那一点，比如说人有时候都喜欢来两套，桌面上一套，桌面下一套，有些事在办公室谈不好，说不定到酒桌上就能谈好，但是要看对人，才能使对招，只有这样才能事半功倍。
3.项目经理要有推动力，也就是说你在你的团队，或者在你的谈判中，要能起到推动作用，把事情不断往前推进。让事情向前发展。这就和开会一样，一般来说开会都是遇到什么问题，需要开会来讨论，大家提会提出一些解决问题的办法，大家提出办法后，大家都在那里争论分析几种方法的优缺点，每种情况都有可能失败，都有可能带来损失，大家都不愿承担责任，如果让这种情况一直下去，我敢说他们会讨论几天都可以，这时就需要一个决策者来下结论，决定采用哪一种方法，然后快速的执行下去，而不是在那里无休止的分析。
4.要能承担压力。人遇到压力的时候，都会焦虑，而且有压力的情况下，思路可能会变得不清晰，有时候还会进到死胡同。这时候就需要一个临乱不乱的人，来支撑场面。如果头都乱了，那下面的人一定会乱。我个人认为我本人这一点是没有做好，以前有时候，项目收尾的时候，面对各种压力，比如客户的压力，程序员本身也有压力，还要面对老板的压力，要做到临乱不乱还是有一点难。
5.要有良好的回报心态。不管是在哪一个行来，不管在哪一个公司，也不管在哪一个职位，都要有一个良好的习惯，那就是回报.回报的意思，就是说你要向你直接领导报告你的实时情况，让你的领导随时能够了解你的进度情况，这样就算出了什么事，你的领导多少会有所准备。但是这都是在你回报的情况属实的情况下，我遇到的一个程序员就是每天给你回报说OK,可是真正当项目测试的时候，才发现什么都不OK,让我一点准备都没有。所以回报也一点属实。
以上是我自己的一点心得体会。其中也有些是我没有做好的，我也会在后面的工作中学习，改进，也提升自己。
相关文章
最新更新
