반응형
반응형

일을 더 잘하게 합시다. - reWork withgoogle.com

 

구글에서는 설문을 통해 리더들이 9가지 원칙을 점검하는지 스스로를 되묻게 한대요. 한번씩 읽어볼만 해요.

 

1.     직원들이 성과를 낼 수 있도록 "실행 가능한" 피드백을 주세요.

2.     팀원을 인간답게 배려해주세요.

3.     세세하게 관리하지 마세요.

4.     관점이 달라도 존중해 주세요.

5.     결과를 달성하도록 해주세요

6.     정보사항을 제대로 공유해 주세요

7.     더 나아가, 팀원들의 경력이 쌓일수 있도록 멘토링해주세요

8.     목표치 명확하게 전달해 주세요.

9.    이제 당신은 훌륭한 리더입니다.

 

https://rework.withgoogle.com/

 

re:Work

Let's Make Work Better. Research, ideas, and practices from Google and others, to put people first.

rework.withgoogle.com

일을 더 잘하게 합시다.

re:Work는 사람을 최우선으로 생각하는 데 도움이 되는 Google 및 기타 업체의 사례, 연구 및 아이디어 모음입니다.

re:Work with Google에 대해 자세히 알아보세요. 

 

About re:Work

Let's Make Work Better. Research, ideas, and practices from Google and others, to put people first.

rework.withgoogle.com

시작하다

re:Work는 직장에서 영향력을 미칠 수 있는 방법을 중심으로 구성되어 있습니다. 각 주제에는 특정 과제를 해결하기 위한 도구와 통찰력이 포함되어 있습니다.

  • 목표 설정목표를 설정하여 노력을 조정하고, 목표를 전달하고, 프로세스를 측정합니다.
  • 고용직무 설명, 구조화된 인터뷰, 고용 위원회 등을 통해 더 나은 고용 결정을 내립니다.
  • 혁신혁신을 위한 기술을 구축하고 이를 직장의 일부로 만드는 방법을 배우십시오.
  • 학습 및 개발학습을 모든 사람의 업무의 일부로 만들어 직원이 성장하고 발전할 수 있도록 역량을 강화하십시오.
  • 관리자무엇이 훌륭한 관리자인지 파악하고 피드백과 개발 기회를 제공하십시오.
  • 사람 분석과학과 데이터를 사용하여 정보에 입각한 객관적인 결정을 내립니다.
  • 팀 효율성과 심리적 안전을 촉진하는 방법을 검토합니다.
  • 편향되지 않음모든 사람을 교육하고, 측정하고, 책임을 지도록 함으로써 무의식적 편견의 영향을 줄입니다.

 

반응형
반응형

SSO(Single Sign-On) 구현을 위한 토큰(Token)의 활용

 


ID/PW 로그인
AccessToken / RefreshToken 생성
AccessToken 소멸하면 RefreshToken으로 인증서버에 AccessToken 재요청
RefreshToken 소멸시 재로그인
 * JWT(JSON Web Token)
 * Token은 Base64 Encoding으로 한다. 토큰에 서명(signiture)부분을 추가해서 서명에 비밀키를 사용. 

 

====================================================================

 

SSO(Single Sign-On)는 무엇인가?

SSO(Single Sign-On)은 한 번의(Single) 로그인 인증(Sign-On)으로 여러 개의 서비스를 추가적인 인증 없이 사용할 수 있는 기술이다. 인증은 하나의 시스템(인증 서버)에서 수행하고, 그 인증 서버가 서비스를 각각 담당하는 서버에 인증 정보를 알려주는 방식이다.




주로 다양한 서비스를 유사한 도메인 혹은 동일한 탑 레벨 도메인(TLD:Top Level Domain)을 서비스하는 엔터프라이즈 서비스 제공자들이 사용자에게 간편한 로그인을 제공하기 위해 사용한다.

예를 들면, 이런 흐름이다.
① www.samsung.com에서 로그인을 하면, 인증 서버 account.samsung.com으로 이동한다.
② account.samsung.com에서 로그인을 성공하면 다시 www.samsung.com으로 돌아온다.
③ 삼성의 다른 서비스에 접속하면, 별도의 추가 로그인 없이 이미 로그인된 상태로 서비스를 즐긴다.

같은 맥락으로 Gmail에 Google 계정으로 로그인을 하면, YouTube나 Google Drive는 별도 로그인 없이 Gmail 로그인에 사용한 구글 계정을 동일하게 사용하는 것도 SSO 기술이다.

SSO를 구현하기 위한 기술 요소는?

