近期一个项目的反思


入行这些年，没多少成功的经验，失败的经验却越来越多。今天花点时间好好的反思一下。老是稀里糊涂的可不行。我以下写的不针对不论什么人。就事论事。

一、无管理核心

　　缺少了这个重要的凝聚力，以下的人能够说是在单兵作战。一盘散沙，各自为战。怎么可能把项目做好。还有以下的这些问题：

　　1、团队成员碰到的问题无法得到及时的协助和解决，会让人有越来越多的挫折感。

　　2、无人管理开发文档。开发任务没有科学的制定会拆分。

　　3、因为没人督促，readmine形同虚设，全然没发挥他的作用。

　　4、人员不能被合理的分配，成员之间的协作越来越少。甚至有隔阂。

　　5、不能有效的控制需求，一会儿做这个，一会儿做那个，最后什么也没做成，士气越来越低。

　　6、项目中遇到的意见不统一、冲突，都不能有效的协调好。团队成员思想不能一致。

　　7、无法把控开发者们的进度。

　　8、阶段性成果，没有安排时间及时确认。

　　接下来的那些问题非常多都是由于无管理核心导致的，联动效应。

二、需求混乱

　　规范点的说。需求的管理应该仅仅有一个进口一个出口，拿到需求后，先做个分析。分解细化，然后再转换成可运行的操作。画原型，制作效果图。

　　如今的情况是出现开发与规划不符的情况时候，直接与开发者确定需求。今天要这样改。明天那样，不断的变化。得不到控制，原先的开发计划不断的插入新的功能改动，全然不依照计划来了，最后当然不能在指定日期完毕预定功能了。

　　开发者没有參与到需求的讨论中，听需求的人，在把需求传达给开发者，常常会出现偏差，最后开发者买单。将做好的功能页面等再推翻，改动，费时费力，还影响开发者的心情。

　　常常会纠缠于一些需求的细节，一步到位，力求达到最好的用户体验与效果。我个人认为用户体验的好坏是须要真正的用户用过以后才干确定的，在开发阶段是高速的将一个可用的软件拿出来。以后再依据各种数据为基础，改进用户体验。项目的开发都是渐进明晰的，一開始的开发肯定不能预料到各个方面。既然预料不到，就把重要的先做好，以后再改，有了可用软件，什么都好说。

　　还把測试人员给拖累了。常常会抱怨开发者临近上线才開始提交代码測试，抱怨开发者自己不好好測试。临近上线还要一堆BUG。

全然没有留时间给他们。让他们非常难做，有时候是快到上线日了，软件都还没有，根本没有測试的东西，别人非常忙，自己却非常清闲。

三、不懂业务

　　开发開始前，应该让开发者们使用市面上面相关的软件，实际操作下。体验流程。

实际操作的效果比嘴上说要有效的多。

在操作的过程中。就能体会到市面上的软件哪些地方做的不好，哪些地方做的好，真正换位到用户的位置上。大家嘴上常说要换位思考，但实际操作起来真的非常难，但让自己做一个真正的用户就方便非常多。

　　开发者不懂业务。是个软肋。导致非常多问题。第一个是最大的问题。

　　1、无法质疑需求的合理性，上面传达下来的需求即使有错，也继续编码。最后就是返工。

　　2、非常难对项目提出一些比較好的建议。有时候也不能有效的和最高决策人沟通。

　　3、开发者自己估算工作量的时候，会有一些偏差。

　　4、代码的设计会有影响，懂业务能更好的设计代码的结构，扩展等

5、技术提高的訪问www.cgzhw.com 游戏编程网非常不错的技术站点。

四、沟通堵塞

　　1、測试人员与开发者之间：

　　一開始測试人员不熟悉系统，提了很多易用性方面的问题，另一部分BUG在开发者眼中并非问题——就是那样设计的。

在提出后，放到readmine上面，分配给測试人员觉得的相关开发者。到这里都非常自然顺畅。可是挂在readmine上面的这些问题就这样挂着了，不改动也不反馈。不了了之了。

他们的工作非常难展开，測试与开发之间出现了小隔阂。团队的凝聚力越来越低。

　　后面经过大家的讨论，给出一个解决方式。须要一个中间的管理人，让他去分析提交上来的问题，依据他的理解定位这个问题属于谁，再由他转给某个开发者，由这个人来追踪。測试人员的工作也单一了，不会老是由她来催促改动问题。

　 2、Web端与server之间：

　 这次的项目是须要不同终端互相协调的。web端须要server端提供接口协助，让那边提供接口却总是一拖再拖，迟迟不给。即使在readmine中开个任务，还是没有在预定的时间中给接口，一催二催三催，没有结果。这里也缺少个中间的协调人，须要这个人做沟通。安排时间。分配人力，满足web端的需求。开发者之间是平等的。不存在指挥的关系。谁也管不动谁。开发者之间出现了小隔阂，团队凝聚力再次减少。

　 3、开发者与需求提供人员之间：

　 需求的提供有从最高决策人那里直接发出。有时候也会通过另外几个人员发出。

因为需求的一直变化以及传达的时候常常出现偏差。导致了开发者不在非常相信他们，对于他们提出的需求，常常会做重复的确认。但最后还是会改。他们做的原型或设计的流程，与最高决策人做一一确认有点不现实。这样常常会导致被推翻，直接影响了开发者，开发者在实现了以后也要返工。这个地方缺少了个需求的管理者，须要他来制服需求。这头猛兽在摧残着各个相关人员。

重复无常的变化。让他们的工作也非常难展开。

开发者与需求提供人员之间出现了小隔阂，团队凝聚力势必再次减少。