타고난 성격 유형


타고난 성격 유형 – MBTI와 거의 같은 것 같다.

사람을 하나의 machine으로 간주할 때, 외부 환경을 입력으로 받아들이는 방식(sensor/intuitive)과 그것을 처리하는 방식(feeling/logical)으로 나눠서 4종류의 타입으로 나눌 수 있다. 이 책에서는 blue 타입, green 타입, yellow타입, orange 타입으로 나누었다.

character

자신이 어떻게 입력 및 출력을 처리하는지에 대해 알고 싶다면 아래의 설문지를 확인해보기 바란다.

감정형(feeling/emotional) F 논리형(logical/thinking) T
조화’가 본질적으로 중요 조화’는 목적을 위한 수단
느낌’에 맞게 행동하는 것을 선호 논리적’으로 행동하는 것을 선호
사람을 먼저 고려 일이 먼저
조화로운 관계를 선호 자신이 옳은 것을 선호
합의를 통해 결정 자신의 생각으로 결정
마음을 먼저 믿음 머리를 먼저 믿음
갈등을 견디기 어려움 갈등이 생겨도 할 수 없음
직관적(Intuitive) N 감각적(Sensor) S
내가 알고 있는 것에 의존 관찰에 의존
가능성에 더 관심을 가짐 현재 상태에 관심을 가짐
창의성을 선호 상식을 선호
순간적인 통찰에 따라 행동 신중한 분석에 따라 행동
개념과 씨름하기를 선호 사실이나 데이터와 씨름하기를 선호
종합적 관점 선호 디테일을 선호
거창한 아이디어 선호 확립된 사실을 선호

MBTI의 유형분류와 유사하다.

  • NT – 블루형, 논리적 의사결정자 – 직관적 정보
  • ST – 오렌지형, 논리적 의사결정자 – 감각적 정보
  • NF – 그린형, 감정형 의사결정자 – 직관적 정보
  • SF – 옐로우형, 감정형 의사결정자 – 감각적 정보

타고난 장점에 부합하는 업무

  • 블루 – 창의적인 아이디어로 가득하고 탁월한 성과를 요구하는 아이디어 건설자(연구 & 프로젝트 초기)
  • 오렌지 – 규율이 있고 신뢰할 수 있는 프로세스를 사용하는 시스템 구축자(경영 & 프로젝트 후반)
  • 그린 – 사람들에게 깊은 관심을 기울여 강력한 충성도를 이끌어내는 인간관계 건설자(HR, coaching, large complex)
  • 옐로우 – 조화로운 팀을 만들고 까다로운 사람들과 함께 작업하는 팀 구축자(마케팅, large complex)

그린/육성형 리더의 장단점

장점 단점
이성적 피해자
온정적 지나치게 예민
따뜻한 마음 비합리적인
감정을 느낌 지나치게 감정적
고귀한 가치 비판적
높은 목표 비현실적

옐로우/포용형 리더의 장단점

장점 단점
관심을 쏟음 모든일을 떠안음
타인을 신뢰 자기 비하적
팀 건설자 갈등을 두려워함
충성도 있음 지나치게 순응적
친절함 인정 욕구 강함
협력적 자신의 견해를 드러내지 않음

블루/비전형 리더의 장단점

장점 단점
비전제시 자기합리화
혁신적 변덕스러움
탐구심 많음 잘 따짐
분석적 비난적
활기참 잘난 척
독립적 권위에 반항적

오렌지/지시형 리더의 장단점

장점 단점
책임을 짐 타인을 비난함
정돈됨 융통성 없음
철저함 남에 대해 판단
신뢰할 수 있음 통제하려 함
논리적 폐쇄적인 태도
일에 집중함 배려심 없음

4가지 영역의 고른 발전이 중요함

  • 비전 – 초우량 기업의 조건(톰 피터스)
  • 육성 – 원칙 중심의 리더십(스티븐 코비)
  • 포용 – 팀이 빠지기 쉬운 5가지 함정(패트릭 랜시오니)
  • 지시 – 훈족 아틸라 그 리더십의 비밀(웨스 로버츠)

관리자의 30퍼센트 이하만이 유능한 관리자로 설문 결과가 나오는 이유는?

관리자는 기본적으로 계획, 조직, 지시, 통제 능력을 갖추어야 하지만, 그것만 필요한 것이 아니라 감정적 측면을 관리자들이 충족해줘야 함

이 책에서 언급하는 4 차원의 영역들이 고르게 발달한 관리자만이 유능한 관리자로 성공할 수 있다는 의미임.

프로젝트 관리자를 뽑을 때 필요한 질문들

  1. 지시적 관점에서 프로젝트 관리자로서의 자질

  2. 함께 일하는 팀원들에 대한 관심(포용)

  3. 정보에 대해 팀원들과 공유하는 방식(양육)

  4. 팀의 성공을 위해 얼마나 헌신했는지(비전)

 

관련 기사

