程序员如何向项目经理估算工时

① 从程序员到项目经理（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）不紧急也不重要如果不是时间充裕的话，建议不要去做。如果碍于人情的话，建议安排或委托其他人来做。它们就像一群在几百米远处飞的苍蝇而已，你完全不必要放下手中的饭碗，举起苍蝇拍跑过去和它们决斗。因此，对于一个卓有成效的管理者，其优先级应该是这样的：第一象限=第二象限>>第四角限。第三象限就像数学中的无穷小一样，被舍弃了。写到这里，我想起了前不久一位项目经理的故事：项目定于当天上线，项目组决定搬到客户现场办公，以应付可能出现在的突发事件。项目成员电脑已经全部打包好，都围在项目经理周围等待。原来项目经理正在理一大堆发票准备报销，于是发生了这下面这样的对话：我：“大家都在等你，怎么还在填报销单呢？”项目经理：“今天是公司的报销日，不填好单子，又得推后很久。”我：“你的电脑打包了没有？”项目经理：“没有”我：“放行条开了没有？”项目经理：“没有”我：“申请用车了没有？”项目经理：“没有”我不知道说什么好了。要知道公司的报销单粘贴和填写非常严格，经常被打回重新弄，那一堆发票，显然不是十几分钟可以搞定的事情。还有公司的用车也比较紧张，不赶紧申请，说不定就没有了，到时就只能租车或打的，这无疑又会耽误更多的时间。更何况六七个同事都在等项目经理一个人，耽误的时间还得要乘以他们的人数。万一系统上线，状况频出，客户火烧眉毛，项目组却仍然在路上，这样的后果是很严重的。贴报销单看上去一件重要紧急的事情，实际上它既不重要也不紧急，因为今天不报销，以后还是可以报销，可是因此耽误的宝贵时间，却无法再要回来。

② 如何做好项目工作量估算——个人心得

在项目管理过程中，工作量的估算是一个重要的环节，他直接关系到项目的成功与失败，下面谈谈我对工作量估算的心得和体会：
工作量的估算方法有很多，如经验估算法，工作分解法，还有就是数学模型法等等，但在我们实际的项目管理过程中，许多着名的估算方法使用起来并不那么灵活、方便，并不一定适合于我们的实际项目。
我认为最简单有效的模型估算法是一元线性关系估算模型，比较适合于一般的小型项目，
工作量=规模 / 生产率+C
生产率借鉴历史项目的数据，C为一个常量，多数情况下为0。这个模型也有经验估算法的影子，他的生产率也需要根据以往的历史数据得出。
在实际项目中，我们应用最多的还是经验估算法。这需要产品经理提供完整详尽的PRD，项目经理对项目所服务的行业有比较深刻的理解，充分了解需求，分解需求，挖掘潜在的非功能性需求（性能，稳定性、可扩展性等），可以用xmind或者mindmanager列出项目所有的功能点，对每个功能点按照一般技术人员的水平逐一进行估算，一般以人/天为单位，在分配任务的时候，可以根据每个功能点所对应开发人员的技术水平将之前估算的标准工作量除以开发人员的生产率，得出该技术人员开发一个功能点所需要的工作量，这里就结合了前面提到的一元线性关系估算模型，其中的C就是对一些不可预测的工作量，如：项目进展过程中评审会议占据的时间，支付宝测试环境不稳定，第三方合作商配合不及时等等，都会影响我们的项目进度，所有整个项目进展过程中，我们要时刻识别风险，通过C的值来做一个调整，风险识别越明确，工时评估就更准确。
当然，项目经理不能仅仅关注编码阶段的工作量，还要和UED、DBA、测试部门以及合作方的负责人商定他们的工作量，完成整个项目的工作量估算之后，项目经理需要从中找出整个项目的关键路径，时刻关注关键路径的进展情况，因为关键路径会对整个项目的进度造成直接的影响。如果后期关键路径发生变化，要及时对整个项目的工作量做一些调整，并通知项目组的所有成员。
没有一个公式可以精确的估算工作量，经验法和模型法在实际中一般混合使用，以互相补充、互相印证。

③ 提高工时估计准确性

“如果一个程序员告诉你他已经完成了 90% 的工作量，那么他还需要同样的时间完成剩下的 10%。”
软件项目容易延期和跳票是屡见不鲜的事情，其中不乏知名项目。

刚毕业的时候，我在一家做系统集成的公司工作，我们定制了一套售票软件，为景区接入互联网售票方案。供应该软件的软件公司非常自信的说，这东西非常简单，最多 2 个月就能搞出来。这家公司小有名气，我老板对 2 个月交付深信不疑，于是张罗了接入的客户、市场的物料等。

不难猜到，最终还是没能逃过 90% 定律，2 个月交付的东西只能算作一个 Demo。于是花了另外一个月测试，修复问题和完善业务逻辑，又花了另外几个月时间响应对接客户的要求，才逐渐稳定下来。

行百里者半九十，软件开发也大体如此。开发者估不准工时常有，估准了才奇怪呢。

后来自己也做了软件工程师，参与 IT 项目开发，项目延期也是非常常见的事情。

IT 团队能准时交付是一项非常有价值的能力，哪怕交付时间长一点。计划两周交付，最后能准时完成，比承诺 一周时间，但是花了三周才交付重要得多。

越是大项目，越是重要。大项目的各个组件可能会发生相互依赖。如果不能准时交付，就会付出团队等待的成本，那可是真金白银。

做过项目管理的都知道甘特图，甘特图的每个泳道表达了项目各项资源的进展和计划。然而，软件项目不确定性非常多，存在各种突发事件。如果能提高准时按质量交付，各个单位的等待成本会小很多。

关键的是，衡量准时交付的关键是质量，其次才是交付。先给一个 demo，然后再慢慢改 bug。这种 “准时” 的交付，还不如有一个明确的延期时间，本质上还是 “猛糙快”。

谈项目工时估算，应该是在满足质量要求的前提下，否则估时没有意义。

那么能不能提高软件工程工时的估算的准确性呢？其实是可以的，刚到 ThoughtWorks 的时候，参与了一个交付项目。在一个项目开始前就计划了项目结束的时间，以及下一个项目的计划和安排。结果让我非常吃惊，那个项目的结束时间，和预期相差两周左右。并且这两周是逐步减少开发人员，最后只有 1-2 个人负责最后一周的交接期。

这就是专业软件团队和小作坊的差别，在专业项目经理带领下能把 3 个月的项目估算，精确到 20 - 30 个人天。能把项目工时估算到这种程度，体现了 PM 的内功。

在一个敏捷团队，需要把工时估准，不在于 “估” ， 而在于团队执行项目的稳定性。 一般来说，准确估算工时需要考虑需求分析程度、任务拆分的合理性、技术方案的可靠性、团队成员的能力、外部依赖和环境，如果这个项目不是新项目，还需要考虑遗留系统改造的成本和数据迁移的成本。

只有把需求分析做的非常彻底，才能保证估算的输入条件。非专业的业务分析师，只能看到需求冰山水面上的部分 —— 软件的特性、功能的复杂性等。

专业的业务分析师，不仅需要考虑功能需求，并对功能需求的逻辑性考虑完备。比如用户需要一个 APP，他实际上还需要一个后台，对应这个后台会有不同的用户、角色等。

根据这些业务输出、拆分出任务，敏捷开发中我们叫做用户故事，一个用户故事代表一个合理拆分的业务逻辑。能被评估工作量，然后根据这个工作量来评估工时。

除了这些功能需求之外，还有非功能需求。客户不仅仅需要一个 APP，还可能需要的是一个安全的、高性能的、国际化的 APP，而这些往往被客户当做默认选项。

一些性能优化的指标需要分析，并考虑性能优化的任务工时；安全需求可能有 HTTPS 配置，防病毒扫描等，都需要考虑；国际化也是额外的工作量。

