'일하다보면'에 해당되는 글 11건

  1. 2010.04.23 좋은 회사!, 좋은 직장? (11)
  2. 2009.01.27 [Reference] How to work the MapReduce of Hadoop (2)
  3. 2007.12.17 까칠한 얘기를 하면서도 웃을 수 있는 공력... (3)
  4. 2007.05.12 미래는 꿈꾸는 자의 것이다. (5)
  5. 2006.12.26 빗형의 지식을 갖추어라.
  6. 2006.12.11 [펌] “업무 일관성 없는 상사 제일 싫어” (1)
  7. 2006.07.04 Keep It Small, Keep It Simple, Let It Happen
  8. 2006.03.01 자바언어를 위한 Static Code Analyzer - PMD (1)
  9. 2005.11.23 기간확정 개발법 (2)
  10. 2005.11.10 같이 일한다는 것 (1)

좋은 회사!, 좋은 직장?

|
이 글을 쓴 계기는 아는 후배 몇몇이 모여서(아무튼 무지무지 부지런한 친구들입니다) "슬랙" 이라는 책을 공역해 내놓았다고 해서 책의 목차를 보다보니 그리고 요즘  "Happier" 라는 책을 보고 있는데  이것저것 머리속에서 생각나는 게 있어서 포스팅을 하게 되었습니다.

먼저 제 얘기를 조금 할까요? 저는 아주 운이 좋게 우리나라에서 몇 손가락에 드는 회사를 두번이나 입사를 한 경험이 있습니다. 그 회사는 지금은 우리나라에서 첫번째가는 회사가 되었죠. 그 회사는 사실 퇴사한 사람은 다시 입사를 잘 안시켜주는 데거든요. 그런데 타이밍이 잘 맞아서 재입사도 하게되었고 한마디로 들락날락 한 거죠.  2000년도에 나와서 자그마한 벤처회사를 3년 약간 모자라게 다닌 것 빼고, 2008년도에 현재의 직장으로 옮긴 지금도 역시  우리나라에서 몇 손가락안에 드는 회사에 다니고 있습니다. 소위 남들이 말하는 "좋은 회사"를 16년 넘게 다니고 있습니다. (어떤 분에겐 염장을 지르는 말처럼 들릴 수도 있겠습니다만 오해하진 마시길 바랍니다.)

그런데 이런 회사들이 "좋은 직장" 이었을까요? 그렇다고도 말할 수 있고 그렇지 않다고도 말할 수 있습니다. 일정에 쫓겨 학대를 하는 듯한 분위기의 프로젝트를 끓임없이 드라이브하는 회사이더라도 내가 속해 있는 그 부서와 프로젝트의 성격에 따라서 "좋은 직장" 이 될 수도 있습니다. 본인이 주도가 되고 무언가를 성취한다는 느낌을 꾸준히 가질 수 있다면 좋은 직장이 되는 것이죠. 하지만 대부분 그렇지 못합니다. 성과를 중심으로 직원을 드라이브 하는 회사의 경우 일을 하는 담당자 역시 내가 왜 이 일을 하는지 어떻게 해야 하는지에 대한 충분한 공감이 없이 기계적으로 일을 시키는 경우가 많습니다. 그런데 똑같이 일정에 쫒기고 힘든  프로젝트에 참여하게 되더라도 이러한 압력을 잘 완화시켜주고 끓임없이 동기부여를 해주면서 잘 끌어가는 팀도 있고 그렇게 어렵지 않은 업무인데도 내분이 일고 사내 정치에 휘말리고 엉망이 되버려서 분위기가 엉망인 팀도 있습니다. 리더의 탓일 수도 있고 속해 있는 팀원 개개인  탓일 수도 있겠지만 결국은 그 팀자체의 문제인 거죠.

