어제 일도 기억하지 못하는데...

개발자들은 동서고금을 막론하고 대부분이 문서화를 싫어하는 경향이 있다. 문서화는 시간이 많이 걸린다고 생각하고 기껏 정리를 해 놔도 남들이 잘 이해하지 못하기 때문이다.

이 생각에 동의한다면 문서화 자체를 완전히 잘못 생각하고 있는 것이다. 문서화를 지금 개발하고 있는 것을 기록해서 나중에 다른 사람들이 활용할 수 있게 한다는 추가적인 작업으로 생각하고 있을 가능성이 높다.

문서화에 대한 생각을 완전히 바꿔보자.

대부분의 개발자들은 기억력이 매우 좋다고 생각하지만 의외로 그렇지 않다. 특정 부분에 있어서 뛰어난 기억력을 발휘하는 경우는 있다.

갑자기 머리에서 번뜩인 아이디어를 10초안에 정리하지 않으면 영원히 사라져 버리는 경우는 흔하다. 하물며 수많은 내가 하고 있는 해야 하는 일들은 시간이 흐르면 내 머리 속에서도 사라져 버린다. 이런 것들을 사라지기 전에 기록한다고 생각하자. 그러려면 특정 형식에 얽매이지 않고 어디서나 기록을 할 수 있 툴들이 필요하다.

간단한 메모장에서 부터 스마트폰과 연동하는 노트 앱이나 클라우드에 저장하는 메모 앱들도 있다. 마인드맵을 이용하는 방법도 있다. 용도에 따라서 다양한 방법들은 각자 구미에 맞는 것들을 선택하면 된다.

이렇게 항상 메모하는 습관을 가지고 있으면 의외로 엄청난 변화를 경험하게 된다. 머리 속에만 있던 생각이 글자로 적히게 되면 점점 발전되어서 머리속 가지고 있을 때보다 가치있게 된다. 또한 다른 사람들과 공유가 가능하고 다른 사람들의 생각과 합쳐서 더 좋은 아이디어로 발전하기도 한다.

이런 메모 습관은 글을 작성하는 것에 대한 거부감을 줄여나가고 개발문서 작성할 때도 도움을 주게 된다. 

나는 오랫동안 메모를 해 왔다. 

아주 오래 전에는 작은 수첩에 메모를 하는 것이 가장 효율적이었다. 그 때는 이를 다시 정리하는 시간이 필요해서 꽤 불편했었다. 하지만 이제는 너무나 좋은 툴들이 너무나 많아서 좋은 것을 선택하는 것이 오히려 어려울 정도다.

과거 OneNote를 사용한 적도 있지만 이제는 Evernote를 이용하고 있다. Evernote는 그동안 메모를 하면서 생각하고 있던 요구사항을 거의 모두 만족한다. 물론 이것 외에도 좋은 툴들이 많으니 입맛에 맞는 것을 선택하면 된다.

우선 아이폰을 이용해서 "텍스트", "음성", "카메라" 메모를 모두 쉽게 남길 수 있다. 이렇게 남긴 메모는 아이폰, 맥, PC에서 모두 접근 할 수 있고 편집할 수 있다. 게다가 무료이다. (유료서비스도 있음)

신기한 기능 중에 하나는 "카메라"로 촬영한 이미지 안의 "텍스트"도 검색이 되는 것이다.

설계 회의를 하다가 화이트보드에 그려 놓은 그림을 사진을 찍어 놓으면 내용을 검색할 수 있는 것이다.

여기에는 거의 모든 내용을 항상 기록한다. 길을 가다가 생각난 모든 것을 기록한다. 스펙을 작성할 때도 이렇게 모인 자료들이 많이 활용된다.

문서화를 남을 위한다고 생각하지 말고 자신이 일을 할 때 자신을 위해서 항상 기록한다고 생각하면 문서화 실력도 조금씩 더 향상될 것이다. 다시 한번 생각하자. 남을 위한 것이 아님을.

A/B는 뭘까?

A/B는 무슨 뜻일까?

A and B일까?

A or B일까?

A와 B가 같다는 뜻일까?

B가 A를 대체할 수 있다는 뜻일까?

스펙(SRS)를 적다보면 의외로 정확하게 적는 습관이 없다는 것을 알게 되다. 하지만 이러한 모호함은 소프트웨어를 개발하는데 큰 방해가 되고 비싼 댓가를 치를 수도 있다.

