谈谈“强大”。
团队在项目启动之初对业内通行的项目管理软件做了充分的分析，简要表述如下：
首先是距离比较远的 excel。excel 的优点是使用方便快捷，支持多人共同编辑；缺点是跨表查询很麻烦，无法处理海量数据，也不能跟踪全部制作数据。excel 支持 Python 是个好消息，看起来可以融入制作工具链了，但这又忽略了一点，使用 excel 的团队往往不会在开发上投入资源。
数据库如何呢？Qt + 数据库为技术栈的管理工具已经很多了，开源闭源的都有。现代数据库能管理 T 级的数据，Qt 又提供了丰富的组件，在本地安装的特点很容易融入制作工具链。不过采用这种技术选型的工具普遍追求“短平快”，在解决具体问题时也一贯如此，这就为后续扩展埋下了隐患。这类工具对多地协作、跨团队协作没有太好的解决办法，接口也谈不上规范，这都是硬伤。这类工具一般也只能面向个人或小团队。
目前比较主流的产品都采用软件即服务的形式，同时提供本地桌面客户端融入制作工具链，且功能强大、文档丰富、接口稳定。务实地讲，这类软件呈现出一种功能过剩的趋势，不少功能使用频率很低；且后端的技术包袱很重，只能用更多的技巧去解决架构陈旧带来的后续问题，而这些技巧也会随着时间的推移变得冗余、难以维护。还有一些网页端的项目管理软件，这类软件无论技术、架构还是接口风格，都挺老旧的，与主流产品相去甚远，可谓是跨团队协作的天敌了。
前两种方案有先天的缺陷，对重量级项目有心无力，第三种方案有足够好的沉淀，但沉淀本身又成了求新的阻碍。所以如果要造新轮子，那它一定要“更强大，更先进”。
借用硬件的概念，我希望新的软件能够有一个稳定的“内核”，能无差别地对待实体，以及图式、页面、权限等元数据；又有一套粒度合理的"外围组件"（peripheral component），能规范、一致地输入输出数据。
理想中的软件应当有以上特质，它应当诞生于一系列良好的愿望。
这里需要引用 AT&T 对自身使命的陈述，这也是我们团队的动机和目标：
“一套策略，一个系统，普遍服务。”
这种理念在遨奇思特流程管理软件中无处不在：
比如在艺术家提交新版本时，后端的"外围组件"会调用”内核“提供的查询功能，找到审核人员；自动化模块向审核人员发送站内信时，调用的又是”内核“提供的创建功能。在这里”内核“仅提供无差别的基础服务。
在开发者使用 Python API 查询昨天提交的所有版本时，软件云端被视作”内核“，这个”内核“提供的单一接口凝练、强大，足以覆盖来自开发者的各类请求。
在技术指导编写 Bridge（桌面客户端）的 DCC 插件时，Bridge 会提供一个”内核“基类，初始化之后就能管理本地插件、云端流程配置、上下文。在此基础上，使用上下文、模板构造出路径，或者从路径、模板解析出上下文就变得十分简单。更进一步，技术指导可以使用此类功能快速地修改一场镜头，或者一批文件。
在经理使用图表页面查看项目摘要数据时，网页端仅仅是生成摘要请求，最终完成统计任务的仍然是“内核”，且摘要（summary）本身就是”内核“支持的请求方式（request_type）之一。
电影视效制作确实有繁琐的细节，软件不做减法就会变得臃肿。这里的减法不是放弃部分功能，而是理解业务，适当地归纳、合并软件的功能集合。软件简化不足会让用户望而生畏，简化过度又会挤压用户的自由创意空间，我们希望简化能恰到好处，提供给用户的工具集合应当足够凝练且有用。
我们希望产品能足够强大，但强大这一特质的受关注程度不应当排在凝练这一特质的前面。往往当我们谈论兼具的时候，就是在谈论平衡。
我们不希望产品像 SAP 一样包含巨细无遗的模块，也不打算提供 Zapier 一样专业的自动化工具。我们仅仅是提供足以应对制作挑战的工具，重新归纳、整理了电影视效制作领域极为必要的部分。对于新的软件，我们希望它足够适用，又不会对感兴趣的用户造成过多的心智负担。
我们反复锤炼了产品的“内核”，希望它的潜力能远超用户预期，希望它能在面对工序繁重、协作复杂的项目时依然能游刃有余，这才是我们团队想要的那种强大。
