|
:: 게시판
:: 이전 게시판
|
- 모두가 건전하게 즐길 수 있는 유머글을 올려주세요.
- 유게에서는 정치/종교 관련 등 논란성 글 및 개인 비방은 금지되어 있습니다.
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
18/11/10 22:33
제가 들어본건 네이버처럼 만들어달라고 할때(제안서 25명인데 혼자함 피엠은 IT모름 그당시 연봉 2700)
참고로 저말을 한건 피엠
18/11/10 22:53
그러게요... 개발 일정을 개발자가 산정 안 해주면 누가 하나요...? 물론 나중에 지키지 못할 수는 있지만 대략적인 마일스톤이라도 찍어줄 수 있어야할것 같은데요
18/11/10 23:23
(수정됨) 마케팅 일정 잡아놓는 제조업 제외하고 소위 잘나가는 회사중에 5번을 저렇게 타이트하게 하는 회사는 많지 않습니다. 사실 거의 없다고 생각해요.
저렇게 커뮤니케이션하는 순간 개발자는 최소 실제 예상 ×1.3하는 수 밖에 없어요
18/11/11 00:12
문제는 5번만 문제가 생기면 상관없는데
1~14 사이의 다양한 문제들이 복합적이라는게 문제겠죠 기획이 자꾸 변하는데 넘겨받은 코드도 엉망진창 근데 입코딩러가 이 정도면 금방하죠? 언제까지 할수 있어요? 근데 내일 기획이 또 바뀜 이런 상황......
18/11/11 00:34
글쎄요. 기획이 절대 안바뀐다면 가능하겠네요.
그게 아니라면 5번에 정확한 답을 해주는건 사실 불가능하죠. 코드리뷰나 큐에이도 생각하면 말이죠. 전 개발자의 능력을 정확한 일정지킴으로 체크하는건 잘못되었다고 봅니다.
18/11/10 22:55
2. 자바코드 이터레이터랍시고 Next() 구현해놓은 코드 보고 어이가 없어서..next() 아니라 Next()라서 게다가 하는 짓은 hasNext()였음..
18/11/11 00:09
윗분들도 말씀하셨지만 5번은 그 자체가 문제가 아니라, 정하라고 해서 정하면 그걸로 끝이 아닌 경우가 다반사라 그렇겠죠.
전 개발자는 아니고 개발도 할 줄 모르지만 쪼이는 개발자는 꽤 본 것 같거든요.
18/11/11 00:36
5번 1번만 아니면 가능합니다.
1번때문에 절대 불가능하다고 봅니다. 전 애초에 단칼에 완벽한 기획이 나오는것도 불가능하다고 생각하기 때문에, 5번을 물어보는 기획자에게도 답 제대로 안해줍니다.
18/11/11 00:28
2번도 사실 1번의 영향력이 좀 있죠.
기획이 자꾸바뀌면 코드가 더러워지는건 뭐... 문법자체를 잘못 쓰는경우가 아니면 대부분 1번이 원인이더라구요. 개발중에 기능 추가/변경/삭제가 이루어지니 덧칠만 계속하는거죠. 그러다보면 인수인계 받을때 답이 없습니다.
18/11/11 00:54
데드라인만 없으면 기획이야 계속 바꾸는 게 좋다는 쪽이긴 합니다. 물론 자체 서비스가 아니면 그만큼 클라이언트가 추가 개발 비용을 지불하거나 개발자가 추가 개발할 시간이 없으면 기존 기획대로 해야겠고요. (혹은 변경된 기획대로 가되 테스팅은 포기하거나 식이 되겠죠.) 그게 아니라 데드라인을 고정 시켜놓고 기획을 바꾸거나 약간의 추가 일정만을 요구한다면 탈 날 확률이..
18/11/11 01:37
그런 스케쥴 관리가 의미가 있을까요?
기획이 추가되면 늘어날거고, 바뀌면 지금까지 짯던거 뒤집어야 할텐데... 무엇을 위한 스케쥴 관리죠? 개발을 빨리 완성시키려면 그냥 개발자가 일 열심히 하게 하면 되는데. 일정 산정하게 하고, 기획이 바뀌었으니 몇일 더 늘어나겠다 어필하게 하고. 이게 의미가 있을런지. 이렇게 일정 산정하고 자기 어필하는 개발자들 일 잘한다 소리 듣겠지만 비효율적인것도 사실이거든요.
18/11/11 01:55
의사결정을 위한 스케쥴 관리죠.
내용에 따라서 시기가 중요한 것이 있을 것이고, 시기 보단 내용 자체가 중요한 것이 있을텐데요. 시기가 픽스되어 있다면, 기획 수정 없이 갈 것이고, (혹은 원래 기획 내용을 축소시키던지) 내용이 더 중요하다면, 일정을 추가적으로 확보해서 연기하던지 하겠죠.
18/11/11 02:19
그런 의사결정은 제가 보기엔 개발진행상황 보고 중간에 해도 될 거 같습니다.
불완전한 기획서만 있는 상태에서 얼마 걸리냐고 물어볼 필요는 없다는거죠. 또한 시기가 중요하다면 굳이 개발자의 일정이 중요한게 아니라 데드라인에 맞추면 될일이고, 내용이 중요하다면 "몇일 걸리느냐" 가 중요한건 아니지 않나요?
18/11/11 11:02
데드라인이 정해져 있더라도 기획자가 역산을 해서 언제까지 기획서가 확정되야 하는지 알려면 5번은 필요하죠 정확히는 아니더라도 최소한 요구사항 확정되고 얼마 걸린다 정도라도요
안그러면 기획자는 이 일이 1주일이 걸릴지 1달이 걸릴지 알 수가 없는데요 개발자가 5번을 제대로 안해주면서 9번을 욕하면 안돼죠
18/11/11 15:05
[기획자가 역산을 해서 언제까지 기획서가 확정되야 하는지 알려면 5번은 필요하죠]
이말이 좀 이상한게, 5번 그러니까 얼마 걸리냐고 물어보려면 기획이 나와야 됩니다. 뭘 만들질 알아야 얼마걸리는지도 알거 아닙니까. 근데 이 시점에 무슨 역산을 해서 언제까지 확정을 한다는겁니까. 걍 최대한 빨리 확정해야죠. 그리고 기획자가 개발은 아얘 아무것도 모르고 기획하면 제대로된 기획이 나올리가 없어서 개발자랑 얘기하면서 수정 많이 거쳐야 됩니다. 개발을 아는 기획자라면, 데드라인 안에는 가능하죠? 정도 질문이면 충분하구요.
18/11/11 16:01
기획된게 아무것도 없는데 일정을 물어보는건 기획자가 미친거고...
현재까지 나온 요구사항을 개발하는데 필요한 일정은 개발자가 산정해줘야죠 리스크가 있으면 그것까지 포함한 일정을 주면 됩니다 변경사항이 있으면 그에 맞춰서 다시 산정해주면 되구요 데드라인까지 된다 안된다가 문제가 아니라 어느정도의 버퍼가 있는지 알아야 요구사항 변경이나 추가에 어떻게 대응할지 관리자가 결정을 하죠 하다못해 결국 일정을 못맞춰서 문제가 생겼을 때도 개발자가 일정 관련 문의에 잘 대응을 해줬을 때가 책임 공방에서도 도움이 됩니다 게다가 기획한테는 [최대한 빨리]를 요구하시면서 자기는 대략적인 일정도 못주겠다고 하시면 안되죠
18/11/12 02:55
(수정됨) 리스크 말씀하셨는데, 제일 큰 리스크가 요구사항 변경/추가, 즉 기획변경 입니다.
그래서 '현재까지 나온 요구사항' 같은게 의미가 없다는거구요. '현재까지' 라는말이 이미 더 추가되거나 변경될거라는 사실을 내포하고 있으니까요. 기획이 어떻게 바뀔지를 개발자가 무슨수로 예측합니까? 아니면 기획이 어떻게 바뀔지는 모르지만 리스크가 있으니까 *2 해버리면 서로 손해일텐데요. 걍 제가 생각하는 일반적으로 좋은 그림은, 기획자도 대충의 감이 있어서 가능한 일정, 가능한 일감을 들고 와서 물어보면, 어 충분히 가능할듯. 이정도 대답이면 충분하다는거죠. 정확하지도 않은 10일 걸리겠어. x달 걸리겠어. 이런게 의미가 없다는거구요. 책임공방 같은건 정말 최악의 이야기네요. 같은 프로젝트 팀원끼리 책임공방이라니...
18/11/12 07:45
아니 기획 변경되면 그 때 다시 일정 산출하면 된다니까요?
리스크는 현재 요구사항 구현에 대한 리스크지 거기다가 왜 자꾸 기획 변경을 포함시키나요 기획을 바꾸면서 일정은 무조건 원래 준데로 가겠다는 관리자가 있으면 때려치고 나오세요 그리고 가능/불가능 을 대답해줄 수 있으면 본인이 생각할 때 대충 얼마나 걸릴지 이미 나온거 아닌가요? 그럼 그걸 말해주면 되지 그게 뭐 대단한 정보라고 숨기나요 [같은 프로젝트 팀원]끼리
18/11/12 08:23
(수정됨) mmm 님//
대단한 정보라는게 아니라 어차피 부정확해서 쓸모가 없는 정보라는 겁니다. 제가 한달이라고 해봤자 있을지 없을지도 모르는 리스크 포함되었다는걸 님도 알고 저도 알고 믿지도 않는데, 그 한달이라는 시간이 무슨 의미가 있나요? 두달이라고 하면 믿을겁니까? 있을지 없을지도 모르는 리스크에 기획이 변경되면 원래 일정까진 몰라도 '데드라인'은 문제가 됩니다. 데드라인은 기획자 마음대로 변경할 수 있는것도 아니에요. 즉 기획이 자주 변경되는 일 자체가 원래 없어야 됩니다. 기획이 변경되면 일정 다시 산출하세요 라는 말은 너무 편한말인거죠.
18/11/12 10:11
keke 님// 그렇게 따지면 가능/불가능도 부정확해서 쓸모 없는 정보 아닌가요? 일정 산출은 대부분 경험에서 나오는거고 연차가 쌓이면 대부분 비슷하게 맞출 수 있습니다 예상치 못한 이슈가 생겨서 타겟 날짜를 못맞추면 그때 가서 조정을 하더라도 일단은 날짜를 주는게 OX퀴즈를 하는 것보단 낫구요
남들 다 하는거 본인이 못해서 못하는걸 필요없다고 하는 패기는 어디서 나오나요
18/11/12 11:51
mmm 님//
보아하니 답변할 수 있는 내용에만 답변달고, 아닌건 달지도 않으시네요. 거기에 제가 할줄 아는지 모르는지는 어떻게 아시고 마지막 문단 같은 말을 하시는지 모르겠네요.
18/11/12 12:54
keke 님// 어떤 부분에 답변을 원하시는지 모르겠네요 본인이 예측하는 일정이 부정확해서 쓸모없는 정보라고 스스로 말하셨잖아요? 아니면 할 줄 아시는데 안알려주시는건가요? [같은 프로젝트 팀원끼리] 왜 그렇게 일하시나요?
아니면 [기획이 자주 변경되는 일 자체가 원래 없어야 됩니다.] 이부분인가요? 당연한 소리를 해놓고 저기에 제가 무슨 답변을 해야 하는지 모르겠네요 저도 요구사항 자꾸 바뀌면 짜증나지만 그렇다고 일정 못주겠다고 째지는 않습니다
18/11/11 03:37
사실 다른건 이미 많이 경험하고 받아들이는데 개인적으로는 그냥 6번... 입만 나불대지 말고 그렇게 불만이면 직접 고치라고요... 아놔...
18/11/11 04:03
5번은 경험있는 기획자면, 기획이 제대로 되어있으면 기획자 본인도 대략 예상가능하고 또 그게 매니저의 능력과 임무일텐데 실상 5번 요구하는 사람은 본인도 기획이 제대로 안되어있거나 능력없는거죠. 데드라인 맞춰서 해도 결국 자기가 생각한거 아니였다고 기획 뒤집고 종국에는 기한 못맞춰서 개발자 탓하거나 퀄리티 못맞췄다고 개발자 욕하거나.. 이게 현실이죠. 1년짜리 프로젝트면 기획 엎어지고 뜯어고치고 실제 결과물에 쏟은 시간은 마지막 한달정도나 되고 그럼 퀄리티도 한달짜리가 되는건데 욕하는건 1년이나 시간 줬는데 솔루션 쓴 것 보다 못하다는 욕 먹고..
18/11/11 08:44
6번은 진짜 어려운게...
대충 해결하고 넘어가도 될일을 정말 깔끔하게 해결하고 넘어가야 할일로 바꿔버리니... 문제의 크고작음을 결정할 권리를 저에게서 뺏어가는 느낌이죠
18/11/11 09:41
영업이 있지도 않은 기능을 있다고 뻥쳐서 팔거나 만들어준다고 무대포로 계약. 고객을 만났더니 계약은 상급자가 한거라 정확인 뭘 해야하는지도 잘 모름. 어지저찌 요구사항 캐물어서 수집하려했더니 말도 안되는 기능들을 요구. 최대한 짤랐는데 영어, 고객은 그래서 얼마나 걸려요? 시전. 팀장과 일정 조율하는데 내가 일정 말하니 그거 하는데 그렇게 시간이 많이 걸려? 이거 이렇게하면 되잖아 시전. 설명해도 안먹힘. 일정 단축. 설계과정에서 기술적 제한 발견. 팀장 영업 협의. 고객 노빠꾸. 야근 발생. 기간 어찌 마춰서 개발했는데 고객 기능 추가 수정 미친듯 발생. 영업 커버 못침. 고객 이거 안되면 검수안함 흥칫뿡. 일정 조율 없음. 야근 시작. 이렇게 너덜너덜한 코드에 이력, 기능 명세 문서도 없는 코드를 인수인계없이 5년이 지나서 갑자기 버그로 수정해야함. 그리고 야근 주말 수당 없음.
이게 일반적은 한국 SI, 솔루션 회사들의 현재 상황이지 않으려나.
18/11/12 11:56
5번은 스케쥴 관리상 확인은 해야하는데 확실히 정해달라는거가 문제인 것 같네요.
그렇다고 기획/사업 쪽에서 서툴게 기한을 말해 버리면 9번이 되버리니 참 어려운 문제인 것 같습니다. 저도 경험상 개발자 분들한테 대략적인 기간을 듣기가 어려웠었는데 이게 꼭 개발, 기획에만 국한된게 아니라 마케팅, 운영과도 다 얽혀있는거라 도중에 변경되더라도 스케쥴은 잡아봐야하는게 회사라는 단체라는 걸 이해해줬으면 좋겠다..라는 생각을 해본적이 있습니다. 크크
|
||||||||||||||
