相信有在接業配文的各種 KOL, Micro KOL, Nano KOL, KOC, Micro KOC, Nano KOC 們,對於各種不同來源和進行到不同階段的業配文,要怎麼管理應該是蠻頭痛的。

這篇文會手把手的教大家怎麼透過 Notion 來製作屬於自己的「業配文管理行事曆」

這個行事曆會包含:

https://vimeo.com/627347824

如果懶得自己動手拉
也可以點此連結直接購買

教學開始:

步驟 0 : 下載 Notion https://www.notion.so/zh-tw

步驟 1:

建立新的 workspace 後,輸入想要取的名字

建立 workspace

步驟 2:

Database 的區塊,選擇 Board,點選後 Notion 將會建立有不同狀態任務的看板

用戶不小心要離開到編輯到一半的內容,如果可以跳個提示問是否要離開編輯,不失為一個貼心的好作法

這個的重要性不用我多說,直接進入重點。

用戶要離開會有兩種情況:
1. Url 變更或是關掉視窗
2. 關閉某個 component

設計概念

第一種情況比較單純,可以用 browser 預設的行為來解決(關鍵字:onbeforeunload),只要可以讓用戶觸發任何可輸入的 …

用 6 個思考脈絡 I.N.V.E.S.T,更好有條理地撰寫和檢視文件

前文有提到好的文件是非常重要的

這裡介紹用 I.N.V.E.S.T 這六個點來檢視一份文件的撰寫,是否涵蓋夠多的資訊

Independent 獨立

一個需求文件,當它可以越獨立時,它可以越容易被評估和執行。一個很好的檢視方式是,這些不同需求文件的順序是否是可以被調換的。一個夠獨立的需求文件,應該是可以有彈性被動態調整實作時間和順序。

Negotiable… and Negotiated 保持協調彈性並已協調

一個好的需求文件,應該是可以保持協調彈性的。在文件中詳細描述客戶/用戶對需求的描述( 專注在 What ),並保留空間給後續討論要如果達到這些需求 ( 討論 How 的空間 )

Valuable 有價值的

一個需求文件開出來,它必須是有價值的,這裡並不要求每個人都覺得有價值。它必須對客戶有價值,有時工程師會有提出必要且合理,但也應考量是否對客戶的價值也是一樣重要。
除了從客戶認為有價值來看,還可以從幾個維度來思考:
1. Strategic 有策略價值:如果不做這件事情,我們將隨著時間失去市場優勢。
2. Compliance 合規需要:如果不做這件事情,我們將有可能違反法律。
3. Revenue Generation 可產生獲利:如果不做這件事情,我們將錯失賺取市場利潤的機會。
4. Cost avoidance 避免提高未來成本:如果不做這件事情,我們未來將會付出更多錢。
5. System stability 系統穩定:如果不做這件事情,我們將會曝露在系統不穩定或無法正常提供服務的風險。

Estimatable 可估計的

一個好的文件應該是「可被估計的」,這裡不是要精準的估出幾個人做幾個禮拜,是需要可以拿來和其它需求文件比較和排序的。越大的需求文件,或是越不獨立的需求文件,都將讓估計和衡量變的很困難。

Small 夠小

好的文件應該盡量夠小。通常會用可被完成的時間來衡量,至少是一個人一週內能做完 (甚至更嚴格會是一個人幾天內能做完 )。超過這個範圍,會讓一張需求文件變的很難清楚地完成和測試。例如一個一次需要用一個月來實作的功能。

Testable 可測試的

當開始撰寫一個文件,代表一個承諾:「我非常清楚對於我想提出來的功能或改變,我知道它該被如何檢驗」
多數的團隊都認同,當我在實作之前,就知道一個功能/修改會怎麼樣被測試,團隊可以更精準的交付功能。
“可測試性” 一直以來都是最能衡量一個需求描述好與壞的關鍵。事實上,越早就規劃好如何測試,可以幫助團隊認知這個功能到底有沒有解決問題。

找到更多我的資訊可以到這 mhtsai

如果這篇文章有幫到你的話,幫我拍個手吧!
對了,你知道每個人都可以拍50次手嗎?試試看吧!

感謝您的閱讀! :)

你還可以在這些地方找到我
Instagram, LinkedIn, Facebook, Github

敏捷開發介紹

今天想寫這個主題有幾點:

1. 簡介敏捷開發
2. 在帶 10 人團隊和 3 人團隊中,對於敏捷開發的心得
3. 最後給一些正在跑或是想要開始跑敏捷開發的團隊一些建議

敏捷開發是一種應對快速變化的需求的一種軟體開發能力

對於這個開發概念,有個對應的宣言,而根據概念和這些理念發展出了 Scrum 和 Kanban 主要兩個大框架 (各個組織裡面後來都會有各種的變形)。
聽過很多把敏捷開發用的很糟的團隊,大部分都是負責帶「敏捷開發」的人或是 Project Manager 把它當成要壓時程的擋箭牌,「敏捷開發」是 Agile Development 而不是 Fast Development,具體上來講這個開發概念跟 Release 功能的時間並沒有直接的關係,Agile 代表是有可以調整開發過程和市場反應的彈性,並不代表一個開發週期裡,塞滿一堆超過開發能量的功能。

接下來我想介紹 Scrum 這個框架,Scrum 這個框架裡主要由 3個角色、 3個產出和 5個會議組成

.角色:
1. Scrum master (How to deliver)
2. Project Owner (What to deliver)
3. Tech Lead (How to implement)

.產出:
1. User Story
2. Tasks
3. Story points

.會議:
1. Sprint Grooming
2. Sprint Planning
3. Sprint Kickoff
4. Sprint Start
5. Sprint Demo and Retro

Scrum 就是透過這幾個角色的互動和不同要素間的使用,確保團隊維持一個有效運作的機制。

在帶 10 人團隊和 3 人團隊中,對於敏捷開發的心得

1. Product Owner ( Project manager ),對於這套方法的認知即為重要,如果不能區分何為彈性,何為快速,團隊將會是一個災難,敏捷開發光是流程本身就是彈性的展示,許多 Product Owner 選擇想辦法讓開會加速,而不是省掉現階段不合適的會議,才會讓大家覺為敏捷開發只是一個為了有流程而創建的工作框作。對這點有疑問的人,可以試著不要任何框架,你還是會發現,最後還是會總結出跟敏捷開發差不多的工作流程。因為這套方法是演化、歸納出來的,並非為了創建而創建的。

2. 文件的重要。文件的重點不在於長,在於對精準、精鍊地記錄對問題的描述、假設和預期的 Acceptance Criteria。定義問題是讓團隊知道為什麼要做,這點說不明白,最直接的影響,就是團隊開發了一個月,不知道產品到底推進了什麼,好像做一堆東西但都看不到市場具體的推進,這裡會埋下互相不信任的點,最好的情況就是清楚闡明為什麼要做。提出假設和預期的產出,這裡的重點可以其它成員讓技術端來理解,有什麼假設是有認知不一致的,和提出可能更全面的解決方法,同時可以更準確的評估時間。

3. Engineer 必須即時地對不清楚的描述提出疑問,很多時候文件描述或是 UI 設計圖沒辦法詮釋所有流程,工程師必須盡可能的減少做下去後才在測試的時候,對於需求描述有模糊的認知後才提出來,要各個角色出來做確認,沒有什麼事情的討論是需要等到特定會議上才能提的。

最後給一些正在跑或是想要開始跑敏捷開發的團隊一些建議

循序漸進

對於敏捷開發裡面所需要的流程,應該是一個一個加上去的:

.發現開發和需求的確認頻率越來越高,拉一個sprint planning 的會
.發現開發的人開始多了,想要有個類比指標知道要產出不同等級的需求,開始估 story point
.開始發現 planning 時,還是很多事項需要跟不同 stack holder 確認,拉一個 sprint grooming 的會

相對地,當情況都開始不適用後,也該減少不必要的會。

記住,要毀掉一套方法最好的辦法就是讓它流於形式,而不去管背後的目的。

找到更多我的資訊可以到這 mhtsai

如果這篇文章有幫到你的話,幫我拍個手吧!
對了,你知道每個人都可以拍50次手嗎?試試看吧!

感謝您的閱讀! :)

你還可以在這些地方找到我
Instagram, LinkedIn, Facebook, Github

靠 Instagram 內的流量,只要三個月就能漲到千人追蹤。

way to 1K

內容摘要

— — — — — — — — — — —正文開始 — — — — — — — — — — —

1.Start with why. 為什麼該漲粉

有沒有好奇過為什麼自己用心經營的內容,在粉絲數量上都沒 …

如果常常覺得明天再開始學程式
那不妨今天來讀一下這篇文章

這篇文章適合…

