Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

3.23 협상과 리더십 스킬 #45

Open
SeokRae opened this issue Apr 24, 2022 · 1 comment
Open

3.23 협상과 리더십 스킬 #45

SeokRae opened this issue Apr 24, 2022 · 1 comment

Comments

@SeokRae
Copy link
Member

SeokRae commented Apr 24, 2022

  1. 왜 아키텍트에게 협상 능력이 중요할까?
  2. 비즈니스 이해관계자는 파이브 나인스 가용성을 주징하지만, 실제로 쓰리 나인스 가용성이면 충분할 때, 활용 가능한 협상 기법을 설명하기
  3. 비즈니스 이해 관계자가 "어제 필요했습니다" 라고 말했다면 어떤 사실을 추론 할 수있을까?
  4. 협싱에서 시간과 비용 문제를 가장 마지막까지 아껴 두어야 하는 이유는 무엇인가?
  5. 분할 및 정복규칙(divide-and-conquer rule)이란 무엇인가?
    비즈니스 이해 관계자와 아키텍처 특성에 대해 협상할 때 이 규칙은 어떻게 적용할 수 있을까? 예시 들기
  6. 아키텍처 4C를 열거하기.
  7. 아키텍트가 실용적이면서 동시에 비전을 가지는 것이 중요한 이유는 무엇일까?
  8. 아키텍트가 자산을 초대한 회의 수를 관리하고 줄이려면 어떻게 해야 하는지?
@SeokRae
Copy link
Member Author

SeokRae commented Apr 25, 2022

  • 왜 아키텍트에게 협상 능력이 중요할까?

소프트웨어 아키텍트가 내리는 모든 결정이 곳곳에서 거친 도전과 반대에 부딪히기 때문이다.

  • 비즈니스 이해관계자는 파이브 나인스 가용성을 주징하지만, 실제로 쓰리 나인스 가용성이면 충분할 때, 활용 가능한 협상 기법을 설명하기

상황을 더 잘 이해하기 위해서 문법과 유행어를 사용한다.

자신의 분석 결과만을 들이대며 너무 분위기를 강압적으로 몰아가지 않도록하고, 자신이 틀렸음을 입증할 만한 내용을 놓치고 있지는 않은지 잘 살펴봐야 한다.

  • 비즈니스 이해 관계자가 "어제 필요했습니다" 라고 말했다면 어떤 사실을 추론 할 수있을까?

출시 시기를 무엇보다 중요하게 생각하는 것으로 판단 가능

  • 협싱에서 시간과 비용 문제를 가장 마지막까지 아껴 두어야 하는 이유는 무엇인가?

중요하다고 이야기 하는 속성이 비용과 시간이 협상의 중요한 속성이 더 중요한 속성으로 판단하는 경우에는 어차피 협상이 타결된 이후에도 고려해도 된다.

  • 분할 및 정복규칙(divide-and-conquer rule)이란 무엇인가?

파이브 나인스가 되어야 한다고 주장하는 경우, 모든 서비스에서 적용되는 것이 아니라 특정 시스템 영역에서 요구사항이 충족된다면 까다롭고 비용이 많이 드는 요구사항과 협상의 범위를 좁힐 수 있다.

비즈니스 이해 관계자와 아키텍처 특성에 대해 협상할 때 이 규칙은 어떻게 적용할 수 있을까? 예시 들기

  • 아키텍처 4C를 열거하기.

커뮤니케이션, 협동, 명료함, 간결함

  • 아키텍트가 실용적이면서 동시에 비전을 가지는 것이 중요한 이유는 무엇일까?

비전을 가진다는 것은 어떤 문제를 전략적으로 사고 방식으로 접근한다는 것이다.
실용적이라는 것은 현실적인 솔루션을 적용한다는 것이다.

  • 예산 제약 등의 비용 요소
  • 시간 제약 등의 시간 요소
  • 개발팀의 스킬 세트 및 수준
  • 아키텍처 결정에 관한 트레이드 오프와 의미
  • 제안된 아키텍처 설계 또는 솔루션의 기술적인 한계

비즈니스 이해관계자는 제약조건에 적합한, 비전이 가미된 솔루션을 높이 평가할 것이고, 개발자는 구현 관점에서 솔루션이 실용적이라는 사실에 후한 점수를 줄 것이다.

  • 아키텍트가 자산을 초대한 회의 수를 관리하고 줄이려면 어떻게 해야 하는지?

회의에는 요청받은 회의와 요청하는 회의가 있다.
요청 받은 회의를 줄일 수 있는 기술은 회의 참여를 결정하기 전에 의제를 알려달라 요청하는 것

아키텍트가 회의 소집하는 경우에는 중요한 정보를 전달하는 용도라면 이메일로도 충분하다.
항상 의제를 정하고 집중할 수 있도록 하여 각자의 시간을 효율적으로 사용할 수 있도록 하는 것이 좋다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant