실리콘밸리에서 바라보는 Mobility 산업 -타다 서비스 혁신이라고 말할수 있는가  vs 아닌가?  

최근 타다는 불법이라는 ‘타다 금지법’  여객자동차 운수업법 개정안이 국회 본의회 통과시 1년 6개월 뒤에는 서비스를 할수 없다고 합니다.

 

법안 추진할 땐 언제고… 7년만에 ‘타다 금지’로 갈아탄 국토부

https://biz.chosun.com/site/data/html_dir/2019/12/08/2019120801366.html


현지? 소식

미국 우버(Uber)가 또 다른 혁신을 시작했다고 합니다. 2019년 9. 26일(현지 시각) 미국 캘리포니아주 샌프란시스코에서 기자간담회를 열고 개인 차량을 넘어 버스·지하철·기차 등 대중교통까지 모두 아우르는 ‘이동 서비스’를 제공한다고

우버 앱 하나면 공유형 이동 수단(Home -> Lime (공유자전거) 역까지 이동 -> 전철역 -> 사무실)을 모두 동원, 사람이 A에서 B지점까지 갈 수 있는 것이다. 서비스명은 ‘우버 트랜짓(transit·환승)’. 이날 미국 샌프란시스코와 프랑스 파리, 멕시코의 멕시코시티에서 서비스를 시작하고 연내 7개 도시를 추가하기로 했다. 우버는 “지난 5년간 준비해온 서비스”라며 “세계 모든 대륙(continent)의 주요 도시에 선보일 예정”이라고 밝혔다.


제가 바라보는 타다와 같은 (Riding share) 서비스;플랫폼)의 혁신성

  1.  플랫폼 기반의 즉시성 (수요자 – 공급자 매칭 ; 5분이내 서비스 제공)마냥,  기다리는게 아니라 모바일 앱으로 call 하면, 5분 이내 서비스 제공
    비오는날 금요일 저녁
    비오는날 금요일 저녁…택시 타기위해 나감…일반적으로 택시는 길거리에 나가서 손을 들어서 내가 간택 당하는 서비스입니다.   즉, 내가 필요할때 부르는 서비스… 그리고 비오는 금요일 저녁 야근을 마치고…힘든 한주를 마무리 할때 편하게 택시 뒷자리에 처진 몸을 접고 가는…서비스..이때 20분 기다린다면 이게 나한테 만족을 주는가?  최소한 5분내에 택시 서비스를 타야해요..서비스에 대한 비용(돈)을 지불하는 건데, 내가 원하는 서비스를 줘야하죠… 안그런가요?

    근데 택시는 대로로 나가서, 내 앞을 지나가기를 기다려야 하는데…  이곳 샌프란시스코에는 …. Uber 경우 모바일 앱으로 부르고, 안오면  lyft 나 다른 앱을 켜요…왜냐하면… 빨리 오는게 이 서비스의 핵심이니깐요…. 서울의 경우 타다 call 하고 안오면 다른 서비스를 부르면 되니…

    그래서 타다는 앱 배차를 많이 하고 고객에게 최대한  빠른시간내에 간택  ???  당하는 서비스를 해야 되요…  우버도 마찬가지…움직이는 화면 참고… (이게 첫번째 혁신..)

    Uber gif
    source : http://우버 (Uber), 도대체 무엇이 특별할까? – 우버 분석

    즉, 출퇴근 시간에, 특정 지역 강남 테헤란로에 비오는 금요일 저녁, 위와 같이 call 분석후 배차를 합니다. 퇴근시 수요가 몰리면 비용(1x -4x) 이 올라가고 차량기사는 자연히 더 높은 비용을 기꺼이 제공하는 장소로 움직입니다. 이때 수요-공급의 법칙에 따라 자연스럽게 비용이 낮아지죠..

    San francisco19787259_10209064005139538_9071142274472891857_o.jpg
    Techcrunch(예시) 행사후 점심시간                  점심시간에 Ride request 증가

    모바일 서비스를 통해 고객에게 현재 위치 도착할대 까지 걸리는 시간등을 공유합니다. 아래는 Uber case…

    uber ux
    이건 제가 그려본? Uber user experience…

    내가 원하는 서비스를 곧바로 제공해야되는 서비스에요,   왜냐하면 내가 돈내고 사용하는 서비스니깐…추가로…이 서비스를 안쓰면…. 잊혀지면 안되니깐. 계속  이벤트를 해요 다양한 push 메세지, 이메일을 통해…신규 런치 되거나, 불편한 점을 수정했다거나,

    정기적으로 고객에 새로운 친구초대, 생일, 월간 할인 서비스를  메일로 알려줍니다.
    일예로 월간  $15 짜리 쿠폰을 구매하면, 한달 동안 우버탈때 비용을  25% discount 한다던가, uber eat discount 쿠폰을 주는것 처럼….

    나를 잊지 말아 달라고…계속 당신에게 택시 서비스를 제공하고 Taxi 서비스를 주문(order)했을때 바로 대령 하겠다는….

  2.  비용의 합리성 &  결제의 편의성 

    보통택시는 거리/시간에 따라 비용이 결정되는 프로세스를 사용합니다. 즉 미터기를 통해, 차를 탄이후에 길이 막히거나 해서 시간이 더 걸리면 택시 미터기에서 비용이 계속 올라가요…그걸 보고 있는. 고객은…비용이 올라가는데 보이니… 심적 부담이 됩니다…하지만, Uber는 처음 서비스 이용시 요금이 결제되면…끝입니다.. 더이상 비용이 증가도지 않으니,  심적 부담 자체가  필요 없습니다. 더구나 카드를 등록해 놓으면, 현금/신용카드 자체를 꺼낼 일이 없는거죠. 또…모르는 길을 갈때는 택시 기사가 길 잘못들어 가는것도 걱정할 필요 없어요…네비게이션을 활용하여 가장 최적의 길을 제공하니깐…사람이 가질수 있는 Human error를 미연에 방지하고 …. 상호 네비게이션 시스템으로 움직인다는것을 상호 기분 나쁠필요도 없는걸 전제합니다.또, 혼자 타거나, 같이 타는 사람이 비용을 1/n 하거나 심지어 합승 메뉴, 그리고 대형차를 부르거나,

    심지어 이사짐 트럭도 부를수 있어요… 가격과 비용을 오로지 내가 선택하고 편리한걸 선택하거나.. 합승해서 저렴한 서비스를 이용하거나, 비싸지만 편리하고 안락한 서비스를 이용하거나….

    P1-BU040_UBER_J_20150615185716

  3. 서비스 연계성(확장성)
    ; Uber eats, 배달연게….Lime (전기 자건거 등)과 같은 last mile 서비스 연계 통해 지속해서 서비스 향상 (확장)

    고객에게 끊임없이 사용당하고, 경쟁에서 살아남기 위한 노력이 서비스의 개선과 확대인데 이게 정말 확장영역이. 정말….무궁무진해 지는게…

    2019092800075_0

    source : 미국 캘리포니아주 샌프란시스코에 있는 우버의 자율주행 연구개발(R&D)기지 ‘피어 70’. 우버가 자율주행 차량으로 개조한 볼보 SUV와 헬리콥터 서비스 ‘우버 엘리베이트’ 모형이 전시돼 있다. /샌프란시스코=박순찬 특파원

    여기에 Finance 도 연결해줍니다요…  Uber 기사? 들에게 월간 수익을 투명하게 제공하지요…어떤고객이 얼마나 지불했고, 그 걸 통해 내가 얼마를 벌었는지 투명하게 비용을 알수 있습니다.

    uber finance

    p.s  단순히 서비스 연계가,  수요 <-> 공급자를 연계하는 서비스인지라 택시 서비스 이외에 택배, 중고품매매(개인간 연결), 심지어 원하는 서비스를 얼마던지 어떤것이 던지 연계 가능
    uber transit.png

    가장 일반적인것이 Uber eats 음식 배달입니다. 내가 원하는 음식을 배달하고…
    (수요자 -공급자 연계)


    06b

    장애를 가진분도 Uber 드라이버로 활동합니다.
    귀가 불편한 분들도 우버 드라이버로 활동할수 있고…

    이에 대해 승객에게 미리 공지합니다. 



    취약계층 (ex 노인…)에 독감 서비스 제공… 샌프란시스코시에서는 독감 유행시 백신을 간호사가 취약계층 list 를 가지고  하루에 (ex…10명) 가능한 인원에 대한에 약품을 우버 서비스로  넣고, 독감 주사 서비스 제공 합니다.

    노인들이 병원에 와서 독감주사 맞는게 아니라, 직접 서비스를 제공합니다. 이렇게 어떤 서비스던지 …  수요-공급자 확장이 가능한 서비스가 됩니다.

    결론 : 마무리…

    우리가 혁신이다 vs 아니다를 논의하고 결론을 내기 보다는

    고객이 선택해야 한다는 이야기를 하고 싶다. 왜냐하면 아무리 IT 혹은 Mobile 기술로 혁신을 한다 하더라도 고객이 사용하지 않고, 더이상 관심이 없다면

    그것은 실패?한 혁신이 아닐까?



    고객에게 충분한 가치, 

    1. 비용을 줄여주거나 (Cost reduce…)
    2. 시간을 줄여주거나 (Time save…)
    3. 재미있게 해주거나 (Have fun…)



    위의 3가지를 통해…나한테 확실한 가치를 준다면… 그것이 많은 사람들에게 도움이 되었다면 혁신이라고 생각한다.

    고객이 이해하고, 자주 사용하게 만들어 그들에게 가치를 주어, 실생활에 일반적으로 사용되는 서비스라면 그것이 혁신이 아니고 무엇인가?

     

계속 읽기 “실리콘밸리에서 바라보는 Mobility 산업 -타다 서비스 혁신이라고 말할수 있는가  vs 아닌가?  “

How To Use Hazel To Save Time, Automate Your life hack & Tasks

When we do an internal poll  our team or ask our team for their favorite macOS apps to be productive, there is one that is always near the top of the list: Hazel.

It is one of our key applications to free up time, eliminate annoying manual tasks, and to make the macOS experience better.

What Is Hazel?

Now that we’ve hyped it up, the natural question is: “what the heck is Hazel?”

Noodlesoft, the creators of Hazel, describe it as “Automated Organization for Your Mac”, and that is a great tagline. Here’s what they have to say about it:

Hazel watches whatever folders you tell it to, automatically organizing your files according to the rules you create. Have Hazel move files around based on name, date, type, what site it came from and much more. Automatically sort your movies or file your bills. Keep your files off the desktop and put them where they belong.

Essentially, you tell Hazel to watch a folder (or multiple folders), set some rules you want Hazel to watch for, and when something happens in that folder that matches one of your rules, take some action that you define.

To use the app correctly, you just have to understand very basic if-then logic. In other words:

If X-condition(s) are true, then do Y-action(s).

For example, you can setup rules (as Hazel calls them) like the following:

  • If a file is in the Downloads folder and is bigger than 1GB and hasn’t been opened in 2 weeks, then move it to the trash folder.
  • If the file name contains “invoice”, then color it green and make a copy in the Finance folder.
  • If a file on the Desktop hasn’t been opened in the last 24 hours, move it to a “Desktop To Review” folder.

There are so many ways you setup rules. They can be very simple, or you can have multiple conditions and multiple actions so you can really make it as complex as you want it to be.

You can even have Hazel run shell scripts or Applescripts, so what you can do with your files is almost unlimited. If you don’t know what any of that means, not to worry — no programming is required with Hazel. Anyone can learn it.

What About Hazel For Windows?

Hazel is a Mac application, and there isn’t a Windows version. If you use Windows, there are alternatives. DropIt is a popular open source tool that can do much (but not all) of what Hazel can do. You should be able to do many of the tasks outlined here on Windows with DropIt.

Why Automation Matters

Why use a tool like Hazel at all? Here is a  reader that is by no means unusual:

I’ve been trying Hazel for the past few days with the trial, and I just don’t get it. It seems that it’s for people who don’t know what’s going on with their file system. I don’t need something to monitor my download folder and move things to other folders automatically – I move things to where they should go myself. Sorry, I just don’t get it – Hazel causes more problems than it solves IMO…

Many people who try automation tools like Hazel and TextExpander don’t “get it” at first. How hard is it to rename, move, or manipulate a file? How hard is it to type?