挖掘用户真实需求的目的是定义怎么才算完成（Definition of Done），如果没人说得清楚满足什么条件这个项目才算完，那么估算工时根本无从谈起。

彻底挖掘客户的真实需求是评估项目工时的首要条件。

技术方案、团队能力和项目时间估算有很大关系。很多项目的时间估算都是由技术经理或者 Tech lead 来完成，往往是他们按照自己的经验和能力进行计算的。光是这样，很难算的准。

团队有多少人？对这套技术方案的熟悉程度如何？方案是否会发生较大的调整。人一多，人员水平差距就为工时估计带来了不确定性。经验多的人来做方案，如果是他做过的相似方案，自然会估的稍准一点。但大多数情况下没有这么理想的场景。

要做好工时估算，需要结合技术方案和团队成员能力，而不是自己能干多少活儿，多快干完来算。

一方面，技术负责人需要安排相应的技术预研，走在实际编码的开发人员前面，探探路，验证方案的可行性、实施难度、风险。就像作战的侦查人员一样，我们把预研叫做 spike。 spike 需要输出一些结论、demo，支持项目的时间估算。

另外一方面，考察团队真实运作效率很好的方式是根据迭代做工时统计。按照两周为例，10 个人的团队是 100 个工时。如果按照之前的估算，2 周内需要完成的 100 个工时的任务，实际上只完成了 50 个工时。也就是进度只有 50%。

我这个算法比较粗糙，敏捷项目管理中还有更准确的速率计算方式。通过速率，就能对下一阶段的工时估算做出调整，并在工作量、人员上做出调整。

通过方案预研和速率计算是提高项目工时估算准确率的良好方法。

我常常花了一下午时间完成了某个特性升级的编码，但是花了一个月的时间才完成了线上平滑升级、数据迁移。

真正有经验的工程师都知道，方案设计的难点往往不在设计一个新东西，而在于演进一个老系统。遗留系统演进是不可避免的，这种历史包袱是造成工时估算不准的一个重要因素。

遗留系统演进带来的估算困难来源下面几个方面：

不负责的猜想，有一些客户就是遗留系统演进不下去了，然后招标做新功能，实际意图是想乙方顺便消化重构的成本。总之基于遗留系统的二次开发都是一件困难的事情，能不接就不接吧。

另外，社会分工意味着一个人干不完所有的事情，IT 项目往往一个项目也不是独立的。大多数情况下需要和外部条件进行集成，这部分时间超出我们的掌控。

集成这件事的成本需要视主动集成还是被动集成来说：

集成充满了不确定性，估算工时时需要预留足够的集成空间，才能让工时估算更准确。

项目工时估算是一个系统性工作，基本上很难有一个万能的方法。因此大多数情况下都是玄学，但是毕竟是 “估” ，也不能要求 100% 精确。

软件工程的估时更具有弹性，相对供应链管理的交付时间估算成本更低。做好估时，对减少项目运行成本和风险有巨大意义，工时估算的准确性也往往体现了一个 IT 团队工程能力。

④ 从程序员到项目经理（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 利用碎片时间碎片时间并非不可利用，而是要安排合理的工作。几块大石头中间的缝隙，肯定塞不下另一块大石头，但放一些小石子或沙子还是没问题。

⑤ 程序员是做什么的

程序员一般的工作是从事程序开发、程序维护。

程序员是从事程序开发、程序维护的专业人员。一般将程序员分为程序设计人员和程序编码人员，软件从业人员分为初级程序员、中级程序员、高级程序员（现为软件设计师）、系统分析员，系统架构师，测试工程师六大类。具体工作职责如下：

1、负责软件项目的详细设计、编码和内部测试的组织实施，对小型软件项目兼任系统分析工作，完成分配项目的实施和技术支持工作。

2、协助项目经理和相关人员同客户进行沟通，保持良好的客户关系。

3、参与需求调研、项目可行性分析、技术可行性分析和需求分析。

4、熟悉并熟练掌握交付软件部开发的软件项目的相关软件技术。

5、负责向项目经理及时反馈软件开发中的情况，并根据实际情况提出改进建议。

6、参与软件开发和维护过程中重大技术问题的解决，参与软件首次安装调试、数据割接、用户培训和项目推广。

7、负责相关技术文档的拟订。

8、负责对业务领域内的技术发展动态。

(5)程序员如何向项目经理估算工时扩展阅读：

职业要求

一般的程序员都有四年的在专业领域的学习，需要一个在程序领域的学士学位获得者，不论是数学方面的还是工程方面的都是可以的。

大约有20%的人在这一领域的计算机科学和工程学拥有更高的学位。还有很小一部分程序员是自学的，尽管一些专业性的学校或者综合大学可以提供，但是也需要一些别的途径来提供相关的人才。

尽管学历是比较重要的，但是公司经常把重点放在应聘者的工作经验上，很多刚从大学毕业的大学生虽然有引人注目的学位证书，但是他们找不到工作是因为他们缺乏经验。

一个程序员虽然没有正规的学历，但是如果一个人拥有程序设计的深厚知识背景或者丰富的工作经验的话，那么他的机会要比有学历的应届毕业生大得多。

对于职业程序员，另外一个重要的方面就是，程序员需要不断提升自己的业务技术，他的技术必须一直保持在一个较高的水平，并且要不断发展，程序员也要寻找贸易的机会，要参加研讨会，在周刊上发表文章和接受职业教育，这些使程序员在自己的领域中分级或者不断并排前进。

⑥ 一个软件项目如何评估工作量和成本

软件开发成本估算过程可进一步细分为软件规模估算、工作量估算、成本估算和确定软件开发成本等四个过程。

其中成本估算需要对直接人力成本、间接人力成本、间接非人力成本及直接非人力成本分别进行估算。

国家标准《GB/T 36964-2018 软件工程 软件开发成本度量规范》中建议的软件开发成本估算基本流程如下图所示：

国家准中的四个估算过程，层层递进，逐步细化，最终达到科学、一致的成本估算。

一、软件规模估算

通常情况下，规模估算是软件成本估算过程的起点。

估算规模是后续计算软件项目的工作量、成本和进度的主要输入，是项目范围管理的关键，因此，在条件允许的情况下，应首先进行规模估算。

在规模估算过程中，需要注意以下情况：

1. 在规模估算开始前，应根据可行性研究报告或类似文档明确项目需求及系统边界。项目需求除包含最基本的业务需求外，还应进行初步的子系统/模块划分，并对每一子系统或模块的基本用户需求进行说明，以保证可以根据项目需求进行规模预估。

2. 依据项目特点和需求详细程度不同，通常估算人员在选择估算方法时应采用纳入国际标准的功能点方法进行功能规模估算，在适用IFPUG或NESMA方法时，可以根据需求的粒度和管理需要，选择预估功能点方法、估算功能点方法或者详细功能点方法。

3. 若当前的项目需求极其模糊或不确定，可不进行规模估算，而直接采用类比法或类推法估算工作量和成本。

二、工作量估算

在完成规模估算后，应当开展工作量估算工作，若当前项目未开展规模估算，也可直接启动工作量估算工作。

工作量估算时，可采用方程法、类比法、类推法、功能点法：

• 方程法：即基于基准数据建立参数模型，通过输入各项参数，确定估算值。

• 类比法：即将待估算项目的部分属性与类似的一组基准数据进行比对，进而确定估算值。

• 类推法：即将待估算项目的部分属性与高度类似的一个或几个已完成项目的数据进行比对，并进行适当调整后确定估算值。

• 功能点法：从用户视角出发，通过量化系统功能来度量软件的规模，这种度量主要基于系统的逻辑设计。功能点规模度量方法在国际上的应用已经比较广泛，并且已经取代代码行成为最主流的软件规模度量方法。

在开展工作量估算的过程中，需要注意以下情况：

1. 当需求极其模糊或不确定时，如果此时具有高度类似的历史项目，则可直接采用类推法，充分利用历史项目数据来粗略估算工作量。

