现在遨奇思特流程管理平台的大部分功能趋于稳定，也该写一下产品备忘录了。
遨奇思特看起来又是一个与电影视效行业普遍采用的项目管理软件相差无几的仿品，对此我想说这只是一种对目标用户群体表示友好的策略。
之所以这么命名，是因为遨奇思特是 Orchestra 的中文谐音，事实上乐队既能体现团队协作，也非常需要团队协作。
作为后发产品，我们拒绝了差异化竞争的思路。从写下第一行代码开始就明确了减少短板、扩大优势的目标，这当然会导致开发曲线异常陡峭，项目夭折的可能性也直线上升。所幸现在短板控制住了，优势也可圈可点。
很显然，遨奇思特是站在市场同类产品的肩膀上更进一步探索的成果。产品的每一处细节未必经过深思熟虑（因为还有待更大范围的验证），但一定冒失又狂热地达成了以下两个目标：
一、后端增强了对图式的管理能力，把图式也抽象为实体类型，使得数据驱动的理念贯彻得更加彻底。
二、前端利用最新技术增加了对视效文件（比如 OpenUSD）的支持。
当然还有一些业内还算新鲜的特性，比如使用 OSS 做存储，节点式的工作流编辑器，还有日程图（很快就被竞品发现并跟进了），还有上云，这个稍后讲。
因为要管理图式，就免不了要修改管理关系图的代码，再怎么模块化，螺栓还是要拧的。早期的关系图模型很不成熟，一个实体字段往往会关联多个实体类型，正向反向的问题就成倍放大了；关系增多，性能也大打折扣，早期生成关系图至少需要五分钟（现在只需半秒）；此外早期关系图缺乏测试，逻辑不完备，这条最为致命。这都是进一步实践数据驱动必须踩的坑，解决关系图与图式的问题用了很长时间，这里就不透露了。最后的结果很满意，图式被整合到实体类型中了，简化后的数据模型看起来非常优雅。
数据驱动还涉及到封装接口的问题，接口需要逐一处理鉴权、排序、分组、统计等处理工作，稍作思考就会发现，这类工作和早期 UNIX 的预处理器一样，排队就行。过程会有些波折，但收效颇丰，接口的大部分请求都能快速响应。在组件形成体系且数据模型这个底座足够牢固之后，添加对路由路径（类似 entity.Shot.user.HumanUser.first_name 这样的字段书写语法，用户可以视它为跨表查询）的支持也是水到渠成一蹴而就的事。
前端的更新很频繁，即使攒够一批修改一批，代码提交数还是轻松破千了，值得一提的是审阅页面。审阅页面最初叫媒体页面，后来又改成审核页面，现在终于定名审阅页面，改名的动机大概是同时追求准确的含义和更像是协作的协作关系吧。团队当然希望这个软件能体现一些不同的价值观念，要知道很多 ERP 软件的功能无非是提交、审批、通过，我并不否认这也是一种协作。审阅页面支持多个轨道，用户可以向轨道拖拽 mov 文件、mp4 文件、usd 文件，并通过划屏工具对轨道上的文件对比查看。多轨显然是借用了剪辑软件的概念，但这在竞品中确实是独一无二的，他们一定想不到真的会有人在浏览器上做这么麻烦的事。在我看来浏览器潜力非凡，还有非常大的挖掘价值。如果用户的内存显卡足够强悍，在轨道上播放 usd 动画没有问题。在批注文件、发表看法时，用户还可以用审阅页面提供的工具截图并标注。补充一句，从本地文件夹中向轨道拖拽文件也是支持的。
软件还开源了 Python API 工具，开发了桌面客户端工具。Python API 可以帮助开发者高效管理数据，开发者可以用它架起连接其他软件的桥梁。桌面客户端则提供了管理多套流程配置的机制，目前支持 Nuke、Maya、Houdini、UE。
整个开发过程如同在遍布机关暗道的迷宫中闯关，需要多次试错才能找到可行的开发路线。
聊完开发，也谈谈部署，也就是上云。
不少用户即使本地部署了也会试着从外网访问，这就对内网安全提出了挑战，SSL 证书、防火墙应该是标配，但现实情况并不尽然。服务器中病毒或者数据泄密的代价并不低，所以我从一开始就决定上云，即使短时间内不会被市场接受。云服务商提供了多地机房，团队可以近距离地访问服务，网络延迟的问题就解决了。云服务器本身的安全策略结合系统安全策略，又解决了安全的问题。况且云服务商还提供了网络抗压能力。遨奇思特提供了面向对象存储服务，只允许通过临时加密链接的方式访问，链接超时就会失效，这就保障了文件的安全（当然面向对象存储这一服务也很快就被竞品发现并跟进了），用户不必担心因为给客户发送了一个链接而泄密。
更进一步，上云给团队与团队之间的协作提供了可能，只有在稳定且可信的前提下，这种协作才能实现，这部分功能我们正在开发（同被竞品跟进，摊手）。
企业网络专线非常昂贵，跳板方案延迟高且易被攻击，托管机器的成本同样不低，云方案有着天然的优势。
这篇就说这么多吧，已经1850个字了。