적는 사람은 당연하다고 적은 것들이 이것을 읽는 사람은 헷갈릴 수 있습니다. 따라서 괜히 몇바이트 절약하기 위해서 애매한 축약을 할 필요가 없다.

OS가 맞을까? O/S가 맞을까?

SW가 맞을까? S/W가 맞을까?

NW가 맞을까? N/W가 맞을까?

"전후"를 써야하나? "전/후"를 써야 하나?

rw와 r/w의 차이를 구분할 수 있나?

MS와 M/S의 차이는? 이것은 Market share일까? Microsoft일까?

이것을 가지고 고민할 필요는 없다. 일단 애매할 수 있다면 풀어쓰는 것이 좋다. 

정답이 있다고 하더라도 누군가가 헷갈려하는 사람이 있다면 그 자체가 문제이다.

그럼 MM과 M/M 중 어떤 것이 맞을까? (Man-Month의 단위로 인력 투입량을 뜻함)

이는 Man x Month를 뜻하는 것으로 MM이 맞다. 하지만 M/M을 쓰는 사람들이 의외로 많다. Man x Month와 Man/Month는 완전히 다른 단위이므로 앞으로 틀린 단위는 사용하지 않는 것이 좋겠다.

스펙문서(SRS)뿐만 아니라 소프트웨어 개발자라면 문서를 작성할 때 항상 정확하고 읽는 사람들이 헷갈리지 않다록 작성하는 습관을 들여야 한다.

내가 소스코드를 몰래 고치는 이유

여러 소프트웨어 회사를 분석해보면 소스코드를 공유하는 정도에서 정말 많은 차이가 난다.

여기서 소프트웨어 회사란 소프트웨어를 개발하고 있는 회사로서 흔히 얘기하는 팩키지 소프트웨어 회사가 아니다.

SI회사, 가전회사, 산업로봇회사, 반도체장비회사, 인터넷회사, 게임회사, 금융회사 등의 다양한 회사를 모두 말한다.

이들 회사 중에서는 개발자가 소스코드를 몰래 고치고 공유도 하지 않는 회사들이 의외로 많다.

개발자가 소스코드를 몰래 고치는 이유에는 이건 것들이 있다.

내 소스코드는 나만 알아야 회사에서 나의 파워가 유지된다.

일부 일리가 있는 이론이다. 내가 없으면 내가 작성한 소스코드를 이해하지도 고치지도 못하면 나는 절대로 짤릴 수가 없다. 문제가 있을 때마다 나에게 달려와서 이것 좀 고쳐달라고 하면 내가 좀 대단한 사람이 된 것 같은 생각도 든다. (이전에 블로그에 포스트한 글 참고)

2009/04/28 - [사람과 기술] - 과거의 개발자 vs. 미래의 개발자

실제로 실력이 있는 개발자들이 이런 행동을 하기도 한다. 하지만 이런 행동은 본인의 성장에 방해가 된다. 더 어렵고 가치있는 해야 할 사람이 과거의 소스코드에 발목잡혀서 휴가도 마음대로 못가게 된다. 개발자의 파워 및 가치는 과거에 있는 것이 아니고 미래에 회사에 필요한 가치에 있다는 것을 알아야 한다. 그것이 회사와 개발자의 상생의 기초이다.

내가 작성한 소스코드의 품질이 형편없어서 보여주기 창피하다.

어떤 천재 개발자도 공유하지 않고 혼자 개발을 해서는 좋은 코드를 작성하기 어렵다. 꾸준히 공유를 하면서 다른 사람들과 의견 교환을 통해서 점점 나아진다. 혼자 개발한 코드는 이상한 코드로 가득차 있기 마련이다. 

세 사람이 걸어가면 그 중에는 꼭 스승이 있듯이 신입사원과 코드 리뷰를 해도 배울 것이 나오게 된다.

소스코드를 보여주는 것을 창피해 할 것이 아니라 자꾸 보여주고 교류를 해야 나아진다.

엄청 어려운 것을 개발하고 있는 것처럼 행동했는데 소스코드를 보면 별 것 아니라는 것이 들통날 것 같다.

종종 접하는 문제다. 심지어는 오픈소스코드를 가져다가 동료들에게는 자기가 개발한 것 같이 자랑하는 경우도 있다. 이것은 회사입장에서 더 큰 문제가 될 수도 있다. 오픈소스 라이센스 규정을 어겨서 소송을 당할 수도 있다.

