团队建设感悟（13）：如何应对需求变化 -管理资料

    系列文章目录索引：《团队建设感悟》

    前记：

    过去，在传统软件行业里，开发的流程一般是：先作需求分析，然后确定功能，最后实施开发，

团队建设感悟（13）：如何应对需求变化

    但是，在进入互联网软件时代后，事情已经发生了变化，仅就需求而言，“朝令夕改”已经不是什么新鲜事，作为系统的实现者，我们当然都希望需求越稳定越好，但那仅仅是“理想”，甚至，有时仅仅是“梦想”。因为，对于一个尚未成熟的市场，尚未成熟的互联网产品或者尚未成熟的团队来说，需求变动的推动者，可能是市场，可能是用户，也可能仅仅是老板的一句话，你无法说这个改动是对是错，很多的情况下，我们也没有那个精力和时间去争辩谁对谁错，对于我们而言，最切实可行的一条路，就是：摆正心态，积极应对。

    这是一篇有关“如何应对需求变化”的作团队感悟，其核心思想是：在互联网软件时代，需求变化是软件开发的一种常态，我们再也不能用开发传统软件的思维来照搬互联网软件的开发。互联网软件“需求变化快，开发周期短”，从各个方面都要求团队内部要建立起应对这种快速变化所需的组织、流程、以及沟通氛围。作为底层的实现者，对于需求变化，很多情况下是我们决定不了的(要么是老板说了算，要么是用户说了算，要么是竞争对手“说了算”)，这时，对于我们而言，只有在力所能及的范围之内作到适当的架构灵活和适当的组织灵活，以积极的心态和主动的方法来应对这种变化才能把产品务实的一步步向前推进。

    引入正题：

    写程序，最痛苦的是什么？就是辛辛苦苦弄了半天，写好了，人家的需求却变了，刚写好的代码没用了，全部删掉。曾经以为，只有互联网软件里，才会比较经常的出现这种情况，但是，跟一些朋友聊了之后，才知道，原来，现在的传统软件行业里也存在同样的问题。不管这个需求来源于哪里，程序员除了抱怨一下，发一下火(还要看有没有那个“资历”)之外，该作的，还仍然要作，一个都逃不掉。

    我们的开发中，也会经常遇到这样的问题，面对不断变化的需求，我们有过懊恼，有过气愤，有过不平，但当所有的情绪都发泄完了之后，静下心来想一想，为了产品，这些新需求还都挺有道理，都必须来实现。

    于是，我试图想在这篇文章里，分析和总结一下有关需求变化的前因后果，还有我们目前的作法，以及我们如何看待需求变化这件事的，希望能给大家带来一些帮助和启发。

    对于我们凭一己之力无法改变或者无力决定的事，应该秉持两种心态：

    1 要以积累的心态去用自己的实际行动对它产生积极的影响力；

    2 既然我们无法改变它，就只有接受它，适应它，再慢慢引导它。

    对待需求变化，也是同样的道理。

    很多的需求，为什么会有，为什么会变，可能本身就是没有太多道理的，老板说这个得改一下，那个得改一下，在产品没有推向市场之前，在用户没有最终体验之前，你也很难说他的这个需求就是不对的或者不合适的，那这时怎么办？我们的策略是：争取一下，沟通一下，想想其它办法，实在不行，就什么也不用说，动手作吧。当然，这是一种被动应对的方式。

    我们认为，这是没办法的事，一个团队，需要成长才能成熟，一个老板，也同样需要成长才能成熟。只有越来越成熟了，才可能会越来越多的提出更合理的更稳定的需求，而反之，当他不成熟时，他作出的需求就谈不上稳定和合理，那这时，是不是我们就不要作事了，是不是就只有散伙了？我想，动不动就这样去想的朋友，还没有真正悟出开发者应该具有的觉悟：其实，老板都差不多的，当你换了一家后，你可能也会遇到同样的问题，你能作的，不是逃避，而是正面面对它，如果他的想法不成熟，就帮着他成熟，如果他坚持，就照作，让事实教育他。当事实一次次告诉他，你的想法和作法才是正确的之后，他才会更愿意放权给你。而在此之前，你没有其它更好的办法，只有忍着。

    也许，我们经常会有这样的抱怨：“我们不是约定好了吗，就按XXX来作的，怎么又改了”。我想郑重的告诉大家：不要相信约定，对于一个尚处在生存期的项目而言，你一切努力的目标，都是为了项目生存和发展，而不是为了一个“浪漫的约定”，