At Asian Efficiency, we live by something called the “3 Times Rule.” If something bothers you 3 times, find and implement a permanent solution for it.

This can apply to things that don’t bother you too. If you find yourself doing repetitive tasks manually that could be automated or outsourced, why not find a solution to take it off your plate? Awesome Asian Efficiency reader Scott says it well:

Look for areas in your workflow where you find yourself doing repetitive tasks with files, then see if there is a way to have Hazel help automate that for you so that you can get on with bigger and greater things. It’s not just about maintaining your file system, but also about automating tasks to free up your time and attention.

The value of freeing up time and attention for things that actually matter can’t be overstated.

Hazel Quick Wins

Now that we’ve made the case for Hazel as a tool, let’s look at some quick wins that will get you started.

When you install Hazel, it automatically adds your Downloads folder and installs some sample rules. It’s highly recommended that you poke through those rules and get a feel for how a Hazel rule is set up before starting with your live important files.

If you ever want to get to your Hazel rules, click on the broom icon in your menu bar and choose Open Hazel….

Open Hazel

The key thing to know about the Hazel interface is that it is split into two sections: Folders and Rules.

 

The Folders section on the left is the list of the folders that you want Hazel to watch. To add a folder, drag it into that window from the Finder or click the + button to add it.

The Rules section on the right lists the rules you have set up for the selected folder. Hit the + button to add a new rule or double-click on an existing rule to view/edit it.

Let’s start with a few simple rules.

Clear Off Your Desktop

The Desktop can be a convenient place to temporarily store files, but it can quickly become a cluttered mess. We’re going to create a rule that moves any file that hasn’t been opened in one day to a folder called “Desktop To Review”.

If you’d like, you can have Hazel delete the untouched files, but we’ll be safe and sweep them to a folder to look through later.

hazel-2-add-desktop.png

First we’ll (1) add the Desktop folder by hitting the + button in the Folders pane or dragging it in. Then, we’ll (2) hit the + button in the Rules pane to add a new rule.

hazel-3-sweep-desktop

Next, we’ll tell Hazel that we want to:

  • Watch for any files that were created more than a day ago
  • Ignore folders (we only want to look at files)

We also tell Hazel we want it to:

  • Move any of these files to the “Desktop To Review” folder

One we hit OK to save it, here it is in action:

Hazel sweep

Automatically move and clean up old screenshots

macOS has a handy built-in screenshot feature (if you haven’t tried it yet, hit ⌘-Shift-4, and select part of the screen).

By default, these screenshots they get stored on your desktop. You can delete or move them yourself, but why not let Hazel do it for you so you don’t need to think about it?

If you’d like, Hazel can delete them for you, but I like holding them in a folder (~/Pictures/Screenshots) for a while just in case.

Here’s a rule that will move screenshots older than an hour:

hazel-5-screenshots

This is great, but now you’ll have a ton of screenshot images in ~/Pictures/Screenshots.

Not a problem. You can make a second rule for Hazel to delete very old screenshots. If you collect all screenshots in a separate folder but never empty it, you’re wasting a lot of space. So make sure you make a new rule for your screenshot folder that deletes files older than, say, 4 weeks.

Add the Screenshots folder to Hazel by pressing on the plus sign in the folders pane (or drag the Screenshots folder in), then add this rule:

hazel-6-remove-old-screenshots

Clean Up Your Downloads Folder

Over time your Downloads folder can become a mess and can take up a lot of space. Here are some strategies for taming it.

Remove DMG files

When you download and install a Mac app outside of the App Store, more often than not you will download a DMG file.

Once you install the application, you probably don’t need that DMG file anymore. If you’d like, you can use Hazel to sweep them away to another folder or to an external hard drive. In our case, we’re going to create a rule that deletes them after a day.

hazel-7-remove-dmg

Sweep Old Files

Similar to what we did with the Desktop, you can keep your Downloads folder clean by moving old files to another folder for further review, or (if you’re brave) you can delete them.

Follow the instructions for “Clear Off Your Desktop” above, but create the rule for your Downloads folder.

Sort Your Downloads

If you like things to be nice and organized, Hazel can automatically sort files into subfolders for you by criteria like date, extension, or type. Here’s how to keep your downloads folder sorted by type for files older than 1 day.

hazel-8-sort-subfolder.png

To select kind, click into the with pattern box. You’ll see you have a number of different options. The date ones can be particularly handy.

hazel-9-sort-type.png

Here’s the rule in action:

Hazel sort into subfolders

Highlight Apps You Never Use

How often have you tested out an application on your Mac and then never used it again? This rule will use the handy Set color label feature to highlight the apps we may want to get rid of.

If there’s any application in the /Applications folder that hasn’t been opened in a year, it will turn it purple.

hazel-11-old-apps.png

If you then sort your /Applications folder by Tag, you can quickly see which ones should be reviewed. It looks like I have a bit of cleaning to do.

hazel-13-clear-trash

Clean Out Your Trash

Many of us are not the most diligent at cleaning out the Trash in macOS. This is great if you need a file later, but not so great if you want to save hard drive space.

Assuming you have an effective backup system in place, you can have Hazel monitor your Trash and clean it out periodically or when it gets to a certain size. Let’s have Hazel clear out the Trash every two weeks.

This time we won’t be creating a rule, but adjusting a setting. Go to Hazel and go to the Trash tab. Check the Delete files sitting in the Trash for more than checkbox, and set the time period you want to keep files for.

 

Just remember, once files are gone from the Trash, they’re gone. Be careful with this setting.

Move Saved Email Attachments

Hazel can be a handy tool for archiving files received via email.

If you want to save your important attachments outside of your email program, you can save them to a central folder and then set up rules for Hazel to move your attachments for you.

We wrote about how to handle email attachments, and that article gives an example for doing this.

Hazel Power Moves

We’ve gone through some quick wins you can achieve with Hazel, but it’s time to take things to the next level. Here are some more technical examples of what you can do with Hazel.

Automatically Move Paperless Documents

Hazel is an absolutely killer tool for processing your paperless documents.

We recommend creating a central folder to act as an inbox, and have everything you can and download go to that folder.

Then you can use Hazel to watch that folder and automatically rename and move your PDFs based on the rule you set up.

You can have it move and rename based on the name of the document, but you can even have it look inside the PDF at the contents and move and rename based on text inside the document. It can even grab the date out of the PDF and use that in your file name (!).

We’ve written about using Hazel with your paperless documents before, so check out that detailed tutorial.

That workflow is good, but if you want to make use of the date in the PDF, you’ll need to set a criteria for Contents and then contain match. Choose Custom Date.

We’re creating a token here, and call it stmt date. Use Month, Day and Year to build the pattern that Hazel should look for, but the key is that the pattern must match the date format in your PDF.

For example, if you had a bill with a date that looks like this:

 

Bill data  July 08. 2019

 

Then your Hazel token would need to look like this:

 

Things like spaces, slashes, and commas matter. This can be a pain to get right, but once you do it is extremely powerful.

Once you have your token saved, you can use it in the Rename step. Going off the example from our paperless article, here is what the new action section would look like:

hazel-21-custom-date-rule.png

Now it will grab the date from the bill, use that date in the name, and rename it with our naming convention and move it. This takes so much of the heavy lifting out of going paperless.

Rename downloaded files

If you download statements, reports, or other files, they are probably not named in the format you want. Fortunately, Hazel can help.

For example, my bank has a report where the downloaded file is named eStatementyyyy-mm-dd.pdf, where yyyy-mm-dd, of course, the date of the report.

I want the file to be named yyyy-mm-dd-XYZ Bank.pdf instead. In plain English, what I want to do is:

Get rid of everything before the date, use the date, and then tack -XYZ Bank after the name.

No problem. There are many ways to do this, but let’s do it the name-manipulation way and do it in a way that we are being extra-safe that it will grab the right file.

Create a new rule and for the criteria, set it to Name and matches. Click into the white matches box and you will see a popup.

hazel-14-name-estatement.png

In this box we will be telling Hazel to do two things:

  1. Look for a file named with a certain pattern.
  2. Grab part of that file name and put it into a token so we can use it later.

First, we want to tell Hazel to look for a name starting with eStatement. Click on the dot beside Custom text. It will open up yet another popup, and this time we want to give our token a name (this one doesn’t really matter) and in the Type text field, I have eStatement. This has to exactly match what we’re looking for in the file.

hazel-15-name-matches.png

Hit Done.

Next we want to create another token for the part of the filename that contains the date. If we wanted to manipulate that date we could use the Custom Date type, but in this case let’s keep it simple and just use Custom text again. Click on the blue dot beside Custom text.

This time we are going to keep it low tech. We want to tell Hazel that we want it to look for the part of a file that has a number, then a hyphen, then another number, then another hyphen, then another number.

Hazel date token

I gave it a name “stmt date”. Hit Done.

Here’s what my Matches popup looks like:

Hazel tokens

Hit Done.

Now that we have our matching done, we’ll tell Hazel to rename the file. For the action, choose Rename and get rid of the part of the filename that says name. We don’t care about the exiting name.

Instead, click on the “stmt date” token we created earlier and then type -XYZ Bank after it. Here’s what my rename pattern window looks like:

Hazel rename pattern

Now when I save the rule, Hazel will look for anything named eStatementyyyy-mm-dd and rename it to yyyy-mm-dd-XYZ Bank.

As I mentioned, there are other ways to do this (especially with PDFs), but I wanted to show you the power of tokens and how you can use them to take information from one place and use it in another.

Create new task in OmniFocus when a PDF bill arrives

A common worry when going paperless is making sure bills are paid on time — how can we remember to pay our bills if we don’t see them sitting there?

The Asian Efficient way is to set up auto-pay, but for some bills you can’t or choose not to.

A solution is to set up Hazel to watch a folder for your bills, and then have it create a task in OmniFocus to remind you to pay it.

This can be done with an AppleScript, and here is how to create an OmniFocus hotspot to do just that. There’s even a sample rule included.

The Preview Button Is Your Best Friend

When you are building complex rules it can be helpful to test as you go along. Thankfully, Hazel has a Preview button to help.

Let’s go back to our file-renaming rule from earlier. We’re going to tell Hazel to look at a document that we think should match the rule. We do that by hitting the Preview button.

Hazel preview button

Once you hit the button, choose the document you want Hazel to watch and hit Open.

Right away you’ll see a green checkmark beside each step that the sample document matches.

Hazel preview button

If a step doesn’t match, there will be a red x.

Hazel preview button

You can double-click on one of the red x’s and it will tell you what part doesn’t match and what it sees instead. You then have something to investigate.

Hazel preview button

Copy Tax Receipts

When you’re downloading a receipt (or you captured it with your phone and uploaded it to Dropbox), you can have Hazel watch a folder, watch for a part of a name, and then move and rename it. This can be handy for tax receipts.

When I am saving a document, I might want it to go to my normal filing system, but I might also want it to go to a Dropbox folder that I share with my bookkeeper. I do that by having a Hazel rule look for anything that has “-taxbd” at the end.

Hazel tax receipts

By now this should be pretty standard Hazel for you. Look for a file that’s name ends with some text, and copy it to a folder. The key is that little icon you see in the name attribute in the Rename with pattern box.

When you (1) click on one of the attributes, you have some options. In this case, I (2) chose Replace text.

Hazel replace text

In this case, I’m telling Hazel to replace -taxbd in the file name with blank text, effectively chopping it off. This way I get the benefits of using this text to tell Hazel to do something without it cluttering up my file names.

Automatically Resize Images

If you are constantly having to resize images to a certain width, you can set up a folder and have Hazel watch it and do the resizing for you.

Now, Hazel itself can’t resize images, but this example shows how the power of Hazel is almost unlimited. We’re going to have it run a shell script and do the resizing for us.

I created a “To 800” folder, and created a Hazel rule that looks for images. I like to put in a safeguard and have it only run if the Pixel Width is greater than 800. Pixel Width isn’t one of the default options. First choose Other… and then scroll down or search. You’ll find it.

Hazel image size

Next it’s time to do a tiny bit of scripting. In the action section, choose Run shell script. Then click on Edit script.

Now you have a script window opens up. Paste or type in this command:

sips -Z 800 "$1"

sips is a command built into macOS and $1 is what Hazel will use to substitute in the file it is working for.

Hazel shell script

Now Hazel will watch for any image you drop into To 800, check if it is greater than 800, and if so run sips to resize it.

