좆타트업 OKR

구글도 페이스북도 OKR로 성공했다고 한다
유니콘, 데카콘은 다 이걸 한다고?
이거 시크릿과 비슷하다고도 할 수 있도?
OKR만 하면 성공하는건가?
한화그룹금융계열과 SK도 OKR을 도입했다고?

유행하던 경영기법이 조금씩 변해왔는데
제조업 중심에서는 식스 시그마
요즘같은 인간 관리와 동기부여가 중요한 시기에 대두되는게
OKR이다

그런데 OKR책을 봐도 기사를 검색 해 봐도
존나 애매한 소리만 가득하다.
이럴거면 KPI에서도 실패를 용인하고 상향식 목표결정을 하면 다를게 없지 않나?

이게 OKR검색하면 또는 책을봐도 제일 많이 나오는 말인데…

목표는 달성 어렵고 가슴 떨리게

그냥 이것만 봐도 우리나라에서 OKR이 얼마나 병신같이 사용될지 가늠할 수 있다.
KPI와 다를게 없겠지

제대로 활용하려면 좀 더 구체적으로 사례를 보는게 낫다

페이스북의 OKR

: A user is engaged if they reach 7 friends in 10 days.
사용자 가입후 연결한다 7명의 친구 10일 이내에

왜 이 목표가 설정되었는가?
이용 통계를 뜯어보니 열흘 안에 페친이 일곱명 이상인 사람들은
페이스북을 안 떠나고 계속 머물렀다

이 OKR를 달성하기 위해서 할 것은?
이걸 각 부서-팀-개인적으로 결정해서 목표를 위해 움직인다

KPI였다면?
이런 느낌의 목표보다는 조금 전사적인 느낌의 목표가 설정된다

기존사용자가 7명의 친구를 초대한다. 기존 100만명 사용자에 추가 700만 800만의 사용자를 확보한다.
그리고 이를 달성하기 위해 사용자 친구초대 이벤트를 시행

추가 다른 회사의 OKR

  • Slack: 2000 messages sent between a team
  • Zynga: User returns 1 day after signing up
  • Facebook: User connects with 10 friends within 7 days
  • Dropbox: One file in one Dropbox folder on one device
  • Twitter: X users followed, Y% followed back
  • LinkedIn: X connections in Y days

OKR 법칙 재정의

  • 사용자에게 보여줘도 당당할 수 있는
  • 데이터에 기반한
  • 핵심적인 가치를 증대시킬 수 있는
  • 고객-직원-회사 모두에게 관련된 목표

이런게 기준이 되야한다고 생각한다

상향식이고 하향식이고는 상관없다고 보고 적절한 목표가 제시되기만 하면 된다
어차피 대부분 사람들은 그런 인사이트가 없다

자칫 KPI스타일의 목표를 세우기 쉬운데 아래같은건 아니라고 본다

  • 글로벌 서비스를 위한 최소 기능을 개발한다
  • 매출 100억을 달성한다
  • 회원 10만을 달성한다

이런KPI스타일의 목표는 달성하기 위해 병신같은 짓을 할 가능성이 높다.
옛날 골드뱅크같은걸 예로들면
회원 100만명을 확보한다 – 이를 위해서 회원1인당 가입리워드를 5000원을 주고 추천할 경우 5000원을 더 준다.
이렇게 하면 회사가??? 망하겠지
물론 그 회원을 이용해서 뭔가를 성공적으로 한다면 망하지 않을수도 있지만
보통은 다 망했다.

너무 개발적인 목표

  • Spring최신버전으로 비동기 MSA 아키텍처를 구현한다
  • Pull Request를 활용한 코드리뷰 시스템을 정착시킨다

개발부서의 서브 목표가 될수도 있겠지만
OKR은 서비스 자체에 집중할 필요가 있다고 생각한다

[개발자가]회사에서 절대 맡으면 안 되는 업무

일반 행정사무직에서 예시

이걸 개발자에 적용 해 보면?