管理资料

    从另一方面说，很多时候，并不是老板自己想作出需求改动，他们可能是受压于市场环境，受压于同类产品竞争，也可能是受压于用户，总之，方方面面的原因，都可能造成需求改动，所以，我们没有理由、也没有必要一直坚持在“需求需不需要改动”这一点上来回的扯皮浪费时间，我们更多需要作的，是要考虑一下，在我们团队内部，以何种开发方式，以何种流程，以何种组织架构来灵活适应这种经常性的需求变化。

    除了上面所说的被动应对，还有一种主动应对的方法，那就是，作为系统开发者，我们自己要不断的使用我们自己的产品，不断思考我们的系统需求，在你使用和思考的过程中，很容易发现一些极可能带来变化的需求，这样，你在设计和实现时就可以提前规避。不要认为一个系统你开发完了，就是完事了。很多的细节完善，其实是在你第一遍开发完成之后再慢慢添加的，而如何才能发现这些细节，只有你自己不断的使用自己开发的系统。

    面对需求变化，首先，我们要摆正自己的心态：

    1 不要一上来就发火，要分析为什么会有这个需求，新需求的核心点是什么？

    2 对比一下旧的实现，这个新需求用旧的框能不能简单改改就可以间接实现？

    3 从心态上，把需求变化当作是一种项目常态，但是，要学会控制这种需求变化的趋势，不能任其发展。

    除了以上相关的心态准备外，在团队内部，还需要建立一种能快速适应需求变化的组织结构，我把这种结构，概括为：一人负责制+小团队协作+信息共享。

    也就是说，在我们所有开发的系统中，针对于其中每一个具体的系统，都只有一个负责人，不会有两个或者两个以上的负责人，这样便可以最大限度的加快项目决策本身所耗费的时间，有利于快速决策和快速实施。

    小团队协作，是指，一个具体的系统，从开发到测试到实施，涉及的人尽可能少，两三个人，四五个人，最好。因为，一个系统，从设计，开发，编码，到测试与交付，其中可能会涉及到诸多环节，并不是由程序员作完编码整件事就完了，产品可不可用，最终还是要由客户说了算，所以，应该想办法尽可能提高产品从编码到交付乃至到用户反馈这样一个完整流程的效率，涉及到这个系统的所有人员的反应速度就决定了整个产品对于用户需求的响应速度。

    团队协作，最主要的两点：分工明确+信息分享。分工明确，是说哪一些人负责作哪一些事，有明确说明，但除此之外，我们比较提倡的一点，就是：每一个人，其最终，都是对产品负责，并不能只关注自己所作的那一块工作，把属于自己作的工作作好，只是一个基本前提，具备完整产品思想的人，才能谈得上合格。而信息分享，是指通过IM群、邮件、小会等多种方式把需求变化的信息尽可能快的通知到所有涉及到的人员，以让这些人员更好的进行协同。

    除了组织架构，我们还需要提高团队成员个体应对需求变化的相应能力，这些能力包括：提高代码架构本身的灵活性，提高编程人员本身的应变能力。因为代码最终都是由单个具体的开发者实施的，他们的能力大小决定了他们的痛苦程度。

    代码的灵活，可以在一定程度上适应需求变化。但是，这并不是解决需求变化的万能灵药。因为，在实际的操作中，我们经常会因为无法把握“灵活的程度”而把代码本身写得过于复杂，从而甚至让代码本身丧失易维护性，这是我们所无法接受的。我们认为，代码灵活性的底限，是不能破坏代码的可读和易维护，如果到达这个底限，我们宁愿丢弃灵活性，宁愿将代码写得笨一点。

    我这里所说的这种方法，对人员也是有一定要求的，比如，这个负责人，就必须是能独当一面的，要有比较成熟的作事方式、方法和态度，知道如何在高压力和短时间内开展最有效的协作。

    很多互联网产品，可能都会遇到一种情况：一个产品的新版本刚刚发布了，但是，在引入大用户量测试时，却突然发现出现严重的问题，这时，就特别考验负责人的应变能力，这种情况往往都是比较紧急的，成千上万的用户可能在网上排着队用你的东西，你需要在一小时、半小时甚至十几分钟内作出有效修改，这种感觉，已经类似于打仗，虽然很刺激，但确实需要相当大的处变能力。

    每个团队，刚开始的时候，可能都不会这么完美，有这么多能独当一面的人，但万事总要有个开头，团队的成熟并不是靠读一两本书，看一两篇博文就能实现的，它需要你和你的团队在具体实践中不断的磨合、提高、总结。

    本文作者：sodme

    本文出处：http://blog.csdn.net/sodme

    声明：本文可以不经作者同意，任意复制，转载，但任何对本文的引用都请保留文章开始前三行的作者，出处以及声明信息。谢谢。