對創業公司的思考

前言

身處一家創業公司,每個人都不是為了輕松與安穩而來的,每個人都是帶著干事業的激情與對成功的渴望而來的。然而創業公司,人員不夠充足、流程不夠規范,從而造成效率不高,我想這是每個創業公司不可避免的問題,也是不得不解決的問題。在這里,總結一下我所發現的問題,以及我所擬想的解決方案。

我發現的問題與解決方案

根據自身情況總結了一下幾個問題,問題確實存在,希望創業者可以用正確的姿態來面對并解決這些問題。

1.產品邏輯不明確。
問題描述:

創業公司,尤其是剛剛做第一版產品的公司,產品的邏輯基本都是老板一個人所構想出來的,老板再將這產品邏輯通過對話的方式傳達給每一個開發人員。在這個傳達的過程中,產品的邏輯極有可能會被扭曲,因為每個人在理解這個邏輯的過程中都會或多或少的加入個人的理解,甚至有些入職晚的同事根本就沒有完整的了解整個邏輯。造成的結果就是每個人腦子中所呈現的產品或多或少都會有一些偏差。

解決方案:

這對這個問題,談一談我個人所想的解決方案。第一,所有人都參加到產品的設計中來,一個好的產品絕不是一個人所能創造出來的,而是有團隊每個人的智慧所碰撞出來的,也一定是經過多次的產品會議才能確定下來的。第二,對產品的設計一定要深入到細節,問題早發現總比晚發現要好,這個道理大家都懂。如果產品的設計階段就能把大部分的細節問題找出來,那么開發階段就不會浪費很多時間。第三,產品存檔,產品的設計過程中,每發現一個問題我們都要記錄,產品每確定一部分更需要記錄,從而避免在同樣的問題上浪費時間。當然最終的產品文檔至關重要,因為他決定了今后開發的路。切記一定是要文檔的形式而不是記憶的形式。

2.缺少領導人
問題描述:

缺少領導人,更準確的說是缺少拍板的人。老板肯定是最高決策著,但是老板很忙,并不會隨叫隨到。當在開發過程中,碰到不解決不能繼續進行的問題,而老板又不在身邊的時,這就需要有人能夠站出來做出決策,從而減少等待時間。究其原因,為什么碰到大大小小的問題,都要請示老板呢,因為大部分員工害怕承擔責任,害怕自己的擅自決定惹怒老板。

解決方案:

在開發人群中,需要一個老板的代言人,當老板在忙其他事情時,這個人有權利并且有責任去做一些決策。無論是對內還是對外,這個人其他一個掌控大局的作用。

3.談論會不夠多
問題描述:

團隊合作溝通最重要,在我入職的這段時間里,只經歷過一次會議。而在我上一段工作經歷中,從產品的發起到產品的上線都會經歷各種討論會,并且是全員參加的會議,例如:產品會N次,UI評審會,技術評審會N次,進度統計與問題搜集會N次。

解決方案:

這個問題的解決方案也就比較明顯了,就是多開會,這里的會是正式的會,而不是閑聊式的會;這里的會是有備而來的會,而不是湊人頭的會。會前每個人總結自己遇到的問題,會上拋出問題集體解決。

4.問題沒有集中處理
問題描述:

在開發過程中,尤其是開發尾聲,老板和同事會拿著產品來體驗,當發現問題后直接找到開發人員要求修改。這樣造成的負面影響有兩個,一是影響開發人員手頭的工作,二是開發人員在忙其他的事情,回頭又把這個問題給忘記。所以問題零零碎碎的拋給開發人員,不僅會影響開發人員的進度,而且容易被遺漏。

解決方案:

最簡單粗暴的解決方案就是招一個專業測試人員。就算沒有專業的測試人員,也需要指定一個問題搜集者,用戶的問題反饋要集中到這個人手里做好記錄,而不是以口頭形式一個一個的拋給開發人員。另外我們本身就是技術團隊,更應該利用好一些技術產品,也就是Bug管理工具,來更好的管理Bug

5.忽略代碼的優化
問題描述:

創業公司,產品邏輯不夠成熟,開發進度過快,甚至是外包完成,這些都會造成代碼凌亂,接口不合理,框架過時等問題,從而影響后期的擴展與修改。就目前我負責的Android方面,外包的代碼不忍直視,只是達到能運行的階段,沒有任何架構考慮,就更別提性能優化了。

解決方案:

開發過程中盡可能的優化代碼,每完成一個版本,都應該特定的安排時間來優化代碼。如果技術團隊壯大了,代碼審核也是必要的環節。

開發流程規范

1.產品討論會

前面的問題一已經討論過,產品討論會至關重要,一次不行就兩次,兩次不行就三次。直到每個人所理解的產品都是一致的,并產出書面的產品文檔。

2.UI評審會

產品確認之后,設計人員登場設計出UI頁面后,召開UI評審會,參會人員包括老板、開發人員、用戶方等,UI評審會中有不同意見及時提出,確定出最終的UI頁面,之后不得隨意更改。并產出設計圖紙。

3.技術評審會

技術評審會,主要參會人員是開發人員,從技術角度去評估產品,梳理出難點,給出預期的解決方案。最終評估出開發時間,開發時間一旦確認,不得逾期。

4.接口確認會

產品會議結束后,即可開始指定接口,接口文檔由前端或者后臺開發人員給出,制定出接口文檔后,前端負責人與后臺負責人需要坐下來一個一個接口的討論,有問題及時提出更改。最終產出 一份前后端都認同的接口文檔。

5.開發階段

開發階段,前后端同時進行,面向接口開發。

6.聯調階段

前后端都開發完成后,進入聯調接口階段,確保每一個接口都能正常通信。

7.測試階段

全體人員進入測試階段,每發現一個問題都要用Bug管理工具來記錄,寫清楚重現步驟,指派給開發人員,開發人員及時解決。

8.產品發布

測試無誤后,即可發布產品。

9.問題發聵

產品一旦發布,如再發現問題不得直接拋給開發人員,需要第一時間找到測試人員或者問題搜集者手里,做好統計與記錄,并安排修復時間。

隨心所欲的一群人叫做團伙,有形式規范的一群人才叫團隊。希望我這微薄之言能對創業公司有一定幫助。
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容