SSO를 구현하려 한다면 인증 서버를 준비하고, 이를 다양한 서비스들과 어떻게 인증 관련으로 연계할지 설계해야 한다. 인증 서버에서 인증을 성공적으로 마쳤다는 '증거'를 다른 서비스들이 어떻게 믿게 만들 것인지에 대한 기술적 고민도 필요하다.

기업 내 솔루션에서 SSO는 전통적으로는 모든 사용자(직원)의 인증 정보를 담고 있는 AD(Active Directory)이나 LDAP(Lightweight Directory Access Protocol)을 적용한 솔루션들을 많이 사용해왔다.

SSO의 직접적인 구현을 위해서 여러 가지 방법이 있겠지만 이 글은 인증 토큰(authentication token)을 사용한 SSO 방식에 대한 글이다. 여기서 토큰이란, 최초 인증이 성공한 사용자에게 일종의 증표로 인증 서버가 발급하는 정보다.

예전의 웹 개발에서는 로그인에 성공한 사용자는 웹 서버와 Session을 맺고, SessionID 정보를 쿠키로 받아, 그 쿠키를 로그인의 증표로 사용하였다. 모든 요청 헤더에 SessionID 쿠키를 넣고 웹 서버에 접속을 하면, 웹 서버는 서버에 보관한 Session 정보와 비교하여 유효하게 로그인한 사용자임을 확인하고 콘텐츠를 제공하는 방식이었다. 매번 요청마다 서버가 Session 정보를 확인해야 하는 부담, 서버가 Session 정보를 어디엔가(DB 혹은 Redis) 저장해야 하는 번거로움과 복잡한 구현 방식이 단점이라 할 수 있다.

이에 반해 토큰 방식은 Session 방식과 다르게 서버가 각각 로그인한 사용자의 세션 정보를 따로 보관하지 않는다. 한번 인증 토큰이 클라이언트에게 발급하면, 클라이언트는 추후 요청부터는 그 토큰을 포함하고, 서버는 클라이언트 요청에 포함된 토큰을 그때그때 확인할 뿐이다. 현재 Facebook, YouTube를 비롯한 소셜미디어, 포탈, 이커머스 서비스처럼 가입자 기반의 로그인 인증이 필요한 서비스들이 토큰 인증 방식을 많이 사용하고 있다.

초기에는 SSO가 저변화되면서 많은 서비스들이 SSO 상용 서비스에서 제공하는 SAML(Security Assertion Markup Language) 방식을 사용하였다. SAML은 XML 형태의 마크업으로, 간단한 정보 전달을 위해 많은 태그가 사용되는 비효율성이 있다. 그 이후부터는 SSO에서도 토큰을 사용하고 있다.


토큰을 사용한 SSO 서비스 다이어그램 

SSO에서 세션과 토큰을 어떻게 사용하는지 아래 다이어그램으로 이해해보자.



① 사용자는 Service1에 접속하여 로그인 버튼을 클릭한다.
② Service1은 인증 서비스(idP: Identity provider)로 해당 요청을 Redirect 한다.
③ 인증 서비스는 사용자에게 로그인 화면을 제공한다.
④ 사용자는 ID/PW (혹은 OAUTH2.0)을 입력한다.
⑤ 인증 서비스는 회원 DB와 비교하여 ID/PW가 올바르면 인증 토큰을 발급하며 Service1으로 돌려보낸다.
⑥ Service1은 발급된 토큰을 확인하고, 올바른 토큰이라면 사용자의 로그인 처리를 해준다.
⑦ 사용자는 Service2에 접속한다.
⑧ Service2는 이 사용자의 세션이 아직 유효한지 확인하고 유효하다면, Service2 용도의 토큰을 발급한다.
⑨ Service1은 발급된 토큰을 확인하고, 올바른 토큰이라면 사용자의 로그인 처리를 해준다.


여전히 세션이 필요한 이유는 한번 발급된 토큰만 믿을 수없기도 하고, 일반적으로 토큰은 짧은 유효 시간을 갖는데 비해, 서버에는 세션 정보를 오랫동안 보관하고 그 기간 내에 재접속한 사용자를 지원할 수 있기 때문이다.


유효 시간이 만료된 토큰 사용자가 다시 로그인하는 것은 불편하니, 다음과 같은 방법을 사용한다.

