Why do things not work as intended? – Lack of expertise(일이 의도한 대로 잘 굴러가지 않는 이유? – 전문성의 결여)


English version is below…

제목: 일이 의도한 대로 잘 굴러가지 않는 이유? – 전문성의 결여

Refactoring책을 보다가 문득 생각이 나서 글을 올린다.

왜 프로젝트를 진행하다보면 일이 잘 진행되지 않을까? 여러가지 문제가 있고 현상도 다양하긴 한데, 그 중에서 한가지를 꺼내보려 한다.

SW개발 프로세스의 전제조건(SW전문가들이 주장하고 나도 동의하는..)

  1. unit test는 개발자들이 해야 한다.
  2. 기능 테스트는 제품에 전문가적 식견을 가진 사람이 해야 한다.

Automotive SPICE 컨설팅을 하면서 기업들의 내부 사정을 들여다봤을때는 막연하게 그러려니 했는데,
지금와서 생각해보면 왜 일이 잘 안되는지에 대한 여러가지 원인 중에 하나를 깨닫게 되었다.

어떤 일을 하는데 있어서 그 일을 감당할 사람이 없거나 너무 부족하기 때문이다. 그 일을 자격이 안되는 사람이 하니까 전문성이 떨어지고 아마추어적인 일을 하게 되어 개발에 문제가 생긴다.

그런데, 아마추어적인 결과가 나오지 않도록  하기 위해서 관리자가 일을 맡기다보면 소수의 몇사람에게 과도한 업무지시가 떨어진다. 사실 그렇게 일을 한다고 임금을 3배 더 받는 것도 아니니, 사람들은 무능해보이려고 하거나 아니면 엄청 바쁜척한다. (개별 인원에 대한 resource control이 이루어지지 않는 회사라면 땡보직에서 꿀빨고 있는 사원들이 바쁜척하면서 힘든 업무는 요리조리 피하는 일을 목격할 수도 있다.)

아마추어적으로 일을 하게 되는 사람을 탓할 수도 없다. 그렇다고 관리자를 탓할 수도 없는 노릇이다. 관리자 입장에서는 사람이 없으니 어쩔 수 없이 비전문가에게 일을 맡길 수 밖에 없고(외부 능력자를 임시 고용할 돈도 없으니까), 지명당한 담당자 입장에서는 원래 하던 일에서 벗어난 일을 해야 하니 전문성을 발휘하기가 어려운 것이기도 하고..어려운 문제다.

SW개발 프로세스의 전제조건의 첫번째를 살펴보자. 나는 unit test는 QA가 할 수 있는 일은 아니라고 생각한다. unit test는 개발자가 할 수 있어야 한다. 그런데 한국의 특정 domain에서의 단위 시험 도구를 보면 QA부서 중심적 도구들이 많은 것 같다.
그 이유중의 하나는 QA부서에서 도구를 구매하려고 하고 있으며, unit test의 도입을 QA에서 하려고 하고 있기 때문이다.

unit test도구 도입을 QA에서 수행하는 경우 프로세스가 매끄럽지가 않다. 그리고 agile하게 프로세스를 돌리기도 어려울 것이다.(개인적 견해론), 결국 뭔가 돌아가는 거 같긴 한데 나이스한 느낌은 안든다. 혹은 도구를 구매해서 개발자쪽에다가 건네준다. 막상 해보니 너희들이 해야 할 일이라고 하면서. 그러면 개발자 입장에서는 일감이 더 늘어난 것이고, 단위 시험 도구는 좀 개떡같게 생겼고(뭘 받아도 프로그램이 후져보인다고 생각할지도 모름), 어쩌면 정말 후져서 짜증이 폭발할 수도 있다. 그리고 QA가 선정한 도구인지라 개발자가 쓰기에 편하지 않을 수도 있고, 게으르고 편리성을 추구하는 개발자 입장에서 ‘노가다’를 강요하는 업무를 해당 도구가 요구할 수도 있다.

게으른데 바쁜 개발자들은 태생적으로 프로세스를 증오하는 거 같다. 대체로 문서화를 싫어하며.. (모두가 그런건 아니고, 대체로…길들여지지 않은 야생의 개발자들이 그렇다. 프로세스에 길들여진 개발자들은 잘 한다..) 그런 상황에서는 사실 자기 일하기에도 바쁜데 뭔 일을 자꾸 주냐고 볼멘소리를 할 것이다.

SW개발 프로세스의 전제조건의 두번째를 살펴보면, 제품의 기능에 대한 시험은 product champion이 할 수 있다. 기능 시험은 제품의 내부를 최대한 black box로 보고 인터페이스를 통해서 기능을 확인한다. 제품 시험을 QA에서 한다고 ? 만약 그렇다면 해당 제품에 대한 탁월한 식견이 있어야 한다. 그렇지 않고 제품시험을 맡기는 것은 아마추어에게 일을 맡기는 것과 다름없다.

