恰你似少年

查尔里西奥又如是说

0%

回去上学第一周,我已经开心到不行了。

倒不是说内容难易,转学 CS 对我来说还是挺难的。爽的部分主要是:我可以实践这几年总结的完整工作流了。上班的时候突发事情多,没法践行,现在环境相对单纯可控,工具们就可以掏出来用了。

简单提几句。图片以后补。

日程管理

这块主要是使用 Fantasticl 结合 OmniFocus。

Fantastical 是一个典型的日历程序,之所以舍弃苹果生态下已经非常好用的日历,原因有几点:

  1. Fantastical 支持在同一个界面里面展示两个时区的实时时间。这样在建立新的日程的时候就会直观很多,不用在心里实时惦记心算了;
  2. 列表模式。Fantastical 会把所有的日程以列表的形式在左侧陈列出来。下一节课是什么时候一眼就能看到;
  3. 在线会议连接。创建日程的时候可以直接贴上会议链接,应用会识别出来,然后在快上课的时候给出一键加入的按钮。不用去课程中心找;
  4. 天气。周视图下会给出临近日期的天气情况;日程列表也会让你知道这个日程开始时大概会是什么天气;
  5. 日历组。比如我女朋友共享给了我一组她的日历,我就可以另外建立一个组。平时只要切换,就能看到她最近的日程安排情况;
  6. blah blah..

GTD 当然还是得 OmniFocus,没得说了。老牌软件,不介绍了。我这边用的最多的是透视功能,会建立一个“下一步”的透视清单,按到期时间列出所有要处理的任务,比如预习、作业啥的。
使用的时候通过苹果的应用 scheme 相互来回跳转,不用花时间到处找,还挺好的。

教材、论文、Slides

教材用 Marginnote,没得说。

论文和Slides相对较短,我会用 LiquidText 来分析重点,完事之后做笔记用。

不说了,好用。

笔记系统和数据库

笔记主要是在用 Obsidian,刚开始用。双向链接感觉良好,整个软件的速度比 notion 快到不知道哪里去了。软件的生态非常棒,插件很多。我最喜欢模板系统,建立Ze什么的新卡片速度很快。

Obsidian 一个优势是所有笔记都是保存在本地的纯文本,这样的话就能很容易的 index 到 DEVONthink 里面。配合 DEVONthink to go,可以在 iPad 和 iPhone 上综合性的检索浏览。当然现在 Obsidian 没有移动端,要在移动端编辑的话目前的方案是使用 IA Writer 直接编辑文本。

其他

不得不说苹果这个软件生态是真的好,配合上 iCloud 基本上指哪打哪(虽然同步做得稀烂)。

其他用的多的还比如番茄工作法,使用的是 Vitamin-R,也是个比较老的软件。不过我用番茄的目的并非番茄本身,主要是一来在早起测算我完成任务的时间,二来监督我定期走动。Vitamin-R 还可以和 OmniFocus 联动,测算时间非常方便。

最近在处理上传 PSD 文件至平台的问题,需要把 psd 里的元素,挨个映射到在线的设计中去。

读取PSD数据都比较简单,有现成的工具像 psd.js psd-tools 之类的开源项目,结合 Adobe 官方的文档说明,基本上没太大问题;但是实现对应功能以及后续的渲染都相对来说比较的麻烦,开源项目解决了一小部分的渲染功能,但是像调整图层、图层样式只能靠自己来处理。

不过,需要考虑的细节点出乎意料的多。

PS里面定位主要是靠左上角的顶点,对于图片、形状来说非常直观。

但是文字框的定位一直有问题,后来发现原因在于文字框左上顶点的坐标并不是和字号&行高的直接相关的 —— 这个顶点的位置其实是文字在四周切边之后的框体位置,并非简单一倍行高时左上角的位置。举个例子,a 和 A 的切边位置就是不一样的。

这个切边后的坐标点位置我们其实是可以进行计算的,只需要结合字体中读取的信息数据来统筹计算,但是由于目前平台对于字体数据的处理缺乏积累,暂时不作那么精细的考虑,可以直接按一倍行高时的位置进行换算。