(Hat tip to Jacob Salmela for this tip.)

Automatically Import To Evernote

For some reason, the Windows version of Evernote comes with import folder functionality, but Evernote for Mac does not. Never fear though, as a Hazel expert, you can make your own.

We’ll create a To Evernote folder and create a Hazel rule that uses AppleScript to add to Evernote.

Here is, at a high level, our rule:

Hazel move Evernote

Now let’s click on Edit script to see the magic.

Hazel Evernote AppleScript

It’s pretty simple. Here’s the AppleScript code to paste in:

tell application "Evernote"
    activate
    create note from file theFile
end tell

theFile is Hazel’s placeholder for the file it is processing.

If you have problems with it, sometimes you need to change the first line to:

tell application id "com.evernote.evernote"

You can do a lot more with this, like automatically adding tags or moving it to specific notebooks. Here is Evernote’s AppleScript reference if you want to get really geeky.

Only move non-secure PDFs to Evernote

Sometimes we may want to copy documents or other files to Evernote, but don’t feel comfortable storing sensitive information there. Here is one way you could protect yourself:

Hazel move Evernote

This is the same as the last rule, and uses the same AppleScript. But now it has a condition where it will only copy the file to Evernote if it does not contain one of the account numbers listed. You can list social security numbers, credit card numbers, account numbers, or any other sensitive text you wouldn’t want uploaded to Evernote.

What Will You Do With Hazel?

Believe it or not, we are over 3,500 words and we have barely scratched the surface of what Hazel can do.

If all these examples are overwhelming, just pick one to implement, play around, and get to know the tools. You can implement the other ones later if they would help you.

Do you have any killer Hazel workflows you’d like to share? Is there anything you wish you knew how to automate but don’t know how? Leave a message in the comments below.

실리콘밸리 우리 팀이 분기마다 하는 질문들…

 

분기별 우리에게 하는 질문들..

64320898_2236868943094477_2064160792831328256_o.jpg

실리콘밸리에서  추구하는  가치…들..

  • 탁월함 : 우리가 그리고 우리팀이 왜 이 업무를 하고 있는가? 왜 우리여야 하는가?

우리는 최고의 팀이다 -> 팀원간의 신뢰로..
서로를 보며 머리속으로 그리고 현실에서도 자부심을 느낄수 있어야 함. 아 우리팀은 이런걸 해내는 구나…

  • 공유정신 :

1) 우리는 현재 자신이 하는일을 공유하고,
2) 잘하기 위해서 어떤 노력을 해오고 있으며
3) 동료(팀원)이 더 잘할수 있는 일이 있다면, 주저 없이 제안하고, 도와주는 행동을
* 지난번에 이렇게 해봤는데… 더 빨리 잘할수 있었다는 이야기와 경험했던 내용을 공유

– 빠른 실행과 배움 : 빠른 실행과 배움이 더 큰 성장의 기회를 준다

1. 우리가 지금하는 일이 무엇이고, 이를 위해 필요하거나 중요한 일을 빠르게 찾아 제안하고 실행했는가?

컨셉이나 아이디어를 끊임없이 논의 하고 계획을 이야기 하는게 아니라
단순 아이디어가 아니라 당장 실행이 가능한가? 어떻게 하면 가능하게 만드는가? 실제 업무(task) 로 진행

  • 안되는 이유가 아닌 어떻게 할 수 있는지 그 이유를 찾자… 어짜피 한정된 우리팀에서 하는 일인데 그 일(task)이 의미있고, 더 중요한 일에 집중하고 실행해야 한다.

계획 세우기와 말잘하기는 누구나 할 수 있다. 하지만 중요하고 필요한 일을 해낼 방법을 찾고 실행하는 건 다른일이다.

2. 결론(ex…본론)부터 이야기하고  (사용자 관점에서) 더 나은 이유를 간결하고 명확하게 말하는가?
이 일이 왜 중요하고 그래서 어떻게 하는지 본론부터 간결하고 명확하게 말해야 한다.
결과물에 대해 간단히 왜, 어떻게, 했는지 이야기 하고 의견을 귀담아 듣고, 강력하게 의견을 낸다하더라도 결정은 팀장, 리더가 하는데 책임과 의식을 하고 있다는 공감을 가질수 있어야 한다.

3. 내가 참여하는 프로젝트와 일에 대해 기록 & 공유를 잘하는가?
진행사항을 내가 이해하고 상대방이 이해하고 이를 통해 서로가 판단과 결정을 할수 있어야 한다.

자신이 무슨일을 하고 있고, 상대방이 내가 무슨일을 하는지 알수 없다는건 필요없는 일을 하는가 아닐까 생각해야 한다.

내가 하는 일이 행방에 의문이 들지 않아야 한다. 이 사람이 이시간에 왜 저기 있지 하는 행동이 계속되면  신뢰가 저해되고, 팀워크가 약해진다.

 

 * 이슈가 생기거나, 이슈가 예상될 때 미리 공유를…통해

이슈를 공유해서 대응 할수 있도록 준비해야 한다.
이슈를 대응할수 있는 시간 방법을 고민하거나, 다음에 또 이런 이슈(상황)이 발생하지 않도록 잘못된 관행을 고치는…
혹은 지난번 대응했던 경험을 공유하는게 필요하다… 이에 대해… 전팀장에게 공유하고… 문제를 이렇게 대응했다는 경험을 상호이야기 할것…

 

 

자신의 할일(하는 업무) 구조화 하기

1_uemkatyd5p5lbdqk0_qolq

“내용을 구조화(서술적인 메모)하고 6p 이내로 정리하면 명확한 방향(생각)을 가질 수 있다.” — 제프 베조스

Most people groan when they hear “product spec”. They think of weeks spent writing docs that no one reads. How can one be agile, and pumping out code like a rockstar, if one is encumbered with documentation? After having spent over a decade building software products used by millions of people, I think this view is misguided. In my experience:

“많은 사람들이 제품 스펙”이라는 단어를 들으면 대부분은 인상을 찌푸린다. 그들은 아무도 읽지 않을 문서를 작성하는 데 수주간의 시간을 생각하고 허비 하는데… 문서 작성까지 해야 한다면 누가 과연 민첩하게 Rockstar록스타 같은 멋진 코드를 쏟아낼 수 있겠는가? 수백만의 사람들이 사용하는 소프트웨어 제품(서비스)를 만들며 10년 넘는 시간을 보낸 후, 난 기존의 이런 생각이 잘못되었다는 것을 깨달았다.

Effective product specs are a critical part of building great software. They force critical thinking up front, scale communication, and raise accountability — all leading to higher quality, lower schedule risk, and less wasted time.

효과적인 제품 스펙(문서)는 훌륭한 소프트웨어를 만드는 과정에서 결정적인 역할을 한다. 그러한 문서는, 개발 초기부터 비판적 사고를 하게끔 하고, 커뮤니케이션을 효율화하며 , 책임 소재를 분명히 함으로써 높은 품질, 일정 리스크 축소, 시간 낭비 최소화에 기여한다.

In this post I’ll walk through an example, and share some general advice. This will be most useful for product managers in mid-to-large companies (100+ people).

사례와 함께 관련된 일반적인 조언을 적어놓았다. 이 포스팅은 100명 정도 되는 중소/대 기업의 프로덕트 매니저에게 가장 도움이 될 것이다.

1st an Example

Suppose you work at:

A company that runs a vacation booking site (like Hotels.com or AirBnb.com but smaller). Your checkout conversion is low, and one idea the team wants to try this quarter is live chat during checkout.

사례 : 여행 예약 사이트를 운영하는 회사에 다니고 있다. hotels.com이나 airbnb.com과 유사하지만, 더 작다고 보면 된다. 결제 전환율이 낮은 상태이며, 이를 개선하기 위해서 이번 분기에 당신의 팀에서는 결제 페이지 라이브 채팅 도입을 시도해보기로 했다.

Your story & roadmap says:

Try adding live chat to checkout to increase conversion.
Checkout conversion is only 18%, whereas the industry standard is 30%. Let’s test showing customers live chat during checkout to see if we can improve it. Customer ops has agreed to lend us 1 head for a month.

전환율 제고를 위한 결제 페이지 라이브 채팅 시범적 도입
현재 결제 전환율은 18%에 불과하다 (동종업계 평균은 30%). 이 수치 개선을 위해 결제 페이지에서 라이브 채팅 화면을 고객에게 노출해보기로 했다. 운영팀 담당자는 이 업무를 전담할 수 있는 담당자 1명을 배치 했다.

And you execute without a spec:

Let’s say you decide that action is 1st priority, and jump into it:

  1. You chat about this with your team in the sprint planning meeting.
  2. Then you simply pick a reasonable chat service (like Slack).
  3. Update the ticket to ask a developer to slap in some Javascript.
And have a meeting with Support to make sure they’re all set.
당신이 스펙 문서 없이 실행한다면….
이 업무가 최우선 순위라고 생각해서 바로 시작한다고 가정해보자.
  1. 스프린트 기획 미팅에서 이 이슈에 관련해 팀에게 얘기를 꺼낸다.
  2. 그리고, 바로 적당한 서비스 제공자 (Slack 같은)를 고른다.
  3. 개발자에게 자바스크립트 코드를 좀 넣어달라고 티켓 내용을 업데이트한다.
  4. 운영 준비상태를 확인하기 위해 고객 지원팀과 미팅을 가진다.

Boom! Why do we need all that spec fuss anyways? Well if you’re a small startup, you don’t — because there are fewer moving parts, and fewer people involved. But if you’re in a larger org, or have a more mature/complex product, the details will appear at some point, and they’ll cost more to address later. For instance:

짠! 이렇게 간단한 일에 도대체 스펙 문서 나부랭이는 왜 필요한 거지? 당신이 작은 스타트업에서 일하고 있는 것이라면 꼭 필요한 건 아니다. 프로덕트에서 바뀌고 있는 부분도 적고, 관련된 사람 수도 적으니까. 하지만 당신이 더 큰 조직에서 일하고 있거나, 더 복잡한 프로덕트를 갖고 있다면 어떤 세부사항은 나중에 나타날지도 모르고, 그런 것들을 늦은 시점에 결정하면 더 큰 비용을 불러오기 마련이다

  • A dev marks the ticket as done, but on giving it a spin, you realize it doesn’t work on mobile. →Doh! You forgot to mention that mobile is key.
  • The customer ops manager wants to have a lengthy vendor review to pick the right chat tool. → Schedule a meeting to explain this is only a test.
  • An hour after launch, support says they are getting live chat requests in Spanish. →Yikes! Do an emergency release to limit to English only.
  • A designer spends days crafting the perfect slide-in animation to display live chat. →UX gold-plating. Did you set expectations that this is a test?
  • After a week of testing, BI realizes they can’t build the report you need because the right metrics weren’t logged. →Epic fail. Restart the test.

Without a spec, you might not have a disaster on your hands (this is a relatively simple project), but you will likely waste time and opportunity.

어떤 상황이 올 수 있는지를 본다면,

  • 개발자가 ticket을 ‘완료’ 상태로 변경했다. 시험 삼아 한번 실행해보자마자 당신은 이 기능이 모바일에서 작동하지 않는 것을 발견했다. →헉! 모바일이 핵심이란 것을 깜빡하고 말하지 않았다.
  • 운영팀 담당자가 ‘적절한 채팅 툴을 골랐는가’에 관련해서 심각한 미팅을 요청했다. →윽.. 이건 테스트일 뿐이라는 것을 설명하기 위한 미팅을 잡는다.
  • 서비스 개시 1시간 후, 지원 담당자가 스페인어로 된 채팅 요청을 계속 받고 있다고 말한다. → 이크! 지원 언어를 영어로 한정하기 위한 긴급 패치를 진행한다.
  • 디자이너가 완벽한 슬라이드인 애니메이션으로 라이브 채팅 화면을 불러오기 위해 며칠씩 공을 들이고 있다. →  이건 테스트일 뿐이라고 기대수준을 맞췄던가?
  • 테스트 시작 1주일 후, BI 담당자가 적합한 지표가 기록되고 있지 않기 때문에 당신에게 필요한 레포트를 만들 수 없다고 말한다. → Epic fail. 테스트를 다시 시작한다.

스펙 문서가 없다고 이런 재앙이 꼭 닥치리라는 법은 없다(이건 비교적 작은 프로젝트이니까). 그러나 아마 당신은 시간을 낭비하거나, 중요한 부분을 놓칠수 있다.