스펙을 적절하게 작성하고 설계를 하는 과정들에서 서로 리뷰를 적절하게 한다면 서로 어떤 컴포넌트를 어떤 Technology를 이용해서 개발하는지 다들 알게 된다. 어떤 것은 어렵고 어떤 모듈은 신입사원이 구현해도 될 만큼 쉬운 것인지 모두 알게 된다. 

SRS를 제대로 작성하게 된다면 모든 프로젝트 관련자가 프로젝트가 어떻게 구성되어 있고 어떻게 진행되고 있는지 훤히 할게 된다.

너무 바빠서 공유할 시간도 없다.

이미 불끄기 모드로 들어간 회사는 단기적인 해결책이 없다. 이런 회사에서는 서로 자기일 하기 바빠서 점점 서로 더 단절되게 된다. 또 다시 악순환이 진행된다.

2011/01/03 - [개발문화] - 매일 불난 호떡집 같은 회사 (중요한 일 vs. 시급한 일)

시간이 좀 걸리겠지만 악순환의 고리를 끊어야 한다.

공유를 해봤자 관심도 없다. 다들 바쁜데...

공유문화가 정착되지 않은 회사이다. 이런 회사에서 코드리뷰는 별 의미도 없다. 

시도를 해봤자 시간 낭비일 것이다. 내용을 모르는데 코드리뷰를 해도 기껏해야 Syntax 검사밖에 못할 것이다.

SRS리뷰를 먼저 시작하는 것이 좋다. SRS가 리뷰를 해야 할 것도 더 많고 SRS가 제대로 작성되어야 다음 단계인 설계, 구현이 제대로 진행되며 리뷰를 해도 내용을 알고 리뷰를 할 수 있게 된다.

이렇게 되면 "바쁜데..."라는 핑계가 조금씩 줄어들만큼 시간을 절약할 수 있게 된다.

결론

개발자가 작성하는 모든 소스코드는 기록이 남아야 하고 남게 된다. 물론 분석, 설계도 마찬가지이다.

Baseline에 포함되는 소스코드와 문서들은 소스코드 관리시스템에 들어갈 때 설명을 적절하고 충실하게 달아야 한다. 이때 이 소스코드를 누가 리뷰했는지 기록을 남기기를 권장한다. 리뷰를 했다는 의미는 소스코드 작성자와 같이 이 소스코드에 대해서 공동책임을 진다는 의미이기도 하다. 이것이 부담스러워서 리뷰를 하지 않는다면 아무도 리뷰를 하지 않을 것이다. 서로 리뷰를 해주는 것은 모두에게 도움이 되는 것이다. 이것은 규칙으로 강요를 해서는 효과가 없고 분위기가 조성되어서 오랫동안 시행을 하여 문화로 자리를 잡아야 한다.

소스코드관리시스템에 소스코드를 올릴때는 버그ID(이슈ID)가 꼭 있어야 한다. 개발자가 원한다고 아무때나 마음대로 소스코드를 고치면 안된다. 개발자가 스스로 발견한 버그를 고칠 때도 버그관리시스템에 등록을 하고 고쳐야 한다.

이렇게 개발자가 생성한 모든 소스코드는 투명하게 모두가 볼 수 있게 한다면 이 혜택은 회사 뿐만 아니라 모든 개발자 그리고 본인에게도 돌아한다.

이번 프로젝트 내일 끝나?

SW개발 프로젝트가 언제 끝날지 정확하게 모르는 경우가 허다하다.

프로젝트를 진행하고 있는 개발자나 PM도 이 프로젝트가 언제 끝날지 전혀 감이 안잡히는 경우가 많다. 

하지만 분명한 것은 이 프로젝트가 예정된 종료일까지는 끝나지 않을 것이라는 것은 아주 잘 알고 있다.

이것을 알고 있다면 일정을 연기해야 하는데 언제로 연기를 해야 하는지 알 수 없으니 일정 연기를 요청하기도 어렵다. 일정을 연기 했으면 그 일정은 지켜야 하는데 연기된 일정도 전혀 근거가 없이 그냥 감으로 생각한 일정이기 때문이다. 이런 일정은 또 연기되기 마련이다.

그래서 Due date이 되어서어 끝나지 않음을 알고 일정 연기를 요청하고 한다. 이렇게 촉박하게 일정이 자주 연기가 되면 영업이나 마케팅 부서에서는 도저히 개발팀의 일정을 믿을 수 없어서 자신있게 비즈니스를 하기 어려워진다.