对于使用 CSS 的平台来说,在行高大于字号时,由于 css 对行高的实现规则,我们还需要减去 CSS 顶部的 half-leading 的数值。

此外文字框由于更换字体导致的换行问题也很多,解决方案相对来说还算容易,系出同源。

PS:当然通过 layer 的顶点位置来做文字框定位是存在很大的问题的,在有旋转或者 skew 操作时更甚;有更精确的方法来处理文字框,但是相对来说要处理的细节也会更多,在此不赘述了。

写在前面:本来是草稿,发现直接发布了… 就这样吧

位图真是个麻烦的东西。你知道一张位图的大部分像素都是无用的,甚至会干扰主次,影响表达。所以你要千方百计的弱化无关紧要的部分,甚至把他们抠掉。

那为什么不一开始就这样做呢?这些多余的像素反而会占用你的磁盘空间,浪费你抹画笔或者抠掉它的时间。

视觉 vs 信息

摄影图片所要表达的是视觉,和我们平日里交流的要传递的信息内容相当的不一样。尽管目前来说很多的信息内容也是依靠摄影图片来表达的。

而我们想传递的形象化、结构化的信息,是完全可以脱离了纯视觉的领域存在的。

数字化表达的核心问题是找到双方都熟悉并且认可的文化基础。但是鉴于文化、成长环境的差异,这套基础大多数时间是很难达成或者得到的,导致人们对形象的认知有差别。

有一个高成本的做法就是回到人的本性,回到纯视觉的领域。这种辨识和表达能力是大师级别的,性价比低,不适合于日常的交流和讨论,而且是非常主观的单方面倾泻信息的。只不过下探的足够底层之后,不需要文化基础也能感受到作者想要传达的内容。

这也是为什么你想在图库里面找一张能完美传达你感受的图片有那么的难,大多数时间你作为一个普通人,发现能用的图也只有那两张。其他的于你,也只是库存的一个数字而已。

所以,有两个方法:

  1. 努力找到双方的共同点;
  2. 加入中间件:请个翻译。

位图的低效性

不是所有人都像 Apple 一样有完美的摄影棚和吹毛求疵的摄影师的。人们沟通的时候也不会特别在意物体打光是不是完美,需要的只是一个意象。位图的成千上万个像素点完全的冗余了。

SVG 这种矢量图是一个相对合适方案,体积小可编辑,后期加上各种属性方便。如果可以的话,我宁愿x所有图片都是 svg 图。况且 svg 嵌入位图也很方便。

CG 图对现实的模拟更是能满足几乎所有人的想象。

什么时候能

Adobe 的 Sensei

Adobe 前两年展示了一套语义笔刷系统,区区几笔就能画出对应的图像。

如果是 CG 图就好了。

抽象 和 具象

模板是做什么的

听觉 vs 信息

嗅觉 vs 信息

我就只是想放个标题在这。乡间的清晨和城市的午夜,两个场景的气味差别之大。

结构信息展示

语义图片

千人千面

大作泛滥的世纪

AI 能代替我们中间最好的艺术家么?

喜欢的风格

有办法通过几个简单的选择来判断用户对于图片的喜好么?p站有给出对应的答案么?

收费策略

目前在线工具类的产品很一致:订阅制,按月或者按年;

这个逻辑很清晰,毕竟服务器要钱的,更新产品养团队也是要钱的。

C 端这个收费策略没什么大问题,但是在 B 端一旦涉及到协作,就有些问题了。

在线工具的优势

协作工具的核心是尽可能的多的把相关内部工作流和人员囊括进来;从我的理解来说,这也是 B 端工具价值的衡量标准之一,判断并尽可能扩张产品的边界。

举个例子,A 同学需要做一张图。

传统流程

传统的流程是 Photoshop 做完图,导出图片,发给 B 同学,B 同学觉得这这这要改一下,然后 A 同学在 Photoshop 里面修改,再发给 B。多次往复。

traditional

在线流程

