開發一款APP時(shí)如何給技術和(hé)設計提需求？

開發一個(gè)APP，首先要從需求開始。産品經理(lǐ)看似掌控大(dà)局，但是很多(duō)事情都不是自己能完成的(de)，發需求成了(le)差評的(de)日常，給設計發，給技術發，給策劃發…

 

需求發出去之後，收回來(lái)的(de)東西不滿意也(yě)是常有的(de)事情，于是吐槽也(yě)成了(le)日常，然而吐槽也(yě)并沒有什(shén)麽卵用(yòng)…下(xià)面，樂(yuè)信小編就爲大(dà)家分(fēn)享一些提需求的(de)經驗。

 

　　下(xià)面說明(míng)3個(gè)提需求的(de)要點：

 

　　一、要充分(fēn)考慮人(rén)的(de)因素

 

　　需求之所以複雜(zá)就是因爲需求是人(rén)來(lái)做(zuò)的(de)，如果是機器來(lái)做(zuò)就太簡單了(le)：隻要輸入正确的(de)命令，機器會準确的(de)幫你實現好。

 

　　有了(le)人(rén)的(de)存在，需求就會存在delay、錯誤、品質不夠等問題。

 

　　但這(zhè)并不能成爲需求實現不理(lǐ)想的(de)接口，爲何别人(rén)的(de)需求可(kě)以加塞在你的(de)前面?爲何别人(rén)提的(de)需求實現品質就比你的(de)高(gāo)?

 

　　同一個(gè)忙，你找陌生人(rén)，朋友，親人(rén)來(lái)幫，其過程和(hé)結果肯定是不一樣的(de)!

 

　　那你能不能讓對(duì)方成爲你的(de)朋友甚至哥(gē)們，就要看你的(de)本事了(le)。
 

 

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

 

　　我相信所有人(rén)都經曆過這(zhè)麽一種場(chǎng)景：

 

　　你發了(le)需求，但是對(duì)方沒有看到，于是在交付的(de)那天你什(shén)麽都沒有收到!

 

　　别怪别人(rén)!怪自己!

 

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

 

　　郵件：很正式，内容完整，并且容易回溯

 

　　口頭：最好是口頭，因爲消息和(hé)郵件是繁多(duō)的(de)，很容易被忽略，但是語言的(de)交流是印象深刻的(de)。如果無法實現口頭交流，最好是通(tōng)過IM再提醒一下(xià)，讓對(duì)方明(míng)确的(de)回複已經看到郵件，加深印象。

 

　　三、需求的(de)内容需要符合“SMART原則”

 

　　Specific——需求必須是具體的(de)，明(míng)确的(de)，别摸淩兩可(kě)

 

　　Measurable——需求必須是可(kě)以衡量的(de)，要能夠評價他(tā)的(de)好壞

 

　　Attainable——需求必須是可(kě)以達到的(de)(這(zhè)個(gè)也(yě)是對(duì)方經常拿出來(lái)的(de)理(lǐ)由，遇到之後參見要點一)

 

　　Relevant——需求必須和(hé)其他(tā)目标具有相關性，沒有意義的(de)需求是浪費時(shí)間，要告訴對(duì)方意義何在

 

　　Time-based——需求必須具有明(míng)确的(de)截止期限

 

　　SMART原則非常實用(yòng)，如果想詳細的(de)了(le)解這(zhè)個(gè)原則，可(kě)以點擊這(zhè)裏——SMART原則 via MBA智庫

 

　　技術需求怎麽提

 

　　給技術提過需求的(de)都有過類似的(de)經曆：

 

　　爲什(shén)麽需求這(zhè)麽簡單，但是技術做(zuò)出來(lái)的(de)東西還(hái)是有問題?

 

　　我的(de)需求文檔已經很詳細了(le)，爲什(shén)麽不按照(zhào)文檔裏的(de)來(lái)做(zuò)?

 

　　……

 

　　這(zhè)些所有的(de)不愉快(kuài)往往都跟自己提需求的(de)方式有很大(dà)關系，而不能隻怪技術同學!