결국  "좋은 직장"이라는 것은 자신이 다니는 회사가 아닌 자신이 속해 있는 팀과 업무에 의해서 결정된다고 생각됩니다.   좀 더 근본적으로는 자신이 하고 있는 일에 대한 자신의 관심과 몰입 정도에 따라서 어떤 사람에게는 좋은 직장, 어떤 이에게는 최악의 직장이 될 수 있는 것입니다. 하지만  스스로 동기부여를 하고 관심과 몰입을 한다는 게 그리 쉬운 일은 아닙니다. 남의 말에 쉽게 상처받고 남의 탓을 하고 주어진 일이 힘든 경우  회피하거나 미루고자 하는 것은 인지상정이니까요. 하지만 함께 일하는 리더가, 팀원들이 이러한 부분들을 서로 토닥거려주고 도와줄 수 있다면 가능해지겠죠. 공동의 목표를 달성하고 성취감도 느끼게 되구요.  그렇지만 현실적으로  그런 리더를 만나기도 그런 동료와 함께 프로젝트를 하기도 힘들 뿐 더라, 본인 스스로도 그런 역활과 협업을 잘 해 나간다는게 쉽지 않죠. 그러다보니 많은 사람들이 "좋은 회사" 를 다니는 것만으로도 위안삼으면서  회사를 다니는 경우를 많이 봅니다. 

3년간 벤처에 있을 때를 생각해보면 결코 그 회사는 "좋은 회사" 는 아니였습니다. 다니는 회사가 작다보니 제 개인 신용도도 함께 떨어지더군요. 그 바람에 신용대출이 불가능해지고 연봉은 연봉대로 줄어들고. 하지만 그때의 업무는 정말 신이 났습니다. 무언가 될 것 같고 누구에 의해서가 아니라 제 스스로 생각하고 일을 하고 심지어 일을 만들어서 하고 아침 일어나서 공부도 하고. 만든 걸 들고 영업하러 다녀보기도 하구요. 힘들었지만 자신이 주도가 되고 직접 부딪혀 보는 그 희열은 느낀 신 분만 아실 겁니다. 결국엔 회사는 점점 사정이 안좋아지고 하는 일들이 점점 루틴해지고 결정적으로 제가 하고 싶지 않은 일들이 점점 늘어가면서 저는 다시 고민고민 끝에 원래 다니던 회사에 재입사를 했습니다.

물론 먹고 사는게 문제가 가장  심각하다면  "최악의 회사, 최악의 직장" 이라도 다녀야 할 것입니다. 하지만 여러가지 선택과 기회가 자신에게 주어짐에도 불구하고 "그래 여기가 최고의 회사이니까..." 라는 생각에 그냥 눌러 앉아 있다면 , 그저 자신이 버닝되고 있고 목표없이 지내고 있으면서도 그저 "좋은 회사" 라는 이유만으로 그 직장에 남아 있는 거라면 스스로를 빨리 되돌아봐야 합니다. 점점 마음과 몸이 다 망가져 버리게 되버리니까요. 저 역시 그랬었죠.  그래서 10년전에 잘나가던 회사를 그만두고 벤처로 옮긴 이유가 여럿 있었지만 당시 너무 버닝 되고 있던 제 자신에 대해서 자신이 점점 회의가 들고 있을 때 기회가 생겨서 조인을 했었죠.

많은 사람들이 그래도 내가 여기서 그동안 다닌 경력을 아까워 하고 "이 회사도 나쁘지 않고 좋은 회사인데" 이런저런 생각에 진정 자신이 선택한 일을 하지 못하고 스스로 타협하면서 지내는 사람들이 제법 많습니다. 그러다가 명예퇴직이다 머다 하면서 더욱 큰 상처와 회사와 사회에 대해서 큰 실망을 하게 되는 거죠.

다시 제 기억을 더듬어 보면 첫번째 회사에 입사에서 1년차부터 8년차때까지가 저에게는 가장 힘들었고 "아 이렇게 일하다 죽을지도 모르겠다" 라는 생각이 들 정도였으니까. 하지만 저에겐 가장 소중한 시간이었습니다. 하고 있는 일에 대한 열정과 함께 일하던 선배와 후배와 존경하는 리더가 있었으니까요.  객관적으로 보면 미친듯이 자신을 버닝하면서 모든 에너지를 다 쏟아버리고 있는 거였지만 그 당시 분위기속에서는 스스로를 학대하고 있는 것 조차 느끼지 못하고 스스로를 대견스러워 하면서 열심히 일했었죠. 그나마 저 같은 경우는 난 편입니다. 제 스스로의 성취감이 있고 그 일을 하는 순간만큼은 몰입하고 즐겼으니까요.

