다른 서비스
NEW
기획
디자인
개발
프로덕트
아웃소싱
프리랜싱
비즈니스
최근 검색어
전체 삭제
최근 검색어가 없습니다.

기획

비즈니스와 애자일 조직은 어떻게 친해질 수 있을까요?

본문은 위시켓과 번역가 전리오가 함께 만든 해외 콘텐츠 기반 번역문입니다. 이 글의 작가인 이타마르 길라드(Itamar Gilad)의 블로그를 통해 발행된 글입니다. 그는 Google, Microsoft, IBM 및 기타 여러 스타트업에서 20년 이상의 경력을 쌓은 베테랑 프로덕트 매니저입니다. 본문은 비즈니스 팀과 애자일 조직 사이의 소통 방법에 대한 내용으로 조직 생활에 있어, 서로 간의 경계를 허물고 원만하게 일할 수 있는 방법은 무엇일지 함께 고민해볼 수 있겠습니다.

 

기업의 경영진과 프로덕트 매니저들은 개발자들이 기업의 비즈니스 차원에서 필요한 부분에 대해서 관심이 부족하다는 사실을 깨달을 때마다 좌절하는 경우가 많습니다. 개발자들은 제품을 디자인하고 기능을 구현하느라 끝없이 바쁘게 일하지만(그들의 업무는 눈으로 쉽게 파악할 수 없는 경우도 많습니다), 비즈니스 측면에서 바라보자면 중요한 프로젝트가 진행되는 속도는 언제나 굼벵이처럼 느리기만 할 뿐입니다. 오랫동안 기다려왔던 제품이나 기능이 마침내 출시된다고 하더라도, 정작 기업이 원하는 수준에는 못 미치는 경우도 허다합니다.

 

우리는 흔히 엔지니어나 디자이너, 데이터 엔지니어 등의 개발자들에게 비즈니스 감각이나 “바람직한 조직문화”가 결여되어 있다고 생각하기 쉽지만, 실제로 그런 경우는 많지 않습니다. 오히려 개발자들은 계획 단계에서 배제되어 있거나, 비즈니스적인 부분과 단절되어 있는 경우가 더 많습니다. 그들의 업무는 언제나 제품이나 기능을 만들어내는 것(산출)에만 머물러 있으며, 비즈니스나 고객의 측면에서 사고하는 방식에는 익숙하지 않습니다. 부서별로 인센티브가 주어지고 목표가 할당되는 분위기 때문에, 개발자들은 강력하고 확장 가능하며, 기능이 훌륭한 소프트웨어를 만드는 일에 더욱 내몰리게 됩니다. 그래서 비즈니스의 성공보다는 자신들의 성과를 수치적으로 개선하는 것에만 집착하게끔 만듭니다.

 

 

애자일(agile)[1]개발 프로세스

애자일 기법을 활용한다고 해서 반드시 상황이 나아지는 것은 아닙니다. 오히려 더욱 악화되는 경우도 많습니다. 애자일 기법에서는 사양 → 설계 → 개발 → 테스트로 이어지는 기존의 순차적인 개발 방식을 폐기했지만, 대부분의 기업들에서 여전히 사용하고 있는 방식인 전략 → 로드맵 → 프로젝트 → 실행으로 이어지는 비즈니스 프로세스를 바꾼 것은 아니기 때문입니다. 그래서 관리 및 경영 부서의 사람들은 여전히 “폭포수 모델(waterfall model)[2]이 지배하는 세계”에서 대부분의 시간을 보내고 있습니다. 즉, 매우 잘 정의되고, 웬만해서는 변하지 않는 전략, 로드맵, 계획에 의해서 거대한 프로젝트를 진행하고 있습니다.

 

 

반면에 수많은 기업의 개발자들은 현재 “애자일 세계”에 완전히 몰두해서 대부분의 시간을 보내고 있는데, 그들은 엄격한 리추얼(ritual)[3]에 의해 코딩 작업을 조금씩 늘려가면서 결과물을 향해 나아갑니다. 이런 팀에서는 우선순위가 정해진 프로덕트 백로그(product backlog)[4]와 상세한 요구사항들을 전달받을 것이라고 기대하는데, 흔히 에픽(epic)[5]이나 유저 스토리(user story)[6]의 형태인 경우가 많습니다. 사용자나 시장, 비즈니스 등의 좀 더 커다란 맥락은 그 뒤로 사라집니다. 역사적으로 모든 애자일 기법은 사용자와 비즈니스 모두에게 있어서 코드가 아니라 지속적인 가치의 전달을 강조하고 있습니다. 이들 모두 사용자/고객 및 이해당사자들과의 짧은 피드백 루프(feedback loop)[7]가 필요합니다. 그러나 애자일 기법에서는 이런 부분을 반드시 지켜야 하는 것은 아닙니다.

 

이에 대해서 많은 기업들이 채택하고 있는 해결책은 바로 프로덕트 매니지먼트(product management)[8]입니다. 요즘에는 프로덕트 오너(product owner, PO)라고 부르기도 하는 프로덕트 매니저(product manager, PM)들은 이러한 두 세계 사이를 연결해주고 “모든 것이 원활하게 동작하게” 만드는 사람들입니다. 이러한 경계선 사이의 한쪽 측면에서 보자면 그들은 로드맵에 따라서 제품이나 기능을 완성해야 하는 책임이 있는데, 이것은 일반적인 프로젝트 매니저(project manager)의 업무와 크게 다르지 않습니다. 그리고 다른 쪽의 측면에서 보자면, 그들은 기술 인력들을 최대한의 역량으로 바쁘게 작업하도록 만들면서 애자일이라는 만만치 않은 조직을 가동시켜야 하는 책임이 있습니다.

 

이러한 PM과 PO의 역할 모두 대체적으로 힘들고 웬만해서는 겉으로 성과가 드러나지도 않습니다. 프로덕트 매니저는 플래닝 세션(planning session, 기획 회의), 리뷰(review), 스탠드업(standup, 애자일 조직에서 매일 간단하게 진행하는 회의), 레트로스펙티브(retrospective, 성과 리뷰 회의)와 같은 이해당사자들과의 다양한 미팅을 관리해야 하는 것은 물론이고, 목표 및 핵심 결과(OKR)[9], 로드맵, 에픽, 유저 스토리도 만들어야 하기 때문에 엄청나게 많은 시간과 노력을 들여야 합니다. 이런 업무들은 아주 어렵고도 시간이 소요되는 업무이기 때문에, 정작 실질적인 영향력을 발휘할 수 있는 제품을 만드는 데 있어서 필수적이라고 할 수 있는 시장조사나 데이터 분석, 아이디어 검증과 같은 업무를 할 수 있는 시간이 부족한 경우가 많습니다. 제가 이야기를 나누어 본 많은 프로덕트 매니저들은 이런 시스템이 제대로 작동하지 않으며 시간낭비라는 사실을 충분히 잘 알고 있었지만, 개인이 그것을 바꾸기에는 무기력하다고 느끼고 있었습니다.

 

 

경계를 허물기

이번 글에서 저는 톱다운(top-down)의 방식의 폭포수 모델을 벗어나서 근거에 기반한 제품 개발 방식으로 전환하는 것이 조직의 관리, 기술, 프로덕트 매니지먼트, 디자인, 당사자들 사이의 밀접한 관계 유지 등에 어떻게 도움을 주는지를 설명하고자 합니다. 여기에서는 제가 고안한 기스트(GIST) 프레임워크를 참고해서 설명하도록 하겠습니다.

 

GIST는 제품 계획 및 개발의 네 가지 레벨인 목표(Goal), 아이디어(Idea), 단계(Step), 작업(Task)을 관리하는 기법입니다.각각의 레벨에 대해서 간단히 말하자면, 목표(Goal)는 우리가 성취하고자 하는 바를 정의하는 것입니다. 아이디어(Idea)는 그 목표를 달성하기 위해서 고안해 낸 방법입니다. 단계(Step)는 그러한 아이디어가 유효한지를 검증하면서 점점 더 발전시켜 나가는 소규모 프로젝트나 간단한 활동을 말합니다. 작업(Task)이란 어떤 단계를 구현하기 위한 일상적인 활동들로, 우리가 스프린트 백로그(sprint backlog)[10]나 간반(Kanban)[11]회의를 통해서 하는 것들입니다. 저는 이러한 GIST의 초기 버전을 구글에서 처음 사용하기 시작했는데, 그 이후로도 수많은 기업들이 이를 구현하는 과정에서 도움을 주고 있습니다.

그런데 작업(task)에 대해서는 GIST에서 뭔가 전혀 새로운 시스템을 도입하려는 것이 아닙니다. 스크럼(scrum)[12]이든, 간반(kanban)이든, XP(eXtreme Programing)[13]이든, 심지어는 우선순위가 지정된 작업 리스트이든, 조직에서 선호하는 용어라면 무엇이든 가능합니다. GIST가 주로 관심을 갖는 것은, 조직이 결과와 영향력을 만들어내기 위해서 언제나 노력하는 것입니다. 즉, 시장에서의 가치를 창출하고 기업에게는 수익을 가져다 주기 위한 활동에 대해서 많은 관심을 가지고 있습니다. GIST는 바로 이러한 과정을 네 개의 레벨로 나누어서 살펴보는 기법이라고 할 수 있습니다.

 

목표(Goal) 레벨은 기업의 모든 부문들이 서로 공통의 언어로 소통하는 영역이며, 보다 더 큰 맥락인 “우리가 이 일을 왜 하는가”라는 질문에 대한 답이 결정되는 곳입니다. 일반적으로 저희는 비즈니스에 있어서 (새로운 온보딩 절차를 만들어 내는 것과 같은) 산출(output)이 아닌 (온보딩 완료 비율을 75%로 끌어올리는 것과 같은) 성과(outcome)에 해당하는 스마트한 목표를 부여하기 위해서 노력합니다. 실제로 조직 내의 모든 팀들이 이러한 목표를 정하기 위해서 함께 참여해야 합니다. 그 방법은 다음과 같습니다.

 