新的在线协作流程是,A 在协作工具上做了图,通过链接或平台内分享给B,B 标记要改的地方或者直接上手改,A 和 B 一起调整完。

online

整个流程都在工具内部完成,在这个流程中省掉了大量的导出文件、审阅反馈意见、本地版本管理、双方对齐版本的过程。

这个体验相比传统流程来说是非常好的,而且工具平台上能囊括的流程和拉进来的人越多,整个团队的体验越好。

现实中的问题

比如上面提到的简要做图流程,此间有两个角色参与其中:设计师 A 和 审阅人员 B。

A 需要全程的参与整个的设计过程,B 可能只在 A 完成之后进行审阅的工作。在时间上来说 A 可能会有5天的时间来参与,B可能花半天的时间就审阅完了。

换个角度来说,对企业来说,A 账号是充分使用了的,B 账号是多数时间都在闲置的。

而大多数平台会针对账号/席位进行收费,团队需要花钱养这两个账号。这样的话,B账号相对来说就没这么划算了,团队就会纠结要不要花这笔钱。这就和我之前说的尽可能的拉进来人和囊括流程的初衷相抵了。

举个比较现实的例子,创业团队的基础产研团队配比可能是这样的:1设计,1产品,2前端,2后端。设计工具的话至少想要把 设计产品前端这三个职位4个人囊括进来,但是重度使用的其实只有设计一个人。团队为了一个人买4个席位?平时会有3/4的账号是闲置状态的。

“不可能的,我们还是用 Sketch 或者 Photoshop 吧?”

Figma 的按角色收费

所以按角色或者功能来给不同类型的席位进行定价是一个好的选择。

Figma 用能否编辑来划分出了两个角色,普通的用户是免费的,Editor 是收费的。

Figma

这是一个好的策略,非常好的策略。Figma 这么做就尽可能的把团队里面的所有人员都囊括进来了。

设计师、产品、前端、后端都可以参与到 Figma 的平台,养成习惯。随着团队的日常工作拓展,还可能把 CEO、隔壁团队、合作伙伴 等等也拉到 Figma 的平台上(毕竟只查看是免费的)。

有人、有流程就有业务范围横向扩展的可能性。

plus: 固定席位的问题

坦白说,按功能划分角色虽然很讨巧也很不错,但是其实并没有解决之前提到的账号闲置的问题。

举个例子,Figma 现在也有原型功能,产品原型的制作流程也可以放在 Figma 上,但是产品原型阶段很短,大部分时间产品人员的账号还就是闲置的。有些对价格敏感的团队可能就不会把原型阶段的流程放在 Figma 上。

这就会与平台方的初衷相抵了,也不是功能限制能解决的,可能需要在定价策略上下点功夫。

ps1: 举例2 其他团队或者合作伙伴加入到业务流程中的处理。

ps2: Figma 做“产品原型工具”的基础在于它吸引了很多 PM 到平台上。

动态席位

这俩天重新开始看文档协同方面的内容,在看 CRDT 的时候,反复的出现了 serverless,顺便仔细的看了下;btw AWS 的 lambda 已经上线好些年了。

意识到对于工具类的产品是一项挺有意义的技术 —— 按需收费,按使用收费;和电&水一样。如果能按天/小时进行收费,就算单价贵一点,作为一个临时的席位,大多数团队是可以接受的。

动态席位在产品上的意义并不只是给中小团队节省费用,而是促使尽可能多的人员和流程移到平台上。

动态席位的产品形态其实可以有多种:不指定到账号的席位、随开随关的席位、按使用量自动计费的席位等等。后续有时间再探讨。

总结

  1. 协作工具的核心是尽可能的多的把相关内部工作流和人员囊括进来
  2. 编辑席位的价格,对于某些较少进行编辑的角色来说,是不划算而有门槛的;
  3. 需要更灵活动态的定价策略;

hmm…

这篇文字是去年在上一家工作的时候对B端的需求梳理。
彼时一心想做好编辑器功能,对B端需求了然没有兴趣;一些关键需求和技术同学商量后觉得前期准备多工作量大,再加上感觉核心的编辑器功能性还无法支撑顶层的B端需求,所以一直没有做为主要方向推进。

