今天下班在公交车上，突然想到我毕业工作将满一年，我觉得该写点什么，然后我决定写我在上家公司两个项目。

首先说说这两个项目，一个是网络化功能，另一个是一个ios app。前者失败，后者上线使用但也只能凑合。

我这四年的大学期间，给我影响最深的是快递和互联网的发展。上家公司在怎么使用网络提升客户满意度和产品质量上希望做一些探索，这就是第一个项目。

当时我刚被分到公司最早的产品组，开始做产品功能的客户定制。突然一天研发经理让我和一个员工开始参与这个项目，其实就我们两个人，但是给我们的资料只有一个设计说明书，在看了技术线路之后，我反映给研发经理，我希望使用开源的技术堆栈而不是我们自己从零开始搞，然后研发经理答应了，我也出乎意料。

项目匆匆上马，对于一个探索性的项目，需求这块可想而知，高层说网络是趋势，要搞，对于一个对公司产品应用场景都没去过的刚毕业的愣头青可想，需求完全是一头雾水，我们组的产品经理对这个很不看好，他跟我说过，车床没几个连网的，需求注定了这个项目只能烂尾。

项目开始提出的需求都是基本的更新，广告提示，系统信息上传。这些功能对于现在的软件都是基本的，可是对于一个10多年时间，开始并没有考虑网络功能的软件添加这些功能难度可想而知。而我对当时产品架构可以说是完全不熟，而这些是设计说明书里面没有的，那个说明书更多的是服务器端的，客户端这块的详细设计一点没有，这就导致了在编码实现时的设计局限性，也为项目失败添加了一笔。

项目的规格说明也没有，不知道做什么样，导致了在项目开启后的中期检查，做出来的功能根本不能使用，只是一个实现功能的原型而已，没有验收标准，这会导致项目实现要求一直在变。

我已经不记得是在那里看到的：“在项目开发中，频繁的修改需求和规格标准，会导致项目延期，更甚者导致项目失败，在没有导致产品不能用的情况下，不需要修改需求和规格。”

最后这个项目的功能大部分被阉割，在服务器搭起来后，在进行了一个小规模的上线测试后，不了了之。然后下面开始了第二个项目。

第二个项目是一个公司软件的注册验证app，算法什么的放在公司服务器，破解的难度就加大了，这是很实际的一个产品，需求很明确，需要完成什么样，也很明白，这个项目的服务器是我负责，app外包给了其他公司，我的大部分时间都是与前端开发人员沟通。

项目进展还比较顺利，在1个月后，第一版产品出来，开始在公司内部测试，这时领导的需求又开始来了，不过这次有些需求被我打了回去，还有一些需求都是在与前端人员讨论之后才修改的。对不合理的产品要求，我也坚持了自己。最后app上线了，算个凑合。

这两个项目让我这个新人，体会了良多，以下为我的一些总结：

1. 需求很重要，连自己做什么都不清楚，那肯定是做不成了。
2. 半路加需求请确定对现设计的影响程度，不然就放到下个版本。
3. 规格要求不能总是变，不然产品无限期推延，最后你自己都不知道会怎么样，客户还能用就不要改，要改也是下个版本。
4. 项目进度是要每天盯了，以便做出调整，给自己留条后路。
5. 在项目中的沟通尽量找到一个都合适大家的沟通风格。

本文由 @zhouxiang 原创授权发表，并经人人都是产品经理编辑。转载此文章须经作者同意，并请附上出处(人人都是产品经理)及本页链接。