- 인증 서버는 ID/PW를 DB에서 확인하고, 정상 로그인이면 AccessToken과 RefreshToken을 발행한다.
- AccessToken은 exp가 짧다. 만료되면 RefreshToken으로 인증 서버에게 AccessToken를 재요청한다.
- RefreshToken은 exp가 상대적으로 길고, 인증 서버의 세션 정보를 포함한다.
- AccessToken 재요청을 받은 인증 서버는 RefreshToken과 세션 정보를 비교 후 재발급해준다.
- RefreshToken 마저 유효 시간이 지나면, 사용자는 다시 ID/PW 로그인을 해야 한다.

한번 로그인했던 Facebook이나 YouTube의 로그인이 상당 기간 필요 없는 것은 위의 방법을 사용하기 때문이다. 브라우저의 쿠키와 temporary internet folder를 삭제하면 모든 토큰은 삭제된다. 때에 따라 AccessToken을 cookie에 저장하고, cookie는 브라우저가 닫히면 삭제되도록 설정할 수도 있다.


토큰에는 어떤 정보가 있고 어떻게 확인하나?

여기에서의 핵심은 토큰이 어떤 정보를 가지고 있고, 각 Service1과 Service2가 유효한 토큰임을 어떻게 확인할 것인지에 대한 디자인이다. 토큰의 종류는 여러 가지이지만 예제에선 JWT(JSON Web Token)을 사용하였다.



① 인증 서버(idP)와 각 Service 서버들은 사전에 비밀키(private key)를 공유한다.
② ID/PW로 정상적인 인증이 확인되면, 인증 서버는 토큰에 이메일, 이름, 유효 시간 등을 입력하여 발급한다.
③ 토큰을 Base64 Encoding 한다. 암호화가 아닌 인코딩이기 때문에 내용은 누구나 알 수 있다.
④ 토큰에 서명(signature) 부분을 추가하여 위 변조를 방지한다. 서명에 비밀키를 사용한다.
⑤ HTTPS 보안 채널로 토큰 확인을 요청한다. 토큰이 유실되더라도 비밀키가 없는 해커는 내용을 변조할 수 없다.
⑥ Service 서버는 비밀키로 토큰 변조 여부를 확인하고, email 등의 사용자 정보 확인 후, 인증 처리를 해준다.

이 방식의 장점은 가벼운 토큰을 사용하여 인증 처리 작업을 하는 서비스들이 부담을 갖지 않는 구조이고, 비밀키 없이는 토큰을 변조하지 못한다는 보안성이다.

단점은 아무리 HTTPS로 토큰을 보낸다고 하더라도, 중간자 공격 등으로 토큰을 훔친 해커는 토큰을 변조하지 않고 그대로 사용한다면, 로그인한 사용자와 동일하게 보일 수 있다는 보안 취약점이다. 그래서 User-Agent 혹은 IP 주소를 확인한다거나, 추가적인 여러 가지 보완책을 마련해야 한다. Naver 서비스의 경우, AccessToken이 유효하더라도 사용자의 IP 주소가 바뀌면 다시 로그인을 하도록 하는 것도 이런 이유 때문이다.


SSO(Single Sign-On) 구현을 위한 토큰(Token)의 활용 : https://brunch.co.kr/@sangjinkang/36

반응형
반응형

NPS의 개념

NPS(Net Promoter Score : 순수 고객 추천 지수) 란?    고객 순추천 지수 프레임워크

  • 추천 의향 문항을 11점(0~10점) 척도로 측정하여 ‘추천고객 비율(Promoters %)’에서 ‘비추천고객 비율(Detractors %)’을 빼서 NPS를 산출합니다. 
  • 당신은 A 제품/서비스를 친구나 동료에게 추천할 의사가 있습니까?’ 라는 질문이 기본
  • ‘추천 의향’이라는 단 하나의 문항으로 고객의 서비스 로열티를 측정
  • 이론적으로 점수 범위는 -100점부터 +100점까지
  • 선택적으로 ‘해당 점수를 선택한 이유’를 묻는 문항을 추가하기도 함

NPS는 ‘추천 의향’이란 질문 단 하나로 고객의 실제 만족도를 파악할 수 있습니다. 문항이 짧아 고객으로부터 답변을 받기도 용이하며, 문항과 척도가 동일하기 때문에 경쟁사 및 업계 평균을 비교하여 자사의 현재 입지를 쉽게 파악할 수 있습니다. 이렇게 보니 NPS를 도입하는 장점이 한가득이죠? 게다가 NPS는 많은 기업이 채택하면 채택할수록 내가 얻는 업계 평균 서비스 만족도 정보도 많아지니 얼른 주변에도 널리 알려주세요.

 

NPS의 3가지 고객 유형

