一思二想

在实际软件项目中，我们会遇到各种问题，开发延期、测试被问题阻塞、软件实现与客户需求不匹配，等等。特别是一些棘手的技术问题，问题本身在技术或者复杂性上很难解决，再加上软硬件资源的限制、紧迫的时间压力等等，我们一下子会觉得无从下手。这时候就需要我们“回到初心”，跳出问题本身，来想想我们解决这个问题的目的是什么？有没有其他途径可以同样达到同样的目的？带点儿“功利心”去看问题。

对于技术问题，问题本身的目的可能很明确，可能是提高某个软件模块的性能指标、降低某个硬件模块的能耗等等。这些首先需要技术专家去从技术方案上来解决，另一方面，从项目管理的角度来说，作为项目经理，我们可以多问几个为什么，进而发掘问题背后更大的“动机”。比如我们解决这个问题的目的是什么？是为了给客户提供更好的使用体验？是减少整个系统的能耗？那么，从项目上来说，我们有什么手段可以达到相同的目的？这种“功利心”可以有效帮助我们回到初心、明确方向，而不是为了解决问题而解决问题。

一方面，我们可以将目光看长远一点，如果问题针对的是一周，那我们就放眼一个月，如果是一个月，就放眼看一下三个月后的目标。这可以使我们在一个更长的时间维度来重新审视问题，问题的解决就会有更多的可能性。

另一方面，就是站在更高的维度去重新审视问题。在一张白纸上画两个点，我们都知道，两点之间的最短距离就是连接两点的直线的长度。但是，这只是从二维的角度来看。如果我们从更高维度去来看项目中的问题，就好比从三维的角度去看待二维空间里的问题，问题本身就会遭受“降维打击”。更高的维度，我们有时候会说成是“上帝视角”，在项目中，就需要我们经常跳出问题本身，以局外人的角度重新观察当前的问题，让自己做一次“上帝”，有了清晰的思路以后，再跳入进去，如此往复。这就好比从三维世界来看待二维白纸上的那两个点，解决问题的思路也会豁然开朗。

所以，对问题的认识和理解，不仅要“功利”地去挖掘问题背后的目标和利益，而且还要从更大的时空维度来看待我们解决问题和目标。

项目需求是指在软件开发过程中，为满足业务需要而提出的对系统性能、功能及其他特性的需求说明。项目需求的充分准确地表述对软件的开发和后期维护有着至关重要的作用。不仅如此，项目需求还对用户体验、软件质量以及对外竞争力等方面都有着重要影响。

然而，在软件开发过程中，存在一种情况，就是项目需求的遗漏。项目需求的遗漏会给软件开发带来什么影响？如何避免项目需求的遗漏？下面我将从这两个角度分别进行阐述。

首先，项目需求遗漏所带来的影响是非常明显的。一方面，项目需求的遗漏容易导致软件的缺陷出现在软件测试的后期，从而导致软件项目的进度延迟。另一方面，在软件的发布后，如果用户对软件原有功能的表达需求没有被考虑到，那么软件的使用体验便会受到影响，进而影响到软件的市场反响。除此之外，项目需求的遗漏还可能使得软件在后期维护过程中变得更加困难和复杂，从而增加维护成本以及减缓软件的更新速度。

那么如何避免项目需求的遗漏呢？与其说是避免项目需求的遗漏，不如说是在项目需求管理中充分考虑各个环节的配合和把控。

1. 需求收集时尽可能全面：在项目启动初期的需求收集阶段，应该尽可能全面地收集用户需求，甚至可以多找几个用户来进行面谈，以确保所有的需求都被考虑到。

2. 需求审查：需求审查是严格把控要求的一种方式，审查过的需求更容易被发现。组织需求审查小组，让多个人来评审项目需求的完备性和准确性，以确保需求被充分审查，它的质量更高。

3. 反复确认需求：在整个开发过程中，需求不断变化，因此要及时反馈和确认需求变更，确保最新的需求一直被跟踪和纳入设计中。

4. 开发过程中及时发现遗漏：开发人员在进行软件开发时，应该定期检查需求文档和设计文档，尽早发现需求遗漏并及时确认。

5. 客户反馈：软件发布后，客户反馈也可以督促开发人员及时发现需求遗漏，并尽快纠正。

总之，项目需求的遗漏会对软件的开发和维护造成非常严重的影响。因此，在软件设计的初期，应该全面、准确地收集、分析、充分考虑用户需求，保证设计出的软件全部能够满足用户的需求。同时，需要各角色之间的配合和协作，确保需求信息的有效传递和反馈，避免因为信息遗漏而影响项目的实施。

原文： https://mp.weixin.qq.com/s/eYkXt28QMSw0Bi1BDUHU6A

1. 安装Composer

1
2
3
4

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === '55ce33d7678c5a611085589f1f3ddf8b3c52d662cd01d4ba75c0ee0459970c2200a51f492d557530c71c15d8dba01eae') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"

2. 安装Flarum

1

composer create-project flarum/flarum . 

3. 设置nginx和URL重写

在nginx站点配置文件中添加root和flarum 配置文件。

1
2

root /<Flarum路径>/public
include /<Flarum 路径>/.nginx.conf;

4. 安装Flarum

项目启动，英文里叫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模板，虽然看起来千差万别，但是“万变不离其宗”，这些基本的问题搞清楚了，不管是什么项目，相信你都能轻松“启动”！

原文：https://mp.weixin.qq.com/s/bnbGKgRm1ts8feEDRCxHkA

下午5点半，开车在小镇的公路上，不远处小山悠然从车窗飘过。离家还有60公里，导航上红红黄黄，提示回去还要差不多1个小时。

“都这个时候了，找个地方吃了饭再回吧！正好躲过返城高峰。今天特别想吃火锅呢”，孩子妈说。

“又吃火锅啊…”我不耐烦回应。

“点评上这家店口碑还不错，就在附近，我看才一公里，我给你导航！”

“好吧” 不知道为什么，这几天我对火锅、烧烤都没兴趣。看女儿提起火锅竟也两眼放光，我也没啥说的。

车子很快就到了来时路过的小镇。镇子很小，旁边就是矮矮的山坡，另一边是零星几块水田，再过去就是国道。整个镇子仿佛就只有横竖这两条街，街边停了不少车子，却很少见有行人。

导航提示已经达到目的地，路边却都是一些建材、五金、杂货店之类的小店铺，一点都不像会有火锅店的样子。

“不会因为疫情已经倒闭了吧…”孩子妈说。

“可能是哦，看着路边的店面，很多都没开门。前边路口掉个头回去吧”我心里暗暗高兴，也省的费口舌了。

车子往前走了几十米，一转头，发现一家类似于小杂货店的门头上写着要找的火锅店的名字。门头很小，躲在旁边正在翻修的一栋房子的高高的脚手架边上。孩子妈下车去问，确认还在营业，我才在路对面路边找了个空位停下车子。

店门是很小的一扇玻璃门。进门左手边一张窄窄的桌子，摆着收款用的二维码扫描机。一把竹编躺椅矮矮地横在桌子旁边，扶手和背靠的地方油光闪亮。右手边桌子上一排摆着香油、蒜泥、麻酱、辣酱、葱末、辣椒粉，水杯一样的小瓷罐，一排掰开。瞄了一眼葱末，小葱切得又大又长，乱乱地躺在罐子里。我自己做饭时切葱，总被说切得太大，这个比我的还长一倍。

整个店里就几张桌子。一张稍微大点的圆桌在最里边角落，几个人已经点好了菜等着吃，旁边是一张小一点的圆桌，一家三口刚到。临马路边的玻璃橱窗边两张长方形桌子还空着，我们挑了靠近门口的小桌。里边一点是放菜品的冷柜，菜品不多，每样数量也很有限，但都用竹签很工整地串起来。细竹签的是素菜，肉荤或者菌菇之类的用粗一点的竹签，然后还有用两根细竹签串起来的，荤素搭配。老板说细竹签六毛，粗竹签一块八，数签结账。

拿好菜，坐下来，一个小伙子就端锅底上来。看着也就20岁多点，穿一件圆领白T恤，下边短裤加小白鞋。上完锅底，开了火旁边呆呆站着，不说话。站了一会儿，就一个人到店门外，找个停在门口的电动车后座斜坐着，往街的尽头望。

除了小伙子，店里还有个胖大姐。身板很是壮实，一双眼睛眯眯地陷入圆圆的脸盘上，看不出表情。不时在店里走来走去，很忙的样子，客人一走就提醒小伙子收拾桌上的碗筷。

火锅吃起来确实很“家常”，有种家里吃饭的感觉。留意了一下周围的客人，店虽然小，但是整个饭点儿一个多小时，陆陆续续几张桌子刚刚坐满，等有客人吃完结账离桌，过几分钟就又有客人进店。都像是拿捏好了时间来吃饭，不用等，店里的桌子也并不闲着。

小伙子收拾桌子不紧不慢，却也不耽误事儿。收拾完又去外边待着，不说话，看着远处。

很快，我们也吃好了，叫小伙子来说要买单。小伙子说了句“好的”，就去找老者，然后过来说让等一会儿，算账的人出去了。这才明白他在说胖大姐。等胖大姐的功夫，小伙子和老者还跑来说实在不好意思，算账的一会儿就回来。

我们也不着急，等着。看到店门口墙上的海边，小虎队、还珠格格、鹿鼎记、神雕侠侣，竟然都认识。墙上挂的小黑板比较有意思，无的东西比有的多，仿佛在告诉你，我们曾经拥有很多…

1
2
3
4
5
6

单锅 18元
鸳鸯锅28元
无 龙虾 98元3斤
无 牛蛙锅（辣）2斤牛蛙+4烫菜
无 牛肉锅 58元/斤 雪花牛肉
无 小吃：红糖糍粑，小酥肉……

不一会儿，见胖大姐从门外进来，一把抓起散在桌子上的竹签，走向门口的收银桌。我正纳闷她为啥还要换个地方数个数，只见她”啪“一下把这些竹签放到一个小称上称重量。

“不用数下吗？”我问。

“不用，称一下就好。每个竹签重量都是定的！”大姐并不看我，在点单的本子上一通乱画，说：“167”。

自始至终，我从她脸上看不到任何表情。

结完账出来，看小伙子还在门口，仍斜靠在门口的电动车上。

我顺着看了看远处的街角，那里并没有什么。

原文：https://mp.weixin.qq.com/s/LywOkgOaheqzL5UeZYve7Q