SegmentFault獨家專訪fengche.co：小而美的團隊協做工具

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. 有正確的渠道去推廣到這些願意買單的人。

當咱們啓動項目去解決本身的問題時，咱們假設的是這個世界上確定有其餘人跟咱們同樣也有這個問題，因此 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的一些文章，主題涉及技術、開發流程、創業等，推薦給你們。

• 讓代碼審查成爲你的團隊習慣

• Rails 初學者指南

• 實用 Git 工做流

• 如何吸引技術合夥人?

• 不要讓辦公室成爲你的效率殺手

• 如何開始你的 SOHO 之旅 (1)

• 如何開始你的 SOHO 之旅 (2)

• 我如何把薪水從 50人民幣/天 提高到 100美圓/小時的 (1)

• 我如何把薪水從 50人民幣/天 提高到 100美圓/小時的 (2)