Now suppose that you wrote a spec:

To illustrate, I’ve written up what early notes might look like, as well as a completed example spec — so you can see what the evolution might look like. Take a few minutes to go and read these before coming back.

  • Read example notes. (2 min read)
    This is a bulleted brain dump of what you know, and questions you want to answer. Write this up front by yourself. It should take about an hour. This is your straw-man to vet with your team and stakeholders.

그래서, 당신은 스펙 문서를 쓰기로 했다.

설명을 위해 초기 단계의 노트와 완성된 단계의 스펙 문서 예시를 제공한다. 예시를 읽고 시작하길 권장한다.

  • 초기 단계 노트 예시(2분 분량)
    지금 알고 있는 정보와 답하고 싶은 질문들을 불릿 포인트로 적은 것이다. 혼자서 먼저 적어보자(예상 소요시간: 1 시간). 이 문서가 당신이 팀 구성원과 다른 관계자들과 논의를 진행하기 위한 기본 자료가 될 것이다.

This is an example early draft product spec/notes, written as part of this post.

Problem:

  • Conversion sucks. 18% but should be able to do 30% (need source).
  • What else have we tried here, and why is this worth trying? Need to look up our past support case summary and survey results.

Goals

  • Prove live chat is worth it. Be ok with scrapping if the results stink.
  • Ideally have an answer by start of Dec so we can ask for support resources in Q1.

Chat vendor?

  • Look at the top few and pick one: slack, etc.
  • What does the UX look like and how much customization is needed and possible?
  • We need cust ops to manage setting their hours, and agents, without a code push!
  • What is the integration cost? Just drop in a Javascript snippet, or…?
  • How much reporting do we get from the tool vs. what do we need to build in house?
  • Can we pass in some variables for our own custom reporting? Like user_id?
  • Can we ignore integrating with our support ticketing ZenDesk instance right now?

Success criteria:

  • Need to model out cost of one chat person, vs. how many chats they can do vs. how many new conversions those chats can bring.
  • If we can’t make this work in Excel, no point in trying the test.
  • Must get early feedback from cust ops manager and finance.

Running the test

  • How much traffic to send? It’s a function of: number of people who click to chat, average time per chat, number of simultaneous chats we’ll allow, wait time, etc.
  • We can model this, but it’s not worth it given we have no data and lots of assumptions.
  • Instead, let’s roll with a guess, like 20% of traffic, and slowly dial up a knob till we know.
  • How many days do we need to run this? Do we need to worry about traffic seasonality?

What reports do we need?

  • I want to know conversion, revenue, and total orders in the test and control.
  • Also how many people in the test actually engaged (initiated a chat).

Anything else?

  • What about international? I’d say skip it for now.
  • Mobile? Fer sure. 30% are checking out on their phones.
  • Page load times? Make sure this chat widget doesn’t slow down the page!

Example of notes you might take to get the process started.

  • Read the example spec. (6 mins)
    You’ll only feel confident writing this after vetting your assumptions and ideas by your team (in small focused meetings, over coffee, or on a foosball break). Once that’s done, this spec should take 1–3 hours.
  • 스펙 문서 예시 (6분 분량)
    초기 노트로 당신의 가정과 아이디어를 팀 구성과 확인한 다음에 좀더 확신을 가지고 작성에 들어갈 수 있다(예상 소요시간: 1–3 시간).

This is an example product spec, written as part of this . Some notes:

  • Commentary will appear with this light blue background throughout the doc.
  • Read the doc once through while ignoring the blue bits, then go back and reread.
  • Links don’t go anywhere. They exist to illustrate the need to do and show related work.

Live chat on checkout

This project aims to increase conversion by introducing live chat on our checkout page. It is a 30-day experiment, after which we’ll keep it alive or kill it ( chat?).

Describe the project in 2 lines or less. By “line” I mean the default reading width of your medium (e.g., Google Docs, wiki, text file) on a desktop client. Sticking to limits is critical for readability.

Overview

Problem

  1. Checkout conversion is too low: only 18% of users who click on “Book” checkout. Comparable funnels for hotel booking sites achieve ~30% (source). We are missing out!
  2. No clear dropout reason: prior support tickets and survey results show a long tail of possible issues (questions on amenities, fees, checkout time), no clear categories.
  3. Adding help content didn’t do much: last quarter we A/B tested content and UI to better point to help content and booking info. This nudged conversion by 1.5% points.

I highly recommend bullets for readability. Use bold words to quickly convey the gist of each point, and limit bullets to 2-3 lines. I prefer numbered lists so one can refer to a point verbally.

Goals

  1. Test if live chat can profitably increase conversion: we need to add 90+ orders/day just to break even on our live chat support cost. Unclear if we can do it. This is a test!
  2. Keep the test cheap: avoid all gold-plating, this will come in Q1 if our test succeeds.
  3. Get final answer by Dec 1: we have 8 weeks before Q1 resource planning starts.

Make sure one can point to a goal and easily answer “did we hit it?”. Make clear promises.

Out of Scope

  1. Major UX changes: we will only add a visible chat button, no other UX changes.
  2. Finalizing a chat vendor: we’ll use slack for now, and review if the test works.
  3. International and non-English: only US/English users to keep our test simple.

This is your chance to eliminate bad assumptions and correctly set expectations.

People and Roles

  1. Heather (cust ops manager): sign off on our support resourcing assumptions.
  2. Kim (cust ops rep): man the queue, and summarize learnings once a week.
  3. lyn (dev): build and qa. Also configure Slack, and show us all how you did it.
  4. lee (finance): review my profitability assumptions for our test, and down the road.
  5. Joshua (design): very light review of the changes we’ll make, no major design requests.
  6. Viky (admin & dasbboard): make sure we can get the reporting we need in time for the test.

Help everyone know who is involved, and what is expected of them. Only include people who have authority to veto/approve decisions, or people who will execute on the plan.

Context

Use this section to provide supporting evidence for your problem and proposal. Add whatever you need here, e.g.: use-cases, personas, metrics, competitors’ solutions, survey results, etc.

Use Cases

  1. Users want to:
    1. Get help within 2 mins: unsure if this is achievable, but let’s aim here for now.
    2. On mobile or desktop: 28% of checkouts are on the phone, so this is critical.
  2. Customer Ops wants to:
    • . Be in the queue: via a desktop/web client, mobile is not needed.
  1. Add/reduce agents: on their own without having to consult the dev team.
  2. Set working hours: control when the live chat button is visible on the site.
  3. View user info: we must pass in the user-id so they can look up the current user.
  4. Tag chats: after a chat is done, put unstructured text into a comments field.

Assumptions

  1. Need +90 orders/day to break even with 1 support head: based on cost per head, and lifetime value of a checkout. See spreadsheet for details.
  2. Send 20% of checkout traffic per support head: based on some assumptions on wait times, chat lengths, and number of simultaneous chats. We don’t have any data to make a good guess, so let’s pick this and allow our system to ramp traffic up/down quickly.
  3. Checkout conversion should go from 18% to 20%: total conversion won’t increase much for us to be successful. See our funnel report

Proposal

Describe your proposal in the most natural way you can. Break it up into sections, and give it a clear narrative flow. Depending on the project, you may also add: wireframes, user flow diagrams, form inputs/validations, data models… all the specifics needed to execute the plan.

Live Chat Vendor

I picked Slack, they meet our stated use-cases and are cheap ($60/month). Note: we’ll do a proper vendor selection if this works. I created a paid account, credentials in our pw tool.

User Experience

View the Slack docs to get an idea of how their chat pops up. Based on that:

  1. Button: label it “Chat Now” and put it near our primary on the detail page.
  2. Behavior: on click, show the agent’s name, and “How can we help you today?”.
  3. All checkout pages: it should persist across all 3 steps of checkout.
  4. No auto-popup: we may try this later, but let’s keep it low key for now.

Chat Variables

  1. What is it: when we embed the vendor’s javascript, we can pass on additional variables that the support person can see, and will also get logged in reporting.
  2. Let’s send: user_id, user_email, user_agent, booking_id, booking_order_value.

Knobs for Running the Test

We will only show this to some checkout page traffic. Here’s what we need to make that work:

  1. Only show to X% users: we must be able to control X without a redeploy, but it’s ok if CS has to file a ticket to dev to do this manually (e.g. if it’s in our DB/Redius).
  2. Persist which users see it: if a user sees live chat once, they should continue to see it on any given day that we’re running the test. Either cookie them, or base it on their user_id (e.g., show it if user id modulo 100 <= X).
  3. Ramp up plan: on day 1, we’ll only have this be at 5%, but will go to 10% on day 2 and then 20% by day 3 if all is going well per customer ops.

Metrics and Reports

  1. Logging: add: “live_checkout=true/false” to our existing metrics logging during checkout.
  2. New reports:
    1. Conversion rate for users in live chat (test) vs. without it (control).
    2. Total num orders and revenue attributed to live chat.
    3. Of users in the test, how many actually click on live chat.
  3. Slack reporting: can tell us time spent per chat, simultaneous chats, etc.

My example above may seem obtuse, but it won’t be for my engineering and BI teams — and that’s the audience it is for. Remember: write what is necessary for human brains to execute.

Future Work

  1. If we see very little live chat usage: we’ll need to try a few things like: (a) auto pop-up chat, (b) change CTA copy/UI, (c) photo of agent next to chat CTA.
  2. If the test succeeds: we’ll ask for more heads, and do a bigger roll out in Q1 with vendor selection, better reporting for wider consumption, and formal chat training.

It’s always a good idea to signal where this is headed so people can think longer-term.

Tasks and Timeline

This timeline may slip by 1-2 weeks due to the kinds of issues mentioned in “future work”. That’s ok as long as we have results by Dec 1, so we can ask for heads during Q1 resource planning.

  1. Oct 4: spec review.
  2. Oct 8: test on dev env with customer support’s help in setting up agents/times.
  3. Oct 11: launch. We will need to increase traffic over the next few days.
  4. Oct 17: sync after 1 week. We may have additional tasks then.
  5. Nov 12: final sync to review stats and decide if we want to do more or kill it.
  6. Dec 1: this is the hard date for having the project wrapped up and results on hand.

It’s ok if you only have a rough estimate, and need more analysis to refine it (such as a tech spec). But it’s still important to try and put time bounds down as early as possible to signal roughly the size and scope. Estimates must come from the builders (dev, design, etc.).

Example of a completed spec.

Aaah, doesn’t that feel more solid? Writing a spec may seem like extra work, but it’s not. Effective specs will help you and your team save time, and deliver with confidence.

아직 확신이 들지 않는가? 스펙 문서 작성이 쓸데없는 추가 업무 같아 보일지도 모르지만, 그렇지 않다. 효과적인 스펙 문서는 당신과 팀의 시간을 절약해주고, 프로덕트를 자신있게 출시할 수 있도록 도와준다.

STOP! —Have you read the example spec yet? Read it now, please.

1_rozjnqqkzgmbnwzma4asog
“엔지니어링 업무에서, 문서로 커뮤니케이션하는 것이 구두로 하는 것보다 더 낫다.
일관성, 지속성이 있으며 책임 소재를 분명히 하기 때문이다” — 벤 호로비츠

A Guide to Writing Specs

I started with an example to anchor the ideas presented in the rest of this post. Do make sure you read the example spec before continuing.

Why write a spec?

To ship the right product with higher quality, speed, and predictability.

스펙 문서 쓰는 법

이 포스팅의 나머지 부분에서 제시하고 있는 아이디어가 와 닿게 하기 위해 예시 문서를 작성했다. 아래로 넘어가기 전에 예시 문서를 먼저 읽기를 바란다.

왜 스펙 문서를 쓰는가?

적합한 프로덕트를 더 높은 품질로, 빠르고, 예측할 수 있게 내놓기 위해서.

Yeah, that’s it. Now, how does a spec help you do that? Horowitz says it well above, and my example illustrates why, but here it is for clarity:

  1. Do critical thinking up front
    Writing forces you to think through specifics, in prose, before the expensive work of architecture, coding, design, qa, etc. takes place. It raises the quality of your decisions, and reduces the chance of surprises.
  2. Communicate efficiently
    One way or another, you will communicate your proposal to various stakeholders (support, engineering, design, finance, management, etc.). A spec allows you to batch this communication, and to do it without ambiguity so your team can grok and respond intelligently.
  3. Raise accountability
    By publicly committing to measurable goals you align the incentives of the team: stakeholders will realize how unreasonable last minute requests are, and engineers will think twice when making estimates.

어떻게 스펙 문서가 그걸 가능하게 하는가? 벤 호로비츠의 말과 스펙 문서 예시를 통해 ‘왜’ 에 대해서는 설명했지만 확실하기 위해 더 적어보았다.

  1. 초기부터 비판적 사고를 하게끔 한다.
    글을 쓰는 것은, 설계, 코딩, 디자인, QA 등의 ‘비싼 작업’이 시작되기 전에 먼저 구체적인 부분에 대해 생각하게 한다. 선택의 질을 높여주며, 생각하지 못한 돌발 상황이 생길 확률도 줄여준다.
  2. 커뮤니케이션을 효율적으로 할 수 있게 한다.
    어떤 방식으로든, 당신은 다양한 관계자들(운영, 개발, 디자인, 재무, 경영진 등)과 이 계획에 대해 커뮤니케이션하게 될 것이다. 스펙 문서는 이러한 커뮤니케이션을 묶어서 해결할 수 있게 해주고(이런 문서 없이 구두로 설명한다면 각자가 이해하는 바가 모두 달라질지도 모른다), 모호한 부분이 없게 함으로써 다른 사람들이 이해하고, 지적인 응답을 할 수 있게 해준다.
  3. 책임 소재를 분명히 한다.
    측정 가능한 목표를 공개적으로 알림으로써 팀의 목표를 정렬해주는 효과가 있다. 관계자들은 마지막 순간에 추가 요청하는 것이 얼마나 무리한 일인지 알게 될 것이고, 개발자들은 일정을 산정할 때 숙고하게 될 것이다.What should a spec contain?

Your spec is a clearly communicated decision on what to build, and why. There are many ways to express your ideas in a structured manner, but at the heart of it, you must address these five things:

  1. The Problem
    Frame the problem that you trying to solve. More importantly, explain why it is worth addressing. Be specific, and provide metrics.
  2. Measurable Goals
    Promise clear deliverable and outcomes. Identify what’s out of scope. Make sure it’s easy to look at each goal and answer: did we hit it?
  3. Context
    Provide evidence that your audience needs to understand the problem and believe in your proposal. Assumptions, use-cases, metrics, etc.
  4. Detailed Solution
    Your proposal should be detailed enough for your team to consume and execute — think of it like code for human brains to run[1].
  5. Timeline
    List dates and milestones that your team believes in. This section may start off vague, but should be finalized in your last spec review.

Use the example spec above as a template for writing your own. Add/remove/move sections as you see fit, the narrative structure doesn’t matter as long as you address the above points in a clear and specific manner.

스펙 문서에 무엇이 포함되어야 하는가?

스펙 문서는 무엇을, 왜 만들어야 하는지에 대한 명확한 결정사항을 모아놓은 문서이다. 아이디어를 구조화하는 방법은 여러 가지가 있지만, 핵심 내용은 다음 다섯 가지다.

  1. 문제(The Problem)
    풀고 싶은 문제를 정리. 중요한 것은, 이게 왜 다뤄져야 하는지를 설명하는 것이다. 구체적으로 설명하고 지표를 제공하라.
  2. 측정 가능한 목표(Measurable Goals)
    결과물을 명시하라. 무엇이 범위에서 제외되는지도 밝혀라. 목표를 보고 “우리가 이걸 달성했나?” 라는 질문에 답변할 수 있도록 목표를 세워야 한다.
  3. 상황(Context)
    문제에 대해 이해하고 당신의 제안 사항에 동의할 수 있게끔 하는 근거를 제공하라. 가정, 사례, 지표 등..
  4. 상세한 해결방안(Detailed Solution)
    팀에서 보고 실행할 수 있을 정도로 자세하게 적어야 한다. 실제 작업에 참여할 사람들의 두뇌를 가동하게 하는 코드를 작성한다고 생각하라.
  5. 일정(Timeline)
    팀에서 논의된 날짜별 마일스톤을 적어라. 처음엔 대략 적더라도, 마지막 리뷰미팅 전에 최종적으로 결정되어야 한다.

위에 첨부한 예시를 템플릿으로 활용해보는 것도 괜찮다. 필요하다면 섹션을 추가/삭제/이동하라. 위의 5가지 포인트가 명확하고 서사적인 구조를 유지한다면 어떻게 되어도 괜찮다.

How to write a spec?

Here’s the general process that I follow to write and review specs. It can vary by project size, number of stakeholders, etc. but this is the general flow:

  1. Write a quick draft (1–2 hours)
    Close Slack and your email. Brew some tea. Sit back and think. Then jot down what you know in bullet form (see example draftfrom above).
  2. Setup a couple of 30 minute 1–1 meetings (1–4 hours)
    The aim is to work through assumptions, improve your proposal, and get buy in. Keep these meetings tiny and focused with as few people in the room as possible (ideally 1–1s). For the example, I would setup 3 meetings with the support manager, a finance person, and an engineer.
  3. Write and edit the spec(0.5–3 days)
    At this point you have a pretty solid idea of what can, and needs to be done, but a lot of details will be swirling in your head. Put it all together with some critical thinking and writing. And when you have a draft: do a lot of editing. You can usually make your first draft 30–50% shorter, and it’s worth it: brevity and clarity will result in it being read. Most specs can be written in 0.5–1 day, but substantial projects may take 2–3.
  4. Publish and setup a 1 hour review (15 minutes)
    Send a wide email with your stakeholders on the “to” line, and other interested parties on the “cc” line (e.g. your product team, the broader support org). Follow up with a meeting invite for key people: those who will do the work, and those who have veto/approval authority.
  5. Review the spec (1 hour)
    Start your spec review meeting by asking who has not read the spec in detail. There will usually be 1 or 2, in which case, say “no worries, let’s take 10 minutes to read the spec, if you have read it already, feel free to take a break”. Use this meeting to get sign off from stakeholders and get understanding and commitments from the doers (Dev, Support). You may need to revise and repeat this step based on what you learn.

After the review, send an update and file tickets (1–2 hours)
Your email should point to an updated spec, the tickets related to the project (e.g., add Javascript code, write BI reports, QA in our staging env, do a dry-run with Support team, etc.), and a rough date on when you’ll update the group next. Often, the next major step will be for an engineer to write a tech spec, but not always (my example doesn’t need it).

스펙 문서는 어떻게 쓰는가?

다음은 내가 스펙 문서를 작성하고 리뷰하는 과정이다. 프로젝트의 사이즈나 관련된 사람들의 수에 따라 달라질 수 있지만, 일반적으로 이렇게 진행된다.

  1. 초안을 작성한다 (1–2시간)
    Slack과 이메일을 닫는다. 차나 커피를 가져온다. 의자에 기대앉아 생각 한다. 그리고 알고 있는 것들을 불릿 형식으로 적어나간다(예시 참고).
  2. 두어 번의 30분짜리 1:1 미팅을 잡는다 (1–4시간)
    이 작업의 목표는 가정을 만들어 나가고, 제안을 개선하며, 사람들을 끌어들이는 데에 있다. 이 미팅이 거창해지지 않도록 최대한 적은 사람이 집중해 참여하게 하라(1:1 미팅이 이상적이다). 예를 들면, 이 경우에는 고객 지원 담당자, 재무 담당자, 그리고 개발자와 각각 1:1 미팅을 잡을 것이다.
  3. 스펙 문서를 작성하고 수정한다 (0.5–3일)
    이 시점에서 당신은 이제 무엇을 할 수 있고, 또 해야 하는지에 대해서는 확실한 아이디어를 가지고 있을 것이나, 여러 상세한 항목들은 머릿속을 어지럽게 돌아다니고 있을 것이다. 비판적인 사고와 글쓰기로 이것들을 정리해보아라. 초안 작성을 마치고 나서는, 계속 수정해라. 보통 초안을 기준으로 30–50% 짧아지도록 할 수 있으며, 그렇게 해볼 가치가 있다. 간결성과 명확성을 높임으로써 사람들이 더 읽게 할 수 있으므로. 대부분의 스펙 문서는5–1일 안에 쓸 수 있지만, 더 규모가 있는 프로젝트의 문서 작성에는 2–3일이 걸리기도 한다.
  4. 문서를 보내고 1시간짜리 리뷰 미팅을 잡아라 (15분)
    직접 관계된 사람들을 “to”에 넣고, 관련이 있을 수 있는 사람들(product team 사람들, 더 넓은 범위의 운영 조직 등)을 “cc”에 넣어서 메일을 보내라. 중요인물들을 미팅에 초대하라. 의사 결정에 거부/동의 권한이 있거나, 직접 프로젝트에 참여하는 사람들을 말한다.
  5. 스펙 리뷰 미팅 (1시간)
    스펙 문서를 자세히 읽지 않은 사람이 있는지 물어보면서 시작하라. 한두 명이 이에 해당할 것이다. 그 경우걱정하지 마세요, 다 같이 10분 동안 읽고 시작하죠. 다 읽으셨다면 잠깐 쉬고 계셔도 좋습니다.” 라고 말하고, 다 같이 읽는 시간을 가지도록 하라. 이 미팅을 통해 관계자들의 동의를 구하고, 직접 실행할 사람들(개발, 운영)에게는 책임을 확인하라. 이 과정에서 알게 된 것을 토대로 문서를 업데이트하고, 미팅을 다시 가져야 할 수도 있다.
  6. 리뷰 미팅 후, 업데이트된 내용을 보내고, 티켓을 만들어라 (1–2시간)
    이 이메일에는 업데이트된 스펙 문서와 프로젝트와 관련된 티켓들의 링크(티켓들은 작업 단위로 쪼개진다 — 자바스크립트 코드 추가, BI 레포트 작성, 스테이징 서버에서 테스트, 운영팀과 함께 예행연습 등..), 그리고 언제 다음 메일을 보낼지에 대한 대략적인 언급이 있어야 한다. 종종 다음 단계는 개발자가 기술 스펙을 작성하는 것이지만, 항상 필요한 것은 아니다 (이 예시처럼 간단한 경우에는 필요하지 않다).

What are some pro-tips for writing an effective product spec?

  1. Keep it short
    No spec writing advice is more important. Brevity forces clarity of thought and communication. It also means that your doc is more likely to be read and understood — because that’s all that counts.
  2. Use plain English and simple formatting
    Use shorter and simpler words over fancy ones. Use bullets and bold styling to make it easy to scan your doc. Write in a casual style, and make it interesting. Use humor if you can.
  3. Stay ahead of your dev team
    A completed spec is one that has been reviewed and generally agreed upon. If you’re hoping to slot in work into a future sprint, make sure you start this process 2–3 weeks before.
  4. Think like an engineer
    A lot of edge cases appear when one finally sits down to write code — but that doesn’t have to be the case. If you think through what it will take to build it, you’ll address them early (e.g., does live chat work on mobile?).
  5. Bring everyone on the journey
    By the time I do a spec review, most people in the room have a general idea of what’s coming — because I’ve vetted it in small focused meetings and informal chats. This means I’ve done my job in communicating the what and the why, and now we’re just focused on the details.
  6. Work hard on images
    Like flow diagrams, or wireframes. They can convey huge amounts of info in an easily digestible manner, but can also take lots of time to make.
  7. Spend 0.5 to 3 days thinking and writing
    Depending on how large the project is. More time than that usually results in diminishing returns, especially because nobody will read a doc that is longer than 5–6 pages.
  8. Set direction and point at the vision
    You’re not just defining this one feature, but you’re also providing context on why we’re doing this and where we’re going. Point out how this project affects the grand plan, and what things may come next.
  9. Make sure your Audience reads it
    If your spec is too long, confusing, or just not shared with the right people, you might as well not write it. Make sure it is read. See my tip on reading it at the start of reviews.

Get honest feedback
Are your specs specifying the obvious? Or don’t have enough detail? Are we finding too many edge cases later on? Or are we spending too much time in planning/review? Ask your team.