그럼에도 일정이 늦어지고 있는 것을 늦게 알려주는 이유는 미리 얘기를 해봤자 일찍 혼나기 밖에 더하겠냐는 생각때문이기도 하다. 일정이 촉박해지면서 매일 야근을 하면서 열심히 하는 모습을 보여주면 일정을 연기해도 큰게 혼나지 않을 것이라고 생각하곤한다. 

하지만, 경영자 입장에서는 밤새면서 일정 못지키는 프로젝트보다는 6시에 퇴근하고 약속한 일정을 지키는 프로젝트가 훨씬 낫다. 그렇다고 주먹구구로 개발하면서도 일정을 터무니없게 길게 잡으면 곤란할 것이다.

제대로된 조직, 프로세스, 시스템을 갖추고 있는 회사에서 SRS를 적절하게 썼다면 1년짜리 프로젝트에서 1주일 지연이 되는 것을 6개월전에도 알 수 있다. PM은 이런 일정 지연이 생기면 이를 복구하기 위한 다양한 기법들을 사용하게 된다. 따라서 일정에 맞춰서 프로젝트를 마칠 수 있는 가능성은 대단히 높아지게 된다.

더 이상 개발팀에게 "내일은 끝나나?"라고 물어볼 필요가 없다. 개발팀도 신뢰를 회복할 수 있을 것이다.

또한, 더 중요한 것은 6시에 퇴근을 하면서도 프로젝트를 더 일찍 끝낼 수 있다는 것이다.

심정적으로 경험적으로 이것이 믿어지지 않는 분들도 많겠지만, 필요한 만큼 적절히 체계화 된 개발을 하고 SRS와 설계를 적절하게 하면 프로젝트 일정도 지키고 개발자도 행복해진다.

여기서 중요한 것은 적절하게 하는 것이다. 적절하다는 것이 가장 어려운 것 중 하나다.

우리 회사에도 숨어서 놀고 있는 개발자가 있나?

소프트웨어 개발 조직은 전통적인 관리 방법이 별로 효과적이지 않습니다. 

소프트웨어 개발 조직은 프로세스와 시스템에 의한 자율적이고 투명한 방법이 필요합니다. 그런데 전통적이고 관료적인 관리 방법도 사용하지 않고 효율적인 프로세스와 시스템도 사용하고 있지 않는 조직에서는 개발자들이 어떻게 일을 하고 있는지 잘 파악안되곤 합니다.

물론, 놀고 있는 개발자를 찾아내고자 이 글을 쓰는 것은 아닙니다. 개발자들은 스스로 자신이 해야할 일을 찾아내고 스스로 관리해야 합니다. 물론 개발자에게 업무와 이슈가 할당되고 자신에게 주어진 일을 해야 하지만 이것이 다가 아니고 많은 일들은 스스로 해야만 회사가 경쟁력을 갖출 수 있습니다.

그러기 위해서는 효율적인 프로세스와 시스템을 갖추고 있어야 하고 문서화도 잘 해야 합니다. 그러다보면 누가 얼마나 많은 일을 했는지 자연스럽게 드러나게 됩니다. 거꾸로 들키지 않고 일을 하지 않기도 어렵습니다.

개발자들이 얼마나 많은 일을 했는지 다음을 보면 알 수 있습니다.

• SCM 사용기록 통계
• 소스코드 라인수
• 문서 갱신 기록
• 다른 개발자의 코드를 리뷰한 기록
•  Bug Track System 사용 통계
• 보고한 이슈
• 할당된 이슈
• 해당 기간 동안 해결한 이슈
• 댓글 수
• 리뷰 기록
• 리뷰 실시 기록
• 리뷰 참석 기록
• Wiki 작성 기록
• 문서관리시스템 업데이트 기록

물론 이 기록들을 점수를 매겨서 누가 더 열심히 일했는지 절대로 알 수는 없습니다. 같은 소스코드 라인수라고 해도 서로 난이도가 다르고 버그를 똑같이 고쳐도 10분 걸리는 버그가 있는가 하면 한달동안 고쳐야 하는 버그가 있기 때문입니다. 따라서 평가에 직접적인 기준으로 삼는 것도 위험합니다.

개발자들은 이러한 시스템을 통해서 자신이 하는 작업들이 항상 기록에 남고 별도의 관리를 하지 않아도 항상 모니터링할 수 있습니다. 이러한 방법이 매일 해야 하는 일을 일일이 관리하는 것보다 훨씬 효율적입니다.

일안하고 숨어서 딴짓하는 개발자를 찾아내는 것은 그냥 부수적인 효과일 뿐입니다.

망할 회사로 옮겨타는 방법

많은 개발자들이 현재 회사에서 희망을 느끼지 못하고 회사를 옮깁니다. 그런데, 옮긴 회사도 별반 다를 바가 없는 경우가 많습니다. 그럼 어떤 회사로 주로 옮기게 될까요? (사실 좋은 회사 찾기 정말 힘듭니다.)

• 망하지 않을 회사? (내가 다니는 동안에는 ...)
• 정말 재미있는 일을 할 수 있는 회사 또는 좋은 사람과 같이 일할 수 있는 회사?
• 이전 회사보다 연봉을 많이 주는 회사? (훨씬 많이)

이 모두 이직하는 회사의 조건들입니다. 하지만 아무리 재미있는 일을 할 수 있고 연봉이 많아도 회사가 망해버리면 소용이 없습니다.

망하지 않을 회사는 왠만해서는 망하지 않을 큰 회사이거나 작지만 알찬 회사일 것입니다. 큰 회사들이야 S사나 N사 등 다들 알고 계실 것입니다. 연봉도 작은 회사보다는 많죠. 이런 회사에서 일까지 재미 있다면 금상첨화지만 욕심 같네요. 주로 안정성 때문에 선택을 하게 되겠죠.

큰 회사도 좋지만 저라면 작지만 재미있게 일할 수 있고 성장 가능성이 높은 회사를 선택하겠습니다. 그럼, 작은 회사 중에서 망하지 않을 회사를 어떻게 고를 수 있을까요? 벤처투자가들이 이것을 알았다면 다들 떼돈을 벌었겠죠?

실제로 꽤 유명하고 규모도 큰 회사가 속은 썩어 있고 망하는 길로 가고 있는 회사는 의외로 많습니다.

제 블로그에 예전에 등록한 소프트웨어 회사의 개발 역량 평가표를 통해서 평가를 해보면 약간의 도움이 될 것입니다. 옮기려는 회사 내부에 이를 평가해줄 친구가 있다면 가능하겠지만 그렇지 않다면 알아낼 방법이 없겠죠. 물론 개발 역량이 회사의 성공을 위한 필요충분 조건은 아니지만 필요조건이기는 합니다.

회사의 내부 정보를 알아 낼 수 없다면 경영자를 살펴보는 것이 좋겠습니다. 대부분의 소프트웨어 회사가 특정 단계를 넘지 못하고 꺾이는 결정적인 이유는 경영자의 마인드에서 찾을 수 있습니다. 소프트웨어 회사에서 경영자가 소프트웨어를 이해하지 못한다면 특정 규모 이상으로 성장할 수 없습니다. CEO가 소프트웨어에 대한 이해가 부족하면 CTO가 이를 대신해주는데 우리나라 대부분의 소프트웨어 회사는 CTO가 없거나 CTO가 있어도 CTO역할을 하지 못하고 있습니다.

따라서 회사를 옮길 때 CEO 또는 CTO가 소프트웨어에 대해서 어떤 생각을 가지고 있는지 파악을 해보면 조금더 즐겁게 일할 회사, 그리고 앞으로 더 성장할 수 있는 회사로 옮길 가능성이 조금더 높아질 것입니다. 

평가를 어떻게 해야 할까?

개발자 여러분 평가철이 다가왔습니다. 이미 평가를 끝낸 회사도 있을 것이고 한창 평가를 하고 있는 회사도 있을 것입니다.

평가가 항상 만족스럽고 공정하다고 생각하나요? 그렇지 않은 분들이 더 많을 겁니다.

평가 시에 자주 보는 것은 개발자들 순위 매기기 입니다. 흔히 "나래비" 세운다고 하죠. (일본말에서 유래)

대부분의 개발자들은 이런 순위매기기의 결과가 공정하지 않다고 생각하고 팀워크를 깨기 일쑤입니다.

