标签：项目启动 项目风险 防止 角度 扩展性 扩展 跟踪 调整 申请
项目：在既定的资源和要求的约束条件下，为实现某种目的而相互联系的一次性工作。
项目成功的三个要素：
1、必胜的信念
2、正确的信息同步
3、可靠的人力
项目风险往往在如下几方面
尤其是跟外部团队合作时，信息同步是重中之重。明确整体项目的目标，清楚自己所在的细分项目在整体项目中所处的环节和作用，以及同其他团队的协同依赖关系。在这里需要向对外的接口人了解整体项目的完整流程，而且一定要跟对方项目的接口人完全对一遍项目整体流程，让对方明白我知道整体项目流程目标和自己所在环节和作用。沟通项目流程时要保证产品、技术（前端、后端）、内外接口人都在场，这可以避免出现缺失某个环节导致的实现问题。
明确需求在项目正式开始之前是非常必要的一步。开发以及测试需要对产品功能有一个全面的了解和时间上的风险评估。这一方面需要产品同学给出一个详细的 产品流程、原型图以及需求文档 ，同时需要拉上相关团队负责人、以及技术同学进行 需求评审 。碰到过几次产品的需求不明确结果项目进行中出现问题，需要产品重新梳理相关模块逻辑，有很大的项目延期风险。
同时产品的需求受到多方面的因素影响，比如时间、历史包袱等因素，肯定会存在初期有部分细节不明确等问题。这也是项目的渐进明细原则，遇到这种问题要及时反馈，在各方博弈中找到一个相对适用的平衡点。
对于从0到1的项目，技术选型是非常关键的一步。 做技术选型一定要从业务角度思考而不是做技术炫技 ，要考虑整体业务时间、团队成员的基本水平、团队成员对某些技术的熟练程度、技术工具框架的成熟程度、社区的活跃性、业界是否有成功的案例、生态的完善程度以及背后的支撑团队。有技术追求的同学在初期技术选型时容易盲目追求新技术工具和框架，从而带来项目风险。最早在上一家公司做项目时，业界成熟的框架是React和Angular2，不知为什么负责选型的同学选了还在beta版本的angular2，导致后期升级迭代出现重大问题。
同时在技术选型确定后，在开发之前一定要 规划技术架构 。做架构的基本思路是分层，层内分模块，模块要做到单一职责。各模块之前尽量降低耦合，保持架构的可扩展性。做架构时可以问自己两点：
等到项目流程和需求确认完毕后，我们需要梳理项目涉及的整体人员。项目人力盘点需要明确项目所需要的角色、人员、人力投入。建议人力盘点分为以下方面：
在项目过程中最怕遇到的是人员的变动。拿个人实际工作来说，遇到过技术人员变动、产品人员变动。发生人员变动往往会给项目带来极大的风险，人员变动需要做好工作交接，前期的工作（需求文档、产品原型、功能流程）做得越多越规范，对项目带来的风险越小。
项目排期阶段最重要的是 确认项目时间点，以及人力成本 。需要研发负责人梳理需求，拆分需求，明确各方的依赖关系和完成时间点做 版本规划迭代 。做排期一定要预留足够的buffer（以月为单位的项目最好预留一周的buffer）以应对可能插入的事情，同时安排好足够的测试时间。迭代的时间最好以两个周为单位进行规划，每一个小版本做一次测试，同时在后面的时间安排两天来修复重要bug，前两个版本可以只修复严重bug，其他bug放到后面项目进行过程中进行修复。
项目排期时一定要 了解项目成员的技术水平和能力模型 ，尤其对于新人和刚加入的同学，要给他们预留一定的buffer。曾经带着一群新人做项目，项目执行过程中出现了不少问题：
还有一种项目排期叫 倒排 ，时间点确定，必须在规定时间内完成。这种项目往往是时间紧、任务重、压力大，我在这家公司经常遇到这种情况，这也跟业务发展有关。遇到这种情况，需要及时向上沟通，调整部分功能或者增加人力。当然如果实在不行，只能加班加点硬着头皮上，这时候往往能看出人的品质。
在项目规划完成后，项目正式执行前，最好能够把大家都叫在一起，开一个统一的项目启动会。项目启动会的主要目的是 正式认可项目管理计划 。项目启动会的参加方包括发起人、项目成员、各个依赖方、相关leader和老板。项目启动会主要介绍以下几个方面：
项目启动会结束后，发起一封邮件，确认项目正式启动时间。
项目规章制度主要明确风险同步机制、需求变更机制、奖罚制度和项目站会。在所有项目中最简单实用的是 项目站会 ，往往在每个版本迭代进入后半程的时候开始。站会时间最好选在上午时间，每次站会时间在15分钟左右，站会每个人回答三个问题：昨天做了什么、遇到问题的解决方式、今天做什么。同时负责人记录其中所遇到的问题，跟踪解决。
项目进行过程中难免出现冲突，依赖于被依赖双方的时间可能存在不吻合情况，或者由于某些事情的插入导致原先时间点出现偏差，这种情况需要项目负责人及时发现问题，协调解决，或者调整排期，或者申请人力，或者调整功能，再或者加个班内部消化。
项目进行过程中需要指定以为项目推进者，负责与外部团队对接，及时同步需求和发现问题，拉动双方快速会议，进行决策。尤其在项目接近尾声暴露出来的问题，可以牺牲一些安全性和规范来及时支持，同时完善长期合理计划。
实在有高优项目插入，对本项目造成影响，那就按照正常的需求变更和项目延期流程来 合理delay 。
项目进行到尾期，这时候测试以及修复bug占主要部分。确定测试环境、预发环境、以及上线回归流程。要确保这个时间测试和预发不与别的项目冲突，以及与测试同学同步产品逻辑确定测试用例。同时要尽量保证测试环境与正式环境的一致性，防止项目上线后由于某些环境变量不统一引起的线上bug，造成损失。
上线之前要 确定各个环节的上线顺序，线上回归用例，以及紧急回滚策略 ，尤其是依赖方。站会时要明确各个环节都清楚上线顺序，并且发送邮件通知各团队相关人员。
项目上线结束后，还需要进行项目总结，目的是对项目进行整体复盘，发掘项目中遇到的问题，以及思考解决方案，避免下次发生类似问题。同时对于项目中存在的问题进行排期解决。
项目总结可以按照以下几个方面来进行：
对于项目参与人员，可以让大家都参与进来，考虑不限以下几个方面：
最后，带人其实一件处理不讨好的事情，领导力是责任和委屈撑起来的。
标签：项目启动 项目风险 防止 角度 扩展性 扩展 跟踪 调整 申请
原文地址：https://www.cnblogs.com/dojo-lzz/p/10230218.html