효과적인 스펙 문서에 관한 팁

  1. 짧게 써라
    이보다 더 중요한 팁은 없다. 간결성은 사고와 커뮤니케이션에서의 명확성을 불러온다. 또한, 사람들은 짧은 문서를 더 잘 읽고 이해한다. 이게 가장 중요하다.
  2. 명백한 어휘와 단순한 포맷을 사용하라
    미사여구보다는 짧고 간결한 어휘를 사용하라. 불릿과 볼드를 이용해 문서를 훑어보기 편하게 만들어라. 너무 딱딱하지 않게 쓰고, 재미있게 써라. 자신이 있다면 유머를 덧붙여도 좋다.
  3. (개발팀 일정에) 앞서서 써라
    완성된 스펙 문서는 이미 검토 과정을 마치고 모두의 동의를 구한 상태여야 한다. 즉, 스프린트가 시작하기 2–3주 전에는 이 작업을 시작해야 한다.
  4. 개발자처럼 생각하라
    보통은 실제 개발자가 코드를 작성할 때가 되어서야 특이 케이스들이 나타나지만, 항상 그러란 법은 없다. 어떻게 만들지를 미리 깊게 생각한다면 그런 부분을 미리 정하여 언급할 수 있다(e.g., 라이브 채팅이 모바일에서 돌아가는가?).
  5. 모두를 동참시켜라
    내 프로젝트의 스펙 리뷰 미팅을 진행할 때면, 이미 대부분의 사람은 이게 어떤 것인지를 알고 있다. 내가 작은 미팅이나 비공식적인 대화/채팅을 통해서 미리 전달했기 때문이다. 이런 방법으로 ‘무엇을 왜 하는지’에 대한 커뮤니케이션을 미리 마친 상태에서 본격적으로 디테일에 집중할 수 있다.
  6. 시각화에 대해 열심히 고민하라
    플로우 다이어그램이나 와이어프레임 같은 시각화는 중요하다. 많은 양의 정보를 쉽게 이해하도록 도와준다. 물론 이건 많은 시간이 필요하다.
  7. 생각하고 쓰는 데에는5–3일만 써라
    이것보다 더 많은 시간을 들이는 것은 더 못한 결과를 가져오는 경우가 많다. 아무도 5–6페이지보다 긴 문서를 읽지 않을 것이기 때문에.
  8. 방향과 비전을 제시하라
    단지 이 기능을 정의하는 데서 끝낼 것이 아니라, 왜 이것을 해야 하는지와, 앞으로 어떤 방향으로 갈 것인지에 대해서도 전달해야 한다. 거시적인 관점에서 이 프로젝트를 보게 하고, 다음엔 어떤 일을 진행할 것인지도 언급해주면 좋다.
  9. 읽히도록 만들어라
    스펙 문서가 길거나, 정신없거나, 적절한 대상에게 공유가 되지 않았다면 당신은 문서를 쓰지 않은 것이나 다름없다. 읽히도록 만들어라. 리뷰 미팅을 시작할 때 다 같이 읽는 시간을 만드는 것도 좋다.
  10. 솔직한 피드백을 받아라
    명백하게 썼는가? 아니면 정보가 불충분한가? 나중 단계에서 특이 케이스를 잔뜩 발견할 것 같은가? 기획/검토 단계에서 너무 많은 시간을 들이고 있는가? 팀에게 물어봐라.

But what about Agile and Scrum?

I know I will raise eyebrows, but specs are fully compatible with the principles of the blog, and are essentially represented in methodologies like Scrum — after all, don’t stories need more meat put on them at some point? Why have verbal and whiteboard sessions, only to then lose the clarity and communication value that comes from writing it down?

The view that specs result in slower releases, over-planning, and generally wasted time is unfounded. Multiple world-class teams I have worked on followed several agile principles (like 2-week sprints), shipped code daily (or more), and measured their success on product shipped (not documentation or meetings) — yet still prized specs as a key part of their process.

And what about tech specs?

I’m a huge fan. While product specs focus on the what, tech specs focus on the how. They bring the same clarity to a different part of the building process, and ultimately make engineers (and their customers) happier. I may write about tech specs in a future post if there is interest.

In Conclusion

Thanks for reading this far. If you’ve found this post useful, please do share with your product and engineering teams. Happy day!

Question :

It seems that in order to write an effective spec, a product manager would need a decent understanding of how businesses work (to frame goals and requirements in a way that can get high-level sign-off); and also the ability to grok how-engineers-think; and experience to know the specific “gotchas” around BI metrics and operations.

That’s a lot. I realize it’s a somewhat leading question, but how should companies hire and train product managers? If an organization doesn’t have a senior product manager with experience in all these areas, any advice for how they can still write specs with the right level of thought around what’s out of scope, setting measurable goals, etc?

실리콘밸리: 최고의 팀 구성을 하는법

최고의 구성 어려운가?
부제 : 우수한 인력과 함께 팀원으로 일하기 위한 5가지 방법

 

(실리콘밸리) 스타트업이 일하는 방식
구글이나, facebook의 일하는 방식은 어떨까? 국내의 환경과 어떻게 다를까?
이를 알아보고  최고의 팀을 구성하고 일하기 위해서는 어떻게 해야 할까 논의해 보기로 하겠다.

국내의 대기업의 경우 일반적으로 대부분의 업무가 Top-down으로 진행된다.
하지만, 구글이나 facebook등 실리콘벨리는 실무자의 주도(Bottom-up)로 일이 진행되는 경우가 많다.

업무를 하다가 새로운 아이디어가 있을 경우 사내 게시판에 공유하고,

이 아이디어가 선정될 경우 아이디어를 제안한 사람을 중심으로 시작되게 된다.
이렇게 새로운  프로젝트 시작되면, 프로젝트의 개요  향후 하고자 하는 일들을 팀원들에게 공지를 한다.

관심이 있는 사람들이 모이게 되면, 단순 Idea 수준의 논의가 아니라 실제 Project(or 서비스)가 어떻게 진행되고, 각 업무에 대한 내용과 어떤 인력이 어떻게 업무를 해야 될것인지 구체적으로 논의한다.

단순히 Idea 차원에서 이야기를 할 경우, 구체성이나 실행 가능성이 떨어진다고 생각이 든다면 팀에
합류 하지도 도와주지 않을 것이다. 단 아래와 같은 경우는 제외

  • 정말 재미있어 보이거나
  • 자신의 실력 향상에 도움이 되거나
  • 세상을 바꿀만큼 멋진 일이 아니라면

자기의 일이 바쁜데 시간 낭비할 이유가 없는 것이다.

이와 같이 어떤 아이디어를 시작하고자 할때 최고의 팀원을 확보하고 이를 위해 좋은 인력을 확보해야 하기 때문에 누가 이 업무를 가장 잘할수 있는지, 최고의 팀을 만들기 위해 어떤 업무를 어떻게 해야 하는지를 고민하고 그 팀원을 찾고 설득하는데 엄청난 노력을 해야 한다.

(필자는 Linkdin을 최고의 툴로 생각한다. 이때 효율적인??? 툴이 Linkdin 과 같은 개인의 프로필과 누가 무슨 업무를 했고 같이 했던 동료들의 feedback과 그 사람이 어떻게 일했고, 그 업무에 대한 peer-review가 담긴 내용이 도움이 된다. 이 때문에 Linkdin은 엄청나게 유용한 Tool이라고 생각한다.)

이렇게 함께 모여서 Idea를 제시하고 각자 생각하는 바를 이야기 한다. 이때 어설프게 컨셉이나 개념수준으로 이야기 한다면 어떻게 될까? 팀원은 팀원대로 팀장은 팀장대로 실력이 있는 프로젝트를 성공적으로 이끌수 있는 사람으로 교체될 것이다. 이와 같이 현실성이 없거나 실행을 가능하게 할 조력자 및 완벽한 팀을 구성하고자 노력하고, 그렇지 않다면 프로젝트는 진행 자체가 안된다.

생각해 보라. 프로젝트 전체를 이해하고 방향을 제시하는 PM이 없고, 실행할수 있는 능력이 안되면 당연히 동조하지 않고, 그 프로젝트는 좌초하거나 담당자가 바뀌는 것이 당연할 것이다. 이렇게 전체적인 내용을 설명하는 과정을 거쳐 업무에 대해 논의하고 상호 설득을 거쳐 팀원들이 조인하고 업무를 나누고 일정을 협의하여 프로젝트가 마침내 실행되는 것이다.

하지만 국내의 프로젝트의 경험을 생각해 보자. Top-down식의 프로젝트가 논의되고 TF팀이 구성되어 업무가 시작되면 프로젝트의 책임자와 팀원들은 전체적인 방향에 대해서 이해고 뭐고 없고, 그냥 Task force 팀이 구성되어 일이 시작되면서, 많은 문제가 발생된다. 프로젝트의 시작과 함께 전체적인 범위가 축소되거나 방향이 바뀌거나, 사공이 많아 프로젝트가 산으로 가는 경우가 많다.

생각보다 많은 회사, 조직에서 이렇게 프로젝트 혹은 업무가 진행된다. 내부 인력으로 하기 어렵다고 판단되면 외주를 주거나, 외부의 우수한 인력을 뽑아 구성원으로 받아 들인다. 외주를 준다고 외부의 인력이 합류한다고 일이 성공적으로 진행될까?

국내에서 진행되는 대부분의 프로젝트가 이럴진데 효율적인 팀 구성과 프로젝트의 업무정의가 선행되고 진행을 위한 프로세스 혹은 전체적인 조율이 안된 상태에서 실력있는 인력이 합류 한다고 해서 이들은 제대로 된 방향으로 끌고 가기는 힘든 상황이 대부분이다.

또한, 대부분의 조직에서 실력과 내공이 뛰어난 인력을 조직의 구성으로 받아들이는 것을 꺼려한다. 그 이유를 살펴보자면 굉장히 단순하다.

 

다양한 이유로 우수한 인재와 일하는 것을 꺼리는 경우가 많은데 이것은 회사뿐만 아니라 리더에게도 도움이 되질 않는다.

 

 

 

그 이유를 4가지 정도로 분류해 본다면.

 

  1. 자신의 자리를 위협한다.
    향후 자신의 자리를 위협할수 있다는 것이다. 다른말로 한다면 실력이 없다는 의미이다. 회사(조직)와 서비스는 끊임없이 성장해야 하는데 실력이 있는 인재를 지속적으로 조직내에 유입되어 성장의 기틀을 마련해야 하는데 실력이 있는 후배가 자신의 자리를 위협할 수 있다는 것으로 실력있는 인력을 받아들이지 않는 것이다. 또한 실력있는 인재가 팀에 합류하여 성과를 만들고 팀자체가 성과 지향적인 방향으로 나아가지 않으면 자신은 물론 조직까지 퇴보하는 것이다. 단순히 자신의 자리를 위협하는 인력이 들어오는 것을 두려워 할 때, 조직이 현재의 수준에서  머무는 상황이 계속된다면, 그 조직이나 팀은 존재 의미 자체가 흔들릴 것이다.
  2. 시키는 대로 일을 하지 않는다
    실력이 있는 인재의 경우 다양한 상황을 고려하고 이를 기반으로 자신의 의견 제시를 한다거나 기존의 Top-down식의 업무가 아니라 능동적으로 본인의 생각을 반영하여 일을 하게 된다. 이렇게 되면 기존의 보스와 문제가 생길 경우가 종종있다. 시키는 대로 일을 하지 않아 문제가 된다는 것이다.실력이 없는 보스는 팀원의 의견을 자신의 의견으로 착간한다거나, 윗사람이 원하는 방향으로 사업(프로젝트)의 방향을 이끌어 가기 때문에 전체적인 관점에서는 마이너스가 될 수 있다.
  3. 주도권을 빼앗긴다.
    일을 하다보면 실력이 있거나, 나아가야 될 방향이 어느순간 정리가 되는데 이때 실력있는 팀원이 이 역할을 주도하는 경우가 많다. 이렇게 되면 다른 구성원들이 보스인 자신보다는 우수한 인력의 말에 더 무게를 싣는 상황이 발생한다.
  4. 그냥 싫다.
    요즘 후배들을 보면 스펙이 뛰어난 사람들이 많다. 일 잘하는 것 뿐만이 아니라 스펙이 좋기 때문에 일을 조금만 잘할경우 눈에 띄게 마련이다. 일 잘 하는 인재가 들어와서 성과 측면으로 접근한다면 프로젝트 올바른 방향으로 가겠지만, 그냥 싫은 상황이 되는 것이다.

 

