Footer流行機能專業除臭襪_忠峰霖纖維科技有限公司

  • 產業類別:鞋類/布類/服飾品零售
  • 資本額:
  • 地址:新北市林口區文化一路一段91巷17號1樓 info 新北好薪水
  • 電話:
  • 網址:

薪水待遇

已有9人想知道這間薪水

匿名提供薪水情報,取得積分,查看更多公司薪水情報

匿名提供薪水情報

Footer流行機能專業除臭襪_忠峰霖纖維科技有限公司

公司簡介

Footer流行機能專業除臭襪_忠峰霖纖維科技有限公司,是一家鞋類/布類/服飾品零售公司,公司位於新北市。在薪水待遇調查中已累積超過8人查詢,也透過關注與追蹤方式,掌握薪水表現狀況。如果目前有興趣暸解薪水情報的話,別忘了透過想知道薪水按鈕,隨時關注。另,如果您目前或是曾經是Footer流行機能專業除臭襪_忠峰霖纖維科技有限公司的夥伴,請留下在薪水待遇情報,幫助大家一起提升台灣薪資結構。

沒有找到您想要的薪水嗎?現在就徵求薪水吧~

刊登想知道的職位薪水,讓內部人士告訴你情報!

我想徵求

Footer流行機能專業除臭襪_忠峰霖纖維科技有限公司在PTT上的評價

Re: [閒聊] 環境令人無力orz

https://www.ptt.cc/bbs/Soft_Job/M.1269841692.A.777.html
你這個問題其實已經有一點離題了。 對於網頁設計,第一個要有的概念叫做Layout。 Layout目的是,將一個完整的頁面因為不同的需要切割成不同的版塊。 例如Header、Sidebar、Footer、Content、NavigationBar等等的。 你會希望Layout達到以下的幾個目的: 1.便於調整。 2.跨越瀏覽器。 3.可以各自獨立不至於影響其他block。 W3C中,Table是用來作資料的顯示整理用,而不是用來Layout,Layout經常會出現 多層次的巢狀結構,而<table>標籤非常因為這樣的巢狀結構,使得在調整得時候 造成版面混亂。 另外,跨越瀏覽器也是一個大問題,基本上<div>在不同瀏覽器上面的行為可以用 css來控制,但是<table>標籤在不同瀏覽器上,本身就存在著差異,光是換行的 狀況,在不同瀏覽器就會有不同的樣子。 因為用<table>標籤切版,所以當上層或下層的table屬性改變得時候,經常會影響到 其他的部份。要知道一件事,版面設計的時候,設計師可以用<table>很爽快,但是 交到程式設計師手上,在套入不同data的時候,<table>的layout會是設計師的惡夢。 當設計師用dreamweaver或frontpage的<table>作Layout做得很愉快的時候,卻沒有想 到對Programmer而言,這些<table>的Layout在寫程式時卻是惡夢。 不能只動CSS改變版型,一堆爛爛的<tr><td></td></tr>...甚至是colspan, rowspan, 在做Template時都是惡夢,要知道,設計師交給程式設計師的,只是樣板,也就是說, 程式設計師還是必須要切割成不同的block分別儲存,不管你是用Smarty或是Tiles. 不懂CSS Layout的Designer在我們的眼中,沒有資格稱得上Web Designer。 不瞭解按照標準去定義CSS Styles檔案的Web Designer,只能算是不入流的Web Designer。 這樣的人只是給Programmer造成負擔而已。Programmer不應該浪費這些寶貴的時間幫 不入流的Web Designer擦屁股。 說難聽一點,若我是Programmer,我不想跟這種會降低我的生產力,連Layout都要我 來寫CSS的設計師合作,最近遇到一位外包的設計師,水準相當不錯,CSS檔案看起來 很有國外Wordpress theme的風格,跟這樣的設計師合作,不但彼此都很愉快,工作 也能更快完成。 要解決跨瀏覽器的問題?不難,請愛用CSS Framework如Blueprint,作為一個進階的Web Designer,不能只靠著工具,Blueprint等得CSS Framework已經是對Designer跟Programmer 最友善的Tools。 有心的話去看一下Facebook跟Plurk的頁面,有幾個<table>標籤。 以現代的技術,用<table>來作Browser Layout是「錯」的。在任何的情況下,都是錯的。 當然每個人能力不同,不是每個人都可以搞到像Facebook那麼威,只是錯多錯少而已。 -- 所有我的作品,請到..... ~四十八個德瑞克~ 馬皇本紀: 上官先生傳: -- ◆ From: 61.64.191.30

[心得] 協同合作系統建制與導入