2. 当需求极其模糊或不确定时，如果此时具有与本项目部分属性类似的一组基准数据，则可直接采用类比法，充分利用基准数据来粗略估算工作量。

3. 对于规模估算已经开展的项目，可采用方程法，通过输入各项参数，确定待估算项目的工作量。若客户或高层对项目的工期有明确的要求时，在采用方程法估算工作量时，工期要求有可能是方程的参数之一。

4. 为追求估算的准确性，建议在条件允许的情况下，可采用两种估算方法，对估算结果进行交叉验证，若估算结果差别不大，可直接使用两种估算结果的平均值或以某种估算结果为准，若差别较大，需进行差异分析。

5. 工作量的估算结果宜为一个范围而不是单一的值。

三、成本估算

在获得了工作量估算结果后，可采用科学的方法进行成本估算。

在成本估算过程中，应需要注意的情况：

1. 类比法和类推法，同样适用于需求极其模糊或不确定时的成本估算；

2. 间接成本是否与工作量估算结果相关取决于间接成本分摊计算方式。在绝大多数组织，项目周期越长，项目组成员越多，其分摊的间接成本就越高，此时项目的间接成本与工作量估算结果直接相关；

3. 直接非人力成本通常与工作量估算结果无关，宜单独分项测算；

4. 成本估算结果，也通常为一个范围，而不是单一的值。

四、确定软件开发成本

在《软件工程 软件开发成本度量规范》中，将软件开发成本分为四类，主要是为便于对成本构成（即哪些成本属于开发成本，哪些不属于开发成本）进行清晰界定。

而在实际确定软件开发成本时，通常并不是分别测定四类成本，加和后获得总成本，而是通常采用以下两种方式确定总成本：

• 根据人力成本费率及工作量估算直接人力成本和间接成本之和，再加上直接非人力成本，获得总成本；

• 根据规模综合单价和软件规模，测算出直接人力成本和间接成本之和，再加上直接非人力成本，获得总成本。

在进行软件的规模、工作量、成本估算时应遵循以下原则：

1. 在规模估算时,应根据项目特点和需求的详细程度选择合适的估算方法；

2. 充分利用基准数据,采用方程法、类比法或类推法,对工作量和成本进行估算；

3. 工作量和成本的估算结果宜为一个范围值；

4. 在进行成本估算时,如有明确的工期要求,应充分考虑工期对项目成本的影响,可以根据项目实际情况以及工期对项目的影响程度,对成本的估算结果进行调整；

5. 成本估算过程中宜采用不同的方法分别估算并进行交叉验证。如果不同方法的估算结果产生较大差异,可采用专家评审方法确定估算结果,也可使用较简单的加权平均方法；

6. 在软件项目的不同场景下(如预算、招投标、项目计划和变更管理等)采用国家标准时,相关要求见国家标准中附录A。

除了上述主要原则外，我们还需注意在使用基准数据时：

• 对于委托方和第三方，建议使用或参考软件行业基准数据进行估算。估算模型的调整因子的增减或取值有可能随着行业基准数据的变化而变化。

• 对于开发方，在引入行业基准数据的基础上，可逐步建立组织级基准数据库，以提高估算精度。组织级基准数据定义应与行业基准数据定义保持一致，以便于与行业基准数据进行比对分析，并持续提升组织能力。

⑦ 作为一个程序员，怎样处理好和项目经理之间的关系

良好的沟通是最关键的，这不仅是程序员和项目经理之间，更适用于所有的关系
他分配任务指标后。
1.首先要明确他的意思，最好和他重复一下，看看你有没有理解错，他不会因此烦的，因为如果你的理解偏差了做出来的东西有差距，到时反而更麻烦了。
2.在做的过程中，随时发现问题难以解决，或难以达到预期的目标要马上向他反映，让他明白你的难点帮助你解决或者让其他人帮助你。
3.明确项目进程，及你的工作完成时间表，随时反映你的工作进程，如觉得时间有困难，要提前沟通，因为项目经理会有一个整个的统筹安排，你的一个环节的滞后可能会导致整个项目的无法进行，事先通知就可以提前修改安排，不会导致项目的停顿，而且原因可以理解他不会怪你的。
希望可以帮到你，谢谢！