다시 한번 스스로를 돌아보세요. 진정 내가 원하는 일을 하는 것인지 진정 내가 좋아하는 일을 하고 있는 것인지. 고민하고 선택하는 그 마지막 순간까지는 매우 괴롭고 힘들지만 그것을 넘어서는 순간엔 늘 희망과 재미있는 일들이 기다리고 있으니까요. 새로운 자유가 있으니까요. 이건 순전히 제 경험에 의해서 나온 얘기라서 동의안하시는 분들도 있겠지만 그래도 누군가에게는 해주고 싶었던 얘기였습니다.

"먹고사는게 걱정된다" 그렇다면 정말 할 수 없겠죠. 꾹 참고 다닐 수 밖에요.
하지만 "그래도 먹고 살만하다"라면 자신이 원하는 일을 하세요. 자신이 원하는 길을 가세요.

그럼 제가 지금 다니는 회사는 분명 "좋은 회사" 인데 ... "좋은 직장" 일까요? 음.... 비밀입니다.

; 오늘도 두서 없는 포스팅이었습니다. 휘리릭 ~




Trackback 3 And Comment 11

[Reference] How to work the MapReduce of Hadoop

|

하둡의 MapReduce 프로그램이 어떻게 동작하는지는 이 그림하나로 잘 설명되어 있는 것 같다.


Trackback 0 And Comment 2

까칠한 얘기를 하면서도 웃을 수 있는 공력...

|
종종 같이 일하는 친구들이 저에게 직언을 하는 경우가 있습니다. 어떨 땐 제 개인적인 허물을 농담삼아 얘기할 때도 있죠. 간혹 제 자신도 불편할 때가 있지만 아무렇지 않게 웃고 넘어가는 경우가 대부분입니다.

마찬가지로 여러사람들이 같이 일하다보면 입장차이 때문에 서로 까칠하게 얘기하고 주장을 하다보면 상대방의 기분을 상하게 하는 말을 하는 경우가 흔히 있기 마련입니다.

그럴때 제가 잘 쓰는 방법은 역시 웃는 것입니다. 상대방의 의견과 상반되는 얘기를 하면서도 웃는 것이죠. 상대방의 기분을 더 나쁘게 할 수도 있을 것입니다. 하지만 동등한 관계이거나 협력을 위해서 모인 자리인 경우에는 나름 효과를 보게 됩니다. 진실성이 보이기 때문에 상대방이나 저 역시 얼굴 붉히지 않고 허심탄회하게 본인들의 얘기를 할 수 있게 되기 때문이죠. 적어도 말로 인한 오해를 많이 줄일 수가 있게 됩니다.

만일 같이 일하는 친구들이 저에게 불편한 얘기를 할 때 무조건 제가 정색을 한다면 더 이상 그들은 제가 정말 듣고 싶은 얘기를 하지 않게 될 것입니다. 그렇다고 제가 늘 사람 좋은 것처럼 웃는 것은 아니지만, 제가 우려하는 것은 정말 하고 싶은 얘기를 더 이상 저에게 하지 않는 상황입니다. 물론 늘 저에게 허심탄회하게 모든 얘기할 수는 없겠지만 얘기해봐야 소용없는 사람처럼 비추어져서는 안된다고 늘 생각합니다.

그런데 의외로 회사생활을 하거나 외부사람들을 만나다보면 그렇지 않은 사람들이 많더군요. 저 역시 욱하고 화나는 경우도 많고 기분나쁜 기색이 바깥으로 들어나는 경우가 있습니다. 언제부터인가 상대방의 입장이라는 것을 곰곰히 생각하게 되면서 나름의 공력이 생겼다는 것을 느끼고 있습니다.