NPS에서는 앞서 잠깐 언급한 것처럼 고객군을 3가지 유형으로 나눕니다. Promoters / Passives / Detractors 입니다. 3개로 나누어지는 고객군을 기반으로 NPS 결과를 분석합니다. 

1. 추천 고객 (Promoters) :
– 9~10점을 준 고객.
– 자신의 만족을 주변에 적극적으로 퍼뜨리는 고객으로 구전 마케팅(Viral Marketing) 효과는 덤 (아싸!)
– 비추천고객보다 더 많이! 더 자주! 구매하는 고객 
– 제품/서비스에 충성도(loyalty)가 높은 고객

2. 중립 고객 (Passives) :
– 7~8점을 준 고객
– 겉으론 ‘만족해요~’라고 말하면서 불만을 감추려는 고객
– 따라서 중립 고객군이 2~3점을 깎아낸 이유를 파악하여 적극적으로 불만을 끌어내는 것이 중요
– 적극적으로 제품/서비스 홍보를 하지 않는 중립적인 고객

3. 비추천 고객 (Detractors) :
– 0~6점을 준 고객
– 언제라도 선택을 바꿀 수 있는 고객
– 친구 혹은 동료에게 제품 및 서비스 사용에 대해 부정적인 피드백을 주는 고객
– 충성도가 낮은 고객

 

 

 

https://blog.jandi.com/ko/2018/11/07/what_is_nps/

 

서비스 성과 지표로 고민중이세요? ① NPS 개념알기 - 업무용 협업툴 JANDI 블로그

잔디 CX 팀은 Customer Experience 라는 팀 이름에 걸맞게 '사용자들이 잔디를 추천하는 지수'인 'NPS (Net Promoter Score)'를 저희 팀 만의 서비스 성과 지표로 삼고 있습니다. 우리 서비스 성과 지표로 고민

blog.jandi.com

 

반응형
반응형

KubeSphere DevOps: A Powerful CI/CD Platform Built on Top of Kubernetes for DevOps-oriented Teams.

https://kubesphere.io/devops/

 

DevOps With Kubernetes And KubeSphere

KubeSphere DevOps offers powerful CI/CD features with excellent scalability and observability on top of Kubernetes for DevOps-oriented teams.

kubesphere.io

 

반응형
반응형

좋은 동료가 되기 위한 10가지 방법

제가 수구를 처음 배울 때에, 코치가 해줬던 말이 잊혀지지 않습니다. 그는 “뛰어난 선수는 주변 선수들을 뛰어난 선수처럼 보이게 한다.” 라고 했습니다. 뛰어난 선수는 잘못된 던지기를 예상하고 미리 움직여 어떤 패스라도 잡을 수 있습니다. 뛰어난 선수가 공을 다시 패스할 때는 다른 사람이 쉽게 잡을 수 있도록 공을 던집니다.

 

오늘날의 소프트웨어 개발은 팀 스포츠와 같습니다. 수구에서와 같이 뛰어난 소프트웨어 시스템은 혼자서 만들 수 없습니다. 그래서 처음 10배 뛰어난 엔지니어에 대한 컨셉을 들었을 때는 혼란스러웠습니다. 어떻게 한 명의 뛰어난 사람이 팀웍을 이길 수 있을까? 제 경험상 성공을 위해 각 개인의 뛰어남은 필수 요소지만, 충분 요소는 아니었습니다. 개개인의 업적에 초점을 맞추면 좋은 소프트웨어 개발을 위해 팀이 필요하다는 큰 그림을 못 보게 됩니다. 그래서 10배 뛰어난 엔지니어에 대한 정의를 이렇게 바꿔봤습니다.

10배 뛰어난 엔지니어는 남들보다 10배 뛰어난 사람이 아니라, 주변 사람을 10배 뛰어나게 만드는 사람이다.

 

수 년에 걸친 개인적인 경험과 효율적인 팀 구성과 발전에 대한 연구를 조합하여, 개개인의 경험과 무관하게 10배 나은 동료가 될 수 있는 방법을 목록으로 만들었습니다. 훌륭한 동료가 되기 위한 일반적인 조언들과 함께, 다양한 배경을 가진 사람들 속에서 어떻게 좋은 동료가 될 수 있는가에 중점을 두었습니다.

 

