改乎? 蟲乎? (中英對照版)

七月 17, 2010

說到 SDLC, 每個資訊人最受不了的地方, 就是當你的客戶跟你說有東西要改吧?

In my experience, one of the least sexy thing in my previous jobs is change requests from internal clients.  Contracts with external clients has all the responsibilities laid out properly, but unless you have a SLA (service level agreement,) “responsibility" is a very fuzzy word internally.

如果是外面的客戶那就還好.  合約中一定會明文說好什麼情況下會是誰的責任 (如果連這都沒有的話, 那 legal department是在那邊做啥的?) 如果釐清了責任, 那接下來就是決定由誰出款, 然後要改的地方的重要性, 及緊急度.

但像我所在的這組, 我們所負責的軟體全都是給內部人員用的.  沒有這些小工具, 他們徒有再好的流程, 也是沒有用的.  (之前我還有提議過用 Flickr來當作 inventory system, 跟用 WordPress來做 workflow enablement… 但別人都當作笑話看.)  但是現在問題就來了 – 程式本身寫的馬馬虎虎, 很多東西其實都寫在程式裡面, 而不是用像是 XML或是其他的設定檔.  那問題就來了, 如果某一個 dropdown選單需要多加一樣東西, 這是個蟲呢, 還是一個 CR (change request?)

In my previous job, I often see multiple coding style residing in small projects.  Some were really good at using arrays, while others like myself rely on newer technologies to reduce manual work (I love DataSets!)  Since no one spent any time on designing, a lot of objects such as dropdown menus are hard coded into the application.  As result, anytime our clients want to change a few options, we would have put up a build to accomodate that.

What defines a change request?  If clients want to add another option under our poorly designed and coded dropdown menu, should we consider that as a valid CR?  Or should we consider that as a defect?  By definition, it should be a defect as business can function without it (it is not defective yet,) but at the same time it is not a fault.  A change request?  I would say our clients should have full access to all the options on the tools they use so they can manage them.  Another issue with change requests is cost – a change request would go through multiple layers before I can actually look at it.  Someone would first find the right team responsible for the tool, then the manager has to resource a person (or two) to look at the change request.  Before you know it, a simple 30 minutes change would result in two human-hours of work without actually getting anything implemented.

分成這兩邊, 又不得不提起工作效率的問題.  假如是一個 dropdown選單的東西需要加減的話, 照理來說做出這個要求的傢伙必須去填一堆表格, 然後等我的 manager排資源去做這件事.  現在問題就來了 – 一個明明只要花不到三十分鐘去做的事情, 繞了一大圈後, 反而用掉一群人總共約兩個小時的 overhead去審核, 或甚至拉一大串 email去找這應該是分配給誰才對?

engagement model

engagement model

這就是效率的問題.  那接下來又不得不講到責任的問題.  身為一個開發者, 你會去在乎這一個小小的 request兜了這麼大的一圈, 然後最後才落到你的手上嗎?  但不這麼做又不行, 你如果開了後門先例, 以後看著辦吧!  所有的使用者都會跑來叫你改東西, 只因為 “上次某某的那個你都幫他做了, 那我們這個也順便嘛!"

You would say “well screw it, I am going to save everyone’s time and do this myself."  Great, guess what?  The clients love to talk to each other, and before you knew it, you would have a line up outside your virtual door (in this case, emails flying into your Outlook.)  Depending on how your manager measures your performance, this can be a huge issue as the manager cannot track all these “backdoor requests."  While you are busy working on these items, real pressing issues with higher visibilities are sitting outside and eventually will burn you if not resolved sooner.

在我工作的地方中, 一個系統負責人的績效是從兩方面去打分的:  1. 修補漏動跟抓蟲的數量及速度.  2. 新 project中的 estimate的準度及真正 implement時所用的時間.  如果你大開後門到處當好好人的話, 很不幸的是, 你所做的事情並不會反映到年終的考核上.

In fact, 這就是吃力不討好的事情!

今天就遇到一個天兵級的內部客戶, 她透過公司內部的問題回報機制, 傳了兩個 “重大問題" 過來.  我們基本上公司內部的問題分約三層 – 小問題, 重大問題, 及解決後可能有人要準備下臺的問題.  重大問題一定要在約 24小時內解決, 所以我當下馬上打了通電話給她.

I had the pleasure talking to one very thoughtful client earlier.  She filed a severity two ticket wanting to have a report fixed.  Here is the background:  there are three severity; Severity one implies red alert and get it fixed soon, otherwise heads will roll; Severity two demands to have the issue fixed within the hour or otherwise; Severity three is the one we care less.

