⑴ 从程序员到项目经理（12）：如何管理自己的时间（上）
项目经理必须要主动的管理自己的时间，合理安排自己的工作，才能真正“翻身”做自己时间主人。1.谁动了我的时间时间对于每个人而言，都是最稀缺的资源，对于一个管理者更是如此，时间不够用成为几乎所有管理者共同的问题。如果要对项目经理常说的话做一个调查的话，想信“我很忙”一定可以名列前茅。以我的经验，当要求项目经理按时提交项目材料，或者临时支援某件紧急事务的时候，经常会听到同样的回答：“我很忙”。多年以前，我就从经理那里听说，厉害的管理者都是很轻松的，因为他的工作全部交出去了，根本不用自己操心，所以他们出去度假十天半个月，一切工作都会如常进行。从那时起，我就充满了对管理的神往，可是后来我才发现原来这只是个传说，现实中忙忙碌碌的经理比比皆是，而轻松自如的管理者则是众里难寻。为什么管理者都这么忙呢？是谁动了他们的时间？实际上，这是一个综合性的问题，既有内部原因，也有外部原因，既有主观原因，也有客观原因。总的来说，让经理们不堪重负的因素有三：(1)工作对于一个程序员来说，他的工作是比较单纯的，基本上是单线程运作，只需要项目经理交待开发任务即可，可是当上了项目经理就不一样了。以前好比在游泳池中游泳，现在是在大海里冲浪，各种事情如潮水一般向你涌来，让你顾此失彼，手足无措。(2)下属下属也是一种资源，即人力资源，这种资源与时间一样，同样具有稀缺性。其实我们可以设想一下极端情况，如果你的下属人数足够，能力也很强的话，你完全可以像我的经理说的一样，把你的全部工作授权给你的下属，你自己也就不用整天焦头烂额了。因为你的下属不给力，所以你总是要自己来制定计划、自己来做系统架构、自己来监控进度、自己来检查质量、自己来写文档、自己来汇报工作、自己来解决重要问题、甚至自己来编写代码，你整天忙忙碌碌，就是在忙这样的事情。然而，千万不要怪你的下属，因为他们不给力正是老板雇佣你的原因，况且资源的稀缺性是永远存在的——从原始社会到将来的共产主义社会。要知道，老板做项目为了赚钱，而不是让管理者更轻松，如果每个项目都是精兵强将，你只要一声令下工作就会自动完成，你倒是轻松了，但老板还要你来做什么？(3)自己既然资源受限是一定的，项目经理还是应该反求诸己，从自己身上找到解决之道。这就好比天下雨了，你怪老天是没有用的，只能怪你自己没有带雨伞。经常问一问自己，我对工作安排合理吗？我抓住了主要问题吗？我在旁枝末节的事情上浪费时间了吗？我有充分发挥下属的能力吗？我自己工作拖拖拉拉吗？…通过不断的自省，改善自己的管理方法和行为习惯，我们对时间利用也必然会变得越来越高效。 2.时间管理的本质是对工作的梳理要破解忙的难题，必须要有意识的对时间进行管理。其实时间本身是没法管理的，因为无论你怎样管理，时间既不会变多，也不会变少，既不会变快，也不会变慢。所谓的时间管理，其实就是如何更有效的利用时间的问题，更加直白地说，其本质就是工作管理，即通过对工作的梳理，让我们在有限的时间内，使得工作更有条理、更有成效。必须要主动、有目标地对工作进行梳理，这是对一个管理者的基本要求。工作梳理就好比整理房间，你不去整理它，杂物就会堆积得越来越多，你房子最终会变得不适合人类居住。一个好的家庭主妇，必定善于将各位物品分门别类，并且适时扔掉一些用处不大的物品。一个好的项目经理也一样，同样需要对工作进行分类，对不同类型工作采用不同的策略，有些工作要现在就做，有些可以晚点做，或者不做；有些工作一定要自己做，有些工作则可以请其他人来完成。通常对工作梳理，可以采用5W1H法，即： Why——为什么干这件事？（目的）； What——什么事情？（对象）； Where——在什么地方执行？（地点）； When——什么时间执行？什么时间完成？（时间）； Who——由谁执行？（人员）； How——怎样执行？采取哪些有效措施？（方法）。在一般的项目中，Why和where往往不是什么问题，或者说对项目经理的时间管理影响较小，因此我们不妨将其简化为3W1H，也就是确定要做什么，不做什么；先做什么，后做什么；谁来做；怎样做才更有效。基于此，项目经理可以按以下三个步骤来梳理工作：（1）分析要做什么、不做什么，以及先做什么、后做什么解决What和When的问题。事有轻重缓急，事情的重要程度和紧急程序直接决定其处理的优先级。虽然很多事情来势汹汹，但并不表示一定要当即处理，有些事情只是静静的躺在那儿，也并不意味着要“等有了时间再做”。（2）分析由谁来做解决Who的问题。虽然我们提倡项目经理要以身作则、亲力亲为，但并不是说每件事项目经理要亲自去做。对于下属可以胜任的事情，就把它分配出去。如果出现项目经理很忙、下属很闲的情况，那就说明项目经理你做得太多了，不要和你的下属抢事情做。（3） 如何让工作更有成效做不做、什么时候做以及谁来做的问题都解决了，剩下就要解决怎么做才能让工作更有成效的问题了。在这里我们不是要讨论编码或写文档的技巧，而是个人的习惯和认识，这对工作成效的影响更是本质上的。 3.做事要分轻重缓急老外就是善于总结，中国有词语叫“轻重缓急”，可是到了国外摇身一变，变成了“时间管理四象限法”——自从美国总统艾森豪威尔提出以来，人人将其奉为圭臬，成为时间管理领域最重要的方法论。所谓的“四象限法”，就是将工作按照重要程度和紧急程度两个维度进行分类。我们找一张白纸，以紧急程度为纵轴，以重要程序为横轴，在纸上划上一个十字，将纸面分为四个象限，然后将当前所有要做的工作放到这个四个象限中。一个典型的项目经理四象限图如下所示： （1） 第一象限：重要紧急这一类往往是火烧眉毛的事情，需要马上去处理，否则项目会受到重大影响，比如客户服务器崩溃。（2） 第二象限：重要不紧急这类事情一般是预防型的工作，例如制定项目计划、团队建设等，它们不需要你停下手上的工作马上去做，但如果没做好的话，可能就会导致产生项目危机。许多第一象限工作产生的原因，正是因为第二象限的工作没有去做。（3）第三象限：不紧急也不重要这类事情看上去最不需要做了，例如上网偷菜、看新闻、写博客等，但如果你在办公室走上一圈，就会发现很多人正在干着这些不需要干的事情。 （4） 第四象限：紧急不重要这类事情虽然不重要，却需要马上去处理。一个典型的例子就是桌上的电话响了，你接还是不接？当然要接，因为你不知道是谁。接通后，发现是推销保险的，你又不好意思立即挂掉，只好被对方折磨一番了。 我们到底该怎样安排四个象限的工作呢？对于一个普通的管理者，其工作的优先级一般是这样的：第一象限>第四象限>第二角限>第三象限。可是，等做完了第一、四象限的工作，根本就没有时间来人做第二象限的工作，于是项目到了后期项目经理只好四处救火。管理大师彼德.德鲁克十分推崇“时间管理四象限法”，并将其总结为“要事第一”的原则。根据这个原则，每个象限的工作处理策略是不一样的。（1）重要紧急优先级最高，需要尽快处理。很多人都玩过《植物大战僵尸》的游戏吧，那你一定知道“一大波僵尸正在逼近”的感觉，是的，你必须要马上打死它们，不然它们就会冲进你的房子，吃掉你的大脑！（2）重要不紧急这类事情看上去可以暂缓，但考虑到其重要性，应当与第一象限的工作并行去做。如果不及时去做，它们就会转移到让你头疼的第一象限中去，或者在第一象限产生更多新的“僵尸”。所以，要在僵尸还没有逼近的时候，就好防御工事，并尽快打死它们，如果等到它们冲了过来，你还能不能保住大脑，就要看你的运气了。（3）紧急不重要它们就像是在你耳边“嗡嗡嗡”地叫着的苍蝇，你必须要花时间去赶走它们。这多少让人有些无奈，但这些事情确实层出不穷。有些公司在实施紧急项目时，经常采用封闭式开发，这样做的一个重要原因就是要回避那些紧急不重要的事情。很多管理专家建议我们在必要的时候勇敢说“不”，其实就是针对这类事情。如果实在无法说不，建议安排或委托其他人来做。（4）不紧急也不重要如果不是时间充裕的话，建议不要去做。如果碍于人情的话，建议安排或委托其他人来做。它们就像一群在几百米远处飞的苍蝇而已，你完全不必要放下手中的饭碗，举起苍蝇拍跑过去和它们决斗。因此，对于一个卓有成效的管理者，其优先级应该是这样的：第一象限=第二象限>>第四角限。第三象限就像数学中的无穷小一样，被舍弃了。写到这里，我想起了前不久一位项目经理的故事：项目定于当天上线，项目组决定搬到客户现场办公，以应付可能出现在的突发事件。项目成员电脑已经全部打包好，都围在项目经理周围等待。原来项目经理正在理一大堆发票准备报销，于是发生了这下面这样的对话：我：“大家都在等你，怎么还在填报销单呢？”项目经理：“今天是公司的报销日，不填好单子，又得推后很久。”我：“你的电脑打包了没有？”项目经理：“没有”我：“放行条开了没有？”项目经理：“没有”我：“申请用车了没有？”项目经理：“没有”我不知道说什么好了。要知道公司的报销单粘贴和填写非常严格，经常被打回重新弄，那一堆发票，显然不是十几分钟可以搞定的事情。还有公司的用车也比较紧张，不赶紧申请，说不定就没有了，到时就只能租车或打的，这无疑又会耽误更多的时间。更何况六七个同事都在等项目经理一个人，耽误的时间还得要乘以他们的人数。万一系统上线，状况频出，客户火烧眉毛，项目组却仍然在路上，这样的后果是很严重的。贴报销单看上去一件重要紧急的事情，实际上它既不重要也不紧急，因为今天不报销，以后还是可以报销，可是因此耽误的宝贵时间，却无法再要回来。
⑵ 当程序员变成软件项目经理怎么办
当你预期的那一天，也许是害怕的那一天，终于来到了：从工程师的队伍里你被提拔到了软件项目领导或者团队领导的位置。这也许就是你选择的职业道路，或许你不太情愿，将就尝试一下。无论在哪种情况下，你都可能缺少工程学科、人员管理以及领导能力的相关教育。 这需要更多的领导能力和管理（它们不是一回事），而不能象Dilbert（译注：着名IT漫画主角）那样简单地和老板对抗了。当你考虑新的目标时，请考虑下面的活动计划列表。一次就抓住了每个亮点，这是不可能的。但是这份建议说明可以帮助你将注意力放在可以提高你和你的团队绩效的活动上。 建立优先级 作为经理，首先要做的、最重要的事是你需要有意识地建立优先级。当你仍陷于繁重的软件开发活动中时，你需要一套新的职责。过多的经理新手不能抗拒技术的吸引而陷于此类活动，这将导致项目组的其他人员想要获得经理的帮助时，却得不到帮助。 有成效的领导知道他们首要的任务是为其他组员提供服务。这些服务包括训练和指导、解决问题和冲突、提供资源、建立项目目标和优先级、提供适当的技术指引。要使每个组员都能清楚的知道，你总是可以帮助他们。我发现将自己定位于为被我监督的人工作是非常有意义的，而不是相反的。在你所作的事情中，对于组员要求你帮助他们这件事，应该具有非屏蔽中断的优先级。 第二重要的，是使你的客户满意。作为一名经理，没有直接的能力使客户满意，因为你已不再是作为个人提供产品和服务完成这点。相反，你必须建立一种环境，准许你的组员最大程度上满足客户的需求。经理提供了强有力的方法，有效地提高客户的满意度。 第三重要的，是为你的项目工作。因为也许还有其他许多技术上的项目，或者其他经理的请求帮助，诸如为指导委员会工作。当这些和二个高级别的发生冲突时，都要准备推辞掉。 很明显，使其他经理满意的事情是你最不重要的事情。在一个有秩序的组织里，如果你在三个以上的重大环节上获得了成功，其他的经理都会很激动的。我们并不都能很幸运地工作在一个良好的环境里，但一定要对你任务单上排在最前面的工作任务努力尽到最大的责任。集中精力有效地、快乐地、尽可能地帮助你的组员，不要将精力放在使你上司满意的上面。 分析你的技能差距 除非你已经为新位置做好了准备，否则相对于你当前的领导能力和管理技能，你会感到一些差距。出色的技术背景或许是你被选为领导角色的一个因素，但是你要想干得出色，你需要更多的技能。针对别人的评论和项目，真实地列出你的长处和短处，然后减少差距。 软件人员并不以令人满意的人际关系技能出名。你会希望增强处理人际关系的经验：解决冲突、说服以及灌输想法。你也不得不处理包括招聘、解雇、商谈计划表，以及在你的办公室里评论某人业绩使其伤心落泪等一些事务。 我发现从一堂倾听技能课开始我的管理职业是非常好的。当作为个体提议人，积极地将我们自己的技术议程提交小组时，我们经常对此感到非常惬意。有效的管理要求更多的合作和善于接受的人际关系方式。要花点时间学习如何（何时）巧妙地引导自己的自然判断。倾听技能课提供了一种交流机制，我已经发现在许多场合下都很有用。 接着，到讲台的另一侧，提高你的演讲能力。如果你真的不适应公开场合的讲话，学习戴尔．卡内基的课会有帮助的。你会发觉，通过这样的培训获得的经验，以及获得提高的交流能力，都可以帮助你更好地适应将来的工作。 作为项目领导，为了计划和跟踪项目，以及当需要项目回退而采取修正措施时，你有责任调整其他人的工作。参加项目管理的培训课，阅读一些有关项目和风险管理的书籍和文章。参加项目管理学会，阅读其月刊--PMNetwork。SEI的软件能力成熟度模型对于软件项目计划和项目跟踪提供了很多有用的建议。建立优先级的能力、控制有效果的会议、清晰的交流，对于你，作为一名经理的绩效将会有实质上的影响。 定义“质量” 几乎每个人都会认真地对待质量问题而且都希望生产出高质量的产品。然而，对于软件的质量含义，没有一个统一的定义。传统上的软件质量观点和“足够好”的软件观点有着激烈的争论。为了帮助小组走向成功，需要花一些时间和你的组员、客户共同探讨质量的含义。 这两种阵营在思想上经常不会有相同的定义，可以很容易的就不同目的开展工作。关注交付计划的经理对于想正常地检查每行代码的工程师会不耐烦的；认为可靠性非常重要的客户对一个带有很少使用但带有很多bugs的特性的产品是不会满意的；一个很好的GUI也许会让用户厌烦，因为用户已经熟记了如何有效地使用前一个版本的产品。 为了更好的理解客户对软件质量的看法，在Kodak，我的小组曾经邀请了我们的客户和他们的经理就这个议题在一个开放的论坛展开讨论。这个论坛是很有意义的，那些使用我们产品的人有着自己的理解，通过讨论，我们可以知道我们制定质量的思路有哪些和他们是不相符的。明白了不同，就可以使你集中精力，照顾客户的最大利益，而不是使开发人员获得最大满意。 软件质量的传统描述包括要与说明书一致，满足客户的需求，代码和文档没有缺陷。“六个∑质量”（six-sigmaquality）这个流行词，建立了一个非常高的尺度，用于监测失败的频率和密度。但它不适用于如快速产品交付，可用性，充足的特性集，已支付价钱的交付意义这样的质量尺度，。对于我们生产和购买的产品，我们总是热衷于尽可能涵盖所有的这些质量特性，然而，妥协总是必须的。 在一个项目的需求阶段，我们制定了包括十项质量属性的一个列表，如效率，协同性，正确性以及宜于学习，我们认为这对于用户来说是最重要的。我们请客户关键人物代表小组以1到5的尺度评估每项属性。一旦我们决定了哪些属性是最重要的，我们就可以设计并实现这些目标。如果你在了解了对于客户的质量含义并在设计实现质量属性的过程中没有麻烦的话，而且客户对质量属性表示满意，那你是很幸运的。 在众多关注的质量说明中，我曾听到过一个：“客户回来了，但产品没有”。和你的客户、开发人员一起对每一个产品都确定适当的质量目标。一旦决定了，就给出达到质量目标的明确的最高优先级。以身作则，按很高的质量标准要求你自己的工作。采用这个座右铭：“力求尽善尽美，满足于优秀。” 表彰成绩 对你组员成绩的表彰和奖励，是激励他们的一种很重要的手段。除非你的小组中已经有了一种表彰程序，否则这应是你最重要的事情之一。表彰包括象征性的东西（证书，旅游奖励）以及实际的东西（电影票，餐馆礼品券，兑现奖）。在送赠品时要说一些亲切的话语：“感谢你所给予的帮助”或者“祝贺取得了成绩”。在表彰和奖励上花费很少的心思和钱，就可以获得很多的友好和将来的合作。包括客户代表，以及为项目成功做出过贡献的支持人员等等开发组外的人员也可以获得表彰。 和你的组员讨论，了解他们感兴趣的表彰和奖励的方式。使得无论大小成就的表彰活动成为小组文化的一个标准组成部分。对每位组员对其所作的工作表现出发自内心的兴趣也要给与含蓄的表扬，为消除所有影响他们战斗力的障碍尽你的力量。表彰是展示组员以及小组外的其他人的一种方式――你要知道并感谢他们为小组成功所作的贡献。 学习过去 你的小组在过去承担的一些项目有可能没有取得完全的成功。甚至在成功的项目上，我们也能经常认为一些事情我们下次会作得更好。当你进入了新的领导角色，需要花点时间了解早期的项目为什么失败，并要计划避免犯同样的错误。对于软件开发，每位经理花时间处理每种可能要发生的错误是非常困难的，学习过去的成功和失败就是个成功的开始。 可以从过去你们小组承担的一个没有经过检查评估的项目着手，不要管其成功还是失败，实施项目后的回顾（有时称作事后调查分析）。你的目标不是判定责任，而是为了在将来项目中作得更好。借此，可以了解什么已经作得很好，什么应该作得更好。在当前每个项目的主要里程碑时，通过集体讨论或公平的组织者，用同样的方式，领导小组用头脑风暴的方式对其展开分析。 另外，要了解领悟已有的软件工业的最佳准则。一个好的起点是SteveMcConnell的JoltAward获奖作品：快速开发（RapidDevelopment，MicrosoftPress，1996）的第三部分，叙述了27个最佳准则。也要避免McConnell叙述的36个常见的软件开发错误。你的组员也许反对新的工作方式，但是你的角色是作为一名领导，要确保团队一致连续地使用最佳可用的方法、过程和工具。积极促进组员之间的信息共享，这样局部单个最好的实践经验就能成为每个开发人员的工具箱的一部分。 建立改进目标 一旦你对过去的项目建立起了回顾，确立了质量对小组的意义，你就要建立短期以及长期改进的一些目标。目标要尽可能量化，所以你要划分几个简单的阶段，标明你是否采取了适当的过程朝着目标前进。 例如，如果你认定由于需求的不稳定导致项目经常延期，你可以建立一个改进需求稳定的目标，在6个月内提高50%。这样一个目标需要你确切知道每周或每月需求的变化数，清楚他们的出处，采取行动控制那些变更。这可能要求你要改变与那些提交需求改变的人的交流方式。 你的目标和阶段是软件过程改进程序的组成部分，你要使之有序。作为缺乏创造力的官僚主义的最后避难所，轻视“过程”很流行。虽然事实上，每个小组都能找到改进其工作的方式。当然，如果你总是用已有的工作方式工作，你也就不要期望你会得到比以前更好的结果。 有两个强烈的原因要求改进过程：校正问题，防止问题。确保你的改进努力要围绕着已知的或可预知的可能威胁项目成功的问题。领导你的小组找出当前正在使用的方法的长处和短处，以及项目面临的风险。 我的小组召开了一次“两段式头脑风暴”练习，来确定改进软件生产力和质量过程的绊脚石。在第一次会议中，参会者在便条上写出他们关于会议主题的想法，一个便条一个想法。组织者将他们写在便条上的想法收集上来并分组。最后，我们就会得到一打主要的分类，并将其记录到活动挂图上。 第二次会议，相同的参会者在便笺上写出解决这些障碍的思路，并贴在挂图的合适位置。进一步细化，归纳出一些详细的活动，就可以成为我们努力的一部分，清除障碍，帮助组员实现软件的质量和生产力的目标。 建立可度量和可达到的目标，便于你集中精力实现改进。要使目标具有明显的优先级，并可周期性地监视过程。记住你的目的是，提高你的项目和公司完成的技术和业务上成功，不要满足于一些过程改进书籍里提到的期望细节。要把改进的工作视为迷你项目，具有可分发、资源、计划和有责任的小项目。否则，过程改进活动将总处于比诱人的技术工作低的优先级上。 缓慢的开始 这篇文章提供了许多建议，帮助你，一位软件经理新人，带领你的小组走向伟大的成功。在日复一日新的工作压力面前，要努力保持你的头脑清醒。在长时间的塑造软件开发小组的文化和习惯上，你还是个非常重要的角色。你不必一次性都作完，可以选择跟环境最相关的的几个开始。 作为软件经理，除了项目要按时按照预算完成外，你要担负的责任还很多。你还要：领导技术人员，将他们形成一个具有凝聚力的团队；建立协同团队工作的环境；鼓励和奖赏高级软件工程师的实践应用；平衡来自客户、公司，组员和你自己的需求。 这是项重大的任务，祝你好运。
⑶ 程序员怎样培养自己成为项目开发经理
项目开发经理?老古怪的头衔。我知到有开发组经理。项目经理。项目开发经理是不是只是负责某个项目的开发负责人?
程序员和开发经理的区别是，一个是控制项目质量，进度，分配工作的。一个是埋头苦写的。两个侧重点不一样。背负的责任也不一样。不要以为套上个经理头衔就是成功了。
我觉得在你为成为开发经理目标努力的过程中，你先要弄清楚，自己公司里各个部门的分工，包括你所说的项目开发经理有怎么样的工作智能。再看看自己缺什么技能。你就知道自己怎么努力了。
一般来说，开发经理需要严密的思维，和较强的协调能力。
⑷ 如何从程序员做到项目经理
经验决定一切。。有任务能合理安排，对整个项目流程熟悉，有技术问题能解决，这一切的一切都需要经验积累。。这些经验书上是没有的，楼主做程序做到一定年龄，就行了
⑸ 程序员转项目经理
能不能，是能力的问题。这是不关键，因为只要有意愿，能力是可以培养的。程序员连复杂得让人琢磨不透的软件都能搞定，还有什么搞不定的？
因此最后落实在需不需要这个问题上。这个问题很棘手，需要从程序员自身以及外部环境等方面进行分析。要讨论这个问题，就要弄清楚它和想不想的关系。想和需要是紧密相关的，但并不是一回事。想不想，主是感情的因素，而需不需要则要进行理智的分析的了。理智与感情，并不总是一致的。有些东西，是你需要的，但你未必想要。比如，被困沙漠的时候，有时被逼喝自己的尿液，这是理智战胜了感情。电影《色戒》中的汤唯，则是感情战胜了理智，爱上了敌人，最后造成了悲剧的结局。因此，我们还是少说气话了，不要冲动，冷静的分析自己的处境吧。
⑹ 如何从程序员转行成一个成功的项目经理
你的为人处事，你的关系，这是一个复杂的问题，但首要的是你的技术能技压群芳吗？
⑺ 从程序员到项目经理要学习哪些东西
吃苦
能抗
技术
交际
机遇
赏识
时间
⑻ 从程序员到项目经理（13）：如何管理自己的时间（下）麻烦告诉我
项目经理必须要主动的管理自己的时间，合理安排自己的工作，才能真正“翻身”做自己时间主人。4.管理者无需事必躬亲有一种类型的管理者，他们不论什么事一定要亲自去做，至少也是亲自过问。人们习惯用一个成语来赞美他们，叫“事必躬亲”，仿佛诸葛亮再世一般。凡事亲自去做未必真的可取，为什么诸葛亮只活了53岁，恐怕跟他这种事必躬亲的精神也有莫大的关系吧——他是把自己累死的。（1）不要和下属抢事做管理者相对于操作层员工，多了一项法宝，就是授权。理论上，只要员工可以胜任，所有的工作都可以授权。事实上，总经理为什么能对全公司发号施令、对工作进行变革，那是因为董事会授予了这个权限。连这么高层的工作都可以授权，一个项目里面的工作还有什么不可以授权的呢？因此，当你疲惫不堪的时候，就应该问问自己，我是不是管得太多了？如果一件事情下属能做，就应该让下属去做，不然等于是你抢了下属的工作。项目经理最可悲的事情就是，自己累得半死，项目组成员却闲得发慌。管理者必须学会授权。授权不只是为项目经理分担工作，也是项目培养下属成长的必要方法。如果项目经理总觉得下属能力行，不给他分配具的挑战性的工作，这显然不利于下属的能力成长，从长远看，对项目、对公司也是有百害而无一利。（2）授权绝不是简单的把工作交出去授权两个字说起来简单，但做起来效果却会因为而异。有效的授权必须把握以下几个要点：l 目标明确：要做什么内容、达到什么质量要求、什么时候完成等等，必须要清晰具体。管理学家们认为目标必须要SMART（S=Specific、M=Measurable、A=Attainable、R=Realistic、T=Time-based），这是很有道理的。l 跟踪反馈：项目经理应当经常性对任务完成情况进行检查，这是很多项目经理非常欠缺的一个重要环节。只授权不检查，最后的情况可能就是进度大大延迟，或者与你想要的东西大相径庭，下属进行种种解释，但为时已晚。l 能力辅导：项目经理要对下属的能力有比较准确的把握，安排工作也应该在其力所能及的范围。如果跳一跳能够得着，就比较理想，但项目经理仍然需要主动辅导，加强监控，当发现偏差时，应及时采取应对措施。如果工作大大超出其能力范围，再怎么跳也够不着，项目经理就要另想高招了。（3）不做甩手掌柜是不是任何事情都可以授权呢？理论上是可以，但由于资源的稀缺性，这种条件往往并不具备。至于什么可以授权，什么不可以，这要因项目而异，根据项目工作与资源的实际情况，两厢权衡之后才能决定。不管怎么说，授权不可过度，否则项目经理就成了甩手掌柜，实际也等于放弃对项目的控制权。项目经理应该做的工作：l 系统性工作由项目经理做，比如制定计划、安排任务、鼓舞士气、项目检查等，具体事务由下属去做。l 重要的事情项目经理来做，紧急的事情让下属去做。l 决策由项目经理来做，执行由下属去做。l 下属能做的事由下属去做，否则由项目经理自己做或带着做。 5.好习惯让工作更有成效高尔基曾这样来描述时间：“世界上最快而又最慢，最长而又最短，最平凡而又最珍贵，最易被忽视而又最令人后悔的就是时间。”的确，时间是快还是慢，是长还是短，不在于钟表是的指针转了多少圈，而是在于在我们如何使用时间。一个人的习惯，对如何利用时间具有至关重要的作用。（1）尽力避免返工项目中最浪费时间的事情是什么？是返工！一旦发生返工，不但所耗时间将会成倍增加，而且会大大降低员工的成就感，打击员工士气，降低员工作效率，使得项目时间进一步滞后。我见过一个城市三维模型制作的项目，经过一年多的辛苦工作，终于提交成果了，但是由于客户认为模型不够漂亮，最后几十平方公里的模型全部重做！项目组员工身心俱疲，公司遭受严重损失，客户也非常不满，一个三输的结局。返工并不总是这样严重，其实在一般的软件项目中，返工现象也是大量存在的，只不过我们借着迭代的名义将其掩盖了。例如软件试运行后，客户要求将某项业务流程中的两个环节进行整合，或者将某个环节中的输入信息，转移下一个环节中。单个修改的工作量也许并不算大，但累积起来就相当可观了。很多项目在试运行后要修改几个月，甚至半年以上，这就是返工的代价。迭代设计还是返工之间，并没有明确的界限。要区分二者，有两条标准：一是迭代是计划之中的完善，而返工则是计划之外、迫不得已而为之的事情；二是在工作量的层面，如果抛弃或被重做的功能工作量很大，那只能认为是返工，如果你非要认为这是设计就是要这样干的，那我只好给它取个新名字：“返工式迭代”。这也这给我们一个启发，做系统原型的时候，千万不要写大量的代码，否则的话，迭代最后会变成返工。（2）打破帕金森定律的魔咒英国学者帕金森通过多年的调查研究，发现一个规律：“工作会自动地膨胀占满所有可用的时间。”一个人可以在十分钟内看完一份报纸，也可以看半天；一个程序员开发一个功能，可以两小时完成，也可能花上一周的时间；项目经理制定计划，可以半天完成，也可能一个月还不见影子......总之，只要还有时间，工作就会不停的扩展。帕金森定律就像一个魔咒一个样，困扰着很多人。它之所以起作用，表面上原因在于时间充裕，外部压力太小。因赖床而上班迟到的人常有，但因赖床而误飞机的则很少，因为误机的后果很严重。因此，有必要对每件工作确定一个时间期限——dead line，一过这条线dead！给下属安排工作时，这的确是一个好办法，但对于管理者而言，约束别人容易，约束自己则很困难。即使工作到期，还可以告诉自己，再推迟几天也没关系，这件事情还可以让某某来完成，即使到了dead line还可以说这件事其实不重要，少做一点没关系。图帕金森定律的魔咒归根到底，还是在于我们的内心力量不够强大，面对一点点的外部阻力，就变得消极懒散，不能自我驱动。截止日期是靠不住的，要靠只能靠自己，养成良好的习惯，主动给自己压力和动力，战胜心中的“懒惰小人”，才能真正解除这个“帕金森魔咒”。（3）合理利用时间每个人都希望工作不被打扰，但作为一个管理者，你的时间不是自己的，你的上级和你的下属都有权来随时打扰你。你坐在那里，就会有人过来找你签字，找你谈工资，找你讨论技术问题，找你支援其他工作……每天的时间就这样被打成了无数的碎片，所以经理们常不由自主的感慨：“白天真的做不了事，只能晚上和周末才能工作”——加班才能做事，你说经理能不累吗？的确，项目经理很多工作都需要大块时间，比如制定计划、编写文档、分析风险、关键技术实现等，都需要较长时间的思考。一个人要让心静下来，进入工作状态是时间的，一旦被打断，再次进入这种状态会花很多时间。这就好比炒菜，把锅烧热是需要时间的，你刚放下油，来了电话，等你接完电话，锅又冷了。时间碎片的问题对管理者而言是不可避免的，但可以采取方法更加合理的利用时间，将其影响降到最低。l 制定规则例如约定在指定的时间签单、讨论技术问题、反馈进展等，而不是随时进行。l 琐碎事情一起做对于工作中的琐碎问题，不用急着处理，可以启动“碎片整理程序”，将其记录下来，在你不需要“炒菜”的时候一起处理。l 利用碎片时间碎片时间并非不可利用，而是要安排合理的工作。几块大石头中间的缝隙，肯定塞不下另一块大石头，但放一些小石子或沙子还是没问题。
⑼ 程序员如何成为一名合格的项目经理
千万不要在进行需求分析阶段就先进行编码工作，也许你觉得这些模块和具体的业务功能无关，可以直接进入编码阶段，但是你要知道，在这个阶段进行编码工作会使你忽视了对需求的理解和分析，而且并不见得你现在完成的代码模块百分之百适合未来的业务系统，万一有偏差，那就是得不偿失了，在需求分析和系统设计上多花一点时间，会为以后的工作减少很多麻烦。所以在项目管理过程中，我认为最为保险的办法就是严格按照软件开发流程规范来开展工作，虽然这样会相对比较繁琐，但是在很大程度上保证了我们项目的成功率。
有经验的项目经理都说自己是打杂的，所以，你要明白你不再是一个coder，项目组中大大小小的事情都要你去处理，你需要学会主动和小组成员加强沟通，从工作和生活等各个方面加以关心和帮助，这样会使团队气氛更加融洽，提升团队成员对你的信任度，在很大程度上能缓解大家的工作压力，我们倡导的是快乐工作，而不只是为了工作而在一起工作。不要认为自己和团队的成员只是工作关系，同时，他们也是你的朋友。如果你是一位性格内向的项目经理，那么，你应该让自己开朗点，不要因为自己的性格而让整个团队变得很沉闷，那样大家工作起来会感觉非常痛苦。
作为项目的管理者，你不仅仅是被人领导，而是还有一个团队需要你去带领，当他们请教你的时候，你有责任和义务去帮助他们解决，或者给他们指定找谁解决，而不应该因为自己不会而一走了之。同时要学会培养团队中的成员，放开手，大胆的让他们去做，不要认为教他们完成任务还不如自己亲自动来得快，那样你只能做一名程序员，而且越做越累，要知道，还有更多更重要的事情等着你去做。
我建议每一两天应该组织项目组成员开一次讨论会，否则，项目组成员之间谁也不知道谁在做写什么功能。和大家谈谈项目的进展，了解下大家目前遇到的困难和工作进展，适当调整项目组成员之间的工作分配。而不是在项目前期安排了任务后，后期的工作任务不根据项目的实际情况进行调整，等到项目后期时，大家同时抛出很多问题，这样会让你束手无策，一片混乱。所以要及时举行项目讨论会，学会灵活得安排工作任务，没有谁规定一个项目的所有工作任务只能安排一次。
其实作为基层的管理者，要管理好团队相对还是比较简单的，我认为只要和同事之间的关系处理得足够融洽，就意味着你的管理已经成功了一大半了，都说做人比做事重要，相信这一点没错的，但是管理走向更高的层次，就需要你学习一些比较专业的管理学方面的知识了，这段时间在看《从技术能手到管理高手》这本书，我觉得非常适合从程序员逐步转向管理的朋友阅读，但不能照搬书上的条例，要结合自己的实际工作环境，消化吸收之后，再用于实践才是最好的。前段时间CSDN上一位牛人阿朱出了一本书叫做《走出软件作坊》，我只是看了书中的目录和部分内容，从同行的评价来看，我想这本书应该是值得一读的，哈哈。
⑽ 做开发做了2年多 如何成为项目经理呢
呵呵，从我的经历来给你一点启发吧，不敢说一定奏效，但是希望能有所帮助：
1、单纯做开发时只要做好本职工作就OK了，不需要考虑团队里面各个人员的契合；成为项目经理后，这些事情是在开发之前就已经定好了的，项目的进度时间表，责任分配表，数据库设计表，详细设计文档，风险评估等等，这些都是需要项目经理妥善安排的；
2、做项目经理需要深刻一点理解老板心中的产品是什么样子的，这就比单纯做程序员跟老板的交流多一些，期间有很多要注意的地方，必经是跟老板在交流，这种事情没什么可说的，平时多留意总结经验即可；
3、做了项目经理了，当然要多多关心一下“兄弟们”了，一句话，除了常规工作外，你还需要调节你的上下级之间的关系，呵呵，这种事情比较麻烦，当然，这种事情比较稀少，一般不会遇到！
4、再有就是往大了说了，培养团队意识，作交流时要起到引导作用，目的是让大家增加默契，有利于协作。
就说这些吧，希望能给你帮助哦！