【5023】创业团队,撕撕更健康

理想的创业团队,当然是熟识多年,底层价值观相同,方法论、能力互补的一群人,但这群人不会一开始就出现,必然经历『借事修人』到『因人成事』的转化。今天就说说在『借事修人』的阶段,可能出现的问题以及应对方法。

 

不管怎样,事情要开始,总能各种凑齐一个看起来可以开干的团队,如果这点都做不到,那也就确实不要强求继续。大家并不是很熟的时候,做起事来总会一团和气,但过一段时间,每个人都会发现,事实、结果,并没有想象的那么美好。

开始进入频繁撕逼的阶段,大家都在找合适的档口发泄自己的失望和不满,当出现这种情况的时候,就说明有些务虚的事情漏做了。

 

大公司里的专业HR可能会更早意识到,然后提醒业务伙伴,但对于创业团队,只能靠老大自己发现。这里面的原因,是一些底层的东西并没有达成一致,观念冲突,团队信任与理解,知已不知彼,没有默契。

 

大家需要聊聊,在什么场合下聊?

很关键,这是默契的第一步,要找一个大家都很想聊聊的场合,就好比恋爱中的男女,吵过架,一阵沉默,然后一个人说『聊聊吧』,另一个点点头。而不是,某天一起吃饭,一个人很开心各种唠叨,另一个一直沉默,然后突然说『我想和你聊聊』,这就很不默契。

所以,比较和谐的场景是,某天下午,又是一个具体的业务问题,从讨论到开始撕逼,到开始各种上升、各种抽象……错过了晚饭的点儿,有点筋疲力竭的时候,老大问一句『晚上都没事吧?一起去吃饭,我请客』,就是一个不差的开始。

 

非工作时间,非工作地点,更容易敞开。这时候和大家一起聊这样几个方面,每个人要说给其他所有人听。

 

首先,为什么来这个团队?具体到:

每个人的理想,若干年后,希望自己在做什么,稍微落地一点,希望三年后项目如何?

大家可能会从小时候的一些故事说起,然后告诉大家将来想做投资人?想开心理诊所?想开咖啡店?想……可能,大家其实有些共通之处,互相会问问为什么这么想,如果大家说的太像『退休后的生活』,可以稍微往回拉一拉,说说最后一份职业可能是什么?你会发现,不太会有人真的把现在做的事情当成一生的事业,而是一个阶段性的里程碑,所以,可以落地聊聊,希望三年后,如果项目成了,你想象中的样子是什么。

每个人的底线,一年后至少收获了什么?

我是一个过于理性的人,所以不管怎么鸡血,我都会认为,大部分事情是没法达到预期的,除非你预期过低。那么,大家说说自己,如果事情没成,这一年,我们假设给自己设限为一年,底线是『至少收获什么』。也许是能找到一份比现在工资Double的工作,也许是提升了某方面的技能,也许『借事修人』,练出了一支能成事的团队……但,不能一无所获。

 

然后,对团队有什么帮助?我们守住底线,奔着理想去,你在这里,你得让大家知道你是有价值的,大家也需要知道你的价值。

你能做什么?表示过去的能力。

过往做过的事情,表示哪些事情可以比较快的上手,比如会App的渠道运营,会SEO……老大把每个人找来,对每个人相对了解,大家的一些私下聊天也会有,但团队两两之间可能互相并不清楚对方能做什么。

在发挥优势的基础上,没人想一成不变,还需要了解——

你想做什么?表示将来的意愿。

希望在什么方面提升,比如想在线上线下的活动策划上有提升,以便对运营岗位有个更全面的把握,大家可以一起看看和个人的长远目标是否契合。知道对方想要什么,配合起来才更顺畅。

 

继续,看气氛到没到位,到位了可以继续,问题暴露,批评与自我批评。

如果项目失败了,最可能的原因?

比如现在团队实力还不够,没能及时引入合适的人,或者大家成长不够快,使得事情会僵死在一个不好不坏的程度没法突破,甚至,初始的股权结构不合理,到某个阶段可能会让团队散掉……

