카테고리 보관물: review

Examples of conflicts with engineers in review meeting and solutions (산출물 검토시 엔지니어와의 갈등 사례 및 해결방법)


한글 버전은 아래로. korean version is below.

When I work as a consultant, I do a lot of different things. The original scope did not have to do this, but when I saw my customers are drowning I have no choice but to save them.

Anyway … If you review the output, you will be in a fate that can not help but posing a problem with the contents expressed inevitably. Then, when the situation that is really common comes up a lot of questions like “Why can not you do this?”

There is a problem like this, and it is good to express it this way. I’m talking about it, but most engineers are a little annoyed at the time. It means that you have to do again what you did.

In general, engineers are awkward in writing technical documentation. But do not you think it’s annoying because you have to write a document? I understand too. But is any alternatives? This is important in the company, and the company trust you to do that important thing.

Most of the time I asked from my customers was to show them examples. And finally, I will work with the customers.

Again, the conflicts often arise in the review meetings, and inevitably there will be conflicts with the engineers who identify their products with oneself.

At this time, I change my role as a certification assessor. At this point, I should be able to explain what he can accept. If that does not work, the consultant can be seen as an incompetent consultant who does not know well.

It is important as a consultant to pass this part well.

Consultant should not only provide DO-178C solutions but also provide judgments as a certification assessor. Obviously, this is not easy, but in order to do this in this area, you have to have this.

컨설턴트로 일하다보면, 진짜 별의별 일을 다 한다. 원래 scope에는 하기로 한 일은 아니었으나 고객이 허우적 거리고 있는데 나 몰라라하고 발뺌하고 있을 수도 없다. 계약 전에는 자기는 수영 전문가이고 1시간 자유 이용권에 해당하는 비용만 지불하겠다고 떼를 써서 그런가보다 하고 계약을 했는데, 입수 후 10분도 안돼 맥주병처럼 되어버린 상황이다.

어쨌건..산출물에 대해 검토를 하다보면 필연적으로 표현된 내용에 문제를 제기할 수 밖에 없는 운명에 놓이게 되고, 이 부분에 대해 지적질을 할 수 밖에 없다. 그때 정말 흔하게 나오는 상황이 “왜 이렇게 하면 안되는 것이냐?”라는 식의 질문을 많이 하게 된다.

그때 이런 저런 문제가 있고, 이런식으로 표현을 하는게 좋다. 는 식으로 이야기를 하게 되는데, 그 때 대부분의 엔지니어는 좀 많이 짜증이 나는가보다. 자기가 한 일을 다시 해야 하게 되는 것을 의미하기 때문이다.

일반적으로 엔지니어들은 기술문서작성에 서투르다. 국어를 못하니까 이과로 온 것이고(나또한 그러하다.) 그런데, 회사와서 국어하라니까 좀 짜증나지 않겠는가? 나도 이해 한다. 하지만 어쩌겠는가? 회사에서 이게 중요한 일이고, 그 중요한 일을 당신을 믿고 맡긴 것인데..대부분 이때 example을 보여달라고 요청을 하기도 한다. 그러다가 결국 컨설턴트와 공동 작업을 하게 되는 결론을…ㅎㅎ

다시 원래대로 돌아가서, 검토 회의에서 이런 갈등이 자주 발생하게 되고 자신이 만든 산출물을 자기와 동일시 여기는 엔지니어들에 대해서는 필연적으로 갈등이 생길 수 밖에 없다.

이때는 마치 인증 평가자의 입장으로 전환하게 된다. 그리고 DO-178C 요구사항에 대한 부적합 사항을 제시하게 된다. 이 때 엔지니어가 받아들일 수 있도록 설명을 해 줄 수 있어야 된다. 만약 그게 잘 안되면, 그 엔지니어에게 컨설턴트는 ‘잘 알지도 못하는 무능한 컨설턴트’로 비춰질 수 있다.

이 부분을 잘 넘기는게 컨설턴트로서 중요하다.

DO-178C에 대한 솔루션을 제공함과 동시에 인증 평가자로서의 판단력도 동시에 가지고 있어야 한다. 당연히 쉽지 않은 일이지만, 이 분야에서 이런 일을 하려면 이정도는 갖춰야 한다.

산출물 검토중에 문제가 예상되는 증상들..


문서가 다음과 같은 증상이 있다면

  1. 문서의 내용이 체계적이지 않다. 두서가 없고, 문장의 구조가 없다. 읽고는 있으나 뭐라고 말하는지 도대체 모르겠다.
  2. 문서에서 쓸데없는 내용이 적혀있다.  이 문서에 넣어야 하는 Scope에 대해서 작성자도 전혀 생각하고 있지 않다.

 

예상되는 결과

  1. 시험 시나리오를 짤 수가 없다.
  2. 구현이 제대로 되었는지 당연히 알 수 없다. 추적관리란 건 당연히 기대할 수 없다.
  3. 내용이 이해가 안되는 것은 당연한 일이므로 죄책감 갖지 말자
  4. 설계가 제대로 된건지 파악할 수가 없다. 내용 파악이 안되는걸 가지고 엔지니어가 아니라서 잘 모르니까 그러는 것이라고 담당자가 드립을 칠 수도 있는데, 그건 사실이 아닌 경우가 많다.
  5. 일의 진척상황을 파악할 수가 없다. 애시당초 scope조차도 모르는데, 일정 시간이 지나고 지겨울 때쯤이면 출시하자고 하겠지.. 그래서 출시하면 곤란한 상황에 처할 수 있다. 그건 이런 상황에서는 자연스러운 일이니 너무 놀랄 필요도 없다.

 

이런 현상의 원인들

  1. 시간이 없으므로 문서작성에 시간을 들일 시간이 없다. – 틀린 말은 아니며, 그간 놀았거나 아니면 계획을 제대로 세운게 아니란 것이다. safety critical 개발철학은 어느정도의 문서화는 필요하다. 안드로이드 앱이나 게임같은거 개발할거 아니면 (이 표현이 앱이나 게임을 비하하는 의미가 전혀 아니고, 문서화를 안해도 가능한 도메인이 있을 수 있다는 의미임)
  2. 솔직히 고백해서 문서화 잘했으면 문과갔을 것이고, 그거 못해서 이과 왔는데, 문서만들라고 해서 짜증나는 것임. 생각해 본적도 없고 훈련받아본적도 없음. 그냥 싫은 것임