네 가지 문화

 

Advertisements

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

Tips of Requirements and design using statecharts formalism(Statecharts formalism를 이용한 요구사항 및 설계 작성 tip)


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

This was introduced at the DO-178C certification consulting meeting, and I hope that this will probably be helpful to others. In DO-178C, there is no clear separation criterion for the requirements and design description steps. Also, the human brain does not think separately of requirements and design explanations. Quite capable programmers often think about the logic of the code while writing requirements. I consider the possibility of verifying the test environment, test method, test case, etc. of this requirement while reviewing the requirements.

My client decided to express the requirements as statecharts in the project for DO-178C certification. The diagram that the customer expressed has various problems in my judgment. Although it was one of the main research fields at the graduate school, it described the specification method even though it was a long time.

Statecharts is a visual formalism devised by David Harel as an extended version of the FSM (Finite state machine). Statecharts has since been incorporated into UML, and has been transformed from Simulink in Mathworks into the notation Stateflow.

(For another moment, statecharts has a non-determinism attribute, a troublesome issue in AI, so to develop a fatalistic system, Mathworks invented a deterministic version of statecharts, Stateflow.)

(Of course, the diagram you are trying to express is meant to be deterministic.)

Components of Statecharts

Statecharts = {S, s0, I, O, T}.

S = set of states
S0 = initial state
I = set of input variables
O = set of output variables
T = S x Cond1 x Cond2 x S The set of state transitions,
Where Cond1 = state transition condition, Cond2 = state transition behavior
Although the mathematical definition of transition is a bit old, it is not perfect, but let’s skip this once.

With all the elements defined above, the above Statecharts can be implemented, executable, and can generate test cases.

For example, suppose you have the following Statecharts

S = {s0, S1, s2}
I = {i1, i2}
O = {o1, o2}
T = {t1, t2}
T1: = {s0, ‘i1 = 1’, ‘o1 = 1’, s1}

T2: = {s1, ‘i2 = 0’, ‘o1 = 0, o2 = 1’, s2}

For developers, this can be done directly in code. In the past, when I participated in the model review and refactoring of projects that automatically generated auto code in stateflow (remember that time). With a few frameworks, it is possible to generate code mechanically without using expensive tools . The following code can be different from the behavior of the actual statecharts when run instead of applying the framework. I just want to understand it as a concept.

State = s0;
While (1)
{
Switch (State)
S0:
If (i1 == 1) {o1 = 1; State = s1; Break;}
Break;
S1:

For tester making test procedure, you can make test procedure by making the following table.

Test prefix for state reachability

S0: null
S1: null. “I1 = 1”
S2: null. “I1 = 1”. “I2 = 0”
The meaning of the above notation means that it is necessary to keep it in the initial state to reach s0. In order to reach s1, 1 is inputted to i1 in the initial state. In case of s2, i1 = 1 is inputted in the initial state And then enter 0 in i2.

I think the test procedure for the transition in each state is understandable enough without saying a word.

So, let’s take the eternal questions of DO-178C beginners.

Drawing with Statecharts, I think I draw requirements and designs together, how do I separate them?

I do not know if it needs to be separated, but if you split it off and decide that you need to write some in the Software Requirement Data (SRD) and some in the DD (Design Description), you can hierarchically represent the statecharts, Slice. It is a purely personal judgment to which level to slice, and I do not think DER will blame it for being wrong.

Note that even if you do not express requirements and designs with statecharts, you can still use vertical logical slicing to represent your requirements in a hierarchical way, even if they are expressed in natural language. Therefore, the upper level can be classified into HLR (high level requirement) and the lower level can be divided into LLR (low level requirement).

If I explained this, I think I got enough sense. I hope to use it in practice now.

What if you still do not know? You need to get consulting services, so please contact me. In the meantime, there have been a lot of examples that have impressed customers with the high-quality expression of experts, so if you have difficulty in expressing it, you may be assisted by a consultant, like me.

DO-178C 인증 컨설팅 회의때 있었던 일인데, 다른 사람들에게 도움이 될 듯 하여 소개를 해볼까 한다. DO-178C에서 요구사항과 설계 설명 단계는 칼로 무 자르듯이 명쾌한 분리기준이 존재하지 않는다. 또한 인간의 뇌는 요구사항과 설계 설명 단계를 별도로 분리하여 생각하지 않는다. 꽤 유능한 개발자들은 대부분 요구사항을 작성하면서 코드의 로직까지 생각한다. 나같은 경우는 요구사항을 검토하면서 이 요구사항의 시험 환경, 시험 방법, 시험 케이스 등의 검증 가능성을 생각하지만..

고객은 요구사항을 statecharts로 표현하기로 했다. 고객이 표현한 diagram은 내가 볼때 여러가지 문제가 있었다. 대학원 박사과정때 주 연구분야중의 하나였기 때문에 오래되긴 했지만, specification방법에 대해서 기술했다.

Statecharts는 David Harel에 의해 고안된 visual formalism으로서 FSM(Finite state machine)의 extended version이라고 볼 수 있다. Statecharts는 이후 UML에도 통합되었고, Mathworks의 Simulink에서 Stateflow라는 표기법으로 변형되기도 했다.

(잠깐 다른 이야기를 하자면, statecharts가 최근 AI에서 핫한 non-determinism 속성을 갖고 있기 때문이다. 그래서 운명론적인 시스템을 개발하기 위해 Mathworks에서는 deterministic version의 statecharts를 창안하게 된 것이고, 그래서 탄생하게 된 것이 Stateflow이다.)

(물론 고객이 표현하려는 diagram에서는 deterministic한 행동을 하도록 표현되어 있다.)

Statecharts의 구성요소

Statecharts = {S , s0, I, O, T} 로 정의된다.

  • S = 상태의 집합
  • S0 = 초기 상태
  • I = 입력 변수의 집합
  • O = 출력 변수의 집합
  • T = S x Cond1 x Cond2 x S 상태 천이의 집합,
    여기서 Cond1 = 상태 전이 조건, Cond2 = 상태 전이 행동

Transition에 대한 수학적 정의가 오래되어서 살짝 완벽하지 않은 감이 있기는 하지만, 일단 이 정도로 하고 넘어가겠음.

위에서 정의한 모든 요소를 갖추면 위 Statecharts는 구현 가능하며, executable하며, test case를 생성할 수 있다.

예를 들어 다음과 같은 Statecharts가 있다고 가정해보자

S = {s0, S1, s2}
I = {i1, i2}
O = {o1, o2}
T = {t1, t2}

t1: = {s0 , ‘i1=1’ , ‘o1=1’, s1}

t2:={s1, ‘i2=0’, ‘o1=0, o2=1’,s2}

개발자 입장에서는 이 것만 보고 코드로 바로 구현이 가능하다. 예전에 stateflow에서 자동으로 auto code를 생성하는 프로젝트의 모델 검토 및 리팩토링에 참여했을 당시 (그 때 쯤이었던 것으로 기억한다.) 약간의 framework만 있으면 비싼 툴을 사용하지 않고도 기계적으로 code 생성하는 것이 가능하다. 아래의 코드에는 그런 framework가 적용된 것이 아니라 실행시켜보면 실제 statecharts의 behavior와 다를 수 있다. 그저 concept정도로만 이해했으면 한다.

State = s0;
while(1)
{
switch(State)
s0:
if (i1==1) {o1=1; State = s1; break;}
break;
s1:

시험 절차를 만드는 tester입장에서는 다음의 table을 만들어서 test procedure를 만들 수 있다.

state reachability를 위한 test prefix

s0: null
s1: null.”i1=1″
s2: null.”i1=1″.”i2=0″

위 표기방식의 의미는 s0에 도달하기 위해서는 초기상태에서 가만히 있으면 된다는 의미고, s1에 도달하기 위해서는 초기상태에서 i1에 1을 입력하면 도달하게 되며, s2의 경우는 초기상태에서 i1=1을 입력하고 그 이후 i2에 0을 입력하면 도달한다.

각 상태에서의 transition에 대한 test procedure는 굳이 말하지 않아도 충분히 이해할 수 있을 것이라고 생각한다.

자, 그렇다면 DO-178C 초심자들의 영원한 질문사항을 받아보도록 하겠다.

Statecharts로 그리면 요구사항 및 설계를 같이 그리는 거 같은데, 어떻게 분리해야 하는가?

딱히 분리를 해야 할 필요가 있을지는 모르겠으나, 굳이 분리를 해서 일부는 SRD(Software Requirement Data)에 기술하고 일부는 DD(Design Description)에 기술해야겠다고 판단한다면, statecharts를 hierarchical하게 표현하고, 그것을 vertical하게 slice한다. 어느 level을 slice하는지는 순수하게 개인적인 판단이며, 그거 잘못했다고 DER이 비난하지는 않을 것이라고 생각한다.

참고로 굳이 statecharts로 요구사항 및 설계를 표현하지 않는다고 하더라도, natural language로 표현한다고 하더라도 철처한 logical thinking process를 적용해서 요구사항을 hierarchical하게 표현하여 마찬가지로 vertical slice를 할 수도 있다. 그래서 상위 level을 HLR(high level requirement), 하위 level을 LLR(Low level requirement)로 구분지을 수도 있다.

이정도 설명했으면 충분히 감을 잡았으리라 생각한다. 이제 실전에서 활용해보기 바란다.

아직도 잘 모르겠다면? 컨설팅 서비스를 받아야 할 필요가 있으므로, 나에게 연락하기 바람. 그동안 전문가의 고급스러운 표현으로 고객을 감동시킨 사례가 많이 있었으므로, 표현하는데 어려움이 있다면 컨설턴트의 도움을 받아도 좋음.