可以抽离出来以第三方的视角看,最终我们会发现,绝大多数还是人的问题,大家能一起意识到就好。

 

最后,共同提出最多3点务虚层面(非业务本身)的改进方案。

比如决策机制,从原来的『核心团队共同讨论,直到达成一致』到改进后的『核心团队共同讨论,最终某个人拍板,然后执行』。

再如,核心团队每周必须聚餐瞎聊一次,都可以。

 

很多务虚的内容,『是什么』其实不重要,『每个人参与,达成共识』更重要。

 

—————————–

iamsujie,前阿里产品经理,写过《人人都是产品经理》、《淘宝十年产品事》,现在做创业者服务,良仓孵化器创始合伙人,“好产品平台”创始人。更多信息可以扫码关注。

iamsujie的公众号二维码
iamsujie的公众号二维码

【2021】技术人员的Secret Toolbox

之前我们谈到过能让产品经理在技术人员,包括工程师/设计师眼中迅速变Low的事情,其中有一点是“逼着技术团队承诺”,有同学不理解,问:

 

技术负责人对开发时间进行评估,并且给出排期承诺,是必须的吧?

答:我更倾向于认为承诺是传统瀑布模型下的模式,开发明确的任务、技术也成熟,可以提前计算好,但互联网的敏捷模式下,很多时候会做着做着发现坑、做着做着需求有不得已的变化,所以应该技术和产品一起做【预测】,心里想着目标,一起面对变化。最核心的区别,承诺是技术对产品的责任,预测是两边一起承担责任。

 

当然,这里面有个前提,就是技术同学要很靠谱。

 

而更可怕的一点,还没说,那就是容易逼出一系列可怕的大招——

技术人员的Secret Toolbox

技术人员的Secret Toolbox
技术人员的Secret Toolbox

Copy&Paste,不假思索的“复用”,满足当前需求就好,不考虑逻辑的可扩展,比如A和B现在1对1,不考虑将来有可能1对N,即使是业务上已经做出提示的时候;

Hardcode,写死代码,不用配置文件、变量,当你发现某个参数不妥,想要多改几次试试的时候,发现工作量超乎想象,而且怎么都改不干净;

Less Testing,听来一个很搞笑的故事,某位技术同学写完代码做单元测试,第一次没过,百思不得其解,于是再跑一次看看,结果过了,再跑,又过了,于是,就认为第一次是幻觉;

Skip Error Handling,不考虑异常情况,假设用户都是正常使用(当然,在某些情况下,业务方认可的时候确实可以这样做),举个最简单的例子,输入框没有做安全上限的长度控制,用户可以直接把程序搞挂;

Descope,偷摸减需求,不举例了,真的会有,验收的时候产品经理负责,发现了还好,但有时候只验收主要场景是发现不了的;

Less Review,减少设计评审、代码Review等,我们认为强技术可以少评审,但会动用secret toolbox的同学往往并不是很厉害的人物;

No Autotest,无测试自动化,工欲善其事必先利其器,磨刀不误砍柴工,一直不磨刀,整体效率就一直上不去;

……

还有啥招,技术同学不妨自爆……

 

这样做,本次交付的时候,会看着很美,需求都满足了,这时候产品经理还会暗爽——就是要逼吧,你看,逼一逼都做出来了,下次继续……

但往后,做着做着,你会发现整个技术团队越来越不愿意承诺了,承诺的越来越难达到了,经常延期?效率好像越来越低?出活越来越少?那就是因为填坑的时间占比越来越大了。

 

最终有一天,技术Leader面露难色的找到你,说:

“兄弟,业务发展太快了,技术架构跟不上,要重构了”

“啊,要多久”

“两个月,一半的兄弟都要参与”

“不可能,因为……”

“必须重构了,不然说不准什么时候就挂了”

……

熟悉吧,over。

iamsujie 微信公众号二维码
iamsujie 微信公众号二维码