더 나은 동료가 되기 위한 10가지 방법

 

  • 정서적으로 안전한 환경 만들기
  • 모두 동등하게 참여하도록 격려하기
  • 공명정대하게 공로 나누기
  • 회의에서 들리지 않는 목소리를 키우기
  • 개인적인 비판이 아닌 건설적이고 실용적인 피드백
  • 자기 자신과 타인에게 책임감 가지기
  • 팀에 가치있는 분야에 투자하기
  • 직장내 다양성, 포괄성 그리고 동등함에 대해 배우기
  • 성장에 대한 마음가짐 유지하기
  • 직장내 평등에 대한 회사 정책에 소리내기

 

1. 정서적으로 안전한 환경 만들기

 

2012년, 구글은 아리스토텔레스 프로젝트를 시작했습니다. 이는 구글 내의 많은 팀을 조사하여 몇몇 팀들이 왜 다른 팀보다 좋은 성과를 내는지 분석하는 프로젝트입니다 1. 이 연구는 팀의 생산성이 높고 낮음에 오직 두 가지 차이점만이 있음을 밝혀냈습니다. 그 중 하나는 연구자들이 정서적 안전함이라 부르는 요소였습니다. 하버드 비즈니스 스쿨의 Amy Edmondson 교수는 이것을 “팀내에서 대인 관계의 위험 감수를 할 필요가 없다는 구성원 사이에 공유되는 믿음” 즉, “발언에 대해 치욕스럽게 하거나, 거부하거나 처벌하지 않을 것이라는 확신” 이라고 설명합니다. 정서적 안전함을 갖춘 환경을 조성하는 것은 팀원들이 서로를 신뢰하고 업무에 대해 자유롭게 의견을 나눌 수 있는 공간을 만듭니다. 사무실에서 정서적으로 안전한 환경을 조성하는 몇 가지 방법이 있습니다.

  •  
  • 비판적이지 않은 방법으로 다른 사람의 아이디어와 감정을 인정해주세요. 인정은 판단하거나 평가내리는 것에서 분리되어야 합니다.
  • 팀 동료의 의견에 “응, 그리고” 같은 자세로 답해 대화를 이어나가 주세요 (즉흥 연기와 같이 말이죠!) 2.
  • 의심스러워도, 믿어주세요. 당신이 믿을 때까지 그들로 하여금 증명하도록 하지 말고, 틀렸다고 밝혀지기 전까지는 일단 동료를 믿어주세요.

 

2. 모두 동등하게 참여하도록 격려하기

 

아리스토텔레스 프로젝트에서 밝혀낸 생산적인 팀을 구성하는 두 번째 요소는 – 학술적으로 말하자면 – ‘균등 분배된 발언권’ 현상입니다. 기본적으로, 효율적인 팀에 속한 사람들은 동등하게 참여한다는 뜻입니다. 모든 구성원이 매 회의마다 동등하게 말해야한다는 것을 의미하는게 아니라, 시간이 지남에 따라 팀원 개개인이 동등하게 기여해야 한다는 것입니다. 그렇다면 팀원 개개인이 동등하게 기여하는 팀 문화를 어떻게 조성할 수 있을까요?

  •  
  • 회의시간에 동료에게 의견을 물어보세요.
  • “내 생각엔” 그리고 “아마도” 같은 표현으로 토론을 시작해보세요. (저는 이것을 ‘여성스럽게 말하면 어떨까?’ 화법으로 부릅니다)
  • 편하게 자주 얘기하세요 3.
  • 혼자 떠들고 있는 사람이 있으면 알려주고, 모두가 말할 수 있는 분위기를 만들어주세요.

 

3. 공명정대하게 공로 나누기

 

업무에 대한 공로를 정확하게 분배하는 것은 팀과 조직 내에 신뢰를 형성하는데 매우 중요한 일입니다 4. 우리들 중 많은 이들이 자신의 작업에 대해 제대로 인정받지 못하거나, 엉뚱한 사람이 공을 가져간 경험이 있을겁니다.

공로를 인정하는 일은 그 사람을 뛰어나 보이게 만드는 것뿐 아니라, 인정하는 사람도 같이 좋아보이게 합니다. 다른 사람들을 인정하는 사람들은 그렇지 않은 사람이 비해 더 똑똑해 보이고 호감이 갑니다. 서로 윈–윈 하는 일이기 때문에 동료를 칭찬하지 않을 이유가 없습니다.

다른 사람의 공로를 인정하는 문화를 만들기 위해서는 어떤 노력이 필요할까요?

 

  • 프로젝트가 끝날때 마다 당신을 도와준 사람들에게 감사를 전하세요.
  • 묵묵히 일을 하고 자랑하지 않는 사람들, 새로 들어와서 아직 자신이 없는 사람들에게 특히 주목하세요.
  • 누군가를 칭찬하고 공로를 인정할 때, 정직하고 구체적이며 진실되게 전하세요.

 

