통합검색
· 마을서비스란?  · 포럼마을  · 일반마을  · 테마마을  · 마을랭킹  · 활동왕
· 덱스퍼트란?  · TECBOX   · PRSBOX   · 이용안내  
· DEXT제품군  · 솔루션베이  · S/W & ESD 컴포넌트
· 프로그램베이
· LiveSeminar  · LiveConference
데브피아 사이트 운영자, 비사모 마을 입니다.
개발이 아니더라도 다양한 분야에 많은 얘기를 나누는 공간입니다.
  마을등급 비사모 마을   이 마을은 테마마을 입니다이 마을은 자유가입제 마을 입니다 마을소개 페이지로 이동 전입신청
마을촌장촌장 비사모 방문자 94151 since 2006-12-31
데브피아 공지사항
자유게시판
앨범
개인게시판
[마을 게시판]
데브피아 운영 소식
교육 & 세미나 홍보
[개발자 공감]
개발자 공감글
개발자 공감만화
랑데브 게시판
칼럼 게시판
개발자 고충상담
Dev Talk
자유토론방
벼룩시장
재나미 우스개
구인/프로젝트 정보
사람인 채용 게시판
  고객지원 게시판
마이 데브피아
 나의 e-Money 내역
 활동왕 My Page
 스크랩한 게시글보기
 쪽지관리
 주소록관리

 개발자 고충상담
 개발자가 기획도 같이 하나요? 2018-07-05 오전 11:32:17
o한o 번호: 25341 추천:0  / 읽음:2,043

개발자로 들어선지 이제 8년차 막 들어가네요.

회사가 비록 작지만 조금씩이라도 성장해나가는 곳이라서 계속 있네요..

그래서 그런지, 이젠 개발 외의 업무도 하라고 합니다.

밑에 팀원에게 기본적인 개발은 맡기고, 좀 복잡한 부분을 같이 해나가면서,

앞으로는 과제 기획 및 PM 역할을 했으면 하더라고요..

제가 아는 개발자 분들이 별로 없어서.. 이렇게 데브피아에 글을 남겨봅니다.

전 개발하는 일이 좋아서 꾸준히 하고 싶은데...

앞으로는 과제 기획, 그리고 현장 PM 담당도 하라고 하니 좀 암담하네요.

한번도 해본 적도 없고, 회사 내에 기획하셨던 분도 원래 없었고요...

다른 분들도 혹시 이렇게 하시는지, 원래 이렇게 개발자는 개발에서 점점 나가게 되는건지...

아니면 이게 회사에서 나가라는 소리를 돌려서 하는건지 도저히 모르겠습니다...

이걸 받아들여야 하는건지, 아니면 이건 아니라고 해야 하는건지 갈피를 못잡겠습니다.

선배 및 후배 개발자분들께서는 어떻게 보시나요??

