产品经理的工作大到产品小到项目，这篇我们来聊一聊项目短暂而又坎坷的一生。

前段时间我亲身参与了持续两个月的项目，心血来潮，想以我的项目为例分析项目坎坷的一生。

为什么说项目是短暂？首先我们要明确项目的定义：

只会进行一次，包含多项互相关联的任务，并且有绩效，时间，成本和范围限制的一项工作。

短暂只是相比于一个产品的开发迭代，项目只需要开始和结束。可是项目短暂的一生却无比坎坷。

一、立项

立项之前，我们需要一个团队。

项目大多是团队合作，所以我们需要组建团队。比如:我亲身参与软件设计大赛，团队组建来源于组织内部，很好的是给我分配到了两个厉害的后端人员。我们的团队包括我由五个人组成，我担任产品，有一位前端，两位后端，还有一位算法。

确定计划，明确我们的项目计划是什么，项目目标是什么。还是以我的经历为例，我们参加软设，主要的目的就是设计出一个软件，不局限于手机端，也可以是网站。

所以我们的大目标就是，让我们的产品赢得评委和观众的认可，主要一点是符合大赛主题的——创新。

没错，我们就是需要产品创新，技术创新，内容创新。

以及我前期也会在团队中充当领导者角色，列出阶段性的计划。我们团队致力于打造一个皮影戏文化的创新科普平台，功能包括用户线上体验皮影戏表演，参与皮影戏创作，了解皮影戏文化知识等。以下是我们初赛后的计划：

虽然没有说用专业性的表格以及术语，但是至少通俗易懂，毕竟我们团队是五个组且每天见面的，用简洁易懂的文字列出计划也是一种高效的方式。

二、需求

虽然我把需求写在第二点，但其实是在最前面的，之所以这样写是因为什么的产品需求是在团队组建完成后再共同进行的

我们逐步开始了需求的讨论:

1. 用户为什么会使用我们的产品？
2. 我们的产品最可以帮用户解决什么问题？
3. 有什么其他类似的产品（app/网站/小程序）可以解决同样的问题吗？（竞品）

这里的需求涉及到很多方面，可以参考我上一篇文章——需求挖掘，在这里我就不再赘述了。

三、研发

来到了技术人员的舞台，研发我们的项目产品。

首先，我想吐槽的是，我们的团队没有设计导致我们的页面不是很上分，这也是我们这个项目不太完美的地方。

各位，让产品去当设计这虽然看似合理但是坎坷的就不止项目了，还有产品经理。

设计完之后开始设计评审，真真切切需要团队里的人对页面达成共识或认可设计。

接下来是编码实现，我非常放心地交给了我的技术人员。毕竟，产品的工作仅限于此，我只能负责每天给他们带咖啡（哈哈哈哈哈也不是）。在这个过程中，我还是在不断了解一些技术的，包括matter.js是我们页面实现的技术之一，以及后端人员如何去创建管理用户。

四、测试

我们的项目在两个月中真正工作的时间其实只有一个月，所以自我觉得测试这一块我们做的不是很好。

测试方法有很多，还是需要根据项目的需要选择合适的测试方式:

1.性能测试

测试网站的性能指标，包括网页加载速度、响应时间等。通过模拟大量用户访问，验证网站的性能是否能够满足用户需求，并进行必要的优化。

2.用户体验测试

测试用户在使用网站时的体验。通过模拟用户行为，评估网站的导航、布局、交互等方面是否符合用户期望，并提供友好的用户界面和操作流程。

3.安全性测试

测试网站的安全性，包括对潜在漏洞和攻击的检测。通过模拟常见的网络攻击（如SQL注入、跨站脚本等），确保网站的数据和用户隐私得到有效保护。

简单列举几种测试方式，测试阶段已经属于在项目的后期了，这个时候产品经理难免会开始欣慰，举个不恰当的例子——仿佛是看着自己的雏鸟慢慢变得羽翼丰满，最终翱翔于天空。

五、发布

这是一个最激动人心的时候，也是大家精神紧绷的时刻。到了发布阶段，技术人员心中默念:不要给我加需求了。我不断提醒我自己，忍住，不要加需求。

发布流程：发布评审——>预发布——>发布———>线上验证。

发布成功那天，普天同庆！

最后要进行项目总结，我还是有复盘的习惯的。

看到这里，是不是会觉得这坎坷吗？坎坷在于过程而不是结果。你有没有发现，上面的一到五个点分别对应着五大坎坷:

1.计划怎么确定，如何算是创新？

2.如何辨别真伪需求，需求从哪里来？

3.开发过程中的技术实现难度太大，功能无法实现？

4.测试失败，是否推翻或者砍去功能？

5.发布前紧张的评审和线上用户验证。

经历过后再次回想，好像再坎坷也都过来了，最后给大家分享一段我很喜欢的话:

请赐予我力量，去接受我所不能改变的；请赐予我勇气，去改变我所能改变的；并赐予我智慧去分辨两种的不同。

感谢观看，欢迎大家提出宝贵意见。