開發(fā)一個APP，首先要從需求開始。產(chǎn)品經(jīng)理看似掌控大局，但是很多事情都不是自己能完成的，發(fā)需求成了差評的日常，給設計發(fā)，給技術發(fā)，給策劃發(fā)…

 

需求發(fā)出去之后，收回來的東西不滿意也是常有的事情，于是吐槽也成了日常，然而吐槽也并沒有什么卵用…下面，樂信小編就為大家分享一些提需求的經(jīng)驗。

 

　　下面說明3個提需求的要點：

 

　　一、要充分考慮人的因素

 

　　需求之所以復雜就是因為需求是人來做的，如果是機器來做就太簡單了：只要輸入正確的命令，機器會準確的幫你實現(xiàn)好。

 

　　有了人的存在，需求就會存在delay、錯誤、品質(zhì)不夠等問題。

 

　　但這并不能成為需求實現(xiàn)不理想的接口，為何別人的需求可以加塞在你的前面?為何別人提的需求實現(xiàn)品質(zhì)就比你的高?

 

　　同一個忙，你找陌生人，朋友，親人來幫，其過程和結果肯定是不一樣的!

 

　　那你能不能讓對方成為你的朋友甚至哥們，就要看你的本事了。
 

 

　　二、提需求要注意方式方法

 

　　我相信所有人都經(jīng)歷過這么一種場景：

 

　　你發(fā)了需求，但是對方?jīng)]有看到，于是在交付的那天你什么都沒有收到!

 

　　別怪別人!怪自己!

 

　　發(fā)需求的方式強烈建議2種結合：郵件+口頭

 

　　郵件：很正式，內(nèi)容完整，并且容易回溯

 

　　口頭：最好是口頭，因為消息和郵件是繁多的，很容易被忽略，但是語言的交流是印象深刻的。如果無法實現(xiàn)口頭交流，最好是通過IM再提醒一下，讓對方明確的回復已經(jīng)看到郵件，加深印象。

 

　　三、需求的內(nèi)容需要符合“SMART原則”

 

　　Specific——需求必須是具體的，明確的，別摸凌兩可

 

　　Measurable——需求必須是可以衡量的，要能夠評價他的好壞

 

　　Attainable——需求必須是可以達到的(這個也是對方經(jīng)常拿出來的理由，遇到之后參見要點一)

 

　　Relevant——需求必須和其他目標具有相關性，沒有意義的需求是浪費時間，要告訴對方意義何在

 

　　Time-based——需求必須具有明確的截止期限

 

　　SMART原則非常實用，如果想詳細的了解這個原則，可以點擊這里——SMART原則 via MBA智庫

 

　　技術需求怎么提

 

　　給技術提過需求的都有過類似的經(jīng)歷：

 

　　為什么需求這么簡單，但是技術做出來的東西還是有問題?

 

　　我的需求文檔已經(jīng)很詳細了，為什么不按照文檔里的來做?

 

　　……

 

　　這些所有的不愉快往往都跟自己提需求的方式有很大關系，而不能只怪技術同學!