iT邦幫忙

專案管理相關文章
共有 1290 則文章
鐵人賽 IT管理 DAY 5

技術 [Part 1: Redmine 帳號管理] 設定、指派帳號的角色權限和分組 (1)

在 [Part 1: Redmine 帳號管理] 設定、指派帳號的角色權限與分組 的文章目標,會讓你知道以下 4 個部分。因為除了操作以外,也會講到不侷限在 R...

鐵人賽 IT管理 DAY 4

技術 [Part 1: Redmine 帳號管理] 建立與管理使用者帳號

做專案的前提是什麼?就是要有人 🤣 所以我們當然就要先從建立使用者帳號進行囉! 今天的這篇文章內容中,預計會讓你瞭解: 帳號可以怎麼產生 註冊帳號的相關設定...

鐵人賽 IT管理 DAY 3
好專案 VS 壞專案 系列 第 3

技術 【Day 3】好專案VS壞專案-什麼是專案管理(waterfall)

什麼是專案管理? 計畫型(waterfall)專案 計畫型專案管理就是在有限的時間、有限的資源、有限的範疇內,完成一件原本產品或系統沒有的功能、服務或結果,...

鐵人賽 IT管理 DAY 3

技術 [Part 0: Redmine 入門指南] Admin 設定導覽:快速瞭解探索 Redmine 網站設定區塊

在上一篇文章,我們已經順利在自己的電腦上啟動 Redmine,而這篇文章內容,預計會帶給你2個部分 知道如何識別你的帳號是不是 admin 對 admin 可...

鐵人賽 IT管理 DAY 2

技術 [Part 0: Redmine 入門指南] Redmine 安裝:如何在自己的電腦輕鬆安裝與啟動

對於 Redmine ,如果以非工程師的角度來看的話,「它並不是一個像是 App 裝了就可用的軟體」,所以如果它真的要可以被大家一起打開瀏覽器使用,就需要有對應...

鐵人賽 IT管理 DAY 2
好專案 VS 壞專案 系列 第 2

技術 【Day 2】好專案VS壞專案-專案管理的由來(agile)

敏捷型(agile or scrum)專案管理 敏捷一詞來源於2001年初,十七名軟體開發人員在猶他州的雪鳥度假村會面,聚會中眾人討論這些輕量級的開發方法,...

鐵人賽 IT管理 DAY 1

技術 隔行如隔山,從專案助理重啟職涯——小白兔怎麼決定跳入IT叢林轉職

「專案」是一個非例行性、在一段時間內有限度需實現特定目標的任務。 回想跨業轉職的規劃過程,就跟寫「專案計畫書」一樣,而「轉職」就是我的「專案目標」。就用與計...

鐵人賽 IT管理 DAY 1

技術 [前言] 選擇Redmine 的原因 & 簡單認識 Redmine 這個專案軟體工具

在正式進入主題前,我覺得想要先說說在這麼多的軟體工具中,這次為什麼我特別選擇 Redmine 這個軟體作為系列文章的主題。 目前我已經在軟體領域的期間投入將近...

鐵人賽 IT管理 DAY 1
好專案 VS 壞專案 系列 第 1

技術 【Day 1】好專案VS壞專案-專案管理的由來(waterfall)