첫 번째의 중요한 단계는 조직의 영향력 평가지표를 정하는 것입니다.대표적으로는 회사가 시장에 창출하는 가치의 양을 측정하는 ‘북극성 지표(North Star Metric, NSM)’와 회사가 (이러한 과정을 통해서) 다시 포착할 수 있는 가치의 양을 측정하는 ‘톱 비즈니스 KPI(Top-Business KPI)’가 있습니다. 이러한 지표들은 기업이 성공으로 간주하는 것이 무엇이며, 모든 구성원들이 마음속에서 가장 우선시해야 하는 것이 무엇인지를 보여주는 것입니다. 기업에서 이루어지는 모든 일들은 조직은 물론이고 각 구성원 개인들의 성장과도 연결되어야 합니다. 이런 과정을 돕기 위해서, 저희는 NSM과 톱 비즈니스 KPI에 영향을 주는 하위 지표들을 만들어 내곤 합니다. 이런 지표들은 성과 지표(outcome metrics)라고 불리며, 여러 가지의 평가지표들로 구성된 트리(tree) 형태의 구조 안에서 배치되는 경우가 많습니다.

 

그런 다음 각 부서별로 이러한 하위 지표들을 할당할 수 있습니다. 예를 들자면, ‘온보딩 완료 비율’이라는 지표는 비즈니스의 성장을 담당하는 부서에게 주어질 수 있습니다. 이렇게 함으로써, 모든 팀들이 비즈니스의 명시적인 목표를 향해서 (또는 다른 팀들이 비즈니스의 목표를 달성하는 것을 돕기 위해서) 노력할 수 있습니다.

 

 

다음으로 우리는 위와 같은 트리 구조에서 가장 중요한 지표들에 대해서 분기별 목표와 연간 목표를 설정할 수 있습니다.여기에서는 일반적으로 ‘목표 및 핵심 결과(OKR)’가 아주 유용하게 쓰입니다. 각 팀들은 각자의 목표를 설정해야 하며, 또한 누락된 목표가 있는지를 찾아내기 위해서 적극적으로 참여해야 합니다. 기술적 부채(technical debt)[14]를 줄이는 것이나 사용자의 프라이버시를 강화하는 것과 같은 트리에서는 구체적인 목표들이 누락되는 경우가 많습니다. 따라서 이러한 누락된 목표를 찾아내는 것은 수많은 기업들을 곤경에 빠트리는 근시안적인 조치를 막기 위해서 중요한 대응방안이라고 할 수 있습니다. 이러한 지표들이 모두 커다란 트리 구조 안에서 서로 관계를 맺고 있기 때문에, 조직 전체가 공동의 목표를 설정하고 동일한 맥락을 공유하는데 도움을 줄 수 있습니다.

 

수많은 조직에서는 어떤 제품이나 비즈니스의 아이디어(Idea) 레벨에 대한 결정권이 회사의 경영진이나 핵심적인 이해당사자들의 특권인 경우가 많습니다. 프로덕트 매니저들은 (그러한 결정권을 가진) 위원회의 의사결정 프로세스를 진행시키는 “실무 담당자”로 전락하기도 합니다. 넷플릭스(Netflix)나 에어비앤비(Airbnb), 부킹닷컴(Booking.com)처럼 근거를 중시하는 기업들은 이와는 다른 급진적인 접근방식을 채택하고 있습니다. 이들은 대부분의 아이디어들이 실질적인 가치를 보여주지 못하기 때문에 수많은 아이디어를 테스트해야 한다는 것을 알고 있습니다. 그들은 아이디어를 짜내고 평가하는 과정에서 제품을 만들어내는 팀들이 적극적으로 참여할 것을 원하며 요구하고 있습니다. 경영진이나 이해당사자들도 여기에서 제외되는 것은 아닙니다. 이들도 아이디어 작업에 참여할 수 있고 발언권을 가지지만, 그들의 의견이 자연스럽게 최고의 아이디어로 받아들여지는 것은 아닙니다.

 

이러한 과정에서 고려해야 하는 사항들은 다음과 같습니다.

  • 개발 팀은 사용자 연구에 있어서 양적으로는 물론이고 질적으로도 관여해야 합니다. 특히 사용자를 관찰하고 그들과의 인터뷰에 참여하는 것이 중요합니다. 이 부분에서는 냉정한 평가와 함께 인간적인 면모가 곁들여져야 하며, 기술적인 측면보다는 고객에 대한 공감이 필요합니다.
  • 각 팀의 구성원들은 교차 기능(cross-functional)[15]팀이나 비즈니스에 집중하는 활동 등을 통해서 해당 비즈니스 부문과 직접적으로 커뮤니케이션을 해야 합니다. (교차 기능 팀에 대해서는 아래에서 좀 더 자세히 다루겠습니다.)
  • 각 팀의 구성원들은 브레인스토밍, 디자인 스프린트(design sprint)[16], 해커톤(hackathon)[17], 가치 매핑(value mapping)[18]등의 활동을 통해서 아이디어 도출에 관여해야 합니다.
  • 이렇게 도출된 새로운 아이디어들은 프로덕트 매니저가 주기적으로 분류해야 하는데, 이 과정에서는 디자인 팀이나 엔지니어링 팀의 리더들로부터 도움을 받는 것이 좋습니다.
  • 아이디어 뱅크나 투명한 아이디어 평가 시스템을 활용합니다. 대표적으로는 영향력(Impact), 확신(Confidence), 난이도(Ease)를 기준으로 평가하는 ICE 기법이 있습니다.
  • 관리자가 아닌 일반 구성원들은 근무 시간의 20%와 해커톤 등을 통해서 자신만의 아이디어에 대해서 연구할 기회를 가져야 합니다.

 

