产品设计体会(4006)我们急需靠谱的会议

首先,这篇说的只是正式会议,意味着不是站立会议,或者23个人在座位边、过道上的讨论,而是需要像模像样的找一间会议室的那种。说到这里,你一定有很多苦水想倒了,没错,大家都很痛苦,听到“开会”这两个字头皮都发麻,那么我们来一起看看怎么减少痛苦吧。

首先,明确目的,最最重要,其实做一个会议和做一个产品也是一样的。不要试图在一个会议中解决所有的问题,就算你要连着召集两个参与人大部分相同的会议,我也建议你把它们分开,甚至,更好的做法,合理安排一个会议中的议题,可以让部分人早点走,或者晚点到。依据目的,类似的日常会议一般在15min23个小时不等。

会议前,做好准备工作,资源的确定是小:会议室、投影仪、白板、纸笔、网络等等(视情况而定);人员的确定是大:确认好“必选的和“可选的,不要漏人,也不要叫闲人,把握“大会决定小事,小会决定大事”的原则(“大/小”指的是参会人数,比如全公司的会议,是没法讨论事情的,只能传达信息)。识别出会议的KPKey Person,关键人物),通常是最大的一个或几个老板,提前当面或者电话知会一下,然后发出会议邀请,我们用outlook。而发送时间,我觉得日常会议提前2472小时比较合适,看情况。邀请中需要注明会议的时间、地点、议程,每一项议程的估计时长,并且附上需要讨论的文档初稿,要求大家会前阅读(虽然很少有人能做到,很现实的问题),而对于KP,争取提前与他讨论关键议题,达成一致,叫做“串供”,这会让会上省很多时间和精力。正所谓,要想让会议不流于形式,就要把会议本身变成走走形式

会议中,关键人物,在会前10min左右再次确认。关于迟到问题,其实没法避免,一般等个5min是极限,如果能想出合适的惩罚规则,会比较好。会议要有明确的主持人和记录人,当然可以是同一个人,主持人主要掌握整体时间进度,控制个人发言时间,均衡发言机会,保证议题不走偏;记录人要如实做好记录,特别是“会议决议”与“遗留问题”(详见下一节)。所有事情,尽量在会上达成一致,给出“会议决议”,实在不行的可以作为“遗留问题”。最后,牢记很实用的“所有人提供意见,少数人讨论,一个人拍板”的民主集中原则。

会议后,会议记录最重要。尽量在24小时内邮件发出,收件人是所有参与者,抄送给所有参与者的老板,让老板们看到手下干的活,让大家知道老板们看得到他们干的活。然后给出“时间、地点、主持人、记录人、议程信息”,其实都不关键,关键是“会议决议”“遗留问题”。会议决议就是传达,是会上大家确认过的,写明是谁最终拍板的,其实也是增加他反悔的成本,形成习惯以后,大家才能都清楚决议的严肃性,并且保证后续动作的连贯;遗留问题要描述清楚是什么问题,谁负责解决(一定只能是一个人),这个人承诺解决的时间点。相应讨论过的文档有更新,也应该补充发出(不一定是做邮件附件,我们通常给个wiki永久链接,自己去随时查看最新文档就好了)。

这一套跑下来还有个好处,因为难免会有人到不了会上,这样通过会议前和后的两个邮件,他也可以大概了解到主要情况。

最后还有兴趣的同学,可以看看我写过的几个目的各不相同的会议实例:13小时不等的评审会15min左右的项目Kick Off;半天时间,需要邀约产品用户,提前布置会场,有预算的用户大会

产品设计体会(4005)计划,计划,计划!

312号,连着发了3篇,有人表扬我勤奋,有人批评我为了写而写,我很郁闷,不是因为被批评了(我一直期待在留言里看到不同的声音),而是因为批评的不在点子上,而且表扬的也不在点子上……

所以特别写一篇说明一下,按照职业病的思路,我做事情都是有计划的,我有自己严格但又弹性的写作计划发布计划,这两个计划是相互关联又明确区分的。写作计划类似软件的开发计划,而发布计划类似产品的上市计划,是市场驱动的。

