从项目管理的角度

从管理的观点来说，尽量赶上计划的发表时间，尽快完成项目是理所当然的。 但是，受多方面因素的影响，项目管理是一个速度不快的过程。 如果这个计划的发表日早于这个实际合理的发表日，追上这个不合理的日期，工期内积累的问题就会越多，在后期结束时爆发，结果可能赶不上合理的发表日期。 如果借用中的一句话，脚会变得太大，容易拉蛋。 为项目组设置合理可见的小目标，逐步露营，逐步向合理的小目标前进，积累小目标，最终可以走向项目的成功。务实项目经理必须认识到：1 .项目组能够以快节奏进行，但项目经理本身一定认识清楚，我们加紧计划发布日期，但项目组的实际目标应该是其客观存在的合理发布时间。2 .随着项目的推进，其客观存在的合理发布时间逐渐明朗。 与预定公开时间的不同也逐渐明朗起来。 此时，项目经理通常希望通过添加资源来缩短此合理的发布时间。 但是，真正的情况是，除非你前期的资源配置不合理，否则在这种情况下添加资源对项目没有什么帮助。3 .项目经理必须有一些主张。 领导和业务部门常常压力重重，要求赶紧计划发布时间，同时要求采取某种办法赶上计划发布时间。 在现实情况下，如果能调整需求范围，还有戏。 否则，此时传达喜讯，后期传达忧虑，此时传达忧虑，后期不要担心。 隐瞒问题常常是愉快的，但并不是说问题不存在。4 .项目经理实际上是5点钟a .控制了需求b .尽快发现问题，报告和解决问题c .资源不会处于空闲状态d .利用各自的资源做出得意的事情，迅速有效地推进各种任务e .需要不浪费资源，做对整个项目目标没有用的工作，或者在后期被推翻。基于这种认识，本文提出#项目责任感项目经理必须有这种责任感。 对这个项目的任何事情都要负责。 因为这影响了整个项目的工期，对整个工期负责。例如，我们发现当前项目存在紧急问题。 项目组以外的人需要解决。 于是我发了邮件，通知了Wendy尽快处理这件事。几天过去了，Wendy还没有处理。 我想我已经谈过问题了。 我想接下来是关于Wendy的。那个问题还没有解决，我的整个工期都受了影响。之后追究的话，我发邮件的是Wendy没能马上处理。温迪说，我有那么多事情，为什么知道这么匆忙。项目工期受影响的是谁的责任Wendy？ 不，是我自己。作为对整个项目负责的项目经理，没有人比你更关心项目的进展。 让没有具体责任的人推动你的项目远比你自己有意的推动有效。#项目经理杂乱无章项目组的各位专家，他们有擅长的领域，他们擅长的事情是他们的幸福。 不是他们擅长的事情，对他们来说也是杂事。项目经理必须有以下意识：项目经理很杂项，帮助项目组成员处理杂项并专注于他们擅长的事情，对于项目组来说很有效率。在简单示例中，测试人员Tracy在测试某个功能时突然发现需要一个帐户，启动该帐户的特定权限并要求服务器信息，如主机名、存储特定功能文件夹的路径等。 但是，她不知道这个账户和权限是向谁开设的，这些服务器的信息是谁有的。Tracy是个喜欢做测试的人，但她不喜欢和项目组外的人说话，特别是要去其他部门找人。 这些对她来说很琐碎，而且她对其他部门的人也不熟悉，一个一个的问题明显效率不高。你可以自己找到她需要的信息。 另外，也可以找一个熟悉这方面的人来解决，但绝对不能自己做。“为什么我的部下不能解决这么简单的问题？ 如果想让你帮忙做到这种程度的话，这个项目经理是做什么的呢？她成了项目经理。 “这种想法并不令人满意。你成为这个项目经理的目的不是管理人，而是让这个人做什么。 你的目标只是迅速推进和完成项目。控制要求在所有因素中，需求对项目的影响至少占50%以上。 在控制需求的同时，项目成功了一半。 要管理需求，请执行以下操作1 .要确保有人能成为一个好的产品经理在项目组中，实际上每个人都可以影响需求。 但是，管理需求的是产品经理这个职场。 如果你的项目组里有一个好的产品经理，那就恭喜你了。 项目经理很容易。 但是，世界并没有那么幸运。 因为在现实生活中并非所有的产品经理都这么出色。 作为负责项目完成的项目经理，如果你的小组没有好的产品经理，除非你自己对项目完成没有责任感，否则至少要扮演一半的产品经理。2 .管理需求的人必须平衡工期和功能的友好度需求有两个极端，一个是尽最大努力，尽量使功能更友好，使用户体验更好，一个是尽快交货，可以牺牲一切改善的需求。如果只满足前者，项目工期可能会延误。 因为许多功能的工作量实际上是细节优化，而不是主流程的完成。 如果只满足后者，很可能会出现对用户产生不满的产品。有经验或者产品意识高的产品经理，有平衡好的两点。 产品经理不平衡的情况下，只能依赖项目经理来平衡。 在这一点上，如果产品经理和项目经理不是天才的话，只能通过经验来学习。例如，我们注册的页面上有一个城市输入框。 城市的输入框非常友好。 如果想尽快完成项目的话，只要让用户自己输入这个输入框即可。 一个好的设计是选择两个下拉框，一个是省，然后是城市。 但是，更好的设计是用户可以选择，也可以在此输入框中自由输入拼音的首字母、汉字，使系统显示出适合自己的城市，让用户能够进行选择。 后者的改善肯定会花费时间，但如果不进行两方面的改善，则仅仅是用户自由输入，在后期维护时用户就会输入基准以外的城市数据，如果用户的城市数据需要其他功能，则有数据出错的风险。3 .知道不能对不重要的需求说如果工期和功能改善不平衡的话，有时需要稍微注意一下。 你必须明白必须对不重要的需求说不。 这很简单，对于一个需求来说，即使发现该需求不是依赖于其他功能的核心需求，在该需求之后必须实现，也可以补充，总体工作量不断增加。 但是，为了达到这个需求而使用资源的话，之后发现这个需求不重要或者可以简单化，就已经浪费了工作量。 两者的成本，明显是前者的成本较小。4 .合理化需求优先级需求优先级必须满足以下要求：a .不变的需求应该先完成，项目组完成一些功能，结果发现需求变化，之前的工作量已经浪费。b .依赖其他需求的需求必须先完成。 仅仅如此，不妨碍依赖它的需求的开发。例如，登录功能要求许多登录页面包含当前登录的用户信息。c .主流程或核心需求先完成，改善性需求后完成。例如，在信息列表页面中，许多功能需要用户从信息列表中选择要操作的记录。 因此，信息清单是核心需求。 信息列表页面列表格式的美化是改进的需要。#风险管理风险管理是项目经理非常重要的技能。 好的项目经理必须尽早列出并解决所有风险。 光滑项目，从前期到后期风险点应为倒三角形，前期风险多，后期风险少。 项目管理不善的是正三角形，风险小，到后期风险大。项目经理必须尽可能确定所有风险点。 如果有一点的话，你不知道他有没有风险。 即使我们早期把它作为风险点来重视，其代价也远远小于后期等爆发时应对。我们现实中有一个恰当的例子。 我们的功能之一是SSO，合作伙伴可以调用我们的界面，以便不直接从他们的站点登录到站点。 因为与第三者有关，所以我们最近担心这个部分可能无法做什么。但是大家只是在想，不太在意。在项目的后期，您需要与第三方站点联系，以测试我们的SSO接口和以下流程是否可用。 结果显示，由于第三方安全管理严格，外部用户无法访问站点。 我们的测试停滞在那里。 后来鸡飞走了，两家公司的IT和组织的人们探讨了这个问题的解决方法。发表时间最终在这方面落后了。#最不能控制外部从属关系风险管理的另一个要点是记住，项目组可以处理的问题是小问题。 项目组外人员需要处理是个大问题。 由于项目组外的人员不会安排给你，所以他应该承担的时间不一定是你满意的时间，即使是你满意的时间，也不一定能在那个时间完成，即使真的完成了，也不一定能得到你想要的效果。#如有必要，任务必须一步一步地进行项目经理不是很容易分开任务的。 如果你的开发人员没什么经验，或者技术能力强，思考周密，就要紧跟你分发的任务。1 .仔细看看他们的任务开发到什么程度。 如果可能的话，让他来执行吧。2 .问问有没有什么问题，有什么可以帮忙的。 因为他很可能有问题。 其实，我更了解经验和背景，所以简单地向他指出简单的解决方法。3 .在检查过程中，有可能发现他还没有发现的问题，或者与这个任务相关的问题。任务完成进度和完成质量是影响项目进展的重要因素。 项目经理的主要职责之一是帮助快速推进每项任务。做现在，看后续我们明确了当前迭代的需要、过程、依赖性和其他疑问，确保项目组顺利进行时，项目经理不应该专注于当前迭代，而应该整理下一次迭代的事情，以便当你们完成当前迭代时，不必停留在那里举一个例子，当前的迭代具有用户注册的功能，在此迭代结束后，再展示已注册的主页。 开发组注册时，项目经理也在那里跟进注册的详细内容。 等待下一次迭代开始，项目组在首页上只展示了原型图，发现UI和HTML都还没有创建，但其他功能还没有准备好。 因此，项目团队只好花两三天在那里等UI和HTML。#固定项目组的成员这是一个简单的要求，但并非所有人都重视。为了不让开发人员随意进入，也不能立即加快整个项目的进展，如果改变人员，整体的进展也一定会受到影响。成员潜力程序员、测试员、艺术家和产品经理都比你想象的要聪明。 如果你不清楚你成员的能力，你就试着对他的任务加点困难，超过你本来的期待。 他能完成，以后可以增加更多困难。 直到他直接告诉你他做不到。 如果你认为你有清晰的认识的话，应该会记得，但你认为。我们有一个项目。 里面有很棒的程序员Joy，平时是个非常安静的人。 项目经理分担任务时，几个特定的模块要他完成。 他也坚守岗位，做了他自己的事。 项目因各种原因而落后。 但是Joy诚实地做了他的本分。后来Joy告诉我，你以后会把自己当作dev lead来看待，调整一切开发的事情。乔依然是个安静的人，他坚持自己的本分，但这次的本分负责一切开发问题。接下来项目的问题不断迅速解决，其他程序员也得到强有力的帮助，迅速处理自己手头的错误。项目的进展很快赶上了原计划。你真的发挥了你成员的潜力吗？人人都看全面项目经理很好地分配任务，使每个成员能够更加独立地工作，但不一定是好事。 因为软件开发是团体的工作，所以每个人都在做的事情是交叉的。 我发挥的功能，接下来会调用你的接口。 你做的那一页，下次跳到我的那一页。布鲁斯创建了显示公司人员信息列表的功能。 其中有选择计算出席率的人的操作。 此操作不是由布鲁斯执行的，而是直接调用Lisa页面时，Lisa页面将显示直接出席率计算结果。 布鲁斯知道他只要简单地传达个人的身份就可以了。丽莎正在做这个出勤率的网页。 因为这个人是商务人员，经常在分公司跑步，所以只能计算在某个分公司的上班情况。 她以为大家都知道。大家完成后，我们发现QA在测试过程中已经在人员信息列表中，而且没有出现工作页面。 整个过程变得不顺利了。然后，发现当前的两个问题仍未解决，一个人员信息在跳转到上班页面之前传达当前的分支机构信息，一个在上班页面添加选择分支机构的功能。这两个问题之一是QA检测错误，一是需求仍然不足。 这本来是在开发周期内发现和解决的问题。根本原因是布鲁斯和丽莎在手头工作的时候没有考虑和别人的关系。 他俩都不想，别人就不想。布鲁斯和Lida在工作时，一想到他们是怎样联系在一起的，问题本身就变得简单了。项目组的全体人员都可以把重点放在自己手头的任务上，思维方式要全面，在大家的脑海里要经常思考。 整个系统是什么样的，我功能的前后依存是什么样的？ 项目经理总要让大家这样想。#每次小的迭代必须分开步伐太大，不知道你是否正确，走得不够快。 项目一步也到不了。 把一个大目标分解成一个小目标，把整个项目工期分成几个短暂的反复，逐个完成。 每个完成的小目标