단계(Step) 레벨은 위와 같은 아이디어를 만들어내고 동시에 테스트도 수행하는 단기적인 프로젝트입니다. 예를 들어서 설문조사처럼 혼자서 며칠 동안 일하는 것도 이러한 단계(Step)의 일부라고 할 수 있습니다. 또는 사용 적합성 조사, 스모크 테스트(smoke test)[19], A/B 테스트[20]처럼 교차 기능 팀들이 좀 더 오랜 기간 동안 수행하는 일들도 여기에 속한다고 볼 수 있습니다. 스크럼(scrum)의 측면에서는 이러한 단계가 여러 개의 스프린트에 걸쳐 있을 수도 있지만, 하나의 완전한 스프린트보다는 기간이 더 짧을 수도 있습니다.

 

 

단계별 TF(Step Force)

 

단계별 TF(step force)란 단계별 태스크 포스(step task force)를 줄인 용어입니다. 단계별 TF는 여러 부서의 사람들을 불러 모아서 소집하는 임시 조직으로, 어떤 단계를 계획해서 실행하고, 그를 통해서 생성되는 결과를 수집하고 분석하는 일을 하게 됩니다.이러한 단계별 TF에는 일반적으로 개발자, 디자이너, 데이터 엔지니어/분석가, 프로덕트 매니저 등이 포함되며, 경우에 따라서는 비즈니스 오너가 직접 참여할 수도 있습니다.

 

단계별 TF에 속한 사람들은 요구사항을 정리하거나, 디자인을 하거나, 코드를 작성하거나, 새로운 소프트웨어를 구현하는 일처럼 기존에 자신이 맡고 있던 역할에만 몰두하지 않습니다. 단계별 TF 조직이 맡고 있는 더욱 커다란 임무는 위에서 도출한 아이디어를 어떠한 추정이나 리스크, 가설 등을 대상으로 검증할 수 있는 수준까지 발전시키는 것입니다. 이러한 조직에서는 “완료”라는 의미가 달라집니다. 예를 들어서 어떤 엔지니어가 A/B 테스트를 구현해야 하는 책임을 맡았다면, 그것은 단지 코드를 작성해서 내놓는 것이 아니라, 그 테스트가 올바로 진행될 수 있게 하는 것은 물론이고, 적절한 분석이 이루어질 수 있을 만큼 충분한 양의 데이터를 확보하는 것까지 포함됩니다.

 

그런데 실제로 일을 진행하다 보면, 우리는 특정한 작업에만 사로잡힌 나머지 목표나 아이디어, 단계에 대해서는 잊어버리는 경우가 많습니다. 이를 방지하기 위해서 제가 추천하는 방법은 GIST의 각 항목들을 추적할 수 있는 GIST 보드를 만들어서 활용하는 것입니다.

 

 

실물이든 디지털이든 이러한 보드를 만들면, 단계별 TF 팀이 현재 진행하고 있는 부분이 전체적인 GIST에서 어디에 해당하는 지를 보여줍니다. GIST 보드는 다음과 같이 만들 수 있습니다.

 

  • 목표는 왼쪽: 일반적으로 이러한 목표는 각 분기가 시작할 때 설정한 핵심 결과인 경우가 많습니다.
  • 아이디어는 가운데: 여기에는 이번 분기에 선택한 아이디어를 배치하고, 나머지는 아이디어 뱅크에 넣어 둡니다. 만약 ICE 원칙을 활용하고 있다면, 최신의 ICE 점수까지 적어두는 것이 좋습니다.
  • 단계는 오른쪽: 일반적으로 아이디어 1개마다 2-5개 정도의 단계가 포함되는 것이 적당합니다. 각각의 단계를 완료하는 데 있어서 가장 중요한 역할을 하는 담당자의 이름을 적어두는 것도 좋은 습관입니다. 그 사람은 디자이너나 엔지니어, PM, 데이터 분석가, 마케팅 매니저 등 누구라도 될 수 있습니다.

 

이번 분기에 착수하기로 했던 기술적인 목표나 디자인의 목표들도 이 보드 위에 추가하는 것이 좋습니다. 이런 것들을 숨겨두기보다는, 눈에 잘 띄게 해 놓고 추적하는 것이 중요합니다.

 

그리고 주간 또는 격주 단위로 회의 일정을 세워서, 진행 상황을 점검하고 보드의 내용을 업데이트합니다. 이러한 회의는 주간 또는 격주 단위의 정기적인 애자일 기획 회의를 시작하기 전에 30분 정도 진행되는 간단한 미팅이라도 괜찮습니다. 여기에서 해야 할 일은 해당하는 목표, 아이디어, 단계의 현황을 점검하고, 보드의 내용을 업데이트하는 것입니다. 이렇게 하면 이어지는 작업 일정 논의에 있어서도 아주 훌륭한 도움이 될 수 있습니다.

 

이처럼 정기적인 회의 일정이 하나 더 추가되는 것에 대해서 눈살을 찌푸리는 팀원들도 있을 것입니다. 그러나 일단 이런 미팅을 몇 번 시작하고 나면, 그러한 거부감이 자연스럽게 사라질 것입니다. 엔지니어와 디자이너들은 기존의 일상적인 업무를 벗어나서, 좀 더 커다란 관점에서 이야기를 나눌 수 있다는 것을 높이 평가할 것입니다. 이런 모임을 지속하다 보면, 주어진 목표와는 직접적인 연관성이 없는 스토리 포인트(story point)[21]나 순전히 기술적/디자인적인 문제에 불필요하게 집착하지 않고 원활하게 논의를 진행할 수 있습니다.

 

 

