박안나 과장님과 하는 마케팅 스터디 첫 책.
오병곤님이 쓰신 대한민국 개발자 희망보고서
지금 다시 보니까 병곤님은 우리학교 선배님이셨네요.
이공계 출신도 아니시고 IT쪽 업체 근무하시다가 프로그래밍에 빠져 이쪽 일 하신다고.
오병곤님이 쓰신 대한민국 개발자 희망보고서
지금 다시 보니까 병곤님은 우리학교 선배님이셨네요.
이공계 출신도 아니시고 IT쪽 업체 근무하시다가 프로그래밍에 빠져 이쪽 일 하신다고.
[프롤로그] 변화를 통한 새 길 트기
1부 [생존] IT 업계에서 살아가기
1장 불타는 갑판
월화수목금금금
사무실이 기가 막혀
5개월 만에 출산하기
뫼비우스의 띠
레드오션(Red Ocean)
2장 동굴의 우상(偶像)
소프트웨어 진짜 위기
일단 짜보고 고치기
실패하는 프로젝트의 7가지 습관
2부 [정진] 소프트웨어 개발 잘하기
3장 개발 생산성 혁신
요구사항을 개발하라
프로토타이핑 퍼포먼스
아키텍처를 아시나요?
모델링, 씨줄과 날줄
지금은 스타일 시대
명세 없이 코드 없다
인정사정 볼 것 없다
재사용은 양치기 소년
4장 관계지향 프로그래밍
프로그래밍을 바라보는 4가지 시선
팀 플레이 프로그래밍
eXtreme Programming
XP를 프로젝트에 적용하기
5장 연금술
프로그래머와 글쓰기
커뮤니케이션 능력 향상
혼이 있는 소프트웨어 개발
3부 [도약] 프로젝트 성공하기
6장 프로세스 혁신
기업의 뼈대, 프로세스
프로젝트 전반부에 집중하라
계획 무용론 VS 계획 결정론
프로젝트의 원죄, 추정
일정 단축하기
소프트웨어는 소프트 하지 않다
동료 성토? 동료 검토!
품질은 여유 있는 자들의 행복한 비명
프로젝트 중심에서 위험을 외치다
실패를 통해 배운다
7장 고객 중심 프로젝트
고객에 대한 깊은 이해
고객 참여와 협상
8장 숨겨진 힘, 사람
사람을 최우선으로 대하라
드림 팀을 꿈꾸며
PM은 리더다
개발자 채용하기
4부 [비전] IT 전문가로 성장하기
9장 IT 전문가의 조건
전문가로 가는 길
IT 전문가 프로필의 변화
스티브 잡스와 안철수
10장 IT 전문가 경력개발
IT 지식체계
개발자 경력 로드맵
나의 기술사 도전기
IT 전문가 육성하기
-----------------------------------------------------------------------------
IT업계의 현실, 개발자들의 현실과 개선 방법을 모든 방향에 걸쳐 제시한 책이다.
불타는 갑판: IT업계의 현실은 암울하다.
저가 수주, 계속되는 요구사항 변경, 밤샘 근무, 비인간적인 대우로 한때 전문직으로 선망의 대상이었던 개발자라는 직업은 이제 3D업종이라고 불러도 될 만하다. 책 속에 예로 나온 사례에서 어떤 개발자는 데이트할 시간이 없어서 결혼을 위해 직업을 바꾸는 극단적인 방법을 사용하기도 했다고 한다. 또 다른 사례에서는 아직 건설이 끝나지도 않은 공사장 한켠의 사무실로 출근해서 에어콘도 없는 사무실에서 개발을 하기도 했다고 한다. 또한 Work Smart 하는 사람보다 무조건 Work Hard 하는 사람에 대해 더 관대한 현실이 답답하다.
계획
계획을 필요 없는 것이라고 생각하는 사람도 많다. 계획을 세워놓고 지키지 않기 때문이다. 또한 프로젝트 납기가 촉박한 경우 결과물을 바로 보고 싶어하기 때문에 무작정 코딩부터 시작하는 경우가 많다. 하지만 계획 없이 '무조건 코딩하고 나중에 고치기'(Code & Fix Development)식으로 개발하면 전체적인 설계 없이 맹목적인 개발이 되기 쉽고 더 효율적인 방법을 간과할 수 있다. 계획이 쓸데없는 것 같아도 미리 전체 그림을 파악하고 설계한 후 개발하는 것이 나중의 큰 실수를 막는 길이다.
계획 과정에서 세가지 방법 중 가장 나은 한가지를 선택하면 세개의 작을 실수를 하는 것이지만 한가지 방법으로 개발하다 문제가 생겨 다른 방법을 사용해보고 다시 다른 방법을 사용해서 문제를 해결했다면 큰 세가지 실수를 만든 것이다.
요구사항 개발
프로그램 사용자와 영업하는 사람, 분석가, 개발자가 보는 최종 제품은 모두 다르다. 고객은 그것을 알고 있지만 잘 표현하지 않고, 잘 표현할 줄 모른다. 또한 개발자는 기술적인 언어로 말하고 사용자는 비즈니스 언어로 얘기한다. 이런 커뮤니케이션의 어려움이 개발의 어려움이 되고 프로젝트 납기가 지연되고 더 많은 비용이 들어가게 한다. 개발 시간 중 프로그래밍의 오류로 인한 재개발 시간은 5~10% 정도이고 고객의 요구사항 변경으로 인한 재개발이 나머지를 차지한다. 고객의 요구사항은 프로젝트 기간 내내 변할 수 있지만 프로젝트 초기에 대부분의 변화가 있어야 하고 시간이 지날 수록 점점 줄어들어야 한다. 또한 프로토타입을 보여주는등 사용자와의 커뮤니케이션을 통해 고객의 요구사항을 정확히 파악하여야 하고 최대한 문서화하고 구두 커뮤니케이션을 줄여야 한다. 또한 고객사의 전산실과만 커뮤니케이션하여 정작 프로그램을 사용할 고객들의 요구를 수용하지 못한 경우가 있었다. 항상 고객의 목소리를 듣고 요구사항을 누락하지 않고 정확히 파악해 품질을 높여야 한다.
XP
eXtreme Programming.
프로젝트 과정에서 고객의 참여와 팀원들간의 커뮤니케이션을 중시하는 개발 방법론이다. 짝 프로그래밍(Pair Programming)이 흥미로웠는데 같은 작업을 두명의 개발자가 팀을 이뤄서 수행하는 방법론이다. 두명이 의견을 나누면서 좀 더 효율적인 개발을 할 수 있는데 알고리즘에 대한 토론을 통해 최선의 방법을 선택할 수 있고, 자신이 가지고 있는 문제점을 상대방에게 설명하면서 자연스럽게 해결방법을 도출할 수 있다고도 한다. 또한 두명이기 때문에 좀 더 대담하게 새로운 방법이나 시도를 할 수 있다고 한다. 친구가 자신의 의견에 동조해주면 혼자 결정할 때보다 부담이 덜 하고 확신이 생기니까 그럴듯? 고객이 프로젝트 기간동안 개발팀과 같이 생활해야 한다는 것도 신선했다. 같이 밥먹고 프로젝트 이야기 하면 결과물은 당연히 좋겠지요~ 그렇지만 어떤 사람이 가서 생활하느냐가 문젠데... 우리나라 현실에서 일 잘하고 어느정도 넓은 시야를 가진 사람-개발 과정에서 건설적인 의견을 주고받을 수 있는 사람-을 몇달동안 실무에서 배제하고 개발팀에 넣을 수 있을까? 하는 생각이 든다.
그리고 팀내 리뷰는 참 좋은 방법인듯.
내가 하는게 맞는걸까 하는 의문이 들고 다른 사람의 생각은 어떨까 하는 궁금증이 들기도 하고 다른 사람은 무슨 일을 어떻게 할까 할때.... 팀원들끼리 리뷰 시간을 가지면 좋을 것 같다. 서로의 일에 대한 깊은 이해를 가질 수 있고, 자신감과 긍정적인 피드백을 받는 시간이 될 수도 있겠다. 방법은 공식적인 회의 같이 하는 방법, 상대방에게 즉석에서 '내가 한건데 좀 봐줘' 하는 방법 등등이 있다고....
커뮤니케이션
커뮤니케이션이 중요하다고 한다. 매니져급으로 갈수록 글이나 구두로 하는 커뮤니케이션이 중요한데 많은 매니져들이 커뮤니케이션이 어려워 고생을 많이 한다고 한다. 특히 고객과의 커뮤니케이션에서 요구사항을 잘못 파악하거나 기술적으로 어려운 것을 약속하면 아래 개발자들이 많은 고생을 하고 프로젝트 전체의 품질도 영향을 받는다. 프로젝트의 커뮤니케이션은 문학적인 커뮤니케이션이 아니다. 기술적인 내용을 간결하고 명확하게 전달하면 된다. 그것을 위해서 많이 연습해보고 많이 써야 한다. 인재 채용시에도 개발 능력이 어느정도 갖춰진 사람이라면 이력서의 문체, 문법, 어투 등등 커뮤니케이션 태도를 고려하여 채용하는 것이 바랍직하다.
ISTJ
40% 이상의 개발자들이 ISTJ 유형의 성격을 가지고 있다고 한다.
I는 내향적, S는 감각적, T는 사고적, J는 판단적.....
내가 INTJ인데... 세개나 겹친다.....
그분들은 나랑 비슷한 분들인건가??????????????????????????????????
◇ISTJ(세상의 소금형)=일처리시 신중하며 책임감이 강하다. 보수적인 경향이 있으며 문제 해결시 과거경험을 잘 적용한다. 매사에 철저하고 사리분별력이 뛰어나다.
스티브 잡스, 안철수
잡스 아저씨는 혁신을 중요시하고 실패를 두려워하지 않았다.
'시장조사따위는 하지 않는다. 혁신만을 생각한. 에디슨이 전구 만들때도 그랬다.'
라는 말을 했다고 한다. 이런 자신감과 뚝심이 지금 애플이 개성있고 혁신적인 제품으로 시장에 돌풍을 일으키고 있는 것 같다. 또한 안철수님은 항상 겸손하고 성실했다. 이러한 성품을 바탕으로 우리나라 최고의 보안 업체를 운영했고 원칙에 입각해서 경영했다. 원칙은 평소에는 별것 아닌 것 같지만 위기 상황에서 모두가 우왕좌왕 할 때 모두가 의지할 수 있는 기둥이 되어 빛을 발한다.
약간 지루하기는 했지만 IT업계에서 개발자분들이 어떤 생활을 하고 있는지, 그들이 더 나은 작업 환경과 효율적인 업무를 하기 위해 어떤 노력을 하고 있는지 볼 수 있었다.
요구사항 개발, XP 방법론, 상류 단계가 중요하다는 것, PM의 요건 등이 유익했다.
1부 [생존] IT 업계에서 살아가기
1장 불타는 갑판
월화수목금금금
사무실이 기가 막혀
5개월 만에 출산하기
뫼비우스의 띠
레드오션(Red Ocean)
2장 동굴의 우상(偶像)
소프트웨어 진짜 위기
일단 짜보고 고치기
실패하는 프로젝트의 7가지 습관
2부 [정진] 소프트웨어 개발 잘하기
3장 개발 생산성 혁신
요구사항을 개발하라
프로토타이핑 퍼포먼스
아키텍처를 아시나요?
모델링, 씨줄과 날줄
지금은 스타일 시대
명세 없이 코드 없다
인정사정 볼 것 없다
재사용은 양치기 소년
4장 관계지향 프로그래밍
프로그래밍을 바라보는 4가지 시선
팀 플레이 프로그래밍
eXtreme Programming
XP를 프로젝트에 적용하기
5장 연금술
프로그래머와 글쓰기
커뮤니케이션 능력 향상
혼이 있는 소프트웨어 개발
3부 [도약] 프로젝트 성공하기
6장 프로세스 혁신
기업의 뼈대, 프로세스
프로젝트 전반부에 집중하라
계획 무용론 VS 계획 결정론
프로젝트의 원죄, 추정
일정 단축하기
소프트웨어는 소프트 하지 않다
동료 성토? 동료 검토!
품질은 여유 있는 자들의 행복한 비명
프로젝트 중심에서 위험을 외치다
실패를 통해 배운다
7장 고객 중심 프로젝트
고객에 대한 깊은 이해
고객 참여와 협상
8장 숨겨진 힘, 사람
사람을 최우선으로 대하라
드림 팀을 꿈꾸며
PM은 리더다
개발자 채용하기
4부 [비전] IT 전문가로 성장하기
9장 IT 전문가의 조건
전문가로 가는 길
IT 전문가 프로필의 변화
스티브 잡스와 안철수
10장 IT 전문가 경력개발
IT 지식체계
개발자 경력 로드맵
나의 기술사 도전기
IT 전문가 육성하기
-----------------------------------------------------------------------------
IT업계의 현실, 개발자들의 현실과 개선 방법을 모든 방향에 걸쳐 제시한 책이다.
불타는 갑판: IT업계의 현실은 암울하다.
저가 수주, 계속되는 요구사항 변경, 밤샘 근무, 비인간적인 대우로 한때 전문직으로 선망의 대상이었던 개발자라는 직업은 이제 3D업종이라고 불러도 될 만하다. 책 속에 예로 나온 사례에서 어떤 개발자는 데이트할 시간이 없어서 결혼을 위해 직업을 바꾸는 극단적인 방법을 사용하기도 했다고 한다. 또 다른 사례에서는 아직 건설이 끝나지도 않은 공사장 한켠의 사무실로 출근해서 에어콘도 없는 사무실에서 개발을 하기도 했다고 한다. 또한 Work Smart 하는 사람보다 무조건 Work Hard 하는 사람에 대해 더 관대한 현실이 답답하다.
계획
계획을 필요 없는 것이라고 생각하는 사람도 많다. 계획을 세워놓고 지키지 않기 때문이다. 또한 프로젝트 납기가 촉박한 경우 결과물을 바로 보고 싶어하기 때문에 무작정 코딩부터 시작하는 경우가 많다. 하지만 계획 없이 '무조건 코딩하고 나중에 고치기'(Code & Fix Development)식으로 개발하면 전체적인 설계 없이 맹목적인 개발이 되기 쉽고 더 효율적인 방법을 간과할 수 있다. 계획이 쓸데없는 것 같아도 미리 전체 그림을 파악하고 설계한 후 개발하는 것이 나중의 큰 실수를 막는 길이다.
계획 과정에서 세가지 방법 중 가장 나은 한가지를 선택하면 세개의 작을 실수를 하는 것이지만 한가지 방법으로 개발하다 문제가 생겨 다른 방법을 사용해보고 다시 다른 방법을 사용해서 문제를 해결했다면 큰 세가지 실수를 만든 것이다.
요구사항 개발
프로그램 사용자와 영업하는 사람, 분석가, 개발자가 보는 최종 제품은 모두 다르다. 고객은 그것을 알고 있지만 잘 표현하지 않고, 잘 표현할 줄 모른다. 또한 개발자는 기술적인 언어로 말하고 사용자는 비즈니스 언어로 얘기한다. 이런 커뮤니케이션의 어려움이 개발의 어려움이 되고 프로젝트 납기가 지연되고 더 많은 비용이 들어가게 한다. 개발 시간 중 프로그래밍의 오류로 인한 재개발 시간은 5~10% 정도이고 고객의 요구사항 변경으로 인한 재개발이 나머지를 차지한다. 고객의 요구사항은 프로젝트 기간 내내 변할 수 있지만 프로젝트 초기에 대부분의 변화가 있어야 하고 시간이 지날 수록 점점 줄어들어야 한다. 또한 프로토타입을 보여주는등 사용자와의 커뮤니케이션을 통해 고객의 요구사항을 정확히 파악하여야 하고 최대한 문서화하고 구두 커뮤니케이션을 줄여야 한다. 또한 고객사의 전산실과만 커뮤니케이션하여 정작 프로그램을 사용할 고객들의 요구를 수용하지 못한 경우가 있었다. 항상 고객의 목소리를 듣고 요구사항을 누락하지 않고 정확히 파악해 품질을 높여야 한다.
XP
eXtreme Programming.
프로젝트 과정에서 고객의 참여와 팀원들간의 커뮤니케이션을 중시하는 개발 방법론이다. 짝 프로그래밍(Pair Programming)이 흥미로웠는데 같은 작업을 두명의 개발자가 팀을 이뤄서 수행하는 방법론이다. 두명이 의견을 나누면서 좀 더 효율적인 개발을 할 수 있는데 알고리즘에 대한 토론을 통해 최선의 방법을 선택할 수 있고, 자신이 가지고 있는 문제점을 상대방에게 설명하면서 자연스럽게 해결방법을 도출할 수 있다고도 한다. 또한 두명이기 때문에 좀 더 대담하게 새로운 방법이나 시도를 할 수 있다고 한다. 친구가 자신의 의견에 동조해주면 혼자 결정할 때보다 부담이 덜 하고 확신이 생기니까 그럴듯? 고객이 프로젝트 기간동안 개발팀과 같이 생활해야 한다는 것도 신선했다. 같이 밥먹고 프로젝트 이야기 하면 결과물은 당연히 좋겠지요~ 그렇지만 어떤 사람이 가서 생활하느냐가 문젠데... 우리나라 현실에서 일 잘하고 어느정도 넓은 시야를 가진 사람-개발 과정에서 건설적인 의견을 주고받을 수 있는 사람-을 몇달동안 실무에서 배제하고 개발팀에 넣을 수 있을까? 하는 생각이 든다.
그리고 팀내 리뷰는 참 좋은 방법인듯.
내가 하는게 맞는걸까 하는 의문이 들고 다른 사람의 생각은 어떨까 하는 궁금증이 들기도 하고 다른 사람은 무슨 일을 어떻게 할까 할때.... 팀원들끼리 리뷰 시간을 가지면 좋을 것 같다. 서로의 일에 대한 깊은 이해를 가질 수 있고, 자신감과 긍정적인 피드백을 받는 시간이 될 수도 있겠다. 방법은 공식적인 회의 같이 하는 방법, 상대방에게 즉석에서 '내가 한건데 좀 봐줘' 하는 방법 등등이 있다고....
커뮤니케이션
커뮤니케이션이 중요하다고 한다. 매니져급으로 갈수록 글이나 구두로 하는 커뮤니케이션이 중요한데 많은 매니져들이 커뮤니케이션이 어려워 고생을 많이 한다고 한다. 특히 고객과의 커뮤니케이션에서 요구사항을 잘못 파악하거나 기술적으로 어려운 것을 약속하면 아래 개발자들이 많은 고생을 하고 프로젝트 전체의 품질도 영향을 받는다. 프로젝트의 커뮤니케이션은 문학적인 커뮤니케이션이 아니다. 기술적인 내용을 간결하고 명확하게 전달하면 된다. 그것을 위해서 많이 연습해보고 많이 써야 한다. 인재 채용시에도 개발 능력이 어느정도 갖춰진 사람이라면 이력서의 문체, 문법, 어투 등등 커뮤니케이션 태도를 고려하여 채용하는 것이 바랍직하다.
ISTJ
40% 이상의 개발자들이 ISTJ 유형의 성격을 가지고 있다고 한다.
I는 내향적, S는 감각적, T는 사고적, J는 판단적.....
내가 INTJ인데... 세개나 겹친다.....
그분들은 나랑 비슷한 분들인건가??????????????????????????????????
◇ISTJ(세상의 소금형)=일처리시 신중하며 책임감이 강하다. 보수적인 경향이 있으며 문제 해결시 과거경험을 잘 적용한다. 매사에 철저하고 사리분별력이 뛰어나다.
스티브 잡스, 안철수
잡스 아저씨는 혁신을 중요시하고 실패를 두려워하지 않았다.
'시장조사따위는 하지 않는다. 혁신만을 생각한. 에디슨이 전구 만들때도 그랬다.'
라는 말을 했다고 한다. 이런 자신감과 뚝심이 지금 애플이 개성있고 혁신적인 제품으로 시장에 돌풍을 일으키고 있는 것 같다. 또한 안철수님은 항상 겸손하고 성실했다. 이러한 성품을 바탕으로 우리나라 최고의 보안 업체를 운영했고 원칙에 입각해서 경영했다. 원칙은 평소에는 별것 아닌 것 같지만 위기 상황에서 모두가 우왕좌왕 할 때 모두가 의지할 수 있는 기둥이 되어 빛을 발한다.
약간 지루하기는 했지만 IT업계에서 개발자분들이 어떤 생활을 하고 있는지, 그들이 더 나은 작업 환경과 효율적인 업무를 하기 위해 어떤 노력을 하고 있는지 볼 수 있었다.
요구사항 개발, XP 방법론, 상류 단계가 중요하다는 것, PM의 요건 등이 유익했다.