개발 환경 구축
개발팀을 어떻게 세팅할 것인가?
모든 사업은 서비스
전략도 우리가 진행할수 있는 상황부터 시작되고 전략적 상수를 확정한 후에는 목적에 맞도록 서비스를 기획, 확장 혹은 Dx 하는 과정이 필요하다.
디지털 기반의 비즈니스 뿐만 아니라, 디지털 전환이 빠르게 일어나면서 최근 UX 의 중요성이 더욱 높아졌습니다.
프로덕트 성공을 위한 3요소
프로덕트 성공을 좌우하는 것은 균형 - 제품 시장에 접합한 프로덕트를 기획하고 개발 단계를 설정하여, 성공 기준을 우선 만들고(내부에 모든 구성원에게 컨펌을 하고) 시작해야 한다.
1. 비전
2. 사용자 가치
3. 사업 수익
제품 개발론 인하우스 VS 아웃소싱 = 하이브리드
1. 인하우스 개발이 메인이되 아웃소싱 개발도 적절히 활용해야
인하우스 개발팀은 아웃소싱에 필요한 업무 난이도를 낮추고, 비효율을 제거하는 “R&D” 역할.
이 과정에서 인하우스 개발팀은 자연스럽게 프로세스 중심의 경직된 일 문화를 가지게 된다.
외부 환경의 변화가 적다면 좋은 선택이 될 수도 있지만. 대부분의 경우 개발팀의 경직성이 사업을 방해
내일만 하려는 개발자들이 모이게 되면 대부분 조직의 문화가 형성되기 마련.
[인하우스 개발방식이 선호되는 사례]
첫째, 소프트웨어가 제품인 경우. 소프트웨어가 기업이 돈을 벌어들이게 해주는 직접 재화인 경우는 100%가 아니라 50%만 해당하여도 인하우스 개발해야 합니다.
예) “테슬라”에서 자율주행은 빼놓을 수 없는 기능이죠. 제품을 만드는 강력한 구성 요소. 인하우스 개발팀이 필요
둘째, 시장 변화에 맞춰 제품을 빠르게 바꿔야 하는 경우. 빠르게 움직이려면 “우리 직원”이라는 운명 공동체 의식이 필요하죠. 느리게 대응해도 좋다면 아웃소싱으로도 충분.
셋째, 노하우가 중요한 경우. 노하우는 제품을 개량하기 위한 강력한 수단으로 시행착오를 통해서만 축적그리고 그 분량만큼 후발주자와의 거리도 차이가 생김. 아웃소싱을 하면 노하우는 외부 업체에 축적되고 우리 제품을 더 좋게 만들기 어렵게 됨.
넷째, 보안. 아웃소싱을 하면 어쨌든 정보는 유출. 정보 유출이 사업에 큰 영향을 미친다면 인하우스 개발이 필수.
2. 내부 개발팀과 환경의 세팅
돈은 얼마나 들까
보통 첫해에 제품을 만들고, 둘째 해에 고객을 만들고, 셋째 해에 매출을 만들자.
그다음에 손익분기점(BEP)을 넘기도록 계획. 창업자는 이 기간을 버틸 수 있도록 돈을 구해와야 합니다. 단순 계산으로도 3년에 20억 원 정도 조달해야 하죠. 빌리거나 투자를 받아야 합니다.
개발자 구직
좋은 개발자는 어떻게 구해야 할까?
첫째, 좋은 개발자는 찾아다녀야 합니다.
둘째, 채용 공고는 긴 호흡으로 냅니다.
셋째, 우리가 하는 일을 잘 알려야 합니다.
기술 블로그나 SNS 등 우리가 하고 있는 일을 널리 알립니다. 돈이 되진 않습니다. 그래도 많이 알릴수록 핏이 맞는 사람을 만나게 될 확률이 큽니다.
마지막으로, 좋은 채용 전략은 좋은 인력풀과 오랫동안 스킨십을 맺는 겁니다.
좋은 인재는 절대 한 번에 들어오지 않습니다. 한 명씩 한 명씩 채워 좋은 개발팀이 되는 겁니다.
제품 개발 방식
유저 리서치 - 정보 설계 - 유저 시나리오 - 와이어프레임 - 디자인 시스템 - UI 디자인 최종 산출물 - 프로토타입 - 사용성 테스트
(1) 순차적 제품 개발 프로세스(워터폴 방식)
포지션 구성: 기획자, UI 디자이너, 개발자.
디자이너는 기획자가 만든 와이어프레임을 전달. 그 후 UI를 디자인하여 개발자에게 전달.
디자인 시스템 구축, 유지보수하기 좋은 컴포넌트 제작, 비주얼라이제이션 등의 UI 디자인 능력이 중요
워터폴 모델의 제품 개발 프로세스가 선호되지 않는 이유
1. 고객은 요구사항의 반영 여부를 파악하기 어렵다.
2. 고객의 수정 요청 발생시 수정이 어렵다.
3. 결과물이 고객의 요구사항과 동떨어질 수도 있다.
(2) 가설과 검증을 끊임없이 반복(린스타트업)
포지션 구성: 프로덕트 매니저, 프로덕트 디자이너, 개발자
MVP*를 출시하고 데이터를 측정,배운 것은 다음 버전에 반영.
만약 배운 것이 기존 계획과 다르면 방향을 틀기도 하는데, 이를 피벗*이라 함.
린스타트업 방식의 특징
빠르게 변하는 시장에서 제품을 오래 만들기보다 빨리 만들고 반응을 읽을 수 있어 효율적이다.
하지만 그 과정에서 제품의 완성도가 지나치게 떨어질 위험성도 있다.
*MVP(Minimum Viable Product): 최소 요건 제품을 뜻한다.
*피벗(Pivot): 회전한다는 뜻이다.
(3) 반복주기마다 프로토타입 제작 후 고객의 요구사항에 대응(애자일 방식) - 린 스타트업과 비슷
포지션 구성: 프로덕트 매니저, 프로덕트 디자이너, 개발자
5~7명의 팀원과 스크럼 마스터로 팀이 구성된다. 일반적으로 대규모 프로젝트를 2~4주 단위의 스프린트로 분할하여 진행한다.
*스크럼(Scrum): 반복주기 동안 소수 인원이 집중적으로 제품을 개발하는 애자일 방법론이다.
스크럼 프로세스:
제품 백로그 작성 - 스프린트 플래닝 회의 - 스프린트 백로그 작성 - 일일 스크럼 미팅 - 제품 개발 - 스프린트 리뷰 - 스프린트 회고
(4) 사용자에 대한 공감을 중심으로 문제를 해결(디자인 씽킹) - 2+3+마케팅
IDEO의 CEO 팀 브라운(Tim Brown)으로 인해 유명해지면서 많은 기업에서 사용된 방식
1. 공감하기: 사용자 리서치를 통해 사용자를 이해한다.
예: 사용자 데모그라피 조사, 제품 구매 시 행태, 니즈 파악 1:1 인터뷰 등
2. 정의하기: 앞의 리서치를 토대로 데이터 분석 후 인사이트를 도출한다. 사용자가 겪는 어려움이 있다면 문제점을 정의한다.
3. 아이데이션: 앞서 정의한 문제점을 해결하기 위한 단계이다.
브레인스토밍 후 경쟁사나 레퍼런스의 UI·UX를 리서치한다.
4. 프로토타입: 사용자에게 테스트하기 위한 제품 시뮬레이션/샘플 버전을 개발한다.
5. 테스트: 프로토타입에 대한 고객의 피드백을 받아 개선한다.
예: 유저 테스트, a/b 테스트 등
3. 개발 관련 프로세스 만들기
개발팀의 변화
인하우스 개발팀은 아웃소싱 팀처럼 변하려는 경향이 있습니다. 분업화, 프로세스화 될수록 말이죠.
수익화 방식이 정해지고 사업 환경이 안정되면, 기술 환경도 안정됩니다. 그러면 기업은 낭비를 줄여 이윤을 높이려는 시도를 하죠. 이른바 효율화입니다.
“ 분업 - 프로세스 - 반복 ”
“분업”은 업무 간 결합도를 낮춰 책임이 넘어가는 걸 막아줍니다. 남의 일은 생각할 필요가 없음.
“프로세스”는 생산 과정을 안정화 시킵니다. 프로세스가 시킨 대로만 해도 결과물이 나오도록.
“반복”은 숙달을 통해 생산성을 높여줍니다. 좀 더 짧은 시간에 완성도 올리기.
이 모습은 어느 정도 “SI”와 닮아 있습니다. SI가 제조업의 효율화 방식을 벤치마킹했으니까요.
3. 개발조직과 운영 조직
개발팀과 운영팀
오류를 줄일 땐 프로세스화가 필요
프로세스는 “불신”을 바탕으로 설계, 옆에서 지속적으로 체크하는 조직을 만들어야함
체크하지 않은 것은 다 오류일 수 있다는 가정하에 접근, 느리지만 점검하지 않는 건 모른다고 가정하고 시작
“운영팀”은 이렇게 프로세스 기반으로 구성
안정성, 항상성, 지속성이 중요 업무적 중복이라는 문제가 발생할수 있고 이는 관리자가 개입해서 자꾸 없애줘야 함
“스케치해 보고 개발”, 이 과정을 반복. 관리 문서가 아니라 결과물과 개발 코드를 보면서 진도 진행
개발팀 푸쉬와 개발 문화
문화는 제도 → 분위기 → 습관 → 관습을 거쳐 만들어집니다.
다만, 코드의 양, 일의 범위, 기존 프로세스와 충돌 등이 변화의 속도를 느리게 만듭니다.
그래서 큰 기업들은 CIC(Company In Company) 형태로 작은 스타트업을 만들거나 작은 스타트업을 인수하기도 합니다. 개발 문화를 바꾸기 위한 불씨로 쓰죠.
일을 하다 보면 반드시 사고가 일어납니다.
분업화, 프로세스화는 사람의 책임을 덜어줍니다.
매뉴얼, 표준화를 통해 문제를 해결하니까요.
시킨 대로 한 사람은 잘못이 없습니다. 단계가 길고 복잡한 업무를 반복해야 할 경우 좋은 선택이죠.
기업은 평이한 개발자를 뽑습니다. 설계는 비싸게 합니다.
복잡한 문제는 구조를 통해 해결하고, 업무 완성도는 반복 숙달을 통해 높입니다.
프로세스가 계속 늘어납니다.
사람도 계속 늘어납니다. 프로세스가 길어지면 시장 변화에 쉽게 대응하기 힘듭니다.
고수 개발자를 뽑아야 합니다.
이것저것 다 해본 사람이니 일하기 편리하고, 결과 빨리 나오고, 소통도 잘 됩니다. 교육 훈련도 필요 없죠. 다만 연봉이 비쌉니다.
개인사가 만사
좋은 채용 전략
어떤 사람을 뽑아야 할까요? 어떻게 뽑고, 어떻게 관리해야 할까요?
우리 고객의 67%가 IT 팀을 확장할 계획을 갖고 있다.
그러나, 90%의 회사가 적임자를 못 찾고 있다.
개발자의 86%는 현재 취업 상태로 이직 의사가 별로 없다.
개발자 채용에는 최소 며칠 ~ 최대 4개월이 걸린다.
채용 담당자의 75%는 입사 제안을 거절당해 본 적이 있다.
거절한 개발자의 53%는 다른 곳에서 더 좋은 제안을 받았다고 한다.
