├── .gitignore ├── README.md ├── SUMMARY.md ├── assets └── import.png ├── chapter-0-preface └── README.md ├── chapter-1-product-design-sprint ├── introduction.md ├── phase-0-prepare.md ├── phase-1-understand.md ├── phase-2-diverge.md ├── phase-3-converge.md ├── phase-4-prototype.md └── phase-5-test-and-learn.md ├── chapter-2-choose-platforms ├── mobile-refers-to-the-user-not-the-device.md ├── native-matters-on-mobile-devices.md └── rails-gets-web-products-to-market-quickly.md ├── chapter-3-laptop-setup ├── automate-your-development-environment.md ├── share-configuration-with-dotfiles.md └── use-an-extensible-editor.md ├── chapter-4-planning ├── adapt-process-to-the-products-needs.md ├── daily-standups-build-trust.md ├── in-person-communication.md ├── manage-priorities-with-a-lightweight-process.md ├── meet-weekly-to-discuss-successes-failures-and-plans.md └── working-remotely.md ├── chapter-5-designing ├── always-carry-a-sketchbook.md ├── test-product-viability-and-usability.md ├── what-is-interaction-design.md ├── what-is-user-interface-design.md ├── what-is-visual-design.md └── wireframing-in-html-and-css.md ├── chapter-6-developing ├── acceptance-tests.md ├── code-reviews.md ├── continuous-integration.md ├── pair-programming.md ├── refactoring.md ├── style-guide.md ├── test-driven-development.md └── version-control.md ├── chapter-7-production ├── domain-names-and-dns.md ├── error-tracking.md ├── hosting.md ├── log-collection.md ├── payment-processing.md ├── performance-monitoring.md ├── production-checklist.md ├── ssl-certificates.md └── transactional-email.md ├── chapter-8-measuring ├── aarrr.md ├── ab-testing.md ├── feature-flags.md ├── instrumentation.md └── subscription-metrics.md └── chapter-9-our-company ├── hiring.md ├── operations.md ├── principles.md ├── sales.md ├── sharing.md └── time.md /.gitignore: -------------------------------------------------------------------------------- 1 | _book/ 2 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Playbook 中文版序 2 | 3 | 事情要从beansmile说起。 4 | 5 | 2010年的时候，两个Ruby粉Leon和Rain走到了一起，创建了一个叫做[beansmile](http://www.beansmile.com/) 的团队。7年过去了，他们变成了下图中的模样： 6 | 7 | ![alt](http://beantalk.net/static/upload/201610/S8XRUkrMmvzk1BhEZFamBzRY.jpg) 8 | 9 | 在这几年里，我们和小伙伴们为北美、欧洲和澳洲的客户完成了电商、社交、媒体、数据可视化、移动App等上百个项目，近两年也开始和国内的一些优秀的创业者们一起合作，共同打造有价值的产品。 10 | 11 | 在完成商业项目的同时，我们也始终不忘初心，不断总结和分享我们在技术、团队、创业等方面的所思所想，我们的[团队Blog](http://www.beansmile.com/blog)积累了很多各种类型的文章，同时我们也在GZRuby、珠三角技术沙龙、RubyConf China、还有RubyConf Taiwan等等技术大会上进行分享。 12 | 13 | 随着团队的不断成长，我们也在系统地总结自己在开发、团队、业务拓展、团队建设等等方面的经验和教训。这时我们发现在地球另一端的一个团队，比我们走得更早，走得更远。他们非常完整地总结了一个现代化的咨询外包团队应该如何高效、高质量地完成客户项目，如何打造自己的产品，如何招揽和自己团队气味相投的成员，并非常大方地分享了出来，这就是[thoughtbot](https://thoughtbot.com/)公司和他们的《[Playbook](https://thoughtbot.com/playbook)》。 14 | 15 | ![](/assets/import.png) 16 | 17 | Playbook字面上是一个体育术语，是一个球队的战术手册，它也非常形象地概括了本书的内容，它不是教条，而是一本鲜活的战术手册，他不仅可以用来学习，更适合用来指导实战。 18 | 19 | 在欣赏之余，我们[beansmile](http://www.beansmile.com/) 团队在征得thoughtbot同意的情况下将这本手册翻译成了中文，并采用同样的开源方式发布到Gitbook，希望有更多的人能够读到这本小册子，并从中受益。也欢迎大家对翻译中有不周到的地方提出批评指正，我们一起提升国内开发社区的水平。 20 | 21 | -------------------------------------------------------------------------------- /SUMMARY.md: -------------------------------------------------------------------------------- 1 | # SUMMARY 2 | 3 | * [中文版序](README.md) 4 | * [这是我们的playbook](chapter-0-preface/README.md) 5 | * [产品设计 Sprint](chapter-1-product-design-sprint/README.md) 6 | - [介绍产品设计Sprint](chapter-1-product-design-sprint/introduction.md) 7 | - [阶段 0：准备](chapter-1-product-design-sprint/phase-0-prepare.md) 8 | - [阶段 1：理解](chapter-1-product-design-sprint/phase-1-understand.md) 9 | - [阶段 2：发散](chapter-1-product-design-sprint/phase-2-diverge.md) 10 | - [阶段 3：汇聚](chapter-1-product-design-sprint/phase-3-converge.md) 11 | - [阶段 4：原型](chapter-1-product-design-sprint/phase-4-prototype.md) 12 | - [阶段 5：测试和了解](chapter-1-product-design-sprint/phase-5-test-and-learn.md) 13 | * 选择平台 14 | - [「移动」是指用户，而不是设备](chapter-2-choose-platforms/mobile-refers-to-the-user-not-the-device.md) 15 | - [在移动设备上原生编程至关重要](chapter-2-choose-platforms/native-matters-on-mobile-devices.md) 16 | - [Rails 可使 web 产品快速推向市场](chapter-2-choose-platforms/rails-gets-web-products-to-market-quickly.md) 17 | * 笔记本设置 18 | - [自动化你的开发环境](chapter-3-laptop-setup/automate-your-development-environment.md) 19 | - [使用 dotfiles 分享设置](chapter-3-laptop-setup/share-configuration-with-dotfiles.md) 20 | - [使用可扩展的编辑器](chapter-3-laptop-setup/use-an-extensible-editor.md) 21 | * 计划 22 | - [流程要因产品和团队而定](chapter-4-planning/adapt-process-to-the-products-needs.md) 23 | - [每日站立会议可以建立信任和保持冲劲](chapter-4-planning/daily-standups-build-trust.md) 24 | - [没有比当面沟通更有效的沟通方式](chapter-4-planning/in-person-communication.md) 25 | - [使用轻量级程序来管理任务优先级并可视化流程](chapter-4-planning/manage-priorities-with-a-lightweight-process.md) 26 | - [每周碰面讨论成果、错误和未来计划](chapter-4-planning/meet-weekly-to-discuss-successes-failures-and-plans.md) 27 | - [一个高效的远程团队不是偶然的产物](chapter-4-planning/working-remotely.md) 28 | * 设计 29 | - [总是带着个速写板](chapter-5-designing/always-carry-a-sketchbook.md) 30 | - [测试产品的可行性和可用性](chapter-5-designing/test-product-viability-and-usability.md) 31 | - [什么是交互设计？](chapter-5-designing/what-is-interaction-design.md) 32 | - [什么是用户界面设计？](chapter-5-designing/what-is-user-interface-design.md) 33 | - [什么是视觉设计？](chapter-5-designing/what-is-visual-design.md) 34 | - [使用 HTML 和 CSS 做线框图](chapter-5-designing/wireframing-in-html-and-css.md) 35 | * 开发 36 | - [验收测试](chapter-6-developing/acceptance-tests.md) 37 | - [代码审查](chapter-6-developing/code-reviews.md) 38 | - [持续集成](chapter-6-developing/continuous-integration.md) 39 | - [结对编程](chapter-6-developing/pair-programming.md) 40 | - [重构](chapter-6-developing/refactoring.md) 41 | - [代码风格](chapter-6-developing/style-guide.md) 42 | - [测试驱动开发](chapter-6-developing/test-driven-development.md) 43 | - [版本管理](chapter-6-developing/version-control.md) 44 | * 生产环境 45 | - [域名和 DNS](chapter-7-production/domain-names-and-dns.md) 46 | - [错误追踪](chapter-7-production/error-tracking.md) 47 | - [主机托管](chapter-7-production/hosting.md) 48 | - [日志收集](chapter-7-production/log-collection.md) 49 | - [交易处理](chapter-7-production/payment-processing.md) 50 | - [性能监控](chapter-7-production/performance-monitoring.md) 51 | - [生产环境检查清单](chapter-7-production/production-checklist.md) 52 | - [SSL 证书](chapter-7-production/ssl-certificates.md) 53 | - [事务性邮件](chapter-7-production/transactional-email.md) 54 | * 度量 55 | - [AARRR 框架](chapter-8-measuring/aarrr.md) 56 | - [A/B 测试](chapter-8-measuring/ab-testing.md) 57 | - [功能旗标](chapter-8-measuring/feature-flags.md) 58 | - [测量](chapter-8-measuring/instrumentation.md) 59 | - [订阅指标](chapter-8-measuring/subscription-metrics.md) 60 | * 我们的公司 61 | - [招聘](chapter-9-our-company/hiring.md) 62 | - [运营](chapter-9-our-company/operations.md) 63 | - [原则](chapter-9-our-company/principles.md) 64 | - [营销](chapter-9-our-company/sales.md) 65 | - [分享](chapter-9-our-company/sharing.md) 66 | - [时间](chapter-9-our-company/time.md) 67 | -------------------------------------------------------------------------------- /assets/import.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/beansmile/playbook-cn/baa7aac2e7d1b74f9a57893c7dad3c3161e29af6/assets/import.png -------------------------------------------------------------------------------- /chapter-0-preface/README.md: -------------------------------------------------------------------------------- 1 | # 这是我们的playbook 2 | 3 | **我们和各种规模的团队合作，在 iOS、Android 和 Web 平台上设计、开发并推广他们的产品。** 4 | 5 | **这是我们的 playbook** 6 | 7 | 我们是 [thoughtbot](https://thoughtbot.com/)。我们和世界各地的上百个产品团队合作过，他们中既有自筹资金的个人创业者，也有庞大的跨国公司。我们也创建了自己的产品，同时有若干个开源项目。 8 | 9 | 这是我们的 playbook。它详细解释了我们是如何创建成功的 web 和移动产品，以及如何运营公司。书中充满了我们自身的经验以及研究其他团队的心得。 10 | 11 | 这是一份未定稿的文档，thoughtbot 中的每一位成员都可以在一个私有 GitHub 仓库中编辑它。 12 | 13 | 我们使用 Creative Commons Attribution-NonCommercial 协议来发布这份文档，你可以学习或者在自己的公司运用我们的策略。虽然这些策略对我们有用，但是哪些工具和技术适合你自己的情况，相信你比我们更清楚。 14 | 15 | **产品设计 Sprint** 16 | 17 | 我们的项目从便签纸和草图，到最终落实到代码实现的整个过程中，都是以设计为导向的。我们使用设计 Sprint 和用户调查来理解我们客户的问题，验证产品假设，构建以用户为中心的产品。 18 | 19 | - [产品设计 Sprints 概述](chapter-1-product-design-sprint/introduction.md) 20 | - [阶段 0：准备](chapter-1-product-design-sprint/phase-0-prepare.md) 21 | - [阶段 1：理解](chapter-1-product-design-sprint/phase-1-understand.md) 22 | - [阶段 2：发散](chapter-1-product-design-sprint/phase-2-diverge.md) 23 | - [阶段 3：汇聚](chapter-1-product-design-sprint/phase-3-converge.md) 24 | - [阶段 4：原型](chapter-1-product-design-sprint/phase-4-prototype.md) 25 | - [阶段 5：测试和反馈](chapter-1-product-design-sprint/phase-5-test-and-learn.md) 26 | 27 | **选择平台** 28 | 29 | 在产品的早期阶段，我们必须确定要使用的平台。选择哪个平台取决于我们解决用户问题的方案。除了考虑对用户而言是最好之外，我们认为最佳的工具还需要有一个活跃的社区，让我们乐于使用，并且有助于创建产品然后快速迭代。 30 | 31 | - [「移动」是指用户，而非设备](chapter-2-choose-platforms/mobile-refers-to-the-user-not-the-device.md) 32 | - [在移动设备上原生编程至关重要](chapter-2-native-matters-on-mobile-devices.md) 33 | - [Rails 可使 web 产品快速推向市场](chapter-2-choose-platforms/rails-gets-web-products-to-market-quickly.md) 34 | 35 | **笔记本设置** 36 | 37 | 你的笔记本就是你的剑。不要打没准备的仗。 38 | 39 | - [自动化你的开发环境](chapter-3-laptop-setup/automate-your-development-environment.md) 40 | - [使用 dotfiles 共享笔记本设置](chapter-3-laptop-setup/share-configuration-with-dotfiles.md) 41 | - [使用可扩展的编辑器](chapter-3-laptop-setup/use-an-extensible-editor.md) 42 | 43 | **计划** 44 | 45 | 我们工作流程的一个主要目标是持续发布可以工作的小版本。我们通过频繁沟通和每周迭代来完成产品开发计划。 46 | 47 | - [流程要因产品和团队而定](chapter-4-planning/adapt-process-to-the-products-needs.md) 48 | - [每日站立会议可以建立信任和保持冲劲](chapter-4-planning/daily-standups-build-trust.md) 49 | - [没有比当面沟通更有效的沟通方式](chapter-4-planning/in-person-communication.md) 50 | - [使用轻量级程序来管理任务优先级并可视化流程](chapter-4-planning/manage-priorities-with-a-lightweight-process.md) 51 | - [每周碰面讨论成果、错误和未来计划](chapter-4-planning/meet-weekly-to-discuss-successes-failures-and-plans.md) 52 | - [一个高效的远程团队不是偶然的产物](chapter-4-planning/working-remotely.md) 53 | 54 | **设计** 55 | 56 | 我们的项目常常是快速变动的。设计师要采用合适的工具和流程来应对这种情况。 57 | 58 | - [总是携带速写本](chapter-5-designing/always-carry-a-sketchbook.md) 59 | - [测试产品的可行性和可用性](chapter-5-designing/test-product-viability-and-usability.md) 60 | - [什么是交互设计？](chapter-5-designing/what-is-interaction-design.md) 61 | - [什么是用户界面设计？](chapter-5-designing/what-is-user-interface-design.md) 62 | - [什么是视觉设计？](chapter-5-designing/what-is-visual-design.md) 63 | - [使用HTML和CSS做线框图](chapter-5-designing/wireframing-in-html-and-css.md) 64 | 65 | **开发** 66 | 67 | 我们的开发实践主要参考 Kent Beck 经典的 [Extreme Programming Explained: Embrace Change](http://www.amazon.com/Extreme-Programming-Explained-Embrace-Edition-ebook/dp/B000OZ0N5S)，以及 Gerald Weinberg 的 [The Psychology of Computer Programming](http://www.amazon.com/The-Psychology-Computer-Programming-Anniversary/dp/0932633420)。我们尝试后发现，在多数情况下使用其中的大部分原则改善了我们的工作质量，并提升了团队的幸福感。 68 | 69 | - [验收测试](chapter-6-developing/acceptance-tests.md) 70 | - [代码审查](chapter-6-developing/code-reviews.md) 71 | - [持续集成](chapter-6-developing/continuous-integration.md) 72 | - [结对编程](chapter-6-developing/pair-programming.md) 73 | - [重构](chapter-6-developing/refactoring.md) 74 | - [代码风格](chapter-6-developing/style-guide.md) 75 | - [测试驱动开发](chapter-6-developing/test-driven-development.md) 76 | - [版本管理](chapter-6-developing/version-control.md) 77 | 78 | **生产环境** 79 | 80 | 我们生活在一个魔幻的新纪元，很多问题都已经有了解决方案。我们尽可能地聚焦在核心产品，尽量将可分发出去的工作交给外部服务来做。 81 | 82 | - [域名和 DNS](chapter-7-production/domain-names-and-dns.md) 83 | - [错误追踪](chapter-7-production/error-tracking.md) 84 | - [主机托管](chapter-7-production/hosting.md) 85 | - [日志收集](chapter-7-production/log-collection.md) 86 | - [支付处理](chapter-7-production/payment-processing.md) 87 | - [性能监控](chapter-7-production/performance-monitoring.md) 88 | - [生产环境清单](chapter-7-production/production-checklist.md) 89 | - [SSL 证书](chapter-7-production/ssl-certificates.md) 90 | - [事务性邮件](chapter-7-production/transactional-email.md) 91 | 92 | **度量** 93 | 94 | 度量的难点在于决定要追踪什么。Dave McClure 的 [AARRR 框架](http://www.slideshare.net/dmc500hats/startup-metrics-for-pirates-nov-2012) 为重要指标提供了一个高层次的概述。我们使用事件追踪等技巧来测量那些指标。 95 | 96 | - [AARRR 框架](chapter-8-measuring/aarrr.md) 97 | - [A/B 测试](chapter-8-measuring/ab-testing.md) 98 | - [功能旗标](chapter-8-measuring/feature-flags.md) 99 | - [度量](chapter-8-measuring/instrumentation.md) 100 | - [订阅指标](chapter-8-measuring/subscription-metrics.md) 101 | 102 | **我们的公司** 103 | 104 | 我们相信总是可以找到更好的工作方式，因此我们期待可以找到它并和分享给尽可能多的人。 105 | 106 | - [招聘](chapter-9-our-company/hiring.md) 107 | - [运营](chapter-9-our-company/operations.md) 108 | - [原则](chapter-9-our-company/principles.md) 109 | - [营销](chapter-9-our-company/sales.md) 110 | - [分享](chapter-9-our-company/sharing.md) 111 | - [时间](chapter-9-our-company/time.md) 112 | -------------------------------------------------------------------------------- /chapter-1-product-design-sprint/introduction.md: -------------------------------------------------------------------------------- 1 | # 产品设计 Sprints 概述 2 | 3 | > 大多数人误解设计是看起来是什么样子。人们认为它只是装饰——设计师接过一个箱子并被告知，「把它弄的漂亮点！」。我们不这么想。设计不仅仅是看起来和摸起来的感受，它还表达了产品是如何工作的。 4 | > — 史蒂夫.乔布斯 5 | 6 | 产品设计 Sprints，是由 [Google Ventures' design team ](http://www.gv.com/design/) 提出的，通过 5 阶段的流程来更好地创造[人们真正想要的产品](http://paulgraham.com/good.html)。在开始昂贵的构建之前，我们先把虚假的自信变成验证后的自信。甚至，我们会发现根本不需要开始这个昂贵的构建。 7 | 8 | Sprints 对于开始新项目和解决已有项目问题同样有用。这个过程通常需要 5 天的时间，不过也有在少于 5 天时间完成过的情况。我们会尽可能多地安排相关各方以及专家在同一个房间内参与设计。 9 | 10 | 产品设计 sprints 是测试驱动的。 11 | 12 | ![alt](http://beantalk.net/static/upload/201610/551efc358a2500bcc880bc6cab94b1d0.png) 13 | 14 | [原文链接](https://thoughtbot.com/playbook/product-design-sprint/introduction) 15 | -------------------------------------------------------------------------------- /chapter-1-product-design-sprint/phase-0-prepare.md: -------------------------------------------------------------------------------- 1 | # 阶段 0：准备 2 | 3 | 在这个 sprint 之前，我们的客户安排 5 个真实人员在我们最后一个阶段进行测试。毕竟客户比我们更懂他们的用户。 4 | 5 | 他们也从以下来源获取数据： 6 | 7 | - [Quora](http://quora.com/) 8 | - [Google Analytics](http://analytics.google.com/) 9 | - [Adwords Keyword Planner](https://adwords.google.com/ko/KeywordPlanner/Home) 10 | 11 | 我们也会做一些（付费的）准备工作： 12 | 13 | - 准备和进行[用户面谈](http://www.nngroup.com/articles/interviewing-users/) 14 | - 进行一次简短[调研](http://www.google.com/insights/consumersurveys/use_cases)，调研结果会在阶段 1 中使用 15 | 16 | 通常，我们会在第一天订早餐来让它觉得特别点。但是在这个 sprint 进行的每一天，我们不订午餐。在这个 sprint，以及平时，我们认为不要进行「工作午餐」这事儿很重要。取而代之的是暂时从工作中抽身出来休息下大脑，或者呼吸下新鲜空气，和队友还有客户进行互动。 17 | 18 | [原文链接](https://thoughtbot.com/playbook/product-design-sprint/phase-0-prepare) 19 | 20 | -------------------------------------------------------------------------------- /chapter-1-product-design-sprint/phase-1-understand.md: -------------------------------------------------------------------------------- 1 | # 阶段 1：理解 2 | 3 | 我们在这个阶段中的努力帮助我们理解用户的生活（消费软件）或者工作（商业软件）的需求，并产生共鸣。 4 | 5 | 这个阶段，讨论人员会记笔记，通常写在便签纸上并贴到墙上。 6 | 7 | 我们以「推销练习」开始，客户像在向投资人推销他们的产品一样来讲解产品。这帮助我们识别用户，他们的问题，以及他们希望产品达到的功用。同时开始记录该领域的[术语表](http://martinfowler.com/bliki/UbiquitousLanguage.html)。 8 | 9 | 接着我们查阅来自 Quora、Analytics、AdWords Keyword Planner、访谈和调查问卷中的资料。这帮助我们理解用户的动机、营销漏斗以及目标市场的规模。 10 | 11 | 最后，我们绘制出这个 sprint 接下来要关注的事项：软件的关键路径。这时，我们尝试尽可能少考虑实现细节，保持在一个高的层面来考虑。一个有助于创建关键路径的问题是： 12 | 13 | > 用户拿这个产品来干什么？ 14 | 15 | ![alt](http://beantalk.net/static/upload/201610/aD-IwHBh8E4BkbI1l-zTov2N.jpg) 16 | 17 | 随着 sprint 阶段的推进，我们可能会修正关键路径。 18 | 19 | [原文链接](https://thoughtbot.com/playbook/product-design-sprint/phase-1-understand) 20 | -------------------------------------------------------------------------------- /chapter-1-product-design-sprint/phase-2-diverge.md: -------------------------------------------------------------------------------- 1 | # 阶段 2：发散 2 | 3 | 在本阶段中，我们会绞尽脑汁列出出满足用户需求的所有潜在解决方案。 4 | 5 | 在这个阶段之前，我们的团队一般会在房间走动，查看贴满墙上的关键路径和便签纸。 6 | 7 | 我们再次从「推销练习」开始，并跟关键路径做对比。 8 | 9 | 接着我们让每个人画出 10 个以上的[用户流程](https://signalvnoise.com/posts/1926-a-shorthand-for-designing-ui-flows)和用户界面，并要求大家把用户来源包含在内：Twitter？博客文章？AdWords？自动推荐? Drip email？朋友推荐？推送通知？ 10 | 11 | 如果产品被开发出来，这些来源最终会在 [Google Analytics' "Acquisition Channels" report](http://analytics.blogspot.com/2013/10/new-acquisitions-reporting-channels.html) 中衡量： 12 | 13 | ![alt](http://beantalk.net/static/upload/201610/a5WFVg6Y3jal9Z7HN4zy5J5M.jpg) 14 | 15 | 我们把这些草图贴到墙上并开始一轮沉默评判，观察并在流程和用户界面的各个位置放置「点数贴纸」，这有助于我们可视化地识别最佳创意。 16 | 17 | 接着我们进行小组评判，每一组解释他们的点数，作者可以补充额外的评论。我们在这个阶段不会否定或者筛选创意。这个投票过程可以让我们规避冗长的讨论，并做到群体设计。 18 | 19 | 最后，我们会使用一个大一点的红色点数贴纸进行「超级投票」。CEO 或者产品所有者在他们认为最好的创意上放一个「超级投票」。这有助于我们识别出他们的组织是如何做决定的，并确定终极方案。 20 | 21 | 我们的经验表明这个阶段是非常耗费脑力的。我们建议早点结束让大家回家好好休息。 22 | 23 | [原文链接](https://thoughtbot.com/playbook/product-design-sprint/phase-2-diverge) 24 | -------------------------------------------------------------------------------- /chapter-1-product-design-sprint/phase-3-converge.md: -------------------------------------------------------------------------------- 1 | # 阶段 3：汇聚 2 | 3 | 本阶段的活动强制我们停止再创造出新的方案，汇聚最好的方案，并开始为原型写测试。 4 | 5 | 首先需要识别最佳方案中的假设。我们列出关于用户动机、商业模式、获取用户以及在预算内完成方案的所有假设。这有助于我们去掉一些无用的选项。 6 | 7 | ![alt](http://beantalk.net/static/upload/201610/U3dq2VYWFBzCQJOR-8ChDOEJ.jpg) 8 | 9 | 接着我们查看剩下的记事贴、用户流程和用户界面三者间的冲突：那些用不同方式解决同一个问题的方案。然后去除当前不能实现的方案。 10 | 11 | 接着我们决定我们是要做一个原型（一枪毙命）还是多个原型（殊死战）。多个原型意味着更多的初始工作，不过它可以揭示更多的绝境，帮助我们避免花更多时间在后续的 sprint 上。 12 | 13 | 然后我们就为每个原型准备故事板。这是一个漫画风格的故事书，其中我们的顾客会走遍关键路径。 14 | 15 | ![alt](http://beantalk.net/static/upload/201610/7aTMhCuOM58H7VDypzNgBsBk.jpg) 16 | 17 | 最后，我们在 Google Docs 创建测试脚本，并在观察室的墙上放置得分板。脚本基于故事板创建，而得分板则被用来记录测试的结果。这会让我们尝试了解的对象更加地清楚和具体。 18 | 19 | [原文链接](https://thoughtbot.com/playbook/product-design-sprint/phase-3-converge) 20 | -------------------------------------------------------------------------------- /chapter-1-product-design-sprint/phase-4-prototype.md: -------------------------------------------------------------------------------- 1 | # 阶段 4：原型 2 | 3 | 在召集大家再做一次推销练习之后，在这个阶段将不再会做类似活动。接下来所有的注意力都花在用恰如其当的保真度来制作恰如其分的原型来得到有用的测试结果。 4 | 5 | 这整个过程中，我们会要求客户在 Google Docs 中书写文案。他们要[写真实的文字，而不是占位符](http://gettingreal.37signals.com/ch11_Use_Real_Words.php)，这样可以测试用户的理解程度和热忱。这些文字以后在推特推广、媒体、广告文案、登录页等等都很有用。 6 | 7 | 在与客户不断地完善沟通的同时，我们也会根据设计师和项目规模，使用不同的工具来进行原型设计。 8 | 9 | 对于 Web 产品原型，一些不错的选项有： 10 | 11 | - [Squarespace](http://www.squarespace.com/) templates 12 | - [Bourbon](http://bourbon.io/) + [Neat](http://neat.bourbon.io/) + [Bitters](http://bitters.bourbon.io/) locally 13 | - [Invision](http://www.invisionapp.com/) 14 | 15 | 对于移动应用，一些不错的选项有： 16 | 17 | - [Flinto](https://www.flinto.com/) + [Sketch](https://www.sketchapp.com/) 18 | - [Prototyping on Paper](https://popapp.in/) 19 | 20 | 不要在这个 sprint 中来学习这些工具。在投资时间中熟悉他们。在这个 sprint 中，选一个你已经掌握的工具来使用。 21 | 22 | [原文链接](https://thoughtbot.com/playbook/product-design-sprint/phase-4-prototype) 23 | -------------------------------------------------------------------------------- /chapter-1-product-design-sprint/phase-5-test-and-learn.md: -------------------------------------------------------------------------------- 1 | # 阶段 5：测试和反馈 2 | 3 | 最后，我们采访 5 位用户来验证我们对他们、他们的情境以及原型的理解。这不是可用性测试。在给他们看原型之前我们会开始一段对话作为采访。 4 | 5 | 我们的一个设计师会采访每一个用户。我们安排他们在一个房间中进行采访，采访会通过视频和音频直播到观察室，其他的相关人士会在观察室观看、讨论并在得分板上记录答案。 6 | 7 | 好的问题是开放式的，允许用户讲出故事。 8 | 9 | > 可以告诉我们一次你给公益组织捐款的经历吗？ 10 | 11 | 不要引导用户到你期待的答案上。 12 | 13 | > 如果可以，你是否愿意给一个公立学校捐款？ 14 | 15 | 不要结束谈话。 16 | 17 | > 过去的一个星期你给某个组织捐过款吗？ 18 | 19 | 如果是新产品，几乎没有团队在第一个 sprint 就能定下来。最有可能的情况是找一些新用户再从发散或者是汇聚那一步开始过一遍。 20 | 21 | 经过一两个 sprints，一般来说我们会有很多验证后的假设，一个清晰的关键路径，并且可以开始编码构建一个初始版本来面对更广泛的用户。 22 | 23 | 对于 web 应用，一般我们 4-6 个星期就可以发布第一个版本。对于移动应用，一般我们借助 [HockeyApp](http://hockeyapp.net/) 可以在 6-8 周时发布一个 beta 版本，8-1 0周时可以在 App Store 发布。 24 | 25 | 从上面的时间线可以看出来，多花 2 到 5 天进行第二次甚至是第三次裁剪产品设计的 sprint 是值得的。否则就可能要多花 4 至 10 倍的时间和金钱。 26 | 27 | 另一个产出是不会产生明显的用户困扰，或者是商业模型非常不清晰，或者是我们以为我们知道的都被证明是错的。做产品设计是一个脑力震荡，但是这是一个成功。节省了时间和金钱。 28 | 29 | 这个阶段结束之后，我们就有了一个继续前进的计划。 30 | 31 | [原文链接](https://thoughtbot.com/playbook/product-design-sprint/phase-5-test-and-learn) 32 | -------------------------------------------------------------------------------- /chapter-2-choose-platforms/mobile-refers-to-the-user-not-the-device.md: -------------------------------------------------------------------------------- 1 | # 「移动」是指用户，而非设备 2 | 3 | 我们在思考如何设计移动应用时，其中的每一个点都要基于以上原则。让我们思考以下问题： 4 | 5 | - 他们在移动吗？ 6 | - 他们是很放松地躺在沙发上吗？ 7 | - 他们的手指灵活吗？ 8 | 9 | 我们尝试从最可用的平台开始。如果这个设备需要相机、日历或者地址簿，那么一个「原生」应用，例如 iPhone 或者 iPad 应用就是恰当之选了。 10 | 11 | 对于其他产品，尤其是内容类型的产品，例如文本、图片、视频、以及首屏，那么一个移动 web 应用就更加合理了，因为： 12 | 13 | - 所有现代的智能手机都可以渲染 HTML。 14 | - [Bourbon](https://github.com/thoughtbot/bourbon) 和 [Neat](https://github.com/thoughtbot/neat) 使得响应式设计变得非常容易实现。 15 | - 我们可以创建产品并且快速迭代。 16 | - 我们可以一天发布多个版本。 17 | 18 | [原文链接](https://thoughtbot.com/playbook/choose-platforms/mobile-refers-to-the-user-not-the-device) 19 | -------------------------------------------------------------------------------- /chapter-2-choose-platforms/native-matters-on-mobile-devices.md: -------------------------------------------------------------------------------- 1 | # 在移动设备上原生编程至关重要 2 | 3 | 我们的移动开发工程师的经验是基于 Objective-C，最近是 Swift 编程语言以及 iOS 框架，例如 Cocoa。 4 | 5 | 我们不承接 Titanium 和 PhoneGap 的项目，因为： 6 | 7 | - 费用：对于我们的设计师来说，同时为 iOS 和 Android 平台设计是一个浪费的负担。不同的屏幕尺寸、分辨率、长宽比、期待的用户交互模式都需要不同的设计方案。 8 | - 及时接触到更新：Apple 的 NDA (译注：Non-disclosure agreement，即保密协议) 迫使像 Titanium 这样的第三方应用直到新版 iOS 发布了公开版本之后才能在它之上做开发。但是按照 Apple 推荐的方式来做，我们可以提前几个月基于新版本进行开发。我们可以使用新特性让应用使用起来感觉更现代化。也可以使用新方式来减小代码行数和节省开发时间。 9 | - 质量：Appcelerator，例如过去的跨平台技术 Adobe Air 和 Adobe Flash，提供了一个最低限度的用户体验。它们可能会，也可能不会被编译成「原生」代码，不过可以肯定的是它们几乎不能获得「原生」体验。 10 | 11 | [原文链接](https://thoughtbot.com/playbook/choose-platforms/native-matters-on-mobile-devices) 12 | -------------------------------------------------------------------------------- /chapter-2-choose-platforms/rails-gets-web-products-to-market-quickly.md: -------------------------------------------------------------------------------- 1 | # Rails 可使 web 产品快速推向市场 2 | 3 | 从我们的经验来看，使用 [Ruby on Rails](https://thoughtbot.com/playbook/choose-platforms/rails-gets-web-products-to-market-quickly) 框架的团队比使用其他工具的团队可以更快将产品推向市场，并且总体成本更低，因为这个框架以及围绕这个框架的社区拥抱「约定大于配置」的思想。这意味着 Rails 应用的代码库之间看起来很相似，使用 Rails 的团队会发现他们在熟悉的技术领域中，可以将注意力更多放到产品本身而不是和代码搏斗。敏捷社区和 Ruby 社区之间也有很大的交集，这意味着 Ruby 程序员（除常规之外）更愿意写测试，使用面向对象设计，以及避免重复的代码。 4 | 5 | 或许我们能够给予 Rails 最大的赞誉莫过于我们在 2005 年就将公司的生死和 Rails 绑定在一起，将公司的未来赌在 Rails 身上，而目前我们还活得好好的。 6 | 7 | 作为回报，我们很自豪能对社区做出贡献，尤其是我们的[开源项目](https://github.com/thoughtbot)，以及我们的 [Blog GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS](http://robots.thoughtbot.com/) 上的文章。 8 | 9 | 除了 Ruby 之外，我们还使用其他的开源软件和 web 标准，例如 HTML、CSS、JavaScript、UNIX、Vim 以及 Postgres，因为它们： 10 | 11 | - 高质量 12 | - 避免锁定特定供应商 13 | - 提供了替换组件的灵活性 14 | - 可以运行在多种设备上 15 | - 经过实战考验 16 | - 当关注的人数众多时 bug 更少 17 | 18 | Ruby on Rails 自带的特性减少了程序员在对抗安全攻击方面的负担，例如： 19 | 20 | - 跨站脚本攻击 (XSS) 21 | - 跨站域请求伪造 (CSRF) 22 | - SQL 注入 23 | - 头部注入 24 | - 日志中的敏感数据 25 | 26 | Rails 帮助我们正确处理安全问题，但在安全问题上我们依然要用心、多知，并且充分测试。更多信息请参考：[Ruby on Rails Security Guide](http://guides.rubyonrails.org/security.html) 27 | 28 | 我们支持 Internet Explorer 10.0+ 以及最新版本的 Firefox、Chrome 和 Safari。我们不支持 Internet Explorer 6、7、8 和 9。这些浏览器正在[失去市场份额](http://en.wikipedia.org/wiki/Internet_Explorer#Market_adoption_and_usage_share)，还有[安全问题](http://en.wikipedia.org/wiki/Internet_Explorer_6#Security_issues)，并且在设计、开发和技术支持上非常耗时。 29 | 30 | 对于移动设备，我们支持 iOS Safari 7.1+、Android Browser 4.4+，以及最新版本的 Chrome for Android。 31 | 32 | 在有限的特殊情况下，用户统计表明需要支持老版本的 Internet Explorer。这些特例应该在早期被识别出来，我们会安排额外的时间和费用来支持这个版本。 33 | 34 | [原文链接](https://thoughtbot.com/playbook/choose-platforms/rails-gets-web-products-to-market-quickly) 35 | -------------------------------------------------------------------------------- /chapter-3-laptop-setup/automate-your-development-environment.md: -------------------------------------------------------------------------------- 1 | # 自动化你的开发环境 2 | 3 | 我们依赖编译器、数据库、编程语言、包管理系统、安装程序以及其他关键的程序来进行日常的开发。 4 | 5 | [Laptop](https://github.com/thoughtbot/laptop) 是一个为 Mac OS X 或 Linux 笔记本设置 Rails 开发环境的脚本程序。安装它应该不用 15 分钟。 6 | 7 | 使用自动化的配置帮助我们和最新的操作系统和程序保持一致。并且，由于它是标准化的，新的团队成员可以快速加入一个项目，而不用把时间花在从新配置开发机器上。 8 | 9 | [原文链接](https://thoughtbot.com/playbook/laptop-setup/automate-your-development-environment) 10 | -------------------------------------------------------------------------------- /chapter-3-laptop-setup/share-configuration-with-dotfiles.md: -------------------------------------------------------------------------------- 1 | # 使用 dotfiles 分享设置 2 | 3 | 「Dotfile」是 UNIX 中配置文件的通用术语，通常以一个点开始（例如 .vimrc），并且位于在你的 home 目录中。包括 Vim 在内的大多数的 UNIX 程序在启动时都会加载一个 dotfile。 4 | 5 | 我们推荐你按照自己的喜好使用 dotfiles 来定制你的工具和环境，减少打字，完成工作。将它们提交到一个 git 仓库并开源，一来可以妥善保存配置，二来也让他人受益。 6 | 7 | 你可以使用我们的 [dotfiles](https://github.com/thoughtbot/dotfiles) 来使得队友间的结对编程更加容易，并使得彼此更加高效。 8 | 9 | [原文链接](https://thoughtbot.com/playbook/laptop-setup/share-configuration-with-dotfiles) 10 | -------------------------------------------------------------------------------- /chapter-3-laptop-setup/use-an-extensible-editor.md: -------------------------------------------------------------------------------- 1 | # 使用可扩展的编辑器 2 | 3 | > 纯文本不会过时。它可以帮助你提升工作效率、简化调试和测试。编辑器应该是你手的延伸；要确保你的编辑器是可配置、可扩展以及可编程的。 - The Pragmatic Programmer 4 | 5 | 几乎所有的 thoughtbot 成员都使用 [Vim](https://thoughtbot.com/upcase/vim) 作为文本编辑器。 6 | 7 | 当使用 Vim 时，我们可以打简写并避免使用鼠标。这样可以做到高效并更容易完成流程。 8 | 9 | Vim 很棒，因为： 10 | 11 | - Vim 很小（1.6MB），打开时飞一样快。 12 | - Vim 是经过长时间精心雕琢过的宝石。它发布于 1991 年，是针对 Vi 的改进，而 Vi 本身则是 [Bill Joy](http://en.wikipedia.org/wiki/Bill_Joy) 在 1976 年创建的。 13 | - 它有一个由开源插件组成的丰富的生态系统。 14 | 15 | [原文链接](https://thoughtbot.com/playbook/laptop-setup/use-an-extensible-editor) 16 | -------------------------------------------------------------------------------- /chapter-4-planning/adapt-process-to-the-products-needs.md: -------------------------------------------------------------------------------- 1 | # 流程要因产品和团队而定 2 | 3 | 对于早期团队来说，一个 Trello 看板上放几个列表应该就够了。然而，随着团队和产品成长，就有必要使用一些组织工具了。例如，我们可能在「当前」看板中增加几个列表： 4 | 5 | - 缺陷 6 | - 产品设计 7 | - 工程 8 | 9 | 随后，[这些列表最好转化成一个看板](http://community.uservoice.com/blog/trello-google-docs-product-management/)。分成独立的多个看板更加有利于对相关的任务进行评估。分解工作也会保持「当前」看板更加干净，产品团队可以专注本周的任务。 10 | 11 | 团队根据产品的开发阶段以及沟通需求来组织每个看板。 12 | 13 | 在「缺陷」这个看板上，我们有时会使用标签来标识缺陷的优先级。如果一个缺陷被标识为「严重」，那他会立即被拖到「当前」看板中的「下一步」列表。如果这个缺陷不是那么重要，它就留在缺陷看板直到下个星期的周期性任务中。一个缺陷要有重现的步骤描述，可选截图或者视频辅助说明。 14 | 15 | 「产品设计」看板中通常是绘制用户流程、可用性测试、其他调研资料或者设计师提升视觉设计灵感的产出。 16 | 17 | 「工程」看板上的卡片是重构任务以及其他为了重现缺陷或者提升用户体验的工程任务。「响应时间」是每个应用的首要用户体验。如果一个工程任务被标识为「严重」，那么它马上就被拖动到「下一步」。如果不是紧急任务，就留到下个星期的周期性工作中。 18 | 19 | [原文链接](https://thoughtbot.com/playbook/planning/adapt-process-to-the-products-needs) 20 | -------------------------------------------------------------------------------- /chapter-4-planning/daily-standups-build-trust.md: -------------------------------------------------------------------------------- 1 | # 每日站立会议可以建立信任和保持冲劲 2 | 3 | 每天早上我们团队在 10 点集合 10 分钟。 4 | 5 | 每人回报昨天做了什么，今天打算做什么，以及有什么阻碍项目进展。我们会立即解决阻碍或者在会后再帮助被阻碍的同事。 6 | 7 | 这样做会让我们： 8 | 9 | - 面对面看到彼此 10 | - 知道别人在做什么，如果有需要你可以帮忙 11 | - 建立责任和信任 12 | 13 | [原文链接](https://thoughtbot.com/playbook/planning/daily-standups-build-trust) 14 | -------------------------------------------------------------------------------- /chapter-4-planning/in-person-communication.md: -------------------------------------------------------------------------------- 1 | # 没有比当面沟通更有效的沟通方式 2 | 3 | 近年来，Slack、GitHub 和 Trello 这样的工具使得远程工作越来越容易，在 thoughtbot 我们每天都和不同办公室的同事们远程协作。 4 | 5 | 远程的顾问工作是可行的，但是会提升难度等级。极限编程中为数不多的要求中的一条是：[客户随时可以联系上](http://www.extremeprogramming.org/rules/customer.html)。 6 | 7 | 理想状态下，这意味着面对面的现场交流。我们已经设置好办公室，客户可以和团队成员坐在一起办公。面对面交流总是最棒的。 8 | 9 | 对我们而言，一个理想的咨询项目中，客户团队中的一员应该愿意周一到周四在办公室和我们一起工作。如果做不到这一点，我们会在商务阶段搞清楚客户在 Slack、GitHub 以及 Trello 上联系到他们的可能性。 10 | 11 | 如果他们看起来并不是很容易联系上，我们应该严肃考虑拒掉这个项目。 12 | 13 | [原文链接](https://thoughtbot.com/playbook/planning/in-person-communication) 14 | -------------------------------------------------------------------------------- /chapter-4-planning/manage-priorities-with-a-lightweight-process.md: -------------------------------------------------------------------------------- 1 | # 使用轻量级程序来管理任务优先级并可视化流程 2 | 3 | 多年以来，我们用过 JIRA、Pivotal Tracker、Lighthouse、Basecamp、Trajectory、Unfuddle 以及其他任务管理系统。下面以 Trello 为例详细展示整个流程，不过即便使用其他系统，整体的流程也是极其相似的。 4 | 5 | 没有两个产品是一模一样的，所以产品开发过程中的灵活性非常重要。Trello 在调整流程结果方面做得可谓「极速」。 6 | 7 | Trello 看板是一个贴满一列列便签纸的墙壁在软件世界中的呈现。在 Trello 的术语中，墙被称为「看板」，列被称为「列表」，列中的便签纸被称为「卡片」。 8 | 9 | ![alt](http://beantalk.net/static/upload/201610/_D6F8A1LLF-BoAent1fDmgX5.jpg) 10 | 11 | 在下面的图片中，「Current」是一个示例看板。「In Progress」是一个示例列表。「Confirm Internet Explorer support」是一个示例卡片。 12 | 13 | ![alt](http://beantalk.net/static/upload/201610/HgSlxUpcLuaD7ThZnK-boLvJ.jpg) 14 | 15 | 在任何任务管理系统中，有这样一个产品开发流程视图非常重要。「Next Up」列表是唯一一个排序的列表，产品团队根据顺序得知下一步要做什么。它代表了一周的工作量。 16 | 17 | 卡片代表了一个工作故事、缺陷修复、工程任务或者一个普通的待办事项。 18 | 19 | 卡片以一个简单的想法开始，一两句话的描述。当它们在不同的看板间拖动时，人们会添加细节，（从商业角度）解释为什么我们会关注它，以及一些实现上的建议（虽然设计师和开发人员会从他们的角度来留下或者考虑接受意见，但应该从有助于项目的角度来做，而不是片面地发表意见）。 20 | 21 | ![alt](http://beantalk.net/static/upload/201610/rwjeWpxoKqt2oHdsBmUk6jvB.jpg) 22 | 23 | 一旦在「Next Up」列表中的卡片被排序并检查过，就可以针对它们进行设计和开发了。设计师或者开发人员通过「把自己的头像放在上面」来将任务指派给自己，并把卡片拖到「In Progress」列表。 24 | 25 | 在「In Progress」列表中的卡片是活跃的任务，在进行设计或者开发。规则是你不应该在两个以上的卡片上同时露面。工作在一个功能分支上完成。 26 | 27 | 当设计师或者开发人员为他们的功能分支创建一个 pull request 时，他们将卡片拖动到「Code Review」列表。评审人在评审时要「将自己的头像放到卡片上」。 28 | 29 | 每个人都有权限合并功能分支到主分支。 30 | 31 | 在 Testing 和 Staging（或者 Testing 以及 iPhone app 的 Ad Hoc build）上的卡片被部署到 Staging（或者通过 HockeyApp 分发 iPhone app），卡片的创建者和设计师来检查还原度以及用户体验。 32 | 33 | 每个人都有权限部署到 Staging。 34 | 35 | 在「Ready for Production」这个列表的卡片包括在 Staging 上被接受的卡片，它们可以被部署（但不一定发布）。 36 | 37 | 每个人都有权限部署到 Production。 38 | 39 | 在「Live（Week of [date])」列表上的卡片已经发布。每周都有自己的「Live」列表，所以我们可以知道什么时候发布了什么。 40 | 41 | [原文链接](https://thoughtbot.com/playbook/planning/manage-priorities-with-a-lightweight-process) 42 | -------------------------------------------------------------------------------- /chapter-4-planning/meet-weekly-to-discuss-successes-failures-and-plans.md: -------------------------------------------------------------------------------- 1 | # 每周碰面讨论成果、错误和未来计划 2 | 3 | 每周一次，通常是周一，大家在现场或者通过视频碰面一次。这会替代掉周一的站会，整个团队一起讨论成果，障碍，以及关注点。会议的目的是大家能对未来一周的任务激动不已，并充满了力量。 4 | 5 | 会议由顾问来主持。 6 | 7 | - 理解团队对过去一周的感受以及对未来一周的预期。问来自 thoughtbot 和客户团队的每个成员，「你过去一周感觉如何？你对未来一周预期如何？」这不是一个事无巨细的报告（细节应该在每日站会中解决），而是感受每个人的脉搏。要记笔记。 8 | - 每个成员都应该提出风险或者关注点；当每个人都说出来之后，大家一起群体协作来化解这些问题。即便有些关注点已经被提出来了，也鼓励其他人提出来；这样有助于团队排出任务的优先级，识别出那些最应该花时间来解决的问题。这是一起讨论如何改善我们共同构建的流程和产品的机会。记下来谁提出了哪些问题，以及我们如何解决这些问题。 9 | - 庆祝成果。回顾上一周已经交付的工作，展示真实的产品，并祝贺做出了这些成果的人。 10 | - 回顾完成之后，和团队分享会议记录，并确保回顾中提到的所有动议都被记录了下来。这样做会让团队看到进展，理解到对产品的感受是如何随时间变化的，以及从回顾中看到的产出对未来设置的目标充满信心。 11 | 12 | 回顾笔记看起来像是这样的： 13 | 14 | Joel 15 | 16 | - last week 17 | - felt like it went by extremely fast 18 | - first couple days, thinking through the project, understanding 19 | - didn't feel like we got much implemented in code 20 | - feel great about knowing what we're building 21 | - this week 22 | - feeling confident 23 | 24 | Ryan 25 | 26 | - last week 27 | - fast-paced with understanding, overwhelmed with the complexity 28 | - towards the end of the week with prototyping and iteration, it helped a lot 29 | - this week 30 | - feel much better than start of last week 31 | - brainstorming + prototype helps a lot 32 | 33 | Yadid 34 | 35 | - last week 36 | - flew by, felt like it didn't happen 37 | - progressed a lot 38 | - defining the interaction was really important 39 | - confident moving forward with what we decided upon 40 | - this week 41 | - time is worrying 42 | - user study, potentially risky 43 | 44 | Concerns 45 | 46 | - timeline - it's a tight project (JQ, RC, YA) 47 | - concerned with choice of technology with vanilla Rails (JQ, YA) 48 | - lots of state involved 49 | - concerns around interaction and not specifically the visual design (RC) 50 | - testing (potentially won't change outcome) (YA) 51 | - need a staging server (JQ) 52 | - don't want to connect to real API 53 | - in dev+test we've created a fake API that we're connecting to 54 | - can't do that on Heroku 55 | 56 | Addressing concerns 57 | 58 | - Yadid to set up a staging server for the app to interact with 59 | - Ryan to do a quick run-through with Yadid re: interactions 60 | - Josh to look into Omar rotating on 61 | 62 | 产品所在的阶段会指导计划会议。例如： 63 | 64 | - 调研和确定：用户界面是不是已经足够确定，可以用来开发一个最小可用版本了？ 65 | - 产品可用性：用户可以在线上部署版本中完成流程吗？ 66 | - 用户获取：这样的流程之后获取的用户数字看起来是怎么样的？ 67 | 68 | 给客户讲用户故事，人们喜欢这个产品吗？展示数字。和上周相比，本周是不是有更多人在使用这个产品了？同一个人是不是用的更多了？ 69 | 70 | 在所有阶段，我们应该问： 71 | 72 | - 我们在创建正确的产品吗？ 73 | - 基于预算，我们还剩多少时间？ 74 | 75 | 基于这些问题的答案，我们在任务管理系统中记录我们的计划： 76 | 77 | - 归档两周前的「Live (Week of [date])」列表。 78 | - 审阅产品设计优先级。将我们认为合适的任务拖动到「Next Up」 79 | - 审查缺陷。将所有严重缺陷拖到 Next UP 并将放到队列的顶端。我们总是优先修复缺陷。 80 | - 审阅工程和重构任务。基于以上的产品和缺陷任务，将设计师和开发人员觉得合适的任务拖到 Next UP。 81 | - 根据优先级再次整理整个 Next Up 列表。上周位于顶端的卡片可以拖动到底部或者拖动到其他的看板或者列表。 82 | 83 | 任务管理系统是计划的正式归属地。 84 | 85 | 当信息是在电话中谈论、面谈、在没有包含全体队员的邮件中或者是一对一的聊天中时，信息就会丢失、忘记或者被误解。当有人加入或者离开问题就会扩大。 86 | 87 | 在这个会议中，试着和客户讨论，而不是获取指示。如果我们没有发现底层问题是无法谈论解决方案的。 88 | 89 | 我们被称为「强势」，我们的方式是裁剪需求，预算，以及时间表。我们经常说「no」。说「no」是不容易的。「no」也不是那么容易被接受的。客户提需求也是有原因的。 90 | 91 | 我们需要和「yes」作斗争，我们能做到这点是因为我们理解了软件开发成功和失败的历史：在 2004 年只有 34% 的软件项目被认为是成功的。好消息是这已经比 1994 年的情况好 100% 了。「主要原因是项目变得小了很多。」 92 | 93 | 很少有软件项目失败是因为做的不够多。说「no」意味着保持我们正在构造的软件足够简单。我们写的每一行代码既是资产也是负担。 94 | 95 | 当简单的软件发布后，更容易改进来满足客户的需求。复杂的软件，即便是发布后，也很难快速响应客户需求。 96 | 97 | [原文链接](https://thoughtbot.com/playbook/planning/meet-weekly-to-discuss-successes-failures-and-plans) 98 | -------------------------------------------------------------------------------- /chapter-4-planning/working-remotely.md: -------------------------------------------------------------------------------- 1 | # 一个高效的远程团队不是偶然的产物 2 | 3 | 远程工作是指当客户和我们团队在不同的地点工作，团队可能是在和客户不同城市的 thoughtbot 的办公室，或者团队的成员在项目过程中在其他的地点办公。 4 | 5 | ## 见面 6 | 7 | 在远程工作开始之前，如果可能，大家至少应该在一起工作一个星期。这有助于大家更好地互相认识并建立联系，会让后续的异步沟通变得更加容易。 8 | 9 | 如果可能，在项目中再次见面会大有裨益的。 10 | 11 | ## 定义好角色和工作流程 12 | 13 | 在项目开始阶段定义好谁来担当哪个角色，以及在团队间应该如何沟通。例如，站会应该是在群聊、语音还是视频沟通。 14 | 15 | 如果有部分团队成员是远程工作的，那么整个团队就要按照远程工作来运行。我们在沟通上要宁繁勿简。项目中的重要决定用在线媒体发布，确保每个人都能知晓并能够反馈。这意味着所有项目相关的文档应该在我们已经使用的异步频道中进行，例如 GitHub、Trello、Basecamp 和 Slack。在远程工作时唯一的不同是我们异步沟通所有的重要信息，保证团队每个成员都能知晓。 16 | 17 | 项目中的面对面沟通通常包含频繁的当前工作更新和社交活动。我们应该使用聊天室来进行沟通，这样没人会觉得被置身事外，尤其是远程工作的的成员。 18 | 19 | 团队成员应该知道，异步沟通意味着有时候其他人不能及时答复，也不应该期待他们马上响应。而且，在线沟通缺少了那些可视化的暗示，例如语调和腔调，面部表情和肢体语言。我们在沟通时要格外注意我们的言辞。一个不错的参考是我们的[代码审查指引](https://github.com/thoughtbot/guides/tree/master/code-review)。 20 | 21 | ## 感受孤独 22 | 23 | 当远程工作时，尤其是独自工作时，很容易忘记融入在团队情谊中的感觉。使用视频会议、偶尔回到办公室或者在联合办公空间有助于消除这种孤独感。 24 | 25 | ## 工作时间 26 | 27 | 在不同工作地点的团队成员，每天应该有 4-6 个小时（考虑到时差）的交集来做同步的交流。 28 | 29 | 对于有些人来说，在家工作时有时很难从工作中解脱出来。还有，灵活的工作时间也意味着有时候在非传统工作时间工作。我们应该有意识地保持一个可持续的节奏，不时从工作中解脱出来小憩片刻。 30 | 31 | ## 工具 32 | 33 | 一些很好的远程[结对编程](https://thoughtbot.com/#pair-programming)工具： 34 | 35 | - [tmate](https://tmate.io/) 和 Vim 或者 Emacs，因为它们只需要占用很少的带宽，并且没有延迟。还需要另一个频道来进行语音或者视频沟通，例如 Hangout 或者 Skype。 36 | - 当你需要使用其他软件，例如浏览器时可以使用 [ScreenHero](https://screenhero.com/)。 37 | 38 | [原文链接](https://thoughtbot.com/playbook/planning/working-remotely) 39 | -------------------------------------------------------------------------------- /chapter-5-designing/always-carry-a-sketchbook.md: -------------------------------------------------------------------------------- 1 | # 总是携带速写本 2 | 3 | 就像在产品设计 spirnt 一样，我们的设计师总是在开发之前先手绘界面。跟 sprint 一样，我们也鼓励团队中每个人随时开始手绘界面。 4 | 5 | 我们办公室有很多 [方形、软质、口袋大小的 Moleskine 记事本](http://www.amazon.com/Moleskine-Squared-Notebook-Cover-Pocket/dp/8883707125)。请拿起一个。口袋大小的尺寸鼓励我们随时随地在上面记录想法。这样的笔记本尺寸也约束我们设计时优先考虑移动设备。 6 | 7 | ![alt](http://beantalk.net/static/upload/201610/miMKGUq8M5xZ79fBVCIMezdX.jpg) 8 | 9 | [原文链接](https://thoughtbot.com/playbook/designing/always-carry-a-sketchbook) 10 | -------------------------------------------------------------------------------- /chapter-5-designing/test-product-viability-and-usability.md: -------------------------------------------------------------------------------- 1 | # 测试产品的可行性和可用性 2 | 3 | 尽早进行用户访谈和可用性测试对于产品的成功至关重要。我们甚至测试设计草图来获取对流程的感受和想象模型。越是早期，我们越多测试问题／解决方案的匹配性，并调研潜在用户获取反馈。在后期，我们更多地测试产品的可用性。 4 | 5 | 用户访谈和可用性测试是测试产品可行性和可用性的最有效方式。不断测试来验证产品和团队关注并解决了人们真正的问题，而且为产品创建了优异的用户体验。我们发现尽早定下测试计划是在项目中能够持续进行用户访谈的最佳方式。项目的访谈和测试应该两周安排一次。这个安排会确定访谈和测试的期望值，团队应该根据具体项目来讨论这个计划是否可行。测试应该永远为项目和用户的需求服务。 6 | 7 | > 我们测试的是软件，而不是你。 8 | 9 | 可用性衡量的是用户想要获得某种产出的难易程度。 10 | 11 | 我们用测试驱动开发的方式来做可用性测试：写下用户的明确产出。我们使用[工作故事](http://blog.intercom.io/using-job-stories-design-features-ui-ux/)的格式来写我们的产出。 12 | 13 | > 当上班时，我希望能够查看团队的状态，这样我可以帮助被阻碍的队友。 14 | 15 | 当脚本写好后，我们就开始寻找被测试者。 16 | 17 | 最有代表性的候选人会从我们现有的用户群众找出。发一条推特，在我们的网站上增加一个横幅广告，或者在我们的 newsletter 中增加一个链接。甚至上线前的项目都有邮件列表。 18 | 19 | 当我们没办法找到候选人，或者现有用户不感兴趣时，我们可以在 craigslist 网站上找到候选人。我们的行政人员在 Craigslist 发一个帖子，安排他们来我们的办公室，并在完成测试之后给他们 30 美元。 20 | 21 | 我们有一个用来在 craigslist 上招人的[模版](https://gist.github.com/croaky/1a1ff3902b4321984b0b)。 22 | 23 | 当测试人员到达后，我们做自我介绍并解释测试流程。流程并不需要非常严格，我们希望测试者放松。虽然是一个放松的测试，还是需要提醒用户几点： 24 | 25 | - 我们需要你的诚实反馈。 26 | - 你将要看到的东西没有一样是我做的，无论你怎么说都不会伤害我的感情。 27 | - 我们在测试软件，不是测试你。这不是用户测试，这是可用性测试。 28 | 29 | 如果我们录像，我们会请他们签订一个[简单的同意表单](https://gist.github.com/croaky/bf97025689b019293f78)。 30 | 31 | 当开始测试后，我们会要求测试者大声说出他们在使用软件时的感受，虽然有点不自然但是非常重要。当测试进行时，唯一需要说话的时候就是让他们再次大声说出感受，问他们问题，给他们要完成的目标。 32 | 33 | 我们应该避免问这样的问题：「这个任务对你来说是不是太难了？」，而应该追问问题。例如某人说：「这个太棒了！」，我们不应该沾沾喜喜。我们应该追问：「为什么你会觉得很棒？」，我们在追寻答案。 34 | 35 | 在这个环节之后，我们看看我们记下的要点，在下一轮可用性测试之前识别出一些最急需修复的问题。如果我们发现了方向性问题，难免会禁不住推倒重来。我们要控制住这种冲动，尽量不做极端的改动。 36 | 37 | [原文链接](https://thoughtbot.com/playbook/designing/test-product-viability-and-usability) 38 | -------------------------------------------------------------------------------- /chapter-5-designing/what-is-interaction-design.md: -------------------------------------------------------------------------------- 1 | # 什么是交互设计？ 2 | 3 | 交互给予用户涂抹画布、直接操控的能力。通过设计这些交互将我们的软件带到现实生活。交互过程应该提供功能可见性，例如可以使用[动画](http://medium.com/p/926eb80d64e3)作为隐喻，让用户更加容易理解一个界面。交互帮助引导用户从开始到完成任务。 4 | 5 | 设计师从原型到实现全程引导交互设计。对于 web 产品我们在浏览器中实现。对于 iOS，我们使用 [QuartzComposer](https://developer.apple.com/technologies/mac/graphics-and-animation.html)。在评审时，我们使用 [gifbrewery](http://gifbrewery.com/) 来演示交互。 6 | 7 | [原文链接](https://thoughtbot.com/playbook/designing/what-is-interaction-design) 8 | -------------------------------------------------------------------------------- /chapter-5-designing/what-is-user-interface-design.md: -------------------------------------------------------------------------------- 1 | # 什么是用户界面设计？ 2 | 3 | > 用户界面是两种东西相遇的地方：人类和计算机。计算机可以运行功能。人类需要使用输入和输出来利用这些功能。用户界面是安排输入输出的地方，使得人们利用计算机的能力来获得他们需要的产出。 4 | > -[Ryan Singer](http://feltpresence.com/articles/19-what-ui-really-is-and-how-ux-confuses-matters) 5 | 6 | 在软件中，用户界面是指为了完成目标而提供的一个个独立的视图。 7 | 8 | 我们用以下标准来评审界面： 9 | 10 | - **将产出放在第一位** 11 | - 为用户提供提示 12 | - 和所在的平台保持一致 13 | - 在整个应用中保持一致 14 | 15 | 我们将用户的目标放在第一位。没有人会仅仅因为一个软件漂亮就用它的。他们找到我们的解决方案是有原因的。将用户的产出做到容易实现和值得拥有是我们的最高优先级。 16 | 17 | 我们让软件易于理解。只提供功能是不够的，用户必须知道已有的功能，并能够预测到软件会如何对他们的输入做出反应。我们的软件必须尽可能地直观。 18 | 19 | 我们和平台指引保持一致。界面和他们所在的环境一致时才让人感觉最好，而不是跨越所有平台强行一致。我们在设计时会优选通用模式。 20 | 21 | 我们强调一致性。真正可用的界面在整个应用中会如预期般地工作。 22 | 23 | [原文链接](https://thoughtbot.com/playbook/designing/what-is-user-interface-design) 24 | -------------------------------------------------------------------------------- /chapter-5-designing/what-is-visual-design.md: -------------------------------------------------------------------------------- 1 | # 什么是视觉设计？ 2 | 3 | 我们提到视觉设计时特指一个应用的样式。我们使用 [gestalt principles](https://robots.thoughtbot.com/gestalt-principles) 沟通和规划我们的应用。 4 | 5 | 它们之中的基本原则包括： 6 | 7 | - 对齐（通常是通过网格来达到） 8 | - 强调（通常是通过大小、位置、颜色来达到） 9 | - 一致（按钮、链接、头部一般要看起来一样） 10 | - 留白（优雅，永恒，让眼睛小憩片刻） 11 | 12 | 成功的设计通常不引人注意。内容要放到前排且居中。整个网站的工作流显而易见。要拒绝做一个令人难忘的设计的诱惑，或者做一个「跳出」的设计。 13 | 14 | 成功的设计是可用的。看看 Gogole 的视觉设计： 15 | 16 | ![alt](http://beantalk.net/static/upload/201610/oDVrU787EJI9BisXhbhRp0xk.jpg) 17 | 18 | 每样东西都在一个网格中。 「Search Mail」和 「Compose Mail」这两个按钮通过颜色从其他按钮中被强调出来。未读信息通过加粗加黑从其他消息中被强调出来。 19 | 20 | ![alt](http://beantalk.net/static/upload/201610/ZzNr2ES18cTQFv2NSpaJapap.jpg) 21 | 22 | 每样东西都放在一个网格中。可以看到有很多留白（尤其是使用 [AdBlock](https://chrome.google.com/webstore/detail/adblock/gighmmpiobklfepjocnamgkkbiglidom) 时）。搜索界面和 Gmail 保持一致。搜索按钮使用颜色强调。 23 | 24 | ![alt](http://beantalk.net/static/upload/201610/HM1arB6qe1FIPQs-wCQst4OC.jpg) 25 | 26 | 网格、留白、一致的搜索框、搜索过滤、搜索结果。 27 | 28 | ![alt](http://beantalk.net/static/upload/201610/rwU6PQmczsoSxe3Omlfvoz8A.jpg) 29 | 30 | 网格、留白。强调搜索和写评论。 31 | 32 | 我们说「视觉设计」而不是「图像设计」，因为我们的应用通常不是图像。相反，我们依靠这些原则和使用来自 [Typekit](http://typekit.com/) 和 [typography.com](http://www.typography.com/) 的高质量优秀[字体](https://thoughtbot.com/upcase/design-for-developers-resources/typography)。 33 | 34 | [原文链接](https://thoughtbot.com/playbook/designing/what-is-visual-design) 35 | -------------------------------------------------------------------------------- /chapter-5-designing/wireframing-in-html-and-css.md: -------------------------------------------------------------------------------- 1 | # 使用 HTML 和 CSS 做线框图 2 | 3 | 设计师将草图提炼为 HTML 和 CSS 线框图。HTML 和 CSS 线框图是使用 [Bourbon](https://github.com/thoughtbot/bourbon) 和 [Neat](https://github.com/thoughtbot/neat) 在浏览器中实现的，这样团队就可以尽快理解核心体验。它也可以让开发人员在线框图中实现功能。 4 | 5 | 设计领先于开发非常重要。重点要放在可用性、用户体验和流程上。 6 | 7 | 我们发现设计和开发流程保持充分的紧密程度很重要。我们不会做超过一月之后的线框图，因为当我们到达某个阶段之后我们经常会决定去掉或者修改功能。 8 | 9 | 随着客户、thoughtbot 团队和用户们之间的不断反馈，这些改动是迭代过程中可以预见到的。花时间为不会被创建的功能做线框，或者创建从来不会用到的功能都是浪费。 10 | 11 | [原文链接](https://thoughtbot.com/playbook/designing/wireframing-in-html-and-css) 12 | -------------------------------------------------------------------------------- /chapter-6-developing/acceptance-tests.md: -------------------------------------------------------------------------------- 1 | # 验收测试 2 | 3 | 验收测试是把[工作故事转化为代码](https://gist.github.com/croaky/d8699363382d86c10c54)的过程。这个代码是针对应用来运行的。测试第一次运行的时候会失败。开发人员实现应用代码直到测试通过。 4 | 5 | 当测试通过时，开发人员提交代码并附上类似以下的信息： 6 | 7 | > 访客创建了抵押 8 | 9 | 代码在[持续集成](https://thoughtbot.com/playbook/developing/continuous-integration)（译注：Continuous Integration，英文缩写 CI）服务器上再运行一次，以确保验收测试在符合生产环境的环境下依然能运行通过。 10 | 11 | 同时，代码会被部署到 staging 环境中，开发人员和客户代表在浏览器中进行冒烟测试。 12 | 13 | 当验收测试在 CI 服务器上通过，你和其他的设计师、开发人员或者客户在 staging 上也确认工作故事完成了，那么这个功能就会随时被部署到生产服务器上。这样做就可以频繁地将新功能部署到生产服务器，迅速地将更多的价值交付给客户。 14 | 15 | [原文链接](https://thoughtbot.com/playbook/developing/acceptance-tests) 16 | -------------------------------------------------------------------------------- /chapter-6-developing/code-reviews.md: -------------------------------------------------------------------------------- 1 | # 代码审查 2 | 3 | 以下是审查流程。请阅读我们的 [git 协议](https://github.com/thoughtbot/guides/tree/master/protocol)来了解使用到的 git 命令。 4 | 5 | - 从主分支创建一个本地功能分支。 6 | - 功能开发完成并通过测试后，暂存这些改动。 7 | - 暂存改动后，提交改动。 8 | - 写上[良好的提交信息](http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message)。 9 | - 推送你的分支到远程服务器。 10 | - 发一个 [GitHub pull request](https://help.github.com/articles/using-pull-requests/)。 11 | - 在 [Slack](https://slack.com/) 发送一个代码审查请求。 12 | - 作者之外的另一个队友审查 pull request。他们[遵守代码审查规范](https://github.com/thoughtbot/guides/blob/master/code-review)来避免误会。 13 | - 他们在 GitHub 的 web 界面或者 Slack 里面评论和直接问关于代码的问题。 14 | - 没问题了他们会在 pull request 上留言 「可以合并」。 15 | - 交互式地变基代码。合并类似「修复空白」这样的提交到一两个有价值的提交中。编辑提交信息，表明你的意图。 16 | - 审查新的提交。审查文件变动。合并分支到主分支。 17 | - 删掉你的远程功能分支。 18 | - 删掉你的本地功能分支。 19 | 20 | 测试驱动开发会让代码的缺陷在开发过程中更早曝露出来。在你的开发机上发现一个失败的测试，比在生产环境上发现要好得多。它可以让你有更加紧密的反馈循环。 21 | 22 | 代码审查在代码合并到主分支之前发生，它能带来类似的好处： 23 | 24 | - 新代码写出来之后整个团队都会知道。 25 | - 错误可以更早地被捕捉到。 26 | - 代码标准更容易被建立、讨论和执行。 27 | - 从这种风格的代码审查中得到的反馈更容易被应用。 28 | - 更不容易忘记具体的情境（「为什么我会写这个？」）因为在作者头脑中它是鲜活的。 29 | 30 | [原文链接](https://thoughtbot.com/playbook/developing/code-reviews) 31 | -------------------------------------------------------------------------------- /chapter-6-developing/continuous-integration.md: -------------------------------------------------------------------------------- 1 | # 持续集成 2 | 3 | Martin Fowler 曾经[详细介绍过](http://martinfowler.com/articles/continuousIntegration.html)持续集成。要点是： 4 | 5 | - 每个开发人员都在他自己的机器上跑测试套件。 6 | - 当他们提交代码到代码控制仓库时，会「集成」其他人提交的代码，重新运行一次测试。 7 | 8 | 这有助于保证不会有依赖特定开发人员机器才能通过的测试。代码在部署到生产服务器之前，还要在生产环境再运行一次测试，这次它运行在 CI 服务器或者服务上。 9 | 10 | 当构建失败时，会通过 Slack 和 email 通知我们。点击链接我们可以看到一个回溯报告，它给我们提示如何来「修复这个构建」。 11 | 12 | 当我们修复并提交到版本控制系统之后，我们将会从 Slack 和 email 得到一个「成功构建」的通知。 13 | 14 | 一个可靠的测试套件对于 web 应用来说绝对必要的。但是，测试套件的问题是它会不断变大的同时也会变得更慢。 15 | 16 | CI 通过并行运行测试来解决这个痛点。通过使用 CI 我们将原本需要 45 分钟运行完毕的测试缩减到 2 分钟内完成。 17 | 18 | 我们用过 CruiseControl、Integrity、Hudson (now called Jenkins) 以及其他 CI 库过来构建我们自己的 CI。结果是花费了很多宝贵的时间。 19 | 20 | 现在我们对开源项目使用 [Travis CI Free](http://travis-ci.org/) 。我们在私有仓库使用 [Travis CI Pro](https://www.travis-ci.com/)，因为它的 UI 一致，配置简单，并且和 GitHub 紧密结合。 21 | 22 | [GitHub post-receive hooks](https://help.github.com/articles/post-receive-hooks) 会触发 CI 运行。我们 GitHub 仓库主要集成的钩子有： 23 | 24 | - 用于 CI 的 Travis 25 | - 用于代码质量和安全检查的 [Code Climate](https://codeclimate.com/) 26 | - 用来强化代码风格规范的 [Hound](https://houndci.com/) 27 | - 用来集成聊天室通知的 Slack 28 | 29 | [原文链接](https://thoughtbot.com/playbook/developing/continuous-integration) 30 | -------------------------------------------------------------------------------- /chapter-6-developing/pair-programming.md: -------------------------------------------------------------------------------- 1 | # 结对编程 2 | 3 | 两个人坐在同一台电脑面前完成的代码被称为[结对编程](http://www.extremeprogramming.org/rules/pair.html)代码。这种代码通常质量更高，而且在考虑到维护成本后总费用也更低。 4 | 5 | 长期看来，这种风格的开发会节省费用，因为出现的 bug 更少，因此也无需以后修复。 6 | 7 | 举一个可以说明结对编程更加有益、要经常进行的例子： 8 | 9 | > 当你写一段非常重要的代码时，在提交到生产环境之前，难道你不想旁边有人帮你看着？ 10 | 11 | 虽然有时由于距离的原因，我们不是 100% 结对编程。但是没有比在键盘上交流更加让设计师之间、开发人员之间、或者设计师和开发人员之间更愉悦的事情了。 12 | 13 | [原文链接](https://thoughtbot.com/playbook/developing/pair-programming) 14 | -------------------------------------------------------------------------------- /chapter-6-developing/refactoring.md: -------------------------------------------------------------------------------- 1 | # 重构 2 | 3 | 「红，绿，重构」的第三步是重构，重构是不破坏外部行为的前提下改善现有代码设计的过程。它是一个非常重要的步骤，但是常常被忽视。我们是如此地热衷于重构代码，以至于我们为这件事专门写了一本书 [Ruby Science](https://gumroad.com/l/ruby-science)。 4 | 5 | [原文链接](https://thoughtbot.com/playbook/developing/refactoring) 6 | -------------------------------------------------------------------------------- /chapter-6-developing/style-guide.md: -------------------------------------------------------------------------------- 1 | # 代码风格 2 | 3 | 我们用[一致的代码风格](https://github.com/thoughtbot/guides/tree/master/style)来写代码，强调代码的整洁性以及团队沟通。 4 | 5 | 总体的规范： 6 | 7 | - 要保持一致性。 8 | - 不要重写已有代码来遵守这个规范。 9 | - 没有足够好的理由，不要破坏规范。 10 | - 如果你能说服队友，那就是一个好的理由。 11 | 12 | [原文链接](https://thoughtbot.com/playbook/developing/style-guide) 13 | -------------------------------------------------------------------------------- /chapter-6-developing/test-driven-development.md: -------------------------------------------------------------------------------- 1 | # 测试驱动开发 2 | 3 | [测试驱动开发](http://www.extremeprogramming.org/rules/testfirst.html)（Test-Driven Development，TDD）可能是我们遵守的最重要的极限编程原则。 4 | 5 | 业务可以从 TDD 受益： 6 | 7 | - 更快地交付更多价值 8 | - 总是交付可以运行的软件 9 | - 更快接受变化 10 | 11 | 代码可以从 TDD 受益： 12 | 13 | - 可读的需求和代码 14 | - 干净的公开接口 15 | - 解耦模块 16 | 17 | 流程可以从 TDD 受益： 18 | 19 | - 回归安全网 20 | - 无所畏惧的重构 21 | - 团队信任 22 | 23 | 在一个更高层面上，如何测试是很简单的： 24 | 25 | - 先写测试。 26 | - 红-绿-重构循环。 27 | 28 | 对于更多细节，我们推荐 [Test-Driven Rails](https://thoughtbot.com/upcase/test-driven-rails) 工作室。他们提供 Ruby on Rails 程序员如何做 TDD 的非常翔实的指导。 29 | 30 | [原文链接](https://thoughtbot.com/playbook/developing/test-driven-development) 31 | -------------------------------------------------------------------------------- /chapter-6-developing/version-control.md: -------------------------------------------------------------------------------- 1 | # 版本管理 2 | 3 | 我们总是使用代码管理。它像是一个时间机器。我们在源代码的平行宇宙中工作，可以无所畏惧地做实验而不用担心丢失工作成果，有问题的时候又可以随时回滚。 4 | 5 | [Git](http://git-scm.com/) 是由 Linus Torvalds 开发的开源的代码管理系统。它很快，并且对分支支持得很好。 6 | 7 | 我们使用 [GitHub](http://github.com/) 来托管我们的 Git 仓库。 8 | 9 | [原文链接](https://thoughtbot.com/playbook/developing/version-control) 10 | -------------------------------------------------------------------------------- /chapter-7-production/domain-names-and-dns.md: -------------------------------------------------------------------------------- 1 | # 域名和 DNS 2 | 3 | 我们使用 [Domainr](http://domai.nr/) 来查看可用的域名。使用 [DNSimple](http://dnsimple.com/) 来购买和维护域名。如果你在其他地方，例如 GoDaddy 购买了域名， DNSimple 提供一个很简单的迁移服务可以把它切换过来。 4 | 5 | 我们喜欢它的简单性。它同时也提供了我们常用的模版： 6 | 7 | - Heroku 8 | - Google Apps 9 | - Cloudflare 10 | - Fastly 11 | - GitHub Pages 12 | - Netlify 13 | 14 | 你可以参考 [Custom Domains](https://devcenter.heroku.com/articles/custom-domains) 教程来设置在 Heroku 上设置根域名和子域名。 15 | 16 | [原文链接](https://thoughtbot.com/playbook/production/domain-names-and-dns) 17 | -------------------------------------------------------------------------------- /chapter-7-production/error-tracking.md: -------------------------------------------------------------------------------- 1 | # 错误追踪 2 | 3 | 我们使用 [Honeybadger](https://www.honeybadger.io/)（$29 - $250 / 月）来追踪我们产品中的错误。 4 | 5 | 它支持我们开发应用的所有编程语言和平台。 6 | 7 | 它还在错误追踪之上提供了集成服务。我们使用 [Slack 集成](http://docs.honeybadger.io/guides/integrations.html#slack)来处理实时错误报警，同时也使用 [Trello 集成](http://docs.honeybadger.io/guides/integrations.html#trello)，这样我们可以在同一个地方确定缺陷和功能的优先级。 8 | 9 | [原文链接](https://thoughtbot.com/playbook/production/error-tracking) 10 | -------------------------------------------------------------------------------- /chapter-7-production/hosting.md: -------------------------------------------------------------------------------- 1 | # 主机托管 2 | 3 | 我们使用 [Heroku](http://heroku.com/)。它是一个构建在 Amazon 云平台上的 PaaS 平台。它非常易用，不管我们的应用只是一个玩具项目，还是高并发高负载应用，它都能应付自如。 4 | 5 | 像 Rails 一样，Heroku 使用约定，这样它就可以做一些我们不要费神的决定。像 web 服务器和应用服务器这样的问题也同时解决了。 6 | 7 | 他们就像是我们外包的运维团队。我们可以花时间在产品而不是解决基础设施的问题上，这些时间和购买基础版的 Amazon Web Services 省下来的钱比起来是值得的。 8 | 9 | 云服务提供更低的运营成本，尤其是刚开始容量比较低的时候。忘记那些昂贵服务器的沉没成本。 10 | 11 | 云服务使得我们客户可以用以前不可能的方式开始运营生意，不用投入大量的前期成本。 12 | 13 | 如果我们需要提供上传功能，例如用户头像，我们上传到 [Amazon S3](http://aws.amazon.com/s3/)。 14 | 15 | 我们还将图片、CSS 以及 JavaScript 资源存储到 CDN 上，例如 [Fastly](http://www.fastly.com/) 或者 [Cloudflare](https://www.cloudflare.com/)。 16 | 17 | [原文链接](https://thoughtbot.com/playbook/production/hosting) 18 | -------------------------------------------------------------------------------- /chapter-7-production/log-collection.md: -------------------------------------------------------------------------------- 1 | # 日志收集 2 | 3 | 大部分应用将有用的调试信息写入日志。在 Heroku，它们默认去向标准输出，最终都被忽视了。 4 | 5 | 我们通常使用 [Logentries](https://logentries.com/) 来接受来自 Heroku 或者其他来源的日志。一旦日志被发送到 Logentries，你就可以搜索之前的日志，并且可以设置针对 Rails 栈之外的错误报警，例如内存不足错误。 6 | 7 | 如果我们要在客户项目中使用 Logentries，最好的解决方案是客户创建一个 Logentries 账号并加一个相关的 thoughtbot 成员。如果客户不想创建账号，或者创建账号的过程过于冗长，我们就在 thoughtbot 的 Logentries 账号创建一个新项目，然后在合约结束后再删除它。 8 | 9 | 我们没有使用 Heroku Logentries addon，因为它会自动创建一系列警报并自动发送给我们在 Heroku 上的每一个管理员。 10 | 11 | 要在 Heroku 设置 Logentries，请参考 [instructions for setting up a syslog drain](https://logentries.com/doc/heroku/#syslog_drain)。 12 | 13 | [原文链接](https://thoughtbot.com/playbook/production/log-collection) 14 | -------------------------------------------------------------------------------- /chapter-7-production/payment-processing.md: -------------------------------------------------------------------------------- 1 | # 交易处理 2 | 3 | 对于信用卡和借记卡收款，我们使用 [Stripe](http://stripe.com/)。它是一个支付网关，也提供商家账号。我们也用它来实现订阅模式收款。 4 | 5 | Stripe 的收费和使用方式有关。信用卡交易成功之后收费 2.9% + 30 美分。没有开户费，月费或者信用卡存储费。 6 | 7 | 向用户的银行账号付款时我们使用 [Plaid](https://plaid.com/)。 8 | 9 | [原文链接](https://thoughtbot.com/playbook/production/payment-processing) 10 | -------------------------------------------------------------------------------- /chapter-7-production/performance-monitoring.md: -------------------------------------------------------------------------------- 1 | # 性能监控 2 | 3 | 我们使用 [NewRelic](http://www.newrelic.com/)（免费 - 100多美元 / 月）来监控我们生产级别应用的性能。 4 | 5 | 性能调试可能是开发工作中最美好的部分。因为这是一个明确的、可以量化的问题。当修复了问题时，我们会看到数据的改善。我们可以说「我们提升了 175% 的性能」。 6 | 7 | 有很多行之有效的修复性能问题的技巧。在使用 Rails + Heroku 时，有些是「免费」的： 8 | 9 | - Amazon server clusters 10 | - gzipping 11 | - [Asset pipeline](http://guides.rubyonrails.org/asset_pipeline.html) 12 | - [SQL query caching](http://guides.rubyonrails.org/caching_with_rails.html#sql-caching) 13 | 14 | 有些需要开发人员的思考： 15 | 16 | - Database indexing 17 | - Eager loading 18 | - HTTP caching 19 | 20 | 页面缓存是我们用得最多的技巧，但是如果我们能缓存页面并将它们推送到 CDN，那将是最快的解决方案。 21 | 22 | [原文链接](https://thoughtbot.com/playbook/production/performance-monitoring) 23 | -------------------------------------------------------------------------------- /chapter-7-production/production-checklist.md: -------------------------------------------------------------------------------- 1 | # 生产环境检查清单 2 | 3 | 我们发现设置一个新的生产环境或者发布一个产品时，有个简短的检查清单会非常有用： 4 | 5 | - 我们是在[最新的 Heroku stack 上](https://devcenter.heroku.com/articles/stack)吗？ 6 | - 我们使用了并发的 web 服务器吗？请参见[如何用 Puma 部署](https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server)。 7 | - 需要长时间运行的进程，例如邮件发送是不是被放到后台任务中了？请参考[如何设置 Delayed Job](https://devcenter.heroku.com/articles/production-check#production-tier-database)。 8 | - 是不是有冗余（至少两个）web 和后台进程运行。 9 | - 我们是否启用了 SSL？参考下一节[「SSL证书」](ssl-certificates.md)。 10 | - 即便是同一个应用，API 请求是否是向一个独立的子域名发送的（api.example.com)？这会给我们未来带来架构上的灵活性。 11 | - Gemfile 中是否定义了[最新版本的 Ruby](https://www.ruby-lang.org/en/downloads/)？请看[如何设置](http://bundler.io/v1.11/gemfile_ruby.html)。 12 | - [配置项是不是存在环境变量中](http://12factor.net/config)？ 13 | - 手动部署是不是安排在了团队成员都是清醒并可联系上的时候？如果万一有问题，可以及时处理。 14 | - 部署是不是遵循了[详细注释的脚本](https://github.com/thoughtbot/guides/tree/master/protocol/rails#deploy)？ 15 | - 我们是否向远程日志服务发送日志？参见下面的[「日志收集」](https://thoughtbot.com/playbook/production/log-collection)章节。 16 | - 我们使用 Heroku 的「标准」数据库还是更高级的？参见 [Heroku production databases](https://devcenter.heroku.com/articles/poduction-check#production-tier-database)。 17 | - 我们备份生产数据库吗？参见 [Heroku PGBackups](https://devcenter.heroku.com/articles/heroku-postgres-backups)。 18 | - 我们监控性能和正常运行时间吗？参见下面的[「性能监控」](https://thoughtbot.com/playbook/production/performance-monitoring)章节。 19 | - 我们追踪错误吗？参见下面的[「错误追踪」](https://thoughtbot.com/playbook/production/error-tracking)章节。 20 | 21 | [原文链接](https://thoughtbot.com/playbook/production/production-checklist) 22 | -------------------------------------------------------------------------------- /chapter-7-production/ssl-certificates.md: -------------------------------------------------------------------------------- 1 | # SSL 证书 2 | 3 | [从 DNSimple 购买一个通配符证书](https://dnsimple.com/ssl-certificate)。通配符（*）让你可以在 `www.`、`staging.`、`api.` 或者其他任意的子域名上使用同样的证书。 4 | 5 | [在 Heroku 上添加一个 DNSimple SSL 证书](https://gist.github.com/croaky/e0beb6025d58eeb88db5)应该花不了你 15 分钟。 6 | 7 | SSL 和 DNS 是紧耦合的。如果要做任何 SSL 相关的工作，我们需要确保有更改 DNS 的权限，例如增加一个 CNAME 记录。如果我们是和客户一起工作，他们有一个部门处理 DNS 事项，那么约好一个避开峰值的时间来一起结对编程做好每件事。如果我们不能有条不紊地进行处理的话，有可能会把一个全站 SSL 网站搞宕机。 8 | 9 | [原文链接](https://thoughtbot.com/playbook/production/ssl-certificates) 10 | -------------------------------------------------------------------------------- /chapter-7-production/transactional-email.md: -------------------------------------------------------------------------------- 1 | # 事务性邮件 2 | 3 | 我们使用 [SendGrid](http://sendgrid.com/)（免费 - $400+ / 月）来向用户发送被称为[事务性邮件](http://www.foundrygroup.com/wp/2010/04/foundry-group-invests-in-sendgrid/)的电子邮件。 4 | 5 | 典型的事务性电子邮件有： 6 | 7 | - 注册确认 8 | - 使用 3 天后对用户的跟进 9 | - 免费试用期失效 10 | - 向系统功能中的其他用户发消息 11 | 12 | 我们直接使用 SendGrid，而不是 Heroku 的 add-on，以避免和其他在 Heroku 上而且在同一个 IP 组内乱发邮件的用户被归到一起。 13 | 14 | [原文链接](https://thoughtbot.com/playbook/production/transactional-email) 15 | -------------------------------------------------------------------------------- /chapter-8-measuring/aarrr.md: -------------------------------------------------------------------------------- 1 | # AARRR 框架 2 | 3 | Dave McClure 的 [AARRR](http://www.slideshare.net/dmc500hats/startup-metrics-for-pirates-nov-2012) 框架提供了一个对于重要指标的高层次总览。我们使用诸如事件追踪等技巧来度量这些指标。 4 | 5 | AARRR 框架是： 6 | 7 | - 获取（Acquisition） 8 | - 激活（Activation） 9 | - 保留（Retention） 10 | - 收益（Revenue） 11 | - 推荐（Referral） 12 | 13 | 对于早期产品，我们按照如下顺序改进： 14 | 15 | - 激活：访客发现这个产品值得一试，而且能够用起来，接着尽可能短时间地来到[「原来如此！」时刻](http://www.growhack.com/2012/12/04/discovering-your-aha-moment/)。 16 | - 保留：用户定期使用产品，产品能满足客户的需求，他们很开心。 17 | - 收益：用户付费使用产品。 18 | - 获取：我们知道用户从哪里来，尝试开辟新的渠道，关闭无用的渠道，扩宽有用的渠道。 19 | - 推荐：用户推荐其他用户，这是理想的获取用户方式。 20 | 21 | [原文链接](https://thoughtbot.com/playbook/measuring/aarrr) 22 | -------------------------------------------------------------------------------- /chapter-8-measuring/ab-testing.md: -------------------------------------------------------------------------------- 1 | # A/B 测试 2 | 3 | 在可用性测试中遇到困惑，或者在结账流程中对向上销售感到沮丧时，人们可以很明确地告诉我们他们的问题。 但是他们可能没办法告诉我们入口页上的这一组还是另一组内容更吸引他们，会更容易让他们掏腰包，甩出一叠现金。 4 | 5 | 所以我们 [A/B 测试](http://en.wikipedia.org/wiki/A/B_testing)入口页和支付流程。 6 | 7 | 我们不会 A/B 测试价格。用户之间会互相谈论价格，这也会给我们的客服人员添麻烦。我们用线下访谈的方式来做价格测试。 8 | 9 | [原文链接](https://thoughtbot.com/playbook/measuring/ab-testing) 10 | -------------------------------------------------------------------------------- /chapter-8-measuring/feature-flags.md: -------------------------------------------------------------------------------- 1 | # 功能旗标 2 | 3 | 软件是柔性的。它总是在变化。希望我们能从变化中学到东西。 4 | 5 | 功能旗标是一个有效管理变化的方法。使用 [Rollout](https://github.com/FetLife/rollout) 这样的工具，我们可以将部分功能标记为只给一部分用户用，例如我们的开发团队，创始人的朋友或者全部用户的 10%。 6 | 7 | 用这种方式，我们可以看到用户对我们提供的功能是如何响应的，同时又可以不用把功能开放给所有用户。我们可以结合 A/B 测试来看用户是如何响应不同的功能的。 8 | 9 | [原文链接](https://thoughtbot.com/playbook/measuring/feature-flags) 10 | -------------------------------------------------------------------------------- /chapter-8-measuring/instrumentation.md: -------------------------------------------------------------------------------- 1 | # 度量 2 | 3 | 为了稍后分析指标，我们需要度量应用来记录恰当的指标。我们最关切的度量类型被称作「事件追踪」。 4 | 5 | 尽可能使用 [Segment](https://segment.com/) 来捕捉事件。它类似分析服务的[适配器模式](http://sourcemaking.com/design_patterns/adapter)。 6 | 7 | Segment 为 web 应用提供一个 JavaScript 库，为服务端框架提供一个库，为移动应用提供一个 SDK。这让我们可以启用不同的服务，例如 Google Analytics、Amplitude、FullStory、Intercom 等等。 8 | 9 | ![alt](http://beantalk.net/static/upload/201611/2ctuEDKgHPl71dDFKI5-YAxH.jpg) 10 | 11 | 当 Segment 不支持一个后端服务时，我们可以直接使用这个服务，或者为 [Segment 开源库](https://segment.com/libraries/analytics.js)提交对应的支持。 12 | 13 | 事件追踪最难的地方是[选择事件的粒度](http://qr.ae/GBPdx)。重建度量历史是很昂贵的，而且错误的结果会杀死一个早期产品，所以： 14 | 15 | - 当事件出现时就及时追踪 16 | - 对于数据来说宁多勿少 17 | - 对每个事件尽量囊括所有状态 18 | - 从开始就记录数据 19 | 20 | 典型需要追踪的数据如下： 21 | 22 | - 打开 App（移动应用） 23 | - 后台应用（移动应用） 24 | - 访问量（web） 25 | - 创建账号 26 | - 发起购买 27 | - 添加内容 28 | - 建立联系／好友 29 | - 升级订阅 30 | - 推荐朋友 31 | 32 | 充分使用各种事件属性，例如： 33 | 34 | - 会话 ID 35 | - 所有用户属性 36 | - 环境：操作系统、应用的版本、设备硬件细节 37 | - 当前电量、Wi-Fi、手机状态 38 | - 会话持续时长，精确到秒数 39 | 40 | [商业分析不必是实时的](http://mcfunley.com/whom-the-gods-would-destroy-they-first-give-real-time-analytics)，记录数据不应该让用户体验慢下来。所以，我们针对每个平台尽可能使用后台任务来执行这些任务。例如 [Delayed Job](https://github.com/collectiveidea/delayed_job) 和 [Resque](https://github.com/resque/resque)。 41 | 42 | [原文链接](https://thoughtbot.com/playbook/measuring/instrumentation) 43 | -------------------------------------------------------------------------------- /chapter-8-measuring/subscription-metrics.md: -------------------------------------------------------------------------------- 1 | # 订阅指标 2 | 3 | 我们有很多产品是使用按月或者按年付费订阅的商业模型。这些产品有一些经典的指标需要我们追踪，例如： 4 | 5 | - 每月经常性收入 (Monthly Recurring Revenue, MRR) 6 | - 活跃订阅数 7 | - 生命周期价值 (Lifetime Value, [LTV](http://en.wikipedia.org/wiki/Customer_lifetime_value)) 8 | - 每个方案，按月、按年的用户流失 9 | 10 | 因为我们使用 Stripe 来处理支付，因此发现 [Baremetrics](https://www.baremetrics.io/) 是追踪这些指标最快、最容易的方式。 11 | 12 | 如果我们的客户需要从投资人那里筹措资金，以下这些数字可以认为是已经为争取投资做好准备了。 13 | 14 | - [LTV 比获取客户成本（CAC）大 3 到 5 倍](http://www.forentrepreneurs.com/startup-killer/) 15 | - [MRR 的月度增长是 10% 到 30%](http://www.forentrepreneurs.com/startup-killer/) 16 | - [年度流失率是 5 - 7%](http://sixteenventures.com/saas-churn-rate) 17 | 18 | 当融资时流失量尤其重要。[流失量的微小调整可以极大地影响估值](http://www.forentrepreneurs.com/why-churn-is-critical-in-saas/)。 19 | 20 | 计算客户获取成本需要手工计算电子表格的活儿。它需要将员工总开支和直接市场开支加到一起，然后除以当月获得的总客户数量。 21 | 22 | 对于我们自己的产品 [Upcase](https://thoughtbot.com/upcase)，我们用记账应用，[Supporting Strategies](http://www.supportingstrategies.com/) 来提供这些数字，并根据我们在哪个渠道投放市场营销费用来做调整，例如 Google（AdWords）、Twitter 或者 AdRoll。 23 | 24 | [原文链接](https://thoughtbot.com/playbook/measuring/subscription-metrics) 25 | -------------------------------------------------------------------------------- /chapter-9-our-company/hiring.md: -------------------------------------------------------------------------------- 1 | # 招聘 2 | 3 | 我们不是客户的长期团队解决方案，他们常常会问： 4 | 5 | - 我怎么找到技术合伙人？ 6 | - 我怎么学会「自己动手」？ 7 | - 我怎么招聘设计师和开发人员？ 8 | 9 | 我们告诉他们： 10 | 11 | - 要找到技术合伙人，到用户组、LinkedIn 和 AngelList 中找。你真的需要一个[设计合伙人](http://www.designstaff.org/articles/does-your-startup-need-a-design-co-founder-2012-01-12.html)吗？ 12 | - 要学会做我们做的东西，来我们的办公室几个星期，和我们结对编程，一起手绘设计。 13 | - 要招到人，按照我们的流程来操作，具体在下面列出。 14 | 15 | ## 招聘 16 | 17 | 我们通过以下渠道遇到我们未来的队友： 18 | 19 | - [GitHub](http://github.com/) 20 | - 用户组 21 | - [Dev Bootcamp](http://devbootcamp.com/) 22 | - [Authentic Jobs](http://www.authenticjobs.com/) 23 | - [Stack Overflow Careers](http://careers.stackoverflow.com/) 24 | 25 | 我们遇到 Josh 因为他给 [Clearance](http://github.com/thoughtbot/clearance) 提交了优秀的补丁。当时他还在密歇根。部分是因为他们在开源项目上的贡献，我们从遥远的印度和泰国招聘到很好的开发人员。我们帮助他们搬到了我们有办公室的城市。 26 | 27 | 很多我们的成员经常出现在 Ruby、JavaScript、Vim 和 Redis 的用户组中。我们在 Boston Ruby Group 遇到了 Ben、Joel 和 Mason。 28 | 29 | 关于这种聚会的一个好处是它是自然而然发生的。我们不会在 GitHub 上滥发信息或者在用户组和会议上钓鱼。不管怎样，我们都在那儿。即便是我们不招聘，我们也会写和使用开源软件。我们仍然会加入邮件列表和参加聚会。 30 | 31 | 我们知道如果按照上面的方式招聘，我们能得到什么样的人才。我们从用户组知道他们的性格和能力。我们从开源项目知道他们的编码风格。我们知道他们会积极主动因为他们自愿给社区做贡献。 32 | 33 | 我们在 Dev Bootcamp 遇到 Jessie 和 Laila。他们通过了 [apprentice.io](http://apprentice.io/)（thoughtbot家的培训服务），Adarsh、Draper、Edwin、Diana、Melissa、Joël、Lisa、Lydia、Rich、Christian 和 Tony 也是。 34 | 35 | 我们也在 Authentic Jobs 上找到了很好的设计师，在 Stack Overflow Careers 上找到了 iOS 开发人员。 36 | 37 | 我们没有使用外部招聘方式。我们发现他们没办法找到适合我们团队的人，而且对于他们提供的候选人资料也靠不住。总体来说，不值得花时间过滤那些不合格的候选人。 38 | 39 | ## 面试 40 | 41 | 我们在「Hiring」这个看板上建立 [Trello](http://trello.com/) 卡片追踪我们每个候选人的面试流程。 42 | 43 | ![alt](http://beantalk.net/static/upload/201611/LwXQsD7ocrzkCNqgeVoja6Mm.jpg) 44 | 45 | 我们根据个人简介来创建 Trello 卡片。这些信息录入到新成员表单后，便自动生成卡片。 46 | 47 | 我们的 CEO Chad 会负责招聘流程。他确保所有的人都得到回应，他和每个要加入的人谈话。 48 | 49 | 每个人都可以对候选人做第一轮审查。尤其是审查候选人的样例代码或者项目经历。如果必要他们会找另一个人（设计师或者 iOS 开发人员）来一起看代码和项目经历。 50 | 51 | 我们要么发拒信，要么基于[这个模版](https://gist.github.com/croaky/3e12ff226d6b04451fe8)发送邮件，并将卡片拖到「Non-Technical Interview」。 52 | 53 | Chad 会将管理总监、设计师、开发人员安排进后续的讨论中，将他们的头像放到卡片上，这样大家总是知道谁在负责。 54 | 55 | 在技术面试中我们针对 iOS 开发者、Rails 开发者和设计师有一些标准问题。我们不用考题或者代码测试。相反，我们喜欢审查候选人做过的实际工作，和他们谈论设计过程，架构问题，然后写代码。我们每天都在做的事情。 56 | 57 | 最后一步是候选人来我们办公室待一天。我们付他们的机票和三晚的酒店（星期四休息好，星期五和我们一起工作一天，星期五晚上享受一下，星期六游览下城市，星期天飞回家）。 58 | 59 | 在一起工作的那天，候选人上午和我们一个开发人员[结对编程](http://www.extremeprogramming.org/rules/pair.html)，下午换另一个。 60 | 61 | 设计师会在早上结对做一个小的产品设计，下午 4 点做演示。主要内容做手绘和 1-2 个 thoughtbot 的设计师结对编程。 62 | 63 | 我们用这种方式面试是因为看到候选人是如何真实工作以及和团队互动是不可替代的。我们也希望候选人自己也体会下公司是如何运作的。 64 | 65 | 除了技术之外，我们也在整个面试过程中考察候选人的[积极人格](http://www.kipp.org/our-approach/strengths-and-behaviors)，例如：激情（感染他人），专注（投入，抗干扰，记得方向），镇定（被批评时保持镇定，不打断），感恩（表达谢意），好奇（乐于尝试，会问问题，积极听取），乐观（很快从沮丧中走出），坚毅（有始有终，不会被阻碍），情商高（懂得尊重别人的情感，知道何时以及如何让其他人加入），幽默（常常笑，或者让其他人微笑），审美（能够鉴赏美好和优秀的事物）。 66 | 67 | 候选人必须得到所有参与面试的团队成员的一致同意才能最终被录取。 68 | 69 | ## 录取和入职 70 | 71 | 我们使用 [RightSignature](https://rightsignature.com/)（14 - 49 美元 / 月）来发送录取通知，并使用它来签字，避免双方「打印并签字」的流程。 72 | 73 | 录取通知至少要有一个 C-level（CXO）的领导团队成员审查后才可以发送。C-level 领导和管理总监可以代表 thoughtbot 发送录取通知。 74 | 75 | 当录取通知被接受后，我们运行一个自定义的入职脚本。它会为队友创建邮件地址，给他们访问 GitHub 和 Slack 等系统的权限，发送他们的员工协议，通知财务，给队友发一封欢迎邮件，给 HR 经理创建一个任务列表，列出需要手动处理的事项。 76 | 77 | 我们给新成员安排一个拍档来引导他们度过第一天。这个拍档帮助他们设置好电脑，购买必要的软件，用加他们的资料到我们网站的方式来走完一个开发环节。这个拍档也会让他们觉得安心，回答他们的问题或者指给能回答问题的那个人。 78 | 79 | ## 待遇 80 | 81 | 我们是自力更生的，没有外部投资者，也没有债务。我们每周四天的咨询工作为我们带来收入。 82 | 83 | 公司的可持续发展是非常重要的。我们希望用合理的薪水吸引优秀的人才加入，并根据他们的实际表现尽可能有力地奖励他们。 84 | 85 | 我们可能永远不能和其他的科技公司进行金元大战，但是我们的工作环境有竞争力，有大量的学习机会，可以自由定义和执行我们自己的项目。 86 | 87 | 除了薪水，每个带来项目的员工都会收到佣金，每个人都会参与季度分红奖金。 88 | 89 | 工资提升是公司提升的自然结果，在全公司范围内每年一次。我们的管理层会按照符合公司财务状况和我们取得的成果来提升工资，例如： 90 | 91 | - 创造了优秀的软件 92 | - 使得用户、队友和客户开心 93 | - 学到了新东西提升自己 94 | - 通过带来业务、指导队友、为内部工具或者调研做贡献改进了 thoughtbot 95 | - 通过写博客、为开源软件做贡献或者参加会议改进了我们的社区 96 | - 做了其它没有列在这里的事情 97 | 98 | 我们的薪资调整也有可能基于市场情况和生活成本增加。 99 | 100 | 说清楚为什么提升工资，以及如何做下次可以得到更高的提升很重要。我们不想只是为了涨工资而涨工资。 101 | 102 | ## 季度评审 103 | 104 | 为了持续改善我们自己和公司，全年内我们都收到来自客户、管理者以及队友对各个项目的反馈。我们有正式的季度评审。 105 | 106 | 在入职时，一个「Quarterly Review」日历事件就被创建了，并被设置成每三个月一次，从雇佣那天算起。 107 | 108 | 在季度评审之前，我们的管理者从所有合作过的人，办公室的每一个人那里收集匿名反馈。在评审之前，团队的反馈是大家共享的。 109 | 110 | 季度评审的安排基本上是这样的： 111 | 112 | - 评审团队成员的反馈 113 | - 我们在最近咨询项目上的表现 114 | - 我们的投资时间贡献 115 | - 我们对工作、项目和公司的满意度 116 | - 我们对于 thoughtbot 和我们战略的问题 117 | - 我们下个季度的重点 118 | 119 | 季度审查报告被记录下来，并影响下次的待遇调整。 120 | 121 | [原文链接](https://thoughtbot.com/playbook/our-company/hiring) 122 | -------------------------------------------------------------------------------- /chapter-9-our-company/operations.md: -------------------------------------------------------------------------------- 1 | # 运营 2 | 3 | 运营一个基于软件的公司不仅仅需要漂亮的代码和受欢迎的产品。管理现金流和税费可能让人觉得不重要或者比较麻烦，但是对于我们的成功来说，妥善处理这些和产品设计一样重要。 4 | 5 | 幸运的是，很多已有的服务可以让诸如记账、收据、签字和发票更加容易。 6 | 7 | 以下原则帮助我们简化运营操作： 8 | 9 | - 把重要但是我们又不擅长的事情外包出去。 10 | - 花点时间来选择供应商，偶而花点时间重新评估其他供应商。 11 | - 自动化重复性的任务。 12 | - 尽可能给每个人「管理」权限以避免瓶颈。 13 | - 避免构建内部工具。构建这些工具需要时间和费用，并且有问题的时候需要我们自己来解决。 14 | - 我们的问题不是独一无二的。我们先尝试手工处理。如果我们构建某种应用，那通常是我们我们使用了其他应用多年以后。 15 | 16 | ## 开销 17 | 18 | 每个全职员工都会获得一张美国运通公司卡来支付商务开销。我们雇佣值得信赖的人。尽你最大努力来判断花多少，以及哪些是商务开销。 19 | 20 | 我们会购买东西。如果我们记录这些 IRS 会感谢我们。我们也是一样，好知道我们是不是盈利。 21 | 22 | 在美国，我们使用 Tallie 来发送所有的收据（餐费，旅行，书籍，电脑）给我们的会计。在斯德哥尔摩，我们使用 Shoeboxed。如何使用 Tallie 的指引。在 iPhone 和 Android 上也有 Shoeboxed 应用可以方便地用来发送收据。 23 | 24 | ## Email 25 | 26 | 我们用 Gmail 来收发邮件 27 | 28 | ## 日历 29 | 30 | 我们使用 Google Calendar 作为我们的日历应用 31 | 32 | ## 文档 33 | 34 | 我们使用 Goolge Docs 作为我们的文档应用。 35 | 36 | 我们选用 Google Docs 因为： 37 | 38 | - 很方便使用 URL 分享。每个人都有浏览器，但是不是每个人都安装了 MS-Office 或者 OpenOffice。 39 | - 总是可以打开最新的内容。 40 | - 可以实时协作，例如群体会议记录。 41 | - 自动存在云端，不用担心备份。 42 | - 像 Google 某样东西一样容易找到。 43 | - 没有文件格式这回事 (e.g. xls vs. xlsx). 44 | - 便宜 45 | 46 | 这些工具不是针对大型文档或者复杂的电子表格的，这反而很好。 47 | 48 | 我们写代码，我们倾向于最小化文档和规范，所以我们不会写很冗长的文档。 49 | 50 | 当我们写大的电子表格时，我们发现用一个小的应用来处理会更快一些。这也是一个很好的时机来问我们自己是不是需要做这么复杂的分析。 51 | 52 | 当文件有少许的变量变化时（例如合同），我们用 Pages 通过模版创建文档并导出为 PDF 文件供外部使用。 53 | 54 | ## 会议 55 | 56 | 我们和客户面对面和线上积极沟通来避免开会。所有的问题都是糟糕的沟通引发的。 57 | 58 | 当我们需要讨论时，我们致力于通过 30 分钟的面对面沟通来解决。 59 | 60 | 当我们远程工作时，Google Hangouts 是不可或缺的「下一个伟大发明」。他们很容易设置，通过 URL 分享，并让我们知道我们要和谁谈话。 61 | 62 | 如果需要的时候，屏幕分享也是很容易的。我们用 Hangouts 和客户开会、面试候选人以及进行公司会议。 63 | 64 | 我们使用会议专线进行语音会议，它也是我们 VoIP 系统的一部分，由 OnSip 提供。 65 | 66 | ## 财会 67 | 68 | Supporting Strategies 为我们提供了外包的记账、财务总管、税务会计／会计师。他们为我们安装了一个托管的 QuickBooks，我们可以通过 Remote Desktop 来访问。 69 | 70 | 我们使用 Earth Class Mail 来接收办公室所有的纸质邮件。这个服务自动打开并扫描所有纸质邮件，并以 PDF 电子邮件附件的形式发给我们，然后我们使用 Dropbox 归档。Earth Class Mail 还会自动检测支票并支取之后存入我们的银行。 71 | 72 | 我们主要通过邮件和他们沟通，这样非高效，我们按需付费，这意味着我们也非常容易扩展。 73 | 74 | 我们的会计每天审阅 Harvest 中的新发票和新收入并录入到 QuickBooks。如果有支票或者转账收入，会被记录到 Harvest 和 QuickBooks 中。Harvest 会发送收到支付通知邮件给客户和我们的管理团队。 75 | 76 | 我们的收据会自动发给他们。 77 | 78 | 我们的会计师非常优秀，他提供以下服务： 79 | 80 | - 确保工资定期准确发放。 81 | - 收集应付款并及时支付我们的合作伙伴。 82 | - 准备每个月的 P&L statements，分解为服务和货物。 83 | - 准备报税。 84 | - 确保现金流、支票账户和存款账户井然有序。 85 | 86 | 在瑞典 Radius 协助我们的公司、会计、税务和人力资源。 87 | 88 | ## 法务 89 | 90 | 我们的法务公司是 [Mesmer Updegrove LLP](http://www.gesmer.com/home.php)。他们提供我们需要的几乎所有法律支持，通常是客户、地产、以及公司／股票相关的事项。我们也雇佣了 [Costa & Riccio LLP](http://www.rcosta.com/) 来处理美国的移民事务。 91 | 92 | 在瑞典，Newcomers 公司帮我们处理移民和重新安排工作地点这些事务。 93 | 94 | [原文链接](https://thoughtbot.com/playbook/our-company/operations) 95 | -------------------------------------------------------------------------------- /chapter-9-our-company/principles.md: -------------------------------------------------------------------------------- 1 | # 原则 2 | 3 | ## 零号原则 4 | 5 | 我们定期清除和精简政策。我们最重要的政策是「自己做最好的判断」。我们叫它零号原则。 6 | 7 | ## 最少层级 8 | 9 | 我们尽量减少工作的职称，更少的部门，更少的层级。我们倾向于根据项目和公司的目标来设置角色，而不是向老板层层汇报。我们之所以在 thoughtbot 工作是因为我们的开发和设计的技能，我们希望应用这些技能，而不是创建一个僵化的公司。 10 | 11 | ## 透明 12 | 13 | 我们避免针对彼此或者客户的私下谈话。相反，我们面对面沟通，并且在项目内、在 thoughtbot 内及公开场合使用 Slack、 Basecamp 和 GitHub 这样的工具。 14 | 15 | ## 诚实 16 | 17 | 尽管我们会体量人们的感受，致力于有建设性地合作，但是我们不能允许这些阻挡我们获取工作的成功和喜悦。我们宁愿太诚实而不是太礼貌。 18 | 19 | ## 信任 20 | 21 | 我们的标准非常高，新增一名成员需要整个面试过程中所有人的同意。也就是说，我们期待每个人都是最棒的，给每个人怀疑的权利，并鼓励每个人主动改善自己和公司。 22 | 23 | ## 持续改进 24 | 25 | 我们知道自己永远可以做得更好。所以，我们有很强烈的意愿，不用拘谨，主动改善自己和公司，以及我们的社区。 26 | 27 | [原文链接](https://thoughtbot.com/playbook/our-company/principles) 28 | -------------------------------------------------------------------------------- /chapter-9-our-company/sales.md: -------------------------------------------------------------------------------- 1 | # 营销 2 | 3 | 我们是设计师和开发人员。我们想设计和开发软件。在我们能做这些之前，我们需要找到雇佣我们的客户。以下部分介绍了我们的营销流程如何运作，以及一些常见客户问题的答案。 4 | 5 | 总体流程是： 6 | 7 | - 某人联系我们。 8 | - 我们请他们填写我们的[新项目表单](https://thoughtbot.com/hire-us)。 9 | - 我们打电话或者约他们来办公室。 10 | - 合格／不合格：我们适合客户吗？ 11 | - 合格／不合格：客户适合我们吗？ 12 | - 理解客户的愿景。 13 | - 对预计的产出达成一致。 14 | - 预估迭代。 15 | - 为迭代安排人手。 16 | - 签订合同。 17 | - 付第一个迭代的款项。 18 | - 我们开始工作。 19 | 20 | ## 线索 21 | 22 | 我们的线索通常来自[客户的推荐](http://www.quora.com/Whos-the-best-web-development-firm-in-Boston)和 Google 搜索。 23 | 24 | 我们在「Sales」看板的「Contacted」列表记录所有的线索。 25 | 26 | ![alt](http://beantalk.net/static/upload/201611/MgPDiOoJFEf9DNADkHPhKQIl.jpg) 27 | 28 | 我们为个人介绍的项目手工建立卡片。我们的新项目表单会自动创建卡片。[Zapier](http://zapier.com/) 会为我们从主要电话线中收到的电话留言创建卡片。 29 | 30 | 通常进来的线索会指派给管理总监，不过每个人都可以负责这个线索，通常负责的人会发一个简短的邮件或者打电话给潜在客户，来看双方合适不合适。在做这个之前，他们要把自己加到对应的 Trello 卡片上。 31 | 32 | 我们一般会结伴来打这个电话，一个设计师和一个开发人员一起打电话。这样让我们可以从不同角度知道这个项目有多适合或者多不适合我们，可以尽可能好地回答设计和开发问题，并且帮助我们培训和改善我们的营销流程。 33 | 34 | ## 理解产品愿景 35 | 36 | 我们的目标是在我们正式开始项目前群体思考客户的产品。一些典型的问题是： 37 | 38 | - 这个产品的独特之处是？ 39 | - 这个产品带来什么好处？ 40 | - 这个产品解决什么痛点？ 41 | - 谁当前在购买这种产品？ 42 | - 你希望谁来买这个产品？ 43 | - 顾客会喜欢你产品的哪方面？ 44 | 45 | 我们在团队全员参与营销流程。潜在客户应该有机会和他们将要一起工作的人交谈。对于要开始的项目，我们应该在管理总监不能及时响应的时候也可以应付得来。 46 | 47 | 我们使用内部工具来管理我们的日程表和可用性。我们不记录时间，不过我们确实做每周的增进计划。 48 | 49 | ## 保密协议 50 | 51 | 如果客户让我们签订保密协议，我们会这样回应： 52 | 53 | > 我们可以不签保密协议先聊聊？我们已经为数以百计的客户服务过。每年我们都和数以百计的客户接触。我们不可避免地会听到相似的创意。 54 | 55 | 如果保密协议对于客户来说是非常重要的，我们让他们充分解释下业务，确保这和我们现有的或者过去的客户不冲突。如果我们没发现冲突，项目又很合适，而且保密协议是双向的，我们就签署。如果不是双向的，我们就使用[我们的保密协议](http://thoughtbot.com/nda)。 56 | 57 | ## 角色 58 | 59 | 我们提供一个由设计师、Ruby 开发以及 iOS 开发人员组成的团队。并分配一个顾问来辅助团队，他每周在团队工作几个小时。每个人都是 [T 型人才](http://en.wikipedia.org/wiki/T-shaped_skills)，在某个领域有专长，并能够跨越职业和他人协作。 60 | 61 | 我们是人而不是「资源」，避免这么称呼彼此，因为我们知道我们是人与人之间的合作。 62 | 63 | 设计师设计用户和产品之间的交互。他们写用户界面代码。 64 | 65 | 开发人员让应用可以工作。他们写代码让应用变得「智能」。他们致力于让产品没有缺陷。他们监控性能因为速度是所有产品的一个共有特性。 66 | 67 | 开发人员让产品可以运行。他们做架构决策，并和现代化的主机公司例如 [Heroku](http://heroku.com/)打交道，他们的员工数量是我们外包的运营团队的两倍。 68 | 69 | 开发人员实现功能。他们编写和维护 HTML、CSS、JavaScript、Ruby、SQL 以及其他代码。他们设置并达到开发规范，保持[持续集成](http://www.extremeprogramming.org/rules/integrateoften.html)构建通过，并评审彼此的代码。 70 | 71 | 顾问提供一个公正的角度。他们进行每周会议保证周到周的持续沟通。他们对项目的高层次的目标保持关注，这对他们来说更容易一些，因为他们不必每天身处细节之中。他们在和团队同甘共苦，并在项目失控时帮助解决问题。 72 | 73 | 在合适的时候，他们和客户沟通来增加或者减少人手来正确地处理项目。 74 | 75 | 顾问不是项目经理。其他的成员不用向他报告。顾问也不是技术或者设计的负责人。顾问不必是管理总监或者 CXO，但是因为时间的灵活性通常是他们担任。在 thoughtbot 任何人都可以顾问一个项目。如果主要销售人员不是顾问，那么应该平滑交接一下。 76 | 77 | 虽然每个人都有自己的角色，团队必须要称为团队。 78 | 79 | 每个人都有责任每天提交高质量的工作，忠诚于产品的愿景，沟通他们的计划和安排，做出艰难的决定，如果时间和能力有限无法完成任务时要及时移交工作，保持团队士气高涨，坚持不懈。 80 | 81 | ## 不做固定预算竞标 82 | 83 | 有的咨询项目是以一份需求文档或者招标书（Request For Proposal, RFP）开始的。需求文档常常十分详细。 84 | 85 | 但是这份文档能够包含最理想的功能集合的概率是极低的。最佳的功能集合是在用户访谈，原型制作，交付实际代码以及从真实用户处得到反馈过程中获取的。 86 | 87 | 基于这份文档，客户常常会期待咨询公司提供一个精确的时间范围和报价。这种合同风格注定了从第一天开始客户和咨询公司之间就是互相对立的。他们不是关注设计产品，或者评估哪些假设是错误的，而是在纠缠文档中很久以前写下的一句话究竟是什么意思，或者是一些随意制定的截止日期。有时候这比谈判更糟糕，因为大家各自有不同的印象，为了追根溯源争论不休。 88 | 89 | 所以你可以想象的到，我们不做固定报价的投标，固定功能集合的提案。 90 | 91 | ## 预算 92 | 93 | 我们[需要知道客户的预算](https://medium.com/what-i-learned-today/a61ec864c898)。客户通常是不愿意提及他们的预算的，不过预算有助于确定可以做多少工作。可以节省时间。如果他们不知道自己的预算，我们考虑其他方式。 94 | 95 | 我们将产品面世分为不同的阶段，在产品的每个阶段我们做如下的工作来提高成功的机会： 96 | 97 | - 集中在一个小的功能子集上。 98 | - 设计有价值的用户体验。 99 | - 和用户之间建立有价值的关系。 100 | - 为市场活动做预算，让用户了解产品。 101 | - 为产品设计交互，让用户引导更多的用户来使用产品。 102 | 103 | ## 费用 104 | 105 | 我们按照每个人每周来收费。我们每周为客户工作四天。我们对于设计师和开发人员收取同样的费用。每周需要完成的工作会指明需要哪些技能。需要的人数就决定了费用以及每周能完成的工作。 106 | 107 | 在解释我们的收费模式的时候，有时候我们会告诉我们的潜在客户「时间和物料」和他们招聘一个年度员工是基本一样的，只不过对他们来说风险更小，因为： 108 | 109 | - 我们的团队更有经验。我们可能面试了上千人来找出现在这样一群有天分的成员来一起工作。 110 | - 我们一起做过很多项目。我们有熟悉的合作方式。 111 | - 短期项目需要的费用更少。 112 | - 我们的时间可以预计（4 天／星期）并且保持不变。 113 | - 如果有人生病、离职或者有新队员就绪，我们可以快速调整人员。 114 | 115 | 我们不会提供详细的发票条目。客户通过项目管理工具（Trello)、聊天室（Slack）、版本控制系统（GitHub）以及持续的沟通，总能及时了解项目的进展。 116 | 117 | ## 典型项目 118 | 119 | 我们的典型项目： 120 | 121 | - 产品设计 Sprint，两个人，一星期 122 | - 「零到第一个版本」，两个人，四个星期 123 | - 「填补内部成员空缺，直到招到合适的人」，2 个人，3 个月。 124 | - 「现有内部团队的人力资源扩充」，3 个人，6 个月。 125 | - 「[维护团队](http://www.thoughtbot.com/maintenance)」，按月付费模式。 126 | 127 | 很多时候我们的客户预算就到做「第一版」。他们随后进行一轮 beta 版邀请，花时间进行市场推广，再融一轮资金，或者做几个月的营收。他们再次回来做下一轮的设计和开发，这时他们对于产品要往什么方向走有更清晰的认识。 128 | 129 | 从功能集合并不一定能够推导出开发它所需要的时间。有时候一个简单的产品，我们需要迭代非常多次。我们喜欢和这样的客户合作，他们懂得伟大的产品需要足够的时间来打磨。 130 | 131 | 作为回报，我们知道我们绝不可以滥用客户对我们的信任。我们应该竭尽全力让我们的时间产生最大的价值。诸如「Research」看板，「Code」内部聊天室，以及共享的 dotfiles，确保问题出现时，我们已有一套最高水准的工具和技巧。 132 | 133 | ## 合同 134 | 135 | 我们用 Dropbox 存储合同，目录分为待定、进行中、老客户、流失客户。 136 | 137 | 咨询提案和合同包含 ： 138 | 139 | - 一页纸的预定工作概述 140 | - 我们的每周费率 141 | - [Net 15](http://en.wikipedia.org/wiki/Net_15) 支付条款 142 | - 预付前两周费用才开始工作 143 | - 两周之后，每周工作结束后，周六早上本周的发票就会发出去 144 | - 双方约定当客户支付了本周费用之后他们就拥有本周工作的源代码 145 | - 双方约定彼此都不使用侵权的材料 146 | - 双方约定都不想 web 主机提供商提交滥用或者不道德的内容 147 | - 双方约定合同是双向自由的，任一方可以在一周结束后决定停止合作 148 | - 一个签字页 149 | 150 | ## 发票 151 | 152 | 我们使用 [Harvest](https://www.getharvest.com/) 在每周结束后给客户发送发票。 153 | 154 | 它可以自动发送周期性发票，这样我们就不会在一周结束时忘记收费。它可以自动发送迟付费通知，这样就可以避免一些关于账单的尴尬对话。 155 | 156 | 客户可以通过支票或者转账付费。 157 | 158 | 在 Harvest 的项目信息中，我们会登记谁应该在这个项目中收到佣金。我们常常给参与营销阶段的两三个人分 5% 的佣金。 159 | 160 | [原文链接](https://thoughtbot.com/playbook/our-company/sales) 161 | -------------------------------------------------------------------------------- /chapter-9-our-company/sharing.md: -------------------------------------------------------------------------------- 1 | # 分享 2 | 3 | 我们从博客、推特和电子报上学到数不清的知识。我们总是想办法给予回馈。 4 | 5 | ## 博客 6 | 7 | 我们的博客叫做：GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS。 8 | 9 | 我们使用 Editorial Calendar 这个 Trello 看板来协调和发布我们的博客。 10 | 11 | 当有人要写博客的时候，他在 Next up 列表中用标题写一个 Trello 卡片，并将任务指派给他自己。 12 | 13 | 花点时间写一个很棒的标题。它有助于你汇聚焦点，明确文章的目的，并第一时间抓住读者的注意力。 14 | 15 | 当我们开始协作，我们把 Trello 卡片拖动到「Draft」列表。 16 | 17 | 我们用 Markdown 书写博客，并存放在我们 GitHub 上博客的仓库中。我们为文章添加标签，这样可以帮助我们的读者找到相关文章。 18 | 19 | 当我们准备好接受团队成员的反馈，我们将卡片拖动到「In Reivew」列，并在 Slack 分享 Trello 卡片的链接。我们在大家的反馈和我们自己的判断的基础上来修改文章。 20 | 21 | 当文章可以发布了，我们设置一个发布时间，合并，并发布文章。 22 | 23 | 我们的 RSS 源、Zapier、Buffer 账号已经设置好了可以自动工作，它们可以自动链接我们的文章到 Twitter、Facebook、Google+ 和 LinkedIn。 24 | 25 | 我们也将文章链接贴到 Hacker News、Reddit、Delicious、Pinboard 以及其他合适的网站。 26 | 27 | 最后我们把 Trello 卡片拖动到「Live」列。 28 | 29 | ## Twitter 30 | 31 | 团队的每个人都可以访问我们的 thoughtbot Twitter 账号。如果这条 tweet 和时间关系不大，我们就使用 Buffer 来按照一定的时间计划来发布。 32 | 33 | 我们希望我们的 Twitter 账号是互动的、随意的、真实的。我们像是面对真人一样谈吐，并要有幽默感。鼓励使用双关语。我们致力于保持高质量，让每条 tweet 都受欢迎。我们着力避免拼写错误，使用正确的标点符号。我们要尊重关注我们的人。 34 | 35 | 和尽量多的听众沟通，不要以一个 Twitter 用户名开始一条 tweet。 36 | 37 | 一些 tweet 的创意包括宣布聚会，开源项目发布，关于新工具或者技术的热情宣传，Git、Unix 和 Vim 的技巧，到我们博客的链接，以及现在还没有在 Hacker News 或者 Twitter 上发布的优秀的博客文章。 38 | 39 | 我们拥有一个认证的 Twitter 账号，我们也是 Twitter Ads 客户。使用这些工具我们可以分析我们的 retweets、favorites、replies、clicks、follows、unfollows，以及不同的 tweet 之间的吸引力。 40 | 41 | Tweet 的推广活动是短期带来流量的最佳方式。每次活动确定目标为 10-25 个相近的、相关的用户名。创建不同主题的活动，我们可以追踪每次主题的表现。 42 | 43 | ## 调研 44 | 45 | 我们在「Research」Trello 看板追踪我们进行中的实验。 46 | 47 | 我们严密地对新工具和新技术进行实验。一旦实验完成，我们在适当的渠道发布实验结果。可以是这个 Playbook，我们的博客、twitter 或者其他地方。 48 | 49 | ## 开源 50 | 51 | 我们创建了一系列的开源库来执行我们的常见任务并回馈给社区。 52 | 53 | 当有个人负责维护时我们的开源项目可以做的更好。每个代码仓库都有一个负责人来确保持续前行。负责人不一定要做大量的实际工作，他的责任应该包括： 54 | 55 | - 理解底层代码和代码库的目标。 56 | - 评审和合并 pull request。 57 | - 回复和关闭缺陷报告。 58 | - 合适的时候发布新的 gem。 59 | - 鼓励人们从代码库中领取有用的任务。 60 | - 写博客、tweet 以及用其他推广方式来宣布新版本发布和技巧。 61 | 62 | 我们在「Investment Time」看板记录当前开源项目的负责人。 63 | 64 | 每个 thoughtbot 的开发人员、设计师和新人都有我们开源项目的提交权限，我们遵守如下规范： 65 | 66 | - 你可以和项目负责人交流对项目的建议，以及他是不是愿意接纳你的想法。 67 | - 发 pull request 而不是直接向 master 提交代码。 68 | - 试着帮助已有的 pull request 或者缺陷报告。 69 | - 为文档打补丁是了解项目的好方法。 70 | 71 | 有新的想法？在客户项目中发现了有用且可以重用的部分？非常好！一些规范： 72 | 73 | - 提取通常比全新的想法更有用，因为你在提取已经被证明有用的东西。 74 | - 如果你创建一个新的库，你要负责这个项目，至少是开始阶段。确定你有时间来维护它。 75 | - 不要尝试重新发明轮子。做一下调研，确保你的问题还没有被解决。 76 | - 在客户项目时间内修复影响客户项目的缺陷或者增加可以真的帮助客户项目的新特性是可以的。决大部分开源工作应该是周五的投资时间内完成。 77 | - 想一想你的创意是不是作为一个已有项目的 pull request 更合理。 78 | 79 | [原文链接](https://thoughtbot.com/playbook/our-company/sharing) 80 | -------------------------------------------------------------------------------- /chapter-9-our-company/time.md: -------------------------------------------------------------------------------- 1 | # 时间 2 | 3 | 我们以一个可持续的节奏工作。我们一周四天为客户做咨询工作，一天用来做「投资时间」。我们通常周一到周四做客户项目，周五用来做时间投资。 4 | 5 | 当从客户任务中脱身而出的时候，我们和其他的团队成员讨论看会不会影响任务安排。 6 | 7 | 在间断期的沟通会让收到消息的人产生一种紧迫的感觉，所以我们尽可能不去产生这种紧迫感。 8 | 9 | 除非真的非常紧急，我们会忽略间断期内的消息，当我们回来工作时再处理它。 10 | 11 | ## 咨询 12 | 13 | 我们通过咨询项目盈利。这些项目从营销阶段开始，通常经过设计、开发、交付、监控、和迭代流程。我们做好工作，客户会竞相找我们合作，我们要创造良好的工作环境，确保我们的队员不会离开我们的团队。 14 | 15 | ## 投资 16 | 17 | 投资时间是用来花在我们自己，我们的公司，我们的社区上的时间。通常来说是指做我们感兴趣的事情，例如学一个新的编程语言，为开源项目做贡献，讨论有趣的事情，参加社区活动，或者读有教益的书。目标是鼓励个体提高自己并和团队其他成员分享知识。 18 | 19 | 我们在「投资时间」看板上管理我们的投资工作。 20 | 21 | 周五在客户项目的间断期，可以： 22 | 23 | - 为开源软件做贡献 24 | - 写博客文章。在「Editorial Calendar」这个 Trello 看板上管理任务 25 | - 从 dotfiles 中获取或者向它贡献内容 26 | - 浏览「研究」看板中关于工具和流程的更新 27 | - 为大会和小聚的演讲准备或者提交提案 28 | - 在 Upcase、 Metis、Galvanize、Dev Bootcamp 或者 RailsBridge，或者其他靠谱的学习社区中担当导师 29 | 30 | 其他能够更加直接产生收益的活动有： 31 | 32 | - 协助营销 33 | - 和新人见面或者让已有的友谊更深厚 34 | - 为已有的书做贡献，或者写一本新的 35 | - 在 Upcase 上创建新内容。在「Upcase Content」 Tello 看板上管理。可以从任何一个列表上获取任务，或者「Ideas」列表上加一个新想法 36 | - 在 Upcase 论坛回答问题 37 | - 在 Hound 项目上工作 38 | - 帮助 FormKeep 项目 39 | - 帮助未发布的产品 40 | - 创建一个团队，运行产品设计 sprint，为你的创意创造产品 41 | 42 | 我们的普通周五投资时间，和客户项目之间的空档期是不同的。 43 | 44 | 客户项目之间的空档期时间更强烈倾向于产生营收的活动。应该是人脉和营销，为已经产生营收的产品和服务工作，或者是创建新的可以产生营收的东西。 45 | 46 | 因为这个空档期在新的客户项目到来的时候就会消失，而且我们无法支持长时间没有营收的活动，在使用这段空档期时间的时候要有紧迫感。 47 | 48 | 验证想法，交付，尽快产生营收应该放在第一位。我们不应该几周都没有东西可以演示，我们应该向对待客户项目一样使用同样的约束和流程。 49 | 50 | 对于长期合作的客户，如果条件允许，我们会在办公室为他们安排座位。我们欢迎客户在工作时间到访我们的办公室，包括周五。我们为如何使用周五时间设置明确的目标，客户可以选择参与我们周五的活动，做自己的事情，或者周五的时候外出办公。所有周五在办公室的人，我们都请大家一起去吃午餐。 51 | 52 | [原文链接](https://thoughtbot.com/playbook/our-company/time) 53 | --------------------------------------------------------------------------------