⑧ java程序员如何到项目经理

项目经理的职责

1.确保项目目标实现，保证业主满意 这一项基本职责是检查和衡量项目经理管理成败、水平高低的基本标志。

2.制定项目阶段性目标和项目总体控制计划 项目总目标一经确定，项目经理的职责之一就是将总目标分解，划分出主要工作内容和工作量，确定项目阶段性目标的实现标志如形象进度控制点等。

3.组织精干的项目管理班子 这是项目经理管好项目的基本条件，也是项目成功的组织保证。

4.及时决策 项目经理需亲自决策的问题包括实施方案、人事任免奖惩、重大技术措施、设备采购方案、资源调配、进度计划安排、合同及设计变更、索赔等。

5.履行合同义务，监督合同执行，处理合同变更 项目经理以合同当事人的身份，运用合同的法律约束手段，把项目各方统一到项目目标和合同条款上来。

作为程序员平时不仅单单只写程序和文档，要学管理的经验，项目的模块分割与人员分配，调节人员之间的合作里......总之要学的很多，最要的是有项目经验。

⑨ 如何做好项目成本管理

如何做好项目成本管控
在项目实施的过程中，成本管控起着非常重要的作用。随着市场竞争越来越激烈，价格逐渐透明，对企业来说要做到有竞争力，成本的管控尤为重要，因为它直接关系到项目的利润。成本项有人工费，材料费，一般费用等等，需要有个数字化的管理系统来进行科学的管理。
1. 存在的问题
以软件项目为例，我国大多数软件项目的参与人员为技术型人才，近年来随着大厂的推波助澜，薪资也是水涨船高。作为项目管理人员，一般也是从技术型转为管理岗，但是普遍的经济观念薄弱，将项目成本的管理归责于财务部门。财务部门缺少数据支持，无法做出客观的成本分摊。
另一方面，是缺少过程管理。我们项目开始的时候需要做预算，如果没有预算就没有参考的基线，而预估项目预算这个工作本身需要由项目经理来评估，项目经理需要根据参与人员的薪资水平，投入的预估工作日来核算出来预算。评估工时本身也是要有对类似工作量的历史工时来做参考，如果没有一个系统，项目经理只能凭借自己的感觉或者开发人员自己的主观评估，缺少客观数据支撑的情况下，作为管理层也没办法评判这个预算是多是少。预算做好了，项目推进过程中，对于人员工时的实际分配没有及时追踪，有的只是用Excel记录，对数据的真实性难以保证，并且缺少流程化管理。这些在企业想要做融资上市，进行第三方财务审计的时候，都是不符合要求的。

