Stakeholder Analysis


최근 Key Performance Indicator같은 뭔가를 만들어보려고 하고 있다. 그러던 중에 자료를 찾다 찾다 이 내용을 찾게 되었는데, 그 Project 초기에 도움이 될 만한 내용이 들어있다고 판단된다.

일반적으로는, 어떤 과제를 진행하는데 있어서 과제 관련된 사람들에 대한 피아식별 및 각 그룹별 대응전략을 짜는데 도움이 될 만한 내용이라고 생각한다.

Advertisements

개발자의 의사소통 능력 – 지디넷코리아


의사소통 능력 – 이것은 또 다른 domain의 tech tree이다. 누구에게는 passive skill이지만, 누구에게는 후천적 학습을 통해 level up을 해야만 도달할 수 있는 기술이다.

말로 한들 뭣하리, 이해는 해도 행동은 똑같이 할 것을…하지만 그럼에도 불구하고 다시 한번 보고, 이 내용을 어떻게 스스로 implement할 것인지를 고민해야 할 필요가 있음.

또는 커뮤니케이션 관련 교육을 듣는 것도 필요하다고 봄.

원문링크: 개발자의 의사소통 능력 – 지디넷코리아

  1. 상대방의 수준을 고려해서 쉽게 설명하기 – 그런데, 이게 생각보다 어렵다. 왜냐면, 상대방이 나만큼 알고 있다고 생각하기 쉽고, 개구리가 올챙이적 시절 생각하지 못하는 습성 때문에..
  2. 처음부터 끝까지 자신을 보호하기 위해 말하지 않기 – 궁금해서 물어보는건데, 뭔가 반응이 이상(?)하게 나오면 상대하기가 싫어지니까.. 당신을 해치려는게 아닌데..
  3. 표현의 Level을 적절하게 선정하기 – 이것도 생각보다 어렵다.
  4. 하고싶은얘기만 하지 말고, 상대방의 이야기에도 귀를 귀울이기 – 상대적으로 쉽다. 입 닫고, 귀를 열어라. 듣기시험한다고 생각하고 틀리면 10대 맞는다고 생각하고 긴장하고 들어라..

 

 

스크랩: Top 5 Embedded Software Problem Areas


Safety critical관점에서 보면, 결론부터 말하면 Top 5에 들어갈 필요가 없는 항목들이 아닌가 싶다.

(1) How is your code complexity?

코드 복잡도는 control flow, data flow complexity, class/component coupling/cohesion등으로 지표화를 할 수는 있다. 단 criteria를 정하기가 애매하다. 그런데, 그렇다고 해도 safety-critical관점에서는 구체적으로 요구하는 표준은 없다. 그래서.. 그냥 무시해도. 다만 고객이나 평가자가 사전 요구했다면 얘긴 달라짐.

(2) How do you know your real time code will meet its deadlines?

deadline을 만족시키는 것을 보이는 것은 어려운 일이긴 하지만, 약간의 희생을 감수하고 충분한 margin을 두면 괜찮지 않겠는가 생각한다.

(3) How do you know your software quality is good enough?

safety critical영역의 approval/certification 관점에서, metric관점의 뭔가를 요구하진 않는다. 그래서.. 별로 흥미가 없다.

(4) Is your software process methodical and rigorous enough?

표준에서 정의했으니까, 별 문제 없다. 이 질문은 표준의 정의가 유효한가에 대한 것인가? 사실 그것은 공학/과학의 영역이 아니라서 어떻게 정하더라도 그 결정의 타당성을 증명하긴 어렵다.

(5) What about dependability aspects?

엄밀하게 따지면 소프트웨어의 영역은 아니다. 임베디드 소프트웨어가 약간 박쥐 같아 보일 수는 있을지라도 그래도 이건 시스템 영역으로 둘 수 있을 거 같다.

Several times a year I fly or drive (or webex) to visit an embedded system design team and give them some feedback on their embedded software. I’ve done this perhaps 175 times so far (and counting). Every project is different and I ask different questions every time. But the following are the top five areas…

방법: Top 5 Embedded Software Problem Areas — Better Embedded System SW