这几天部门的兄弟们又被产品新版本发版搞得焦头烂额，很是无语，像我这种混混都觉得明显错误的地方，研发中心的中层和高层领导却在不停地反复地来犯，搞不懂，是我目光短浅还是各位老大太弱，为什么这样不想多纠结，这里就把我认为的错误总结出来。

首先是我们为什么进行这次开发。
领导认为原来的产品不满意，需要大幅改造，看网站不爽了，需要重新改版，老板觉得人家其他公司有的东西，我们也要有。好吧，研发老大不知是受到老板鼓舞还是感觉自己的危机，开始立即组织大家进行封闭开发，开发什么，怎么开发，封闭了再说，结果上了山之后，那些搞需求的和几个部门老大，天天吵来吵去，在经过一周多的争吵之后，终于有点方向了，大家开始行动。

错误在哪里？
目标不明确！得到用户的需求，首先想到的不应该立即去响应，而是进行研讨，明确目标，然后，制定路线，开发范围，这样才能让下层开发人员有目标，才能清楚自己该干什么，怎样是开始，何时结束。需求人员才能围绕一个中心去梳理需要开发的内容等等。

此种情况如何解决?
这个需要高层领导有觉悟，要理解和了解整个研发过程，你是整个研发中心的老大，要为大家指明方向，明确实际目标，而不是空喊号子，各级领导也要层层下放明确本部门目标，需求要和上层人员做好目标的问题沟通，并推敲出本次开发路线图。



接下来是需求确定。
由于没有明确的目标，大家急急忙忙组织到一起顶本次开发的需求，大家已经封闭起来，准备好开发了，所以需求要得特别急，在这种情况下，需求不能顶住压力，而是随意地制定了简单需求，让这些开发人员先做起走。

错误在哪里？
需求不稳定！由于着急，盲目和仓促地定制需求，这样导致需求很不稳定。为后来的开发埋下隐患。

如何解决？
需求要充分和上层还有开发人员沟通，明确本次开发的需求和任务。制定好开发任务清单。



再下来是开发。
各团队拿到需求说明了，就开始乱七八糟的搞起来。分工不明确，目标不明确，需求不明确。

错误在哪里？
认为时间不能耽搁，先做起走，这样不浪费时间？这时大错特错。这样盲目行动才是最浪费时间的。古人早就告诉我们，磨刀不误砍柴工！

如何解决？
拿到需求后，先制定好一个基本的开发路线和功能点，安排好开发人员和设计人员，这样才能做到责任有所指，任务有所依。



再下来是需求变更。
又是上层问题，需求问题，需求人员在开发过程中得到开发人员反馈，或者各种上层“指导”随随便便改变了需求，下面人员乱成一锅粥，做好的东西，又要重新来过，仅仅是因为需求的一句话，设计和开发人员怨声载道。

错误在哪里？
需求人员可以说是完全不负责任，最初的需求为了完成自己的工作而不管以后情况，之后的开发中又迫于现实和领导要求，不顾一线人员感受，频繁修改需求，既导致开发时间增加，又使开发人员怨声载道，士气大跌。

如何解决？
求求搞需求的负点责任，最开始的需求如果你不确定就先不要做，做需求的时候从一线人员和客户的角度想一想。开发过程中的需求变更要把返工的时间和开发人员的心情，需求的重要程度都考虑进来，争取做平稳的需求变更。而少做最好不做颠覆性的变更。



最后是发版。
搞了几个月终于算是弄个东西出来了，兄弟们觉得终于要摆脱痛苦了。经过一堆这这那那的老土测试。版本也终于要发布了。这时候一些领导就突然没了信心。在发布的时候，吧所有的人都召集起来，不许休息，发布后，测试人员要再次进行无比蛋疼，本来可以省略的测试，发现问题要立即修改。开发人员拖着疲惫的身躯陪着测试人员搞测试，寻找一堆莫名其妙的发布后问题。郁闷无比。而且这时候，竟然有些东西还只是半成品！

错误在哪里？
发布流程不可靠，发布结果不可控，导致领导没有信心，进而使开发人员无法休息，百无聊赖的等待测试结果。一些东西由于前期计划混乱，甚至没有计划，而无法和不可能赶上进度。

如何解决？
完善发布流程，有一套可靠的发布机制，比如在线产品，提供发布服务器，与发布测试没问题后，通过同步软件，同步的运行服务器，这样，使发布服务器的测试结果和生产服务器是保持一致的，测试的可靠性就高，甚至可以说发布后无需再次测试了。而一些无法完成的任务，只有靠前期和中期工作，这算是一种重大的事故！



以上就是这次开发我觉得错误的地方。贯穿整个开发流程，蝴蝶效应尽显。我也给出了一点自己的拙见，希望有能力的人来验证一下是否真的可行。

建议继续学习：

1. 使用线框图来简化你的产品设计流程    (阅读：2711)
2. 发布及其检查的自动化实践    (阅读：2262)
3. 产品UI设计流程    (阅读：2188)
4. 研发流程中与其他岗位协作效率的提升    (阅读：2106)
5. 产品UED流程及交付物    (阅读：1934)
6. 也谈前端开发流程    (阅读：1868)
7. 线下项目工作流程(归纳篇）    (阅读：1787)
8. 关注前端开发流程    (阅读：1708)
9. 线下项目工作流程（分析篇）    (阅读：1660)
10. 产品评审那点事    (阅读：1516)