我觉得一篇文章写出来马上就发布,难免会存在一些问题,所以我愿意把它“酿”几个礼拜、甚至几个月,好比软件的测试阶段,在这个过程中,我经常会从侧面发现文章里的一些错误,可以有改正的机会,当然发布后肯定还会有问题,我能力有限,只能尽力。最后在每篇文章发表之前,我还会通读一遍,很像软件的预发布,是最后找bug的机会。而最终的发布时间,大多数文章都是有理由的。

所以什么时候发布文章,并不意味着我是什么时候写的,甚至不意味着我是什么时候发的(用定时发布),比如说我现在就有将近10篇的储备。这样还有一个好处,如果我这段时间工作很忙,就可以发布一些已经写好的文章,尽量保持blog更新的频率不变。

那位同学问:这两个计划有文档么?……我还没那么变态,在脑中而已。

说说这次的3篇:

Ø 1号发《从“2月推广”到一季度KPI,是因为这篇应该在刚到3月的时候发,介绍2月推广计划的那篇也是在21号发的;

Ø 2号发的《TTT培训记录》是因为我计划在2号发的文章里,有到这篇的链接,所以这是个前置任务,其实到底发不发这篇我也犹豫过,确实太密集了,有点“浪费”;

Ø 2号发的《产品经理值得听的13个培训》是早就计划好的3月推广“内容为王”的第一篇主打,每周推一篇,周一发布并转载到各大论坛、网站,周二启动IM群推广、周三逛一遍帖子,顶+回复……都在计划中。

好了,开始拔高,对于一个产品经理来说,在战略目标的指引下,完成可行性分析之后,确定了做不做、做多少、怎么做(用什么策略)之后,就要订计划了,简单的说就是确定:何时做、谁来做。我习惯了,甚至是有强迫症的这样做事,是好是坏,我心里也没谱……

当然,这篇是临时写的,只“酿”了两天,:)

产品设计体会(4004)资源战争与BRD

2008年春。

产品团队刚刚经历了一场公司内部的战争,争夺的是下个月的开发工程师与测试工程师的资源。

先说一下为什么以前没有过这样的战争吧,因为公司原来是按照产品线划分的部门,这样对于某个产品来说,有自己的PD、开发与测试等,下个月要做哪些需求,完全可以在产品经理的层面上决定;而现在公司变成了按职能划分团队,有了统一的产品运营中心(PD和运营)、研发中心(所有开发工程师)、质控中心(所有测试工程师),这样的话,下个月各个产品就都想尽可能多的抢到开发与测试,然而资源总是严重不足的,所以最终做哪些,就必须要上升到几个中心的大老板层面来决定了,而大老板的决策依据就是各个产品经理的pk,对各自产品发展BRDBusiness Requirement Document)的描述,于是,战争爆发了,:)

所以前段时间,大家一起在准备BRD,这就是我们的武器,我们需要尽力说明我们要做的东西的商业价值,才能抢到各种资源,因为在pk之前,全公司的资源需求已经是现有资源的好几倍了……(一般以“人日”来简单估算衡量,有同学说一群人pk简称群p,就是多争取点~~~~~~,呃,很邪恶!)

武器主要包含以下几个部分:项目概述、项目背景、商业价值分析(重点!大老板最感兴趣的,一定要说在点子上)、功能需求描述、其它需求、资源评估(重点2!大老板们要看成本)、风险和对策。大家可能也发现了,其实本质上还是那个词——性价比

当然同学们也会搞点技巧性的东西,比如卖个破绽,故意加入一些让老板砍的东西,有点类似谈判技巧里的玩意。

最后谈一下两种组织架构的各自优缺点,按产品线划分的部门对产品本身是有利的,产品经理可以按照自己的想法做,资源有保证,产品规划不会被动改变,它的缺点也就是按职能分部门的优点;职能部门对全公司的资源共享有利,确保所有资源都用在对公司最有意义的产品上,另外它能把资源战争的鲶鱼效应从产品内部扩大到公司层面,使PD和产品经理们更抓狂的去为产品的发展而苦苦思索……

iamsujie补:

1.     两种组织结构的变化,我的理解是公司自然发展的必然过程,随着产品的增多,全公司变成了越来越多个资源局部最优,他们之间可以互补的资源越来越多,此时全局最优的效益越来越明显,所以打通。

2.     产品线的优势,还有个是沟通的顺畅,单线领导,都向产品经理负责。

3.     更多有关组织结构的讨论,其他篇章里还有描述。