现在已经离开一年,回头看觉得基础逻辑依然没有变化,核心依然是围绕“设计过程“的管理。索性和文字框需求一样发出来,算是对自己有个交代。

有些内容会有变化。

传统设计工具的常见症结

  1. 通过文件系统进行管理。管理的是结果,而不是过程(根源);

  2. 沟通时,需要发送原始文件或导出最终结果(图片/视频),时间长而且对方体验差;

  3. 版本管理通过文件+自定版本号进行,导致管理杂乱;

  4. 用户反馈和设计师修改的周期过长,文字邮件或口头描述往往抽象难以理解,设计过程琐碎不够直观。

    复杂设计往往需要进行反复的调整和修改,导致需要多个周期的迭代,尤其在跨部门或公司的时候由于沟通问题,往往邮件往来的最后得到一个不甚满意或者妥协的结果;

  5. logo、标准色、常用素材的增添补删及相应的团队间同步问题。

  6. 设计资源缺乏沉淀,以往的设计散落在电脑各处(和5 可以归为同一类问题);

线上团队设计工具

就像产品周期管理一样,管理的是设计的整个周期。

设计需求 -> 制作 -> 核实 -> 调整 -> (核实 -> 调整)* n -> 输出内容

线上设计工具的目标就是额外解决 核实 -> 调整 的流程。