想學程式,卻不知如何開始
買了程式語言課程,卻一直還沒開始
學了一陣子,卻不知道怎麼繼續往下鑽研
熟悉這個語言,卻不知道去哪找個地方大展身手

只要記住這五點
相信你在學習任何程式語言時
會更有方向和方法

1. 設定一個具體目標

最常聽到的問題都是線上課程看完後,不知道要幹麻。

如果沒有設定一個具體的目標而學習,就像是摸石頭過河,感受不到具體在進步的感覺,而學習中最重要的就是「挑戰 →想出解法→成就感」,刺激大腦分泌多巴胺,讓自己養成coding的習慣。因此,建立一個個的小目標是非常重要的。

舉例如果今天想要學 NodeJs,一個很好的起點就是用 NodeJs 來建一個Server。再來試著在server的endpoint中做不同類型的資料處理,之後是針對header、cookies做不同的功能。

隨著一個個目標慢慢疊上去,不只可以拓展水平方向的技能知識,也能縱向地將程式語言鑽研地更深。

在 Instagram 導流到自己 profile 最好的方法,就是去和別人的post互動

當你去按別人 like 或是追蹤別人時,都會直接跳出一個通知給對方,而對方出於好奇都會點回profile看這個人是誰。

將用戶導來 profile 是對於品牌塑造一個非常重要的開端,自介裡面可以讓用戶清楚知道你的定位、理想,profile裡的內容可以讓用戶知道更多關於你的產品或是你的生活,再決定要不要按下追蹤鍵。

但一張一張的去按 like 非常花時間。

在這跟大家分享一個好用的 instagram 機器人,輸入你想要按有哪個hashtag的照片,機器人就可以自動幫你按所有照片的愛心。

Instaliker

https://instaliker.mhtsai.me/

這個機器人需要一些資料來替你工作,下面會分幾個步驟來說明:

Step1. 打開網頁版的 Instagram

Step2. 按右鍵,點選「檢查」 (或是 「開發人員選項」)

Step3. 點選右上角的 Network ,開到Network的部分

Step4. 重新整理網頁,讓 Network 可以抓到網站的資料

Step5. 找到 bz,看到 Headers 往下滑,會有cookie, x-csrftoken, x-instagram-ajax

小心,如果你下述幾點你得超過10分,你可能正在做一份你非常喜歡的工作。

對於很多人來說,找到一件自己有熱情和使命感的事情是一件困難的事情。或是說,我們很難查覺自己是不是真的喜愛自己現在的工作,因為影響我們對於工作的因素很多,可能是薪水、環境、合作的人。

下面列出 15 個如果你熱愛你現在的工作和環境,所會出現的徵兆:

你和你正在做的工作滿足了上述幾點呢?

0–4:人生旅途很短,你需要找到一件真的適合你的行業/產業。

5–8:你不討厭你現在的工作,但其實你也不愛它,該做些改變了!

9–12:你很享受現在的工作且喜愛與你一起工作的人。

13–15:你已經不能再更愛這份工作了,這幾乎是你的天職(連你朋友都會嫉妒)

原文來源

你也喜歡你的工作嗎?

我們正在匯集不同行業中,一個熱愛自己工作的人,會是什麼感覺,如果你也很享受你的工作,歡迎來信到bornforthis@workuniverse.co,我們在徵得您的同意後,會做成每日一分享或是做一小段您的專訪,分享在我們的專欄上。我們期許大家都能在工作中找到自己,享受工作,也達到自己的目標。

範例:

收件人: bornforthis@workuniverse.co

主旨: 全端工程師 — Frank

內文: 非常享受和其它人一起動手完成不同的產品,讓身邊的人或是客戶驚豔,就像是有一個超能力一樣,想做出什麼產品就做出什麼產品,尤其在使用者說真的讓他們生活變的更有趣更方便的時候,只想說一句,有我們這個職業在,小鎮村又恢復了和平的一天。

拍手是對我們很大的鼓勵👏!也不要忘記 follow 我們,我們將陸續推出職涯相關文章。有任何有興趣的議題都歡迎留言,我們會想盡辦法為您找到解答!

🎉 Workuniverse 官方網站 [ 找工作前,先找對人 ]

🔥🔥🔥 每天都可以在 Facebook 粉專Instagram 學習新知 😎

MH Tsai

https://mhtsai.me | Find the thing you love so much that you don’t even want to stop | Put down some thoughts.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store