초고수의 길은 아직 멀지만 늘 이러한 점을 곰곰히 생각하고 실천한다면 언젠간 매우 힘들고 불편한 상황에서도 서로 윈-윈 할 수 있는 대화의 스킬과 마음의 여유를 갖출 수 있지 않겠습니까?
Trackback 0 And Comment 3

미래는 꿈꾸는 자의 것이다.

|

이 뻔한 말이 다시금 생각나게 되는 것은 그만큼 제가 처한 현실이나 상황이 쉽지만은 않다는 것이겠지요.

"미래는 꿈꾸는 자의 것이다. "

특히,

"조직이 같은 꿈을 가지게 되면 실행할 수 있는 추진력을 가지게 된다."


이 말을 나 자신이 실천하고 있는가...

나는 같이 일하는 친구들에게 나는 꿈을 심어주고 있는지 꿈을 깨트리고 있는지 반성하게 됩니다. 꿈을 심어주기 보다는 꿈을 깨트리고 있는 역할이 아닌가 싶기도 하고.

곰곰히 생각해보면 그들이 저에게 오히려 꿈을 꾸게 해주고 있다는 생각에 고맙기도 하구요.





Trackback 0 And Comment 5

빗형의 지식을 갖추어라.

|
PHP를 공부하는 할아버지 라는 글과 지적호기심이 없는 20대 노인들이라는 글을 보다가 생각이 나서 적어봅니다.

"앞으로는 빗형의 지식을 갖추어야 한다."
이 충고는 7년전 근무한 부서에 계시던 일본인 고문께서 하신 말씀입니다.

보통 전문가라고 하는 사람들의 지식형태는 T자형, 즉 한 분야에 대해서 깊숙히 파고들어 전문성을 가지게 되는데 앞으로의 세상은 다양한 지식을 접목해서 새로운 형태의 제품이나 새로운 분야를 개척할 수 있어야 한다는 의미에서 "빗" 이라는 비유를 하신 것입니다. 여기서 빗은 바로 다양한 분야에 대한 지식을 갖추되 어느정도의 깊이있는 공부와 경험을 갖추어야 한다는 의미입니다. 그저 이것저것 수박 겉햟기식의 정보를 갖추어서는 안된다는 점을 강조하신 것이죠.

이 빗형의 지식을 갖추어야 한다는 점은 다른 분야에 계신 분들에게도 해당되는 것이겠지만, 소프트웨어 개발자 입장에서는 더더욱 깊이 새겨야 할 충고가 아닌가 생각됩니다. 워낙에 빠르게 진보하는 소프트웨어 기술도 기술이지만 그 응용의 범위가 점점 넓어지고 비중이 커지고 있는 소프트웨어 개발에 있어서는 단순한 고객의 요구사항에 맞추어서 필요한 개발언어, 개발 플랫폼에 대한 지식만을 알고 살아가는 것이 아니라 그 이상의 지식이 필요하다고 생각됩니다.

이러한 측면에서 최근의 소프트웨어 프로그래머중에서 나름 고급이라고 불리우는 분들을 보면 단순한 소프트웨어 기술만을 갖추고 있는 것이 아니라 프로젝트관리에 대한 지식과 능력, 소프트웨어 설계 지식과 더불어 해당 소프트웨어가 적용되고 있는 도메인 지식을 갖추고 있는 사람들이라 할 수 있습니다. 이러한 분들을 보면 관련된 주변 지식에 대한 끓임없는 학습과 해당과제 대해서 자신이 익힌 지식을 끓임없이 적용하고 다양한 시도를 하고 있음을 알 수 있습니다.

특히 제 생각에는 자신이 개발하는 소프트웨어와 관련된 도메인 지식을 함께 갖추고자 하는 노력이 바로 시간이 지남에 따라서 다양한 지식을 빗형과 같은 형태로 갖출 수 있는 방법이 아닐까 생각이 듭니다. 그저 요구사항에 맞추어서 그 스펙에 따라 개발하고 떠나가버리는 코더가 되는 것이 아니라 어떠한 업무를 맡았을 때 이와 관련된 지식들을 함께 익히고, 좀더 깊이있게 다룰 수 있도록 스스로를 훈련하면서 후에 다른 프로젝트나 업무를 맡았을 때 이를 응용, 적용할 수 있는 노력과 센스가 필요한 것입니다.

그러고보니 당시 점심식사를 하면서 일본인 고문께서 하신 말씀중에 자신은 "맛의 달인"이라는 만화를 보면서 음식에 대해서 좀더 관심을 가지고 음식에 대한 좀더 깊이 있는 지식을 얻고자 노력하고 있다고 말하시더군요. 얼핏 맞지 않는 비유라는 생각이 들 수도 있겠지만 당시 나이가 상당하시던 그 일본인 고문의 말씀에는 여전히 자신은 빗의 크기를 넓혀나가고자 노력하고 있다는 점을 강조하고 싶으셨던 것 같습니다. 그리고 "맛의 달인" 이라는 공통적인 소재때문에 상당한 나이차이임에도 불구하고 어색했던 분위기에서 좀더 친밀하게 대화를 (물론 통역하시는 분이 계셨습니다.) 나누었던 기억이 나네요.

사용자 삽입 이미지

Trackback 0 And Comment 0

[펌] “업무 일관성 없는 상사 제일 싫어”

|
우연히 아래와 같은 기사를 보았습니다. 아래사람으로써는 직장 생활을 하면서 가장 힘든부분입니다. 자신이 아무리 중심을 잡아도 상사가 흔들어놓으면 허탈함을 떠나서 원망마져 하게되니까요. 그래서 종종 저는 얘기하곤 합니다. 너무 열심히 하지말라고. 어쩌면 저 자신에게 하는 말일수도 있다고 생각됩니다.

참고로 매년 이러한 조사를 하지만 늘 원하는 상사의 유형은 바뀌지 않는 것 같습니다. 한편으로는 많은 후배들 중에서 본받고 싶은 상사와 같은 사람은 또 얼마나 될지 궁금하기도 합니다.

“업무 일관성 없는 상사 제일 싫어”


[출처] http://www.dailyzoom.co.kr/news/news_view2.asp?article=0300&id=9736

상사에 대한 신뢰도와 부하직원·동료와의 관계는 직장생활을 유지하는 중요한 요인이 된다. 그럼 직장인들이 함께 일하고 싶어 하는 상사는 어떤 유형일까.

온라인 리크루팅 업체 잡코리아(www.jobkorea.co.kr)가 사원급부터 임원급까지 각 직급별 직장인 1093명에게 ‘함께 일하고 싶은 상사·후배유형’을 조사했다. 그 결과 사원급(사원~대리) 직장인들이 꼽은 함께 일하고 싶은 상사유형으로 가장 많은 46.9%(복수응답)가 ‘업무능력이 뛰어난 상사’를 꼽았다. 다음으로는 ‘부하직원의 의견을 경청해 수용하고 이해시키는 상사’(46.2%), ‘업무에 도움을 받을 수 있는 인맥이 풍부한 상사’(44.1%) 등의 순이었다.

간부급(과장~부장) 직장인들 역시 ‘업무능력이 뛰어난 상사’가 48.5%로 가장 높았고, 뒤이어 ‘부하직원의 의견을 경청하는 상사’와 ‘업무성과에 공정한 평가를 내리는 상사’가 나란히 42.6%로 공동 2위에 올랐다.

반면 함께 일하기 싫은 상사 유형으로는 사원급과 간부급 모두 ‘업무 지시의 일관성이 없는 상사’를 1위로 꼽았다.
Trackback 0 And Comment 1

Keep It Small, Keep It Simple, Let It Happen

|
우리들은 늘 제품이나 솔루션을 개발할 때 최소의 기능을 구현해서 최대의 효과를 얻고자 합니다. 하지만 초기의 이러한 구호는 말로만 그칠뿐 결국 그 최종 결과물들을 보게되면 어느새 필요한지 불필요한지도 판단이 잘 서지 않는 여러가지 기능들로 둘러쌓인 제품이나 솔루션들이 되기 마련이지요. 특히 소프트웨어 개발에 종사하는 분들이 과제초기에 갖는 회의중에 하나가 고객의 요구사항을 파악하기 위한 것이라는 점에서 이미 이러한 각오는 물건너 갔다고 볼 수 있습니다. 요구사항을 듣고 이를 수렴하여 가장 필수적인 것이 무엇인지를 판단하고 결정하기 보다는 요구사항이니까 구현하고 집어넣지 하는 바로 그런 접근방법이 여전히 남아있기 때문입니다. 아마도 이글을 보시는 분중에서 소프트웨어 개발이나 솔루션개발 업무를 하시는 분들은 이러한 상황을 쉽게 부인을 하지 못하실 겁니다. 그렇다면 처음부터 질문을 바꾸어 보는 것은 어떨까요? 대략적인 요구사항을 정리해서 보여주고 도대체 정말 필요없는 기능은 무엇인지 물어보는 것이죠. 아마 처음에는 당황하겠지만 개인적인 취향들로 뒤섞인 어설픈 요구사항보다는 필수적인 요구사항들만 남게 되지 않을까요? 그럼 이럴 분들도 있겠군요. 어설프게 정리된 요구사항과 개인의 취향이 담긴 추가요구사항으로 일만 더 많아질 수 있다고 말이죠. 현실적으로 이런 상황도 생길 수는 있겠지만 제 개인적인 생각엔 이러한 접근방법도 나름대로 큰 의미가 있다고 생각됩니다.

우리가 제품이나 솔루션을 개발할 때 정말 정말 단 하나의 기능이 남는다면 그것은 무엇일까 고민했을까 하는 것입니다. 여전히 우리는 무슨 기능 빠진 것이 없는지를 살펴보게 됩니다. 그렇게 훈련받았고 그렇게 일을 해왔기 때문이요. 결코 NO하지 못하도록 훈련되었지요. 하지만 최근에 읽어본 HCI 관련 자료, 개발 방법론 책 , iPod, iTune과 같은 애플 제품들의 성공 스토리들을 보게 되면 이 글의 제목처럼 "Keep It Small, Keep It Simple, Let It Happen" 의 정신을 철저히 지킨 제품 , 솔루션들만이 성공적으로 살아남았습니다.

최근 프로젝트 진행을 통해서 저 역시 노력하고 있습니다만 여전히 쉬운 일은 아닙니다. 특히 저희 회사와 같이 VOC 가 많은 조직에서 말이죠. 하지만 이러한 입장을 견지했을 때만이 맡은 프로젝트를 성공적으로 추진할 수 있다고 믿고 있습니다.
Trackback 0 And Comment 0

자바언어를 위한 Static Code Analyzer - PMD

|
이클립스를 이용해 자바 어플케이션을 개발하면서 코드를 분석해서 코드의 질과 잠재적인 에러 방지를 도와주는 툴로써 여러가지가 있지만 오픈소스 중에는 PMD(http://pdm.sourceforge.net) 라는 것이 가장 쓸만한 것 같습니다. 코딩 스타일에 대해서 온갖 잔소리를 하고 있는 것 같지만, 꼼꼼히 보면 개발자들의 코딩 습관도 고쳐줄 수 있고, 이클립스와 ANT을 모두 지원하고 있어서 여러 측면에서 활용이 가능하도록 되어 있네요.. 회사에서는 방화벽덕분에 최신 버전 설치를 이클립스에서 제대로 확인 할 수가 없어서 예전 버전으로 확인하였는데 집에서 최신 버전을 설치하고 나서 확인해 보니 예전 버전의 이상한 에러도 없어지고 UI가 좀더 깔끔해졌네요. 그런데 왠일인지 링크된 아래 글에서 설명하고 있는 모든 기능이 제대로 동작을 하지 않네요. 다른 얘기이긴 한데 오픈소스의 가장 큰 문제점중에 하나는 버전간의 호환성이 확실하지 않다는 것입니다. 새로운 기능 때문에 최신버전을 설치하다보면 먼가 또 안되는 일이 종종 있으니까요. (호오 이렇게 얘기하니까 제가 개발자인 것처럼 느껴지는 군요.)

http://www.eclipsezone.com/articles/pmd/

참고로 상용툴인 DevPartner for Java에서도 분석모듈로써 PMD을 사용하고 있습니다.
Trackback 0 And Comment 1

기간확정 개발법

|
기간확정 개발법은 제작시기에 쓰는 개발법으로, 개발팀에게 절박감을 느끼게 만들어 가장 중요한 기능에 프로젝트 초점을 유지하도록 도와준다. 기간확정 개발법은 일정을 프로젝트에 맞춰 재정의하는 대신 제품을 일정에 맞춰 재정의하여 일정 단축을 이끈다. 이 방법은 내부 비지니스 소프트웨어에 가장 적합사지만, 고객 맞춤식이나 기성품 프로젝트의 특정 부분에 대해서도 선택적으로 활용할 수 있다. 기간확정 개발법이 성공하려면 이를 활용하는 데 있어 적합한 프로젝트 선정과 최종 사용자가 일정을 늘이는 대신 기능을 줄이는 의지가 필요하다.


주요 위험요소

  • 부적절한 제품에 기간확정 개발법을 적용하기

  • 기능 대신 품질을 희생하기



주요 상호작용과 상충요인

  • 발전적인 프로토타이핑에 의존한다.

  • 기능 통제를 희생해서 개발 시간 통제를 얻어낸다.

  • 때때로 RAD 프로젝트에서 JAD, 케이스 도구, 발전적인 프로토타이핑과 결합한다.

  • 내용보다도 출시 시점을 중요하게 여길 때, 발전적인 출시와 결합한다.



스티브 맥코넬의 "Rapid Development" 에서


아마도 소프트웨어 개발 프로젝트중에서 가장 많이 사용되는 것이겠죠. 장점과 리스크가 정리된게 눈에 띄어서 올려봅니다. 많은 S/W개발자들이 기간확정 개발법에 반발이 많지만, 적절하게 적용하고 긍정적으로 이에 대처한다면 나름대로 의미가 있는 방법이네요. 그래도 불합리한 여건속에서도 열심히 힘써 준 분들에게 가장 고맙지요.
Trackback 0 And Comment 2

같이 일한다는 것

|
요즘 같이 일한다는 것이 무엇일까 생각해봅니다. "같이" 라는 말이 정말 의미가 있는지도 생각해봅니다. 혹시 일방적인 지시를 내리는 것이 아닌지, 혹시 일방적인 지시를 받아서 일하는 것은 아닌지. 이것도 같이 일한다고 말할 수 있는지. 주위에서 "같이" 일하는 친구들에게 늘 얘기하는 것이 있습니다. 스스로 움직일 수 있는 사람이 되자. 그곳이 이곳이든 어디든 스스로의 의지로 일할 수 있는 사람이 되자는 것이죠. 그럴경우 "같이" 라는 의미를 더 찾을 수 있지 않을까 하는 것이죠. 진정한 프로 , 진정한 고수들은 혼자서 잘나서 어떤일을 제대로 할 수 있을 거라고는 생각이 안듭니다. "같이" 할 수 있는 분위기를 이끌고 그 속에 자신의 내공을 불어넣어 줄 수 있는 사람이 진정 고수라고 생각이 듭니다. 저는 어떨까요? ... 당연히 아직 멀었지요. ^^ 그래도 노력중이랍니다. 갑자기 이런 글을 쓰게 되는 이유는 물론 있지요. "같이" 일한다는 느낌을 받지 못해서라기보다는 더 신경을 써야 한다는 생각이 들어서입니다. 그런면에서 가족에 대해서도 마찬가지이겠지만 어쩌면 가족보다 더 많은 시간을 "같이" 보내는 사람들에 대해서 더 신경을 써야 하지 않을까 생각됩니다. 음... 여전히 낭만적이군요.
Trackback 0 And Comment 1
prev | 1 | 2 | next