iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 8
2

寫了一週的文章之後,意外收到不少反饋!默默覺得工程師們真的都好辛苦啊QQ
工程師這種生物畢竟就是太過認真可愛,比較逆來順受一點(抱大腿)
所以大部分的工程師,都點了不少通靈技...

不過~我來參加鐵人賽,肩上背負的使命或許也包括「想為工程師們發聲」吧!
(我想工程師們推我下這個坑肯定是對我有所期待吧!?對吧?對吧?)(並沒有。)

好吧。自作多情的設計師要開始正文了(拭淚).../images/emoticon/emoticon02.gif/images/emoticon/emoticon02.gif


除了在「與工程師的協作之路-工具篇(Zeplin)」中介紹的溝通工具,其實更重要的是實際討論與企劃書本身!

當然,業界不是所有的企劃書都那麼完整。
照書養 的,即使有照辦的少數,大部分都是一個對現實來說極度理想的狀態...(就像亂世出包青天那樣)

理想與現實落差總是有點大的...這點不只是在工程師角度,設計師也同樣感同身受,但是繼續寫下去我可能會 被公司吉 ...還是來寫點看起來很規矩的教學文吧!/images/emoticon/emoticon13.gif


產品核心

一個產品,最重要的是「核心宗旨」。

你的產品核心概念是什麼,決定了往後每個決策與走向,甚至能夠滲透到細節的決議~
所以核心宗旨絕對不會是萬人受用或是老少咸宜(又不是什麼營養口糧之類的),這類的只能當作一個「目標」,並不能被當作「宗旨」!
宗旨是更能夠貫徹整個產品的一個中心思想。只要團隊間對這個思想有一定的共識,溝通起來就會更有效率!

User Story

有了一個核心宗旨之後,我們就可以開始進行近一步的討論了!
查詢一下wiki你會看到他這樣說明:

In software development and product management, a user story is an informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end user or user of a system. They are often recorded on index cards, on Post-it notes, or in project management software. Depending on the project, user stories may be written by various stakeholders including clients, users, managers or development team members.

User stories are a type of boundary object. They facilitate sensemaking and communication, that is, they help software teams organize their understanding of the system and its context.

大概的意思,總而言之就是說,用戶故事是基於用戶的觀點來寫的,用以提高共識和作為溝通使用,團隊中大家都可以來寫

User Story是針對這項產品的使用者做一個比較具體的描述,例如:在職媽媽、朝九晚五的小資女...等等這類的形容詞搭配角色來述說一個故事!藉由這些故事,去推敲使用者可能有什麼習慣、哪些需求是他們首要的痛點。
有了這些故事,在發想產品時有遇到任何感到瓶頸、無法想得透徹的時候,試著帶入這些角色,你將能注意到原本看不見的東西...(不是阿飄!)


那麼,這和 與工程師的協作 有什麼關係?

PM「企劃書寫好了,請大家各自執行作業!」
Designer「請問...這是針對哪樣的客群呢?」
PM「有網路的都可以用!」
RD「這裡...這樣做真的好嗎?」
PM「你先開發看看再來討論!」

發現了嗎?
以上範例只有PM本身可能知道方向,對設計師和工程師來說,其實處在一個 不知自己為誰而做 的狀態。

這時候如果沒有足夠的中心思想與對使用者的描述,其實PM自己也容易遇到瓶頸,這可能造成朝令夕改、浪費資源的情況發生!也會使執行者感到薛西佛斯(對,又是他)/images/emoticon/emoticon70.gif

執行者不只是執行者

任何團隊,只要越能凝聚共識,就越能把產品做好!
最早以前的開發方式,執行者在拿到企劃書之前,對即將開發或設計的內容幾乎不了解,就算拿到企劃書也只能從頭理解起,但每個人對於一段話、一個故事、一個需求能夠理解的深度和含義絕對都不同,這樣非常有可能造成:

設計拿到,去找企劃討論一番;
工程拿到設計稿,去找設計討論一番,接著可能又協同設計去找企劃討論一番;
接著設計也要改、工程也要動了,但 時程已經快到了 呀!
企劃書還在難產中,只好壓縮開發時間了.../images/emoticon/emoticon17.gif

反覆不斷確認甚至翻盤,這都是很常有的事情...(以上還沒計入無限輪迴地獄)
甚至企劃和設計好不容易達成共識之後,工程只能回句:這沒辦法做
這下子工程師又要被貼標籤了.../images/emoticon/emoticon36.gif

邀請設計師與工程師參與前期討論吧!

承上,執行者不只是執行者,使用者體驗必須是一種文化!
以使用者角度作為任何一個細節的發想立場,將能使你的產品更臻完美~

.設計師

設計師必須了解「為誰而設計」、「團隊正在解決或遇到什麼問題」...
因為畫面是產品接觸使用者的第一個門面,也直接影響使用者體驗!不了解這些,別說是解決問題,連一些基本該注意的細節都無法顧及!

強烈建議發想期就可以找設計師一起加入 !越了解使用者,設計師越能發揮得更好!

.工程師

在團隊中,最了解技術的就是工程師了!
概念發想時工程師可加可不加(有些工程師對瞭解使用者也很熱衷,有些則是純技術狂熱者,務必尊重每位工程師的適性發展),但要開始討論架構的時候,請 一定 要邀請工程師加入!

就像一夥人出團去打怪,路上缺了HP藥,大家千辛萬苦的採集挖坑想取得補品,殊不知法師唸唸咒語大家就回血了,前面都是白忙一場。

前期討論這個產品可能有哪些功能想做、邏輯可能是什麼的時候,找工程師進來協助發想吧!
他們絕對會告訴你哪些功能已經有哪些套件可以使用、其實有更快的方式能夠解決這些問題。


其實本來只是想稍微介紹一下User Story的名詞定義與產品發想時的使用方式,好像不小心囉唆了起來/images/emoticon/emoticon25.gif

但願眾設計師與工程師們在開發的漫長道路上,能夠每天心平氣和、充滿目標與希望(?)~
那麼,下次見~


上一篇
與工程師的協作之路-那些年,我們一起混淆的CSS(三)
下一篇
與工程師的協作之路-icon篇(上)
系列文
學什麼就寫什麼,知道什麼就分享什麼31

1 則留言

0
darwin0616
iT邦新手 3 級 ‧ 2018-10-22 11:02:09

台灣、日本、韓國不是都走隕石開發法,在這行幹了6年多沒聽過User story這件事!/images/emoticon/emoticon23.gif

(拍拍)至少知道有這樣的方法~
未來把主管X掉
未來有機會帶人的時候,可以試著整頓啊XD

我要留言

立即登入留言