---
lang: zh-tw
title: '目前問題 與 改善'
tags: '看'
---
目前問題與改善
===

<br>

# :sweat_smile::face_with_head_bandage: <span class="green">說明大家遇到的問題</span>

> **狀況一**、[有經驗 <font class="pg">PG</font> 採用邊開發邊問的作業模式，長期會造成不良後果](#狀況一)
>
> **狀況二**、[規格太晚給，開發時間不夠](#狀況二)
>
> **狀況三**、[規格沒開好，也就是規格開不明確(正確、清楚、足夠)](#狀況三)
>
> **狀況四**、[沒跟客戶溝通和確認好規格，就直接進行開發](#狀況四)
>
> **狀況五**、[<font class="pm">PM</font> 與 <font class="pg">PG</font> 之間互動、溝通的頻率過少，產生「認知落差」+「不爽心情」](#狀況五)

<br><br>

## 狀況一
### <span class="blue">有經驗 <font class="pg">PG</font> 拿到沒開好的規格，卻採用「經驗」+「通靈」之邊開發邊問模式，長期會造成不良後果?!</span>
* 當有經驗 <font class="pg">PG</font> 拿到一份沒有開好的規格(不明確的規格)時，只要在規格說明時大概聽懂規劃的大方向、邏輯、規則、流程，就選擇收了這份規格，直接採用「經驗」+「通靈」之邊開發邊問模式進行，然後就會先開發出一版給 <font class="pm">PM</font>，除非…在開發中遇到真得需要再釐清或缺的東西還沒給或資訊不正確導致無法往下開發時才會發問，而 <font class="pg">PG</font> 會選擇這樣做的原因大致有 : <div class="newline"></div>
1. **開發時間已經不夠了**，不想浪費時間，因為問的風險太大了。<div class="newline"></div>
2. 已經發現是開規格時根本沒想清楚，問了之後，東西還是不能一次給正確、清楚、足夠，會發生只給不太重要的資訊，真正重要確資訊反而沒給到，再追問後，常常是必須還要等 <font class="pm">PM</font> 再想想再規劃或是還要再等跟客戶來回確認，如果再一直追問下去，發現會來來回回太多次數，真的是太浪費時間、太累了，那不如我用「經驗+通靈」先寫一版，**不然…這樣搞下去一定會來不及**。<div class="newline"></div>
3. <font class="pg">PG</font> **怕一問反而工作量更多**，甚至要大變動，這也是在開規格時沒想清楚、沒想到、沒想法，等 <font class="pg">PG</font> 問了之後才有想法或才認真去想，這種狀況肯定會走到開發時間不夠用的田地。<div class="newline2"></div>
* 這樣的方式，之前的客戶是比較沒主見，就我們給什麼就接受什麼。或是只要稍微說服一下就過關，那就皆大歡喜。但是…現在的客戶是有主見的比較多，不管是真的有主見還是被逼得必須要裝一下有主見，<code class="red">總之，現實狀況漸漸跟之前不一樣了，所以不可以再這樣了!!!</code><div class="newline"></div>
* 這樣的方式，**會導致 <font class="pm">PM</font> 以為規格不用開明確**，只要大概開一下就好，也不用太在意是否要去跟客戶確認，反正 <font class="pg">PG</font> 看不懂會自己來問，沒問也會出一版程式，到時候看狀況再說。

<br><br><br>

## 狀況二
### <span class="blue">規格太晚給，開發時間不夠</span>
* 如果規格開得夠明確(正確、清楚、足夠)，那可能靠加班或 <font class="pg">PG</font> 們互相幫忙還可以解決。<div class="newline"></div>
* 如果規格開得不明確，那就不是靠加班就能解決了，還必須「不斷的來回確認需求」+「通靈」，會消耗相當多的開發時間與動力，有時又要等客戶回覆，那就更浪費時間，最後連開發時間也變不夠。

<br><br><br>

## 狀況三
### <span class="blue">規格沒開好，也就是規格開不明確(正確、清楚、足夠)</span>
* 規格開的太簡陋或開規格時沒想清楚，規格根本不完整，<code class="red">重要資訊沒有提供完整，缺東缺西，還必須「不斷的來回確認需求」+「通靈」</code>，會消耗相當多的開發時間與動力，有時又要等客戶回覆，那就更浪費時間，最後連開發時間也變不夠。<div class="newline"></div>
* 更可怕得是…都開發到一半，甚至都已經開發好了，才發現規格根本不對，不是客戶要的結果，那 <font class="pg">PG</font> 就只能不爽的大改或重寫。

<br><br><br>

## 狀況四
### <span class="blue">沒跟客戶溝通和確認好規格，就直接進行開發</span>
在開規格時，會出現以下兩種不好的狀況 :</code>
* **第一種: 需求資訊未收集/挖掘完整**
➜ 就自行依據經驗或自行腦補開規格
➜ 但是沒有跟客戶溝通確認所開的規格是否符合需求(通常應該會再來回個幾次)
➜ 就直接開發
➜ <code class="red">導致做出來的功能跟客戶要的有很大落差</code>
➜ 最後就又必須大改版</code><div class="newline15"></div>
* **第二種: 只收集到極少的需求資訊，因為客戶沒想法、沒時間、不想參與**
➜ 那就只能依據經驗與自行腦補開規格，基本就規劃出1個版本，後續再跟客戶確認，有些視狀況可規劃2~3個版本，後續再作選擇與確認
➜ 到這裡都還 OK，因為現實中真的有滿多客戶就是要等你有東西給他後，他才願意有想法、有需求
➜ 但可怕的是…就沒有後續了，規格開好沒拿去跟客戶作溝通確認(通常應該會再來回個幾次)
➜ 就直接開發
➜ <code class="red">導致做出來的功能跟客戶要的有很大落差</code>
➜ 最後就又必須大改版

<br><br><br>

## 狀況五
### <span class="blue"><font class="pm">PM</font> 與 <font class="pg">PG</font> 之間互動、溝通的頻率過少，這種狀況久了，會產生「認知落差」+「不爽心情」</span>
* <font class="pm">PM</font> 很少主動去了解 <font class="pg">PG</font> 在開發過程中狀況、是否有需要協助或溝通的地方，「功能小、功能少」可能無所謂，但是如果「功能大、功能多」+「一直都沒有進行工項管制」，最後 <font class="pm">PM</font> 將無法知道 <font class="pg">PG</font> 開發的進度，也不知道 <font class="pg">PG</font> 在幹什麼，常常都只有開發前交付工作項目與要交付前一天或前幾天才會去找 <font class="pg">PG</font>，中間幾乎都沒有。<div class="newline"></div>
* <font class="pg">PG</font> 很少主動跟 <font class="pm">PM</font> 說明跟回報功能開發得難易度與進度，導致至 <font class="pm">PM</font> 無法理解為何要花這些時間，也會導致 <font class="pm">PM</font> 在評預估功能開發時間會錯誤。

<br><br>

:::success
:loudspeaker: <font class="pg">PG</font> 有話想說
===
以 PG 的立場，為了讓專案可以順利結案，如果規格太晚給但有開好，是可以加班的，但是規格太晚給又沒開好又要加班，在實際經歷過後，真得很不願意，因為必須一次一次來回的確認規格，真的很浪費時間，也真的很沒效率，這種狀況如果次數多了，甚至變成常態，會非常反感。
:::

<br><br><br>

---

<br>

# :grinning: <span class="green">我們要怎麼一起改善</code>
主要是想讓大家有相同的概念、觀念，跟執行時的大方向、大原則。

## 一、觀念宣導
:::danger
* 專案中，**<font class="pm">PM</font> 必須是積極主動的**，不管是對客戶還是對 <font class="pg">PG</font>。
* 專案中，有技術相關事項需要協助，**<font class="pg">PG</font> 必須積極支援**。
* 專案中，**<font class="pm">PM</font> 與 <font class="pg">PG</font> 必須持續互動、溝通與調整**，達成共識(減少認知落差與誤解)。
* 專案中，<font class="pm">PM</font> 在管控專案的同時，**必須主動適度去了解 <font class="pg">PG</font> 的處理狀況，是否有需要溝通與協助的地方**。
* 專案中，<font class="pg">PG</font> 在撰寫程式的同時，**必須主動適度回報處理狀況給<font class="pm">PM</font>**。
* 專案中，要讓執行進度透明化，**不要呈現出 :**
* <font class="pg">PG</font> 不知道為什麼 <font class="pm">PM</font> 要我作這個，也不知道專案目前的狀況。
* <font class="pm">PM</font> 不知道 <font class="pg">PG</font> 目前的開發進度與狀況，也不知道目前在作哪一個功能。
:::

<br><br>

## 二、實務要求

> 1. [任務角色](#1.任務角色)
>
> 2. [開工前一定要有啟動會議](#2.開工前一定要有啟動會議)
>
> 3. [需求訪談很重要](#3.需求訪談很重要)
>
> 4. [需求規格力求明確](#4.需求規格力求明確)
>
> 5. [工項管制表有效控制專案進度](#5.工項管制表有效控制專案進度)

<br><br>
### 1.任務角色

digraph  {
  fontname="Helvetica,Arial,sans-serif"
  fontsize=20;	
  rankdir=LR; 
  node [fontname="Helvetica,Arial,sans-serif"]
  node [shape=box,style="filled",color="#9370DB",fillcolor="#ECECFF", fontcolor="#333"];
  
  協助撰寫RFP
  協助撰寫RFP -> 撰寫服務建議書;
  撰寫服務建議書 -> "進行需求訪談
  (需求收集)";
  "進行需求訪談
  (需求收集)" -> 開需求規格與工項管制表;
  開需求規格與工項管制表 -> 開發與維護;
}

1. 在 協助撰寫RFP、撰寫服務建議書、進行需求訪談(需求收集)、開需求規格與工項管制表階段，以專案處為主(執行者)，技術處為輔(協助者)。<div class="newline"></div>
2. 在 開發與維護 階段，以技術處為主(執行者)，專案處為輔(協助者)。

<br><br>
### 2.開工前一定要有啟動會議
* 專案開工前一定要有啟動會議，主要是要讓所有參與者知道專案內容(工作範圍)、方向、時程與查核點(查核時間與項目)，
<code class="red">讓大家知道我們是在做什麼東西?</code>
<code class="red">要做到什麼程度?</code>
<code class="red">什麼時候要完成什麼東西?</code>
<code class="red">目前的進度如何?</code>
這樣，大家才會有明確的目標、才會作的安心、才會有向心力。

<br><br>
### 3.需求訪談很重要
* 需求訪談一定
<code class="red">要積極主動的去收集/挖掘與溝通確認出客戶的真實需求，</code>
<code class="red">過程中必須確認方向、框定範圍，</code>
<code class="red">並確定所收集的需求資訊足以拿來開出明確的規格，</code>
並且在完成需求訪談後，將彙整的結果給客戶確認，~~最好可以簽名畫押~~。<div class="newline"></div>
* 經評估後，如需 <font class="pg">PG</font> 到場協助，就要通知 <font class="pg">PG</font> 並協調出時間。<div class="newline"></div>
* 需求訪談在實務上、經驗上，它常常是需要多次的，而且也常會在開規格、開發、測試、上線、維護階段時，也需要再作需求訪談，只是我們~~必須~~期望在開規格前將大多數主要、必要的真實需求給它收集/挖掘到。

[關於需求訪談更多內容](https://hackmd.io/@SuperBin/ByCseBrqs#-%E9%9C%80%E6%B1%82%E8%A8%AA%E8%AB%87)

<br><br>
### 4.需求規格力求明確
* 需求規格的開立，是對所收集的需求資訊進行彙整、分析、規劃出滿足真實需求且必要可行的規格，而規格內容的描述必須是正確、清楚、足夠地詳細。<div class="newline"></div>
* 開需求規格時，如需了解技術可行性，就快讓 <font class="pg">PG</font> 加入吧!!!<div class="newline"></div>
* 實務上、經驗上，它很有可能會出現邊開規格、邊需求訪談、又邊跟 <font class="pg">PG</font> 溝通討論技術上的可行性。<div class="newline"></div>
* 實務上會發生，已經到必須開規格的時間，但需求資訊卻還不完整或極少，先去除 <font class="pm">PM</font> 是否有積極主動的因素，常是因為客戶配合度不高，有可能是 : 客戶沒想法、沒時間、不想參與，<code class="red">這種狀況，趕快主動去追著客戶進行需求訪談，</code>如果真的無法如願完成，那就先將可以開規格的部分先開，並跟客戶(主要是承辦)反映，<code class="red">同時也必須讓 <font class="pg">PG</font> 知道狀況，然後採取邊需訪邊開規格的模式。</code><div class="newline"></div>
* 所開的規格如果連自己都覺得不行，那就不要拿給客戶進行確認，也不要交付給 <font class="pg">PG</font> 進行開發，建議可以使用情境模擬（使用者故事）的方式來協助自己確認規格是否明確，就想像使用自己所開的規格，是否可以正確且順利的模擬各種所規劃的使用情境。<div class="newline"></div>
* 規格開好後，是先給客戶，讓客戶先看過，並進行溝通確認，如有落差，必須針對該部分作修正，最後，將完成的規格給客戶確認，~~最好可以簽名畫押~~，再進行下一步(建工項管制表)。
* 不管客戶會不會看，會不會想好好地進行溝通確認，我們至少要將規格文件給客戶，告知客戶如有需要作調整/修正，可再進行溝通討論，如沒有就依規格開發<div class="newline2"></div>

[關於需求規格更多內容](https://hackmd.io/@SuperBin/ByCseBrqs#-%E9%9C%80%E6%B1%82%E8%A6%8F%E6%A0%BC)

<br><br>
### 5.工項管制表有效控制專案進度
* 客戶確認規格後，需再建立<code class="red">工項管制表</code>。<div class="newline"></div>
* 必須清楚列出每個工項，並對每個工項定出預計完成日、優先順序、實際完成日⋯等有助進度管控的資訊，供查看或回報，其中預計完成日一定要給足夠的開發時間。<div class="newline"></div>
* 在定每個工項預計完成日時，如需 <font class="pg">PG</font> 的技術協助，以了解工項執行(功能開發)的難易度與預估花費時間，讓預計完成日可以定的更精準，就快讓 <font class="pg">PG</font> 加入吧。

[關於工項管制表更多內容](https://hackmd.io/@SuperBin/ByCseBrqs#-%E5%B7%A5%E9%A0%85%E7%AE%A1%E5%88%B6%E8%A1%A8)

<br><br>

## 三、新實施表格
為了讓大家作事要有紀錄有依據，所以依據目前問題與狀況，在專案執行中，分別針對「需求收集與變更」、「規格書」、「工項管制」有對應的表格要請大家確實填寫。

<span style="display:block;padding-left: 2rem;">[:memo: 1-1.需求訪談記錄表範本(docx)](https://www.geosmart.tw/docs/1-1.需求訪談記錄表範本.docx)</span>

<span style="display:block;padding-left: 2rem;">[:memo: 1-2.需求變更訪談紀錄表範本(docx)](https://www.geosmart.tw/docs/1-2.需求變更訪談紀錄表範本.docx)</span>

<span style="display:block;padding-left: 2rem;">[:memo: <code class="red">**2-1.需求規格書範本(docx)**</code>](https://www.geosmart.tw/docs/2-1.需求規格書範本.docx)</span>

<span style="display:block;padding-left: 2rem;">[:memo: <code class="red">**2-2.專案工項管制表範本(xlsx)**</code>](https://www.geosmart.tw/docs/2-2.專案工項管制表範本.xlsx)</span>

<br><br>

## 四、最後再強調
1. 交付規格書與工項管制表給 <font class="pg">PG</font> 的時間點**不可以太晚**，而且**要面對面進行口頭說明與溝通**，如雙方有認知落差，必須先釐清確認後再進行下一步(開發)。<div class="newline"></div>
2. <font class="pg">PG</font> 在開發前，**一定要再次確認規格有搞懂、該給的參考資料也都有給齊，才可以進行開發**，如有不 OK 的地方，必須先處理好再進行開發。<div class="newline"></div>
3. <font class="pg">PG</font> 在開發時，**原則上是依據工項管制表所定的優先順序開發各個功能**，每完成一個功能或一組功能，除了必須自行測試外，也必須主動適時回報。<div class="newline"></div>
4. 關於專案中「留紀錄」這件事，它除了讓我們作事有一個依據、也可以讓我們回顧與追蹤過程、也可以透過它來了解進度(建立工項管制表的用意也是如此)、**也可在未來如果出事時拿來當證據，是一個保障**，尤其是我們跟客戶之間處理事情一來一往的紀錄或任何簽名畫押的動作。

<br><br><br>

## <span class="red">五、先作到以下事項吧~</span>

:::info
**<font class="pm">PM</font>在<font class="red">交付工作</font>時問問自己**:question:
- [x] 我有講清楚、說明白嗎？ 對方有聽懂嗎？
==_`要明確，千萬不要認為對方可以從對話中感受到你的標準或期望`_==
==_`➜可以問 : 有沒有聽不懂或有問題的地方?`_==
==_`➜可以問 : 有沒有需要再加強說明的地方?`_==
==_`➜可以問 : 給這樣的資訊，有辦法進行接下來的開發或設計嗎?`_==
- [x] 我有給優先順序嗎？
- [x] 我有說什麼時候完成？ 或期望什麼時候完成嗎？
==_`要明確指出來，千萬不要認為對方可以從對話中感受這個日期`_==
:::

:::info

**<font class="pg">PG</font> 在<font class="red">接受工作</font>時問問自己**:question:
- [x] 對方說的我有聽懂、搞懂嗎？ **不懂有反問嗎？**
==_`如果發現所交代的東西聽起來只是大方向，但沒有更清楚明確的規劃或指示(也就是說有聽懂，但往細部想，是空空的，需要施展通靈之術)，或發現好像還沒想清楚，也感覺不出有要進行討論的意思`_==
==_`➜可以說 : 還是等你想好、規劃好再跟我說，因為我聽完還是不清楚要作的東西、範圍與程度`_==
==_`➜可以說 : 還是說我們需要先一起討論討論，討論後等你整理與決定好後再跟我說`_==
- [x] 對方有說優先順序嗎？ **沒說有反問嗎？**
- [x] 對方有說什麼時候完成？ 或期望什麼時候完成嗎？ **沒說有反問嗎？**
==_`如果發現手上工作有可能會應付不來，會影響到交付日期，可以提出討論`_==
:::

:::info
**<font class="pm">PM</font> 與 <font class="pg">PG</font> 在進行工作交付與接收，有達到共識嗎**:question: :question:
- [x] 不管如何，一定會存在標準與認知的落差，即使再有經驗也會有，我們都不是對方肚子裡的蟲，所以必須透過互動「說出來」與「溝通」，進行「釐清」，逐漸減少與縮小落差
:::

:::info
**<font class="pm">PM</font> 與 <font class="pg">PG</font> 在工作執行的過程中，有互動、有溝通、有討論、有協調嗎**:question: :question:
- [x] 大家除了守本分的把事做好外，<font class="pm">PM</font> 與 <font class="pg">PG</font> 雙方一定要有互動、溝通、討論與協調，工作才會越來越順暢、越來越有默契
- [x] <font class="pm">PM</font> 在團隊中一定要積極主動去了解成員執行進度與狀況，並看是否有需要溝通與協調的地方
:::

<br><br><br>

---

<br>

:::warning
* **其實…以上都是中文字，除非內容真得寫得很爛很爛，讓大家看不懂，那寫的人就要改進表達方式。**
* **不然…上述想傳達的概念、觀念，應該多多少少都有所理解，最難的是<code class="red">++積極主動的執行它++</code>。**
* **當然…上述得不一定全對，也不是全部，也可能表達的不好，那就要請大家提出來討論。**
:::

<br><br><br>

# :link: 參考

<br><br><br><br><br><br>

<style>
code.red {
color: #e91e63 !important;
font-size: 1.6rem !important;
/*background-color:#FFFFBB !important;*/
}
code.blackred{
color:#900000 !important;
font-size: 1.6rem !important;
}
code.blue {
color: #337AB7 !important;
font-size: 1.6rem !important;
}
code.orange {
color: #F7A004 !important;
font-size: 1.6rem !important;
}
font.pm{
color: #bd0000 !important;
}
font.pg{
color: #006700 !important;
}
.red {
color: #ff0043;
}
.blackred{
color:#900000 !important;
}
.blue {
color: #055787;
}
.green{
color:#126903;
}
.newline{
height:1rem;
}
.newline15{
height:1.5rem;
}
.newline2{
height:2rem;
}
</style>