线上工具的优势

  1. 易读性:
    设计储存在云端,不需要额外的软件就可以在手机或电脑上第一时间查看。非设计师方体验相当好。

  2. 实时性:

    所有对这个设计的修改都是第一时间反馈到设计本身的。
    除了设计师本身之外,协助修改的同事,查看结果的老板,看到的都是最新的结果,都是(而且应该是)你几秒前对这个文件的修改。

    甚至甲方可以扮演一个云监工的角色。

  3. 可交互性:
    对设计的调整是非常细致的,每个调整都需要配合和沟通。在线直接对结果进行调整,能省下最多的沟通和协调成本。

    在线的沟通方式不限于 直接编辑、评论、聊天、语音等等。(可以借助第三方解决,亦可以给其他相关产品赋能。

  4. 数字资产管理:

    可以专门针对设计本身进行详尽的存档归类。
    查找的时候可以方便的按时间、按热度、按类型、按场景、按标签、按文件夹等等属性进行全面的分类整理等等。

  5. 数字版权内容:
    部分设计工具还能提供设计模板或者版权相关的收费内容。集成到设计工具内,使用更为便捷。

  6. 设计内容沉淀:
    系统自动分析或者用户自己的慢慢积累团队的设计资源。比如品牌颜色、调色盘、排版样式、常用素材、常用模板等等。

在线设计工具的功能要求

  1. 现有数字资产的导入和导出:

    B端已有的设计文件需要导入设计工具内,包括 ps、ai、sketch 等等。而且现阶段设计工具功能性大多无法完全取代 PS、AI 等,因此 psd ai 文件的导入导出也显得重要;

  2. 核心功能:

    在线设计工具需要满足大多数场景下的设计需求,才能保证可用性。

  3. 协作:

    包含多人实时编辑、沟通等等;分享协作链条;

  4. 权限&人员管理

    编辑器权限、设计权限、数字资产权限、功能权限 等等;

  5. 数字资产管理

    除权限外,灵活的内容管理和内容沉淀是保证粘性的重点。

个人与团队

个人和团队是一对多的关系。但是大多数小B场景下,个人和团队其实是一对一的关系。

由于需要沉淀和管理内容,我们需要个人的设计能正确的放置在对应的团队下。从这个角度来说,每个设计都需要从属某个团队。

简单来说:

团队 -> 项目(如果有的话) -> 设计

所以,从我的角度来看,石墨的团队文档组织形式是混乱不堪的。(但是从产品演化的角度来说,也可以理解)

截然不同的商业模式和链条

线上团队设计工具依靠的不仅仅是产品本身。

还有设计过程本身的产品体验管理。

后者尤其对B端来说是一个相当重要的闭环。

不是总结的总结

团队设计工具的核心是面向设计流程的,通过实时协作和在线交流来尝试着解决。

重新强调下,核心其实是 “团队” 和 “设计”,其余的都是次要的;团队的素材、成员/权限、品牌诚然重要,但是都只是加分项。

作为一个B端产品,我们也可以顺便解决设计完成后的问题,虽然沉淀不是大多数团队拥有的好习惯,但是如果真的能好好解决,也算是增加用户粘性的好方法。

真的。

北方的天气,干燥,这也没什么,至少晚上洗的袜子明儿一早就干了。
但是,让人没法接受的是,下雨天们,没有了。

湖北小镇上的下雨天们是一些惬意的日子,诚然,泥泞和扑到身上的小雨点会让人浑身难受,更不论淋湿之后裹在身上散不去的潮湿气息。而且雨季又那么的长,小雨一下就是一两个星期,灰蒙蒙的看不到太阳。

但是,在长久的干燥后,所有的缺点都被抛在脑后,变成了少女脸上可爱的雀斑们。

北方的扬起的灰尘也很无奈,无定所的飘荡,到开了加湿器的房间里面,或者贴在房间窗户上慢慢积累成泥土。这已经比大多数的去处要好了。飘到树上、灌木丛上,勉强有个安身的地方。看起来所有都是灰蒙蒙的,城市里努力种的植物也是。

我一下子就没那么喜欢北京了。下完雨的时候会稍微没那么讨厌一点,但是最多一个晚上,雨还没淋透,就又开始飘满灰尘了,我就又开始讨厌这里了。

抵在窗台上看雨落的日子。得开始找下一步了。

今儿差不多一周年了,挺好。

下午看了阿汤哥的电影,完了把卫生做了。顺便把猫屁股毛剪掉。

hmm…

0. 背景

15年那会,移动支付刚开始普及,滴滴的风正刮着,ofo 摩拜火的一塌糊涂。觉得停车场会是一个细分的流量入口,而且这行玩家其实不太多,抱着一种无产阶级改造产业升级的心态就进去了。

业务本身不难理解,靠平台把线下车场和线上的用户连接起来。首先要解决的是把车场连接到线上的问题。这个事情靠的是OCR的车牌识别,用车牌作用户标识,然后把停车订单等基础数据同步到线上。

以此搭建停车平台,连接和沟通车场方和车主方,通过智能化、信息化的停车设备改造来改善停车的体验。

商业模式也很明确,给车场方赋能,换取用户流量做后续运营。典型应用包括 在线查找车场、支付停车费用、包月用户等等。

尝试了很多途径,前后主要有两部分,面向社会停车场和面向政府的路内车场。

先说社会停车场,也叫封闭车场或者路外车场。

(有道闸围起来收费的就是路外车场,一般由地产/物业公司或者专门的停车管理公司运营;大马路上停车位属于路内车场,所有产权属于政府。)

1. 2016年的社会停车场

1.1 车场的需求

老板:钱。 管理团队:省事。 收费员:别太麻烦。

1.1.1 能满足需求么

能,但是对老板那级不大明显。

原因有几个:1. 市面上案例较少,不愿意做尝鲜者;2. 惯性,现在车场的管理结构已经比较稳定了,不愿意折腾;3. 确实短期内不会有太大的额外收入。

不愿意进行改造的也不只是老板,车场内部的利益分成也会有阻碍。

1.1.2 我们的赋能

a. 业务运营的线上管理:主要包括三个部分,车场运行状态、车辆管理、收费团队的管理。改造完成之后,每一笔订单都可以在线上查看到,包括出入场时间、车牌、照片等等。固定车辆直接在线上平台录入,收费团队的收费记录也完全透明化。堵住了两块收入:1. 线下随便放行车辆导致的费用缺失;2. 收费员私吞的停车费用(管理得好的车场我估计这个费用比例在 5% 左右,但是按一天1万的营收,一年下来其实也能增收15-20万)。

b. 提高进出场效率:车牌即身份,不用发卡或者手工记录了,免去了车主或者收费员额外的交互流程,提高了出入场时间,特别是高峰期非常明显。一般的车辆出场时间大约22秒,装上设备后,临时停车出场时间大约为16秒,固定车辆或者我们的用户3秒。意味着一个小时的峰值从160辆提升的最少220辆。当我们用户数量上去之后提升更明显,能显然的降低人工成本。(其实大多数时间不会满负荷运作,能节省的数额有限)

c. 线上支付的能力:其实这点应该归纳到车场的智能化里面,但是单独拿出来说的原因是现在停车场的线上支付已经成为日常无现金出行的一部分。(15、16年没有那么强的需求)我在呼和浩特的收费岗亭蹲点的时候都能看到有接近3成(4天 ,21点到24点,23/78用户)的用户主动询问能否微信支付(没一个问支付宝的)。

d. 其他:包括降低对收费员素质要求、提升车场形象等等。

1.2 社会停车场场景下的用户

1.2.1 用户的核心需求

无论到哪,核心需求都是快速找到车位。

1.2.2 能满足吗

坦白说,现阶段智慧停车在用户端并不是一个革命性的东西,因为它只能提供一个优化过的停车体验,并没有解决停车问题本身,不能保证每次都有个停车位留给你。或者眼光稍微长远一点,想象你去饭店吃饭,饭店门口下车之后,能自动驾驶的私家车还是要开很远才能停到我们给它安排的车位上。

问题的本质在于,车位其实是稀缺资源。北京现在差不多600万辆车,不到200万的车位,比例才0.3,这个正常比例应该是1.2。而且内环和核心商区潮汐现象明显,需要绕很久才能找到一个车位。

所以,无法保证能解决。

1.2.3 那我们能做什么

a. 告诉用户车场状况。目前该区域/车场有多少剩余车位,起到一个疏导或者引流的作用;对价格敏感的用户还可以筛选车场。

b. 优化过的停车体验。入场时不用停车或者下车取卡,出场时我们的用户直接线上扣费不用停车出场。

*c. 包月停车等定制化的运营服务。

*d. 车场本地的洗车、保养等增值服务。(本质其实是提高车位的附加值。)

*e. 其他与车相关的服务。

/* c d e 都需要和车场深度合作才可以。

1.2.4 谁是我们的用户

理论上,所有停车的人都是我们的用户。因为我们做的是基础设施。

但是核心用户的特征非常明显,周期性在车场/区域停车的临时用户。

他们是我们的种子用户,在车场守着就能看到他们。

1.2.5 如何能快速获取用户

前期获取用户的最快速的途径在车场本地,后面会谈到。

但是如果只有线下的推广,大批量的得到优质用户也是空想。但是因为车场数量少的原因,一直没能以点连成线,导致没能在线上进行推广,非常遗憾。

如果能有机会做这件事情的话,除了现在已经玩出花了的优惠券之外,我想有机会能拿一些车位做一些事件或增值服务的运营。

想过的可能比较好玩事情包括:1. 会员等级,进出场的显示屏和声音有一些特殊的声音或者效果;2. 求助活动:找朋友集赞获得预留车位的使用权;3. 会员积分,比如洗车 etc 顺便验证车场内类似服务的可靠性;4. 类似 foursquare 的 mayor 机制,专用显眼的车位…

1.4 我们遇到的问题

1.4.1 技术

软件平台上的问题随时可以改,硬件上的问题就很麻烦。

特别是识别率的问题,车牌是用户的身份,是连接线下到线上业务的核心。

最早的OCR采用拍照识别,即地磁线圈触发拍摄一张照片然后识别车牌号。号称98%的识别率,其实受到识别环境的影响只有92-94%左右。那就意味着500辆车出入场会有接近50个订单是错的。这是不可容忍的。

16年中后期供应商的技术更新,采用了视频图像识别,一次识别多帧图像然后分析对比,使提高到了 98-99%,意味着500辆出入场的出错订单数降低到了10单左右,加上人工的干预,基本上可以接受。

还有无牌车或者车牌涂抹车辆的处理,目前的技术架构没法很好的处理,只能慢慢的优化。

1.4.2 资金问题

首当其冲的是设备,贵。

价格适中的进出场的设备造价在2-3万左右,还不包括出入口改造的成本。在2015年一般的车场没那么大觉悟投入好几万来做一个对他来说“看起来没什么用处”的系统。所以只得我们前期“送”,对于手头紧的创业公司来说,就是一个大问题。

1.4.3 B端需求多样化

车场本地的施工和调试。车场的需求实在是太多了,历史遗留问题更多。我国人民解决问题讲究一个中庸和平衡,但是这种刀尖上跳舞的状态不是初创公司的人力能解决的。比如说,一个车场,停在场地左边的收费,右手边某个餐馆前的不收费。或者场中场计费规则不按常理来的。这种历史遗留的需求一个没处理好,马上电话就打过来了。

有些需求软件可以解决,但是有些需求你只能慢慢和车场周旋。

1.4.4 冷启动

这是所有 o2o 项目都会遇到的问题,和推荐系统不一样,这种lbs属性明确的 o2o 项目的解决方法很明确,拿车场就意味着拿到用户。原因也明显,车场本身就是需求发生的场所。

前期的获取用户的途径非常集中的分布在线下,一般一个500个车位的车场前一个月能带来不到一百个活跃用户。

2. 对手们

前面提到我们没法解决快速拿车场的问题。大部分对手也没有。

16-17 年挂了一大批做停车的新晋公司,有几家活了下来。

主要是两种:

  1. 物业/地产公司旗下有自己停车场的,不愁没业务;
  2. 自己做硬件生产和解决方案的,就算不做平台,卖方案也可以过很好。

对于我们来说 第2种 亦敌亦友,第1种才是直接竞争对手。

16年我个人第一种的简要分析:

  • 他们的优势:车场资源,可以深入挖掘定制车场服务。自家车场不用担心,可以优先照顾用户端。
  • 他们的劣势:技术团队的节奏要慢;其他公司的车场会有芥蒂而不和他们合作。
  • 我们的机会:利用技术和团队效率优势带来的时间窗口拿下其他车场资源,争取尽可能多的用户;
  • 对我们的威胁:竞争对手产品成型后可能会利用C端用户“倒逼”其他车场和他们合作。

结果其实有点惨淡,问题在我们这边,不谈了。

3.政府的路内车场

所有的路内车场都是政府的。所以来说,跟社会停车场要一家家谈不一样,路内车场跟政府一家谈就行了。

谈下路内车场还有几个优势:

  1. 覆盖广,全市都有路内车位

下次再补。

很奇妙的事情是,梦里是在一个露天的婚礼上,有点像诺兰 08年那部黑暗骑士里面的场景,线条简约厚实的机身带着婚礼的祝词 firmly (脑子里面都是这个词 缓缓 结实 充满了力量感) 的低空掠过。

外形确实传达很多。

昨天晚上看了“美丽人生”,第一次看,前半段差点没看下去,因为父亲有些行为比如偷人帽子这种事实在有点不地道。但是后半段为了孩子所做的事情却因此形成了极大的对比反差。

我一直不理解为什么人们都拼命要给孩子营造一个快乐的童年,反而觉得早点理解社会运行的规则、早点接触社会的残酷面不是会更好么。

可能我童年的精神生活太过贫瘠了吧,没有被平等对待,也没有学着平等对待别人。

然后今天我重新看到尼采这句话:

“He who has a why to live can bear almost any how.”

我自己的问题不在这句话上,但是这句话解释了快乐的童年的意义在哪里。让孩子看到美好的事物,了解美好的事物,激发出他们内心对美好事物的热爱,他们才能热爱生活本身。

我现在做事情并没有考虑到 why 的问题。

让孩子早点接触社会真相的想法本身没错,问题在于边界在哪。哪些是要保护着的,哪些是要展现给他让他学着去热爱的。

引以自勉。