是一個剛剛好的中小團隊協作工具。原名
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 算是一個重用戶端應用。服務端使用的是
Rails3.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 都非常擅長賣自己，它的市場風險是非常低的，有
，有
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用戶端，值得一試。