fengche.co是一个刚刚好的中小团队协作工具。原名pragmatic.ly，2013年以来主攻国内市场，使用了更好记的新域。经过多次迭代的fengche.co，始终保持了简洁的风格。
卡片式的控制面板，风格简约，项目完成度，近期的活跃度等基本信息一目了然。任务模板主要按照任务周期分为三种：个人的Todo模板、协作模板和软件开发模板，协作模板增加了“进行中”状态，软件开发模板在协作模板的基础上增加了“验收通过”状态。
单页面，实时应用，使得任务的创建、查看、管理无比流畅。
按下快捷键 n 键就可以直接创建新任务。方向键或j/k切换任务，附加shift切换任务状态，/搜索。快捷键的设置少而精，既保证了常用操作都可以通过快捷键完成，双手无需离开键盘，又避免了繁杂的快捷键，增加用户的记忆负担。可以通过拖动的方式对任务进行排序，移动任务到列表，以及分配任务给成员，方便直观。
所有的操作都是实时的，无需重复刷新页面。即时聊天般的体验让讨论更加愉快。
每个任务的历史操作和讨论都完整地保存在一起，让你快速了解任务进展情况。动态摘要能让你迅速地了解进度。单页面设计，整个项目的状态、计划、任务进展、交流讨论、验收都在同一个页面上，极大地提高了效率，避免反复切换。
fengche.co 目前主打的用户群是技术创业公司，因此任务描述使用GitHub Flavored Markdown，对开发者十分友好。还支持绑定GitHub、Bitbucket、Gitlab的hook，方便集成提交日志的记录。
SegmentFault独家专访了fengche.co的创始人Ye Dingding，带大家走进fengche.co的幕后。
SegmentFault: 当初是怎么想到要开发这样一个协作工具的？
Ye Dingding: 我们在做 fengche.co 前是在做另一个企业社交工具 Present.ly，开发中尝试了很多工具，基本的感觉是现有的工具已经跟不上团队自身素质发展的需要，或者说都算是上一代的产品，所以我们在 2011 年底决定自己去创造一个更加适合现代团队的目标驱动型的协作工具。我们自己也在这些年的工作中，合作过不少团队，有创业型的，也有咨询类型的，还有大公司，我们很清楚知道为啥团队工作低效或者项目会失控，fengche.co 是我们对这些问题的一个解决方案，来传播我们认为好的理念和工作方式，让团队能专注高效的协作，创造更多的价值。
SegmentFault: 给大家介绍下fengche.co的技术架构吧。
Ye Dingding: Fengche.co 算是一个重客户端应用。服务端使用的是 Rails 3.2，只用于做数据 API 服务器，逻辑部分基本都在客户端，我们用的是一个轻量级的前端 MVC 库 Spine.JS 和程序员最喜欢的前端框架 Bootstrap，包括移动端也是用的 Spine Mobile 和 Zepto。在实时通讯方面，我们是用基于 WebSocket 的一个在线服务 Pusher。包括我们的测试用RSpec，Cucumber，Jasmine，JS Coverage，都是为了保证重客户端应用的健壮性。我们以前的测试覆盖率比较夸张，很全，现在已经降下来了，在我们理解了不应该过度的做开发以后……
SegmentFault: “过度开发”算是技术创业者的一个比较强的倾向。你在pragmatic.ly两周年回顾中就提到过“过早和过多地做开发”是一条弯路：
当我们决定要启动这个项目的时候，我们没有去找更多的用户聊天，聆听他们的想法，而是选择直接进入了开发阶段，美其名曰解决自己的问题。我们不停得去假想用户的需求，所有人都在做开发，直到发布。”
但是，fengche.co一开始就是因为没有找到好用的适合小团队的协作工具而开发的。因此，这个提法好像和37signals的主张有些不一致：
我们做的产品是我们自己的生意需要用到的。 比如，想关注我们商谈过的某人的动向，我们说过什么， 以及什么时候我们再跟进。所有我们做了 Highrise，我们的联系人管理软件。我们遇到了问题，所有自己解决。当你开发某种产品或者服务时，每天都要解决几百个小决定。如果你解决的是别人的问题，你每天都会在黑暗里倍感刺痛。当你解决自己问题时，光明来了。你明确知道什么是对的。
能谈谈这方面的经验体会么？
Ye Dingding: 我个人的观点，我们只看到了 37signals 的主张，却没有去代入他所处的背景。对于互联网创业者来说，主要有两种风险，技术风险和市场风险。一般而言，对于技术人员创业来说，技术风险很低，市场风险很高。但是，37signals 不是，Jason Fried 和 DHH 都非常擅长卖自己，它的市场风险是非常低的，有 Rails，有 Rework，有 Getting Real，有新出的 Remote 等等，这些都能帮他建立起非常好的 marketing channel，所以他可以说我只解决自己的问题。这些是绝大多数技术创业者所不具备的，包括我们。
一个项目要成功，要有三点：
解决了真正的问题
这个问题有人愿意买单
有正确的渠道去推广到这些愿意买单的人。
当我们启动项目去解决自己的问题时，我们假设的是这个世界上肯定有其他人跟我们一样也有这个问题，所以 1 是没有问题的。那么，从比例中肯定也有人愿意买单，2 有了一部分，但是还是有一个问题，这个量够不够？第 3 点很有问题，根本没有在开始时去思考 channel 的事情。我们知道这个东西是有价值的，但是我们不知道用户到底是愿意为具体怎样的价值付钱，哪些价值是他们不愿意买单的。同时，当开发到了一定阶段后，也会非常被动，产品的改进需要很多意见，但是却没有真正的用户群能提供意见。这也是我说的很多技术团队都会犯得错误，过早和过多的去做开发。
SegmentFault: 说到推广渠道，刚开始的时候，pragmatic.ly主攻海外市场，认为海外市场成熟，教育用户成本低，付费习惯好。后来发现由于协作产品竞争较多，认知度缺乏，获取天使用户的渠道很少。而专注做国内后，有“柳暗花明”的感觉。这可能和你们团队在国内技术圈、创业界的影响力有关。那么，对于不具备这一优势的创业公司，产品的主攻市场又该如果选择呢？
Ye Dingding: 其实说实在的，我们团队很草根，在国内技术圈和创业界没有任何影响，我们有的只是我们的实战经验和实际知识，所有你觉得可能的影响都是我们在创业后去建立的。所以我们针对我们的目标用户，去建立信息传递的渠道，去建立交集的圈子。所以，对于创业公司来说，既然选择了这条路和这个方向，就去努力做好它，好好做产品，做好产品。
SegmentFault: Fengche.co主要是通过远程的方式打造出来的，能谈谈远程办公的优点么？
Ye Dingding: 关于远程办公，可以参考我最近的文章：远程工作，你准备好了吗？
对于我们团队来说，它给我们带来了自由的工作方式、更好的团队成员、更少的运营成本、更多的工作时间、更好的工作效率。
SegmentFault: 其实Dingding从07年到现在一直以远程办公为主，做过独立开发者，也管理过多达18人的远程团队。你觉得远程办公面临的最大挑战是什么？
Ye Dingding: 项目管理问题，要明确目标、状态同步、沟通交流，这些在远程的时候都有更多的挑战。明确目标让团队拧成一股绳，状态同步和沟通交流让团队同时使力。而这个就是 fengche.co 要解决的问题，它非常适合于有异地办公需求的团队来协作和做项目管理。
SegmentFault: fengche.co是一个很好的状态同步和沟通交流的工具。除了fengche.co，你们还使用远程协作工具？
Ye Dingding: 在每天的工作中，我们只用两个协作工具：HipChat 和 Fengche.co。HipChat 用来做群聊，high level 或者碎片的，Fengche.co 来管理项目。我们喜欢功能单一但是把一件事情做到极致的工具。还有些用但是频率不那么高的工具有 Skype 和 Dropbox。最近在尝试用为知笔记来代替 Dropbox。
SegmentFault: 无论是远程办公还是本地办公，开发者长时间面对电脑，时间久了身体容易出现各种问题。Dingding给我们介绍下锻炼和保护身体的经验吧？
Ye Dingding: 忏愧，锻炼是够的，身体并不好，很多久坐工作者的职业病，比如腰，比较颈。2013年4月份，我入了 Herman Miller Embody 椅子，觉得是很划算的一个投资。
我觉得程序员久坐太正常了，所以一定要经常锻炼，能每天就更好，让锻炼成为工作的一部分。
SegmentFault: 目前fengche.co修改任务描述是没有通知的，这个设计有哪些考虑？
Ye Dingding: 因为我们提供的 edit it place 没有显式的保存，我们会做自动保存，所以担心如果提供通知的话，会有很多消息产生，对用户来说是个干扰。我觉得描述的版本控制系统不是不能做，而是这个功能相对来说不是那么重要，在我们有限的资源条件下，会先专注于更高优先级的，如果以后有时间可以再改进。
SegmentFault: 邮件通知是很好用的功能，直接通过邮件新建任务或参与任务讨论很方便。但是也可能会觉得邮件有点多。现在在用户设置有“智能提醒”选项，当网页或手机在线时不提醒。有考虑提供一些其他设置选项么？只提醒优先级为高的任务，只提醒分配给自己的任务，或者@给自己的任务之类。
Ye Dingding: 在线不提醒是我们最近刚刚增加的功能，更细粒度的提醒会在后续跟上。
邮件通知是个很纠结的事，不同的人对于邮件有不同的习惯。企业服务又会很容易产生大量的邮件，可能对用户是个骚扰。我们目前在思考怎么找到一个更好的平衡，让用户用起来最爽。
SegmentFault: fengche.co主办过Ruby China Conf，开源了mails_viewer（邮件预览Rails gem）smart-time-ago（智能灵活的更新相对时间的jQuery库）等模块，Dingding是Ruby社区的核心人物，对整个Ruby社区作了很多贡献。能谈谈对Ruby语言本身和对国内Ruby社区的感觉么？
Ye Dingding: 对于 Ruby 语言来说，这是一个能让我感觉到快乐的语言，这就够了。这也是 Ruby 的设计目标之一，让开发者，用的人快乐。
国内的 Ruby 社区在我看来虽然小，但是很有爱。从 Ruby Tuesday, Rails Girls, RubyConf China, 都是没有掺杂一点杂质的活动，大家都是无私的奉献，去分享自己的知识，很喜欢。整个 Ruby 社区也是很包容万象，比较宽容，这也跟玩 Ruby 的人一般很少只玩 Ruby。
SegmentFault: Ruby很强调快乐编程、优雅编程，但是真正制作产品的时候，往往要兼顾其他因素，可能需要先用不那么优雅的方式快速做出产品，将改良延后。同理，为了求稳，技术选项的时候也会偏向成熟保守的方案，而不是更新更酷的方案。Fengche.co在开发中是如何平衡这两极的呢？
Ye Dingding: Ruby/Rails 已经非常成熟，对我来说用这些就是保守，:) 我觉得不是求稳去选择这些方案，而是尽可能的去减少开发的时间，去验证想法和市场，如同我之前所讲的，市场风险对于技术团队来说才是需要花时间去克服的。
至于 quick & dirty, 我们虽然知道要这么做，也在努力靠，但是我们骨子里设计的架构和写出的代码都已经不是那么的 dirty 了... -,-
SegmentFault: Dingding和Terry、Daniel、Kevin、Yi-Ting等主持的Teahour.fm，是非常有意思的播客。2014年Teahour会给听众带来更多惊喜么？
Ye Dingding: Absolutely，敬请期待！
SegmentFault: 国外这类面向开发者的播客非常多，国内就…… 如果有人打算仿效Teahour，Dingding能传授一些经验么？
Ye Dingding: Just do it. 有几个人，有网络，有话筒，就可以了。关键是去做了，坚持下来了。做博客很需要执行力。
fengche.co，其简洁的界面设计、明了的信息组织、极速的用户体验，让你专注、有序、高效地工作。最近刚推出了Android和iOS客户端，值得一试。
fengche.co的团队
-
叶玎玎是一位七年远程工作者，[Fengche.co](https://fengche.co) 联合创始人和系统架构师，[RubyConf China](http://rubyconfchina.org) 组织者，[Teahour.FM](http://teahour.fm) 联合主播。开源狂热者，喜欢解决各种疑难杂症，完美主义兼强迫症者。喜欢研究开发流程及方法论，关注如何改善团队协作，希望 Fengche.co 能帮助技术创业团队更好地做产品！ -
太檑有超过 8 年的 Web 应用开发经验，同时也曾是企业协作平台 Presently/Socialspring 的核心开发人员。他是中国 RubyConf 的讲师，国内最好的 Rails 视频教学网站 Railscasts China 的创始人和目前国内程序员领域 #1 的播客节目 Teahour.FM 的联合主持人。 -
何斌崇尚极简，可用性永远在他设计的第一位。目前他和太太及可爱的女儿居住在一个宁静的小山村，所以在他的设计里有许多清新自然的元素。除了设计之外，他同时对技术保持着热情，了解如何在开发上和设计上取得一个平衡。 -
从 PHP 转到 Ruby 的程序宅，喜欢钻研，分享和传播写代码的心得和体会。沉迷于测试驱动的设计和架构研究，努力做一名出色的架构师。
延伸阅读
fengche.co团队成员Ye Dingding和Terry Tai的一些文章，主题涉及技术、开发流程、创业等，推荐给大家。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。