關於作產品的幾點思考

1、戰略失誤

我作的第一款產品在今天看來，絕對是屬於戰略失誤的典型。從整個市場來看，這款產品的領域已經存在太多的典型和優秀的產品，和絕大多數領域和絕大多數產品經理同樣，在產品層面上都不會有創新，作的事情只是「複製」一份產品方案，就是一種「重造輪子」的複製一份市面上的解決方案服務商的產品或競品的功能。時至今日細細思考，這款產品的特點和功能價值不突出，功能不穩定，交互體驗差。耗時耗力、費盡心思不斷地作大量相關瀏覽、梳理、概括、總結綜合而成的產品，設計奇葩，交互奇怪。經過觀察，這類型的領域不少，好比在線教育、電商、知識付費等領域。對於這類型領域的產品，其實是不值得這樣花費的，這些領域在市面上有不少產品解決方案的服務商，幾千或者一兩萬就可以購買到一套成熟的產品方案，可是若是本身研發，時間成本+人力成本，一年至少百萬以上。最爲重要的是時間成本，頗有可能讓公司錯失了關鍵的或最佳的運營窗口期。

在同類型產品領域市場已經存在太多的典型產品的狀況下，咱們應該經過「運營」的角度來設計產品功能。不一樣領域不一樣產品，真正的創新是在「運營」層面上的，根據不一樣的「運營場景」來設計產品功能，考慮產品需求的市場背景和運營場景。而這款產品在設計之初，就過多的對標了競品的功能和設計，致使花費大量研發時間和人力在產品的功能上，反而應該是產品自己的特點和附加值的基本盤和核心競爭力，均沒有時間進行集成和開發。試錯成本很高，我要感謝公司給個人寬容及成長。

2、戰術失誤

此外，在第一款產品上，戰術一樣失誤。因爲產品的功能和現有市場領域產品的功能類似，在研發力量不足的狀況下，耗費太長週期「重造輪子」，沒有充分利用開源的力量。產品實現的功能，在GitHub這樣的技術社區也能找出N多個來，相似功能控件等模塊化的方案，在許可容許的條件下咱們均可以引用於產品中，這樣能夠加速咱們的產品功能實現。將錢和研發力量花在運營層面上，纔是最高回報率的投入。

實質上產品自己僅僅只是一個內容的承載平臺，而咱們卻花費了一年多的時間在產品自己的功能實現上，內容運營自己還將來得及投入研發力量着手解決，業務需求已經開始推着咱們不得不投入力量進行內容運營的開發工做。這就致使咱們的工做越作越多，一旦有突發事件和應急事宜，項目成員都會手忙腳亂。徹底打亂以前的節奏，等應急事宜忙完回來，項目又得從新開始進行梳理。

3、管理失誤

從項目管理角度上來看，也是存在着很明顯的失誤。包括天天代碼的提交，最開始項目的構建徹底是程序員本地進行開發，項目成員之間經過相互拷貝代碼的方式進行代碼合併和代碼版本管理。致使每次版本的合併及更新都會出現問題，有時甚至分不清楚主次版本，甚至還會致使部分代碼丟失。這徹底是屬於代碼管理上的嚴重失誤，在影響效率的同時，也形成項目開發的混亂。後續採用git等工具進行代碼版本管理，狀況稍微獲得改善，因爲我本人並無進入開發，僅管控進度，項目成員之間的代碼質量屬於放養式管理，項目開發人員沒有按期進行Code Review，代碼質量出現不可控因素，也致使後續一系列的功能優化和修改均費時費力。

我在項目中給予了他們很是充分的信任，信任他們能夠把一切事情都作好。但我沒有在正確的時候給予他們正確的指引，項目中出現的困難點，我也沒有幫助他們解決，甚至於沒有給出思路。全部的一切，都靠他們本身完成。我在這個項目裏作的，就是對接需求，催進度。再無第三件事。

基於以上緣由，我掉以輕心，沒有在項目初期進行項目的設計和規劃，未指定任何開發規範。僅僅告訴開發的同事要多複用，也未檢查他們是否真的複用了。

項目開發中的需求變動，需求反饋意見，我都僅僅是告知他們一聲，未作詳細的修改規劃，全部事情都靠嘴說，全部變更都放在了我和他們的腦子裏。

對項目上心程度不夠，未對需求變動作控制和管理。全部變動都壓給了開發的同事。

整個項目以及其不規範的方式在運行，我也未在其中起到控制做用，項目開發一團亂麻。

項目開發過程當中，也未讓開發間互相進行代碼review，也沒有進行代碼評審會。其實代碼中出現了不少問題，最後檢查代碼的時候，發現各類命名不規範、代碼複用不到位、簡單邏輯複雜寫等等。而這些問題，很大一部分都是早期未作規定，未指定人負責項目、未進行早期code review形成的。開發各自爲戰，不免形成代碼問題。代碼質量的問題，淋漓盡致的體現的在項目中，項目中的諸多bug，都是由於代碼不規範引發的。甚至於開發人員本身對本身寫過的東西，都有些拎不清了。

綜上，致使這款產品的特點和功能價值不突出，功能不穩定，交互體驗差。如今還在投入研發力量進行修補和優化。