[코멘트] 좋음
2018-07-05 13:22
메일전송안됨
작은 회사는 다하는 곳도 종종 있더라고요.
개인적으로 전체를 보는걸 좋아해서
다른 롤을 체험식으로 며칠씩 해보는건 좋아하는데
그런식으로 롤자체가 뒤섞인채로 일하는건 싫어함.
저장 취소
[코멘트] 좋음
2018-07-05 13:25
지후니파파
회사마다 차이는 있겠지만 작은 회사일 수록 개발에서 관리로 바뀌고 PL을 거쳐 PM을 하죠
접하는 시기는 회사마다 다소차이는 있지만요.
전 경력 12년차이고...지금 PM입니다.
지금 저희 회사 기준으로 PL은 대리급도 시킵니다.
개발만 하고 싶으면 R&D 부서가 있는 회사... 그것도 좀 많이 규모가 있는 회사여야 개발만 쭈욱 할 수있을 겁니다.
저희 회사도 R&D가 있으나 급하면 PL이나 PM으로 보낼 때도 있고 프로젝트 빵구나는곳에 소방수로도 갑니다.
저희 회사 부서중엔 PMO팀도 있습니다. 그 부서 막내가 차장급 ㅋㅋ PM을 전문적으로 뛰는 사람들인데... 처음부터 이런쪽으로 했던사람은 거의 없고...다들 개발 어느정도 해서 PL하다가 프로젝트 관리만 집중적으로 하는 부서로 온 경우가 대부분입니다.
직급이 올라가면 개발보다는....프로젝트 관리자를 시키죠.
개발자를 고급인력이라 생각안해요... 언제든지 대체 가능한 인력이라 생각하죠.
저장 취소
[코멘트] 좋음
2018-07-05 15:08
글로벌게이트
월급만 잘나오면서 체험학습한다고 생각하고 해보세요 자기 좋은 일만 할순없잖아요
그래도 PM경험은 작은 곳에서 시작해야 문제가 생겨도 책임이 크지 않습니다. 연습은 작은곳에서 익숙해지면 다른곳 PM급 이직도 쉽겠지요
손해볼 부분은 아니라고 봅니다. PM이 기획을 한다 생각하기보다 프로젝트의 큰그림을 정리하는 수준으로 출발해보세요
저장 취소
[코멘트] 좋음
2018-07-05 21:56
일쌍다반사
작은회사는 하기도 하는데, 바람직하다고 생각하지 않습니다.
저장 취소
[코멘트] 좋음
2018-07-06 08:17
삼식이당
개발자는 기획 하면 안됩니다.
왜냐 어짜피 자기가 개발할꺼니 개발이 편한쪽으로 기획을 하게 됩니다.
저장 취소
[코멘트] 좋음
2018-07-06 10:35
DevCow
해보는것도 나쁘지 않다고 생각합니다.

나중에 창업하거나 할때,

어떻게 시스템을 기획하고 구성해야 하는지에 대해 감을 잡는 경험으로 좋습니다.
저장 취소
[코멘트] 좋음
2018-07-06 15:34
분당에집갖고싶어
생각하기 나름인데요.

정말 회사에 없으면 안되는 특급개발자(?)가 아닌 이상은 언젠간 후배에게 내주겠죠.

PM으로 간다면 그나마 윗선이니 좀더 나은거라 생각될거 같은데요.
저장 취소
[코멘트] 좋음
2018-07-06 17:11
밍키
할수도 있죠
그런데 기획할줄 아는사람이 한 기획하고 안해본 사람이 기획한것은 하늘땅 차이입니다.
회사가 성장해 갈때 기획이든 개발이든 인원이 충원될것 입니다.
그 과정을 위해 포지셔닝하는건 중요한것 입니다. 회사가 기회를 주는거죠.
말단 개발자로만 계속 남아 있을수는 없어요.
저장 취소
[코멘트] 좋음
2018-07-07 00:20
SkyNET
필요에 따라 인원여부에 따라 할 수도 있지요
저장 취소
[코멘트] 좋음
2018-07-07 12:49
갈라파고스
전 부정적으로 받아드릴 필요없다고 생각합니다.

물론 개발이 좋아서 놓기 싫겠지만.

본인이 발전한다고 생각하고 긍적적으로 받아드리시는게 좋을것 같습니다.

누군가 그일을 한다고 봤을때
다른사람에게 일을 지시 받는거 보다
일을 지시하는 쪽이 아무래도 회사내에서 입지가 좋을거 같네요
저장 취소
[코멘트] 좋음
2018-07-08 13:00
JUNE_MS
그런 회사들 꼬ㅐ 있음 ㅋㅋ
저장 취소
[코멘트] 좋음
2018-07-08 23:43
ARMSharp
작으면 그럴 가능성 높죠.

이걸 기회니 뭐니 살려보라는 사람들도 있는데 저는 극구 반대함.

예를 들어,

야구 선수 투수가 1루수 줄부상으로 비어있으면 "1루수도 하고 투수도 하고 너한테 얼마나 좋은 기회니?" 이런 이야기하면 투수가

"빙신아 그럼 니가 하든가"

