'개발자'에 해당되는 글 6건
- 2009/01/14 아키텍트 이야기
- 2007/12/11 변화해야 산다.
- 2007/07/10 상습적인 야근을 자제하자~ (2)
- 2007/06/27 프로젝트 관리를 위한 필수 요건
- 2007/06/22 IT 개발자들의 야근~~ (4)
- 2007/05/18 프로젝트 참여자들의 역할
 |
아키텍트 이야기 -  야마모토 케이지 지음, 이지연 옮김, 이용원 외 감수/인사이트 |
일반적으로 건축공학을 전공하고 나면 설계사가 되어 건축물의 구조와 설계를 담당하는 역할을 많이 합니다.
맞나요? 물론 실제 시공을 하거나 감독을 하거나 감리와 같은 업무를 하는 분들도 있겠죠.
하지만 제가 보기에는 구조 설계가 일반적인 건축공학의 역할이라고 보여집니다.
그런데 컴퓨터공학을 전공하고나면 일단 프로그래머가 되어야 한다고 합니다.
코딩 자체도 중요하지만 실제로는 프로그램의 전체 구조와 설계를 하는 업무가 더 중요한데도 말이죠..
그래서인지 요즘 컴퓨터 분야에서 아키텍트(Architect)라는 말이 많이 나옵니다.
처음 들었을 때는 프로그램의 DB와 프레임워크를 설계하는 일로만 생각했는데요.
"아키텍트 이야기"란 책을 읽어보면서 그 역할에 대해 한번 더 생각해 보게 되었네요..
책에서는 아키텍트를 개발자의 다음 단계라고 이야기 하고 있습니다.
10년 후에도 기술자로 활약하기 위해 아키텍트가 되어야 한다는 것이죠.
이 부분에 대해서는 좀 다르게 생각하는 면이 있습니다.
아키텍트라는 역할이 책에서 이야기하는 것처럼 복합적인 지식을 요구하지만 그것이 최고의 프로그래머만이 할 수 있는 것은 아니라는 것이죠.
진정한 아키텍트가 되려면 컴퓨터 분야에 대해 폭넓은 지식을 쌓아야 하기 때문에 처음 시작 단계부터 트레이닝을 한다면 지금부터도 될 수 있지 않을까요?
(물론 책에서는 개발하고 10년 후에 아키텍트를 할 수 있다는 이야기는 아니었습니다. ^^ 아키텍트가 되면 좀더 오래 개발과 관련된 업무를 할 수 있다는 뉘앙스였죠..)
아키텍트의 업무에 대해서 예를 들어가면서 자세히 설명하고 있습니다.
주요 사항을 정리해 보면 다음과 같습니다.
- 요구사항 정의에 참여
- 아키텍처 설계
- 프레임워크 준비
- 문제 해결
- 테스트 지원
- 개발 이외의 업무 지원
일단 기술적인 부분 즉, 설계와 프레임워크가 핵심이라고 보면 될 것 같습니다.
아키텍처를 설계하거나 프레임워크를 준비하기 위해서는 개발과 관련된 기술에 대해서 폭넓고 깊이있게 이해해야 합니다. 또한 과거의 기술에만 얽매이지 않고 새로운 기술들도 꾸준히 파악하고 있어야 효율적인 시스템을 설계할 수 있을 겁니다. 즉, 공부를 게을리해서는 안된다는 것이죠.
또한 요구분석, 문제 해결을 위해서는 의사소통에 대한 능력도 필요하다고 합니다.
대부분의 개발자들의 특성이 자신의 의견을 표현을 잘 하지 못하는 점이 있습니다.
개발자는 개발 언어로 설명하려 하고, 고객이나 사용자는 개발 언어를 이해하지 못하기 때문인듯 합니다.
개발 관련된 이야기들이 나오기도 하지만 전체적으로 어렵지 않게 읽어볼 수 있는 내용인 듯 합니다.
특히 프로그래머로서 또는 아키텍트로서 나아가고자 하는 대학생들이 미리 읽어보면 좋을 듯 하네요~
오랜만에 서평을 올리네요.. 요새 바쁘다는 핑계로 책을 못봤네요.. -.-
'리뷰' 카테고리의 다른 글
| 구글 안드로이드 개발을 위한 기본 개념 설명~ (2) | 2009/09/17 |
|---|---|
| 스타벅스~ 공짜 커피 쏜다. (0) | 2009/07/21 |
| 아키텍트 이야기 (0) | 2009/01/14 |
| 기본적인 경영 프레임워크 (0) | 2009/01/05 |
| 문제를 해결하는 방법 (0) | 2008/12/26 |
| 2009년 탁상달력 공모.. (0) | 2008/11/27 |
개발자로서 살아가는 것은 정말 쉬운 일이 아닙니다.
왜냐하면 끊임없이 변해야만 하기 때문이니까요..
보통의 직업은 한번 익힌 기술을 가지고 어느정도는 평생 먹고 살수가 있습니다.
물론 그들도 끊임없이 자기 발전을 위해 노력하는 면은 있을 겁니다.
그러나 우리 개발자만큼은 아닐거라고 생각합니다.
끊임없이 나오는 새로운 용어와 기술들, 발전하는 하드웨어, 진보하는 플랫폼, 여기에 새로운 언어들까지..
새로운 것을 배워서 2~3년 써먹다 보면 어느덧 구석기 시대의 기술이 되어버리는 느낌이라고나 할까요?
변하기 위해서는 끊임없이 배워야 하지만,
의외로 개발자들은 변화에 익숙하지 않은 것 같습니다.
새로운 것을 받아들이는 것을 두려워하기보다는 귀찮아하는 면이 많은 것 같습니다.
지금 기술로도 충분한데.. 왜 그걸 써야 하는데?
하는 이야기를 많이 합니다.
하지만 2~3년이 지나면 어느덧 지금 기술은 옛날 기술이 되어 버리고..
그런 개발자들은 점점 도태되기 마련이라고 생각합니다.
추가적으로 개발자들에게 변화하는 기술만큼 중요한 또 하나의 요소는 바로 경험이라고 생각합니다.
그동안 프로젝트를 하면서 쌓아온 노하우는 다른 어떤 것과도 바꿀 수 없는 소중한 자산이니까요..
이 경험과 기술발전에 따른 변화의 조화가 이 시대의 개발자에게 요구하는 것이 아닐까 합니다.
'프로젝트관리론 > 인력관리' 카테고리의 다른 글
| 프로젝트 팀원 역할 어떻게 설정해야 할까요? (0) | 2008/09/29 |
|---|---|
| 변화해야 산다. (0) | 2007/12/11 |
| 프로그래머의 멀티플레이와 컨텍스트 스위치... (2) | 2007/08/31 |
| 프로젝트 관리자의 의사소통 능력!~ (0) | 2007/07/27 |
| 프로젝트 관리를 위한 필수 요건 (0) | 2007/06/27 |
| 프로젝트 참여자들의 역할 (0) | 2007/05/18 |
얼마전 IT 개발자의 야근에 대한 글이 블로고스피어에 많이 나온 적이 있었습니다.
저도 IT 개발자들의 야근~~ 이라는 제목으로 포스트를 하나 올렸었는데요..
오늘은 프로젝트 관리에 있어서 야근, 즉 초과근무를 어떻게 바라봐야 할 것인지에 대해서 간단히 이야기하려고 합니다.
먼저 야근을 왜 하게 될까? 하고 생각해 봤습니다~~
첫째는 본인 스스로 눈치를 보면서 하지 않을까 합니다.
모두 야근하는데.. 나만 먼저 가면 찍히니까..
둘째는 관리자의 압력에 의해서..
즉, "이것 오늘까지 끝내~~" 하는 무리한 작업요청이 있을 수 있죠..
셋째는 정말로 할일이 많아서...
딱히 할 말이 없는 경우죠. 하지만, 이런 경우는 프로젝트에서 한 두번 마감 직전에 있지 않을까 합니다.
그렇지 않다면 프로젝트의 일정관리에 문제가 있었겠죠~
그럼.. 첫번째와 두번째에 대해 살펴보죠..
Dead Line이라는 책을 보면 다음과 같은 이야기가 있습니다.
모든 사람들이 최선을 다한 것처럼 보이기 위해서..
압력과 초과근무 시간을 사용하는 실제 이유는 ...
프로젝트가 실패하더라도 모든 사람들이 최선을 다한 것처럼 보이기 위해서일 것이다.
즉, 프로젝트의 성공이 아니라~ 실패했을 때를 위한 면죄부라는 이야기인데....
이런 프로젝트는 100% 실패할 거라는 생각이 들었습니다.
일단, 압력이든 뭐든.. 스트레스를 받으면 업무의 효율성이 극도로 떨어진다고 합니다.
또한 단기간이 아닌 장기간에 걸친 야근도 생산성의 감소로 이어진다고 합니다.
프로젝트 관리 측면에서 볼 때, 어떤 방법이 과연 합리적일까요?
첫번째를 고려한다면, 먼저 개발자는 퇴근 후 시간을 자기개발을 위해서,
취미생활을 위해서, 프로젝트의 남은 업무를 처리하기 위해서.. 자유롭게 분배해서 활용할 수 있어야 합니다.
굳이 PM등 타인의 눈치를 보면서 할 필요는 없다는 것이죠..
(대부분의 프로젝트가 일정이 촉박하다구요? 아마도 그럴 것입니다.
하지만, 야근을 염두에 두고 무의미하게 보내는 낮시간을 생각해보면.. 답이 보일것 같다는 생각도 듭니다.)
두번째를 보면, 관리자 입장에서는 개인별로 1주 분량의 적절한 업무 할당을 해주면 될 것 같습니다.
전체 프로젝트 일정을 보면서 스스로 해당 주 내에 업무를 분산 처리할 수 있도록 융통성을 주는 것이죠..
물론 할당된 업무는 일과시간내에 열심히 하면 마무리 할 수 있을 정도로만 주는 것이 좋구요~~
할당한 업무를 완료했는지 여부로 개개인의 개발능력을 판단하시는 것이 바람직하다고 봅니다.
단순한 업무시간이 아니라~~
쩝.. 다 쓰고 나니.. 두서없이 혼자 중얼거린듯한 느낌이 드네요 -.- 에궁~~
'프로젝트관리론 > 프로젝트지침' 카테고리의 다른 글
| 다양한 프로그래밍 언어를 익혀라... (5) | 2007/07/23 |
|---|---|
| 요구사항을 수집하지 말고 채굴하라 (0) | 2007/07/19 |
| 상습적인 야근을 자제하자~ (2) | 2007/07/10 |
| 소스를 모두 다 만들려고 하지 마라. (0) | 2007/06/12 |
| 소스코드 버전관리를 활용하라. (2) | 2007/06/01 |
| 프로토타입을 통해 학습하라. (0) | 2007/05/21 |
프로젝트 관리에 대한 자료들을 참고하다보면.. 꼭 빠지지 않는 이야기가 있습니다.
여러분은 그것이 바로 무엇이라고 생각하나요?
간트차트(Gantt Chart)를 통한 일정관리 ??
CVS와 같은 프로그램을 이용한 소스관리 ??
PMP(Project Management Professional) 자격증을 통한 검증 ??
보통 가장 중요하게 이야기 하는 것은 바로 "인력관리"가 아닐까 생각합니다.
프로젝트라는 것도 어차피 사람이 하는 것이므로..
문제도 사람이 만들고, 해결도 사람이 하게 됩니다.
그러므로 문제를 만들고 해결할 수 있는 사람들을 관리하는 것이야말로
가장 중요한 프로젝트 관리가 아닐까 합니다.
그러나 여기에서 고려해야 하는 점은 바로 사람의 다양성을 인정해야 한다는 것입니다.
혹자의 글처럼 모든 개발자를 람보로 만들어야 한다는 생각은 매우 위험한 발상이라고 봅니다.
사람마다의 다양성이 있으므로 서로의 장점을 잘 찾아서 개발해 주는 것이 프로젝트 관리의 묘미가 아닐까 합니다.
솔직히 프로젝트 진행할 때,
개발자들을 3~4명만 두고 업무 분장을 해 봐도.. 개인적인 개발능력의 차이는 분명히 있습니다.
개발 능력이 떨어지는 것 처럼 보이는 A란 친구는 꼼꼼하게 모든 변수를 고려하는 면이 있고..
개발 스피드가 빠른 B란 친구는 눈앞의 문제만 해결하기도 합니다.
심지어 아무리 한심해 보이는 친구가 있어도.. 분명 그 친구가 잘하는 것이 있고~
그것을 이용해 프로젝트에 도움을 줄 수 있도록 만들 수 있는 것이 있을 것입니다.
이처럼 개발자들의 특성을 파악해 거기에 적합하도록 업무를 분배하고 관리하는 것이
프로젝트 성패의 중요한 요소인 것이지요..
A에게 스피드를.. B에게 꼼꼼함을 가르치려 한다면..
당장의 프로젝트에서는 좋은 결과를 기대할 수는 없겠죠~~
물론 서로의 장단점을 프로젝트 중간중간 미팅을 통해서 이야기 해주는 것은 좋죠^^
요즘 읽고 있는 "데드라인"이란 책에는 "훌륭한 관리를 위한 4가지 필수 요건"으로 다음과 같은 항목이 나옵니다.
1. 적절한 사람들을 구한다.
2. 그들에게 알맞은 일을 할당한다.
3. 항상 동기 부여를 한다.
4. 팀이 결속하도록 하고, 그 상태를 유지하도록 돕는다.
좋은 이야기인 것 같습니다. 실행하기 어려운 말이기도 하구요~~
마지막으로 ...
"믿지 못하면 맡기지 말고, 일단 맡겼으면 끝까지 믿어라"
'프로젝트관리론 > 인력관리' 카테고리의 다른 글
| 변화해야 산다. (0) | 2007/12/11 |
|---|---|
| 프로그래머의 멀티플레이와 컨텍스트 스위치... (2) | 2007/08/31 |
| 프로젝트 관리자의 의사소통 능력!~ (0) | 2007/07/27 |
| 프로젝트 관리를 위한 필수 요건 (0) | 2007/06/27 |
| 프로젝트 참여자들의 역할 (0) | 2007/05/18 |
| 프로그래머?!? (0) | 2007/05/16 |
블로그를 돌아다니다 보니.. IT 개발자의 야근에 대한 이야기들이 있었습니다.
야근~~ 프로젝트를 진행하다보면 필수적인 것처럼 인식되기도 하는데요~
실제적으로 야근을 한다고 해서 프로젝트가 얼마나 빨리 제대로 이루어질까요?
음... 제 생각에는 그리 큰 차이가 없을 듯 합니다.
왜냐하면, 다음날 그만큼의 성과를 올릴 수 없기 때문이죠.. 피곤하기 때문에~~
물론 일찍 퇴근해서 술마시고 밤새 논다면.. 차이가 있겠지만.. ㅋㅋ
그런 의미에서 예전에 주 16시간 근무 이야기로 관심을 끌었던 "애자일 컨설팅에서 일해보니" 란 글이 생각이 나네요..
근무하는 시간이 문제가 아니라 얼마나 집중력을 가지고 일하는 가 하는 점이 중요하다고 봅니다.
집 욕조에 누워 프로젝트를 고민하는 것과..
책상에 앉아 아무 생각없이 웹서핑을 하는 것..
과연 어느 것이 진정 일하는 것일까요??
IT 개발자들의 야근 중에 이런 상습적인 야근.. 눈치보는 야근은 없어져야 하지 않을까 합니다.
그렇다고 하더라도~~ IT 분야의 야근이 많은 것은 사실이죠..
다음에서 서명을 받고 있더라구요..
IT 개발자들의 야근을 없애주세요
디지털타임즈의 이런 기사도 있구요..
[신음하는 SW 개발자들] 매일 밤샘 야근…"보상도 비전도 없다"
떡이떡이님의 포스트
SW 개발자들이여 람보가 되라
마지막으로.. 예전 Devpia 태권브이님의 글입니다.
난 개발자요
'리뷰 > 블로그' 카테고리의 다른 글
| 윈도우 설치할 때... 최적화 방안~ (0) | 2007/10/08 |
|---|---|
| 무기력증... (0) | 2007/07/03 |
| AIR, Silverlight, 그리고 Java FX Script.. (0) | 2007/06/29 |
| 구글과 프로젝트 관리~~ (0) | 2007/06/25 |
| IT 개발자들의 야근~~ (4) | 2007/06/22 |
| 오버추어의 새로운 검색 마케팅 플랫폼 '파나마' (0) | 2007/06/20 |
프로젝트를 수행하다보면 많은 사람들이 참여하게 됩니다.
기획자, 개발자, 디자이너, PM, PL…
어느 하나 중요하지 않은 것이 없다고 생각합니다.
톱니바퀴가 물려 돌아가듯이 서로 협력하고 앞으로 나아갈 때만 좋은 결과가 나오지 않을까 하네요~~
그런 의미에서 얼마전 블로고스피어에 나온 글들을 나열해 봅니다.
Linus님의 개발자와 기획자 상생의 길
본인의 경험에 따라 개발자와 기획자 사이의 의사소통 해결부분에
대해서 이야기하고 있습니다.
기획하시는 분들이 아주 좋아할 만한 스타일의 개발자라는 생각이 드네요~~
개발자와 기획자가 서로 이해하지 못하는 이유에 대해서 적어놓고 있습니다.
서로간의 조금씩 양보하고 서로의 입장이 되어준다면 이정도 문제는 해결해 나갈 수 있을거라 생각합니다.
이제 다 큰 어른들이니까요.. ^^
마지막으로 ENTClic님의 프로그래머와 유치원생 입니다.
훌륭한 개발자가 되기위해서는 어릴 때 유치원에서 배웠던 대로 하면 된다는 이야기네요~
원문을 All I Need To Know To Be A Better Programmer I Learned In Kindergarten을 번역한 것입니다.
이번 주는 간단히 블로그 글을 토대로 정리해봤습니다.
'프로젝트관리론 > 인력관리' 카테고리의 다른 글
| 변화해야 산다. (0) | 2007/12/11 |
|---|---|
| 프로그래머의 멀티플레이와 컨텍스트 스위치... (2) | 2007/08/31 |
| 프로젝트 관리자의 의사소통 능력!~ (0) | 2007/07/27 |
| 프로젝트 관리를 위한 필수 요건 (0) | 2007/06/27 |
| 프로젝트 참여자들의 역할 (0) | 2007/05/18 |
| 프로그래머?!? (0) | 2007/05/16 |
