我和大部人从事IT的人一样，毕业后第一份工作刚开始也是从事软件开发，说得简单点就是程序员，因为刚从学校出来，对这个行业都不懂，但是听社会上工作一两年的人都说，做it要有职业规划。要先做程序员，到转到管理，于是我心里在想，所以我也有一个想法，就是以后要转向做管理。
后来我自己也从项目Leader,做到项目经理。
以前做程序员的时候，认为做项目经理或者项目主管只要在这方面做的时间长，经验丰富，别人遇到问题能解决就可以了，可是真正当我一步一步走上时，我才发现，原来并不这么简单。
刚做项目管理的时候，真的不知道要做些什么，因为我服务的公司不是一个很正规的公司，所以这方面的培训，也没有说教你说做项目主管应该做些什么，或者做项目经理应该做什么，后来我只有从网上找，朋友问，但是这些旁听来的消息，也不知道是真是假，半信半疑。
后来我也卖了一些这方面的书来看，想从中取经。
现在想想刚开始那段时间还真有一点难受，甚至有一段时间我在心里就想不做这个项目主管，让我做个程序员就可以了。
后来慢慢的，我们老总也给我很多帮助，也感谢公司里。net团队和flex团队的两位资深项目经理，他们也不断给我鼓励，给我帮助，让我慢慢的找到正确的路，让我慢慢知道项目经理应该做些什么，怎么样才算是一个好的项目经理。
现在回想起来，做一个项目经理应该具备以下能力：
1.用一句比较常用的话来说：上得了厅堂，下得了厨房。因为做项目经理的时候，难免会与客户打交道，也有可能与合作伙伴打交道。有的人出了公司，见了客户就发虚，底气不足，说话都很抖，让人爱给看扁了。有的甚至一见面就是哦,晕倒,哇靠之类的词就出来了，这样有个客户都会被你吓跑。有的也会很私文，气势都被对方压倒。我本人是07年毕业，到现在才两年多的时间，到现在为止面试的人员差不多有近百了，里面有研究生，有工作很多年的，我记得有一个工作九年的项目经理，能说会道，我和他面谈也很顺利，到面试完后，我才给他说，其实我是07年毕业的，他说真的看不出来。所以作为项目经理，在和自己组员打交道可以 随便点，但是和客户谈话，要注意分寸，有进有退，保持立场。
2.做事要目标明确，抓信问题的关键。不管和客户打交道，还是和程序员打交道，都要能快速的找到问题的关键。很多程序员遇到一个问题，不知道如何下手，其实只要点博一下，找到问题的关键所在，就能很快找到解决问题的办法。在有些场合要与客户谈判或者协商事情的时候，更要注意，更要能够快速找到关键的那一点，比如说人有时候都喜欢来两套，桌面上一套，桌面下一套，有些事在办公室谈不好，说不定到酒桌上就能谈好，但是要看对人，才能使对招，只有这样才能事半功倍。
3.项目经理要有推动力，也就是说你在你的团队，或者在你的谈判中，要能起到推动作用，把事情不断往前推进。让事情向前发展。这就和开会一样，一般来说开会都是遇到什么问题，需要开会来讨论，大家提会提出一些解决问题的办法，大家提出办法后，大家都在那里争论分析几种方法的优缺点，每种情况都有可能失败，都有可能带来损失，大家都不愿承担责任，如果让这种情况一直下去，我敢说他们会讨论几天都可以，这时就需要一个决策者来下结论，决定采用哪一种方法，然后快速的执行下去，而不是在那里无休止的分析。
4.要能承担压力。人遇到压力的时候，都会焦虑，而且有压力的情况下，思路可能会变得不清晰，有时候还会进到死胡同。这时候就需要一个临乱不乱的人，来支撑场面。如果头都乱了，那下面的人一定会乱。我个人认为我本人这一点是没有做好，以前有时候，项目收尾的时候，面对各种压力，比如客户的压力，程序员本身也有压力，还要面对老板的压力，要做到临乱不乱还是有一点难。
5.要有良好的回报心态。不管是在哪一个行来，不管在哪一个公司，也不管在哪一个职位，都要有一个良好的习惯，那就是回报.回报的意思，就是说你要向你直接领导报告你的实时情况，让你的领导随时能够了解你的进度情况，这样就算出了什么事，你的领导多少会有所准备。但是这都是在你回报的情况属实的情况下，我遇到的一个程序员就是每天给你回报说OK,可是真正当项目测试的时候，才发现什么都不OK,让我一点准备都没有。所以回报也一点属实。
以上是我自己的一点心得体会。其中也有些是我没有做好的，我也会在后面的工作中学习，改进，也提升自己。
延伸阅读
管理人或管理问题?优秀IT技术经理必读[2]
肯鲍彻（Ken Boucher）以前是提供电子商务和支付处理服务的Smalltalk开发人员，他在极限编程讨论列表中写道：我感到很困惑。我觉得经理的工作是管理问题，不是管理我。只有需要与另一个部门协调，或者我自己解决不了问题时，我才需要经理来介入。
他继续说：比方说，我需要经理来处理那些人力资源事务，或者弄清楚为什么DB2部门不提前六星期通知就无法创建一张简单的表。我需要经理能够用六西格玛人员听得懂的话，向他们解释我们所做的工作，解释为什么我们所做的与他们所要求的似乎不一样。我不需要纯粹管理我的经理，而是需要处理这些事务的经理。
软件质量保证分析师亚历克思（Alex）补充说：经理没必要知道如何编写程序，他只要了解这方面的方法、流程以及术语。因为经理了解这些，就足以支持整个企业的编程工作。
沟通技能比技术专长更重要
没错，技术技能是很重要；要成为一名成功的经理，你对本部门从事的工作至少要有个头绪。但是如果考虑一下经理的系列技能，更多员工表示基本的沟通技能比精通技术可重要多了。
欧洲一家大型IT解决方案公司的测试经理皮特奈恩（Pete Nairn）发帖称：技术经理的首要职责就是能够管理人员；管理人员所需的技能就是良好的沟通技能。
提供C#开发和架构服务的Tom Jorgenson咨询公司软件架构师汤姆乔根森（Tom Jorgenson）补充说，充分信任那些下属的技术能力至关重要。他这样描述自己最欣赏的一位经理：他管理着软件架构师和甲骨文数据分析师共同组成的一个团队。他对软件架构师从事的工作所知甚少，所以他就说'去解决问题/设计/其他任何方面吧。让我面子有光啊。不必告诉我你是怎么解决的。'结果，这个团队非常成功。
具体来说，技术员工提到的优秀经理（而不仅仅是技术经理）具备的四大技能包括如下：
沟通。经理要具备会聆听的技能，以及与其他部门顺畅合作的能力。
信任/尊重。具体来说，技术经理必须尊重员工表现出来的技能，并且充分信任员工，相信他们会完成分配的任务。
设定及管理预期目标。帮助员工确定项目的优先级别；要是出现争夺资源的局面，通常还要有协调的本领。
支持。要为整个团队说话。在高层管理班子面前捍卫团队的利益，安排切合实际的项目最后期限，并争取获得必要的资源。
尽管这些技能看似相当简单，但身兼多种技能却很难得，员工对此很明白。我觉得自己是在寻找超级英雄般的经理。优秀的经理需要了解软件在本企业所发挥的作用，了解技术基础以便为我们的工作方向制定总体远景，还要能够与高层管理人员沟通。这个要求实在太高了。
刚上任的管理者如何带好团队
职业规划怎么写，相信很多朋友们对这个问题很感兴趣，下面给大家介绍一下。第一部分，前言即总论；第二部分，自我分析，包括业余爱好、性格、价值观、专业技能等；
不管是空降的还是新提拔的部门管理，在刚上任的时候都会面临一个问题，那就是如何带好这个团队。
刚上任的管理者如何带好团队
刚上任的管理者如何带好团队
成为团队的管理者和单个时候做业务是不一样的，身为管理者不是要你个人把事情做好就可以了，而是需要整个团队把业务做好，想要做好这些对一个新的管理者来说是一个很大的考验。管理人员想要带好团队，做好以下三点很关键。
1.消除员工的不信任
不管是空降队长还是自上而下的管理者，与一个团队合作的第一件事就是信任。从底层晋升的管理者看，员工会这样想：你以前和我们一样，能做到这种管理吗？？你怎么坐在这个位置？甚至有人会刻意不配合，为难新领导..空降兵的问题更大：你是新来的，我们为什么要领先？新手，你认识我们吗？他能控制我们吗？我们不会打开它，等等，毕竟，三个字：没有信任！
管理者要摆脱这种不信任的也不是没有办法，无论是做生意还是沟通。短期做生意那是不可能的，（经理）接手的第一个新的团队做的是与员工沟通。空降人员可能不会像老人们这支球队，通过沟通可以很快融入团队;从下往上的领导也要求员工消除障碍，不信任沟通，以全新的姿态开始了新的就业机会。
沟通是管理的第一步。沟通是管理者和普通员工之间的纽带。沟通对于消除员工对管理者的不信任至关重要。
2.使用实际业务来证明自己
不管是乱七八糟的还是好的铺位，新来的家伙都想要一个快速的立足点，这取决于他的业务能力。如果管理者能和一个团队做生意，无论你是新的还是老的，不管你的年龄，所有的问题都会消失。这是一个不仅是团队，而且老板也会依靠你，并将全力配合你的团队更好地运作的时代。
所以，你想究竟如何做生意？真的不好回答，毕竟不是小编的管理人才。不同的条件也不同的团队，管理者需要做的是不一样的。如何做生意是团队成员的老板和新任经理人怀疑新的管理者需要做的就是把这个问题消除。
3.谋求进一步的发展
有人说，如果现代社会不前进，那就是倒退。这是一个非常合理的说法，对管理者也是如此。当管理者从一个团队开始并取得一些成就时，并不意味着它就结束了。工作场所永不满足，企业的发展永不停息。如果你想在经理的职位上站稳脚跟，你需要不断进步，创造新的成就。
新中国成立后，伟大的领导人告诫同志们不要躺在旧书上，在新的征程上做出新的贡献。这句话适应了现代社会的每一个方面，对于刚刚取得一点进展的新经理人来说，需要记住。
程序物语：项目经理预成长
今天，根据自己的体会，我来谈谈项目经理的初始化阶段。
新人工作一段时间后，或长或短，可能一至两年后，有可能出任项目经理。此时，考验你能力的时候真正来临。项目分很多类，如基础研究项目，大型综合性项目。这里我们选取小的商业应用型项目为例。
刚开始，我们是没什么经验的，好在有热情。但这是项目，是一个讲究人与人之间配合的技巧性的活，光靠热情是难以持久的。退一步说，你是能力很强的聪慧之人，什么都拿得起放得下，那你充其量只是个精兵，而不是一个好的管理者。管理者的目标让整个组织的效率更高，管理者是没有那么多时间老是冲锋在前的，请深刻体会这一点。 因此我们得掌握一些基本的技术，讲究一些策略，力求避免未做勇士，先做烈士。
需要先补的课程是，项目的三要素：时间、成本、范围。
第一：时间
如果三峡项目做得很漂亮，质量很高，专家也很满意，惟一不足的是项目比预期推迟了两年半，那么这个项目的考评可能从A+会直降到C-甚至D-。因为这样一个大项目群，耽误一天便产生数以亿计的成本损耗。我们的项目虽然小，但道理是相通的。所以在执行项目之前。项目的时间至关重要。
客户有个时间表，老板有个预期的时间表，每个项目成员都有个时间表，作为项目经理，必须把这些协调起来，达成一个各方满意的结果、按照利益相关方的优先级别排序。这里有个分析的小技巧：请注意，老板说是下月底完工，你得有两手准备。一方面：alpha版一定要在下月上旬先给老板看下，给他一个初步印象，避免到时心里落差过大，情绪失控，万一有错，也来得及修正。另一方面，不要做得太细太完善，既浪费时间，又不给领导提意见的空间，领导只会怪你不会做事。于是，你得留一些简单的易于完成的小破绽给领导。是不是很委琐？！我相信这 样做，对项目组有利。当然，看具体的人，看性格。
第二：成本
项目花下去多少成本，预算时要心中有数。多大的西瓜多大的秤。这个成本包括时间成本、人力成本、费用成本等。在项目中间要勤计算挣值 。这是一个很关键的指标。投入与产出必须有一定的正相关系数关系。人有多大胆，地有多大产的教训在我身上太深刻了，记住，什么事都不要拍脑门，项目中没有任何板上钉钉的事，特别在公开会议上，要控制自己的情绪和言行。 有时候，一时不必要的斗气，让项目成员苦不堪言。
第三：范围
有了时间、成本的到位分析。范围就是一件简单的事了，简单的说，范围就是项目需要完成的程度。时间长、成本允许，可以内外兼修，各环节都做得漂亮，各方满意，自己也挺有成就。这是理想中的理想，基本上在实际中属于空想的范畴。所以，如何控制好范围，而又保持好项目成员的积极性，是一门学问，水很深哪！项目经理的一个基本观念是：项目是独立核算的，项目的考评是本项目完成到什么程度，而不是为了别的项目组或者为了下一次项目做了多少。如果这个项目可能为了别的项目组做出一些牺牲或额外努力，请尽量避免！如果必须得做，也需要在项目组 会议上言明，为自己项目组争取既得的回报，不一定非得物质的，比如领导的心知肚明，客户的理解和感激等，这些会帮你加分。千万不要偷偷摸摸的干，把项目成员的暗中努力不当回事，我是雷锋我怕谁已经不能用来唬人了，这是个讲究科学、兼顾效益的商业社会。
有人会问，在这三者冲突的情况下，如何取舍。建议很明确：先砍功能，也就是范围，把一些能推到项目二期的先往后推，向范围要时间。所以，在项目开始之前，要给项目孵出20%左右的可压缩时间，这个只有项目经理自己清楚，不必言明。
最不可取的就是项目经理挥刀自宫，让整个项目组在低成本下高速运行，这样的项目最后成败我们先不说，在项目成员的眼中，你基本上与黄世仁无异，甚至不用等到项目结束，就已经牺牲了。所以在第一次项目中一定不要让项目成员感觉跟你就是为了体验雪山草地，他们配合你，一是出于利益，二才是看你这个人值不值得跟。都看着你呢。所以，遇到不顺事先忍着，抓重点，回头再总结。这就是前文所说的做人、做事的原则：为什么级别的事情，就得付出什么级别的代价！
其实，第一次，不要将成败看的太重，教训要自己书写。有人说，哪怕只打一次仗，一个兵才会淬火成为真正的军人。谁没有第一次呢？做人，要经得起失败，但得明明白白地失败。
有人说 程序员的人生有三重境界。第一重、见山是山，见水是水。刚入门的程序员基本只能看到表面的东西，由于各种原因，没法了解更深入。第二重、见山不是山，见 水不是水。成长并有经验后，看到的表面现象渐渐有头脑中成型，犹如行军详细地图已经了然于胸。第三重、见山亦是山，见水亦是水。大悟之后，举重若轻，外松内紧，处事看似笨拙，实则暗藏玄机，惜语如金，然字字珠矶。此时，胸中亦有各种框图，然表面内敛以藏拙，见人说人话，见鬼与鬼语，谓之通灵也。
要想修炼到气定神闲的第三重境界，那就用心和智慧体验吧！
项目经理眼中的合格程序员
职业规划是对职业生涯乃至人生计划的过程，职业生涯规划的好坏可能将影响整个生命历程。感谢您阅读《项目经理眼中的合格程序员》内容，职场资讯网小编向您推荐一些职业规划知识，欢迎参考，希望能帮到你。
一、合作与团队精神及计划性
服从分配的工作，并在保证质量的前提下尽快完成任务。如果接到的新任务没有给出工作量估计，首先估计出完成任务所需要的工作量，并有责任向领导说明其估计的合理性，如果接到的新任务已经给出工作量，除非能提出充分的理由，否则必须接受该工作量估计。提前完成任务时，应该及时通知上级。在同时承担几个模块任务时应能根据优先级的变化及时调整自己的工作时间分配。
二、需求理解能力
在开发过程中，要在需求细节不明的情况下，有责任设法搞清楚，积极学习编程思想和方法，并在设计、编码工作中自觉应用，对有一些复杂程度的设计，主动申请设计审查。并能在开发用户界面之前，尽可能使用界面原型方法获取用户的确认。
三、测试意识
在工作负担允许的情况下，采用测试驱动的编码方式，及时把完成编码的部分提交测试，并及时排错。不断通过自己的测试来驱动程序质量的提升。
四、规范化，标准化的代码编写习惯
良好的文档是正规研发流程中非常重要的环节，作为代码程序员，25％的工作时间写技术文档是很正常的。缺乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇到极大的麻烦。
对正规的企业，会有完整的编码规定，代码的变量命名，代码内注释格式，甚至嵌套中行缩进的长度和函数间的空行数字都有明确规定，良好的编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。代码具有良好的可读性，是程序员基本的素质需求。
五、总结与全局观
以项目全局为重，采取尽可能简捷的解决方案，把完美方案的设想提交设计人员，有问题时首先向同事们征求解决办法，不鼓励花大量时间解决难题，并鼓励给同事提供技术支持。项目结束，做出个人小结，以利个人和集体的改进。
团队管理：怎样激励不同类型的人？
职业规划是对职业生涯乃至人生计划的过程，职业生涯规划的好坏可能将影响整个生命历程。感谢您阅读《团队管理：怎样激励不同类型的人？》内容，职场资讯网小编向您推荐一些职业规划知识，欢迎参考，希望能帮到你。
【导读】:每个人的差异性决定了其需要也不同，激励方式也应该因人而异。这里列举了十种针对不同类型员工的激励方式，不仅对管理有用，灵活运用于人际交往也会有很大收益。很多企业管理者都有这样的问题，如何让自己的员工和团队充满激情，有很高的生产效率？其实员工的激情和高效是企业不断成功的关键。尤其对一些创业企业而言，人少。一般而言，最成功的创业企业开始都是小型、敏捷，而且火力十足。
虽然老板都要找到聪明，充满活力，有创新精神的员工，但这是可遇而不可求的。而另一方面，要让员工永远保持激情不是容易的事情，尤其当他们在努力一段时间以后，却没有看到任何令他们满意的结果时，他们会产生倦怠。很多时候，老板们最容易想到的激励方法是金钱，但是让他们苦恼的时，有的时候，金钱的激励也常常失效。有些公司，如google，就是给员工每周有20%的工作时间去自我支配，这些时间内，google的员工完成了他们的梦想，而这些梦想的成果也极大地帮助了google产品的丰富，以及利润的提升。可以说，gmail，googleNews等都是来自这种激励的结果。畅销书作家DanielPink把google的这种激励模式叫做内在激励。
虽然内在激励的成功案例让我们兴奋不已，但是并不代表只有内在激励是最好的激励模式。很多人需要金钱，或需要职务，或需要奖励，或需要灵活时间等。每个人的差异性决定了每个人的需要也是不同的，也许激励方式也应该因人而异。以下是美国作者GeilBrowning根据不同的人，总结的10种不同的激励方式，这里我和大家进行分享。
1、分析型的人
他们希望了解这个项目是有价值的，他们的工作会最后的成功带来不同。他们需要一个在某些领域特别擅长的领导，他们相信这个领导的特长会使整个团队受益。他们更希望得到与他们的贡献相当的回报。如果他们独自做了大量工作，不要认为你奖励整个团队，他们会高兴。
2、天生架构型的人
他们想了解他们的工作帮助了公司进步。他们希望有一个做事有条不紊，有能力，对细节处理好的领导。用一种针对任务的特定方式，他们希望得到书面，或者及时的态度的回报。所以一封鼓励的邮件是和他们交流的方式。
3、人际型的人
他们希望感受到自己的价值，他们所作的对这个项目有影响。他们宁愿对哪些对他们能力表现出信心的领导多做事情。他们希望得到一个发自内心的个人性手势作为回报。如果你的个人喜好是书面交流，送一张亲手写的便条给这个特别的人际型的员工。
4、创新型的人
他们必须理解这个原因。对他们而言，一个宏伟蓝图比一个导向命令更有意义。他们喜欢一些非传统的，充满想象的事情作为回报。比如一个表达你敬意的古怪徽章就很有意义。
5、安静的员工
他们不需要大量的那种忽悠，但是他们喜欢私下的，一对一的鼓励。
6、喜欢表达的人
当这个项目被公开讨论，或者大家可以参与的时候，他们感觉更受激励。他们喜欢宏大的、正式的公共认可。
7、维护和平者
他们希望每个人都朝同一方向前进。他们从不要求回报和认知。所以这由你决定回报什么。
8、严厉的驱动者
他们是独立的思考者。如果他们与你意见一致，他们会被极大的激励。他们会让你知道，他们喜欢什么额外报酬。无论这是什么，他们希望立刻得到。
9、注意力在员工成员的人
他们必须对领导和项目有信心，否则他们的激励会很麻烦。他们想事先知道他们会得到何种回报。一定要使他们确信无论什么承诺，你都会坚持到底。
10、灵活的人
他们和团队相处很好。只要这个项目不和他们的道德和信仰相抵触，任何一种认同，他们都会非常高兴。
当然，除了正确的激励以外，作为领导者，还必须做到公平、公正。仔细观察你的团队成员之间的每种弱联系。如果你的团队中有一个懒人，他做的比别人少，却可以侥幸逃脱不受惩罚，那么这个人一定会对别人的激励有极大的削弱。也许这就是中国的古话，一颗老鼠屎坏了一窝粥。
软件业职位总结3 项目管理类[1]
每当公司接下一个单子，为了能够按时保质的完成合同的交付物，老板就会将这样重要的任务交给项目经理，这是一个要求综合素质的职位，既要懂技术又要懂管理还得性格适合。从这三方面我们逐一了解一下项目经理的工作。为什么会有项目经理这样的职位呢，很简单一个项目总得由一个人来计划调度实施，如果是个小公司那么项目经理就是老板，但是到了一定规模的软件公司老板哪有这么大的精力同时管理多个项目，所以他就将项目分配给合适的项目经理来负责。一般的来说老板要求项目经理确保项目顺利实施，保证客户满意，只有顺利实施客户满意公司才能拿到钱。这也是老板衡量项目经理工作能、水平高低的基本标志。再者老板会让项目经理报告整个项目的评估包括工作内容、工作量，人力安排分配，经费预算，项目总体规划，如何分阶段实施。看过项目经理的报告老板再加入自己的意见，再和其他部门，比如测试部，开发技术部，系统部项目的相关部门一起讨论这份报告项目，确定如何实施项目，最后由项目经理来综合管理这个项目。似乎在这里好像除了老板就是项目经理厉害了，其实不然。项目经理只是综合管理这个项目并不是老板有着绝对的控制权，他要从开发技术部、测试部等相关部门的职员中找到合适的人来成立项目组，要想组织起一个成功的项目组，这不是想象的那么简单，需要这么项目经理有适合的性格，一个脾气大有抠门的项目经理是组织不起来好的队伍，但是脾气好由大方的也不一定能，需要一个合适的性格。来管理那些属于不同部门的同事一起同甘共苦完成项目。既然队伍拉起来那就干吧，既然是这个项目组项目经理很多关键问题需要他来决策。项目经理要亲自决策的问题包括实施方案、总体技术方案、重大技术措施、奖惩、设备采购方案、资源调配、进度计划安排、合同及设计变更、接待客户等。 是她来决策干活的可能是架构师、测试部工程师、也可能就是他自己做的文档。在实施的过程中不断的监督进度，检查质量，修正方向，修改方案，和各部门扯皮最多的是系统部和测试部，向老板汇报，联系客户展示阶段成果和客户沟通，还得犒赏组员吃吃饭喝喝酒。最后按时按要求的交付。我们来看看项目组的成员，一般项目组都会有架构师，系统分析师，需求分析师，开发工程师，测试工程师，一半个系统部的人，QA，项目经理就是要哄着这些人好好努力工作，不惜加班，带病工作。
但这样人都不是好惹的，他们中有些人的级别比项目经理的级别高，薪水地位比他高，怎么能带好这支队伍，这就要求项目经理有个合适的性格。在别的行业项目经理可能不会遇到这样的问题，但是软件行业这是常有的事，甚至有的老板都不了解这个问题，随便招来一个自吹自擂的家伙就让他来负责，结果组员告状，消极怠工，项目失败或者不成功。可见项目经理要有好的EQ。其次还有具备项目管理知识，项目管理已经发展成一门的管理学科，它不仅仅要项目经理具备软件开发过程管理，熟悉CMM知识，还得具备较深的开发技术功底，不然要是一个笨蛋架构师提交了一份糟糕总体设计若是没有相关的知识不能及时纠正项目实施出现了问题再从头来。可见一个合格的项目经理要具备懂技术甚至是技术高手能够代领大家走出技术困境，发现错误还得懂管理运用科学的项目管理知识经验最后还得有个合适的性格。要介绍项目经理的工作和如何做一个好的项目是一个非常大课题，但是从讲座的目的我只想大家了解下项目经理的工作，如果有志在这个方向发展的朋友，我的建议就是项目管理是干出来的，不是学出来的不要以为去参加个软考拿个证书就能干这行，同样我早大一的第二学期就认识到我的本科专业管理工程不会让我在毕业时找到好工作，同理管理是干出来的，不是学出来的，所以我马上纠正了自己，通过考研究生换了专业。
软件业职位总结3 项目管理类[2]
高级项目经理
同他的名字，就是比项目经理更厉害的项目经理。有时高级项目经理是老板对跟随自己多年的老功臣的安慰，有时只是为了让薪水拉开距离，有时是只有高级项目经理去做大项目，也有的时候高级项目经理来管理项目经理，它是项目经理的老板。总之具体的工作还是那些只不过更高级了，就像有些人的职务前加个资深。我在公司做的就是高级架构师但是做的就是架构师的工作，给个高架的职位是老板对你安慰，而且他还不让你写代码，如果不做开发时间长了很多东西就会逐渐流失落后。
我们来说说项目管理类的职位会用到哪些工具，最基础的就是Word和Excel，不要小看这两样，他为项目管理提供了最基础的数据，每份统一了格式的文档，每份精心设计的Excel都是项目的重要成果，包括各个项目周报，个人周报等等。然后就是专门用于项目管理的软件如MS Project。软件生产是智力密集型的活动，其产品无物理外形，生产状态也不可见，因而难于检查和驾驭。如何管理项目的计划、调度、通信、费用估算、资源分配以及质量控制等。软件项目管理工具就是要使这种生产过程成为可见、可控的过程。使用它能帮助进行成本估算、作业调度和任务分配，并制定出成本较低、风险较小的项目开发计划；同时能设法在预计工期和经费之内适当调整项目的安排，以节省时间和人力，从而对软件生产的各个环节进行严格、科学的管理，使项目开发活动获得最佳的进程。 使用专业的项目管理工具不仅有效的帮助项目管理，而且它还能规范你的管理过程。
QA工程师
如果一个软件企业正在实施CMMI或者已经建立了研发管理体系都会在项目组中加入一名QA工程师。在我的工作经验中只有到达软件企业的公司，组织规模在300人以上，才可能去实施CMMI，就算去实施CMMI，最后也只不过是为了拿个CMMI的证书，QA工程师很多时候都是为了CMMI才存在的。不知道是咱们的软件公司不重视研发管理还是CMM和CMMI不适用于中国人。CMMI标准文件说，QA是高级经理的ears and eyes。研发人员眼中的QA往往也是警察，QA的作在于发现和报告项目的问题。一个合格的QA在项目中会充当三种角色：
角色1-老师，具备学习和培训的能力。
角色2-医生，通过度量数据对项目过程进行诊断，帮助分析原因，开处方。
角色3-警察，以企业流程为依据，但要告诉大家流程背后的原因；如果和项目组针对某些问题意见相左，可以直接汇报高层。
但在我的工作经验中却没有看到过这样的QA，虽然我的项目组也有为QA，但是主要为了实施CMMI而设置的，她是一位女性，不参与我们的讨论，只是默默地看着听着，然后回去写她的文档，只有在项目组研究去哪里吃饭庆祝阶段成果时就是看到她积极踊跃发言。
任鼎：把自己当成一个项目来管理
任鼎：各位同学、各位老师、各位嘉宾，大家上午好。我的名字叫任鼎，英文名字叫ding。目前我从事IT项目管理工作，今天我结合项目管理经验和职业发展的一些感悟给大家做一次分享，我分享的主题是：《把自己当成一个项目来管理》。
接下来我会给大家分享两个故事，第一个故事是关于我的目标和计划管理。第二个故事是讲述我如何在不到两年的时间里，从一名普通的工程师做到项目经理，再做到部门经理，也希望能给大家带来一些帮助。
首先给大家分享第一个故事，关于我是如何制定了自己第一个五年规划，也称我的“一五计划”。
这张照片是我大学毕业照，其中这个人就是我。2008年我毕业于安徽省一所普通的院校，本来我不想透露这个学校名称，但是我今天早上碰到了我的指导老师， 他说你一定要把学校名称说出来，我说为什么呢。他告诉我，你的学校名字叫淮北煤炭师范学院，这个学校的名字出现在任何人简历里面都是一个悲剧。他说你应该 拿着自己的不开心让大家开心一下，拿着你的悲剧让大家的学校成为喜剧。所以我也是把这个学校名字跟大家说了。
和很多同学一样，我职业规划的第一个阶段，也是一个来自于拍脑袋的梦想。大学毕业只有我满怀着梦想来到北京，当时的梦想就是拿高薪，去名企。至于去什么 企，拿多少薪，怎么去，不知道，总之就是要去。现实是残酷的，刚来北京以后，我一开始在一家小的公司做起了技术员的工作，每天的工作内容也就是接接电话、 处理一些电脑故障。虽然做的也不错，但一直没有什么激情，那个时候的我会经常问自己，我来北京的梦想是什么呢？总感觉离我的梦想越来越远，而我不知道怎么 抓住它。到09年初我参加一些职业规划的课程，系统学习了职业规划的一些理论和方法，通过大量的职业访谈，调查了一些我想去的行业和公司，也调查了一些我 想去的岗位，第一次真正意义上制定了我的第一个五年规划，我也相信在座的各位也上过古典老师职业规划的课程，也都制定过自己的五年计划，也就像这张图展示 的这样“yes，but”，我认为这是职业规划的第二个阶段，就是通过科学的方法制定清晰的职业目标，但是这并不是我想强调的，我想强调的是，如何把几张 纸的职业规划做成几摞纸的职业规划。这个图是我五年计划中的其中一年计划，共15本，包括我的年工作、年学习、年休闲等年计划，也包括每个月的月计划，其 中我把五年目标分解成年目标，把年目标分解成月目标，月目标分解成周目标和日目标，也就是说我把一个长期目标分解成明确的、可量化的、实际的、具有实现意 义的而且具有实现现实的目标。我认为这是清晰的并且是可操作的职业规划，这就是职业规划的第三个阶段。我想提醒大家，你要时时刻刻专注你的长期目标。这是 我的第一个故事，关于我的目标和计划管理。下面分享第二个故事，如何用不到两年的时间从一个普通工程师做到项目经理，再做到部门经理。
我是09年9月份进入我现在服务的这家公司，叫太极计算机股份有限公司，太极公司也是隶属于中国电子科技集团，是国内非常优秀的系统集成商之一，当时也是 为了能够进这家公司兴奋了很长一段时间。我入职太极公司以后第一个参与的项目就是民航气象中心业务系统技术服务项目，这是一个很悲催的项目。悲催的原因有 几点：第一，这个项目属于我们公司新业务拓展项目，没有统一的标准可供参考，也没有类似成功的经验。第二，这个项目这套系统是给民航局飞机起飞降落提供气 象预报的，需要24小时技术支持，所以我们得24小时待命。有时候我们领导也说，飞机不休息，我们就不休息。第三，这个项目需要我们项目组长期驻扎在民航 空管局，也是长期离开我们公司，缺乏归属感。这个项目组的成员也抱怨条件太辛苦，抱怨时运不济。当时我也想，搞了那么多访谈，最终弄这么破项目来做。但是 话又说回来，你积极主动的工作是工作，你天天抱怨着工作也是工作，为什么你不积极主动的去做呢？当时就凭着这个想法，我也就停止了抱怨，着手积极主动的想 解决问题的办法。也是在09年的9月份到10年1月份，这几个月时间里，我一方面借鉴公司传统强项系统集成项目的实施经验，另一方面通过访谈调研吸取一些 科技资助，甚至自己掏钱学习项目管理知识，到10年的1月份，我制定和总结提炼出了我们这个项目的执行规范、制度流程、标准等22篇文章和200余页的资 料。10年1月份，当时我们这个项目经理调任别的项目的时候，我顺理成章接过这个项目当起这个项目的项目经理，之后领导找我谈话，他说小任，知道为什么这 么快提拔你当项目经理吗？我当时想了想说，是因为我比较努力吧。领导说，努力是应该的，必须的，但是你用结果来说话，你现在做一名工程师，你已经作出了项 目经理该做的东西，甚至超过了项目经理的标准。不瞒你说，他们几个也找过我，如果你让我当项目经理，我怎么干怎么干，规划了半天的蓝图，你认为这两种情况 下我会选谁呢？不用你有道理吗？
这是我的第一个阶段，在民航从09年9月到10年1月，从工程师到项目经理。第二个阶段，在10年1月份到10年9月份，我当时所在的这个项目一切都按照 计划和步骤进行，非常游刃有余，当时我就想，得扩大我自己所管的项目才能体现出来我的价值。也是事逢部门业务扩张，这段时间里我也是凭借着在民航项目的成 功经验，不断的接受了类似于人民日报社信息管理系统、唐山钢铁、石家庄钢铁的技术服务，还有中煤能源集团等等，当时我是参与和管理了我们部门的大多数的项 目，我也是根据我管理的技术服务类项目的一些经验，制定和总结了技术服务类的项目执行标准、流程27篇文档模板、260余页，这也是10年9月份我被升任 为部门副经理。这是第二阶段。
第三阶段，10年的9月份到10年的5月份，在我当副经理的时候，我主导和发布了本部技术服务类的执行标准白皮书，10年5月我正式接任部门经理职务，带 领14人团队每年为公司提供近千万元的利润，曾经服务于新华社、人民日报社、国防部网站、中煤能源集团、中钢集团等等，包括中石油、中石化等国内大中型企 业。
之后大约在上个月的时候，我一个高中的同学，铁哥们，给我打了一个电话，他说听说你小子这两年混的不错，能给我们传授传授经验吗？当时我想，这没什么经验 可传授的，我是这么说的，我说在我做工程师的时候，我是按项目经理标准来要求自己的，结果没做半年成项目经理了，我做项目经理的时候，我按部门经理标准要 求自己，不到一年的时间我做到部门经理。当然，现在我是按总监的水平来要求自己的。我说完之后，电话里沉默了，我还以为这下把他震撼住了，谁知过了几秒 钟，电话里传来一个声音，你傻啊，为什么不按总裁的标准来要求自己呢！当然这是一个笑话了，我想给大家说的是，只有你不断超出公司的期望，公司给你的也会 超出你的期望。民航这个项目已经三年多了，也在不断的续签，这个项目给我的回馈一直到现在还在延续。这个项目也是10年入选本部最佳实践项目、最佳解决方 案项目，11年荣获我们集团公司荣誉项目，这个项目也是协助公司参加国际ISO2000技术标准认证，也协助公司参与工业与信息产业部运维服务的资质审评 定级。
最后我想跟大家分享的是，你制定了一个清晰可操作的目标，而且也在不断的超出自己的期望，但是你不一定马上就能得到回报，这个时候你剩下的就是用耐心和坚 持等到回报的到来。如果你的耐心和坚持只有一个小时的话，其实可以做一名合格的钟点工。如果你的耐心和坚持在一个月的话，你可以是一名白领。如果是一年的 话，你可以做一名职业经理人。如果是十年、二十年，你可以做一名投资家。三十年到五十年，你可以做一名教育家。三百年，你可以成为一名伟人。如果是三千 年，那么你就是像孔子一样的圣人了。各位，如果你们的人生是一个项目，那么你们怎么执行它呢？谢谢大家。
安利一波值得收藏的团队管理方式！
为了让团队有所成就，管理者不仅要了解自己的目标，还要针对目标，带领团队一起前进。衡量团队的成果——让团队的每一个人"言出必行"也是其中的一部分。让一个完美的想法变为现实，从来都不是容易的事情。今天小编安利大家团队管理方式，帮助大家创造一种有效的执行机制，希望会有事半功倍的效果。
一、团队的管理方式
级别一：考勤式管理
其特征如下：
1、不以结果为导向，一般泛指以强调形式的，机械的，忽略个体差异的军事化的管理方法。属于较为低级的管理方法。
2、对于员工层级较低，或主动性素质较差的团队，也许是最好的办法。如制造型企业一线员工。
3、员工形式化的责任很多，但是缺乏自我驱动式的责任感和主动意识。
4、以领导为核心。管家式领导总是担心下边的人不干活。首先将员工当成坏人（即如果不管，员工就偷懒）。
除非迫不得已，尽量避免这种“累死狗”的管理方法。
级别二：任务式管理
其特征如下：
1、以阶段性或局部性结果为导向，仍以领导为核心。
2、适用于创业型企业，单中心或项目制，扁平的组织结构。
3、员工掌握局部的或临时的情形，不能激发出最强的责任感和主动意识。
4、强势又很有才干的领导，管理“一竿子插到底”，直接过问产品细节，直接与一线员工和用户沟通；沟通决策效率快。
临时过渡性的管理模式，待团队梯度成熟之后，应进化为责任式管理。
级别三：责任式管理
其特征如下：
1、清晰的责任划分，以长期性或全局性的结果为导向，以员工为核心。
2、方便压力向下传递。能够激发出最强的责任感和主动意识。
3、适用于职务较高的层次，如中层管理以上。或门槛较高的协作团队，为主动性较强的精英型团队。
这是一种比较理想的管理方法，能够调动更大能量的团队工作。
二、怎么进行责任式管理
1、无论按专业责任划分，还是按项目责任划分，都要尽量清晰，无交叉且无盲区；责任划分需要有长期的稳定的规划预期。让责任人清楚自己较长稳定期限内的责任领域，这一点非常重要。哪件事出了问题，能够确定地找到唯一责任人。
2、由责任人做领域内长远的自我规划，以激发自我的主动性。
3、团队管理者不要朝令夕改，保持责任划分的长期稳定预期。
4、放松考勤式管理，以结果为导向。即使预知较差的结果，也不要提前干预，让子弹飞一会，静等结果的产生。用结果来驱动管理。
拒绝家长式管理，培养出职场的“巨婴”们!!!
从一名程序员过度到项目经理
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,技术不高怎么对付组里的牛人
我们经常会因为公司里的顶尖人才、个性化太强，不能与其他人合作而感到棘手，要解决这一问题其实也是有法可寻的。
一、在肯定其价值和优势的前提下，明确地制定改进的目标；
二、顶尖人才能够面对中肯的，明确及一对一的批评作正面反应，所以要加强与他沟通的力度；
三、可以根据具体情况调整考核目标，加强与其他员工合作的内容；
四、把顶尖人才调到相对能独立发挥其才能的岗位，减少与别人发生矛盾的机会。
项目经理能力成熟度与职业阶梯
感觉有些是企业环境因素，不是项目经理能力范围，以项目经理的实践经历来评估。但感觉有点抽象，没有深入探讨，与实际中应用对比起来。
1级：具备项目管理的一些基本知识，有一定的计划、控制意识，但还没有全面掌握PMBOK知识。
这一类人，在实际中较多，基本上靠自己的经验和意识在管理项目，对于系统学习项目管理体系知识还有些抗拒，认为过于理论化，实则是还没有意识到项目管理的重要性。典型的一种例子，在项目计划中，只注重开发任务，对于项目干系人的沟通计划、项目实施得不太关注。这类角色，实际还不太具备项目经理的能力，顶多是开发小组组长，但实际还是不少人担任项目经理，如果项目技术性较强，这类人可以担当，如果项目业务类较强，项目实施涉及较多干系人，则通常项目会搞得很糟。
2级：全面掌握项目管理知识领域知识，并能结合实际运用，有一定的沟通协作能力。
与第1级相比，2级的PM意识到项目管理的重要性，主动学习相关的知识，并在实践中应用。意识到沟通、计划的重要性。
已经可以单独承担6-12人月的项目。可以管理10人左右的项目团队。
3级：可以管理项目群，相当我们说的部门经理或者高级项目经理了。一般会管理几个项目的项目群。
与2级相比，这一类具有更好的沟通能力，以及教练指导能力、授权能力，以及团队建设能力。一般可以管理的团队规模在20-50人。
4级：可以管理一个团队规模在100人以上、项目规模几百人月以上的大型项目，也就是我们说的项目总监。
与3级相比，4级因为管理团队规模较大，会在市场战略分析、管理标准化和规范化（如开发过程体系、绩效考核体体系、人员培训计划）多下功夫，与公司高层、外部客户的沟通协作能力也很强。已经开始上升到高层管理角色了。
5级：应该是大型公司的GM、CTO级别了，不过这个层次的主要工作好象不是项目管理了，是企业管理了，一般已是公司总裁级别，或者是事业部负责人。严格意义上，这类角色已经是不是在管理项目，他们是在管理企业，我之所以列在这里，是从职业通道上，很多做到4级的项目总监，有希望再上一层，走到这一级。所以我将题目由项目经理的能力成熟度探讨扩展为项目经理的能力成熟度与职业阶梯探讨。
5年程序人生路 从新手到项目管理[2]
工作渐渐展开之后，就是平静如水的生活，每天上班，吃饭，睡觉，日子也过得很快。刚开始，由于懂得东西少，所以每次任务下来后，都是积极的去完成，因为害怕自己做不完。但是渐渐的，当自己清楚该怎么做的时候，人会产生疲倦，因为每天都做一些差不多的劳动。慢慢的，做事情就喜欢拖拉了。当分配一个任务后，自己先估量一下这个工作自己大概需要多久，一般老板给的时间会多很多。所以喜欢把工作先放着，去看看网页，逛逛论坛什么的，等到剩下的时间差不多了，需要开始工作了，就懒洋洋的进入工作状态，但是往往完成工作质量都不怎么好，很多提交后会有些BUG。不过我也没怎么在意。因为和老板关系好嘛，像我这样，再怎么说也属于元老级别的。就这样慢慢的工作了几年。因为小公司什么都要做，技术也积累了很多。包括各种主流数据库的用法，。NET，CSS,JAVASCRIPT,PHP,JAVA,perl,FLASH, 等等，其间，自己独立开发项目的时候，总想找出一种架构，加快自己下一个项目的开发进度。但是每次开发完后，发现上次设计的架构真垃圾。开发过很多项目，每次都想了一些新的架构方法。到现在沉淀下来的还值得用的架构思想也没多少。记得在做JSP的时候，感觉JSP里面服务端代码和HTML混在一起，很难看。不如。NET的事件驱动好用。就去写个模块，让JSP也实现事件驱动的模式。结果写到后来，也没得到什么好处，并且感觉有点不伦不类，后来项目慢慢做大了，才渐渐明白面向对象的用意。当一个项目很小，逻辑很简单的时候，用面向对象的方法设计用处不大，反倒是组件用处更大。因为项目小，基本上都是建几张表，改改HTML的工作。但是项目一大，逻辑变复杂了，如果你要理清楚逻辑，这里就需要一种方法论。我一开始写算法的那种方法有点不适用了。原来那种是从顶层开始，向下细分。是一种至上而下的设计方法。而面向对象不是，它是一种由点及面的设计方法。面向对象是先找出一个个对象点，然后再找出每个点之间的关系。在实际的项目中，你很难从上至下的设计。因为项目需求往往刚开始很不全面，很多项目后来改得都是面目全非。从上至下的设计不适合这种平凡的修改。并且当需求很大时，他涉及东西太多，你也很难从一个俯视的角度去全面的看这个系统。所以从上至下的设计不能满足要求。打个比方，记得一个项目已经做了80%，结果客户觉得用得不方便，要改一下。很多原来做的功能都不需要，并且提了几个新功能。但这几个功能也只是对原来的功能稍加改动。但是逻辑上看却是大相径庭。人脑不是电脑，如果想着这个代码，去改那个代码，势必到后来让自己也搞糊涂了。所以需要抽象出几个对象出来，是按照客户的思维方式。然后抽象出来的对象里面包含原来的功能。这样做起来就事半功倍。
在工作的磨练中，慢慢的发现了普通的程序员与优秀的程序员的一些差别：
1, 普通的程序员遇到问题喜欢张口就问别人，问之前没经过大脑想想。这是一个不好的习惯。其一，自己都没仔细想想，就算别人帮你把问题解决了，你自己不多久就会忘记。下次遇到，照样是不会。因为这个问题你没有经过大脑。其二，能够回答你问题的人，多半是有一定经验了。他们或许很会安排好自己的事情，管理好自己的时间。如果时常去打断他们，他们会觉得你很烦。
优秀的程序员多半会先到网上查找一下相关问题，看看网上有没有相关解决方法。经过一翻查找，他会把这个问题记得比较牢。
2，在一个项目的合作开发中，普通程序员往往只了解自己开发那方面的东西。项目做完后往往对整个项目有哪些功能都不太清楚。可能会有人抱怨，自己工作都做不完，哪有时间去了解整个系统。但现实多半是，花大量的时间去网上闲逛，却不愿花时间去增进知识。 如果总认为项目的设计是设计者的工作，自己没必要去了解。那么这样的程序员只能是手工劳动者。
优秀的程序员会对整个项目有认识，对一些自己感兴趣的功能会去做一下了解，更优秀一点的，会去对整个项目的架构设计做一下了解。自问如果他是项目设计者该怎么做？ 去学习项目设计的优秀之处，去发现设计的不足之处。触类旁通，把优秀的地方用在自己将来的工作当中。
3，普通程序员往往有很大的惰性。不能自觉的去学习知识，增进能力。所以每天耗费大量的时间在一些消遣状态中。所以时间往往白白的浪费掉。
优秀的程序员往往会安排好自己的工作和学习。在工作中学习，在学习中工作。能够感觉到自己每天都向着自己的目标在前进，状态佳，动力足。他们因为每天工作情绪很高，所以研究的东西也多，时间比较宝贵。因此他们会善于利用一些工具来操作自己的电脑，大大来的减少琐碎的电脑操作时间。更有胜者，会开发一些符合自己的操作习惯的小程序，来提高自己的效率。说不定这些小程序放到网上共享，可能还会有意想不到的收获。
我现在做项目管理，看着手下的程序员，时常也让我想起原来做程序员时候的坏毛病。比如，上班迟到啊，工作时间上网闲逛啊，交上来的程序BUG成堆啊！看到这些，我时常都是会心的笑笑，可以理解！ 不过我也时常提醒他们，如果你们想将来成为IT界的精英，而不是等到30岁感觉自己无路可走，那么请你们珍惜自己的时间。如果你们自己都不珍惜自己的时间，那么别人更不会去珍惜你的时间。
今天花了两个多小时，写了一篇短篇自叙。感觉值得，把自己五年多的光阴回顾了一遍。从前的故事历历在目。写下来过五年后再来回顾一下，说不定会是另一番感受。
关于项目管理的几个关键点，建议收藏！
做好一件工作和一件事情都需要一些技巧，那说到项目管理，技巧在哪里呢，下面小编手机分享几个关于项目管理的几个关键点，来帮助大家进行日后的工作。
1、明确目标，上下同欲
无论是团队还是个人，目标意识非常重要。对于团队来说，最清晰的目标就是什么时间最终交付什么成果，这个成果可以是一个产品的哪些功能，也可以是客户需求满足度达到多少等等。
总之这个目标一定要清晰，最好可衡量，当然，还要保证团队每个成员都清楚的知道自己做这项工作最终的目的是什么。只有这样，最终交付的结果才是有价值的。
此外，制定团队目标时还要注意一点：一定要跟公司整体目标保持步调一致。这里的步调一致是宏观对齐并非简单的目标拆解。例如，公司今年在产品上的核心目标是上线一个大版本，那么你的核心目标一定是与大版本上线相关的。
2、做好计划，井井有条
从一开始就对项目进行规划可以确保每个项目里程碑都在实际时间线上，一直到项目完成。每个人都知道谁负责项目的哪部分并且能够全面洞察正在进行中的工作和已经完成的工作。然后，协调并安排整个规划中的项目，确保能最大限度的利用你团队的时间。
3、依据项目目标和关键结果划分工作优先级
每个员工每天可能有几个不同的跨项目任务要完成。在这个时候，每项任务似乎都是重要而紧迫的。那么他们应该从哪里开始着手呢？他们应该把自己的大部分时间和精力放在哪里，以使他们的工作得到最大的好处？
当然，有些任务和项目是比其他的要重要一些的。这个时候如果有一套定义明确的目标以及工作如何取得成果的想法或许能帮助你如何判断这些任务及项目的优先级。
对那些与公司或部门目标一致的任务保持清晰的认知，有助于让每个人都保持在同一节奏并使每个团队成员都能做出影响大局的决策。所以，衡量目标的关键结果就是判断各项工作的优先级之一。
4、明确分工，责任到人
目标是从认知上建立统一，避免资源浪费。而在具体的执行过程中，项目负责人或者部门经理在分配任务时一定要明确每个人的分工，让每项任务都有唯一的负责人。
这里唯一的负责人并不是这件事自始至终都由一个人负责，而是让TA作为这件事的主导者去推动、协调工作，这样做能让每个人都有较强的责任意识。负责人对这项任务的最终结果负责，参与人配合负责人的工作，可以就某些方面提出意见。
5、高效沟通，提高信息透明度
项目执行过程中的沟通非常重要，主要是为了确保项目进度的信息透明和对称。如果A组已经做好某件事，需要B组做另外的事，如果没有沟通，B可能压根就不知道，这样项目进度就会延误。
一般来说，项目组会定期召开项目进度会，和项目成员同步进展情况，并再次确认各项任务的截止时间。但如果项目组有用到项目管理工具协作和沟通，信息比较公开透明的话，项目进度会就没有必要太过频繁。当然，和关键干系人的沟通还是必不可少的，可以定期核对项目进度。
6、进度管理，减少逾期
进度管理是项目管理中非常重要的因素。常见的项目进度表一般是甘特图。甘特图只一般包含工作事项、负责人、交付时间、时间跨度等几个关键点，可以清晰的展示整个项目的执行进度。在用甘特图做项目进度管理时有几点需要注意：
（1）培养团队的deadline意识
这似乎是一个简单的步骤，但它直接关系到整个项目是否能够正确完成。因此，在项目计划阶段，我们必须在项目进度上花足够的时间，在分解项目任务时，我们必须尽可能地精简，确保完成分工到人，设定截止时间，并确保任务能在截止时间前完成。
（2）优化工作流程
项目组成员间的工作流程，是通过邮件、Excel还是项目管理工具沟通，在项目启动会上一定要明确清楚。例如官网改版的项目，我们可以把工作流程分为【需求收集】-【原型设计】-【UI设计】-【WEB研发】-【网站上线】，每个流程由某位或多位负责，任务状态变更后，再进入到下一个流程。
（3）定期检查项目节点/里程碑
很多时候我们会同时负责多个项目，或是还有很多其他日常工作，如何保障项目正常运行，这需要我们时常检查项目节点/里程碑，及时发现项目中可能的风险。还拿官网改版项目举例，如果项目任务流转到UI设计了，但是设计组一直没完成，我们就需要尽快找相关负责人沟通。
项目中琐碎的事务如果怕忘记了，建议大家可以给自己建个循环任务，比方说每天检查官网改版项目，该任务就会循环提醒负责人。
7、总结复盘，经验复用
任何项目交付成果并不是最后一步，复盘才是最后一步。无论项目目标达成与否，最终交付结果如何，及时复盘总结能给团队和项目经理更多思考，这样也便于经验复用。
5年程序人生路 从新手到项目管理[1]
本人普通院校，非计算机专业本科毕业。从毕业到现在也工作有五年了。回忆起程序人生，也颇有一翻滋味。
本人是从大三上学期开始学习计算机的，因为那时电脑突然一下比较普及，本人家里也有能力买台电脑。买了电脑后，最先看的是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，当时对这个知道的很少，只能一边翻书，一边做事。要达到老板的要求，每天都八点左右才能搞完下班。
