[答疑]需求規約要不要提醒程式設計師介面設計的注意事項

• 2019 年 10 月 6 日
• 筆記

甘思咪哚 2018-12-25 12:41

潘老師，我們做的app需要在各種平台各種型號的手機上使用。現在有這樣一個問題，假設存在一款Android手機操作方式和其他Android手機有點不同，例如，手用某種方式滑動，其他手機沒有問題，但在該款手機上app就關閉了，會導致不了解情況的用戶帶來不好的體驗，所以程式設計師有必要對這種情況作相應處理。

那麼，需求規約里需要描述處理這種情況的要求嗎？如果不描述的話，程式設計師可能就會漏掉。

潘加宇：

這個問題屬於實現平台的問題，不管針對什麼領域，針對哪一款app，針對哪個用例，這個問題都是一樣的。它不是需求，也不是分析，而是設計。

我們可以通過問"不這樣可能會怎樣"來找到真正的需求。不這樣做可能會怎樣？可能會提高了執行者的操作中無效操作的比例。這個才是真正的需求，屬於可用性需求。

手不小心一滑導致app關閉的操作，和關閉按鈕在螢幕上擺設位置不當總是不小心按到沒有本質區別，和鍵盤布局不合理導致老是按錯鍵沒有本質區別，甚至和資料庫欄位設計不合理導致保存失敗也沒有本質區別。

我們來理一下三個不同的工作。這三個不同工作的結果之間的映射是多對多的，穩定性也不一樣。

（1）可用性需求：執行者在本用例的操作中無效操作的比例不高於***。

這個比例的值不是隨便亂定，而是根據相同情況下執行者使用競爭對手產品的比例而定。

負責做需求的崗位可以稱為需求工程師。

（2）交互設計：某種操作環境中，什麼樣的交互方案是最合適的。

這個需要人機交互心理的知識、不同操作環境中人機交互方式的知識。

負責做交互設計的崗位可以稱為交互設計師。

（3）介面實現：某種操作環境中，執行者真正與之交互的介面實現。

這個需要實現介面的組件庫的編程知識。

負責介面實現的崗位可以稱為程式設計師。

首先，（1）（2）（3）這三個事情要分開，就算是一個人來做，依然是三件事。

就像看病一樣，不能說醫生給自己看病就可以直接開藥吃。醫生也要老老實實鑽到儀器裡面自己檢查，自己看影像，自己診斷，自己開藥，自己吃。

我們回到上面的問題。如果需求寫了（1），又沒有交互設計師參與，程式設計師也對某種操作環境下的開發介面的注意事項不熟悉，結果肯定是不好的，但這裡的問題是（2）（3）兩項技能缺乏，應該補上（2）（3）的技能。

問題又來了：如果目前就沒有辦法請交互設計師，程式設計師的技能也一下提高不上去，能不能在需求規約裡面寫（2）（3）？

回答依然是不應該。一個東西是什麼就是什麼。這種情況下，需求人員如果覺得自己是目前團隊中最適合做交互設計的，那麼可以順便把（2）給做了。但做的東西依然是（2）。同理，如果經過權衡，認為需求人員在介面實現的某些方面比程式設計師要熟悉，或者程式設計師是老闆的小舅子，到公司來上班就是玩玩的，那麼需求人員也可以順便把一部分（3）給做了，但做的東西依然是（3）。

也就是說一個人可以做三件事情，三件事情的結果也可以釘在一起交付，但沒有必要把這三件事情混在一起——"程式碼就是需求"，那就混淆了自己的視線，把自己給坑了。

人可以變，崗位的名頭可以花樣翻新，事情還是那些事情。

還是那句老話：哄人可以，但自己心裡要清楚自己在做什麼。而這一點，很多開發團隊是做不到的。