安装Flarum
1. 安装Composer
1 | php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" |
2. 安装Flarum
1 | composer create-project flarum/flarum . |
3. 设置nginx和URL重写
在nginx站点配置文件中添加root和flarum 配置文件。
1 | root /<Flarum路径>/public |
项目启动会议（kick-off）都干啥
项目启动，英文里叫kick-off，原指足球赛里的“开球”。一旦开球，就表示整个比赛正式开始，双方队员就要在接下来的90分钟里争取进更多的球。我们在平时生活中也经常看到各种启动仪式、开幕式等，都是某种意义上的项目启动大会，只不过对于旁观者公众来说，更多的是被通知。在实际研发项目中，我们并不一定会有多么郑重的启动“仪式”，但是项目启动会议却必不可少。那么，作为项目经理，应该怎么入手来准备项目启动会议呢？
基本思路
在开始相关准备工作之前，项目经理先“自私”一下，问问自己想从启动大会得到什么？再反过来问一下，如果别人收到了启动大会的邀请，他们会有什么疑问，他们想要什么？这两个问题，基本涵盖了启动会议所要准备的主要内容。
问题1：自己需要什么？
问题2：别人想了解什么？
问题1：自己需要什么？
首先，从我们自己出发，问一问自己，为什么要召开项目启动会议？在生活中，大部分时候并没有所谓的项目“启动大会”，那我们是怎么做的？比如我们要在接下来的两个小时内完成一份研究报告，我们会告诉周围的人：“接下来两个小时我要完成研究报告，请尽量不要打扰，谢谢！”。
简单的一句话，就是一个很好的项目启动声明，清晰表达了两个意思：
告诉大家：在接下来的一段时间内我要做xx项目啦
提出请求：希望大家能够给予支持
所以，从项目经理自己的角度，项目启动会议目的也是一样，也是这两个方面：1. 我们的项目要开始了；2. 希望得到相关方面对项目的支持。剩下的，都是为这两点服务，来解答大家心中的各种”为什么”。
问题2：别人想了解什么？
自己的想法已经很明确了，那其他人会怎么想？设想一下，周一早上9点，我们刚到办公室，打开邮箱，弹出一个会议邀请，要求我们在上午10点参加xx项目的启动会议，而我们之前从来没有听说过xx项目。这时，我们会怎么想？很自然，第一反应会在心里问：
xx项目是干什么的？
为什么我被邀请？
如果我们去参加这个项目的启动会议，这就是我们想从会议上得到答案的问题。这两个疑问，一个是关于“事儿（项目）”，一个是关于“人”。那么，作为项目负责人，启动会议的邀请者，我们就需要从这两个基本问题出发来准备启动会议。比如，可以在会议邀请里添加项目简介和被邀请人员名单、角色等，来回答大家的疑问，如果有相关材料，也可以提前附到邀请里一起发出。
步骤和逻辑
明白了自己的诉求和大家可能的疑问，准备启动会议的思路就会清楚很多。大概的内容我们可以简单分为关于“事儿（项目）”和“人（团队）”两部分。关于项目的，主要用来解答大家关于“xx项目是干什么的”之类问题，然后告诉大家项目要启动了；关于人的，就是明确项目团队成员和相关人员在项目中扮演的角色，以便项目能够得到对应的支持。
1 项目及运作方式
要解答大家心中关于项目的疑问，需要我们从项目本身出发，对项目做一个基本的介绍。当然，由于项目仅仅是启动阶段，对于大部分人来说，可能是第一次听说、被加入到项目中，所以对项目的介绍不需要也不应该涉及到过多底层细节。
在启动会议上，对项目的介绍主要集中在下边两点：
1.1 项目简介——明确背景和目标
一些基本的背景介绍，可以帮助解答大家心中的一些初期疑问，比如为什么要做这个项目、出发点是什么、对整个部门、公司意味着什么，等等。这里重要的是从“道”的角度，让大家统一认识到项目的重要性、在组织中所处地位、愿景是什么，这些都是在以后的项目中要始终坚持和强调的“初心”。
有了基本的背景介绍和项目愿景，我们还要清晰说明项目目标。某种意义上来说，这个目标就是长期愿景在项目中的量化表示，所以一定要是具体可见的衡量的。比如我们的长期愿景是在5年内达到行业领先，那在当前项目的目标则是在接下来的1年内实现销售额30%以上的增长。行业领先就比较笼统，但是销售额增长30%就比较具体。
1.2 运作方式——强调特殊性
了解了项目的出发点，也有了明确的项目目标，那这些目标要怎么实现呢？这就要说项目的基本运作模式了。特别是针对开创性的新项目，之前没有类似项目，运作方式将会是大家关注的重点，因为这直接影响到接下来大家怎么参与进来、支持这个项目。当然，如果当前项目要在已经比较成熟的运作框架下运行，这时候，我们需要将关注点转移到针对当前项目的一些特殊点上来，比如这个项目有哪些跟之前不一样的地方，这些都要在项目启动的时候点出。
这里要强调的一点是，运作方式的制定或变化，是以更好地完成项目目标服务的。所以，在说明项目运作方式的时候，要与目标结合起来。我们的每一个步骤、环节，是如何帮助实现最终目标的。落实到实际操作层面，就是有哪些定期和不定期的会议、哪些决策点、哪些申诉渠道、触发条件是什么，等等。
02 团队介绍
经过项目和运作模式的介绍，每个人对整个要做的事儿以及怎么做都有了大概了解。事儿总是要人来做的，那么，在当前原作模式下需要什么样的项目团队设置也就一目了然。整个逻辑也很清楚，为了完成项目目标，我们需要什么样的运作模式；在这种运作模式下，我们的项目团队是什么样的。
项目+目标（干什么） => 运作模式（怎么干） => 团队设置（谁来干）
2.1 核心项目团队
项目团队的各种角色设置，都是建立在现有运作模式的基础上的，其最终目的都是使项目按照设定的运作方式运行，从而实现预定的目标。
所以，项目团队介绍除了基本的团队成员、角色之外，更重要的是每个角色的职责，并且将这些与其在整个运作模式联系起来，明确每个成员、每种角色在模式中的位置，以及他们如何确保项目模式顺利运作并实现设定目标的。
2.2 支持团队
除了直接参与项目工作的核心团队之外，还需要背后的支持团队，或者说是项目团队成员背后的整个研发团队。启动会议的其中一个重要目的，就是获得研发领导对项目的支持。在项目执行过程中会遇到各种困难和问题，很多时候，仅仅依靠现有项目团队成员并不能很好地解决这些问题，这时候我们就需要请求额外的支持。所以，在准备启动会议时，我们要设想以后可能遇到的困难，可能需要的外部支持，或者上级领导的支持，然后在启动会议中提前告知，让对方至少在思想上有所准备。
针对这些支持团队，可以简单说明哪些环节、在什么情况下，可能会需要什么样的支持。凡事预则立，不预则废。也就是平时说的“丑话说在前头”。
03 下一步展望
到这里，我们的启动会议的内容基本解答了上文提出的主要疑问。所有参会者对项目基本情况和目标有了初步了解，清楚了项目的大概运作模式，明白了自己在项目中所处的位置、需要提供哪些支持。这些已经足够我们开始接下来的项目工作。为了接下来工作的开展，在启动会议上可以对下一步的工作做一个展望，特别是一些在启动会议上提出的、还没有确定的问题。
下一步展望可以包括：
关于项目运作模式和项目团队还没有彻底澄清的地方(包括会议上可能新提出的)
接下来关键的项目实施工作
总结
关于如何准备项目启动会议，这里仅仅提供了一个简单的思路和步骤。具体操作层面，还可以参考各种不同类型的kick-off模板，虽然看起来千差万别，但是“万变不离其宗”，这些基本的问题搞清楚了，不管是什么项目，相信你都能轻松“启动”！
吃火锅
下午5点半，开车在小镇的公路上，不远处小山悠然从车窗飘过。离家还有60公里，导航上红红黄黄，提示回去还要差不多1个小时。
“都这个时候了，找个地方吃了饭再回吧！正好躲过返城高峰。今天特别想吃火锅呢”，孩子妈说。
“又吃火锅啊…”我不耐烦回应。
“点评上这家店口碑还不错，就在附近，我看才一公里，我给你导航！”
“好吧” 不知道为什么，这几天我对火锅、烧烤都没兴趣。看女儿提起火锅竟也两眼放光，我也没啥说的。
车子很快就到了来时路过的小镇。镇子很小，旁边就是矮矮的山坡，另一边是零星几块水田，再过去就是国道。整个镇子仿佛就只有横竖这两条街，街边停了不少车子，却很少见有行人。
导航提示已经达到目的地，路边却都是一些建材、五金、杂货店之类的小店铺，一点都不像会有火锅店的样子。
“不会因为疫情已经倒闭了吧…”孩子妈说。
“可能是哦，看着路边的店面，很多都没开门。前边路口掉个头回去吧”我心里暗暗高兴，也省的费口舌了。
车子往前走了几十米，一转头，发现一家类似于小杂货店的门头上写着要找的火锅店的名字。门头很小，躲在旁边正在翻修的一栋房子的高高的脚手架边上。孩子妈下车去问，确认还在营业，我才在路对面路边找了个空位停下车子。
店门是很小的一扇玻璃门。进门左手边一张窄窄的桌子，摆着收款用的二维码扫描机。一把竹编躺椅矮矮地横在桌子旁边，扶手和背靠的地方油光闪亮。右手边桌子上一排摆着香油、蒜泥、麻酱、辣酱、葱末、辣椒粉，水杯一样的小瓷罐，一排掰开。瞄了一眼葱末，小葱切得又大又长，乱乱地躺在罐子里。我自己做饭时切葱，总被说切得太大，这个比我的还长一倍。
整个店里就几张桌子。一张稍微大点的圆桌在最里边角落，几个人已经点好了菜等着吃，旁边是一张小一点的圆桌，一家三口刚到。临马路边的玻璃橱窗边两张长方形桌子还空着，我们挑了靠近门口的小桌。里边一点是放菜品的冷柜，菜品不多，每样数量也很有限，但都用竹签很工整地串起来。细竹签的是素菜，肉荤或者菌菇之类的用粗一点的竹签，然后还有用两根细竹签串起来的，荤素搭配。老板说细竹签六毛，粗竹签一块八，数签结账。
拿好菜，坐下来，一个小伙子就端锅底上来。看着也就20岁多点，穿一件圆领白T恤，下边短裤加小白鞋。上完锅底，开了火旁边呆呆站着，不说话。站了一会儿，就一个人到店门外，找个停在门口的电动车后座斜坐着，往街的尽头望。
除了小伙子，店里还有个胖大姐。身板很是壮实，一双眼睛眯眯地陷入圆圆的脸盘上，看不出表情。不时在店里走来走去，很忙的样子，客人一走就提醒小伙子收拾桌上的碗筷。
火锅吃起来确实很“家常”，有种家里吃饭的感觉。留意了一下周围的客人，店虽然小，但是整个饭点儿一个多小时，陆陆续续几张桌子刚刚坐满，等有客人吃完结账离桌，过几分钟就又有客人进店。都像是拿捏好了时间来吃饭，不用等，店里的桌子也并不闲着。
小伙子收拾桌子不紧不慢，却也不耽误事儿。收拾完又去外边待着，不说话，看着远处。
很快，我们也吃好了，叫小伙子来说要买单。小伙子说了句“好的”，就去找老者，然后过来说让等一会儿，算账的人出去了。这才明白他在说胖大姐。等胖大姐的功夫，小伙子和老者还跑来说实在不好意思，算账的一会儿就回来。
我们也不着急，等着。看到店门口墙上的海边，小虎队、还珠格格、鹿鼎记、神雕侠侣，竟然都认识。墙上挂的小黑板比较有意思，无的东西比有的多，仿佛在告诉你，我们曾经拥有很多…
1 | 单锅 18元 |
不一会儿，见胖大姐从门外进来，一把抓起散在桌子上的竹签，走向门口的收银桌。我正纳闷她为啥还要换个地方数个数，只见她”啪“一下把这些竹签放到一个小称上称重量。
“不用数下吗？”我问。
“不用，称一下就好。每个竹签重量都是定的！”大姐并不看我，在点单的本子上一通乱画，说：“167”。
自始至终，我从她脸上看不到任何表情。
结完账出来，看小伙子还在门口，仍斜靠在门口的电动车上。
我顺着看了看远处的街角，那里并没有什么。
不要急于去打破
事情是这样的。在以往的项目中，出现了因为某个测试工具没有按时完成而影响测试进度、而最终影响交付的经历。于是，项目团队便想把所有功能开发中与这个测试工具相关的工作和问题单独管理起来，一旦出现问题，可以重点跟踪，同时也便于对该测试工具做整体的把控。乍一看貌似很有道理，成立“工作组”，重点问题重点跟踪。但是，跳出来看看呢？
每个软件版本的发布，都包含了一系列新的功能（feature）的引入。在敏捷开发实践流程下，每个新功能由对应的功能开发团队（虚拟的）来端到端负责并最终发布的。每个功能团队对自己的feature全权负责，直至交付客户使用。其中包含软件开发的所有工作，从前期需求澄清、软件设计和实现，再到不同级别的功能、系统测试，其中自然要考虑测试工具的支持，缺一不可，我们才能将这个新功能交付给客户。如果功能团队对交付做出承诺，就需要对每个环节负责到底。
现在，因为以往项目中出现了某个测试工具的问题而导致的功能延迟交付，所以我们吸取教训，跳出功能团队和开发流程，将该工具相关的工作和问题横向管理起来、单独报告，这样做真的要去解决问题？还是说只是想找一个“篮子”，每个功能团队一旦遇到该工具相关的问题，就可以简单地丢到这个篮子里，世界就清净了？每个功能就可以顺利发布了？
另外一种思路就是，既然大部分功能都能正常交付（也使用到了该测试工具），而某些功能却出现了因此而延迟交付的问题，那是不是这些功能团队在实施中缺失了什么？或者忽略了对这些工具的跟踪？这些功能团队应该采取哪些措施来避免类似问题的发生？毕竟，只有每个功能开发团队最清楚自己对这些测试工具的要求。
问题：是流程问题还是执行问题？
这其中有个问题就是，如果在现有流程下遇到了某一个具体的问题，我们是打破当前流程，增加新步骤、新流程，还是说找到根本原因并改进当前流程的问题？或者说，就仅仅是这些团队的执行力度不够的问题。我觉得这取决于遇到问题的影响范围和通用程度。
执行力：流程的执行问题
如果只是个别功能的某些步骤有这些问题，大部分的功能仍然可以按时交付，那可能是这几个功能的对应执行团队在执行中问题。我们可以去分析和挖掘在执行过程中出现了什么问题？是否需要为遇到的特殊场景做流程的微调。
持续改进：对流程的持续优化和改进
如果大量的功能都因为相同的原因（某个模块），那可能是对应的模块出了问题，而不是功能开发流程的问题。这就需要对应的模块就回顾和反思对功能开发的参与方式、重视程度等等，从模块本身的工作流程来改进和优化对于功能开发的支持。同时，也可能需要在单个功能开发的流程和实践中增加对该模块的特殊处理等等。但是大前提并没有改变，功能开发的思维和迭代逻辑仍然不变。
思维转变：研发模式的转变
最坏的情况就是（其实并不坏），新功能开发本身的逻辑已经不满足最新市场需求，我们要换一个不同的维度和视角来重新设计研发模式来保证产品交付。就好比从软件设计、开发、测试的瀑布模式，到现在基于单个可用功能的端到端敏捷开发模式的转变一样。在未来，我们完全有可能转变到另外一个全新的模式。
从优化执行到对流程的持续改进，再到思维模式的变革，这是个递进的过程，看看我们面临的问题属于哪个层面？不要急于去“打破”，尤其是思维和文化，具体问题具体分析!
回答面试中的“大问题”
在面试中，经常会遇到比较“大”而“开放”的问题，比如说怎样才能达到月底的目标？如何才能避免工作中的“甩锅”？等等。这种关于HOW（如何）的问题，如果是自己正好处理或经历过的，自然好说。但如果是不熟悉的领域、或者一些“虚拟”的场景，乍一听会觉得无从下手。有时候甚至会脑子突然空白，不知道说啥，冷场不说，面试的结果也可想而知了。
我们来想想，这种问题之所以让人头疼，其实就是我们平时说的，问题太大，乍一听还比较空，都是一些鸡汤文里经常提到的一些话题。我们不能想鸡汤文一样，说些“只要踏踏实实做好每件事”、“从细节做起”、“保持良好心态”之类的大而无当的鸡汤励志口号。生活中遇到的一些实际问题，每个人都会自然地拆出个步骤一二三步，或ABC部分，然后按步骤、分布去逐个解决。对待面试中遇到这种问题，我们只要按相同的逻辑来思考和回答就可以。
1. 阐述自己对问题的理解，争取更多的思考时间
首先从问题本身出发，就问题进行拆分。
问题：如何避免工作中的“甩锅”？
我们拿到这个问题，先就事论事地对问题中的关键词进行分解，按类别、按步骤等等。
工作“甩锅”（做了不该自己做的事情，努力没有得到认可）
“责任”甩锅（出错误以后，不是自己的问题却被拿来顶罪）
…
2. 按某个维度对问题进行拆解
针对拆分后的几个方面，针对其中一方面，按某个维度来分析可能的解决问题的方法。这个维度可以是时间维度、空间维度、逻辑维度等等。
工作“甩锅”
既然是做了不该做的事情，那我们还可以进一步从事前事后不同角度来看？
事前
是不是可以从工作划分、分配的角度来找原因？工作划分的时候有没有明确各个部分的工作内容、有没有考虑到不同工作之间的关系？分配团队的时候有没有考虑到团队之间的合作？
事后
既然已经做了一些额外的工作，怎么让这部分工作变得“可见”？对自己可见，对团队和组织可见？事情一旦可见，就不存在“甩锅”一说了。
3. 结合自身经历，选择熟悉的方面提出有效、可行的方法和措施
经过第二步的分解，到这里一般已经很轻松地得到一些“显而易见”的措施或步骤。接下来提出具体方法和步骤的关键，在于结合自己以往的工作和项目经历做出取舍。很多时候解决问题的方法和步骤是相似的，大家都知道那个把大象放进冰箱的三个步骤，但是为什么有的人可以放进去，有的人却不行？关键在于对不同步骤的处理和侧重。结合以往的项目，每个人就会有自己的角度。提出来的措施才不至于高高在上而不可落地。
在面试过程中，我们并不需要真的一个一个把所有的方面都挨个说一遍。重在把自己的思路和逻辑说出来，有理有据，找其中最熟悉的，列举一些典型的可操作性的步骤和计划即可。
总结
最后，总结一下，针对这种看起来“大而空”的问题，我们要发挥佛教中的“灭度”精神，按上边提到的“三大步”，所有问题都可以“可操作”、“可回答”。
从阐述对问题本身的理解出发，为自己争取时间；
在阐述的过程中，按某个维度对问题进行拆分；
结合自己以往的工作经历，选择熟悉的方面提出有效、可行的方法和措施；
这种问题，考察的是将事情“落地”的能力，重要的是展示自己的对问题的分析、处理和解决思路。找个问题试试？