一个项目的总结

我是移动互联网行业的新手，这个月是来到这个公司的第12个月了，写这篇东西是因为最近自己的一个项目宣告挂起，偶尔维护不开发的状态，在这里有些感慨。

这个项目是一个lbs的交友软件具体说明不能说，失败的原因我总结了有以下几个原因：

1、我是新手：

      虽然已经参与开发了几个项目了，但是我毕竟还是新手，而且我们服务端没有开发过这类软件的软件。在可能客户端开过几次会议而没通知我们客户端开会的情况下，就开始说要做了。因此我们服务端定义出来的协议是有缺陷的。

2、产品不明确：

     除了要做成一款基于lbs的社交类软件外几乎没有创新，基本上就是中国互联网的老手段“抄”，看看哪款软件出了新功能了感觉可以跟客户端一合计就要上，也基本上不理会服务端的开发情况。几乎是产品一定下来就开始定协议做了，由此引发下一个问题。

3、加班严重：

     由于到了中期的时候服务端就基本上我一个人开发导致服务端的我加班非常严重，导致每天都是晕着下班。然后洗澡睡觉，第二天继续这样的轮回流程。虽然项目还在进行。但是整个项目组的人除了很能加班的项目组boss基本上都是很累的，期间客户端还走了几个人。

4、需求变动大：

     都说产品是开发的天敌啊～～～尤其是不懂技术的产品啊～～～导致我们技术就算实现了一个功能也很有可能要因为别的原因修改数据库中的表的属性，甚至与修改属性的字段。还好是个新应用，用户量还不高，否则将是一件痛苦的事情。

5、迭代时间过快：

     迭代过快，这话怎么说呢。一个还没有成熟到可以发布的应用就发布，导致了一系列的问题，比如加班，比如人员流动。

 

总结：我觉得虽然互联网应用的确是要快，但是这个快是相对的。什么是快?快不是让你很快把一个未成熟的应用发布出去，快不是让你成为先驱，给拍死在沙滩上。而是合理的开发完基础的功能之后，经过一定的测试以及审查后再发出去。

1、初期的版本不必要有太复杂的功能，但是要保证稳定，以此来留住用户。用户体验上去了用户自然也就会留下来，你发布新版本也自然会有人去升级了；

2、必要的信息要收集，比如用户日常的坐标移动（当然，这个必须给用户弹框让他们知道这件事情，并同意才给注册）等可以用于后期新功能开发的信息；

3、衡量自己开发人员的能力，不要一味的加需求，求进度。开发人员也是人，也有自己的生活，逼得太紧导致的便是离职，从而降低开发进度，甚至拖死。

 

暂时想到这些，欢迎拍砖