| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
Tags
- goland
- RDS
- 구조체
- Intellij
- AWS
- LLM
- AI
- MCP
- ai agent
- GoF
- MSA
- esbuild
- typescript
- go
- Kubernetes
- EKS
- GIT
- Harness Engineering
- OpenClaw
- 오블완
- golang
- DB
- 디자인패턴
- 아키텍트
- logging
- claude code
- 클로드코드
- Infra
- 티스토리챌린지
- elasticsearch
Archives
- Today
- Total
목록ade (1)
Fall in IT.
요청을 받는 사람과 문제를 다시 쓰는 사람: BRM이 일하는 방식
조직에서 "이런 걸 만들어 달라"는 요청은 끊이지 않는다.대시보드를 만들어 달라, 보고서를 자동화해 달라, 알림 기능을 넣어 달라. 이 요청들을 빠르게 접수하고 정확하게 전달하는 사람은 유능해 보인다. 그러나 BRM(Business Relationship Manager)이 하는 일은 그 지점에서 시작되는 것이 아니라, 오히려 그 지점을 의심하는 데서 시작된다.BRM 후보 과정에서 학습한 내용을 한 문장으로 요약하면 이렇다.좋은 분석가는 요청을 그대로 전달하지 않고, 그 요청 뒤의 필요와 가치, 그리고 다음 행동을 분명하게 만든다. 이 글은 그 한 문장이 실제 업무에서 어떻게 작동하는지를 단계별로 풀어낸 기록이다. 1. 문제는 '요청'의 형태로 도착하지 않는다가장 흔한 실수는 현업의 요청을 곧바로 문제라고..
기타
2026. 6. 11. 13:40