A평가를 받은 개발자와 D평가를 받은 개발자의 차이가 크지 않은 경우가 많습니다.  심지어는 더 잘한 개발자가 더 낮은 평가를 받는 경우가 흔합니다. 그런데 평가시스템에서 A는 10%, B는 50%, C는 30%, D는 30%를 할당 받아서 무조건 나눠야 하는 경우가 있습니다. 개발자가 5명밖에 안된다면 나누기도 어렵습니다. 기계적인 평가시스템 적용이 1년 동안 고생한 개발자들을 한순간에 힘을 잃게 할 수도 있다.

물론 D 평가를 받아야 할 개발자도 있을 수 있으나 열심히 일했고 성과도 꽤 잘 냈음에도 불구하고 D평가를 받는 개발자들도 있습니다. 그렇다고 평가를 관리자 마음대로 하라고 할 수도 없습니다. 그럼 더 엉망이 될 것입니다. 

평가는 불공평할 수밖에 없지만 불공평하다는 의식이 너무 팽배해지면 개발자들이 진정으로 열심히 하려고 하지 않을 것입니다. 평가를 잘 받기 위한 편법이 난무할 수 있습니다.

이렇게 평가가 공정하지 못하다는 인식은 평가의 기준이 애매하거나 없기 때문인 경우가 많습니다. 팀장 또는 관리자가 맘에 내키는 대로 평가를 하면 무슨 기준으로 평가를 했는지 알 수 없는 개발자들은 평가 결과를 납득하기가 어렵습니다.

그렇다고 너무 구체적인 평가 기준(KPI)도 문제가 됩니다. 몇가지 예를 보죠.

• 개발 일정을 맞추면 평가를 잘 주겠다. 
  코드는 엉망으로 만들어서 유지보수를 어렵게 만들지만 일단 일정은 지킵니다. 하지만 나중에 유지보수 개발자들이 엄청난 고생을 하게 됩니다.
  
• 버그를 많이 찾으면 평가를 잘 주겠다. 
  테스터는 스펙, 설계단계의 검토를 소홀히 하여 버그가 더 많이 발생하도록 합니다. 전체적으로 프로젝트 기간이 늘어나고 비용도 증가합니다.
  
• 버그를 적게 만들면 평가를 잘 주겠다.
  개발자는 최대한 일을 적게 하려고 하게 됩니다. 약간의 리스크가 있는 시도도 두려워하게 되며 새로운 기술도 연구하지 않게 됩니다.

이쯤 되면 개발자는 공장의 생산직 직원처럼 평가가 불가능하다는 것을 눈치채셨을 겁니다. 개발자들은 원래 돈에 그렇게 좌지우지 되지 않는데 공정하지 않은 평가를 몇번 받게 되면 기분이 나빠서라도 평가를 잘 받기 위해서 편법을 동원할 수 있게 됩니다.

흔히 하는 실수 중의 하나가 평가가 이렇게 부정확한데도 불구하고 평가에 의해서 A와 D 등급의 개발자를 엄청난 연봉 인상의 차이를 두면 개발자들이 더욱 열심히 일할 것이라고 생각하는 것입니다. 이는 착각이며 자칫하면 평가만 잘 받기 위한 편법이 난무하게 되며 평가의 결과는 불공정하다는 불만만 팽배하게 됩니다.

공정한 평가는 필요하지만 100% 공정하기는 불가능합니다. 그렇다고 평가를 하지 않을 수 없습니다. 평가는 잘못 휘두르면 안 한 만도 못하게 되고 그렇다고 안 할 수도 없는 균형잡기 어려운 줄타기입니다. 그리고 다음과 같은 기준은 세울 수 있습니다.

• 평가 기준은 회사의 비전과 일치해야 한다.
• 평가 기준은 평가자나 피평가자 모두가 납득해야 한다.
• 평가 기준은 연초에 미리 정해야 한다. 
• 평가 기준은 객관적이어야 한다. 즉 평가 가능해야 한다.
• 평가 결과를 너무 믿지 말아야 한다. 적당히 활용해야 한다.

평가의 목적은 결과를 보고 상과 벌을 주기 위한 것이 아닙니다. 평가기준이 회사의 비전을 절묘하게 잘 반영하여 하나의 목표를 가지고 매진할 수 있도록 하기 위한 것입니다. 잘 만들어진 평가 기준은 평가 결과를 가지고 벌을 주지 않아도 이미 목표를 달성한 것입니다.

A를 받은 개발자는 기분이 좋고 C나 D를 받아도 별로 기분이 나쁘지 않은 그런 평가 어디 없을까요?