After talking with her for about 30 minutes, I found out she was proposing a process change through reinforcing the process through tools.  This is great – I would love to shape people’s behavior through changing the tool they use, except my experience tells me such change management style would only result in big failures.

聽她講了約十分鐘後, 我才發現她所敘述的, 並不光只是個系統的問題.  從問題回報系統上看來, 她只是在抱怨我們的某一個報告中的數字不準確.  但在她長篇大論的解說之後, 我才知道她所想要改變的, 是一整個部門的某一個流程.  但很不幸的是, 以她的視野及她所受過的訓練, 她認為最好的做法就是從系統開始下手.

Essentials of a Company

Essentials of a Company

The dynamics of employees, processes, and systems (also known as tools) are essential to any organization.  Just imagine a firm with no employee – until the day computers can do everything (literally everything, and that will also be the day when Skynet attacks…) we still need humans around.

The three elements would grow with each other – employees can improve processes, which would require supports from the tools.  The tools would help employees to focus on higher value tasks, and the process helps shaping the behavior of systems and employees.  Although an organization can be completely fine with only processes and employees in place – since humans make mistakes, a system will greatly reinforce what employees can do.  On top of that, a system can also automate repetitive tasks to improve productivity.

說到流程, 系統, 與員工, 這又是完全另外一個故事了.  這三樣東西是一個產品線的命脈, 缺少了其中一個都不行 (除非是生產線完全自動化…)  員工(employees)去做一件事的方法要靠流程(process)去規範, 而一個流程會跟著員工而改變.  流程本身可以不靠系統而存活, 不過在大家都求快求準求透明化的環境中, 是不可能沒有系統在後面撐腰的.  同時, 一個系統如果沒有流程的需求, 那他存在還有什麼必要性?  (打個比方 – 咱們上桌吃飯有先後之分, 這個是個系統.  而後面支撐這個系統的流程, 就是禮數.  如果沒有禮數的話, 那我們還尊循這個系統做什麼?)

三角關係的最後一環, 就是員工與系統之間的巧妙關係了.  流程雖然規範了員工做事情的方式, 但沒有系統去強制執行, 再怎麼守規則的員工也會有犯錯的時候.  (就像 Dell偶爾會出包打錯價錢那樣!) 而沒有員工去使用一個系統, 那它也沒有存在的必要性.

Sadly, as time goes employees would only see systems in place.  Systems would become the only thing employees interact with on a daily basis, and the processes can be embedded in systems without employees actually knowing (or remembering) that.  My encounter with the internal client is exactly the case where she thought by changing the system the problems would go away.  In fact, from her perspective she was absolutely right, but she failed to recognize this company does have Business Analysts looking after processes, and the management is very cautious when making system changes without enhancing the processes.

但是, 對一個員工來說, 真正每天在接觸的東西是那個系統, 而不是 BA (Business Analyst) 每天在紙上畫的流程圖.  他們或許會知道做完一件事後, 要按某一個按鈕而進行下一步, 但他們不知道按了按鈕後這個包裹會送到誰的手上 – 反正系統已經幫他們處理好了.

Relationship among the essentials

Relationship among the essentials

呼, 回到三段之前的事情 – 這個天兵內部客戶的意思, 就是希望我們直接從系統下手去改.  改完之後反正大家會自動的去 follow.  聽到她這樣一講, 我差點沒有從椅子上摔下來.  這種蠻橫的做法倒是從來沒有聽說過阿!  要做的話也要有對方的 manager 批準才行, 這可不是我改系統說改就改的大事.   她所想要做的事, 是會完全改變大家做事情的方式耶!

At the end, I asked her to document everything into a Word file.  Such process change will require synchronized moves from both the tools, the leaderships, and the processes.  At the end, I closed the ticket as what she described was not an issue at all.  I also advised her that I would speak to other owners of the same tool to see how they want to proceed.  The only thing I forgot to ask her was if she had a charge code, without capital (MONEY!) all change requests will just stay on the paper… (and that is another story for another day.)

遇到這種情況, 除了請她把要改的東西, 全部都放在 Word中, 也沒有其他的辦法可以去處理.  同時我也通知了內部問題回報小組, 把這個 “問題" 給解決掉 – 畢竟這是一個 CR (還包含了process improvement) 而不是一個問題 (bug.)  等到她把文件都打出來後, 我會去找這個系統的使用者負責人, 再跟他討論一下這該怎麼進行.  如果真的要進行的話, 下一步就是要問他們有沒有經費了.  而這又是完全不一樣的故事了…

廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s

%d 位部落客按了讚: