'교육'에 해당되는 글 5건

  1. 2013/07/23 글뻥 간만에 써보는 학습에 대해...
  2. 2011/07/20 글뻥 Agile 교육후 사용자 반응도 설문조사 결과
  3. 2011/07/18 글뻥 Agile 컨설팅중 교육 후기 (6)
  4. 2010/08/02 글뻥 애자일을 적용한 팀내 교육
  5. 2009/08/18 글뻥 성희롱 교육 그까이꺼 뭐~ (1)
프로그래밍이 됐던, 경영이 됐던, 운동이 됐던, 제 1법칙은 "반복"이다.

* 해보면 안다. 총검술의 짜세는 반복이다.... 닝기리..
사용자 삽입 이미지


한가지 재미있는건 우리나라 교육기관(?)중 최고봉인 군대이다.
예비역들은 한번 생각해보자. 아무리 돌빡이라도 군대만 가면 직무시험 90점이 넘는다. 쉬워서?
노!

그들의 방식은 아주 단순다.
"될 떄까지 한다."

좀더 살펴보면 이러하다.
1. 보여준다.
2. 시킨다.
3. 못한다고 갈군다. 한번보고 잘하면 뭔가 이상한거다.
4. 다시 보여준다.
5. 시킨다.
6. 못한다고 기합준다.
5. 시킨다.
6. 못한다고 기합준다..
5. 시킨다.
6. 못한다고 기합준다...
5. 시킨다.
6. 못한다고 기합준다.... (이쯤 되면 피교육생은 살려고 바둥바둥상태가 된다.)
5. 시킨다.
6. 못한다고 기합준다..... (아이!!! 18 고만해!!! 소리가 목구멍까지 나온다.)
5. 시킨다.
6. 못한다고 기합준다......
(아마도 더하면 내가 맞을 것 같다...)

메커니즘을 정리하면 이러하다.
1. 보여준다.
2. 시킨다.
3. 피드백한다. (잘하면 열외, 못하면 죽음)
4. 모두가 일정수준이 될때까지 2와 3을 반복한다.

암튼, 학습과 교육은 무조건 반복, 그리고 즉시적인 피드백.





2013/07/23 02:42 2013/07/23 02:42
TAG ,
총 3분이 교육받으셨는데 답변은 2분에게만 받았습니다.
(한분은 꽤 고위직이라 답변 받는걸 포기하고... ㅋ)

몇가지 질문에 대한 응답은 다음과 같았습니다.
1. 애자일 개발 문화에 대해 교육을 받으셨습니다. 달라진 부분이 무엇입니까? (복수응답)
    a. 과거 프로젝트를 진행하면서 상처 받았던 이유를 알게되었다.
    b. 프로젝트를 조금더 과학적으로 볼 수 있는 시야를 가지게 되었다.
    c. 요구사항을 듣고 이해하고 추가적인 질문을 할 수 있는 스킬을 확보하였다.
    d. 변경의 원인과 그 대응법을 갖게 되었다.
    e. 공유와 협력의 의미를 생각해보았다.
    f. 기존 방법론으로 정의하지 못하는 문제를 인식하게 되었다.
    e. 잘 모르겠다.
===================================================
복수응답을 요구드렸지만 각자 1개씩 선택하셔서 조금 난감합니다. -_-;;
개인적으로는 a와 d, e에 대해 답변이 나오기를 욕심냈지만, 역시 성심성의껏 한다고 해서 청강자가 그리 선택하지는 않는 군요. -_-;;
===================================================

2. 문제의 본질과 접근법, 그 접근법으로 도출되는 솔루션의 성격을 교육하였습니다. 개발시 많은 도움이 될까요? (1점-많이 아니다. 5점-많이 도움된다., 1점~5점까지 점수를 주세요)
   (    평균 3점   )
===================================================
역시나 그저그렇다... -_-;; OTL...
===================================================

3.1. 요구사항의 본질과 특성을 이해하셨나요? 그리고 얼마나 도움이 될까요? (1점-많이 아니다. 5점-많이 도움된다., 1점~5점까지 점수를 주세요)
   (    평균 3점    )
===================================================
이 역시 보통입니다. OTL... X 3
===================================================

3.2. 요구사항을 이해하게되었다면 변화에 대한 입장은 어떠하십니까? (1점-그럼에도 변하지 말아야한다. 2점-모르겠다. 3점-변화에 대응해야 한다. 1점~3점까지 점수를 주세요.)
   (    평균 2.5점   )
===================================================
음.. 이부분은 조금 발전이 있었습니다. 변화에 대응해야 한다라는 방향으로 조금씩 움직이기 시작했어요.
===================================================

4. UML을 교육하였습니다. UML이 도움이 된다면 개발공정상 어떤 부분에  도움이 될까요? (도움되는 순위를 주세요. 1순위, 2순위, 3순위, 4순위)
    a. 요구사항 (2순위, 2순위)
    b. 분석설계 (1순위, 1순위)
    c. 개발 (3순위, 4순위)
    d. 테스트 (4순위, 3순위)
===================================================
대체적으로 분석설계가 인상에 남으셨는가봐요.
개발과 테스트는 그리 비중을 두지 않았었습니다. 아무튼, 의도했던 교육결과!!
===================================================

5. 계획수립에 대해 교육하였습니다. Planning Poker가 도움이 되나요? (1점-많이 아니다. 5점-많이 도움된다., 1점~5점까지 점수를 주세요)
    (   평균 3.5점    )
===================================================
계획수립에 대해 인상깊으셨던것 같습니다. 다행히 도움이 되는 것 같아요.
===================================================

6. 회고에 대해 교육하였습니다. 회고가 도움이 될까요? (1점-많이 아니다. 5점-많이 도움된다., 1점~5점까지 점수를 주세요)
    (   평균 5점    )
===================================================
의외입니다! 이 과정은 시간관계상 짧게 말로 때웠거든요. (물론 마지막에 진행했지만...)
그런데 개발에 도움이 된다는 답변을 2분다 주셨네요.
===================================================

7. 전체적인 교육 만족도를 답해주세요. (1점-많이 아니다. 5점-많이 도움된다., 1점~5점까지 점수를 주세요)
    (   평균 4점    )
===================================================
다행히 교육 만족도 점수는 80점, 양호합니다.
===================================================

8. 기타 교육과정에서 가장 인상 깊었던 교육내용을 짧게 써주세요.
    - UML이라는 자체가 인상깊었고,  use diagram~sequence diagram까지 전체적인 흐름를 한눈에 파악할수 있다는 부분과 업무에 관한 우선순위(기존엔 체계적이지 못하였지만)를 선정하여 업무에 대한 달성도가 높여 진다는 교육이  인상깊었습니다..
    - 처음으로 Planning Poker를 하면서 흥미롭기도 하고 실제 프로젝트를 진행함에 있어서 많은 도움이 될 것 같았습니다.
===================================================
두 분의 관심이 서로 달랐는데 역시 교육후 인상깊었던 부분도 관심분야인듯 합니다.
===================================================

9. 기타 교육과정에서 가장 불만족스러웠던 교육내용을 짧게 써주세요.
    - 특별히 교육과정에 불만족스러운 부분보다는 시간적인 부분이 많이 작용되었다면 습득력이 최대한 발휘되지 않았을까 하는 생각이 듭니다.
    - 내용자체에 불만족스러운 부분은 없었지만 짧은 시간에 많은 것을 해야하는 것 같아서 조금 부담이 되었습니다.
===================================================
일일 3시간씩 총 6일에 걸쳐 진행했는데 결국 18시간 분량으로 진행하다보니 너무 많은 정보를 전달했던 것 같군요.
다음에는 조금 더 많은 시간을 함께 했으면 합니다. ㅋ
===================================================

설문에 답변해주신 임대리님과 이대리님께 감사드립니다. ^^;;


2011/07/20 16:11 2011/07/20 16:11
이미 일전에 포스팅한 바와 같이 작은 사무실하나 오픈해서 사무실 유지비는 조그만한 일을 하면서 벌고 있습니다.

현재하고 있는일은 미국과 한국간의 커뮤니케이션 코디네이팅, 설계, QA 역할을 하고 있고요.
여기에 부과적으로 개발팀의 Agile수행 능력을 향상시키는 교육과 개발 프로세스에 대해 컨설팅을 하고 있습니다.
주당 2일정도 일하고 1달에 사무실 월세와 관리비 정도는 벌고 있지요.

나머지 3일은 저희 회사의 주력업종인 2D 게임 만들기에 투자하고 있습니다.
아마도, 9월정도에는 첫 작품이 나올듯 하네요.

투자금은 조금 넉넉해서 월급가져갈 생각안한다면 1년정도는 시행착오할 정도의 버퍼는 되어 있습니다.

각설하고 최근에 진행했던 Agile 개발팀 교육과 관련한 후기를 정리해봤습니다.

1. 서론
사용자 삽입 이미지
위 그림은 Cynefin 모델입니다.
여기서 부터 출발했습니다. (지난 김창준님의 RT에 참석했을때 배운 모델입니다.)
이 모델은 세상에 존재하는 문제의 유형을 어떤 과정을 거쳐 어떻게 문제를 해결할지 구분한 것입니다.

문제에 대한 구분으로 Simple, Complicated, Complex, Chaotic, Disorder 5가지로 구분할 수  있습니다.
Simple영역에 있는 문제는 인지, 구분, 반응의 3단계 과정을 거쳐 "베스트 프렉틱스"를 만들어 냅니다.
Complicated영역의 문제는 인지, 분석, 반응의 3단계 과정을 거쳐 "굿 프렉틱스"를 만들어 냅니다.
Complex에서는 조사(실험, 탐침), 인지, 반응의 3단계를 거쳐 "창발적인 솔루션"을 만들어 냅니다.
Chaos에서는 행동, 인지, 반응의 3단계를 거쳐 "신기에 가까운 솔루션"을 만들어 냅니다.
Disorder는 어느 영역에도 속하지 않은 문제들입니다.

Chaotic 영역에서 "제한(Limitation)"을 주면 Complex가 됩니다.
Complex에서 "사람(Human)"을 제거하면 Complicated 또는 Simple이 됩니다.
꺼꾸로, Simple이나 Complicated 영역의 문제에 사람을 더하면 Complex가 되고,
Complex에서 제한을 제거하면 Chaos가 됩니다.

김창준님께서는 Effective Enterprise를 예로 들어 설명하셨는데, 제가 다 이해하지 못해서 저는 모든 개발의 기준인 "요구사항"을 예로 들었습니다.

2. 요구사항
* "요구사항"은 무엇으로 이루어 졌는가?
* "요구사항"의 정체는 무엇인가?
2가지 화두로 진행했으며 우리의 토론의 결과와 수 많은 요구사항을 해체한 결과 다음과 같은 결론을 얻었습니다.

a. 요구사항은 기능목록이다.
b. 요구사항은 Spec.을 포함하고 있다.
c. Spec.은 결국 제한조건이다.

이를 다시 Cynefin Model에 대입하자.
놀라운 일이 생겼습니다.

a. 먼저 사람이 참여하고 있기 때문에 개발은 Simple, Complicated 영역에 포함될 수 없다.
b. 요구사항은 제한조건을 포함하고 있기에 Complex 영역에 속하게 된다.
c. 요구사항에 제한조건이 없다면 Chaos 영역에 속하게 된다.

교육받으시는 개발자 분들과의 토론을 통해 위의 Cynefin Model이 맞다는 전제로 요구사항은 Chaos 또는 Complex 영역에 있는 문제라는 사실을 알게 되었습니다.

3. 심화논증
이제 다시 반대로 대입했습니다. Cynefic Model의 특성을 파악했지요.
Complex 영역에 있다면 시험, 실험이 반복되어 창발적 솔루션이 도출되는데 과연 개발이 그러한가? 입니다.
실험에서 우리는 가정을 세우고 그 가정이 맞는지 각종 변수를 바꾸어 가정이 맞는지 틀린지 검증합니다.
그렇다면 개발과정에서 요구사항이 실험에서의 가정이 맞는지 따져야 겠지요.
그 결과, 우리는 요구사항이란 가정과 동일한 특징을 발견했습니다.

a. 가정이 실험결과에 따라 바뀌듯 요구사항은 우리의 경험적으로 바뀌는 특징이 있다.
b. 가정에 실험제한적 요소가 없다면 막막해지듯, 요구사항에 상세한 Spec이 없다면 Chaostic 상태에 빠진다.
c. 가정이 틀리면 수많은 가정이 동시에 따라오듯, 요구사항을 만족하지 못하면 수 많은 요구사항이 추가적으로 발생한다.

또한, 기존의 방법론에서의 접근법은 Completic 또는 Simple 영역의 문제를 해결하는데 만족할지 모르겠지만, Chaostic 또는 Complex 상태의 접근법은 아니다. 따라서, 반복 점진적 방법을 사용하는 Agile은 접근법은 이론적으로 합리적이다.

거기다가, Simple영역에 개발문제가 있다고 가정하더라도 각 영역의 경계선에 있는 Disorder 문제는 어떻게 해야 하는가?에 대한 문제가 그대로 남게된다.

4. 다시 요구사항
따라서, 우리는 계획을 세우고, 진행하면서 무엇을 어떻게 해야하는가?에 대해 약 8시간동안 토론했습니다.
먼저, 요구사항이 맞는지 틀린지 어떻게 검증할 것인가?
우리가 개발 영역의 문제가 대부분 Complex 영역에 있다고 인정한다면 요구사항은 테스트되어야 한다는 의견을 냈습니다. 개발자분들은 동의하셨고 어떻게 테스트되어야 하는가는 2가지 방법을 제안했습니다.
첫째, Mockup을 만들어 보거나 Prototype을 만들어 본다.
둘째, UML 설계를 통해 Use case와 Activity Diagram 을 그려보아서 제대로 그려지는지 확인하는 방법입니다.

요구사항을 검증하고나면 계획은 어떻게 세울것 인가를 같이 고민했습니다.
UML을 Class Diagram과 Sequence Diagram을 그려볼 수 있게 교육을 진행했지요. 아마도 4시간 정도 한것 같았습니다.
먼저 화두는 "뮤비 플레이어 개발"이라는 요구사항을 냈습니다.
이제, 개발자 분들이 다시 물어봅니다. "그건 Chaos한 상태입니다. 제한을 더 주세요."
놀라운 변화였습니다. 어디서 구동할지 어떤 포맷을 지원할지 이야기를 더 해달라는 Feedback이었습니다.
이어 저는 다시 정정했습니다. "이 뮤비플레이는 네비게이션에 내장되어 Avi 포맷만 지원합니다."
이어 USE CASE를 하나그리고 그 USE CASE가 User TEST로 사용이 가능한지 Activity diagram으로 그렸습니다.
* 이 이론은 다음의 모델에 기반합니다.
사용자 삽입 이미지

위의 그림과 조금 상이하지만, 저는 요구사항과 사용자 테스트, 분석/설계와 유닛테스트, 개발로 간단히 그렸습니다.

Activity Diagram을 그리면서 너무 작게 나오거나 크게 나올경우 다시 Use CASE로 올라가 그걸 변경했지요.
적당한 크기가 되자, 다시 Method와 Entity를 구분했고 Entity 구분을 위해 몇가지 이야기가 더 오고갔습니다.
이어 Class Diagram이 완성되고 Sequence Diagram을 완성한 후, 우리는 몇가지 이야기를 더 나누었습니다.

"자 다음시간에는 계획을 같이 할께요." 이 말이 떨어지자, 다들 스스로 그린 그림을 뚫어져라 보시더니, "이게 개발근거군요!"라고 하시더군요. 이어, 제가 맞다고하자. 왜 지금까지 이렇게 교육을 받았는지 알겠다고 했습니다.

그리고 오늘 마지막으로 전체적인 Review와 함께 계획에 대해 교육했습니다.
Function Point와 같은 정형적인 계산방식의 모순을 실증해보기도 했습니다.
예를 들어, 우리가 개발할 시스템에 검색방식이 3가지 인데, 각 각의 방식을 설계한 결과 총 7개의 Method가 도출됐습니다. 그러나 Drag&Drop 검색 방식은 더 구현 난이도가 높았음에도 7개의 Method를 FP에 적용하자, 3가지 모두 같은 점수가 도출되었지요.

결국, 우리는 Planning Poker에 주목하게 되었습니다. 규모를 산정하는데 절대적인 기준치가 아닌, 상대적 기준을 적용했고 이를 다시, 절대적 일정으로 환산하는 방법을 통해 일정을 구할 수 있었습니다.

이후에는 시간관계상 가장 중요한 회고를 말로 떼우며 몇 일간 강행군의 교육을 마쳤습니다.

5. 회고
a. 잘된점 : 처음 문제를 인식하고 동기부여 된 상태에서 교육을 진행할 수 있었음.
b. 잘못된점
    - 지나친 긴장으로 굳어진 상태. (아무래도 타사의 대표가 와서 교육한다는게 걸린듯...)
    - 편안한 분위기 유도가 잘 안됨.
    - 동기부여에 대해 조금 더 노력 필요함.
c. 새로운 사실
    - 강요하지 말고 개발자 스스로의 경험에 비춘 판단을 존중하는 성과가 좋았음.
    - 기법이 아니라, 주변의 있는 일로 설명
    - 역시나, 똑같은 강의를 두번 못함.

* 부연설명-Cynefin 모델에서 문제의 영역이 변화하는 조건에 대한 부연설명.
먼저 인간이 개입되지 않는 문제를 예로 들겠습니다.
인간이 개입되지 않는 문제는 바로 이런류의 문제들입니다.
사용자 삽입 이미지
사용자 삽입 이미지
우리가 기계고장이라 부르는 고장입니다. 2가지 접근법이 필요합니다.
하나는 매뉴얼을 보고 수리해야할 부분을 교체, 수리하는 방법입니다. ==> 이경우 Simple영역으로 분류
또, 다른 하나는 전문가가 살펴보고 분류해서 교체, 수리하는 방법입니다. ==> 이 경우는 Complecated영역으로 분류

하지만, 여기에 사람이라는 인자를 넣으면 조직문제, 문화문제, 인간관계문제, 이혼 등으로 발전합니다.
사용자 삽입 이미지
학자분들께서 이러한 문제를 Complex문제 영역이라고 정의하셨습니다.
(Business 도 결국 인간관계가 바탕이 된다는 전제로 Effective Enterprise라는 새로운 영역의 학문이 나오고 있다고 김창준님께서 소개해주셨습니다.)

여기에 제한조건, 제약조건이 빠지면 이런 문제상태가 됩니다.
사용자 삽입 이미지
전쟁, 화재, 자연재해, 사고 등 일반적인 상식과 법령, 도덕규범이 제거된 상태가 Chaostic상태입니다.
나머지는 Disorder상태로 어디에도 포함될 수 없는 기타 영역입니다.
예를 들어, 개미들 간의 전쟁이 발발하여 한쪽 개미들이 떼죽음을 당하는 문제가 있다고 가정하고 이를 각 영역의 어디에 포함시켜야 할지 고민해본다면 인간이 비포함되어 있지만, 전쟁이라는 상황이므로 저는 Disorder 또는 simple 또는 Complecated영역의 문제로 보겠습니다.
* 예초에 인간의 입장에서는 문제가 아니겠지만, 집안에서 개미들 끼리 전쟁한다면 곤란한 문제가 되지요.

여기에 또하나의 부연설명을 드리자면, 인간은 정형적인 기계적 사고방식을 하는 부품이나 기계가 아니기 때문에 매뉴얼이나 솔루션이 있다고 해서 그걸 들이덴다고 문제가 해결되지 않기 때문입니다.

예를 들어, (이 대목에서 최근에 깨달은 사실이기도 합니다.) 아내와 혹은 아이와 문제가 발생했습니다. 흔히 말하는 불화입니다. (이때는 전쟁과 다르게 최소한 도덕관념, 법률적 제한이 걸린상태이므로 Complex상태가 됩니다.)
이 상황을 해결하기 위해 매뉴얼을 뒤지거나, 가정상담을 받는다고 가정해 보겠습니다.
이렇게 함으로써 이 문제를 단 1방에 해결이 가능할까요?

최근의 저희 집에서의 문제 해결과정을 회고하면 이러한 솔루션 (실버블릿)은 없더군요.

결론부터 말씀드리면, 여러가지 시도를 해보는 수 밖에 없었습니다.

최근에 조심스럽게 내려보는 결론은 인간은 매 시간, 매 분마다 변하는 동물이기 때문이지 않을까요?
예를 들면, 기분이 하루종일 안좋다고 하더라도 필시 하루중 단 몇분은 좋을 때가 있지 않을까요?
즉, 인간이라는 동물은 매뉴얼이나, 솔루션으로 정의될 수 없는 상태이기 때문에 Complex영역에 속하는 문제는 인간이 만들어낸 문제가 아닐까 추정해봅니다.

다시 정리드리자면,
Chaostic = 문제 + 인간문제 - 제한조건
Complex = 문제 + 인간문제 + 제한조건
Complicated = 복잡한 문제 - 인간문제 + 제한조건
simple = 간단한 문제 - 인간문제 + 제한조건
입니다. ^^;;





2011/07/18 20:08 2011/07/18 20:08
XPER에서 팀내 교육에 관련한 포스트가 있어 조금 구태의연한 방식을 올렸었는데..
http://groups.google.com/group/xper/br ··· 14f0533d

김창준님께서 답변 달아 주신것을 조금 정리하여 보았다.

먼저 기존방식.
2가지 방식이 있다. 하나는 PL급을 모아서 전파 교육을 하는 방식으로 ptototype을 만들면서 같이 애자일 프래틱스를 하나씩 적용해가며 튜닝하는 방식과 또 하나는 별도의 교육없이 전체에게 어떤 프래틱스를 쓰라고 공지하는 대신 프로젝트 Iteration 별로 단계별로 교육하는 방식이다.

여기에 김창준님께서 권해주신 방법은 이러하다.

쉽지 않은 일을 하시네요. 저는 다음 방안을 권해드리고 싶습니다.

일종의 애자일 프로젝트 식으로 교육을 진행하는 방법입니다.
최초 소규모 그룹을 선정합니다(두가지 전략이 가능한데, 하고 싶어하는 사람들로 하는 방안, 최대한 다양한 샘플링을 하는 방안이 있습니다). 그 그룹과 실험적으로 (기간도 압축해서 -- 예컨대 하루나 반나절) 교육을 진행합니다. 단, 교육을 하기 전에 다음 세 가지는 미리 고민을 해둬야 합니다.

1. 교육이 효과(여러 레벨에서 말할 수 있는데 다음 순서를 참고로 하세요: 만족하는가, 잘 이해하는가, 그렇게 행동하는가, 그래서 성과가 있는가)가 있는지 없는지, 그리고 왜 그런지를 모니터링 할 수 있는 방법
2. 잘 될 때 이걸 어떤 식으로 증폭시킬지에 대한 전략
3. 잘 안될 때 부정적 효과를 어떻게 감소시킬지에 대한 전략

그리고 교육이 끝나면 피교육자들과 함께 고민을 하면서 어떻게 이걸 나머지 인원에게 효과적으로 전파, 발전시킬지 "함께" 의논하고 액션 플랜을 만듭니다. 그리고 주기적으로 이런 과정에 참여하고 싶은 사람을 뽑습니다.

그 다음 릴리즈 2를 계획합니다. 조금 더 사이즈를 늘린 실험을 하는 것이죠.

대략 세 번 정도 릴리즈 하면 이 조직 문화에서, 이런 사람들을 대상으로 어떤 방식의, 어떤 내용의 교육이 효과적일지 윤곽이 드러나지
않을까 생각이 들고요, 또 이 과정에서 동지들을 얻어서 전파도 더 쉬워지지 않을까 합니다.

마지막 팁으로, 이런 과정에 함께 하는 동지들(위원회라고 해도 될 듯)과 함께, 필수, 가능한한, 옵션 사항들을 정하면 좋을 것 같습니다.

필수는 이 부분은 무슨 일이 있어도 지켜야 한다는 겁니다. HOW보다는 WHAT을 정하는 것이 좋습니다. 그리고 HOW는 각자 선호도에
따라 알아서 하도록.  그리고 왜 이것이 필요한지, 중요한지, 잘 안지켜지면 어떤 impact가 있는지를 분명히 밝혀야 합니다.

가능한한은 가급적 이 부분을 노력해 달라는 것인데, 좋기는 하지만 정 사정이 안되면 잘 못해도 괜찮다는 것입니다.

마지막 옵션 사항은 다음과 같은 옵션들이 있는데 결정은 당신들의 선택이다라고 하는 겁니다.

이런식으로 개인별(혹은 소규모 그룹별) 어느 정도의 자유도와 동시에 책임/의무를 함께 보여주는 것이 효과적인 것 같습니다.

정리요약하면 이러하다.
먼저 계획을 수립한다. 계획 수립에는 3가지 측면에서 고민한다.
1. 교육의 효과를 측정하는 방법
2. 교육의 효과가 좋을 때의 증폭방법
3. 교육의 효과가 나쁠 때의 감소방법
그리고 또하나 유념해야 할 것은 교육 내용을 무엇(What)으로 채우자.(기존의 어떻게(how)에 비해 효과적일 것이라 생각됨)
그리고 교육 아이템을 필수, 가능한, 옵션 3단계로 설정하여 필수적인 것은 반드시 해야 하는 프래틱스, 가능한은 상황이 가능하다면 해야 하는 프래틱스, 옵션은 해도 안해도 무방한 것들로 채운다.

이제 교육대상을 추린다. 방법은 2가지이다. 지원자 또는 무작위 샘플링이다. 아무래도 대한민국의 특성이 반영된 듯 싶지만... 개인적인 생각으로는 한국과 같은 상황을 반영하려면 다른 사람에게 영향력을 미치는 키맨을 찾아야 될 듯 싶다.

샘플링이 끝나면 Quick하게 반나절 교육을 실시한다.
교육이후에 피교육자들과 토론을 거쳐 전파 시킬 방법을 찾고 액션플랜을 세운후에 담당자를 지정한다.

이렇게 iteration 1이 완료되면 교육 범위를 확대하여 (여기서 조금 정리가 안되는 것이 교육 과제 확대일까? 대상의 확대일까?) iteration2를 진행하고 iteration1을 반복한다. iteration2 종료후에는 iteration3을 진행한다.

여기서 하나더 나아간다면 Keyman을 찾는 방법이다.
Keyman이란 직급과 나이를 떠나 팀내에서 영향력을 많이 주는 요원인데 이를 찾는 방법은 이전에 포스팅한 것을 참조하자.
http://www.wolfpack.pe.kr/487

영향력과 관심도 2개의 축으로 개개인별로 분석하면 어느정도 영향력이 있는 요원들을 따로 선별할 수 있으리라 생각된다. (나름 응용이랄까... ^^;;)

하나더 이야기 하고 싶은 것은 나이를 먹다보니 인문학의 중요성이 더 커지는 것 같다.
어릴때는 기술지상주의였는데 리더의 위치로 다가갈 수록 철학과 심리에 대해 공부하지 않으면 안되는 느낌이다.
2010/08/02 18:45 2010/08/02 18:45


OTL... 나는 기준 미달 ㅋㅋㅋㅋ
2009/08/18 13:44 2009/08/18 13:44