이럴거 아닙니까?
저장 취소
[코멘트] 좋음
2018-07-09 19:49
진리와자유
제 생각은 좀 다릅니다.
개발자는 기획을 할 수 있으면 좋습니다.
용어상 엄격히 말하면 코더는 기획이 필요없지요
제가 생각하는 기획이란 일정, 요구사항대로 프로젝트를 끝내는 작업입니다.
위 상황이 가능하도록 설계를 해야하고요.
실제 개발에 깊이 들어가 본적이 없으면 불가능한 것이기도 합니다.
기획이라고 해서 코딩에 완전히 빠져야 한다는 조건은 없습니다.
프로젝트가 원하는대로 안될 때 설계한 대로 어떻게든 이끌어야 하니까요.

저는 hero 엔지니어가 필요하다고 보고 있습니다.
어려운 프로젝트일수록 더욱 그렇습니다.
그런 hero 엔지니어는 탁월한 기획자일 수도 있습니다.

어떤 사람은 이런 hero와 궁합이 맞는 코더 hero일 수도 있지요
적성도 고려하고 자기 미래를 설계하기 나름이지 않나 싶습니다.

자신의 미래를 고민,고찰하시고 정리하시길 조언합니다.
저장 취소
[코멘트] 좋음
2018-07-10 11:33
AgnesHyo
회사가 작으면 니일 내일이 어디잇어요.

할수 있으면 하는거죠
저장 취소
[코멘트] 좋음
2018-07-11 10:46
 guni2430  guni2430님께 메시지 보내기guni2430님을 내 주소록에 추가합니다.guni2430님의 개인게시판 가기 
진리와자유 // 제가 생각하는 기획이란 일정, 요구사항대로 프로젝트를 끝내는 작업입니다.

이건 기획이 아닌 프로젝트 매니저의 작업입니다만...

기획은 요구사항들을 정리해서 개발자가 개발할 수 있게, 디자이너가 디자인 할 수 있게 화면정의서를 만드는 일부터 시작해서,

말그대로 기획서를 만드는사람을 기획업무라고 이야기 합니다만...

개발자가 기획으로 전향자체는 상관이 없지만, 개발업무와 기획을 같이하는건 정말 아니라고 생각됩니다.

기획과 개발을 같이 하게 되면 나타나는 문제점이 여러가지가 있는데,

위에서 말을 해주신 것처럼 개발을 편하게 하기위해 기획 방향을 틀어버리는것이 있습니다.

전문적으로 기획관련 공부를 해오고 프로젝트를 해본사람과 개발일을 하다가 기획일을 하는 사람들은

정말 천지 차이입니다. 당연히 아웃풋에서도 차이나고요.

어쩔 수 없는 상황이거나 혹은 작은 프로젝트면 큰 문제는 발생하지 않겠지만

프로젝트 단위가 크면 클 수록 본인 전문쪽에서 일을 하는게 맞다고 생각합니다.

감당이 가능하실거 같다면 말리지는 않지만, 가급적이면 안하시는게 낫다고 생각됩니다.
저장 취소
[코멘트] 좋음
2018-07-11 11:16
crazygun22
저는 개발자인데 기획을 같이 합니다. 기획시에 모든 관련자들에게 동의와 의견을 반영하구요.
최종 기획안에 모든 관련자들에게 확인을 구합니다.
때문에 개발을 편하게 하기 위해 기획 방향을 어차피 틀수가 없어요.
오히려 시스템을 모르고 논리적이지 못한 기획 때문에
개발 일정은 많이 걸리고 제품이 버그 투성이가 되는 경우가 제 경험으로는 더 많아요.