앞서 일하는 방식의 문제점 뿐만 아니라 우수한 인력과 함께 일하지 못하는 문제점에 대해 이야기를 해 보았다. 그렇다면 이제는 실력있는 인재(팀원)와 일을 하기 위해서는 어떻게 해야 할까 그 대안을 이야기 해 보겠다.

 

  1. 문제를 정의하고 해결방안에 대해 끊임없이 고민하고 재미있게 일하는 분위기를 만들어라

일에 대해 몰입하다 보면 일이 재미있다는 생각이 들고, 끊임없이 고민하던 문제를 해결하게 되면 그 성취감은 무엇에도 비할수 없다. 대부분의 일이 혼자 하는 것이 아니기 때문에 협업하다 보면 엄청난 성과를 이룰수도 있고, 팀과 함께 일을 하다 보면 혼자 일하는 것 보다 훨씬 큰 성취를 거두기도 한다. 재미있게 일하는 분위기를 항상 만들어야 한다.

 

하지만, 이상하게도 국내에서 기업에서 일한 경험에 따르면 일하면서 사람에게 받는 스트레스가 너무 컸다는 생각이 든다. 일에 대한 스트레스가 아니라 사람에 대한 스트레스다.

 

이게 참 이상하다. 일을 할때는 일로 스트레스를 받아야지 사람에게 스트레스를 받는다는게 이상하지 않은가? 자신의 업무에 몰입하다 보면 해결책은 어떻게든 해결책을 찾아낼수 있다. 하지만 보기 싫은 사람과 일하거나 끊임없이 사람으로 인해 받는 스트레스라면 그 사람과 마주치지 않는 방법이 가장 현실적이다. 이렇게 문제를 해결하다 보면 우수한 인력이 더 나은 환경을 찾아 나가게 된다.

  1. 우수한 인력을 적극적으로 찾아 이들과 함께 일하는 방법을 터득하라
    주변에 최고의 인력이 반드시 있다. 이들을 찾아 내 사람으로 만들고 함께 일을 도모할수 있는 계기를 만들어야 한다. 우수한 인력이 합류하여 효과적으로 일하고 최고의 성과를 낼수 있는 조건을 만들고 더불어 나도 함께 성장할 수 있는 기회를 만들어야 한다.
  2. 권한 위임으로 업무에 책임을 부여하고, 전체적인 방향을 제시하라
    업무에 대한 책임을 위임하고, 업무에 대해 방향을 제시한다. 그렇게 하면 우수한 인력은 사업의 방향을 잡고 팀원들을 설득하고 각 개별 인력의 최고의 성과를 낼수 있도록 설득하고 올바른 방향으로 나아가기 위해서 부단히 노력할 것이다. 이로 인해 전체적인 결과(output)도 좋을거라 믿는다. 단 중간 중간에 체크해서 진행사항과 방향을 체크하면서 초기의 목표를 벗어나기 않도록 조율하는 과정을 거친다.

가장 문제는 실력있는 팀원이 들어왔는데 기존의 조직에서 이 실력을 발휘하고 그 내용을 조직이 흡수할수 있는 체계가 갖춰지지 않아 조직에 실망을 느끼고 조직에서 이탈하게 되는게 가장문제가 된다. 친한 지인이 외국계에서 오랜 경험을 쌓은뒤 국책은행에 들어갔는데 조직체계가 사업의 본질과 관련없는 보고를 위한 보고서 작성과 업무와 상관없이 내려오는 임원들을 숙제들 그리고  실력을 발휘하는 것 보다 빨간펜으로 문서에 수많은 시간 낭비에 지쳐 조직에 실망과 함께 얼마후 조직에서 이탈하는 것을 보면 너무 안타까웠다.

  1. 업무성과를 출퇴근 시간으로 성과를 측정하지 않는다.
    명확한 업무정의, 일정 등 큰 그림을 제시하는 것만으로 충분하다.
    일잘하는 사람은 성실하게 자신의 일을 한다. 하지만 많이 고민하고 전체적인 방향이 정해지면 그때부터 엄청난 속도로 결과를 도출한다. 즉 일 잘하는 사람은 자신이 알아서 시간관리를 한다. 보스가 하나 하나 챙기면서 귀찮게 할 경우 오히려 시간이 더 걸리기도 하고 보스가 보기에는 답답한 경우도 있지만 본인은 가장 효율적인 방법을 찾고 그 방법대로 일하기 때문에 시간표 대로 일을 하지 않은 경우가 있을 수 있다. 필자는 실력이 뛰어난 사람들 하고 일하다 보면 어떻게 저렇게 빠른 시간내에 저렇게 멋진 결과물을 내는 사람들도 보았다. 하지만 이런 경우는 극히 드물고 일을 하다보면 다양한 input이 필요하고 연계되는 상황들을 고려하다 보면 생각보다 시간이 걸리거나 너무나 다양한 case를 고려할수 있다. 이때에는 옆에서 조언자로서 전체적인 방향만 제시해 주면 된다.실리콘밸리의 많은 회사들이 출근시간에 혹은 업무시간에 구애 받지 않고 성과에만 집착하는 경우를 많이 본다. 실제로 협업할시에는 미친듯이 일을 하지만 회의를 통해 혹은 협업을 통해 나아가고자 하는 방향이 정해졌다면 그 이후는 개인이 미친듯이 일해서 결과물을 내 놓는다. 모두가 이를 지지하고, 이때 결과물이 늦어지면 모두에게 피해를 미치기 때문에 일을 하면서도 서로간에 필요한 상황을 체크하고 긴밀하게 연계해서 일을 할 수밖에 없다.

 

이에 더해서 대기업 혹은 기존 조직에서의 문제를 마지막으로 이야기 해 보고자 한다. 필자는 IBM GBS, Deloitte 의 컨설팅 조직에서 10년이 넘는 기간 동안 40개 이상의 프로젝트를 대기업과 경험해 보았다. 이 경험에서 문제를 인식해 본다면 회의문화 혹은 보고체계에 문제라고 이야기 할 수 있겠다

 

신규 프로젝트가 시작되면 업무를 담당하는 임원이 참석하여 보고를 받는다 주간/월간 보고를 통하여 보고를 받고 중간/완료 보고를 받는다. 하지만 이 사업이 시작될 때와 달리 프로젝트 중간에 방향이 바뀔수도 있고, 업무의 범위가 변경될수 있다. 하지만 단순히 보고를 받게 되면 중간에 변경되거나 범위의 변경 자체에 대한 이해도가 떨어진다. 사업이 시작되면 의사결정자가 반드시 중요한 회의에 참여하여 진행사항을 이해하고 전체적인 맥락을 파악해야 하는데 단순히 보고를 받아서는 그 이해 수준이 떨어질수 밖에 없다.

또한 회의시간에 보고를 받아서는 안되서 회의전에 논의사항과 의사결정이 필요한 사항을 충분히 숙지하고 회의에서는 의사결정을 해야될 사항을 중심으로 논의가 되어야 하는데 사업의 이해가 떨어지는 상태에서 진행사항을 설명듣는 차원에서 회의가 진행되기에 이렇게는 프로젝트가 산으로 가능경우가 대부분이다.

즉 기존에 대기업에서 하는 방식의 회의와 보고체계로가 아니라 일하는 방식을 바꾸지 않으면 효과적인 업무, 효율적인 프로젝트 진행이 어려운 것이다.

이에 대한 구체적인 해결 방안은 다음번에 기고 하기로 하겠다.

취업(인턴쉽)을 준비하는 분들에게 드리고 싶은 말씀

저희 Companyfactory는 지난 6월 부터  인턴쉽을 진행하고 있습니다.
IMG_5257
(San Francisco SOMA 지역의 Wework 코워킹 스페이스 : 제가 찍은 사진)
많은 분들이 대기업 혹은 중소기업 인턴과정에 대한 오해가 있는것 같아 제 생각을 말씀 드리고자 합니다.
저희는 4년차 스타트업입니다. 대기업 처럼 인력이 많지도 않거니와 다양한 일을 하기에 인턴으로 오셔서 커피타기 복사와 같은 일을 하면서 시간을 보내지 않습니다. 정말 인력이 필요해서 인턴을 채용한게 가장 큰 이유이기도 하고요.
저희는 프로젝트 개념의 업무가 진행되기에 프로젝트 매니저 그리고  팀원의 개념으로 일을 하기에 각 개별 인원이 업무를 배분하여 진행합니다. 각 나름대로 최대의 Performance를 내기를 원하죠…
하지만, 스타트업을 하다보면 대부분의 일이 해본것 보다 그렇지 않은 일들이 많기에 저희도 내부적으로 끊임없이 시행착오를 하며 일을 하고 있지만 그래도 즐겁게 일하려고 노력을 기울입니다. 일도 중요하지만 사람이 중요하다는걸 알기에 자신의 일을 최대한 사랑하고 협업의 하모니를 추구합니다.
저희는 일부 대기업에서 행해지는 ‘인턴이 아는게 없으니 단순 노동을 시켜야 되나’라는 생각을 하지 않습니다.

우리의 팀으로 받아들이고 앞으로 우리와 함께 하는 사람에 대한 Human resource 확보차원의 투자라 생각하고 있습니다. 제가 많은 시간 일하면서 힘들고 스트레스를 받으면서 회사 생활을 한 기억이 있기에 일하면서 행복을 찾기를 원하고 또 제 주위의 사람들도 그렇게 되길 바라며 회사를 경영합니다.

출장 간 시간에 고민하던 문제를 해결하기 위해 1달 넘게 고민하던 문제 해결을 위해 해결책을 찾은 결과가 오해를 사기도 하구요.
서비스 매칭 알고리즘 개선을 위 타 서비스(tantan 소개팅앱)를 분석하다가 여자친구 wechat에 알람이 가서 오해를 받기도 하구요… 푸는게 쉽지 않을 듯 합니다. ㅡ,ㅡ
물론 모든일을 효율적으로 일하면 좋겠지만 그 경험이 없을때에는 몰라서 힘들고, 선배들한테 혼나기도 하면서 이리저리 차일때도 있을테지만 그래도 선배들이 이끌어 주고 하면서 함께 성장하는 그런 회사 생활이면 좋겠습니다.
우리가 회사를 다니며 일을 하며,  스트레스를 받을 때도 있지만 사는게 다 그렇듯이 자기 만족이고 일을 하면서 자신이 일이 재밌고  행복과 만족감을 가지면 좋겠습니다. 그러려면 목표의 설정과 지속적인 feed back, 수정, 다시 목표설정을 반복하고 앞으로 나가야하는 절차를 밟아야만 한다고 생각합니다.
잠을 못자고 고민을 하고 또 힘들어해도 문제를 해결하고 방법을 찾고 이러한 방법을 통해 작게는 나, 조직, 회사, 사회가 바뀌는 과정을 반복함으로 스스로가 사회적으로 의미있는 존재가 되기를 모두에게 바라고 있습니다.이러한 절차 및 과정에 보람을 느끼기 위해서는 본인의 인생에 대한 설계가 매우 중요한 요소라고 생각합니다.
내 인생에서의 보람, 목표 및 방향을 측정하는 척도가 없으면 feed back도 없고 개선도 없는 쳇바퀴 굴러가는 인생이 될 것입니다. 이에 많은 분들이 힘들어하고 인생의 의미가 없다고 생각하고 불행해하시는 것이라 생각됩니다.적어도 많은 대학생들이 궁극적으로 본인의 기여로 세상에 바뀌고 이에 모두 인생의 의미를 얻을 수 있는 좋은 기회로 이 인턴쉽이 자리매김했으면 좋겠습니다.

스타트업 커뮤니케이션의 단절, 그 의미는….

스타트업에 합류하여 3년차가 되다 보니 다양한 일들이 발생한다.  그리고 또 극복해야 하는 상황들이 발생하면서 문제를 해결하기 위해 다양한 상황을 부딪치며 해결을 위해 노력하고 있다.

 다양한 서비스를 제공하는 스타트업 대표와 팀의 개발자, 디자이너, 기획자로 역활은 구분될 수 있으나 스타트업에서 서비스의 성공으로 이끄는 것은 결국은 리더의 역량과 조직문화이다.
일반적으로 문제의 발생은 사람과 사람과의 관계에서 발생하는데, 그 원인은 커뮤니케이션의 문제에서 비롯되는데, 서로 다른 경험을 가진 사람들과 일을 함께 하면서 서비스를 만들어 가기 때문에 다양한 상황이 발생된다.