專案管理的手法,不論是計畫型或是敏捷型,其實都脫離不了大家所熟知的PDCA。PDCA起源於1920年代貝爾電話實驗室的物理學家沃爾特·休哈特 (Walter S...

技術 如何使用專案管理工具提升產品開發效率

在今日的數位環境中,專案管理已成為許多商業組織和團隊提升效率、保持組織和實現業務目標的核心方法。尤其在產品開發的過程中,從產品的構思、設計、開發到測試和推出,專...

C++30日挑戰之旅 系列 第 39

技術 【WIDE LAB紀錄 Day9】 先讓我們看那神奇的工具:Clockify!

壹、Clockify是什麼? 在學長的推薦下認識了這款軟體,初步的感覺是有點類似軟體工程之前用過的“Toggl”,而經由下列兩篇文章: 參自:接案工作者常用工...

鐵人賽 IT管理
專案開發的鳥事 系列 第 32

技術 獨自完成3.5百萬美金(一億元台幣)的資訊系統,如果你是主管,要學會任用有才能的反抗者

這是我看完這篇「什麼是造就團隊成功的關鍵?從Google的例子看「反抗者」人才的重要性」,剛好想到的我職場遇到的故事,寫成文章分享給大家。 什麼是造就團隊成功的...

技術 【閒聊】如何做好軟體專案的評估?談簡易的專案評估表撰寫

最近在跟同事討論專案時,忽然想到在以前公司的專案流程中專案業務或專案經理在專案承接前會做一個專案評估的檢查,並將整個專案做量化數據給公司的主管,由他確認這專案的...

技術 【閒聊】嘗試用客戶需求表、需求追溯表來取代系統需求規格_SRS撰寫

最近與學弟聚餐時,我們閒聊共同討論專案文件時是否精簡系統求規格書與需求文件嗎?因為學弟公司是小型開發團隊(4-5人),每個專案花太多時間整理需求文件,這也是增加...

鐵人賽 IT管理 DAY 30

技術 完賽感言-產品經理的字字真跡

終於完賽了!!! 到了最終回,身為產品經理,不免俗還是幫自己Retro一下,回顧一下在寫文章的過程中,所發生幾個的重要的小事: What feels grea...

鐵人賽 IT管理 DAY 30

技術 Day 30 下一位踏入PM多重宇宙領域

來到了最後一天了,終於堅持到這天了!PM的經驗使人快速學習各方面的事物無論是技術面、行銷面、溝通協調與堅持對的事情說服老闆,還有如何面對各式的情緒勒索,來到這屆...

鐵人賽 IT管理 DAY 29

技術 Churn/Retention 3: 老闆,我真的把客戶留住了,請看我衡量的留存率!

當老闆/主管來問到產品近況時,問道:我們的客戶留存率如何?怎麼算的?這時,如果看過這篇,也許你就可以有自信地這樣回答老闆: 我們如何定義和衡量留存率? How...

鐵人賽 IT管理 DAY 29

技術 Day 29 回首這趟絕命專案管理

如同這一次鐵人賽的主題「掉進絕命專案管理的多重宇宙」,在絕命專案管理中產品從無到上市並銷售到國外市場,這過程非常難忘的經驗與心得透過這次鐵人一次公開與各位以自身...

鐵人賽 IT管理 DAY 28

技術 Churn/Retention 2: 讓客戶來了就不想走,這就是使用者黏著

在開始討論之前,請容我先對客戶們唱首歌https://youtu.be/pB-5XG-DbAA 希望客戶在產品中多停留一點,必須先有幾個但書: 定義「讓客戶多...

鐵人賽 IT管理 DAY 27

技術 Churn/Retention 1: 用微笑留著客人!談談retention Curve的微笑曲線

Churn Rate: 使用者流失率Rentention Rate: 使用者留存率 其實他們是一個一體兩面的相反詞,所有的產品經理理所當然都希望使用者來了就不會...

鐵人賽 IT管理 DAY 28

技術 Day 28 先做人還是先做事?

如同鐵人賽開賽第一天提到的「專案管理比鬼還可怕,尤其是...人更是可怕千百倍啊!」,進入職場多年遇過各式各樣的人,有些很會做人超會做人超會演...但不太會做事,...

鐵人賽 IT管理 DAY 26

技術 User Onboard 4: Customer Success對於to B產品的重要性

客戶貌。 如果你的客戶,總是等你來Approach他,產品主要是靠Sales、Account Manager等人工推廣、Demo、POC而賣出的,不用懷疑,這基...

鐵人賽 IT管理 DAY 25

技術 User Onboard 3: 讓客戶成功地完成價值探索

每個to B的客戶,在面對全新的產品時,心裡不免想著:每個使用者,無非就是希望: 要馬節省時間 要馬節省成本 要馬賺到更多利益 有足夠好處,才有辦法讓客戶...

鐵人賽 IT管理 DAY 24

技術 User Onboard 2: 讓用戶舒服地走過新手村

前面有提到 User Onboarding指的是讓User順利進入新手村,並且完成第一次的核心功能使用。個人認為這件事在to B產品格外重要,Facebook...

鐵人賽 IT管理 DAY 27

技術 Day 27 從模仿找到創新方程式

在專案進行過程中,從模仿別人優點再進行創新研究,一般常見的方式應該會比較分析一些相關產品的作法,不論是功能面、商業面等,做以產品需求的評判標準,通常都是為了某些...

鐵人賽 IT管理 DAY 23

技術 User Onboard 1: 讓用戶第一次使用就上手

To B的產品有個硬傷,就是客戶不如to C地多少少的客人,能夠拿來優化使用者體驗的測試機會少很多,這意味著每次接觸都很重要。 萬事起頭難,大部分的to B 產...

鐵人賽 IT管理 DAY 22

技術 產品品質5: Google分享的4個軟體服務運行黃金信號

四個黃金信號 The Four Golden Signals 首先先說明一下,四個黃金信號皆是以衡量請求(request)為基準,也就是說,每當使用者對網路服...

鐵人賽 IT管理 DAY 26

技術 Day 26 評估適合的委外合作

專案執行的過程可能應為人力與能力問題,需要請求外界第三方協助,無論是開發、行銷、測試等技術委外,能讓產品開發進行順利的方法,但是在茫茫大海中如何找到適合的合作廠...

鐵人賽 IT管理 DAY 25

技術 Day 25 市場規劃經驗談-歐洲

昨天跟各位分享中國大陸市場的規劃分享,今天繼續來分享市場規劃的心得,當初產品規劃完後也差不多完成進市場準備,中國大陸市場規劃都差不多後,就也開始準備歐洲市場作業...

鐵人賽 IT管理 DAY 21

技術 產品品質4: Google教你掌控軟體服務的品質可靠度!

俗話說的好,打不贏Google,就加入他(!?)什麼!加入不了?那至少可以學學他吧~Google這麼強大,背後一定有很多Know how是我們可以參考的。 這樣...