4. 회의에서 들리지 않는 목소리를 키우기

 

 

2009년, 오바마 대통령의 여성 스태프 그룹이 함께 ‘증폭’이라는 전략을 만들었습니다 5. 그들은 남성 중심적인 사무 환경에서 여성들이 겪는 여러 어려움에 직면해 있었습니다. 여성들이 중요한 회의에 참석하는 동안 그들은 간과되거나 소외되는 문제가 있었습니다. 그래서 그들은 목소리를 서로 증폭하기로 했습니다. 여성 스태프가 핵심 아이디어를 만들면 다른 여성들이 그것을 반복하고 계속해서 원 저자를 알려, 그 아이디어가 누구에게서 나온 것인지 알아차릴 수 밖에 없도록 합니다. 오바마 대통령은 이 사실을 알고, 여성 스태프들에 더 많은 기회를 주도록 했습니다. 그의 두 번째 임기에는 성별이 더 동등하게 나뉘었으며, 부서 중 절반은 여성이 이끌게 되었습니다.

이 일은 매우 단순하지만, 누구나 동료를 위해 할 수 있는 시행할 수 있는 구체적인 방법입니다. 소외되거나 간과되는 사람에게 귀기울여, 그들의 목소리를 증폭시켜주세요. 여성들이 자주 말하게 되는 것이 일상이 되어도 6, 부드럽게 말하거나 수줍어 하는 사람, 내성적인 사람에게도 일어날 수 있는 일입니다.

 

5. 개인적인 비판이 아닌 건설적이고 실용적인 피드백

 

 

비판받는 것을 싫어하는 것은 매우 일반적인 일이고, 신중하지 못하거나 건설적이지 않은 비판은 사람들의 생산성마저 깎아내릴 수 있습니다 7. 앞서 얘기했던 것과 같이 당신의 피드백이 사려깊고 건설적인지 아닌지가 좋은 동료가 되는데 있어 정말로 중요합니다. 뿐만 아니라, 피드백은 편향을 불러올 수 있으므로, 피드백을 잘 전달하는 것에 대한 학습은 다양한 팀에게 있어 아무리 시간을 들여도 아깝지 않은 일입니다.

예를 들면, 여성들이 받는 비난이나 조롱을 남성들은 받지 않는다는 것은 누구나 알고 있습니다. 여성들은 ‘된장녀’, ‘뻔뻔한’, ‘공격적’ 같은 이야기를 남성에 비해 많이 듣습니다. 2014년에 Textio의 설립자이자 CEO인 Kieran Snyder는 이 일이 사실인지 확인하고자 했습니다 8. 남성 105명과 여성 75명, 총 180명으로부터 248개의 리뷰를 수집하고 내용을 분석했습니다. 그게 사실이라는 것을 이미 알고 있음에도 놀라울만한 결과가 나왔습니다. 87.9%의 여성이 조롱이나 부정적인 피드백을 받았는데, 남성의 경우 58.9%에 불과했습니다. 내용을 따지고 보면 이 차이는 더 심해집니다. 76%의 여성이 업무 외의 개인적인 부분에서 비난을 받는 동안 2%의 남성만이 그러한 비난을 받았습니다.

더 나은 피드백을 주기 위한 다음의 방법을 제안합니다.

 

  • 피드백을 받을 수 있는 상황인지 먼저 물어보세요.
  • 그 사람의 업무적인 부분에만 초점을 두고 피드백하세요.
  • 어떻게 하면 더 개선할 수 있는지 얘기해주세요. 문제를 명확하게 하고 어떻게 하면 대상자가 개선할 수 있는지에 대한 생각을 얘기하세요.
  • 개인적인 비난은 하지 마세요. 그런 부분에 대한 피드백이 정말 필요하다고 생각한다면, 관리자나 HR 담당자와 얘기하여 내용을 정리하고 검토하세요.

 

6. 자기 자신과 타인에게 책임감 가지기

 