그런데, 제품 시험을 오랜기간을 들여서 시험을 하게 한다면 가능할 수는 있을 것이라 생각한다. 즉 해당 제품을 잘 몰라도 배워가면서 제품의 요구사항을 분석해서 시험을 할 수 있는 시간이 있다면 충분히 가능한 일이다. 어쨌든 결과적으로 제품 시험을 하려면 해당 제품의 전문가가 시험을 해야 한다.

대학원때 제품 시험을 수행해 본 적이 있는데 아무것도 모르는 초보에서 시작해서 제품의 기능을 파악하고 전문가들과 미팅해서 협의하고 다시 파악하고, 미팅하고, 그래서 어느정도 spec을 파악해서 테스트 케이스 만들고 테스트하고, 결과 공유해서 판정하고 테스트 종료하는데 약 1년에서 그 이상의 시간이 걸렸다. 외주를 준 업체 입장에서도 아마추어들을 키워내도록 정기적인 협의를 해야 했다.

만약에 QA에서 충분한 시간이 있으면 제품 시험이 가능하다. 하지만 그렇지 않고 사람도 충분하지 않으면 QA가 할 수 있는 일이란게 사실 (unit test, 제품 시험 범주 내에서) 없다.

이런 현상을 두고 상당히 많은 고민을 해왔으나, 근본적으로 해결이 쉽지는 않은 것 같다. 각 작업의 value를 개별 평가해서 해당 작업을 수행하는 사람에게 그 value에 해당하는 임금을 주지 않는한..(공산주의가 왜 생산성이 떨어지는지에 대한 이유와 비슷할 거라고 생각한다…)

(근데 그렇게 된다고 하더라도 다른 문제가 생길 수는 있을 거라고 생각한다만…)

 

Title: Why do things not work as intended? – Lack of expertise

While reading book related to refactoring, I think about it and upload it.

Why do things go bad when they’re working on a project? There are various problems and phenomena, but I would like to take out one of them.

Prerequisites for SW development process (SW experts claim and I agree)

  1. Unit testing should be done by developers.
  2. Functional testing should be done by a person with expertise in the product.

When I looked into the internal affairs of companies while doing Automotive SPICE consulting,
When I think about it now, I come to realize one of many reasons why things do not work well.

It is because there is not enough or too little people to do the job in doing something. Because the person who does not qualify for the job is poor, he / she has a poor professionalism and an amateur job, which causes development problems.

However, when an administrator leaves work in order to avoid amateur results, excessive work orders are lost to a few people. Actually, it does not mean that you get paid three times as much as you work, so people try to look incompetent or pretend to be very busy. (If you do not have resource control for individual personnel, you might witness the temptation of honey-sucking in the hidden place, while avoiding the hard work of dodging jobs.)

I can not blame the person who works amateurishly. But I can not blame the manager. As a manager, I have no choice but to leave my job to a non-specialist (because I do not have the money to temporarily hire an external competitor) and it is difficult to show my professionalism because I have to work away from what was originally done. It is also a difficult problem.

Let’s look at the first of the prerequisites for the SW development process. I think unit testing is not what QA can do. The unit test should be available to the developer. However, unit testing tools in a specific domain in Korea seem to have many QA department-oriented tools.
One of the reasons is that the QA department is about to purchase tools and QA is trying to introduce a unit test.

The process is not smooth when QA implements the unit test tool. And it will be difficult to agile the process (personal opinion), and eventually it seems like something is going on but it does not feel nice. Or buy a tool and pass it to the developer. I thought it was something you guys should do. Then, for the developers, there is more work, the unit test tool looks like a bit of a cake (you may think that the program is looking back at whatever it is), and maybe it’s really late and it can explode. And because QA is the tool of choice, the developer may not be comfortable writing, and the developer may need to force the developer to “tough labor-intensive work” from a lazy and convenient developer.

Lazy and busy developers seem to hate the process natively. Most of the time, I do not like documentation, and I do not like documentation … (not everyone, mostly … wild developers who are not tamed, developers who are well-trained in the process). I will make a loud voice.

Looking at the second prerequisite of the SW development process, the product champion can test product functionality. The function test verifies the function through the interface by viewing the inside of the product as black box as possible. Do you take product tests in QA? If so, you should have excellent insight into the product. Otherwise, leaving a product test is like leaving an amateur to work.

However, I think that it will be possible if I take the product test for a long time. That is, if you do not know the product well and you have time to learn and analyze the requirements of the product while you are learning, it is possible. Anyway, in order to test the product as a result, the expert of the product should test it.

I started the product test at the graduate school, but I started from the beginner who does not know anything, I understood the function of the product, and I met with the experts to discuss, re-understand, and meet the test. It took about a year or more to determine and complete the test. I also had to make regular arrangements to raise amateurs in terms of outsourcing companies.

If QA has enough time, product testing is possible. But there is not a unit test (within the product testing category) that QA can do if there are not enough people.

I have been in a lot of trouble with this phenomenon, but it seems to be fundamentally not easy to solve. Unless you individually assess the value of each job and give the person performing the job the wage that corresponds to that value … (I think it would be similar to why communism is not productive …)

(But I think that if it does, there might be other problems …)

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중