1 쉽지만 중요한거 개발하기

FocusBoard
중요도
긴급도
1사분면을 떼서

파급력 X축
난이도 Y
1사분면 파급력 +, 난이도 + 필수업무
2사분면 파급력 -, 난이도 + 하지마!!!
3사분면 파급력 – , 난이도 – 시간낭비
4사분면 파급력 +, 난이도 – 거저먹기.. 일도 못하는데 인정받는 사람

상호평가가 없는 회사에서는 4번만 주서먹기가 될 것같기는한데… 실력이 안 늘어서 장기적으로는 안되겠지?
1번과 4번의 조화가 좋아보인다
가끔은 3번도.
2번은 회사에서 아예 필요없는 일일 가능성이 높다

2 핵심기능 개발하기

위랑 좀 겹치는 것 같은데

떨거지 모듈 개발하지 말것
예를들어
배달의민족의 개발자라면
(이런게 있는지 없는지 모르지만)
레거시로 남은 php 어드민기능이라던가 이런거 하지 말라는 것
도메인 분야로 보면
로봇배송, 배송관리, 결제, 정산 다 중요하니까 괜찮음

보통 개발자는 PHP는 할 줄 모른다고 하는게 이롭다
PHP전문개발자는 특화분야로 높은 연봉을 받기도 하지만.. 곁다리 PHP개발 경력은 정말 쓸모없고 성가시기만 하다.

3 남들 다 실패해서 퇴사하는 어려운거 하지말기

담당자가 왜 나갈까

남들은 다 병신이라 못했을까

업무가 쉬운데 처리가 안된다면 다 사정이 있다.
연동해야 할 대상이 좆같거나

4 내가 완성할 수 없는거 떠맡지 말기

원래 업무는 조금 어려운 도전적인 정도가 딱 좋은데
신입이나 2~3년차로 들어갔는데 팀장이라고 주고 프로젝트를 떠맡긴다??
바로 퇴사각~
밤새고 같이 고생해서 완성을 할 수도 있긴한건데
대학생도 아니고 ㅋ 잘 하는 사람 하나만 있어도 업무진행이 다르다.

원래 아무것도 모를 때 남한테 배우기가 제일 쉽다. 일정이상 경력이 쌓이면 나보다 잘하는 사람 찾기도 힘들게 되는 경우가 많으니
(부분적으로 서로 가르쳐주고 하지만 다 뛰어난 사람은 없다)

하지만 신입때는 그냥 거의 모든게 나보다 뛰어난 사람이 넘쳐난다
그래서 신입 때 잘 배울 수 있는데루 가라는것…지름길

5 반복 노가다 업무

개발자도 반복업무가 상당히 많은데

무슨 쿼리 뽑아달라던가
이메일 추출해달라던가 하는거

이런건 업무협의를 잘 하거나
시간을 따로 잡아서 개발을 하면
대부분 업무 자체를 없애버릴 수 있다

오브젝트objects, 코드로 이해하는 객체지향 설계

내용이 너무 자바처럼 verbose하다

짧은 내용을 너무 길게 설명해서 지겨워서 볼 수가 없다.

ex) ch07. 객체분해 p216~217 2페이지는 대략 이정도로 표현할 수 있다

일반적으로 작업기억은 7개의 chunk를 가지고 있다. 즉, 한번에 기억할 수 있는 숫자는 7개까지로 아래 11개의 연속된 숫자를 한번에 기억할 수 있는 사람은 드물다

29689928269

하지만 아래처럼 변환하면?

2968-992-8269

한번에 인식 가능하고 외울수도 있다.
11자리 숫자를 한번에 기억했다면 아마도 무의식중에 숫자를 나눴을 가능성이 높다

이런식으로 큰 문제를 작은 문제로 분해decomposite하면 문제를 이해하기 쉽고 더 좋은 해결이 가능하다.

이거 볼 시간에 DDD, JPA를 보자.
그래도 시간이 남으면 매트릭스와 에일리언을 보자