谁适合阅读本文？
CTO、首席工程师、联合创始人或任何负责构建SaaS应用的初创企业的人员。
CHECKLIST
开始
选择一个不是那么时髦但是靠谱的技术
- 专注于能够帮助公司构建产品的技术， 而不是为了追赶热点，和潮流的”Cutting Edge”的技术。
- Dan McKinley :: Choose Boring Technology
在做工作计划的同时， 对工作内容有自己的见解和观点
工具
Github
选择最适合团队的PaaS/IaaS平台
- 最小化开发的工作和尽可能简化部署 > 性价比
选择一个CDN服务来提供静态资源
启动一个Wiki(可以使用github的)
配置一个CI (Continuous Integration)
- 必须通过CI才能合并PR (Pull Request)
- 使用CI来检查代码风格 (Codestyle)
架构
选择一个技术路线
- 选择服务端渲染/客户端渲染
- 选择微服务(Microservice)架构或传统的Monolith架构
选择一个能让团队用起来最方便的框架
用户身份认证和基于策略的访问控制
- 设置MFA/2FA是迟早的事情.
- 可以从基于密码的认证开始， 不过支持SSO是迟早的事情.
创建和管理“Admin” 用户
档开始建模时， 考虑一下最终你需要支持的人群
由于是SaaS， 你非常有可能在未来需要增加自定义域名和子域名的功能， 现在就考虑这个因素
你的营销网站和公司博客会运行在何处
- 如果把营销网站做在产品中， 那么产品将成为营销/增长的瓶颈
- 如果一开始就把应用运行在app.yourdomain.com上， 日后切换或者更换可能会更容易一些。
- 避免使用不带前缀的域名 yourdomain.com， 否则迁移时可能会缺乏灵活性。
需要提供API
使用可重用的代码来配置服务器， 例如Terraform, Ansible
自动化数据库备份， 并定期尝试恢复来检验备份是否有效
维护一个Staging环境
设置并启动监控和配置适合的告警规则
永远不要把生产的数据放到非生产环境上运行
代码
README应描述从头开始设置开发环境的步骤，并始终保持更新
尽早确定并制定代码风格指南
尽早确定并制定测试规范
决定在代码中添加什么样的注释
使用linters来帮助代码标准化，并使每个人都能更好地进行代码Review
制定并记录日志记录的指南和最佳实践
设置并记录异常处理的指导原则和最佳实践
配置Runtime错误异常报告
为性能报告设置实时分析
在数据库级别设置跟踪记录更改的能力，以进行审计或版本管理
定义并制定代码Review的流程和期望值
- How to Do Code Reviews Like a Human (Part One) ·mtlynch.io
- How to Do Code Reviews Like a Human (Part Two) ·mtlynch.io
早期代码在性能/可扩展性成为问题之前不会出现瓶颈问题， 因此要重点关注， 因为一旦出现， 会带来不可避免的灾难。
将开发环境的数据库环境变量放到代码中
团队
汉伦剃刀(Hanlon’s razor)：永远不要将可以用无知/愚蠢/傻缺所能解释的事情归咎于恶意。
向前看并 “招兵买马”
一旦有了至少一名工程师，确定工程级别
设置一个可以试验的结构
质量保证：您需要质量保证的时间比您想象的要早。
当你不再有效地管理团队时，寻找一个比你强10倍的/总监/副总裁。
选择管理还是编写代码。两者兼顾会导致两者都表现不佳。
决定您是否需要组建远程团队，如果需要远程团队，您需要组建哪种 “类型 “的远程团队。
- 远程团队为您提供了一个庞大的人才库，但也面临着独特的管理挑战。如果是远程招聘，则根据技能和自主性进行招聘。
- Managing Remote Teams - A Crash Course | Andreas Klinger
日常执行
站会、Sprint、Review、Milestone
使用简单的 “项目管理 “来保持健康的产品开发节奏，无论您的 “团队 “有多小
团队成员的失败很可能源于您做出（或没有做出）的决定
产品
使用 “Feature Flag“发布新功能，并有选择性地为现有客户启用这些功能。
不要尝试让产品更出色，而要始终关注如何让用户更出色。
从分析和数据的启发中做决定。
报表： 您迟早需要将从数据库中查询到的数据转化为报表功能提供给您的客户。
客户提出的需求通常是合理的, 但是他们建议的解决方案通常是错误的。在权衡 “如何做 “之前，先了解 “为什么”；
切勿仅仅为了一个客户而实施一项功能；这将在未来对您造成更大的伤害，而不是在短期内对您有所帮助。
- 付费/赞助功能除外，应将维护和支持考虑在内
在开始构建功能之前，确保现有客户需要该功能
- 潜在客户总是 “望梅止渴”，而 “多一个功能 “却很少能吸引到客户。选择许多潜在客户需要的功能，而不仅仅是少数几个。
对您的产品有一个愿景，并为之努力。因为功能不符合您的愿景而丢失客户短期会很痛苦，但从长远来看会有回报。
以 “简单 “的产品为目标。简单并不容易，但却是您的客户和用户所需要的。产品的工艺就是做艰苦的工作，弄清产品的复杂性，使您的客户能够简单地使用它。
支持深度链接；您的用户和支持人员将感谢您
技术支持
尽早实现Admin portal
为确保应用程序的 “健康”，启用一个展示服务状态的页面
为Admin提供 “Impersonate “功能(使用用户的身份登录)，帮助他们体验客户正在经历的事情。
工程师轮流提供支持，以建立同理心，这意味着您和其他联合创始人也是如此。
尽早建立服务/产品支持工单系统
定义明确的产品支持时间表并将其传达给您的客户；与您的支持人员一起严格执行这些时间表， 早期您可能无需考虑24x7， 但是当规模变大后， 您可能还需要考虑来自不同时区的客户。
那些 “提出 “24x7支持的客户需要为此支付额外费用。
尽早定义并记录支持的操作系统、浏览器和平台，
- Can I use... Support tables for HTML5, CSS3, etc 是您的朋友
- 如果您计划支持IE，请确保您和您的团队能够测试和调试IE中的错误。
在应用程序中为Admin用户（授权用户）设置只读的SQL查询界面，并阻止使用外部客户端
安全
SaaS首席技术官安全检查清单
准备一套与企业客户共享的资产
为你的框架运行静态代码分析安全工具
尽早研究第三方笔测试和代码审计服务/工具
实施漏洞奖励计划
合规性
熟悉您所在行业的合规标准
尽早为公司获得行业前三名的合规证书
杂项
找到指导他人的方法（公司内部或外部）
加入一个由CTO、工程师、技术领袖组成的社区，与他们分享知识。
在日常工作中，平衡史诗任务和小Backlog/Bug修复之间的关系
使用邮件组来提供所有对外的沟通和服务， 例如support@youcompany.com
- 使用密码管理器的共享功能，确保访问权限不依赖于您个人
用公司信用卡支付所有第三方平台/服务的费用
- 如果使用个人的信用卡, 角色变更、收购、注销信用卡等都可能使这一操作变得麻烦。
2380
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
