제목 : UX/디자이너/기획자들을 위한 개발이야기(HCI연구회 2월 세미나)
강사 : NHN 이철혁 과장
일시 : 20130227
[강의록]
- 접수 1일 내 강의 신청이 마감됨
--> 개발에 대해 알고 싶은 마음이 크다는 점을 반증.
- 2시간은 개발을 배우기에 찰나의 시간.
--> 강의 목표 : 개발자와의 협업을 어떻게 유연하게 할 수 있을까?
- 개발 용어 어려워요.
--- api를 wikipedia에서 검색해보자.
--- 보면 설명글도 이해하기 어렵다.
--- 원래 '개발'이라는 것을 설명하기가 쉽지가 않다.
--- 그러나 쉽게 설명하려는 시도가 늘고 있다.
--- (예) 페이스북 생활코딩(개발관련 질의응답 사이트)
-> 뭘 모르는지 알 수 있게 해주는 게 목적
-> 물어볼 때 정확하게 모르는 부분을 지정하면 원하는 답을 얻기가 수월하다.
- 소프트웨어 위기
--- 개발 완료 후 쓸 수 있는 게 5% 정도 밖에 안됨.
--- 원인 : 대규모화, 복잡화, 고가격, 필요교육 증가.
- 위기의 극복 : 소프트웨어 엔지니어링
--- 표준화, 분업화, 균일품질 이론을 도입하여 성공율을 높이고자 함.
- 프로그래밍?
--- 요구사항 분석, 설계, 프로그램 작성, 테스트, 배포, 유지보수가 모두 포함됨.
- 개발 방법론
--- 구조적 개발방법론/객체지향 개발방법론/Agile
--- 도입 후 위기를 극복했으나 성공율은 여전히 30% 내외이다.
--- 50% 이상 프로젝트가 심각한 비용 초과 발생
--- 우리나라도 동일하다.
---> 개발자가 무능한 것이 아니다.
- 그럼 실패하는 원인은 무엇인가?
--- (예) 부르즈 칼리파 : 유동적 설계로 만들면서 설계했으나 비용 초과 되지 않음.
--- (예) 비씨 차세대 시스템 : 500억, 500명 투입했으나 오픈 실패했고 현재도 진행 중??
---차이의 이유는?
---> 건축은 오랜 역사로 양적인 추측이 가능하다. (블루프린트, 3D, 목업 등)
---> 결과물이 어떻게 될지 충분히 상상이 됨. => 프로토타이핑의 중요성 확인.
- 소프트웨어는?
--- 프로토타이핑이 쉽게 무시되고 있다.
--- 제대로된 설계서가 없이 진행된다.
--- 소프트웨어의 비 가시성
---> 진행 사항에 대한 정확한 판단이 어렵기 때문에 수정 요청 및 수용에 대한 부담감이 적음.
- 수정 비용
--- 프로젝트 진행 단계 중 수정이 뒷단에 일어나면 날수록 비용은 기하 급수적으로 늘게 된다.
- 개발자들이 변경을 싫어하는 이유
--- 변경 시 유지/관리에 영향을 미치므로 항상 조심할 수 밖에 없다.
--- (예) 페이스북 처럼 로그인을 계속 유지하게 해주세요
--->로그인 유지만 필요한게 아니라 로그인 후 페이지 요청량 늘어날 것을 대비해서 서버 증설 준비, 보안 검토 등..개발에서 고민할게 너무 많다.
--- 수정/변경 관련된 부분은 개발자와 직접 얘기해야 한다. (바꿔야 할 당사자가 의사결정을 함께 해야 한다.)
- 건축은 일정이 어떻게 맞나?
--- KPI 사이트 : 역사가 오래돼서 일정과 가격을 표준화하여 산정할 수 있다.
- 개발 일정 산출이 어려운 이유는?
--- '감'으로 잡는다.
--- Man-Month : 개발 투입 자원을 시간단위로 표시하는 것
--- 완료 산출물이 비가시적인 상태에서 정확한 일정 산출을 하는 것은 거의 불가능하다.
- 개발 일정 산출 사례
--- 3명이 4달 = 12명 1달?
--- 모두 역량이 다르므로 단순 계산을 하면 안된다.
--- 인원이 많으면 의사소통에 소요되는 시간이 늘어나므로 단순 계산을 할 수 없다.
--- 사람을 리소스로 산정한다는 자체가 말이 안된다.
--- 팀 생산성은 팀원이 한명 더 추가될 경우 뚝 떨어진다.
- Brooks의 법칙
--- 지체된 프로젝트에 추가 인원을 투입하면 프로젝트는 더 늦어진다.
--- 새 인력이 익숙해질 때까지 학습 곡선 떨어지며 인력이 증가할 수록 커뮤니케이션 복잡도가 증가한다.
- Human Intensive
--- 개발자 사이 생산성 차이는 30배 이상이다.
--- 그러므로 동일한 1MM 기준으로 정확한 일정을 산출하기는 힘들다.
--- 그 개발자는 하루면 한다던데.... X
--- (예) 주식의 예측 시스템 : 과거 데이터 + 전문가 경험 + 리스크 반영 => 그래도 정확한 예측은 힘들다.
--- 개발도 이와 유사하다.
- 경험에 의한 판단
--- 개발자는 대부분 일정을 짧게 말하는 경향이 있다.(능력과 자존심 문제라고 생각함)
--- 각 MM을 아래와 같이 예측하는 것이 맞음.
---- 고급개발자 = 1MM X 110~130%
---- 중급개발자 = 1MM X 150~200%
---- 초급개발자 = 1MM X 200~300%
-그렇다면 초/중/고급 정의는?
--- 소프트웨어기술자 등급분류 기준표가 있다.
--- 기준표에 따라 단가를 측정하는데 기준은 연차이다.
--- 이 기준에 따라 비용이 산정 되므로 제대로 일정이 산출된 개발을 하기가 어렵다.
- Agile 방법론
--- Story point
매일 아침 모여서 회의. 어제/오늘 한일을 짧게 공유. 문제점만 공유, 서서하는 것이 포인트.
- 방법론
--- (예전 : 폭포수식) 계획 - 분석 - 설계 - 구현 - 테스트 - 유지보수
--- 기능 단계별 위 프로세스를 거침 : 개발 - 테스트 - 피드백
--- > 나눠서 짧게 개발.
--- > Pair Programming(짝코딩)
우리 나라는 100% 실패함.(선임, 후임의 관계이기 때문)
운전자와 네비게이션 방식이 되어야 한다.
--- 주당 40시간만 일해라
- 기획자/디자이너가 알면 좋은 개발 기술은?
--- 441개 혹은 그 이상의 개발 언어 존재
--- markup language는? 언어를 어떻게 구성할지에 대한 것.
--- script vs language : 등한시 된 적도 있으나 현재는 선호됨.
--- Top language : Java script : 21% 점유하고 있음.
- 서버란?
--- 물리적 컴퓨터 또는 서버일을 하는 소프트웨어.
- 버그가 왜 이렇게 많나요?
--- 개발자 자질 보다 일정 미 고려가 문제일 수 있다..
--- 개발 초기에 프로젝트, 서비스에 대한 이해가 부족함이 원인일 수 있다.(기획단계 부터 개발자 참여 필요)
--- 개발 단계에도 기획/디자인이 적극적으로 참여할 필요 있따.
- 버그에도 우선순위가 있다.
--- 한 개발자가 하나의 버그를 잡을 수 없으므로 우선순위를 만들어 협의하는 과정 필요하다.
--- 개발자는 개발과 커뮤니케이션을 동시에 할 수 없다.
- 일정과 스펙 중 하나만 선택
--- 둘다 정하면 개발자는 영혼없이 코딩만 하게된다. -> 의견을 물어보고 조율해야 한다.
- 개발 트렌드를 아는 법
--- zdnet, 전자신문 등.
--- 개발자와 페이스북 친구가 되어 유심히 보면 된다.
- 이렇게 까지 개발을 이해 해야 하나?
--- 차라리 내가 개발한다고 생각이 들 수 있음. 더치개(더럽고 치사해서 개발 내가 한다)
---> 진정한 능력자가 아니고서야 혼자서 기획/디자인/개발을 다 할 수 없다.
- 소통의 문제
--- 모르는 개발 용어를 쓴다면 -> 배우자.
--- 개발자가 우긴다고 생각이 들면 -> 개발자를 사용자라고 생각하고 설득해보자
--- 상호 존중과 배려 속에 소통이 가능하다.
[내 생각]
- 개발 환경에 대한 기본적 문제를 그동안 간과하고 개발자 탓만 한 것은 아닌지 반성.
- 개발자도 쉽고 재미있게 지식을 전달할 수 있다는 사실(?) 확인.
- 경험 DB를 통한 정확한 MM과 일정을 뽑는 것이 가장 중요함을 인식.
- 시나리오에 모든 내용을 담으려 해왔으나, 잦은 소통을 통한 상호 이해가 중요함을 인정.
- 그래도 답답하다면, 개발은 배워서라도 아는 게 낫다는 생각.
LNstory :D
.png)
.png)
.png)