https://www.ptt.cc/bbs/Soft_Job/M.1423141882.A.6BA.html
看到前面有人分享在 start up 做 Tech Lead 的心得, 也想來分享一些這幾年的工作心得, 比較不是技術面的, 但也是在 start up 的一些心得. 在這個工作之前, 我比較長的時間都是在做 java developer 的工作, 因緣際會, 跑去做了 SQA 的事情, 在這家 start up 做的則是 SQA Manager (黑臉/壞人) 的工作. 過程中, 遇到很多有趣的事情, 和讓人瘋狂/崩潰的故事 .... 文章描述的方法或工具, 都不是最新的, 但或許是一個拋磚引玉的分享. 文長, 有在 start up 做過, 可能會更有感覺. PS: 如果有同事看到的話, 鞭小力力一點 XDD 線上閱讀: 本文開始:協同合作系統建制與導入 - 以 Redmine 為例 -- 我很重視團隊溝通的效率和方法, 包含問題回報, 文件表達, [會議], [工作管理], 因為 [溝通=成本]. 以前系統沒那麼進步, 這些成本就算了, 但是現在時代那麼進 步, 還用很沒效率的方法在做事, 就很可惜. 通常系統的設計是符合一般的需求, 而且是遠大於需求, 所以導入一套系統制度, 通常要改變的不是系統, 而是人. 當 然系統也要調整, 為人來調整. 當時在導入 [Redmine][2] 之前, 我花了很多時間, Survey 過很多套類似的系 統, 一開始目的只是做 bug tracking 為主, 然後我熟悉的優先. 從安裝, 然 後試著建立 scenario, 模擬各種 role, 了解系統的需求, 如何維護, 哪些單 位需要使用 ... 等等. 當時公司內部使用的 [Mantis][4], 先前我做過的案子使用的過 [Bugzilla][5], 同仁推薦 [Jira][3], 因為看到 Jira 和 Redmine 除了 bug tracking 之外, 同 時也兼具了專案管理的功能, 甚至是文件系統, Forum ..., 另外還可以有 pluggin, 基於同樣的想法, 我又繼續找看看有沒更完整的系統, 後來找到了 [CodeBeamer][1], 也試著和台灣的代理商聯繫過. [CodeBeamer][1] 是要錢的, 但是他對文件以及 Test Management 就有更完整的 support. 文件系統有完整的 toc (table of content) 的支援, diff, 通知等. 另外也有 DevOps, SCCM, Lifecycle, QA 等模組, 相對來說是更完整的. [Jira][3] 也是要錢的, 它也是很有名的專案管理系統, 他有很多整合的套件, 也和 CodeBeamer 類似, 但是更專業, 有不少大的 open source project, 或者 像 Microsoft 也都在使用. 附帶一提, [Bitbucket]( 就是 Jira 開發公司 Atlassian 所提供的. 經過這些比較, 我歸納出完整的協同合作應該要具備以下的功能, 以及使用對象: 1. *Requirement Management* - PM / Marketing / Support Team 2. *Issue Tracker / Filter / Query* - All Members 3. *SCM / Code Association / Code Review* -- Developer 4. Test Management - QA 5. Report System - QA/PM/Leader 6. *Release Management / Baseline* – Release Engineer 7. *Document System* - All 8. *Custom Workflow / Status* - PM, System Admin CodeBeamer 是比較完整的協同合作平台, 除了 Issue tracking, 也包含其他更多, 但是複雜度也更高. 以當時正在導入 redmine 使用的狀況來看, 不見得適合. 因為 大部份的人工作習慣改不過來, 加上公司既有的文化特性, 導入這些系統只會是專 案另一種阻礙, 除非有高層下來推動. 最後老闆選擇了不用錢的 Redmine, 敲定機器設備, 然後我負責系統規劃安裝, 執行新舊系統的合併, 導入流程, 教育訓練. 然後老闆給我很大的精神支持 XD Redmine 我透過 Config, Plugin, 搭配一些 scripts 的方式, 針對公司文化以 及專案需求, 調整很多東西, 主要是前述需求斜體部分: # 定義追蹤與流程 (Tracker and Process) 專案進行當中, 有很多事要追蹤管理, 這些事情統稱 **Tracker**. 依據不同的 單位以及追蹤的屬性, 我定義了一些常用的 tracker type, 包含: Task, Requirement, Bug, Suggestion, Feature, Improvement, 其他額外還定義了 Document Publish, Release Process ... 等. 這些流程包含針對不同的角色 Roles (PM, Leader, Developer, Reporter, Release Engineer), 會有不同的 狀態和流程. 每一種 trackers * roles 會有不同的流程. 而流程的重點在於 **開始** 與 **結束** 的定義, role 和狀態的流程等. 下圖是 Bug for developer 的流程之一: 事情追蹤以大的為主, 有時候一些小事情, 或者無關要緊的, 則視狀況, 讓同仁自行決定是否建立 Tracker. # 工作管理 上一個 Tracker 定義中有一個叫做 **Task**, 主要用來管理同仁的工作狀況 以及工作相依性. 例如一個功能經常會跨很多 component, 也會和其他很多功 能有所關連. Redmine 每一個 Issue 都具備 subtask 以及 related issue 的功能. 透過這樣的關聯, PM or Leader 就很容易將要做的工作項目, 安排 成樹狀結構, 然後清楚的設定 owner, 工作時程, 相關 issue, 文件等. 推動讓 PM 習慣用 Task 的管理, 取代過去習慣的 Microsoft Project. 在 redmine 上透過 **公開透明, 流程標準化** (這兩點很熟悉吧 XD) 的方式, 讓同仁彼此可以知道彼此的工作內容, 然後 Team Leader 可以適度的調度人 員, 掌握同仁的工作狀況以及 loading; PM 更可以有效而且清楚的知道專案 的狀況. 而 QA 和 RD 也得以透過此方法, 可以加速專案的執行狀況. 這部分也是未來 如果, 主力 project 要導入 agile, 那麼要先具備的條件. 我還在試著醞釀中, 因為目前還缺少一些必要條件與共識. # 文件管理 文件是企業裡面很重要的溝通媒介, 也是公司重要的資產. 大部份的人習慣用 word / powerpoint, 然後存成 pdf, 檔名加時間, 透過 email 寄給相關的人, 稍微有 sense 的會開啟 word 的文件追蹤的功能. 工作這麼久, 我非常非非常 討厭這種很沒效率的方式. 所以我當時借由一個時機點, 在內部提出以下問題: 現在系統已經很進步, 各種 diff 工具, 通知, change log ... 都非常完整. 所以我額外花了一點時間, 了解 redmine 能做什麼, 什麼不夠, 缺什麼, 思考 導入的可能性 .... 等. 最後做了一些內部的推動, 大概做了下面的事情: 1. 文件集中管理, 定義文件結構 layout, 階層. 2. 建立教育訓練文件, 可以提供給未來新人使用. 3. Survey redmine wiki plugin, 增加 redmine 的不足 4. 建立文件的樣板 (Template), 包含 RD, QA, PM, Support, Marketing 等. 導入過程我花了不少時間去做 **說客**, 因為要說服一個既定的習慣, 是很不 容易的, 特別是老闆. 以身作則是我覺得最好的方式, 所以我就自己去做, 包含: 幫忙把很多既有的文件 (word) 轉入 redmine (wiki), 試著定義 template, 改變 wiki 的樣式, 讓他看起來更正式 (header / footer), 然後透過內部教 育訓練方式, 教大家怎麼寫 wiki, 推動用 wiki 寫 design document. 雖然 redmine 的 wiki 還有很大的改善空間, 但是勉強讓同仁有一致性的參考點. 但是針對: 輸出 (Export as pdf/html), 撰寫方式 (WYSWYG), 文件結構等部分, 其實還有很大進步空間. 我也提出一些建議方式可以改善, 執行上是可行的, 可 以利用 third-party 的 plugin, 或者自己寫, 總之, 要一些額外的 resource. 整體而言, 文件管理這部分, 我覺得還有很多討論的空間, 我也持續在 survey 一些更好的方法或系統, 目標是希望可以做到像 [eclipse help center]( 那樣的概念. # 整合 SVN hook 達到 commit code 必須綁定 issue 和 issue status, 達到有效追蹤管理. 當然這會額外帶給 developer 一些 overhead. 專案進行中, 依照 stage 狀況, 完整控制 source code status. 通常是進入 RC (Release Candidate), 會進入 code freeze 狀態狀態, 然後讓 QA 能夠 focus on Regression. 但是也會保留彈性, 放行 must fix 的 issue, 當然 風險就要審慎評估. 配合 redmine 本身的 repository + change assication, 可以很方便的 diff code change, 通知相關人員 (developer or QA) code change. 過程中也曾經試著要導入 Git 作為版本控管, 不過這還是基於企業文化以及 決策者的決心問題, 所以後來不了了之了. 反而技術和教育訓練對我來講, 倒不是太大問題. # 有效的 Bug 追蹤與管理 我們目前專案的進行狀況, 每一個 phase 從開發階段 (6w) 到測試階段 (6w), 每一個 phase 的 test stage 平均下來, SQA team 會開出大大小小約 200 ~ 300 個有效的 bug, 同時這些問題跨過數個 components (cloud server / logistic / iOS / Android / WinPhone / Web / embedded devices 共有 3 * 4 種組合), 這些 component 從純 software 到 mobile app, 到 web, 到 embedded devices (數種 IPCam 和 Network Router) 等, 要掌握 / 追蹤這些問題的狀況, 同時要有 效率的和這麼多 function team 的 developers 在三個地方, 兩個時差, 三種文化差異的溝通, 提出改善建議, 不是一件容易的事情. 更別提我還負責 Cloud Performance 測試部分 (模擬 App/Device 在一定的上限數量的壓力測試), 還有其他硬體的問題 (機構/Wifi Performance/光學/RF/FW ...). 為了有效追蹤這些 bug, 達到溝通以及問題反映的需求, 針對 redmine 裡的 tracker -> bug, 除了重新定義 workflow (參考 "定義追蹤與流程"), 我另外定 義了一些欄位, 描述如下: * priority: 時間優先級, redmine 預設的, 分成 low, normal, high, urgent, immediate. 事有輕重緩急, 加上人也會有惰性. 大部份我採取信任原則, 讓 developer 自己控制時間, 讓 SQA 自行去跟 developer 溝通. 不過有時候太 久沒反應, 我會適時地調整 priority, 同時透過 PM / Team Leader, 軟硬兼 施的方式, push developer 動作. * severity: 問題的嚴重性, 沿用 Mantis 的定義, 分成: block, critical, major, minior, warning, suggestion 六個等級. severity 是作為達到 release 的參考準則. 能夠 release 的條件如下: * 1) test case 是要執行完畢 * 2) severity major 以上的 bug 必須全數 closed, 包含 major, critical, block. * 3) 執行過 Regression, 超過 80% 以上的覆蓋率 * severity 有一個比較特別的是 suggestion, 用來讓同仁對產品提出建議. SQA team 在這方面做了很多功夫, 提供很多實質且有效的建議, 也讓同仁對 於產品更有歸屬感. 訓練時, 經常會跟同仁提及的. 我認為一個好的執行者, 必須要學習如何 [自我管理], 而自我管理的第一步就是時間管理, 了解事情的輕重緩急. 而自我管理則是人生 的課題, 已經遠在這個主題之外了. * reproducibility: 問題的可重現性, 這也是從 mantis 參考過來的. * highlight: boolean, 用來追蹤需要特別討論的 bug, 以縮短週會的會議時間. 通常被 highlight 的問題可能是閒置太久沒反應的, 或者是需要討論的, 這些 問題會直接請 PM push. * TechNotes: boolean, 無法解決的問題, 通常是環境 (像是 iOS 版本) 因素造 成的問題, 通常會請 developer 提供 workaround, 然後 highlight 給 support team. * Reported From: 用來分析問題的來源單位. 很多戲劇小說都有一句話:沒有對錯, 只有立場不同。bug 是否是 bug, 不同單位會有不同的看法以及見解. 這是為了 分析問題以及需求的根源, 定義的有 Developmnet, Field in House, Support, Sales/Marketing, Customer, Manufacturer, Others. ## Issue Template 另外安裝 issue template for redmine, 可以針對不同 tracker 定義常用的樣板, 讓同仁回報問題時, 可以標準化, 減少溝通的問題. ## Category and Target Version 這兩個欄位是 Redmine 預設的, 但是不是必要選擇的. 通常需要 PM 去設定才行. 在專案進行中, 很多人都搞不清楚這兩個的用途, 因為他不是必要的選項, 所以常 常空著沒選, 造成 PM 或者 QA Manager 建立 query or filter 時無法掌握狀況. 這兩個簡單說: Category 是 **邏輯** 的分類, Target Version **實體** 分類. 所有的問題一定需要有明確的修復目標, 明確要 commit 到哪裡, 所以 Target version 我會在專案一開始就定義清楚, 同時要求同仁要確實選, 如果不知道怎麼 選, 表示不清楚問題點在哪, 那麼就要討論. 而 Category 是邏輯的定義, 一般就是指一個 function or item. 我們的專案很 複雜, 所以這部份很難定義, 目前我在專案逕行中, 用來做問題分析使用, 每一 個 phase 都回重新整理, 所以沒有強制同仁要選擇. # Version Control and Autobuild Target Version 牽涉到 version control 的問題, 簡單說就是如何定義版本號碼, 以利未來溝通. 我引入一般 x.y.z 規則. 也定義了個別的意義, 以及什麼時候該怎 麼跳號. version number 除了做控管, 有些邏輯也會用到, 定義清楚, compare 的邏輯就容易寫. 另外就是跳號管控方式與時間, FW 和純 software 會有所慣例 的差異, 後來我和 device team 協調統一規則, 讓溝通更精確. 我定義了一個標準的 interface 描述版本控管, 格式就是 key/value 的 Properties, 欄位如下: ``` comp.name=iOS version=1.2 fixpack=3 buildId=%TIMESTAMP% revision=%SVN_REVISION% buildType=dev ``` 這個檔案我把它叫做 `releng.properties`, 全名是 [Release Engineering] 的縮寫. `releng.properties` 在所有 component 裏都會有, 優點是透過統一個 agent 管理所有的元件, build script 有一致性的標準. 然後透過我就用 python 寫了一 個叫 `autobuild` 作為 daily build agent. 透過簡單的架構以及可擴充性的設計, 同時部署在數台不同機器, 每天 build iOS / Android / WinPhone / JEE application / Embedded ... 等, 產生報表以及通知. Build Fail 會自動通 知 developer, build 的過程會有詳細的 log 以及所有的訊息, 其實有點像是 jenkens 做的事情. build 出來的 image 會有固定的格式, 像是: `App.iOS-1.2.3_InHouse_b20141203-1200_r2356.ipa` 人是健忘的, svn revision 意義不大, git hash code 也是, 所以 buildId 是一個必要的資訊, 讓大家用時間追. autobuild 這件事情間接讓 developer 和 QA 可以專業分工, QA 開的 Bug 會很精 確的描述 build 的訊息以及時間. ## Bug 的組織分析與管理 Bug 的追蹤與管理, 要善用 query / filter 做有效的 [組織與分析], 然後對 於 **人** 也必須軟硬兼施, 不疾不徐, 得以讓事情順利進行, 同時也不會造 成 RD 與 QA 的爭執. 有時候必須扮演黑臉, 有時候也需要扮演潤滑劑. # 導入軟體開發流程 (Software development life cycle, SDLC) 前面講的都是 redmine 的功能面, 其實貫穿整個協同合作系統的精神是 **軟體開發流程**. 2012/04 到這家公司發現一件讓我覺得很不可思議的事, 就是這邊是沒有流程控管 的概念, 不清楚事情先後相依關係, 不清楚角色定義以及工作流程, 沒有停損, 沒有 release 概念, 也不懂得怎麼做專案控管, 沒有 development, release, deployment, production 等認知, 對於測試更是完全沒概念, 更別提 **軟體開發流程** 的一些方法論. 整個工作模式完全是傳統的硬體代工思維, 不難想見當時做出來的東西是長得什麼樣. 2012 下半年, 我和一群我雇用的年輕 QA 工程師, 還有辛苦的 RD 們, 大家憑著 一股熱忱 (怨念?), 透過原本公司是既有的 Mantis 追蹤問題, 大家天天加班加 到昏天暗地, 硬是把東西做出來, 雖然依舊只是堪用的東西而已, 但至少比先前 好很多. 後來我花了很多時間, 把以前在 IBM 做 projects / products 的流程和經驗, 加上過去半年來對這家公司文化的了解, 做了適度的調整與安排, 然後說服老闆 (這很重要), 取得對應的資源 (IT/權限/Server ...), 讓我對內部做了完整的教 育訓練, 導入基本的軟體開發流程 (Software development process, SDLC): 瀑布模式 (Waterfall), 內容引用 IBM development lifecycle 部分的名稱與方法, 同時將開發流程整合到系統, 讓流程系統化, 導入 autobuild, 整個流程如下圖: 然後在老闆的支持之下, 將公司既有架構在 Windows 上的 Manits/SVN/trac (EasyCM), 全部轉換到以 CentOS 為基礎的 Redmine/SVN. 當然中間也花了一些時間到各個 site 做教育訓練, 以及內部的溝通與協調, 讓同仁 *漸漸了解* 軟體開發流程的重要性, 以及什麼時間做什麼事情. 了解流程之後, 同仁 就可以自發性的控制自己的工作時間, 更能專注的執行專案任務, 同時也減少不必要 的加班工時. 專案也能夠有效的控管, 準時的 release (delivery / publish / deployment) 有品質的產品, 達到上面的要求. 這個 **漸漸了解** 其實花了我快一年半的時間. 有了流程, 有了系統, 透過教育訓練將這兩個制度連結起來, 剩下的就是看它發酵, 讓大家體驗成果. *發酵* 過程包含了各式各樣的衝突與相互了解的事件, 總之, 最後大家漸漸有了共識, 信任, 還有默契. 當然過程中我也考慮過導入現在流行的 agile, 不過產品性質 (軟硬整合) 以及公司文化因素, 主要的 project 暫時沒導入, 次要的則已經導入. # 改進與期望 經過快要三年來的導入與調整, 目前 Redmine 有使用的單位主要是以 Software RD + SQA, 另外有 Support, 其中包含 RD 有 6 個 team, 分別在三 個 location (US, TPE, Wuhan), 人數約在 50 - 60 人左右. 不管是彈性還是 功能, 是滿足大部份的 project. 除了傳統的 waterfall 開發流程, 有另一個 web project 是使用 agile 在跑, 所以 redmine 在專案管理是可以滿足大部份的. 另外可以繼續改善的有: 1. 還是文件系統 * 有更方便的編輯器會更好, 或者支援 markdown (redmine 2.x 之後才 support markdown) * 有 review, comment 機制更好 * 更好的輸出模組 2. code review 機制 3. 整合 slack 這種溝通系統, 讓 developer 溝通更有效率 4. 整合 Test Manamgement (我後來買了 testrail, 功能很強大, 但是我錯估 和 redmine 版本的差異性問題, 所以整合的沒有很順 5. 和公司的 IT 系統整合: LDAP or AD 一直沒有順利, 因為公司的 IT 系統複雜, 不好整合 6. 可以整合類似 Google Docs 線上協同作業的系統, 同仁可以在上面貢獻想法, 發想鬼點子 .... 這是我天馬行空的想法 XD 整體來說, Redmine 是很棒的專案管理系統, 管理者還可以配一些免費的 app (easy redmine, rougemine), 隨時掌握狀況; 使用 eclipse 的 developer 也可以搭配一些 plugin, 簡化工作流程. 但是 Redmine 在文件以及 release 方 面並沒有比較嚴謹的功能, 勉強只能算是堪用. 如果系統使用者要跨越到其他像 是 support, marketing, sales, 甚至是 end user, 就還需要做一些調整, 不過 我覺得應該是沒問題的. 除了上述列表中的, 其實我還想做幾件事情: 1. 導入 git, 取代 subversion. 不是為了趕流行, 而是希望讓 developer 能更 有彈性做事情. 2. 將 redmine 做異地備援, 也就是利用 mysql master-to-master 架構, 讓不同 地區的同仁, 可以有同樣存取 redmine 的速度. 然後也可以有備份的效果. 3. 導入 agile 以及落實 requirement management. requirement SOP 導入是困 難的, 因為這牽涉到與上層溝通的問題. * 通常我知道台灣很多公司愈高層, 越不會用這種系統, 也越不懂它的價值所在. 而這是一種決策支援系統, 決策者沒有信賴依據, 憑感覺決策是很不可靠的. * 如果一家公司或者政府機關的財務人事系統是用 excel, 你會期望他有什麼效率 可言嗎? 4. 將公司其他部門的文件納入管理, 因為實際上我們很多文件都是會相互參考, 但 實際上卻是到處散落. 5. 讓其他 team (Sales, Marketing, PLM, support ... ) 等, 也來使用, 讓內部 的資訊更同步. # 結尾 系統的導入目的在於讓工作流程標準化, 公開透明 (有沒有和柯 P 的理念很像XD); 讓訊息與資源集中統一管理, 讓同仁可以透過它, 清楚明白自己的工作任務, 即時 修正; 管理者可以清楚掌握專案狀況, 資源多寡, 同仁的工作狀況; 決策者做即時 的組織與分析, 進一步做出有依據的決策; 系統的最大的目的就是: **減少溝通所 造成的成本問題**. 系統流程導入的過程, 最難推動的還是管理階層/高層. 系統的導入, 需要仰賴高 層的認同, 然後一起推動, 或者充分授權與信任, 讓執行者得以與不同的 team 溝 通, 然後重新定義流程, 使用規範等. 幸運的是, 我的老闆很支持我做這件事情, 也給予了充分的授權與支持, 所以我得以大刀闊斧地去推動這些事情; 過程中也有 幸同仁給予很多回饋, 與配合, 讓我能夠驗證這些方法的可行性. -- ::: 喝咖啡 聊音樂 ::: -- 工作分配是 PM / Leader 的職責, 除了定義 item 項目, 同時也要定義每一個 item 的 priority, type, 指定 owner, 評估 effort. 了解每個 item 相互的關係 (有關的, 對上對下的關係), 相依的 components, 使用 third-party api ... etc.. 這點做不好, 只能仰賴有經驗的 developer, 或者看看會不會發爐 XD 我到這家公司之前, 其實原本的 developer 也裝過 redmine, 不過不知道裝來做什麼, 擺在那裡好看而已. 系統的價值, 還是怎麼去規劃以及導入, 再好的工具, 人不會用都是空談. 自己去做導入, 才知道為什麼 CMMI 導入的費用那麼貴 ... 吃過苦頭就會知道了, 我也和 developer 經歷過類似的衝突過程. 後來大家知道該怎麼做了, 沒有 issue 讓他們 tracker, 反而會不習慣. 因為歷史會開始重演, 有一些 bug 會造成 side-effect, 大家開始會感覺以前追蹤的紀錄, 很有參考價值, 時間會證明給大家看. 我以前做 developer, 就習慣用 issue 做每件事情的追蹤, 包含 design document / unit test 方法 / ut 報告 / schedule / 相關的 component / 相關的 bug / 參考資料 ... 等, 只是不同工具而已, 以為這是 developer 該有的 common sense, 到這家公司才知道很多人都不知道, 所以造成一些衝突. 後來才知道, 很多公司專案管理, 連切票都不知道, issue bind source control 沒聽過, SVN / git 只是一個很高級的檔案系統而已, 也有離職的同事說, 新公司完全沒有控管, 都不到在做啥 ... 原來類似現象, 在很多公司都有 ..

Re: [討論] 你想成為怎樣的軟體人?

https://www.ptt.cc/bbs/Soft_Job/M.1360034303.A.558.html
之前有在專案與一個前端工程師配合 他本來是後端用.NET的 然後改走前端 配合起來沒話說 我把我寫好的初版交給他 他拿去改一改 然後把靜態頁給我拿回來套 我只把主板切出來 其他沒甚麼改 瞬間就套好了... header footer main 的部分都用駐記標好 新手都知道怎麼切 這應該就是後端轉前端的優勢之一吧 不過話說回來 在小公司 有幾種都叫做Art 會畫圖是基本 1.不會切版 2.會切版 會HTML 不會CSS + JS 3.會切版 會CSS 不會js 會flash 4.都會 在大公司的職位名稱為F2E 畫圖不一定熟 但都熟 HTML + CSS + JS 然後混雜程式碼大多也看的懂一些 然後在小公司 這些人做的事情都不一樣 但是領的薪水有些情況常常差不多 曾在一間還算賺的公司的資訊部 遇過要跟只會畫圖的Art拿張圖 還要拜託她 一天只畫一兩張圖... 就是把廣告單改一改 去背 放商品上去 然後還不能催她 不爽會請假出國玩... 然後另外一個會切版不會CSS的Art 是一天內會用我提供的素材切出3主頁 總計9頁的網站 兩邊領的薪水卻差距不大 是一直想不透的地方... -- ◆ From: 202.89.121.16 恩...我這解釋下 只會設計版面配置是我說的小公司第一種Art 就是純畫圖而已 畫出老闆喜歡的東西 不會CSS會切版 是指他純用HTML作出靜態版面 Style都寫在HTML Tag <Table><tr><td> 不用<div class="one" > 這種的 我也只遇過一次這種的啦 在foreach array的時候會有排序的問題 1 3 5 在上面 2 4 6 在下面 沒辦法一次跑完 然後少了文字的話會內縮 爆版之類的問題

Re: [閒聊] 環境令人無力orz

https://www.ptt.cc/bbs/Soft_Job/M.1269914683.A.9AC.html
我一直都是設計師,從找錯戰場這件事情出發, 就當做給原po拍拍吧...XD 自己在現任的職位上應該分屬員工和主管的角色, 目前負責的網頁大約十幾個網站,共計約一萬出頭個 htm 檔, 完全沒有使用資料庫, 穿插 frontpage 時代的成品,間或有 java applet 的效果在裡面。 因為實在太古老了,有很多檔案原始碼開起來, 放眼望去盡是我沒有看過的語法 XD 因為接手後,製作、維護、更新....等責任,都是我, 所以我才說自己既是員工又是主管, 以下是我面對這一萬多個檔案的應變方式: 1、如果程式設計師可以配合寫資料庫、做後台, 我會用 css + div 去做網頁, 而且做到不管是 banner、footer、導覽列...要修正的時候, 可以從單一檔案修改,而不是每一頁都要開起來。 2、遇到更動頻繁,又沒有資料庫,非得要手動修改的時候, 在視覺美觀容許的範圍裡,儘量減少網頁複雜程度, table 可以用上沒關係, 免得哪天我突然掛了,接手的人不會改。 3、所有檔案包括 .css 都要加上註解。 4、一定要漂亮到靠杯,卻又不需要任何選取功能的網頁, 直接比照 eDM ,photoshop開起來切圖放下去了。 當然我能有這麼多自由,是因為上面完全把權限放給我, 就因為一切都是自己決定,更不能愛怎麼做就怎麼做, 我自己認為的職業道德就在於: 1、在 deadline 之前把事情做完。 (當然這死線都是我自己訂的 XD) 2、在我離開單位之後,接手的人不會持續詛咒我祖宗十八代, 反而會感謝我怎麼交代的這麼清楚。 3、我最大的期望是,一個剛出學 web design 的人, 只要用功,查查 google 教學,就可以看懂我在做什麼。 不一定要會自己做出來,但至少知道我的脈絡,會改就行了。 4、tabel/css 技術沒有優劣,方式沒有好壞, 用的好、用的快、符合當下作品和環境要求,就是最適合的方式。 我承認身為設計師或工程師,都有一定程度的驕傲和自尊, 很多時候,維持自己的原則往往和企業永續經營(快速致富?)的理念相左, 當然大環境太差也是一個因素, 要嘛不是把自己弄到很強,進去一流的網頁設計公司, 要嘛就是一邊順應時勢,一邊私下練功, 不然就第三條路,自己創業。 第四條路也是有啦.....轉行吧!! 是說台灣的設計還有明天嗎? -- -- ◆ From: 140.115.95.115

[情報] 最後三天!報名新竹黑客松贏取首獎8萬

https://www.ptt.cc/bbs/Soft_Job/M.1448117816.A.F4D.html
高齡90年的前所未見的33小時, 新竹黑客松,正式開始! 來去夜宿古蹟新竹州廳,兩天一夜打造新竹市民該有的網路服務, 新竹市府懸賞,捕捉, 邀請各界網路、程式應用高手來新竹體驗古蹟之夜! 【活動時間】 ,共計33個小時。 【報名時間】 即日起至11/25(三) 12:00截止,一律採網路報名 報名網頁: 【參賽方式】 1. 每隊1~4人,以團隊為單位填寫報名表格。 2. 團隊中至少需有1人具備手機應用APP開發或web前端開發之技術。 3. 報名時需提供團隊成員專案經歷、團隊分工方式。 【活動費用】 !保證金1000元於參賽後發還。 為鼓勵更多參賽隊伍加入,新竹縣市以外之全程參賽隊伍,憑11/27~30間往返新竹之大眾 運輸工具(高鐵、台鐵、客運)交通票據,可,每隊上限1萬元。 【競賽獎勵】 第一名:新台幣獎金壹名。 第二名:新台幣獎金壹名。 第三名:新台幣獎金壹名。 佳作:新台幣獎金貳名。 【競賽內容】 運用新竹市政府提供的、過往、使用數據等,設計出新竹市民 需要的網路服務、app功能。 【評分標準與權重】 結構完整及可執行性 35% 使用者體驗及整體設計 30% 創意設計 25% 新竹市府Open Data 介接應用 10% [加分] 參見下方參賽加分項目 10% 【參賽成品】 1. 請依據(Responsive Web Design)方式設計。 2. 競賽成品格式可為設計原稿(PSD、AI)及網頁(Html、PHP、aspx、JSP等)。 3. 參賽者使用之圖片、影像、設計元素等以不侵佔或侵害任何其他人或實體之任何著作權 為原則;如有侵權主辦單位得取消其參賽資格。 3. 網站納入新竹市府識別Logo 4. 本次活動當天研發成果權利屬於參賽團隊,但我們鼓勵參賽者以open source的方式對 公眾釋出成果。 1.網頁符合官網無障礙規範 2. 納入下述市府官網架設需求功能 快速連結區功能:回首頁、網站導覽、語言版本切換(英文本、日文版) 全文檢索:搜尋文字輸入、進階搜尋、熱門關鍵字詞 跑馬燈 選單目錄 FatFooter 頁尾資訊 網頁可於以下主要瀏覽器順利運作及檢視: Internet Explorer、Microsoft Edge、Mozilla Firefox、Safari、Chrome 即日起至11/25(三) 12:00截止,一律採 報名網頁: --

您覺得這家公司如何?

寫評論

覺得自已賺的多?
新巨企業股份有限公司維修比一比

1人比過
比薪水

覺得自已賺的多?
金屬中心_財團法人金屬工業研究發展中心工程師比一比

0人比過
比薪水
熱門公司薪水
  • 群創光電股份有限公司

    70人想知道薪水

    27筆薪水
  • 鼎新電腦股份有限公司

    42人想知道薪水

    7筆薪水
  • AUO_友達光電股份有限公司

    54人想知道薪水

    12筆薪水
  • 鴻海精密工業股份有限公司

    50人想知道薪水

    12筆薪水
  • 力成科技股份有限公司

    63人想知道薪水

    5筆薪水
  • 勤業眾信聯合會計師事務所

    36人想知道薪水

    10筆薪水
  • VIS_世界先進積體電路股份有限公司

    38人想知道薪水

    5筆薪水
  • 中華電信股份有限公司

    52人想知道薪水

    9筆薪水
  • Asus_華碩電腦股份有限公司

    54人想知道薪水

    8筆薪水
  • 友達_友達光電股份有限公司

    45人想知道薪水

    5筆薪水
  • 中國鋼鐵股份有限公司

    120人想知道薪水

    5筆薪水
  • 廣達電腦股份有限公司

    66人想知道薪水

    11筆薪水
  • 台塑_台灣塑膠工業股份有限公司

    22人想知道薪水

    5筆薪水
  • Wistron_緯創資通股份有限公司

    91人想知道薪水

    12筆薪水
  • 京元電子股份有限公司

    32人想知道薪水

    5筆薪水
  • 日月光半導體製造股份有限公司(日月光)(高雄廠)

    80人想知道薪水

    28筆薪水
  • 矽品精密工業股份有限公司

    41人想知道薪水

    11筆薪水
  • 仁寶電腦工業股份有限公司(仁寶)

    61人想知道薪水

    5筆薪水
  • Synology_群暉科技股份有限公司

    45人想知道薪水

    5筆薪水
  • 聯華電子股份有限公司(聯電)

    42人想知道薪水

    9筆薪水
  • 新光三越百貨股份有限公司

    50人想知道薪水

    10筆薪水
  • 中國電子股份有限公司

    22人想知道薪水

    6筆薪水
  • 華亞科技股份有限公司

    20人想知道薪水

    8筆薪水
  • 中央研究院(中研院)

    39人想知道薪水

    6筆薪水
  • 玉山銀行_玉山商業銀行股份有限公司

    25人想知道薪水

    7筆薪水
  • 台灣美光記憶體股份有限公司

    60人想知道薪水

    7筆薪水
  • MTK_聯發科技股份有限公司

    44人想知道薪水

    9筆薪水
  • 光寶科技股份有限公司

    99人想知道薪水

    12筆薪水
  • 宏達電 HTC Corporation_宏達國際電子股份有限公司

    32人想知道薪水

    10筆薪水
  • TSMC_台灣積體電路製造股份有限公司(台積電)

    137人想知道薪水

    43筆薪水
  • 聯電_聯華電子股份有限公司

    33人想知道薪水

    8筆薪水
  • 台新金控_台新國際商業銀行股份有限公司

    29人想知道薪水

    5筆薪水
更多熱門薪水
身價是跳出來的,有按讚有見效