각각의 단계를 작업으로 변환하기

조직 내의 각 부서에서는 이런 과정을 거쳐서 만들어진 프로덕트 백로그를, 스프린트 백로그나 간반 백로그 목록에 넣기 위한 작업(task) 단위로 변환할 수 있을 것입니다. 각각의 단계에 우선순위를 설정하면, 각 팀에서 필요한 정확한 백로그를 만들어낼 수 있습니다.

 

이러한 작업까지 완료되고 나면, 프로덕트 매니저들은 이제 “프로덕트 오너(PO)”로서의 역할에 투자하는 시간을 적극적으로 줄여야 할 필요가 있습니다. 이제 모든 팀들이 동일한 맥락과 명확한 목표를 공유하고 있기 때문에, 그 전보다는 프로덕트 오너로서의 역할에 대한 부담이 상대적으로 줄어들게 됩니다. 이제는 더 이상 구체적인 작업들까지 모두 개입할 필요가 없이, 좀 더 높은 차원의 목표, 아이디어, 단계 레벨에서 상황을 리드하는 것이 좋습니다.

 

 

피드백 루프

정보라는 것은 기업의 위에서 아래로 흐르는 일방적인 형태가 되어서는 안 됩니다. 조직 내의 누구라도 언제든 문제점을 지적하고 발언할 수 있게 해야 합니다. 신뢰를 구축하는 것이 중요합니다. 커뮤니케이션은 많을수록 좋습니다. 그리고 프로덕트 매니저들이 해야 하는 일도 바로 이런 것입니다.

 

조직의 목표나 아이디어 뱅크, 그리고 GIST 보드를 포함해서 이런 방식으로 만들어지는 모든 자료들은 조직 내의 누구라도 쉽게 이용할 수 있어야 합니다. 그러나 경영진이나 비즈니스의 이해당사자들이 그런 자료를 언제든지 들여다볼 수 있다는 생각이 들게 해서는 안 됩니다. 그러지 않으려면 이메일이든 대면 회의를 통해서든, 조직의 목표가 무엇이고, 그것이 어떻게 이루어지고 있으며, 현재 연구가 진행되고 있는 아이디어는 무엇인지, 지금까지 얻어낸 결과는 무엇인지, 그다음 단계는 어떻게 될 것인가 등의 내용을 주기적으로 구성원들에게 공유해야 합니다. 이러한 활동은 새로운 아이디어나 피드백을 요청하기에도 좋은 기회가 될 수 있습니다. 하향식 의사결정 문화에서는 쉽지 않은 시스템인 것입니다. 우리는 몇몇 사람의 의견보다는 근거에 기반해서 결정을 내려야 합니다.

 

마지막으로, 이러한 조직 문화는 모든 구성원들간에 더욱 건강한 관계를 키워나갈 수 있습니다. 프로덕트 매니저, 다양한 이해당사자, 경영진과 여러 부서들이 공동의 이해와 신뢰를 바탕으로 하나의 견고한 조직을 만들어낼 수 있습니다. 프로덕트 매니저들은 더 이상 단순히 로드맵이나 백로그만 담당하는 실무자가 아닙니다. 이제 그들은 고객 전문가, 제품 탐색 과정의 리더, 실행 단계의 조력자로서 제대로 역할을 수행할 수 있어야 합니다.

 

원문: https://itamargilad.com/breaking-the-walls-between-business-and-agile-teams/

 

[1] 끊임 없이 변화하는 환경에서 살아남기 위해서 조직을 기민하게 만들어서 운용하는 기법

[2] 마치 폭포수처럼 지속적으로 아래로 향하는 방식의 순차적인 개발 프로세스

[3] 애자일 조직에서 수행하는 의식적인 절차

[4] 사용자가 요구하는 제품의 기능 목록으로, 모든 요구사항에 대해서 우선순위가 정해져 있음

[5] 애자일 조직에서 활용하는 프로젝트 단위의 목표

[6] 어떤 제품이나 소프트웨어를 실제 사용자가 사용하는 것처럼 이야기의 형태로 쉽게 풀어서 설명하는 것

[7] 어떤 결과물에 대한 테스트를 개발 과정에 지속적으로 반영해서 끊임없이 개선하는 프로세스

[8] 제품 수명주기(life cycle)의 전 단계에 걸쳐서 제품의 개발과 관련된 모든 사항들을 체계적으로 관리하는 것

[9] 목표 및 결과를 추적하기 위한 프레임워크

[10] 스프린트(sprint)를 통해서 백로그(backlog)를 만들어내는 활동

[11] 개발자에게 과도한 부담을 주지 않으면서 적시(just-in-time)에 제품을 출시할 수 있게 하는 개발 기법

[12] 럭비에서 선수들이 스크럼을 짜는 것처럼, 구성원들이 각자의 역할에서 최선을 다하면서 모두가 하나로 결집하여 문제를 해결하기 위한 기법

[13] 고객이 개발 과정에 직접 참여해서 단기간에 생산성을 극대화 하는 프로그래밍 기법

[14] 시간에 쫓겨서 급하게 완성품을 출시하려고 하다 보니, 개발 과정에서 발생한 기술적 결함을 부채(빚)처럼 쌓아두고 가는 것

