[Essay] SW 팀/엔지니어 의 성과 측정방법에 대한 단상.

아래는 모두 필자 개인의 생각임을 미리 밝힌다.

우리나라에서 SW산업은 그 역사가 짧다. 그래서 아직 제대로 된 체계가 잡혀있지 않다.
또한 SW 프로젝트에 대한 성과를 측정하는 방법 또한 체계적으로 정리되어 있지 않은 관계로, SW쪽 경력을 가지고 승진을 하는 것도 쉽지 않은 것이 현실이다.
(SW쪽에서 대단한 일을 했다고 내세울 수 있고 받아 들여질 수 있는 판단 기준이 정립되어 있지 않기 때문이다.)
이련 현상은 SW개발이 주가 되지 않는 embedded쪽에서 더욱 극명하게 나타나는데,  어떤 제품이 크게 성공했을 때에도 SW쪽에서 특진을 하거나 노고를 치하 받는 경우는 드물다는 것이 이를 잘 반영해 주고 있다.

앞서 이야기한 바와 같이 이런 모든 부작용의 근본 원인은, 합리적인 측정기준이 없다는데 있다. 측정할 방법이 없기 때문에, 성과에 대한 보상을 할 수도 없고, 잘한 것 못한 것을 구별할 수도 없다. 한 마디로, 주먹구구식으로 진행될 수 밖에 없다는 것이다.
싫으나 좋으나 그래도 측정이란 것을 해야하니 이런 저런 방법들이 동원되는데, 일단 논의의 대상을 ‘각 개인의 성과에 대한 측정’으로 한정해서 생각해 보기로 하자.

SW R&D 쪽에서 보면, 회사 차원에서 SW 엔지니어의 성과를 측정하는 구체적인 기준이 마련된 곳은 거의 없다.
그냥 개발 팀의 팀장의 주관에 맡기는 것이 현실이다.
쉽게 말하자면, 회사차원에서 측정 방법에 대한 가이드 라인을 줄 수가 없으니까 그냥 손놓고 있다는 말이다.
그리고, 요즘 SW 연구소에서 팀장의 직급을 맡고 있는 분들의 상당수는 예전에 IT 붐이 일어났을때 IT업계에서 실무를 담당해서, 대단히 이른 시기에 관리자의 역할을 했던 그런 분들이다.
즉, 실제 실무 SW개발 경력보다는 관리 쪽 경력이 풍부한 분들이다.
그런 관계로, 모든 분들이 그러하진 않겠지만 필자가 보아온 대다수는,  기술적인 측면에서 상당한 아쉬움이 있었다.
문제는, 기술적인 면이 부족한 사람이 기술력이 가장 중요한 엔지니어의 성과를 측정한다는 것이다. 제대로 될 리가 없다.
일 예로, 야근을 얼마나 많이 했느냐? 주말에 얼마나 많이 출근했느냐? 버그 수정 개수 – 얼마나 많은 수의 버그를 수정했는가? – 등으로 로 엔지니어의 성과를 측정하기도 한다.
이게 말이 되는가?
그런데 놀라운 사실은, 내부적으로 이런 식의 측정기준을 가진 팀/연구소가 내가 평소에 생각했던 것보다 많다는데 있다.
실무에 대한 경험이 부족하니, 엔지니어의 성과를 측정하는 제대로된 기준을 만들 수도 없는 것이다.

이런 저런 이야기를 쓰다보니 횡설수설하게 되었는데, 요점을 미리 말하자면, 마땅한 측정 기준이 없다면, 이런 측정 기준은 어떤가?

“테스트&디버깅 단계에서 나온 버그 수(1), 마지막 배포 버젼에 남아 있는 버그 수(2)” 이 두 가지가 적은 것! 단 (1)이 (2)에 우선한다.

SW개발에서 가장 잘못된 믿음이 “열심히 하는 것”이다. 열심히 버그 만들고, 고치고, 고치면서 또 만들고…
SW개발에서 상책은 버그를 가능하면 만들지 않는 것이다.
“열심히 하는 것이 미덕” 이라는 생각이 “버그 수정 개수 = 성과” 라는, 얼핏 생각하면 그럴 듯 하지만,  SW실무에서 봤을때 말도 안되는 공식을 만들어 내는 것이다.
능력이 부족한 엔지니어의 대부분이 버그 수정 개수가 많다. 자기가 버그를 만들고 자기가 수정하는 과정을 반복하니까.
특히 하루에 버그를 2~3개 잡아 냈다는 것은 자기가 만든 버그를 자기가 잡았다는 말이다. 자랑할게 아니고 부끄러워 해야할 것이다.
남이 만든 버그는 하루에 1개 잡아내기도 힘들다.

그렇다면, 왜 (1) – 발견된 버그 수 – 이 (2) – 남아 있는 버그 수 – 에 우선해야 하는가?
버그의 수정은 반드시 검증의 과정을 필요로 한다. 그런데 이 비용이 작지가 않다. 오히려 버그 수정 그 자체에 드는 비용보다 검증에 드는 비용이 더 큰 경우가 많다. 하나의 사소한 버그 수정이 만들어 낼 수 있는 side effect가 모두 검증되어야 하기 때문이다.
또한, 만약 버그 수정이 모듈의 interface,  심하게는 software 전체 구조의 변경을 요구한다면, 엄청난 추가 비용을 요구하게 될 수도 있다.
즉, 버그의 수정에 드는 비용은 해당 팀/개인 의 비용 뿐만이 아니라, 부수적으로 상당히 많은 양의 추가 비용을 포함하기 때문에, 될 수 있으면 피해야 하는게 옳다.
따라서, 버그를 많이 수정해서 남아 있는 버그 수를 작게 유지하는 것도 중요하지만, 그 보다 더 중요한 것이, 버그 자체를 적게 만드는 것이다.

글을 쓰다보니 약간 흥분한 듯 하다. 차후 내용을 정리하도록 해야겠다…

추가적인 생각들…

* 개발이 아니라 maintenance feature의 경우, 넘겨 받은 부분이 거의 완벽해서 아무일도 하지 않아도 버그가 없는 경우.
-> 일을 적절히 나누어 주는 것은 관리자의 몫이다. 이런 feature들은 그 이전의 history로 부터 파악이 가능하다.

[Dev] Time oriented vs Quality oriented development

It is already well known and proved that quality oriented development is better than time oriented development in terms of quality and time.

Time Oriented Development
Developing software with fixed schedule. For example, we should complete this project by 10th of March.
In this case, usually, functionality has priority to show progress. And, quality is put behind. So, software is not tested enough during development. Usually, real stage for test and debugging begins at the latter part of project. This is main cause that make time for test and debugging be longer than expected.

Quality Oriented Development
Development focusing on software quality. Software continuously tested during development to keep software quality good. So, software is debugged at the early stage. So, cost for debugging lessen(It’s well known that debugging at the early stage is much cheaper than debugging at the latter stage.). This shorten time and increase quality.

[Dev] Sharing between members and leader…

The team member (henceforth member) needs to report current state (what he/she is doing and progress etc) frequently to team leader (henceforth leader); Leader always want to know what members are doing.
On the contrary, leader needs to tell members what he/she wants to be done.

Usually, leader set the vision, goal and direction; members make those come true. Members cannot decide what they should do if they don’t have any idea about what leader wants.; It is same to the leader. Leader cannot make right decision about the future goal and vision without knowledge of current state of what members are doing.

So, “Sharing current state and goal” is very important to team.

In general, members know about practical state and issues better than leader. And leader understands external situation better and studies vision and future goal harder than members.

Now, it’s time to share it!!

(Is it too trivial to discuss? Never!.)

[Dev] Key point to succeed in large project…

There lots of books and guides about project management. But in my opinion, most important and efficient way is “Divide and Conquer”. In general, small-size-project is easy to succeed regardless of methodology. So, most important thing to succeed is “Dividing large project into several small independent projects”. We should focus and spend time on this!!!

( Yes.. I know…”Easier said than done!” :-( )

[Dev] one persone under full responsibility for one time-critical-project

Let’s consider a software project.

Usually, we have two general way to make up team.
1st : We may organize one team for each project. That is, one team for one project. And this team – actually, team lead if we should pick only one person – is fully responsible for the project.
2nd : one team for each features.(for example, WAP team, MMS team etc…)

We cannot tell which model is better (each model has it’s own pros and cons.).
But, in terms of time-critical project, 1st model is better.
In the 1st model, issues detected during project development are definitly under project team’s responsibility. So, we don’t need to struggle for finding appropriate team to handle those issues. And this project team tends to be active to resolve those. (But, Several teams may suffer same issues with high possibility, because sharing know-how and accumulating knowleges about each feature is difficult)

But, in 2nd model, it is difficult and takes time to know which team should handle those – for this, usually lots of communication overhead is required. So, each feature team tends to be passive. And they want to avoid being assiged to issues, because they don’t have responsibility to succeed this project. (But, in this case, each feature team can accumulate know-how about features and expect synergy from this because team becomes expert for the feature!)

We should take attention to main difference between 1st model and 2nd model. That is just “Is there any ONE person who are fully responsible for the project?”.

So, we would better to mix up this two models. (ex. 1st model for SW maintenance and enhancement; 2nd one for making product.)

My point to succeed in time-critical-project (ex. making product), (based on my experience..) is,

* There should be only ONE person who are fully responsible for a project and he/she should have enough authority to manage this project. Responsibility of several people means “No one under responsibility”.

Does it seems too simple and trivial? But, it is not easy to obey this rule efficiently.

[Dev][Quotation] 죠엘 test의 항목들.

아래의 항목은 “죠엘”의 블로그에 소개되어이 있는 내요들이다. 뭐 100% 동의하는 것은 아니지만, 충분히 기억해 둘 만하다.

1. 소스코드 관리시스템을 사용하고 있는가?
2. 한 번에 빌드 결과물을 만들어낼 수 있는 script를 사용하고 있는가?
3. 일일 빌드를 하고 있는가?
4. 버그 추적시스템을 운영하고 있는가?
5. 코드를 새로 작성하기 전, 매 baseline마다 알려진 모든 버그를 수정하는가?
6. 일정을 업데이트 하는가?
7. 요구명세서, 설계명세서 등 명세서를 작성하는가?
8. 개발자에게 조용하고 개인적인 작업환경을 제공하는가?
9. 경제적인 범위 내에서 최고의 성능의 도구를 사용하는가?
10. 테스터를 별도로 두고 있는가?
11. 프로그래머 채용 인터뷰 때 코딩 테스트를 하는가?
12. 무작위 사용편의성 테스트를 수행하는가?