기획자일이 무슨 전문기술로 생각하는데, 제가 일해 본 기획자들은 뭔가 특별한 기획을 만들지는 않았어요.
저장 취소
[코멘트] 좋음
2018-07-11 12:06
헐퀴_
소프트웨어 개발자(Software Developer)는, 시스템 분석가의 요구에 맞게 컴퓨터 프로그래밍을 하거나 시스템 설계를 하는 사람이다. 흔히 프로그래머와 혼동하기도 하지만, 소프트웨어 개발자와 프로그래머의 뉘앙스는 조금 다르다. 프로그래밍뿐만 아니라 좀 더 넓은 범위의 프로그램 설계 분야 전체를 포함한다. 사실 대한민국에서 개발자라고 하면 프로그램 개발에 관련된 모든 일을 다하는 사람이라는 뉘앙스를 가지고 있다고 보면 된다. 외국의 경우, 프로그램 개발시 프로젝트를 관리하는 사람(PM이나 게임 기획자) 설계하는 사람, UI 디자인 하는사람, DB 하는 사람 제각기 나뉘어져 있다. 하지만 한국의 경우 소프트웨어 개발자라 하면 코드도 짜고, UI 디자인도 하고, DB 설계도 하고, 기술영업도 하고... 물론, 외국도 영세 업체는 별로 다르지 않다. 사실 프로그램을 만드는 사람은 가급적 프로그래밍이라는, 그리고 그 중에서도 자신의 전문분야 한 두가지만 들이파서 거기에만 집중하는 것이 좋을 것이다. 사실 다른 모든 일도 그렇겠지만 일을 할 때 이래저래 주 업무 외적으로 신경쓰이게 하면, 업무효율은 떨어지기 마련이다. 특히 개발자가 부족한 대한민국 환경상이 아니고 원가 절감하려고 고용하기 않는다는 게 더 정확한 표현, 한명의 개발자가 커버하는 영역이 엄청나게 넓기 마련인데 이것저것 엉뚱한 일들까지 신경쓰게 만들면 당연히 개발하는 물건의 품질이 제대로 안나올수 밖에 없다.
저장 취소
[코멘트] 좋음
2018-07-11 13:13
진리와자유
guni2430 //

기획이 개발자 입장에서 말도 안되면 프로젝트가 난항을 겪습니다.
그래서 결론을 낸 것이 기획 시에 일정과 가능성까지 다 고려해서 나와야 기획대로 프로젝트가 제대로 종료된다는 것입니다.
그 방법으로 위에 crazygun22님이 말씀하신 것처럼 모든 관련자들의 동의와 의견을 구할수도 있겠고요.
그런데 참여할 모든 사람의 의견을 취합하는 행위도 쉽지만은 않은 작업입니다.

결국 Hero 엔지니어가 기획하고 PM을 하고 PL을 하는 것이 이상적이라는 결론을 내렸습니다.
PL 역할을 하게 될때 직접적인 코딩보다는 코드 리뷰식으로 전체를 조율하는 것이 좋은 것 같고요.

SI는 고객 요구라는 게 들어가니 PM이 영업적인 협상력도 있어야 하므로 솔루션 이야기입니다.
Hero 엔지이어에게 기술 외의 것까지 바라면 그건 Super Hero겠지요.

개발이 기획을 틀어버리는 일은 음... 전제가 잘못되지 않은가 싶습니다.
기획에 문제가 있으면 윗선에서 컨펌이 나지 않을테고요
컨펌 나면 기획이 바뀌면 안되지요.

제 의견의 뜻이 제대로 전달되었기를 바랍니다.
저장 취소
[코멘트] 좋음
2018-07-12 09:11
 guni2430  guni2430님께 메시지 보내기guni2430님을 내 주소록에 추가합니다.guni2430님의 개인게시판 가기 
진리와자유 //

기획에서 개발자가 쉬운 방향과 말도 안되는 방향은 전혀 다른겁니다.

제가 말한 개발하기 쉬운 기획이란건 말그대로 여러가지 방법중에 개발난이도가 낫거나 편한 방법으로 한다는거죠

사이드 이펙트나 추후 기능적인 면에서 확장될 가능성은 생각을 안하고 그냥 편하기 쉬운 방법만 택한다는 겁니다.

기획 할때는 당연히 일정도 신경써야 하고 확장 가능성 둘 다 최대한 고려를 해야하는건 맞지만

그거때문에 개발자가 기획 업무를 하는건 아니라고 봅니다.

다른분들은 기획업무가 별거 하는거 없다고 보시는데, 기획업무 생각외로 할 거 많아요

물론 기획자체도 제대로 나와야 개발자가 개발하기 편한거고요.

PM, PL, 기획 셋 전부 다 전문분야가 다른사람입니다.

뭐 말씀하신 상황대로 개발자가 기획업무를 맡아서 하는 프로젝트도 뛰어봤고,

전문 기획자가 따로 있는 프로젝트에서도 해봤지만,

