项目：在既定的资源和要求的约束条件下，为实现某种目的而相互联系的一次性工作。
项目成功的三个要素：
1、必胜的信念
2、正确的信息同步
3、可靠的人力
项目风险往往在如下几方面
一、信息同步尤其是跟外部团队合作时，信息同步是重中之重。明确整体项目的目标，清楚自己所在的细分项目在整体项目中所处的环节和作用，以及同其他团队的协同依赖关系。在这里需要向对外的接口人了解整体项目的完整流程，而且一定要跟对方项目的接口人完全对一遍项目整体流程，让对方明白我知道整体项目流程目标和自己所在环节和作用。沟通项目流程时要保证产品、技术（前端、后端）、内外接口人都在场，这可以避免出现缺失某个环节导致的实现问题。
二、明确需求明确需求在项目正式开始之前是非常必要的一步。开发以及测试需要对产品功能有一个全面的了解和时间上的风险评估。这一方面需要产品同学给出一个详细的 产品流程、原型图以及需求文档 ，同时需要拉上相关团队负责人、以及技术同学进行 需求评审 。碰到过几次产品的需求不明确结果项目进行中出现问题，需要产品重新梳理相关模块逻辑，有很大的项目延期风险。
同时产品的需求受到多方面的因素影响，比如时间、历史包袱等因素，肯定会存在初期有部分细节不明确等问题。这也是项目的渐进明细原则，遇到这种问题要及时反馈，在各方博弈中找到一个相对适用的平衡点。
三、技术选型对于从0到1的项目，技术选型是非常关键的一步。 做技术选型一定要从业务角度思考而不是做技术炫技 ，要考虑整体业务时间、团队成员的基本水平、团队成员对某些技术的熟练程度、技术工具框架的成熟程度、社区的活跃性、业界是否有成功的案例、生态的完善程度以及背后的支撑团队。有技术追求的同学在初期技术选型时容易盲目追求新技术工具和框架，从而带来项目风险。最早在上一家公司做项目时，业界成熟的框架是React和Angular2，不知为什么负责选型的同学选了还在beta版本的angular2，导致后期升级迭代出现重大问题。
同时在技术选型确定后，在开发之前一定要 规划技术架构 。做架构的基本思路是分层，层内分模块，模块要做到单一职责。各模块之前尽量降低耦合，保持架构的可扩展性。做架构时可以问自己两点：
这个架构能够允许多少人同时参与
这个架构能够支撑业务发展多长时间
四、人力盘点等到项目流程和需求确认完毕后，我们需要梳理项目涉及的整体人员。项目人力盘点需要明确项目所需要的角色、人员、人力投入。建议人力盘点分为以下方面：
外部人员：接口人、具体功能对接人
内部人员：
对外接口人
主体业务团队：产品、视觉、交互、前端、后端、客户端、QA、项目负责人、研发负责人
依赖团队：产品、具体功能对接人
其它相关干系人：leader、老板等
在项目过程中最怕遇到的是人员的变动。拿个人实际工作来说，遇到过技术人员变动、产品人员变动。发生人员变动往往会给项目带来极大的风险，人员变动需要做好工作交接，前期的工作（需求文档、产品原型、功能流程）做得越多越规范，对项目带来的风险越小。
五、项目排期项目排期阶段最重要的是 确认项目时间点，以及人力成本 。需要研发负责人梳理需求，拆分需求，明确各方的依赖关系和完成时间点做 版本规划迭代 。做排期一定要预留足够的buffer（以月为单位的项目最好预留一周的buffer）以应对可能插入的事情，同时安排好足够的测试时间。迭代的时间最好以两个周为单位进行规划，每一个小版本做一次测试，同时在后面的时间安排两天来修复重要bug，前两个版本可以只修复严重bug，其他bug放到后面项目进行过程中进行修复。
项目排期时一定要 了解项目成员的技术水平和能力模型 ，尤其对于新人和刚加入的同学，要给他们预留一定的buffer。曾经带着一群新人做项目，项目执行过程中出现了不少问题：
缺少主动推进意识，佛系
没有风险同步意识，自己瞎搞
描述问题不清晰，沟通成本高
没有全局意识，随意改接口
新接口不向后兼容，对老版本造成影响
还有一种项目排期叫 倒排 ，时间点确定，必须在规定时间内完成。这种项目往往是时间紧、任务重、压力大，我在这家公司经常遇到这种情况，这也跟业务发展有关。遇到这种情况，需要及时向上沟通，调整部分功能或者增加人力。当然如果实在不行，只能加班加点硬着头皮上，这时候往往能看出人的品质。
六、项目启动会