Q&A와 스터디
안녕하세요 초짜 PM역할과 기획을 맡고 있는 2년차 분야 근무자입니다
제가 요즘 엄청난 고민에 빠진 것이 프로그래머들과의 커뮤니케이션입니다
제 머릿속에서는 일반적인 상식으로 당연히 해야할 것들이라고 생각을 하는데
프로그래머들과 일을 하다 보면 꼭, 이런 분야의 개발을 해달라 라고 하면 반드시 해야할 작업들이 빠져 있는 경우가 잦았습니다
예를들어 로그인 화면을 제작을 하는데, 로그인 버튼을 눌러 접속하는 프로그램을 만들지 않는다거나,
경매장 프로그램을 제작할 때 입찰은 있는데 낙찰이 없는 경우 등이 있겠습니다
지시서를 잘못 쓴 제가 가장 큰 문제겠지만,
제가 이를 쓰지 않더라도 프로그래머가 보다 능동적으로 생각해 개발을 할 수 있도록 만들수는 없을까요?
반드시 지시한 사항이 아닐지라도, 그러니까 지시에서 빠져 있다 할지라도 필요한 부분을 스스로 개발할 수 있도록 만들려면
어떻게 이야기를 나누는 것이 좋겠습니까?
제가 요즘 엄청난 고민에 빠진 것이 프로그래머들과의 커뮤니케이션입니다
제 머릿속에서는 일반적인 상식으로 당연히 해야할 것들이라고 생각을 하는데
프로그래머들과 일을 하다 보면 꼭, 이런 분야의 개발을 해달라 라고 하면 반드시 해야할 작업들이 빠져 있는 경우가 잦았습니다
예를들어 로그인 화면을 제작을 하는데, 로그인 버튼을 눌러 접속하는 프로그램을 만들지 않는다거나,
경매장 프로그램을 제작할 때 입찰은 있는데 낙찰이 없는 경우 등이 있겠습니다
지시서를 잘못 쓴 제가 가장 큰 문제겠지만,
제가 이를 쓰지 않더라도 프로그래머가 보다 능동적으로 생각해 개발을 할 수 있도록 만들수는 없을까요?
반드시 지시한 사항이 아닐지라도, 그러니까 지시에서 빠져 있다 할지라도 필요한 부분을 스스로 개발할 수 있도록 만들려면
어떻게 이야기를 나누는 것이 좋겠습니까?
![[레벨:7]](http://old.lameproof.com/modules/point/icons/default/7.gif "포인트:5377point (71%), 레벨:7/30"){kind=icon}
게임초보
2010.12.28 17:34:27 (*.93.64.84)
![[레벨:9]](http://old.lameproof.com/modules/point/icons/default/9.gif "포인트:7303point (0%), 레벨:9/30"){kind=icon}
프리스켄 이건 PM쪽에서 지시해야 할 문제라 봅니다.
요즘 S그룹 쪽의 일을 하고 있으면서 느낀점은.
절대 제 개인 생각으로 일을 하면 피본다는 느낌을 많이 받습니다.
물론 유능한 PM이 있다면 개발자의 능동적인 행위에 대해 포괄하는 방향으로 프로젝트를 진행하겠지만
대부분은 불가능하더군요..
프로젝트 방향이 이거다! 라고 정해 졌다면 모르겠지만 이놈의 프로젝트는 산으로 가고 바다로 가고 우주로 가기 때문에
개발자 독단의 행위로 무언가 창출했을때 잘되면 그냥 넘어가고 잘못되면 그 피해는 제작한 개발자이기 떄문이죠
이런 리스크를 감수하면서 할 이유는 없다고 봅니다.
개발자는 지시사항에 대해 개발만을 하고픈 것이 우리나라 개발자 1人의 바램입니다.
요즘 S그룹 쪽의 일을 하고 있으면서 느낀점은.
절대 제 개인 생각으로 일을 하면 피본다는 느낌을 많이 받습니다.
물론 유능한 PM이 있다면 개발자의 능동적인 행위에 대해 포괄하는 방향으로 프로젝트를 진행하겠지만
대부분은 불가능하더군요..
프로젝트 방향이 이거다! 라고 정해 졌다면 모르겠지만 이놈의 프로젝트는 산으로 가고 바다로 가고 우주로 가기 때문에
개발자 독단의 행위로 무언가 창출했을때 잘되면 그냥 넘어가고 잘못되면 그 피해는 제작한 개발자이기 떄문이죠
이런 리스크를 감수하면서 할 이유는 없다고 봅니다.
개발자는 지시사항에 대해 개발만을 하고픈 것이 우리나라 개발자 1人의 바램입니다.
2010.12.28 17:39:57 (*.248.67.14)
![[레벨:6]](http://old.lameproof.com/modules/point/icons/default/6.gif "포인트:4254point (86%), 레벨:6/30"){kind=icon}
bard 수동적인 사람들을 능동적으로 바꾸는 손쉬운 방법은 없습니다.
안그랬으면 공산주의가 세상을 지배할겁니다. ;]
어쨌건, 수동적인 -- 다른말로 시키는 일만 하는 -- 사람들을 능동적으로 바꾸는 건 "아 시바 그냥 내가 하고 말아!!" 가 튀어나올
정도로 어렵고 지루한 일입니다.
대부분 수동적인 사람들이 수동적인데는 동기부여가 되어있지 않고, 그냥 "일"로써 자기의 일을 바라본다는데 그 이유를 찾을 수 있겠죠.
하고자 하는 작업에 대한 spec 문서를 던져주고, 빠진부분은 니가 채워서 해! 라는 식의 작업지시는 솔직히 효율이 나기가 힘이 듭니다.
효율이 나도록 하기 위해서는 본문에서 말씀 하신것 처럼 spec 문서(지시서)를 한치의 빈틈도 없이 꼼꼼히 작성해 줘야 하겠습니다만,
그건 쉽지가 않은 일이겠지요..
우선 이야기를 해 보십시오. "너 왜 이것도 생각 안해보고 이 따위로 했어!" 가 아니라 좀 둘러가더라도 같이 일해야 할 프로그래머라면
어째서 그런식의 행동을 하게 되는지에 대한 root cause를 찾기위해 많은 이야기를 나눠봐야 합니다.
능동적의 다른 말은 주도적이고 주도적의 주자는 주인 주(主)자입니다. 즉, 그 일에 대해 오너십을 갖고, 자기의 일이라고 생각하게 만들어야 합니다.
초반 단계부터 개발자를 참여시키고 최종지시 문서를 개발자가 직접 confirm 하게 해 보시는것도 좋은 방법입니다.
의사결정단계에서 자신이 참여하고 하지 않고의 차이는 일을 대하는 자세에서도 많은 차이를 가져옵니다.
그런데 이렇게 주절주절 적어놔봐야 사람을 다룬다는게 항상 case by case 인지라 정답은 없겠지요..
어찌됐건 이야기를 나누려는 생각을 가지고 계신것 자체가 아주 긍정적이고 좋은 자세라 말씀드리고 싶습니다. ^^;
안그랬으면 공산주의가 세상을 지배할겁니다. ;]
어쨌건, 수동적인 -- 다른말로 시키는 일만 하는 -- 사람들을 능동적으로 바꾸는 건 "아 시바 그냥 내가 하고 말아!!" 가 튀어나올
정도로 어렵고 지루한 일입니다.
대부분 수동적인 사람들이 수동적인데는 동기부여가 되어있지 않고, 그냥 "일"로써 자기의 일을 바라본다는데 그 이유를 찾을 수 있겠죠.
하고자 하는 작업에 대한 spec 문서를 던져주고, 빠진부분은 니가 채워서 해! 라는 식의 작업지시는 솔직히 효율이 나기가 힘이 듭니다.
효율이 나도록 하기 위해서는 본문에서 말씀 하신것 처럼 spec 문서(지시서)를 한치의 빈틈도 없이 꼼꼼히 작성해 줘야 하겠습니다만,
그건 쉽지가 않은 일이겠지요..
우선 이야기를 해 보십시오. "너 왜 이것도 생각 안해보고 이 따위로 했어!" 가 아니라 좀 둘러가더라도 같이 일해야 할 프로그래머라면
어째서 그런식의 행동을 하게 되는지에 대한 root cause를 찾기위해 많은 이야기를 나눠봐야 합니다.
능동적의 다른 말은 주도적이고 주도적의 주자는 주인 주(主)자입니다. 즉, 그 일에 대해 오너십을 갖고, 자기의 일이라고 생각하게 만들어야 합니다.
초반 단계부터 개발자를 참여시키고 최종지시 문서를 개발자가 직접 confirm 하게 해 보시는것도 좋은 방법입니다.
의사결정단계에서 자신이 참여하고 하지 않고의 차이는 일을 대하는 자세에서도 많은 차이를 가져옵니다.
그런데 이렇게 주절주절 적어놔봐야 사람을 다룬다는게 항상 case by case 인지라 정답은 없겠지요..
어찌됐건 이야기를 나누려는 생각을 가지고 계신것 자체가 아주 긍정적이고 좋은 자세라 말씀드리고 싶습니다. ^^;
![[레벨:11]](http://old.lameproof.com/modules/point/icons/default/11.gif "포인트:12461point (75%), 레벨:11/30"){kind=icon}
39쇼핑
2010.12.29 00:07:52 (*.162.77.190)
![[레벨:3]](http://old.lameproof.com/modules/point/icons/default/3.gif "포인트:1004point (30%), 레벨:3/30"){kind=icon}
Remma 개발자로서 얘기하면 기획이 부실할때 개발자가 능동적이면 같은 기간에 일을 더 하게 됩니다.
꼼곰하게 한다고 여러면에서 긍정적으로 끝나지는 않습니다.
개발자를 움직이게 하려면 많은 문화적인 부분이 필요하죠.
꼼곰하게 한다고 여러면에서 긍정적으로 끝나지는 않습니다.
개발자를 움직이게 하려면 많은 문화적인 부분이 필요하죠.
2010.12.29 01:26:58 (*.51.74.159)
![[레벨:2]](http://old.lameproof.com/modules/point/icons/default/2.gif "포인트:645point (63%), 레벨:2/30"){kind=icon}
AI 저도 윗분들과 동의하는게 프로그래머의 효율을 올리려면 디테일하고 확고하며 정확한 지시사항이 필요합니다.(본문글답은 끝 ㅋ)
잡담으로 제가 근무하는 회사 특성상 발주자체도 50%이상, 스크립트에서 사용할 값들을 리턴해달라는 것과 특정 상황에서 특정 스크립트 돌리고 인자값 몇개 넘겨달라는게 대부분입니다.
그리고 나서 그 함수들과 조합은 '기획자'들이 하죠;;;;;; 아 그런데 이런 구조 좋은게 아니네요;; 저희 팀 1장이상 기획서를 써 본적이 거의 없네요;;
지시서라는 것을 써서 프로그래머에게 전달할 수 있는 회사가 상상이 안가네요;; 어떤면에서는 엄청 부러버여;;
잡담으로 제가 근무하는 회사 특성상 발주자체도 50%이상, 스크립트에서 사용할 값들을 리턴해달라는 것과 특정 상황에서 특정 스크립트 돌리고 인자값 몇개 넘겨달라는게 대부분입니다.
그리고 나서 그 함수들과 조합은 '기획자'들이 하죠;;;;;; 아 그런데 이런 구조 좋은게 아니네요;; 저희 팀 1장이상 기획서를 써 본적이 거의 없네요;;
지시서라는 것을 써서 프로그래머에게 전달할 수 있는 회사가 상상이 안가네요;; 어떤면에서는 엄청 부러버여;;
Pado
2010.12.29 11:31:50 (*.98.37.243)
![[레벨:4]](http://old.lameproof.com/modules/point/icons/default/4.gif "포인트:1551point (13%), 레벨:4/30"){kind=icon}
정상택프로젝트를 시작하기 전에 기획 내부에서 논리적으로 검토를 해봐야 합니다.
일정도 공식적으로 줘야 하고,
명시적으로 세세한 부분까지 지정해야 합니다.
요구분석설계서부터 확고하게 짜는 것이 매우 도움이
일정도 공식적으로 줘야 하고,
명시적으로 세세한 부분까지 지정해야 합니다.
요구분석설계서부터 확고하게 짜는 것이 매우 도움이
2010.12.29 12:50:41 (*.35.99.132)
![[레벨:5]](http://old.lameproof.com/modules/point/icons/default/5.gif "포인트:3087point (84%), 레벨:5/30"){kind=icon}
안군 한마디로 얘기해서... PM 및 기획에서, 진짜 사소한것 하나까지 다 정리해서 지시하지 않고 그걸 프로그래머한테 맡기면...
프로젝트는 '반드시' 산으로 갑니다. 프로그래머의 사고구조는 기획자와는 딴판이거든요.
프로그래머의 관심은 언제나 '기능' 입니다. 자기가 만든 프로그램이 어떤 기능을 가지고 있느냐가 주요 관심사지요.
근데, 기획자의 관심은 '사용성' 입니다. 아무리 기능이 많아도 그걸 쓰기가 너무 어렵거나 불편하다면, 안 만드니만 못한거지요.
PM의 능력은 그것을 잘 조율해서, 프로젝트의 방향성을 제시하고, 기획자와 프로그래머들에게 적절하게 업무을 나눠주느냐에 의해 판가름 나는거구요.
프로젝트는 '반드시' 산으로 갑니다. 프로그래머의 사고구조는 기획자와는 딴판이거든요.
프로그래머의 관심은 언제나 '기능' 입니다. 자기가 만든 프로그램이 어떤 기능을 가지고 있느냐가 주요 관심사지요.
근데, 기획자의 관심은 '사용성' 입니다. 아무리 기능이 많아도 그걸 쓰기가 너무 어렵거나 불편하다면, 안 만드니만 못한거지요.
PM의 능력은 그것을 잘 조율해서, 프로젝트의 방향성을 제시하고, 기획자와 프로그래머들에게 적절하게 업무을 나눠주느냐에 의해 판가름 나는거구요.
2010.12.29 15:17:48 (*.74.149.140)
이 질문은 사실 좀 너무하네요.
마치 "스스로 기획해서 코딩하는 프로그래머는 없나요?" 같은 질문 아닌가요.
그럼 기획자가 무슨 필요죠?
바꿔말하면, "간단한 프로토타입을 코딩해서 가져오는 기획자는 없나요?".
마치 "스스로 기획해서 코딩하는 프로그래머는 없나요?" 같은 질문 아닌가요.
그럼 기획자가 무슨 필요죠?
바꿔말하면, "간단한 프로토타입을 코딩해서 가져오는 기획자는 없나요?".
2010.12.30 10:06:04 (*.234.76.254)
msz006 프로그래머가 기획의 문제점을 지적할 수 있는 단계를 넣으면 됩니다.
본문에 예로 드신 경우는 명백히 기획이 잘못된건데, 이때 프로그래머가 해당 부분의 문제점을 지적하면 기획을 수정하여 다시 진행하는 형태로 업무 프로세스를 잡으면 됩니다.
요는 프로그래머가 알아서 구현하는 경우도 없어야 하고 구현에 문제점이 생겨도 안된다는건데, 그렇다면 기획이 고치는 수 밖에 없고, 이를 위해 프로그래머가 구현하기 전에 검증하는 단계를 넣는거죠.
본문에 예로 드신 경우는 명백히 기획이 잘못된건데, 이때 프로그래머가 해당 부분의 문제점을 지적하면 기획을 수정하여 다시 진행하는 형태로 업무 프로세스를 잡으면 됩니다.
요는 프로그래머가 알아서 구현하는 경우도 없어야 하고 구현에 문제점이 생겨도 안된다는건데, 그렇다면 기획이 고치는 수 밖에 없고, 이를 위해 프로그래머가 구현하기 전에 검증하는 단계를 넣는거죠.
2011.01.03 15:57:16 (*.110.172.248)
![[레벨:0]](http://old.lameproof.com/modules/point/icons/default/0.gif "포인트:10point (11%), 레벨:0/30"){kind=icon}
이호영이제 6년차 접어드는 프로그래머 입니다.
완벽한 기획서(요구분석설계서)는 없다고 봅니다.
일정 이라는 태풍 앞에서 나아가려면, 서로 손발을
완벽한 기획서(요구분석설계서)는 없다고 봅니다.
일정 이라는 태풍 앞에서 나아가려면, 서로 손발을
2011.01.08 23:43:00 (*.56.117.92)
![[레벨:1]](http://old.lameproof.com/modules/point/icons/default/1.gif "포인트:121point (11%), 레벨:1/30"){kind=icon}
러브태연 가장중요한건 커뮤니케이션이고 그다음 중요한게 기획이죠.
기획에 없는내용 개발자가 임의로 넣었다가 문제 생기면 개발자가 독박쓰죠
기획에 없는내용 개발자가 임의로 넣었다가 문제 생기면 개발자가 독박쓰죠
2011.01.18 16:33:21 (*.150.33.146)
Waaagh! 제가 보기엔 기획자가 기획서 보내주고(100% 아님)프로그래머 알아서 능동적으로 하다가 잘못됐을 경우 기획자가 책임지는 것이 아닌 프로그래머가 책임을 져야 하기 때문에 수동적으로 하는 것 같습니다만...
2013.05.19 11:10:58 (*.153.235.115)
bestbasci01@yahoo.com
PM이 권위가 있어야 가능한 방법이겠지만 지시서를 제안받는 방법이 좋겠습니다.
포괄적인 가이드라인을 만들어서 전달하고 개발자에게 제안서를 다시 받아서 첨삭해서 다시 돌려주면 되겠네요.
참고로 권위는 입증할 수 있는 것이 아니지만 "회사"라는 조직은 권위를 믿는 (예-상사는 높다.)사람들로 구성되어야 일이 진행되는 조직이므로
상급자에게 권위(지시 권한)를 부여해 달라고 해야겠네요.