如何与项目里的未知相处?

你是团队的技术负责人,肩上扛了一个,销售催得紧,客户等不及,可行性模糊的项目。你对你的老板说,这个项目我规划不了,未知的东西太多了。当初我就是这么干的。如今,大大小小的项目经历了十几个,技术负责人做了快三年,学会了几个和未知相处的方法:分开已知和未知,拿替代方案减少未知,提前遇见未知,和最美的迭代未知。

分出已知和未知

分出已知和未知首先会让你成为一个思维有逻辑,表达清晰的人。如果你是老板,你听下属汇报的时候,到处模棱两可,恐怕你很难给这个下属委以重任。很多时候,未知只占很少的一部分,一颗老鼠屎,坏了整锅汤,未免太可惜了。与其说,这个项目有未知的部分,我规划不了。你可以说,这个项目里,有一部分需求清楚,方案可行,需要三十天,另外一部分,我们需要进一步的探索,目前规划起来难度大。这样一来,老板不仅知道你做了有效的工作,还会增加对你的信任。

第二个好处是客户可能暂时根本不需要那些未知的部分。很多时候,你只开发20%的功能,就能满足80%的需求,这是著名的帕累托的八二法则。一个项目,不会因为存在部分的未知就会让整体失去意义。如果你项目中,恰巧已知的部分,可以满足大部分需求,就可以先把未知的部分暂时搁置。

最后,就是你可以管理利益相关者的预期。作为技术负责人,在大家着急的时候,会让你说一个发布日期。你迫于压力,也出于对团队的保护,很可能说一个足够遥远的日子。这样做,其实是你给自己挖了一个坑。一是你很难解释这个日子为什么这么遥远,二是看似遥远的日子,在处理一些复杂度高的任务的时候,你实际需要的时间会比预期的多。所以,分开已知和未知,只在已知的部分承诺交付日期,在未知的部分一定不要做没把握的承诺,不管压力有多大。清晰的解释未知的部分,会让利益相关者感受到项目所存在的风险,神奇的是,他们会和你一起找办法。

拿出替代方案减少未知

如果未知的部分是项目成败的关键,为了避免在一棵树上活活的吊死,你可以找一些替代方案。这些替代方案,如果找的精妙,可以快速的产出部分有价值的东西,也可以为你们争取更多的时间做更加完美的方案。最为惊喜的是,在寻找替代方案的过程中,你们会更加深刻的认识到,那些是可以砍的,那些是必需留的。

但是这么做也有一个陷阱。如果你的替代方案像秋后的蚂蚱,活不了几天,千万不要在它们身上浪费时间,这只会给你们团队造成更多的麻烦。很多时候,你认为火烧眉毛的事,很有可能是有人为了倒逼你们出成果而采用的心里战术。到目前为止,我还没有见过哪个项目是真正的一天两天等不及,却见多了因为赶工而让整个团队深陷的维护陷阱,返工,以及可悲的人员流失。

找替代方案既有好处也有缺陷,如何衡量?我会问自己一个问题,这是从《逃脱构建陷阱》得到的灵感,我们是为了交付而交付,还是为了产生价值而交付?

提早探索下个未知

当项目中都是已知的时候,不要高兴的太早,等你已知的都做完的时候,一旦遇到未知,你们就会被卡主。项目进展顺利时,大部分人要低头拉车,一定要有人抬头看路,作为技术负责人,你就是那个必须要看路的人。

看路的时候,你不能只自己看。带上产品经理,毕竟路都是他指的;带上某些队员,要不然低头拉车久了,缺乏参与感。看路的目的,就是在稳步推进已知的同时,提前探索下一个未知,这样一来,你们会进入一个良性循环。当下一个阶段开始的时候,如果你按照开头说的分开已知和未知,你会发现,有不少东西都有了眉目,团队可以立马撸起袖子干。

迭代未知

我相信上面的几个办法,熟练掌握后,你可以很从容的去处理项目中的未知。但真正的能去拥抱未知,把未知转化成优势,还得在团队上下,培养迭代未知的能力。有未知的项目,就像摸着石头过河,你不知道深浅,就去摸石头,摸完就知道前面可不可以走,需不需要调整方向。普通的人,一小时摸十个,优秀的人,几百个。河都是同一条河,有的人摸索的慢,有的快。

天下武功,唯快不破。什么是快速迭代?从技术层面讲,你们一个程序员从代码提交到功能上线要用多久的时间?你们一天能交付多少次代码?交付完之后有多少原有功能照样好用?如果交付的不好,你们用多长时间修复它?从产品层面讲,有多功能你们不用开发,就能测出来他们是否真的有用?你有多少用户愿意尝试最新鲜出炉的功能并且给你们反馈?

之前的三个办法,可能会因为个别人的努力而得以解决未知带来的困扰,快速迭代的功夫,一天修不来,一个人也修不来,它需要整个组织的努力。这样的组织,一定是一个学习型的组织。