얼마 전에 대학시절 축구 선수로 활동했던 친구 James를 만났습니다. 그는 지금 한 스타트업의 COO로 있는데, 그가 말하길 많은 시간을 직원들에게 기본적인 팀웍에 해당하는 것을 가르치는데 쓴다고 합니다. 책임감에 관한 것에 중점을 두고요. 예전 일을 생각해보면, James는 수백 수천 시간을 좋은 팀원이 되기 위해 연습하는데 썼습니다. 팀으로 잘 굴러가기 위한 일들이 그에게는 명확하게 보이겠지만, 다른 사람들에게는 – 특히 책임감에 관해서라면 – 명확하지 않을 수 있습니다. 축구는 강한 책임감이 필요한 운동이고, 선수들에게 서로 책임을 지게하기 위해서는 시간을 들여 연습하는 것 외에 긍정적인 태도, 팀원을 독려하는 일, 그리고 유능함에 대한 높은 기준을 유지하는 방법이 있습니다. 자기 자신과 동료 모두가 책임감을 높이기 위해서는 이런 방법을 사용해보세요.

  •  
  • 일을 가능한한 제 시간안에 할 수 있도록 합니다 (엔지니어들에게 이게 참 어려운 일인건 알지만, 작은 프로젝트부터 정확성을 높여 나간다면 책임감 향상에 도움이 될겁니다).
  • Jeff Lawson이 창업자들에게 가장 중요하다고 말하는 것은 “한다고 말했던 일을 해라” 입니다. (역주: Jeff Lawson은 Twilio의 창업자)
  • 다른 사람을 돕다 보면, 다른 사람에게 도움을 구하기도 합니다.
  • 큰 프로젝트나 이슈에 대해서 팀의 일이 끝날 때까지 함께합니다 9 (실제로 남아도 좋고, Slack 같은 원격 도구라도 좋습니다).

 

7. 팀에 가치있는 분야에 투자하기

 

10배 뛰어난 엔지니어 되기에 대해 얘기하면 사람들은 흔히 다른 사람보다 뛰어난 것으로 받아들입니다. 개인적인 역량이 뛰어난 것은 좋은 동료가 되기에 필수 요소일 뿐이고, 결국 팀을 위해서 뭔가 해야합니다. 어떤 분야에 뛰어난 사람이 되려고 한다면, 그 분야는 당신에게 진정한 동기부여가 가능한 것이어야 합니다. 당신에게 에너지를 주는 일이면서 동시에 현재 보유한 능력과 관심사와도 맞아야겠죠. 개인 지식 기반이 점점 더 전문화되고 있기 때문에, 뛰어난 사람이 되기 위해서는 정말 많은 시간과 에너지를 투자해야 합니다 10. 잠깐으로 되는 일이 아니기 때문에 진정 즐길 수 있는 일이어야 합니다. 자기 계발/개발에 대한 이 사회의 관심이 큰 것으로 알고 있으니, 해당 분야에 대해서는 도서나 블로그 등을 통해 발전시키는 것도 좋겠습니다.

 

8. 직장내 다양성, 포괄성 그리고 동등함에 대해 배우기

 

다양성과 포괄성은 팀 스포츠와 같이, 모든 직급의 모든 사람이 함께 해야합니다. 좋은 동료가 되기 위한 최고의 방법 중 하나는 성차별과 인종 차별이 직장에서 어떻게 이뤄지고 있는지 스스로 학습하는 것입니다. 프로그래밍 언어와 툴 사용법을 익히는 것만큼이나 평등한 작업 환경을 구성하는 것에 대한 글과 연구에 관심을 가지고 따라잡는 일도 중요합니다.

“깨우친 남성의 뒤에는 항상 페미니스트가 있다”라는 농담이 있는데, 아마 깨우친 백인들도 유색 인종들이 받은 핍박 속에서 태어났을 겁니다. 이제 바꿉시다. 누구나 읽고 연구할 수 있는 시대입니다.

 

  • 모든 것을 읽으세요.
  • 사람들에게 읽기를 권유하거나 메일링 리스트에 가입하라 하세요.
  • 최대한 많이 들으세요.
  • 당신의 의견은 교육받은 만큼 그 가치가 올라갑니다. 그러니 스스로 깨우치지 못하면 당신의 의견은 별 의미가 없습니다.

 

9. 성장에 대한 마음가짐 유지하기

 

30년 전에, 심리학자 Carol Dweck은 실패로부터의 추진력에 관심을 가졌습니다 11. 그녀와 그녀의 연구팀은 학생들이 작은 실수로도 무너지는 반면, 실패로부터 회복하는 학생들도 있음을 알게되었습니다. 그 이유가 궁금했습니다. 수 천명의 아이들을 연구한 결과, ‘성장하고자 하는 마음가짐’이라는 용어를 얻어냈습니다. 이는 능력과 지능을 발전시킬 수 있다는 믿음을 의미합니다. 이런 마음가짐이 있는 학생들은 실패에서도 배워 능력과 지능을 키울수 있다는 믿음이 있는데, 지능은 발전되지 않는다고 믿는 학생들이 작은 실수로도 무너지는 것과 비교가 됩니다.

 

  • 주어진 시간과 노력, 인터넷으로 무엇이든 배울수 있음을 명심하세요.
  • 어떻게 발전할 수 있었는가에 대한 피드백을 준비하세요.
  • 결승선이 없는 일입니다. 좋은 엔지니어와 동료가 되는 것은 평생, 매일의 수련입니다.

 