기획, 개발이란게 나뉘어져 있는 이유가 있는것처럼, 개발자는 개발을 기획자는 기획을 하는게 가장 부드럽게 프로젝트가 흘러 가더라고요

물론 이건 제 개인이 경험해 본 프로젝트 들이지만 주변 몇분의 이야기를 들어봤을때는 개발자가 기획업무 맡아서 잘되는 경우를 본 적이 없어요

그리고 SI 이야기를 하셨는데, SI에서는 클라이언트가 요구사항 바꾸는게 되게 잦아요

특히나 클라이언트는 개발쪽을 모르는곳도 많기 때문에 전문가가 아닌 이상에야 제대로된 요구사항을 이끌어 내는 사람이 얼마 없어요

물론 전문가가 아닌 분들이 그 역할을 다 하는건 그 분들이 대단한거고요
저장 취소
[코멘트] 좋음
2018-07-12 17:18
진리와자유
guni2430 //

>> 사이드 이펙트나 추후 기능적인 면에서 확장될 가능성은 생각을 안하고 그냥 편하기 쉬운 방법만 택한다는 겁니다.

위의 의미가 참 여러가지를 생각하게 해 줍니다.
결론적으로 그렇게 택하는 기획자는 hero 엔지니어가 아니지요.
문제에 대해서 여러가지 코드 가능성을 예측하고 그중 최적의 코드 구조를 설계, 기획해야 합니다.
모든 시스템에서 그러기는 너무 힘들고 적어도 자기 도메인에서는 그래야겠지요.
설계된 후에 그대로 코딩만 하면 되니 품질이 떨어지는 일은 드뭅니다.

이러건 웬만한 시니어 개발자들은 가능할건데요.
다른 회사에서도 그렇겠지만 개발 일정은 경험이 많을수록 예측이 정확해지는 것 같습니다.
왜냐하면 개발된 최종 코드를 예측할 수 있으니까요.

아무래도 제가 아는 기획이라는 것과 말씀하시는 기획이 다를 수가 있을 것 같습니다.
기획이야 어차피 초반에 실무 개발 들어가기 전의 단계이므로 실무 개발과 겹치지 않는다고 봅니다.

그리고 SI를 언급한 이유는 이 상황만 예외가 되기 때문입니다.
고객의 요구라는 게 너무 막강해서 개발자를 갈아 넣는 현실이니까요.
아무리 기획을 잘 해놔도 개발 상황을 뒤집어야 하는 상황에 직면하는 일이 비일비재 합니다.

이건 기획에서 결정할 부분이 아니라 PM 차원에서 고객 요구를 컨트롤하는 부분이라고 봅니다.
아는 사람은 알지만 모르는 사람은 SW는 쉽게 고칠 수 있다는 개념에서 요구 사항이 변경되는 경우도 많거던요.
물론 초반 요구 사항 정리가 잘못된 것이라면 능력 부족이니 변명의 여지가 없습니다.
저장 취소
[코멘트] 좋음
2018-07-14 23:45
이순희
궁한 회사는 그러기도 하지요
저장 취소
[코멘트] 좋음
2018-07-18 17:59
천상.
과한 부담이 아니라면 개인적으로
좋은 경험이 될 수 있습니다.
저장 취소
코멘트쓰기
  좋음   놀람   궁금   화남   슬픔   최고   침묵   시무룩   부끄럼   난감
* 코멘트는 500자 이내(띄어쓰기 포함)로 적어주세요.
목록 보기   지금 보고 계시는 글을 회원님의 my Mblog >> 스크랩에 넣어두고 다음에 바로 보실 수 있습니다.  
회사소개  |   개인정보취급방침  |  제휴문의  |   광고문의  |   E-Mail 무단수집거부  |   고객지원  |   이용안내  |   세금계산서
사업자등록번호 안내: 220-81-90008 / 통신판매업신고번호 제 2017-서울구로-0055호 / 대표: 홍영준, 서민호
08390, 서울시 구로구 디지털로32길 30, 1211호 / TEL. 02_6719_6200 / FAX. 02-6499-1910
Copyright ⓒ (주) 데브피아. All rights reserved.