如何与项目里的未知相处?
你是团队的技术负责人，肩上扛了一个，销售催得紧，客户等不及，可行性模糊的项目。你对你的老板说，这个项目我规划不了，未知的东西太多了。当初我就是这么干的。如今，大大小小的项目经历了十几个，技术负责人做了快三年，学会了几个和未知相处的方法：分开已知和未知，拿替代方案减少未知，提前遇见未知，和最美的迭代未知。
分出已知和未知
分出已知和未知首先会让你成为一个思维有逻辑，表达清晰的人。如果你是老板，你听下属汇报的时候，到处模棱两可，恐怕你很难给这个下属委以重任。很多时候，未知只占很少的一部分，一颗老鼠屎，坏了整锅汤，未免太可惜了。与其说，这个项目有未知的部分，我规划不了。你可以说，这个项目里，有一部分需求清楚，方案可行，需要三十天，另外一部分，我们需要进一步的探索，目前规划起来难度大。这样一来，老板不仅知道你做了有效的工作，还会增加对你的信任。
第二个好处是客户可能暂时根本不需要那些未知的部分。很多时候，你只开发20%的功能，就能满足80%的需求，这是著名的帕累托的八二法则。一个项目，不会因为存在部分的未知就会让整体失去意义。如果你项目中，恰巧已知的部分，可以满足大部分需求，就可以先把未知的部分暂时搁置。
最后，就是你可以管理利益相关者的预期。作为技术负责人，在大家着急的时候，会让你说一个发布日期。你迫于压力，也出于对团队的保护，很可能说一个足够遥远的日子。这样做，其实是你给自己挖了一个坑。一是你很难解释这个日子为什么这么遥远，二是看似遥远的日子，在处理一些复杂度高的任务的时候，你实际需要的时间会比预期的多。所以，分开已知和未知，只在已知的部分承诺交付日期，在未知的部分一定不要做没把握的承诺，不管压力有多大。清晰的解释未知的部分，会让利益相关者感受到项目所存在的风险，神奇的是，他们会和你一起找办法。
拿出替代方案减少未知
如果未知的部分是项目成败的关键，为了避免在一棵树上活活的吊死，你可以找一些替代方案。这些替代方案，如果找的精妙，可以快速的产出部分有价值的东西，也可以为你们争取更多的时间做更加完美的方案。最为惊喜的是，在寻找替代方案的过程中，你们会更加深刻的认识到，那些是可以砍的，那些是必需留的。
但是这么做也有一个陷阱。如果你的替代方案像秋后的蚂蚱，活不了几天，千万不要在它们身上浪费时间，这只会给你们团队造成更多的麻烦。很多时候，你认为火烧眉毛的事，很有可能是有人为了倒逼你们出成果而采用的心里战术。到目前为止，我还没有见过哪个项目是真正的一天两天等不及，却见多了因为赶工而让整个团队深陷的维护陷阱，返工，以及可悲的人员流失。
找替代方案既有好处也有缺陷，如何衡量？我会问自己一个问题，这是从《逃脱构建陷阱》得到的灵感，我们是为了交付而交付，还是为了产生价值而交付？
提早探索下个未知
当项目中都是已知的时候，不要高兴的太早，等你已知的都做完的时候，一旦遇到未知，你们就会被卡主。项目进展顺利时，大部分人要低头拉车，一定要有人抬头看路，作为技术负责人，你就是那个必须要看路的人。
看路的时候，你不能只自己看。带上产品经理，毕竟路都是他指的；带上某些队员，要不然低头拉车久了，缺乏参与感。看路的目的，就是在稳步推进已知的同时，提前探索下一个未知，这样一来，你们会进入一个良性循环。当下一个阶段开始的时候，如果你按照开头说的分开已知和未知，你会发现，有不少东西都有了眉目，团队可以立马撸起袖子干。
迭代未知
我相信上面的几个办法，熟练掌握后，你可以很从容的去处理项目中的未知。但真正的能去拥抱未知，把未知转化成优势，还得在团队上下，培养迭代未知的能力。有未知的项目，就像摸着石头过河，你不知道深浅，就去摸石头，摸完就知道前面可不可以走，需不需要调整方向。普通的人，一小时摸十个，优秀的人，几百个。河都是同一条河，有的人摸索的慢，有的快。
天下武功，唯快不破。什么是快速迭代？从技术层面讲，你们一个程序员从代码提交到功能上线要用多久的时间？你们一天能交付多少次代码？交付完之后有多少原有功能照样好用？如果交付的不好，你们用多长时间修复它？从产品层面讲，有多功能你们不用开发，就能测出来他们是否真的有用？你有多少用户愿意尝试最新鲜出炉的功能并且给你们反馈？
之前的三个办法，可能会因为个别人的努力而得以解决未知带来的困扰，快速迭代的功夫，一天修不来，一个人也修不来，它需要整个组织的努力。这样的组织，一定是一个学习型的组织。