[15] 한 사람이 여러 부문의 일을 수행하거나, 또는 여러 다양한 부서의 사람들이 하나로 모인 것

[16] 새로운 제품을 디자인 할 때 혁신적인 아이디어를 만들어내기 위한 기획 단계의 프로세스

[17] 여러 명이 팀을 이뤄서 마라톤을 하듯이 긴 시간 동안 어떤 제품에 대한 아이디어나 솔루션을 만드는 이벤트

[18] 어떠한 아이디어가 가치의 창출로 이어지는 과정을 지도처럼 시각적으로 표현하는 것

[19] 어떤 시스템을 본격적으로 테스트하기 전에 동작 여부를 점검하기 위한 일종의 시험 가동

[20] 서로 비교되는 두 가지의 항목을 사용자에게 제시하고 그에 대한 선호도를 평가하는 것

[21] 주어진 유저 스토리를 구현하는 것이 얼마나 어려운지를 측정하는 난이도

댓글 0

요즘IT의 번역글들

이 프로필을 만든 저만 해도 영어가 서툴러 영어로 된 기사는 읽는 게 더딥니다. 그래서 준비했습니다. 읽어볼만한 해외 소식들을 번역해 전합니다. We are the world.

스크럼이 개발자를 괴롭히는 9가지 이유

개발

북극성 지표(North Star Metric) 선택하기

비즈니스

피그마는 여러분을 나쁜 디자이너로 만들고 있습니다

디자인

인터랙션 디자인 vs 시각 디자인

디자인

좋은 디자인 포트폴리오를 만드는 팁

디자인

나에게 맞는 웹 기술 스택을 고르는 방법

개발

윈도우11은 실패작이다

프로덕트

“파이썬은 느리다”에 대한 반론

개발

파이썬 초보자가 저지르는 10가지 실수

개발

우리가 주목할 UI/UX 디자인 트렌드

디자인

2022년 프론트엔드 개발 동향

개발

코드 리뷰 문화

개발

데이터 분석가는 무슨 일을 할까요?

개발

최고의 오픈 소스 개발 도구 Top 8

개발

데이터 분석이란 무엇일까?

개발

Flutter로 UI를 구현하는 방법

개발

자바 언어의 장단점과 2022년 트렌드

개발

데브옵스(DevOps) vs 데브섹옵스(DevSecOps)

개발

엑셀을 사용한 아름다운 데이터 시각화

디자인

여러분을 더 나은 플러터 개발자로 만들어줄 7가지 프로젝트

개발

모든 디자이너가 숙지해야 할 피그마 팁과 노하우

디자인

디자인 원칙과 디자인 가치, 그리고 디자이너

디자인

디자인, 산출물 그 이상을 넘어

디자인

이 회사는 디자인에 투자하고 있는 회사일까요?

디자인

애자일은 정말 디자인을 배제하나요?

디자인

평판 관리가 프리랜서 경력에 미치는 영향

프리랜싱

리액트 네이티브 개발자들이 겪는 가장 빈번한 5가지 문제와 해결책

개발

“솔직히 우리가 하는 것은 스크럼이 아닙니다!”

기획

데이터 시각화가 인류를 위기에서 구한 세 가지 역사적 사건

디자인

NFT의 장밋빛 미래는 사실일까?

기획

피그마 토큰으로 디자인 시스템 만들기

디자인

디자이너+개발자 = 슈퍼팀 만들기

기획

1인 개발자로서 테크 스타트업을 운영하며

기획

웹 디자이너가 PX대신 REM을 사용해야 하는 이유

디자인

100개의 스타트업을 멘토링하며 깨달은 성공의 비밀

기획

중화권 앱 UI가 영미권 앱 UI와 다른 점 알아보기

프로덕트

내가 테크 리더로 일하면서 얻은 8가지 교훈

기획

모두가 즐길 수 있는 디자인 검토 회의 만들기

디자인

프로덕트 매니저에서 프로덕트 마스터로

기획

10배 이상 뛰어난 개발자가 되는 법

개발

제품 디자인 관점에서 바라보는 NFT 아바타 열풍

디자인

에어비앤비: 대규모 iOS 앱 개발 생산성을 위해 바꾼 것들

개발

스포티파이: 맞춤형 플레이리스트 개발 비하인드 스토리

개발

프리랜서가 일하게 될 15가지 유형의 프로젝트

프리랜싱

슬랙: 제품 원칙을 통해 다시 태어난 알림 기능

프로덕트

페이팔: 실시간 그래프 데이터베이스 분석을 통해 사기를 방지하는 방법

개발

트위터: 수십억 개의 이벤트를 실시간 처리하기

개발

슬랙: 4가지 애자일 가치와 방법

기획

스퀘어: 모바일 우선을 넘어 웹에서 누리는 모바일앱 경험

디자인

스포티파이: 카피를 언어로 만드는 UX 라이팅

기획

마이크로소프트: 디자인의 미래를 위한 4가지 원칙

디자인

메타: AR/VR 경험까지 고려한 디자인 청사진

프로덕트

슬랙: 훌륭한 마케팅 카피를 위한 5가지 원칙

기획

2022년 UX/UI 디자인 트렌드

디자인

구글: 가변 폰트의 놀라운 활용법

디자인

에어비앤비: 위기 상황에서의 디자인 원칙 5가지

디자인

어떻게 두 명의 인턴이 수백만 개의 코드들을 보호할 수 있었나

개발

Lattice로 마이크로 프론트엔드를 구축하는 법

개발

Cool Cats NFT를 구축하면서 배운 것

개발

웹 컴포넌트가 프론트엔드 프레임워크를 대신할까?

개발

당신이 NFT에 대해 알아야 할 모든 것

개발

우리에겐 이상하지만 개발자들에겐 일상인 일들

개발

Next.js 12에서 주목해야 할 5가지 변화

개발

스벨트 vs 리액트, 누가 더 뛰어날까?

개발

개발자를 위한 iOS 15의 새로운 기능

개발

내가 오픈소스를 싫어하는 이유

개발

프로덕트 매니지먼트 고객 여정 5단계

기획

클럽하우스의 인기는 모두 거품이었다?

프로덕트

데이터 기반 의사결정의 장점

기획

시각 디자인의 폐쇄성 법칙이란?

디자인

사용자 경험(UX) vs 서비스 디자인

기획

프로덕트 매니저는 하루 종일 무슨 일을 할까?

기획

제품 주도 성장은 어떻게 이루어지는가?

기획

UX를 망치지 않는 설득력 있는 배너 디자인

디자인

팝업(Pop-up)으로 불리는 것들에 대하여

디자인

드롭다운(Drop-down)으로 불리는 것들에 대하여

디자인

당신의 생각을 표현하는 새로운 이모지

디자인

가장 똑똑한 소프트웨어 엔지니어에게 배운 10가지 교훈

개발

성공적인 UX 프로젝트를 위한 가장 중요한 질문

디자인

2021년, UI 디자이너가 모바일 앱에서 흔히 저지르는 실수

디자인

IT 매니저가 되는 방법과 성공하기 위한 요소

기획

슬랙(Slack) 같은 앱을 만들려면 비용이 얼마나 들까?

개발

아웃소싱이 이토록 인기를 얻게 된 이유는?

아웃소싱

마케터가 UX 관련 역량을 키워야 하는 이유

기획

미니멀리즘 디자인의 핵심적인 요소들

디자인

새로운 소프트웨어 개발사가 필요하다는 7가지 신호

아웃소싱

2021년을 이끌어가는 프론트엔드 개발 트렌드 5가지

개발

PM을 성장시키는 학습 프레임워크

기획

UI 카피라이팅, 어떻게 써야 하나요?

기획

트렌드 예측: 경쟁에서 앞서는 방법

기획

제품 사고(product thinking)의 힘

기획

인하우스 vs 아웃소싱, 소프트웨어 개발 어떻게 하나요?

개발

그림을 못 그리는 사람도 쉽게 와이어프레임 그리는 방법

기획

스타트업 기업들에게 아웃소싱이 중요한 이유

아웃소싱

제품과 기능, 성공적으로 종료하는 방법 (下)

기획

제품과 기능, 성공적으로 종료하는 방법 (中)

기획

제품과 기능, 성공적으로 종료하는 방법 (上)

기획

UX 디자이너에게 반드시 필요한 12가지 스킬

디자인

패스워드 없는 세상이 오고 있다

개발

디자이너를 쉽게 잃는 방법 10가지

디자인

프론트엔드 코딩 작업에 영감을 줄 8가지 아이디어

개발

구글이 아웃소싱을 하는 이유: 아웃소싱 성공사례 5가지

아웃소싱

일 잘하는 PM이 되기 위한 로드맵 도구 5가지

기획

이제는 말할 수 있다! 아웃소싱에 대한 오해 11가지

아웃소싱

디자인 트렌드, 모던 미니멀 스타일의 UI 가이드

디자인

MVP 개발을 아웃소싱으로 해도 될까요?

개발

온보딩 효과를 높이는 '좋은' 귀차니즘 3가지

기획

게임처럼 즐겨라, 게임화 기법 TOP3

기획

시니어 소프트웨어 엔지니어는 어떻게 일할까?

개발

프로덕트 매니저가 글을 잘 써야 하는 이유

기획

2030년엔 사라질 수도 있는 프로그래밍 언어 5가지

개발

고객들이 언제나 옳은 것은 아니다

기획

유저 스토리는 무엇인가?

기획

고객 성공을 위한 14계명

기획

8px 그리드 시대가 끝나고, 4px 그리드의 시대가 열릴까?

디자인

모바일 앱은 더 이상 스타트업에게 좋은 아이디어가 아니다

기획

과연 구글의 UX 강좌는 도움이 될까요?

디자인

프로덕트 매니저 여러분, ‘소비자의 요구사항 수집’을 그만두십시오

기획

고객 여정과 경험 지도의 차이점

기획

내가 AI 업계를 떠난 이유 5가지

기획

모달윈도우(팝업)를 디자인할 때 생각할 9가지 원칙

디자인

대기업 vs 중소기업, B2B SaaS 스타트업을 위한 시장은?

기획

내가 개발 인터뷰에서 면접자에게 감동한 이유

개발

HTTP의 새로운 메서드, 서치(SEARCH)에 대하여

개발

세상의 모든 프로덕트 디자이너를 위한 5가지 심리학 원칙

디자인

2021년 테스트 자동화 트렌드 리포트 (下)

개발

2021년 테스트 자동화 트렌드 리포트 (上)

개발

