이런 사람과 같이 팀이 된다면 당신은...
이 사람은 아키텍쳐가 중요하다고 말하며
대부분의 경우 아키텍쳐도 없고 막무가내식으로 개발된다고 합니다.
웹프로그래밍과 프로그래머는 솔직히 무시할 수 있다합니다.
왜냐하면 자기가 봤을땐 아키텍쳐가 없었기 때문이랍니다.
웹프로그램을 개발하는데 자바스크립트를 안쓰려고 합니다.
그런데 플래시는 쓰려고 합니다. 왜인고 하니 자기는 CS만 하다와서
자바스크립트를 잘모르고 알기도 싫어합니다.
플래시는 자기가 할줄알고 좋아한답니다.
웹디자이너와의 회의시간에 자기는 잘 듣지도 않고 졸기까지 합니다.
그러다 바쁘니까 빠지겠다고 PM한테 귓속말하고 뜹니다.
그 웹디자이너는 어렵게 시간내서 왔었습니다.
남들이 봤을땐 꽁수에 불과한데 그냥 그렇게 다들 처리한다고 합니다.
정석을 알려줘도 시큰둥입니다.
그 정석이란 웬만한 지식정도에서 나오는게 아닌데도 말이에요.
자기는 프로젝트 초반에 와꾸(프레임워크)만 잡아주고 빠지고 싶어합니다.
이른바 공통모듈.. 코딩량을 대폭 줄여주고 유지보수를 할 수 있게 해준답니다.
개발 총 본수가 300본이 넘는데 나머지 3사람은 코딩하고
PL은 이 사람은 이런일 하라고 거의 제외시켰습니다.
다음주부터 구현에 들어가고 실질적인 코딩을 하는데
일주일이면 자기가 하는일이 정리가 되어서 구현에 적용가능하다고 합니다.
그리고 에러나고 잘못되는거는 계속 수정해나면 된다고 합니다.
제가 봤을땐 아키텍쳐가 아니라 꽁수들의 집합인데 그는 애기합니다.
아키텍쳐가 원래 복잡하고 어려운게 아니라고..
회의시간에 MVC 모델로 설명을 하는데 좀 구체적으로 설명해달라고 하면 귀찮아 합니다.
아무리 봐도 우리 개발의 기본 틀 자체가 MVC인데
그거말고 구체적으로 설명을 해달라면 사람들이 너무 어렵게
생각한다고 합니다. 그리곤 코딩에서 차이가 난다고 합니다.
뭔가 속는 느낌이고, 자기 공부를 위해 이 프로젝트를 활용하는듯한 기분이 안들수가 없습니다.
막 성질이 나는데 어떻게 할 수가 없습니다.
항상 맞는 소리만 하거든요. 아키텍쳐가 중요하고
코딩량을 대폭 줄여야 하고 유지보수가 수월해야 한다고요.
그렇게 애기해버리면 말을 못합니다.
회식자리에 사장님은 슬쩍 저한테 일정대로 진행될수 있겠냐고 묻습니다.
저는 안된다고 하면 안되는 상황이 아니냐며 대꾸합니다. :cry:
아.. 미치겠습니다.
꾹꾹참기도 하고 신경 끄고 싶습니다만 일이 잘못됐을경우 저도 책임을 면치못하고 아마 회사 나가야 할껍니다.
어떻게하면.. 그 사람을 유용하게 이 프로젝트에 활용할 수 있을까요?
짜를수는 없습니다. 아마 그 사람에 의해 제가 짤리면 짤릴껏 같습니다.
가지치듯 거슬리는 사람 쫓아내는데는 경험도 있고 영특한것 같습니다.
어떻하면 저는 무사히 이번 일을 마무리 짓고 계속 회사에 다닐수 있을까요?
힘드시겠습니다.악당 보다는 자신이 절대 선이라고 외치며 사람들을
힘드시겠습니다.
악당 보다는 자신이 절대 선이라고 외치며 사람들을 죽이고 다니는 사람이 진짜 무서운 거죠.
그래도 업무는 업무니 최대한 협조하시고 여러가지 기록을 남기셔서 그 사람이 얼마나 능률을 저해 했는지 제시하면 되겠습니다.
감정적으로 대처하시면 클나요.
life is only one time
[quote]항상 맞는 소리만 하거든요. 아키텍쳐가 중요하고 코딩량을
그냥 배째세요. 이런저런 관계에 묶여서 할 말, 해야 할 행동 못하는 것도 좋은게 아닌 것 같습니다.
그냥 배째시고, 솔직히 말해서 도저히 당신에게 믿음이 안간다(상사라면 공손하게.. -_-;; ). 내가 봤을땐 도저히 그런 식으로는 일이 진행안된다. 나는 뭔가 더 구체적인걸 원한다. 그게 보장되지 않으면 더 이상 일 할 자신이 없다, 고 말씀해보시는게 어떨까요?
(그런데 써 놓고 보니 제 일 아니라고 너무 과한 주문을 한 것 같기도 합니다. ^^;; )
에휴.. 힘내세요.. 정말 이런 일은 누구나 다 겪는 모양이군요. ㅜ.ㅜ
--->
데비안 & 우분투로 대동단결!
아.. 제 심정을 알아주시니 고맙습니다.안그래도 그 사람과 자꾸 대립
아.. 제 심정을 알아주시니 고맙습니다.
안그래도 그 사람과 자꾸 대립구도로만 가는것 같아 연장자인 제가 못나보이기 까지 하는데
앞으론 협조해 갈꺼고 할말은 하고 넘어가야겠지요.
하지만.. 버전관리, 소스관리를 그냥 공유폴더로 하면 된다고 하는
그 주장에 흥분했고 열심히 작성한 코딩 가이드라인을 출력해서
줬는데 이런것 보다 sql 프로시저 작성법이 더 중요하다며
거기다 낙서하고 아무데나 던져놔버리는 행동에 정말 어디까지 참아야 하나 싶습니다.
결국 소스관리, 버전관리는 안하는걸로 결정났고..
코딩 가이드라인도 아마 거의 무시될꺼라 봅니다.
코드 보고 제시된대로 안되어있다면 한마디 하겠지만
아마 그건 태클거는 수준으로밖에 생각안들테고
바빠죽겠는데 사소한걸 가지고 트집잡는 놈으로 비춰질까
애기도 못꺼내겠습니다.
가만보면 정말 제가 팀에 별 도움도 안되는 존재로 취급당할것 같기도 하고요.
나이먹고 무시당하고 무능력하게 보여지다니.. 제가 그렇게 될지는 몰랐습니다.
그 사람이 개념이 상당히 없는 것 같습니다.그 사람이 팀에 위해를
그 사람이 개념이 상당히 없는 것 같습니다.
그 사람이 팀에 위해를 끼치는 요인들을 차근차근 정리하세요. 가끔은 그 사람의 책임이 아닌 일도 끼워넣구요.
그 자료를 상사에게 내 보였을 때 빈틈없을 정도로 준비하세요.
- 죠커's blog / HanIRC:#CN
..
아키텍처, 즉 프레임워크를 말씀하시는 모양인데 MVC모델이라고 한다면 간단한 축에 속합니다. (요즘은 프레임웤 천국이죠?)
프레임워크를 쓰는 이유는 어떤 사람이 프로그램을 해도 같은 프로세스와 모듈을 사용하기때문에 개발자는 달라도 코딩은 비슷해지기때문에 생산성이 높아지죠.. 또는 개발자 수준이 낮아도 비슷한 수준의 출력이 나옵니다. (아예 4GL로 가버리는 프레임워크도 많습니다)
코딩에서 차이가 난다.. 란 말은 프레임워크를 사용하지 않았을때 나타나는 현상입니다. 말이 약간 맞지않던가 어떤 의도인지 모르겠습니다.
(웹프로젝트에서 JS가 빠진다는것도 이해가 잘 되지않습니다만..)
struts정도만 알고 적용해도 웬만한 프로젝트는 무난하게 진행될텐데요..
PM과 PL이 특히 PL이 믿고 맡기는 걸보니 뭔가 있긴 한 모양입니다.
일단 기본 골격이 나올때까지 있어보시죠..
근데 버전관리, 소스관리는 하셔야 할겁니다. 나중에 피봅니다..이건 강하게 주장하셔야 합니다. 이걸 무시하는 PM과 PL이 더 이상한데요?
여담입니다만.. 경험상 프레임워크는 어려운것이 아닙니다. 초등학교 학생들에게 자기 박사논문을 설명해줘서 초등학교얘들을 이해시킬 수준이 아니라면 논문을 완전히 이해한 게 아니다.. 라는 교수님의 말씀이 생각나는군요..
뭐든 진리는 단순합니다.. KISS.. 아시죠?
일주일뒤에 PM에게 프레임워크를 이해해야 작업이 원활히 진행될것 같다..
라고 '주장'을 하십시요.. 이해될때까지 물어보세요..
(제대로 된 사람이라면 아주 쉽게 아주 친절히 설명해야 합니다.)
그래야 프로젝트 끝나도 하나는 남습니다..
정확히 이해가 잘..PL 이라면 팀원들에게 프레임웍에 대한 이해를
정확히 이해가 잘..
PL 이라면 팀원들에게 프레임웍에 대한 이해를 시켜야 하지 않을까요?
그러면서 프레임웍에 대해 강조를 하는 것은 무엇인가 문제가 있는 듯 하네요.
그사람 이 PL 인가요?(중간의 글을 보니, PL 도 아닌것 같네요.)
프레임웍 설계자(?) 인가?
조엘의 이야기가 생각나네요.
외계인 아키텍쳐
http://www.joelonsoftware.com/articles/fog0000000018.html
너무 아키텍쳐에 현혹되어 정작 중요한 사항들이 간과되는 것을 조심하셔야 합니다.
F/OSS 가 함께하길..
설명은 쉽고 간걸하게..그게 안되면 그 사람은 PM이든 PL이든
설명은 쉽고 간걸하게..
그게 안되면 그 사람은 PM이든 PL이든 할 자격이 안됩니다.
일반 팀원이라면 그런 부분은 PM과 논의하고 수정해 나아가야 할 것이지 하부 사람들하고 백날 얘기해봐야 소용 없다는것을 이해시켜야겠지요.
하여간 같은 팀원 라인에서 깎아내리고 하는건 하여간 뒷다리잡기밖에 안되고 생산성 효율 증대에 극도로 나쁜 영향을 미칩니다.
...
...
대충 봐도 진짜 쓰레기네요. 웹하는데 js 는 빼고 flash 는
대충 봐도 진짜 쓰레기네요.
웹하는데 js 는 빼고 flash 는 넣는다는데서 피식....
전 아직 학생이라 자세하게는 모르지만, 힘내세요 :D
저는 웹은 거의 안해보고 어플만 했지만 그래도 이런 말씀 드리고 싶네요.
저는 웹은 거의 안해보고 어플만 했지만 그래도 이런 말씀 드리고 싶네요..
That's Too Bad!!
인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com
표현된 내용만 보면..거의 허접한 사람인것 같긴한데...글쎄요. ra
표현된 내용만 보면..거의 허접한 사람인것 같긴한데...
글쎄요. rainmon 님이 정말 객관적인 시각으로 이런 글을 쓰신
건지는 의문이네요. 어쨋든 두 사람의 말을 다 들어보고 판단을
해 볼 문제지만.. 그 분이 이곳에 오셔서 의견을 피력하시지
않으시니 rainmon 님의 말씀만으로 추측해볼 도리밖에 없군요.
아키텍처가 중요하다는건 두말할 나위도 없지만
이것의 중요한 존재가치중 하나가 의사소통인걸 감안한다면
그 분은 이 점을 간과하고 있는거라 볼 수 있겠네요.
하지만..저라도 특정 아키텍처를 설명해달라고 한다면
제가 일일이 설명하기 보다는 책이나 다른 참고자료를 보도록
추천하겠습니다. 아키텍처가 무엇이고..왜 어떤 모델을
사용해야 하는지 개발할때마다 구구절절이 설명하는것만큼
소모적인 일도 없을테니까요.
적어도 시스템이 잘 되어 있는 회사라면...
떠먹여주는 교육보다는 팀원들이 자발적으로 학습할 수 있도록
여건을 조성해서 학습조직을 구성하는것이 맞습니다.
물론 전문 mentoring 시스템을 도입해서 체계적인 교육을
수행하는건 또 별도의 일입니다.
하지만 글의 내용을 보면..그렇게 하는것도 아닌것 같고...
글이 자세하지 못해서 대강의 분위기는 알겠지만...
구체적으로 무엇이 문제인지는 잘 파악이 안됩니다.
그리고...분야나 수준에 따라 다르게 생각되어야 하겠지만
대체적으로 웹 프로그래밍이 수준낮게 평가되는것은
어느정도 일반화된 내용이므로 그 사람의 얘기가 크게 틀린건
아닙니다.
물론 여기분들은 웹 프로그래밍을 그렇게 낮게 보는건 아니라고
항변하실 분들도 계시겠지만...현실적으로 그런 "착한사람들"
만 존재하는건 아니라는것도 아실 필요가 있습니다.
그 밖에..그 분이 회사에서 정치를 하는 부분에 있어선...
다른 분들에게 충분히 욕을 얻어먹을 이유가 된다고 봅니다.
하지만 아무리 대단한 단수의 정치인들이라해도 스스로에게
당당한 사람에게는.. 끽 소리 못합니다.
그 분이 회사에서 세를 불려 자신의 편을 많이 만들고 있다면..
그것을 안 좋은 눈으로 쳐다보는것만으로는 부족하고..
뭔가 그 사람에 대해 대처할만한 무기를 만드시기 바랍니다.
그 무기가 어떤것인지는...스스로 깨달아 나갈 부분입니다.
흠 글을 쓰게 만드는 군요.
우선 전 Application 개발로 시작했다가 회사 요구로 인해 Web도 같이 개발 하다가 Web쪽으로 많이 치우쳐 졌었던 기억이 있고 지금은 다시 Appication을 개발하고 있습니다. 안되는 Web을 하려니 영~~ 안 맞더군요. 결국 지금 Appication을 개발하는 곳에서 일하고 있습니다.
Web이라는 환경은 참 묘한 구석이 있어서 알구 보면 S/W 공학이 잘 들어 맞으면서도 정작 Web에 S/W 공학을 적용시키기가 힘이 든다는 생각이 있다는 전제하에 글을 씁니다.
여기서 뜨거운 감자는 "이 사람"이라는 사람에게 촛점이 맞춰져 있는 듯 합니다. 저기 위에 학생은 "쓰레기"라는 표현까지 사용했는데 제 생각은 좀 다릅니다.
서론이 길었는데 그럼에도 불구하고 좀더 몇확하게 몇가지 짚고 넘어갔으면 합니다.
우선 현상을 분석해 보겠습니다.
. 웹프로그래밍은 무시할수 있다 => 웹프로그래밍은 CS와 다른 아키텍쳐가 존재합니다. 물론 CS와는 달리 아직은 정리가 덜된 것은 있습니다만 웹 아키텍쳐는 웹프로그래머들에 의해 정리되어야 합니다.
. 웹프로그래밍을 하는데 스크립트를 안쓰고 플래쉬로 해결한다. => 이것은 정말 위험한 발상입니다. PM 이건 PL이건 리더는 그 상황에 맞는 랭귀지 혹은 도구를 사용하는데 있어 길잡이를 해야 합니다. 분명 제대로된 도구가 있는데 그것을 사용하지 않는다라는 것은 리더로써의 자격이 없는 것입니다. 리더로써의 자격이 없는 사람을 팀의 리더로 끌고 가는 것은 정말 위험한 일이지요.
. 정석을 알려줘도 시큰둥입니다. => 정석을 알려주는 방법도 정석이 있습니다. 위에분 말씀 대로 책이나 이런 근거를 제시하시는게 가장 현명한 방법입니다.
. 초반에 와꾸만 잡아주고 빠지고 싶어합니다. => 팀 리더로 리드를 하는 것이라면 와꾸만 잡아주고 빠지는 것이 어느정도 맞을수 있습니다.
. 일주일이면 자기가 하는 일이 정리가 되어서 구현에 적용가능하다 거기서 에러나고 잘못되는거는 계속 수정해 나가면 된다. => 와꾸를 잡는다 혹은 공통모듈은 그렇게 쉽게 수정할수 없습니다. 와꾸는 한번 잘못잡아서 수정을 해야 하는 경우가 되어 잘못되면 자칫 전체 모듈을 수정해야 하는 최악의 경우가 생길수 있습니다. 이 와꾸는 그 분야에서 충분한 경험이 있는 사람이 만들어야 하며 실제 많이 사용이 되었던 코드라는 전제로 사용을 해야 합니다. 아무리 천재 프로그래머라도 와꾸를 충분한 경험없이 단기간에 만들수는 없습니다. 분명 나중에 큰 문제가 될 가능성이 농후합니다.
. 소스관리 버전관리 필요합니다. => ...너무 당연해서....-_-
위에야 뭐 그냥 그렇고 여기부터가 핵심입니다.
. NN님이 쓰신글중에 정치라는 부분을 볼드로 사용해서 써 놓으셨는데 전 PM이나 PL이 되었건 팀을 이끄는 사람에게 가장 중요한것은 정치라고 생각합니다. 정치를 잘하면 팀원들이 쉽게 일을 하고 완벽하게 일을 하면서도 그들에게 연구할 시간을 벌어 줄수 있고 정치를 잘못하면...쩝.... 제가 볼때 최소한 "이 사람"이라는 사람은 정치는 좀 하는 사람인듯 싶습니다. 아~~ 물론 이 사람이 하는 정치는 팀원을 위한 정치라기 보다는 자기 자신을 위한 정치인듯 싶습니다.
* 문제는 그럼 그런 사람을 어떻게 끌고 가면 되냐??
"몰론 ___ 님께서도 아시는 부분이시지만 ~~ 해야 되는것 아니겠습니까?"라는 식으로 말을 하되 본인에게 하지 말고 약간 돌려서 이야기를 하듯 하면 그 정도 정치를 하는 머리가 있는 사람이고 자존심이 있는 사람이면 자기 자존심 다칠까봐 슬슬 따라 갈거라고 보이는 군요. 물론 전제가 아직은 서로 서운해 하지 않는 상태라는 전제가 붙겠죠. 괜히 감정이 있는 상태에서는 자칫 잘못하면 오히려 저 말 자체가 어떤 그 비꼬는 투가 되기 쉽상이 되기 때문이지요.
더불어 그 사람을 좀 띄워줄 필요가 있습니다. 일단은 내가 너하고 다른 생각을 가지고 있지 않다는 것을 혹은 경계심을 가질 필요가 없다는 것을 인식 시킬 필요가 있는 것입니다.
문제는 이런 것 자체가 일련의 정치 이기때문에 이것을 지금 글을 쓰신 분께서 커버하실수가 있느냐 없느냐가 관건이 될듯 싶습니다. 팀장 혹은 리더는 이런 부분에 신경쓰다 보면 정작 자신은 일을 못할때가 많아 지는 것이겠지요.
사는건 팀장이건 팀원이건 쉽지 않은 일임에는 틀림이 없는 듯 싶습니다.
풍기는 분위기처럼 별거 없이 말만 많은 사람이라는 확신이 드시면그
풍기는 분위기처럼 별거 없이 말만 많은 사람이라는 확신이 드시면
그사람 좋아하는 "아키텍쳐" 공부하세요.
별거 없는 사람 수준이라면 (그사람이 박사라 하더라도)
몇일 안걸려서 다리 걸 수준까지 갈 수 있으실겁니다.
그러면 큰소리 칠 수가 없어지겠죠.
그러면 좀 더 제대로 공부해서 기를 완전히 죽여 주세요.
근데 그게 아니고 그사람이 최소한 아키텍쳐만이라도 실력이 있다면
그냥 타협 하세요;
그 사람의 그 실력은 인정 해주고,
다른 분들 말대로 객관적인 근거를 들어서 기분 나쁘지 않게...
어쨌든 일은 되도록. 해야 하는거 아니겠습니까 :)
-------------------------
The universe is run by the complex interweaving of three elements: matter, energy, and enlightened self-interest.
- G'kar, Babylon 5
그 박사님은 무슨 전공을 하셨기에...
그 박사님은 뭐하시는 분이시길래 프레임워크만 짜고 열심히 놀고 계신답니까?
회드실때 뼈만 드실 분이시로군요. -_-
힘드시겠지만 잘 견뎌내시고요, 업무 보고 같은 것은 따로 안하시나봐요.
그 사람이 업무에 '프레임 워크' 한가지 가지고 A4 용지 한장 체우시면 rainmon님께서는
A4 용지 10장으로 만들어서 내시면 됩니다.
팀원들 불러서 사장님이 '왜 당신은 한장이냐'고 물어볼 때 장황하게 설명하시면 옆에서
껴들어서 도와주시는 척 '프레임 워크는 중요한 것이기 때문에 모든 일에 대해서 다 알고
제작해서 해서 그만큼 밖에 일을 못했답니다.' 라고 말씀하시면 되요. +_+
그럼 다음부터는 업무보고를 위해서라도 뭔가 끼어들겁니다. -_- +
Re: 이런 사람과 같이 팀이 된다면 당신은...
쿵~
화병의 근원이네요.
말로만 합니까? 그렇다면 문제군요.
좋은 얘기인데, 실제로 어떻게 하냐고 물어보세요.
자꾸 물어보세요. 아는것도 물어보고, 모르는것은 당연히 물어보고...
얘기의 진행상으로 보면 대상이 상급자인것 같은데, 그사람한테 던지세요. 문제를..
사장께서 물어보시면, "저는 시키는대로 일하고 있다. 전체적인 프레임워크 및 기본틀은 그에게 있으니, 그에게 물어봐야 정확하다."등으로 답하시는게 좋겠군요. 그게 사실인것 같고.
이말을 하실 분은 아닌듯 하군요. 본인이 사장/상급자인가요?
만일 본인이 상급자라면, 당연히 주도해야 하며, 동급이라면, 두사람의 상급자를 설득해야겠지요.
왜 그렇게 생각하나요? 반대로도 시도해보세요.
* 이상하게 들릴지 모르지만, 저는 이런 경우 스스로를 자릅니다.
별로 안좋아 하는 인간형이군요. 그분야의 전문가를 몇번봤는데, 현재도 그분야에 능한(?) 사람 별로 안좋아합니다.
문제를 던지는 연습을 해보세요. 안고 가서 풀리는 문제도 많지만, 힘이 들기도 하고, 효율적이지도 못한것 같습니다.
회피가 아니라, 문제를 조금 풀고... 던지고 다시 받고 하면서 풀리는 문제들이 더 많은 것 같습니다.
음.
결국, 그와(또는, 그 프로젝트를) 잘 해보고 싶은 마음이 있군요.
문제의 해결책 속에 그가 있는 것으로 보입니다.
그럼 얘기해보세요. 상대의 성격(?)에 따라 직설/간접적으로 얘기하는 지혜를 발휘해야 겠군요.
------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.