적은 인원이다 보니 다양한 일을 한 사람이 할수 밖에 없다. 따라서 리더 즉, CEO 는 목표와 방향을 끊임없이 팀원들과 논의하고 공동의 목표를 팀원들과 이야기 하면서 문제를 해결을 위한 동분서주 하는데 특히, 서비스의 품질을 높이기 위해 부단한 노력을 기울인다.

이를 위하여 다양한 의견 즉, 조언을 토대로 서비스의 품질을 높일 수 있어야 한다.  이 모든 일이 협업을 통해 이루어지기에 조직의 문화 중 커뮤니케이션 자체가 조직의 문화를 만드는 중요한 구심점이 될수 있다.

스타트업에서 일을 하다 보면 작은 조직임에도 불구하고 이야기 즉, 커뮤니케이션이 거의 없는 상황이 발생한다. 왜 이런 상황이 발생되는가? 커뮤니케이션이 사라진 조직은 어떻게 될까?  조직간 커뮤니케이션이 사라지는 이유를 우선 살펴 보면

 첫째, 리더와 팀에 자신의 의견을 제시 했을때 무시되는 조직

대기업에 오랜 경험을 가진 CEO 의 경우 다른 사람의 말을 듣지 않는 경향이 많다. ‘나는 10년이 넘게 이 업계에 종사해 왔다. 당신은 이 업계에 도대체 알기나 하냐?  모르면 이야기 하지 마라?

이 한마디로 인해 커뮤니케이션의 단절이 시작되는데 오직 한 사람만 그 사실을 모른다., 제일 나쁜 경우는 이야기중에 모른다고 야단을 치거나 화를 내는 경우, 더이상 서비스 향상을 위한 아이디어나 커뮤니케이션은 점점 줄어들게 되는 것이다. 왜냐하면 그럴 필요가 없다는걸 경험을 통해 알게 되니까.

스타트업에서 빠른 일처리를 위해 다양한 피드백과 그 피드백을 통해 서비스의 질적 향상이 이루어진다. 이에 따라 다양한 의견을 나누고 그 의견이 반영되지 않는다고 판단하는 순간 서비스의 향상, 고객가치(Customer Value)는 증가하기 힘들다.

  둘째, 격리된 공간으로 자리배치,  경직된 조직의 리더

예를 들어 5명, 소수 인원으로 구성된 스타트업인데 공간을 구분하여 업무를 하는 경우 커뮤니케이션이 어려워지고, 격리된 공간 즉, 방문을 열고 들어가서 커뮤니케이션이 시작되어야 한다면 이 또한 코메디가 아닐수 없다.

경직된 조직의 리더가 아니라고 하더라도, 이런 상황이라면 커뮤니케이션이 점점 줄어드는 경향이 발생하고, 이는 조직문화가 문제가 아니라 스타트업이 망해가기 시작한다는 사실이다.

 이런 유형의 분위기를 피하기 위해서는 다음과 같은 두 가지 전략을 제안한다. “첫째 신뢰감을 서로 심어주기 위해 좋은 판단력을 가진 팀을 구성하는 것이고, 둘째 목표에 대한 공유, 그리고 서비스에 대한 가치에 대한 공감대 형성을 통해 다양한 의견제시를 통해 옳바른 의사결정을 하는 분위기를 만들어가야 한다.

조직의 리더가 모든 것을 다 알고 의사결정을 할수 없기에 조직의 리더가 우물쭈물 하는 사이 아무도 커뮤니케이션에 동참하지 않고, 이로인해 의사결정은 늦추어지고 스피디한 결정을 하지 못해 고객은 떠나버리기 마련이다.

 셋째, 리더와의 관계에서 신뢰를 잃어버린 경우

감정과 오해로 인해 리더와 신뢰를 잃어버린 경우, 커뮤니케이션을 할 필요성을 느끼지 못한다. 아무리 열심히 해도 남 좋은 일만 시킨다는 생각이 자리잡게 되면 커뮤니케이션을 통해 더 좋은 서비스와 고객가치를 만들려는 노력은 사라지기 마련이다.

조직문화는 회사에서 가장 중요하고 조직 문화를 만들어가는 첫번째가 팀원들과의 신뢰이다.

서로의 의견제시를 통해 상대방에게 설득시키고 좋은 서비스를 만들기 위해 끊임없이 논쟁하고, 그 논쟁을 통해 좋은 서비스, 즉 고객에 가치를 주는 서비스를 만들어 가는 조직이라면 성공할 수 있는 증거이다. 하지만 커뮤니케이션을 통한 더 좋은 서비스 만들기가 사라지고 CEO의 질문과 호통에 눈치를 보면서 리더가 듣기를 원하는 답변을 하기 시작한다면 이미 그 조직은 더 이상 성장하기 어려운 상황이 되는 것이다.

커뮤니케이션의 단절이 시작되고 있는지 않은지를 판단하는 쉬운 잣대로 지난 한달 동안 팀원들과 얼마나 커뮤니케이션이 했었는지 생각해 보자.

지난 일주일에 한번도 한적이 없다면 이미 직원들은 마음이 떠나 있다는 증거일 것이다. 일에 대한 열정과 서비스에 대한 신념이 식을대로 식어버렸다는 증거일 것이다.

리더와 커뮤니케이션을 하지 않고 혼자 모든일을 해 나가는 조직이라면 그 스타트업은 망하는 여정에 동참했다는 징조이다. 서비스고 뭐고 없다. 커뮤니케이션이 없는 스타트업은 더 이상 나아가지 못하고 팀은 더 이상의 성장이 멈춰버린 것이다.

당신의 (Startup) 아이디어를 도둑 맞을까 걱정하지 않아도 되는 이유

실리콘밸리에는 많은 한국 Startup 분들이 방문 하시는데요…
오늘 만난 Startup 대표님은 자신의 아이디어를 도둑 맞을까봐 걱정하며 이야기 하는 분을 만났습니다. 떠오르는 글이 있어서 다시 한번 공유 드립니다.

Medium에서 ‘Why Nobody Will Steal Your Shitty Start-up Idea”를 번역한 글입니다.

원문 읽기

  1. (대부분의 사람은) 당신에 (서비스에)대해 관심이 없다.
  2. 왜냐하면, 아이디어가 1%라면  99%는 실행력이기 때문이다.
  3. 동일한 아이디어로도 다른 사람들이 만들어 가면서 전혀 다른 제품과 비즈니스로 탄생하기 때문이다.
  4. 더 이상 ‘끝내주는’ 아이디어란 존재하지 않기 때문이다.
  5. 대부분의 성공적인 비즈니스들은 단순한 아이디어로 실행에 완벽하게 성공한 비즈니스들이기 때문이다. (실제 서비스 실행을 위해 얼마나 고생했을까 생각해…봐야…)
  6. 만약 Uber나 Airbnb가 시장에서 처음 선보여진 아이디어라고 생각했다면, 그렇지 않다. 비슷한 아이디어로 이미 많은 시도가 실패했기 때문이다.
  7. 서비스는 고객(중요한 것)에 집중해야 하고 제약없이 일할 수 있어야 하기 때문이다.
  8. 당신은 해답을 모르고 찾을 수도 없기 때문이다. 그러나 당신의 고객(시장)은 알고 있다. 밖에 나가 전문가와 만나라(되라), 사람들과 만나고 대화 하면서 피드백을 수집하라.
  9. 당신이 생각하는 수준에서는 해결되지 않기 때문에, 더 중요한 것(고객)에 집중해야 된다.
  10. 사람(vc)들은 당신의 서비스(아이디어)를 듣기 위해 NDA 를 체결하지 않고, 한다하더라도처음에는 상관조차 하지 않을 것이기 때문이다.
    (저도 여기 실리콘밸리에서 만난 일부 VC는 NDA 하자고 하면 싫다고 하는 사람도 봤네요 ㅡ,ㅡ)

영어 원문:

  1. Because nobody cares.
  2. Because an idea is 1% and execution is 99%.
  3. Because the same idea executed by different people will lead to totally different products and businesses.
  4. Because there are no revolutionary ideas anymore.
  5. Because the most successful businesses are basic ideas PERFECTLY executed.
  6. Because if you think Uber and Airbnb were first of their kind, you’re wrong. Thousands have failed with the exact same idea.
  7. Because you need to focus on what really matters and work without restrictions.
  8. Because you don’t have the answers, your market does. Talk out loud, go out there, become an expert, speak, network, and collect feedback.
  9. Because you don’t want to tune yourself to this level of thinking, and have better things to focus on.
  10. Because people you will interact with will never sign your shitty NDA to know more about your idea they don’t give a shit about in the first place.

1st 기업의 승자 독식 사회

기업의 평균적 이윤은 2007년 이후 급격히? 증가하는데 반하여 직장인(노동자)의 경우 임금소득은 오히려 하락하는 상황이 발생되고 있다고 합니다.  아래 그래프 참조

1391946475_04UPkIrA_20140209_203812

* 임금소득과 기업이윤의 상대적 비중 추이를 보면 1987년대 이후 기업이윤의 빠른 증가와 임금소득의 하락이 나타나고 있습니다.

하지만, MGI의 리서치에 의하면 이런 기업 이익의 증가는 이제 어려울 것이라고 합니다. 사실 미국의 상황이라고 보면 더 적합할듯 하지만요

1. 노동시장이 크게 변하고 있는데 노동인력의 국경간 이동이 점점 활발해지면서 고용주에 대한 협상력이 커질 것이라고 합니다.

2, 인구통계의 변화로 기업의 매출 성장이 쉽지 않을 것이랍니다.

3, 기업의 비용 감축이 점점 한계에 달하고 있답니다.

4, 이머징 국가의 대기업들은 이익보다 성장에 초점을 맞추는 경향이 크다고 합니다.(중국 조선업체처럼 이익보다 시장점유율을 높이려는 전략이 이런 모습이지 않을까 합니다.)

5. 선진국 경쟁 기업간의 경쟁이 가열되고 있답니다.

6. 새로운 테크기업들이 계속 등장하여 기존 산업을 위협할 것이라고 합니다.

988c7b36-58a8-11e5-9846-de406ccb37f2.img

그런데 MGI는 기업의 전체 이익은 떨어질지 모르지만 산업내 기업간 이익의 격차는 더 커질 것이라고 전망하고 있습니다. 현재도 승자기업은 더 많은 이익을 가져가는 상황이라고 합니다.

아 래 그림을 보면 미디어 산업에서 채굴업까지 기업들의 평균 이익은 다양하지만 각 산업의 상위 5%와 하위 5%의 이익차이는 업종에 관계없이 큰 편입니다. 이에 반해 유통업과 자동차 산업은 아직 승자독식이 크지 않다고 할 수 있습니다.

CEO(경영자)의 의사결정(Decision making) : 조직을 위해 동업자을 정리해야 할때

CEO나 리더의 경우 혼자가 아니라 창업을 같이 하거나 주위의 많은 이들의 도움으로 성장했다는 걸 알고 있습니다.

하지만, 어느 정도 성장한 후에, 힘든 시기를 함께 했던 사람들이 이상하리 만치 공정하지 않은 의사결정과 잘못된 행동으로 많은 사람에게 미움을 받는 경우가 있습니다.

명백히 잘못된 의사결정으로 회사의 손실을 입히거나 개인의 사리 사욕을 위해 행동하여 문화와 조직의 균형과 반하는상황이 발생하게 됩니다.

CEO나 리더라면, 그들의 일탈로 인해 성장의 위축,  핵심 인력의 이탈이 발생되는 행태를 그대로 보고 있을 수만은 없습니다.

한비자는 ‘(동업자) 측근을 언제 떠나 보내야 하는가‘라는 문제에 대해 이런 답을 주고 있습니다.

힘든 시기를 같이 겪은 동료이지만
조직을 이끄는 경영자라면 의사결정을 해야 될때가
사적으로는 안타까운 일지만
<군주는 언제 그 측근을 정리해야 하는가 – 한비자>
“賞之譽之不勸, 罰之毁之不畏, 四者加焉不變則其除之”

상지예지불권, 벌지훼지불외, 사자가언불변칙기제지

상을 주고 칭찬을 해줘도 힘쓰려 하지 않고,
  벌을 주고 헐뜯더라도 두려워하지 않으니,
 이 네 가지가 가해지더라도 변하지 않으면 그를 제거해야 한다.
경영자는 한번 생각해 보아야 할 문제라고 생각합니다.