아마존과 스포티파이는 어떻게 사용자를 유지하고 측정할까?

기획

UX 디자이너라면 필수적으로 알아야 할 5가지 법칙

디자인

앵귤러 vs 리액트, 2021년의 승자는?

개발

2021년, SaaS 스타트업 시작을 위한 놀라운 아이디어 10가지

기획

디지털 제품 관리에서 B2B와 B2C 사이의 차이점은?

기획

빠르게 실행할 수 있는 ‘제품 요구사항 문서(PRD)’ 만들기

기획

더 나은 제품을 위한 프로덕트 메트릭스 가이드

기획

노 코드(No Code) 트렌드로 프로그래머들은 일자리를 빼앗길까?

개발

넷플릭스의 플랫폼: 코스모스(Cosmos)에 대하여

프로덕트

효과적인 제품 전략 세우기: 다수의 전략적 트랙(MuST) 활용

기획

1년 만에 이메일 마케팅 효과를 극대화했던 방법

기획

솔루션 아키텍트를 위한 팁: 아키텍처 다이어그램의 5가지 유형

개발

새로운 맥 OS ‘빅서’에 대한 UX 디자이너의 생각

디자인

디자인 트렌드, 뉴모피즘의 정석

디자인

스스로 학습하는 UI/UX 디자이너가 되기 위한 2021년 로드맵, 3편

디자인

스스로 학습하는 UI/UX 디자이너가 되기 위한 2021년 로드맵, 2편

디자인

2021년 모바일 UX 트렌드 10가지

디자인

스스로 학습하는 UI/UX 디자이너가 되기 위한 2021년 로드맵, 1편

디자인

앱 설정 기능의 UX를 개선하는 효과적인 방법

디자인

다크모드 UI 디자인의 원칙

디자인

온라인 고객 경험을 개선하기 위한 5가지 방법

기획

신생 스타트업에서 일하는 프로덕트 매니저를 위한 현실적인 조언

기획

웹 개발자와 소프트웨어 개발자의 차이는 무엇인가요?

개발

랜딩 페이지 디자인을 개선하는 13가지 꿀팁

디자인

오프라인 비즈니스가 온라인에서 존재감을 가져야 하는 이유 5가지

기획

상향식 가격 책정 및 패키징 정책: 사용자 여정을 가이드로 활용하기

기획

B2B 제품의 UX, 그것은 숨겨진 영역인가요?

기획

상단 내비게이션 vs 사이드 내비게이션, 어느 것이 더 나을까?

디자인

자동완성 검색 기능 UX 설계를 위한 8가지 팁

디자인

프로덕트 매니저는 전문적인 IT 기술을 갖춰야 하나요?

기획

실리콘밸리 51개 기업들이 말하는 프로덕트 매니저의 역할 9가지

기획

아웃소싱에 대한 모든 것

아웃소싱

앱 디자인 가이드, 사람들이 즐겁게 사용할 수 있는 앱을 만드는 법

디자인

처음부터 완제품이 아니라 ‘MVP’를 만들어야 한다

기획

플러터 vs 리액트 네이티브 vs 네이티브, 성능이 더 우수한 것은?

개발

스타트업 프로덕트 매니저로 성장하는 법, 30-60-90일 플랜

기획

당신의 두뇌는 진보하고 있다: 성취감을 위한 3가지 전략

기획

디자이너들을 편하게 해주는 HTML/CSS 마법 10가지

디자인

코딩의 미래는 ‘노 코드(No Code)’이다

개발

내가 엔지니어링 매니저로 일하면서 저지른 실수들

개발

내가 롬 리서치(Roam Research)를 좋아하는 이유와 실제 사용법 (下)

기획

내가 롬 리서치(Roam Research)를 좋아하는 이유와 실제 사용법 (上)

기획

프로그레시브 웹 앱(PWA)이란 무엇이며, 왜 필요한가?

개발

PWA vs 네이티브 앱, 어떤 것을 선택해야 할까?

개발

UI 디자인에 여백을 활용하는 8가지 팁

디자인

마이크로소프트와 링크드인의 새로운 시도, 프리랜서 마켓에 도전장을 던지다

기획

토마스넷은 왜 가입자 수를 폭발적으로 늘려준 테스트 결과를 거부했을까?

기획

잘 팔리는 기업용 소프트웨어 디자인하기

디자인

파이어베이스(Firebase)란 무엇인가? 파이어베이스 심층 탐구 : 하편

개발

파이어베이스(Firebase)란 무엇인가? 파이어베이스 심층 탐구 : 중편

개발

파이어베이스(Firebase)란 무엇인가? 파이어베이스 심층 탐구 : 상편

개발

업워크(Upwork)가 조사한 요즘 가장 인기 좋은 개발 기술 15가지

개발

일자리 산업이 휴먼 클라우드(human cloud)에 적응하는 방법

기획

팬데믹 이후 세계에서의 디지털 가속화는 어떤 모습일까?

기획

같은 분야를 다룬 글들을 권해드려요.

요즘 인기있는 이야기들을 권해드려요.

일주일에 한 번!
전문가들의 IT 이야기를 전달해드려요.

[구독하기] 버튼을 누르면 개인정보 처리방침에 동의됩니다.

일주일에 한 번! 전문가들의 요즘IT 이야기를 전달해드려요.

[구독하기] 버튼을 누르면 개인정보 처리방침에 동의됩니다.