标签：没有 好项目 部分 项目 状态 完成 标准 可扩展性 组成
这一步看似简单，却直接关系到整个项目能否正常完成。所以，在项目计划阶段，我们一定花足够多的时间做好项目进度计划，在分解项目任务时，颗粒度尽量细一些，确保分工到人，并确定好截止时间。以下时阅卷项目的人员在wiki上的分工和任务拆解：
项目组成员间的作业流程，是通过邮件、Excel还是项目管理工具沟通，在项目启动会上一定要明确清楚。比方说官网改版的项目，我们可以把作业流程分为【需求收集】-【需求内审】-【需求评审】-【开发中】-【测试中】-【已上线】，每个流程由某位或多位负责，任务状态变更后，再进入到下一个流程。
很多时候我们会同时负责多个项目，或是还有很多其他日常工作，如何保障项目正常运行，这需要我们时常检查项目节点/里程碑，及时发现项目中可能的风险。还拿官网改版项目举例，如果项目任务流转到UI设计了，但是设计组一直没完成，我们就需要尽快找相关负责人沟通。项目中琐碎的事务如果怕忘记了，建议可以在桌面建一个备忘录，将任务记录上去，完成了就打勾，每天检查任务是否完成。
项目执行过程中的沟通也是非常重要的，来确保项目进度的信息透明和对称。如果A组已经做好某件事，需要B组做另外的事，如果没有沟通，B可能压根就不知道，这样项目进度就会延误。有些项目的项目组会定期召开项目进度会，和项目成员同步进展情况，并再次确认各项任务的截止时间。但如果项目组有用到项目管理工具协作和沟通，信息比较公开透明的话，项目进度会就没有必要太过频繁。当然，和关键干系人的沟通还是必不可少的，可以定期核对项目进度。
想让项目成员工作起来更有激情，只靠冷冰冰的管理制度是没有太大用处的。项目负责人要信任每一位成员，并实时注意成员的工作状态，适当增加成员在执行任务中的乐趣，做得好的一定要及时鼓励，培养成员的积极性和自我成就动机。整个团队有干劲了，项目的完成也就是水到渠成的事了。
1）紧紧抓住“需求定义”，要求对方把所有需求都反映到文档中，定期Review这些文档（1周1回吧）
2）要求对方做出“整体计划”，在其中表现出各个重要的“里程碑”，然后根据整体计划制定各个阶段的“详细计划”
3）根据“详细计划”，定期检查项目进度，至少1周1回。首先得有“周报”，然后基于“周报”确认一下这一周的问题点，是否有延迟，下周是否有风险，共同商讨对策。
4）评价是否到达“里程碑”不能由对方随口报告，而是要由发注方对“需求定义”以及“代码”都比较熟悉的人，参与Reiew后，在问题点都基本解决的情况下，才可以判断为到达里程碑，可以进入到下一个开发阶段。
5）最容易出问题的阶段是编码实现阶段，因为有大量功能本身就存在一定的“歧义”，很难用简单的语言进行定义；大部分的开发人员会认为“开发出能用的产品”就OK了，而很多“可扩展性”、“可维护性”的东西很难在事前说下。为了解决这种问题，在编码之前，整合开发人员的思路，统一大家的意识，这些“设计”工作就很必要了；重要的整合内容务必保存为“设计资料”，在今后的代码审查阶段，要基于“需求定义”和“设计资料”这些上游资料进行检查
6）最好在每个阶段的开始和结束之间留下一些预留的空档，哪怕仅有2、3天，一来是预留对应风险的时间，二来是调整一下开发人员的节奏，总结、反省一下上游工程的问题点，规避一下下游工程可能发生的风险和问题
标签：没有 好项目 部分 项目 状态 完成 标准 可扩展性 组成
原文地址：https://www.cnblogs.com/garxiu/p/11100406.html