2. 解决方案
我们需要制定完善的成本管理制度，在项目开展前进行预算评估，以笔者参与的一些大中型项目经验来看，可以采取双向的评估方案。先由管理者从上往下进行约束性预算评估，即有最高管理者依据以往项目预算的情况来按照最小预算评估，再分配到各个部门或者环节分别给予预算值，再由各个部门或环节的负责人依照给予的预算值进行二次核对评估，如没有较大出入即可再次向下分配，一直到最小的团队单元。任何一个环节的评估超出上层分配的预算值，可依据实际情况反馈申请更多的预算。这样确定下来的才是相对准确合理的预算。对预算也要进行分批下拨，方便分阶段管控和调整。比如一个大项目可以拆分为一期二期或者按季度下拨。项目推进过程中，需要记录实际成本，包括人工成本和费用报销的成本，有的也需要将水电费房租等分摊到项目上。其中最复杂的是人工成本，它依赖于员工自己在各个项目上的工时投入情况。粗放一点的管理方法是由部门的负责人进行每日/每周统一填报分配，精细切实的管理方法是员工每日填报日报，将自己的一天工时分配到各个项目上，同时汇报相应时间的工作内容。审核的方法也有多种，视团队规模而定。一般30人以下的公司建议项目经理审核即可，100人左右的团队可以由部门负责人+项目经理两层审核，300人及以上的可以由分组负责人+项目经理+部门负责人三层审核，对于特殊部门也可以适当增减审核环节。
再好的管理制度和方法也必须结合软件来落地执行。我们用的是工时管家管理系统(https://www.ttkuaiban.com)，可以管理项目开展全过程，支持成本预算的管理，分季度/月度下拨预算，并能对人工成本进行实时管控。员工可以每天或者按周填报工时，审批支持多层级，每月可以出具项目成本报表，支持财务上的人员薪资分摊，非常方便，大大提高了管理者的工作效率。

⑩ 如何管理项目成本之－工时管理

工时管理第一步：工时录入与人工费率确定

首先，如何保证项目成员将工时填入系统中？很多企业，公司对项目成员的考核，往往以工作的努力程度来衡量。因此项目成员不想被把每天工作的时间透明化，否则他们就没有自由了（比如知道他出差一天就干了两小时活，公司经理该怎么想？）。同时，项目经理也不想填工时，因为不想把项目成本算得那么清楚，否则就要对成本负责。于是很多企业的项目管理中就没有成本的概念，只关注进度。这时候，企业如果强制要求项目组填工时，他们往往会多填，以显得工作努力，你看项目忙多啊。工时系统是管不了数据质量问题的，怎么办呢？想想，如果我们不但考核项目进度，还考核项目成本，项目经理就会让项目成员少填工时，以降低成本。这时候矛盾就产生了，项目经理希望少填工时，项目成员希望多填工时。这就是问题的本质，如何利用好这对矛盾，让项目经理与项目成员的矛盾达成一定平衡，工时录入问题就能解决，显然，学过博弈论或者有生活常识的人都知道，这个平衡的结果就是大家都说真话，填报真工时——问题的解决办法找到了，但是不是就这样加上一个成本考核就行了呢？没有基准的比较，考核是没有用的，因此还需要一个建立项目成本基准的过程。

变革往往需要和风细雨，企业要做好工时管理，找到了问题的根本点，也不能急于求成，要通过一定的变革，来改变人的习惯，建立项目绩效基准。比如应该先要求成员尽量将工时填到系统，并将填报工时的项目组，成立标杆进行一定的奖励，通过榜样的力量，使项目成员形成一定的习惯，逐步建立企业项目成本与进度的基准，然后，再请君入瓮，慢慢纳入考核，这样经过1－3年的调整，工时管理就基本上能做起来了。

其次，人员费率如何确定？很多人可能会直接把人员日平均或小时工资作为人工费率，从企业运作的角度而言，这是不正确的。打个比方，你招聘一名员工后，除了发工资外，你要对他进行培训，要给他配备办公设备，水电，电话费，办公场地，卫生费等等，这些都是企业的用人成本，也必须要分摊到人工费率，才是准确的。据调查，一个企业使用一名员工的平均成本是其工资水平的3－6倍，因此很多国际企业做法，就是参照一些行业的标准，把人员的平均工资乘以3－6倍，来作为人工费率。（当然不能行业差异较大，你可以通过参照同行业的水平，或者根据本企业财务来计算。如：人均工资＋公共费用分摊等）工时管理第二步：工时的利用

当一个公司真正把工时管理好以后，除了能比较准确的计算项目成本外，工时还具有其他非常重要的应用：

1、 建立员工能力基线

某一岗位的员工做某一任务花的时间多少，很多情况可以直接反映该岗位员工的能力，经过多个员工多个项目的统计分析后，企业就可以概要的分析出，做某一岗位员工的所需要的平均能力，我们称为能力基线，将能力基线与目前在岗员工的工作能力对比，如果发现该员工能力低于能力基线，企业就应该去分析，是其工作态度，还是工作安排的问题，就要采取相应的培训或者激励方式。如果发现某员工能力高于基线，企业可能需要去奖励该员工，让别的员工也产生更高的绩效等，因此能力基线是成为企业人力资源政策的重要依据。同时当能力基线建立后，项目计划的进度就可以比较准确的估算，一个企业当项目成本与进度都可以清楚的计算出来，项目管理与控制就显得容易，别且可以开展与同行业，甚至跨行业的基准比较。不断的提升员工能力，进而提升企业整体能力。

2、 建立企业资源管理依据

作为企业的高层经理或者人力资源总监，可能都经历过这样的事情：当一个职能经理或者项目经理，提出该部门或项目组人员不够，需要申请加人或者招聘员工，企业如何来判断是否真的需要？有什么依据？如果通过工时计算，我们就非常清楚了。比如一个部门现有员工10人，按照公司上班如每天工作8小时，有效工作时间加入为6个小时，每周上班5填，该部门每周总的有效工作时间至少为300小时.人。如果整个部门的统计工时少于300个小时.人，说明部门工作量还不饱满，就应该不需要招聘新人，而需要加强有效工作时间，比如减少非正常请假，减少员工闲聊的时间等，如果工时统计已经超过400小时.人了，说明部门为完成工作，已经在努力加班，超负荷运转了，这时候，企业可能就一定要考虑为该部门增加人员配置了。同时如果，经过统计发现某部门一年的有效工时远低于其部门的标准工时，说其部门员工工作量可能不饱和，对其部门经理要进行考核，该部门也可能需要裁员以降低成本了。这也避免了，每年职能经理为了争取多的人员配置，争得面红耳赤。

3、 EVM管理方式的实现

EVM在项目管理中是个非常好的概念，可以通过挣值将项目计划，成本，进度联系起来，非常直观的监控与预测项目现有及未来的成本是否超支，进度是否延迟等，但很多企业做不起来，因为没有其中挣值，计划值，实际值无法计算。如果，工时管理做好后，员工能力基线制定出来，每个任务的计划值，挣值，实际值就很容易计算，EVM管理方式就能建立起来。很多时候，企业在评价项目绩效，决定给项目经理或团队进行奖励时，因为项目的差异，很多指标难以直接比较，而找不到比较的标准。但EVM跟项目类型的关系不大，可以在项目之间进行横向比较。因此，EVM的建立，使在企业内，甚至行业间的跨项目绩效比较机制可以建立起来，项目绩效的好外可以直接放映出企业项目管理能力的差异，为公司项目管理能力提升，流程绩效改进提供依据，这一切，工时管理公不可没。

4、 工序管理与BPO成为可能

所谓工序就是为了完成某一工作的一个个步骤或相互关联的任务，工序连接起来，我们可以称为流程或者工作流。当我们建立每个员工的工时，并通过任务的对应，我们就知道该任务的工时，将任务整合到一定的维度，就得到工序的工时。有了工序工时，我们就可以通过分析工序的工时，来判断我们整个流程环节的瓶颈，并通过改善瓶颈而提高流程的效率。对于一个企业而言，其效率的高低，处决于整个流程的系统效率，而不是单个节点的效率。很多企业在面对效率低下的时候，往往无法判断问题出在哪儿。如果有工序工时管理，问题可能就简单得多。

另外通过工序管理，我们能发现哪些工序在企业的成本是比较高的，并且是企业的非核心竞争力的流程。而这些流程可以通过外包给擅长于该方面的第三方，通过直接获取第三方的专业服务，企业不但可以提高效率，降低成本，更可以专注于其核心竞争力的发展。这就是现代流行的业务流程外包BPO（Bvusiness Process Outsourcing）的概念。在《世界是平的》这本书里就介绍到，每个企业都应该利用全球的资源，专注于自己擅长的领域，通过BPO的方式获得更快速的发展，但问题是：现代很多企业，根本不知道哪些流程是自己不擅长的，而不敢外包，导致企业的高成本运作，如果能将工序管理做好，这个问题就变动容易解决，企业就可以在自己的核心竞争力领域集中精力创造更高的价值。