---
# System prepended metadata

title: 2020.03.27 第四次Meeting
tags: [題目確定, 溫室, 下學期, Meeting]

---

2020.03.27 第四次Meeting
===
###### tags: `Meeting` `下學期` `題目確定` `溫室`

:::info
- **Location:** D02-322
- **Date:** Mar 20, 2020 10:00 AM
- **Agenda**
1. 嘉義大學自然農法學園提案討論 `60min`
- **Participants:**
    - **林宸堂 教授**
    - **蔣昆興**
    - **黃士芬**
    - **盧俊吉**
    - **曾彗瑀**
    - **蔡岳霖**
- **Contact:** James Lu **<james40309@gmail.com>**
- **Host:** 黃士芬
- **Reference:** - [Last week meeting minute](/s/template-meeting-note)
:::

> [TOC]
> 
## 系統架構圖
可以分成核心功能(專案主要要做的)與附加功能(可以排priority)，或自己多分幾種，當然還是先做到最好。這會牽涉到實務的問題，什麼東西在實務上有意義的(核心功能)。系統端跟消費者端不要畫在同一張圖，可以先分這兩個，兩者下面的功能也許會也關係也許也沒有。

## 實務應用的問題
常常談完需求，東西做完，卻無法上線，其實都是差在決心，因為都會需要測試、維護(做義工)，可能都會超過專題時間。所以需要考慮到實務上如果要上線，那些要做那些不要做，有時候比較實際、有意義的東西可能在技術面會比較沒有深度，但是還是希望可以做出有技術價值的，就是怕東西做出來厲害但不好用(有可能是技術本身的問題或是做的不夠)。

## demo 或 proposal的時候重心會不會因為系統端和消費者端都要顧就跑掉
本來就是這樣啊，就看你怎麼說故事而已，有些東西需要系統端和消費者端一起講才會了解，到時候demo的時候有些不必要的不需要講，講重點特色，大家都大概知道系統長怎樣，要講出他們不知道的，甚至有時候要靠故事來避掉做不好的地方。

## 亮點：遊戲
其實就是類似集點換產品的概念，但是要看最終目的、主要客群，如果都是婆婆媽媽、老師，對他們來講遊戲會不會太複雜，搞不好單純做集點會對他們來講比較直觀比較願意使用。集點也許調整的彈性還比較大一點，如果遊戲也要做到可以隨時調整就會複雜許多。遊戲也會有美編跟定位(大家聽到遊戲會有所期待、與其說是一個有趣的東西)的問題。

## 自助取貨
可以想想怎麼做，結合硬體也會蠻帥的

## 蔬菜箱
他們有沒有想過要作蔬菜箱，其實還是要研究他客群的分類，如果主要都是老師、附近的婆媽的話，就也不用往宅配做。如果可以當然是希望可以往外擴展。但是至少還是要守成。
> 訪談的時候可以問問看

## 食農教育
要釐清辦的目的，如果是要交差了事對大哥是個困擾，那就看怎樣可以最方便達到績效。如果是做行銷，那就要想想做這個的意義，會不會算系統能做的一部份，如果不是就不用放進去了。

## 實務操作
實務類型的題目，需要考慮到實際的操作方式，要實際演練，依實際的工作情況下去設計系統應用方式。

## 訪談問題
1.主要客群2.付款方式3.消費者取貨方式4.食農教育的目的(行銷、教育部的計畫？)5.自主取貨怎麼樣

## 系友訪談
下禮拜自己先找，跟學長姐講說願不願意，然後說要跟老師回報一下，不要直接跟學長姐說確定要他。

## 4/10號meeting
不管進度怎樣都要跟老師報告，時間有點不夠了