10. 직장내 평등에 대한 회사 정책에 소리내기

 

마지막으로, 팀의 모든 동료를 위해 더 평등하고 포괄적인 업무 환경을 조성할 수 있다고 생각하는 것을 얘기하세요. 조직 내에서 어떤 위치에 있더라도 작업 환경을 개선하는 정책에 대해서는 지지할 수 있습니다. 8번에서 얘기한 것들을 읽고 연구한다면 더 쉽게 진행할 수 있습니다. 검증된 조직적인 변화의 예를 몇 가지 들어보겠습니다.

  •  
  •  
  • The Rooney Rule: 중요한 직책을 채용할 때, 소수 인종을 반드시 한 명 이상 후보에 넣어야 합니다 12.
  • 승진 대상 후보자 평가는 혼자가 아닌 단체로 해야합니다. 13
  • 회의, 급여, 계획과 같은 내부 절차의 투명성을 만들어가야 합니다.

 

맺음말

 

수구 선수 생활을 그만둔 뒤에 코치 생활을 시작했고, 가르쳤던 아이들에게 항상 얘기했던 하나는 이것입니다. 승률은 개인의 재능 합에 팀으로 얼마나 잘하는가를 곱한 것이라고요.

승률 = Σ(재능) * 팀웍

 

일하는 것에 적용한다면, 수식은 이렇게 됩니다.

생산성 = Σ(재능) * 팀웍


팀웍이 강한 팀은 개개인의 능력이 더 뛰어난 팀보다 더 뛰어날 수 있습니다. 이런 일들을 스포츠와 기술업계, 사회에서 수도 없이 보아왔습니다. 소규모 팀이라도 팀으로써 잘 기능할 때, 엄청난 소프트웨어를 만들어내는 일은 결코 우연이 아닙니다. 자, 그러니 개인적으로 우수해지는 것 외에, 제 코치가 저에게 말해준 것처럼, 진정한 뛰어남은 당신이 얼마나 대단한 사람이냐가 아니라 당신 주변을 얼마나 대단하게 만드느냐에서 온다는 것을 잊지 않길 바랍니다.

 

 

 

 

 

 

https://www.kateheddleston.com/blog/becoming-a-10x-developer

 

Becoming a 10x Developer

When I was first learning to play water polo, a coach told me something I’ve never forgotten. He said, “Great players make everyone around them look like great players.” A great player can catch any pass, anticipating imperfect throws and getting int

www.kateheddleston.com

 

반응형
반응형

Pizza As A Service 2.0 By Paul Kerrison

https://www.ami.com/tech-blog/pizza-as-a-service-20-by-paul-kerrison/

 

Pizza as a Service 2.0 by Paul Kerrison

Pizza as a Service 2.0 by Paul Kerrison Recently I was trying to describe the various types of cloud services available for modern IT deployment. Like

www.ami.com

Now for the justifications…

  • On-Premises – like a homemade pizza, made from scratch, you do everything yourself (no change so far). Example: Datacentre
  • Infrastructure as a Service – You share a kitchen with others. The utilities and oven are provided, but you make and cook the pizza yourself. Example: EC2
  • Containers as a Service – You bring the pizzas but someone else uses their facilities and cooks the pizza for you. Example: ECS
  • Platform as a Service – You order a pizza for collection, the pizzeria make and cook the pizza using their facilities. Example: App Engine
  • Function as a Service – You go to a pizzeria with some friends. You order and then eat pizza made by the restuarant. You order drinks from the bar and they’re made for you. Example: AWS Lambda
  • Software as a Service – You go to someone’s house for a party, they provide the pizza and invite others round for you to meet. Conversation with the guests is still your responsibility! Example: Gmail

For the more technically minded, I’ve added the levels of abstraction at the side so you can see what I was thinking from an actual implementation point of view. The one that’s probably slightly contentious is the scaling level. I was trying to use this to highlight the difference between PaaS and Faas ie with PaaS you still have to worry about how to manage scaling Eg how many dynos (Heroku) do you want to run.

반응형

+ Recent posts