개발자의 실수에대한 책임

Question

특정될 수 있어서 지웠습니다. 감사합니다.가스라이터들에게 당하지 않겠습니다.

hieroglyphs · Answer

항상 양자 의견을 다 들어봐야 하겠지만, 님이 작성하신 글만 그대로 본다면 당연히 프로세스에 문제가 있고, 팀장이 팀장 역할을 못하는 것이죠.별개로, QA상관없이 본인이 개발한 건은 본인이 철저하게 테스트하는게 일단 맞습니다. QA가 있으면 버그에 대해서는 개런티 해주겠지만 이러나 저러나 본인이 개발한 기능에서 버그가 나오는 것 자체에는 책임감을 가져야한다는 의미입니다.받는만큼만 일한다-정말 그게 가능한지는 모르겠으나...- 라는 마인드를 가지신 것 같은데, 긍정적으로 생각하세요. 본인의 연차와 그에맞게 주어지는 R&R을 벗어나는 업무(실무)를 하고 계시다는 건 남들과는 다른 밀도의 경험치를 쌓고 있다는 의미기도 합니다.어떻게 활용하느냐에 따라 더 좋은 직장에 이직하기 위한 훌륭한 무기가 될 수도 있지요

녹호 · Answer

1. 곧 오픈할 서비스 혼자 감당: 말씀을 하세요 "이 프로젝트 곧 오픈인데 제가 혼자 맡고 있어 부담감이 크다. 진행상황 체크나 코드 리뷰라도 해주셨으면 좋겠다"2. 별도의 테스트: 원래 QA직군 없으면 개발자가 다 합니다 테스트시트도 다 작성하고요3. 애매모호한 기획요구사항: 저도 이것때매 짜증나긴하는데 드문 일은 아닙니다. 개떡같이 말해도 찰떡같이 알아듣고 "이러이런 걸 말씀하시는 게 맞나요?"라고 그자리에서 구체적으로 확인하면서 들어가야 합니다.4. 관리하는 레포지토리 7개: 이건 뭐 회사사정이니 패스5. 팀장 본인이 PM도 아닌데: 팀장의 마음까지 알아줄 필요 없습니다 즐겁게 하든 울며 겨자먹기로 하든 일만 하면 됩니다6. 일감 내가 알아서 가져가다가: 이게 젤 문제라고 보는데요, 이부분은 약간 님 문제인거 같습니다 왜 일감을 알아서 가져가나요? 그거를 분배해주지도 않았는데 스스로 가져가서 빵꾸를 내면 완벽히 할수도 없는데 할수 있다고 생각한 님이 좀 잘못한 부분이 있다고 보여집니다. 아니면 중간에 깨달았으면 중간보고를 해서 "이런이런 문제가 있어서 이대로 가다간 빵꾸가 날 것 같다, 도와달라"고 하던가요... 물론 큰 회사에서는 시스템과 프로세스로 이런 상황을 막는데요 주먹구구식으로 돌아가는 중소기업은 그런게 없기때문에 개인의 책임감과 의사소통 능력에 의존합니다.전체적으로 봤을때 뭔 느낌이냐면 이상을 꿈꾸지만 현실을 사는 분인 것 같네요.님이 생각하는 부분이 틀린 건 아닙니다. 책임감과 열정 있는 팀장, 평탄한 일감 분배, 프로세스 잘 갖춰진 회사, 언젠간 그런 회사 갈 수도 있겠죠근데 지금은 아닙니다. 그런 데 가려면 거기서 살아남아야 합니다. 팀장에 대한 감정이 이미 나빠져 상황공유나 의사소통이 부족하신 거 같다고 짐작해봅니다만 인간이 더러워도 감정과 일은 분리하셔야 됩니다.짜증내더라도 신경쓰지 마세요. 내가 요청한 일을 해주냐 안해주냐만 신경쓰세요. 욕하고 짜증내면서도 해주면 그걸로 된겁니다.제 전회사랑 상황이 너무 비슷해서 좀 길어진 감이 있는데 더러워도 이거 다 내걸로 만들어서 이직해주마 생각하십쇼. 화이팅입니다

음 · Answer

경험산 신입과 1년차의 말은 양쪽 얘기 들어봐야됨

캐티 · Answer

4번은 본인이 맡은 일인데 못 고치겠으면 답이 없쩌. 애당초 못 고치게 만드는 거이면 개발자는 고집이 강하다는 이유를 들어서 반항을 하여야 해요.3,5번은 의사소통을 잘하여서 해결하여야 하는 거여요. 말이 안통하는 사람이거나 이런 사람을 채용하였거나 .. 일부러 채용하지 않았곘지만 머 결과적으로 못하겠으면 답이 없쩌.솔까 오래 개발하면서 머머 문제는 아니지만 개선할 여지는 있다는 부분이 많쩌. 시간과 돈이 무한하면 다 바꿀 거여요. 이런데 내 돈을 쓰겠다 이러는데 누가 말리더나요.

chytonpide · Answer

코드를 추가함으로 다른 곳에서 예상치 못한 버그가 발생하는 건지, 새로 구현한 것들이 요건대로 동작하지 않는 건지 구분해 봐야해요. 후자면 본인 실력 문제 입니다. 매니저들도 신뢰도 낮은 코드를 딜리버리하는 팀원에 대해서 한번 생각해볼 필요가 있어요. 마치 태도 문제처럼 보이거든요. 테스트를 하냐 안하냐의 태도 문제인 경우는 거의 없습니다. (이런경우면 피드백 한번으로 고쳐지기도 하겠죠.)실상은 테스트의 목적과 중요도, 어떻게 테스트할지, 어떤 부분이 약할지 생각하지 못해서 신뢰도가 낮은거죠.

カワウソ · Answer

요구사항 분석이라는게 없는 조직이라 어쩔 수 없어요. 기획이 애매모호할수록 신경써야하는데 대부분 핑계로 넘어가죠. 근데 내 실수는 사소하고 남의 실수는 태도로 보는게 마치 최근 논란이 많아진 백XX님 같군요.

WLM · Answer

여기달린 댓글도 그렇고 회사도 그렇고 가스라이팅 오지네요 규모가 작다고 책임도 n빵일 순 없는건데 시스템이 허술해서 계속 실수를 개인의 문제로 만드는 회사는 답 없습니다

장독깨기 · Answer

전체적으로 좀 웃기는 상황이네요. 1. 팀장과 중니어 둘이 대부분의 시간을 페어 프로그래밍한다? 둘이 사귀나요. ㅎㅎ페어로 하려면 팀장이 글쓴이와 해야겠죠.3. 기획은 늘 애매모호합니다. 기획과 글쓴이가 구체화 하지 못허면, 팀장이 나서서 구체화 해야 합니다.5. 미 할당한 일에 대해 신입에게 책임을 묻는다? 팀장 이게 돌았나. ㅋㅋ팀장이 책임감도 없고 역할을 전혀 못 하고 있네요.기회 만들어서 팀을 옮기세요.그리고, 너무 스트레스 받지 마세요. 본인이 뭔 가를 잘 못 하고 있는게 아닙니다.물론, 맡은 일에 대해서는 책임감 가지고 열심히 하는건 중요합니다.

퓨리오사 · Answer

팀장과 중니어 둘이 페어프로그래밍(대부분의 시간)-> 팀장이 직접 실무를 하는 경우도 있고 아닌 경우도 있지만 둘이 페어를 하는건 잘 모르겠네요. 본인이 실무를 할 시간이 없으면 지시를 하고 확인을 해야겠죠.별도의 테스트 거의 없음 (개발자 본인이 테스트하고 끝남)운영배포 당일에 가끔 통합 테스트-> 안타깝게도 테스트를 개발자만 하는 경우가 많더군요.기능적 버그는 없어야 하는게 맞고 최소한 기획 및 고객 테스트도 반드시 필요하다고 봅니다.애매모호한 기획요구사항 (기획한 사람도 잘 모름)-> 재밌는 것은 고객도 모릅니다. 고객 조차도 내가 뭐가 필요한지 모르는 경우가 많습니다. 기획한 사람도 고객이 뭐가 필요한지 모르고 기획하는 경우도 많고 그게 개발까지 전달되고 나중에 결과물 보고 다시 요구사항 정의부터 시작하는 경우도 많습니다. 그래서 애매한 경우 개발자가 개입해서 하나하나 따지고 정리해야 하며, 제대로 정의가 안된 부분은 돌려보내서 다시 정리하게 해야 하며, 그대로 수용하고 가면 안됩니다. 수용 시점에서 개발자 책임으로 전가되는 경우가 대부분입니다.관리하는 레포지토리 7개 (심지어 한 레포에 브랜치 나눠서 각각 다른 서비스로 배포되는 것도 있음)-> 버전 관리 문제점 지적하고 개선하자고 해야 합니다.오묘한 일감 할당 방식팀장 본인이 PM도 아닌데 이걸 왜 해야 하는지 의문을 갖고 있음-> R&R 명확하게 구분 짓자고 해야합니다. 일감 할당 해달라고 하면 나보고 알아서 가져가라고 함-> 일감 알아서 가져갈테니 일정 조율도 알아서 한다고 하세요. 우리팀 일감을 다른팀 팀장이 만들어서 우리팀장 이름으로 할당해주는 지경에 이름 -> 일감 관리가 안되고 있네요.알아서 일감 가져가다보니 할당되지 않은 일감들이 마감를 못지키게 되고. 이것을 내 책임으로 돌림-> 프로젝트 관리가 안되고 있네요. PM이 없으니 일정관리도 안되는 것이겠죠.

초보개발자111 · Answer

관리하는 레포지토리 7개 (심지어 한 레포에 브랜치 나눠서 각각 다른 서비스로 배포되는 것도 있음) -> 한레포에 브랜치나눠서 다른서비스로 배포하는거 진짜 극혐이에요 본인들이 개발할때 편하면 장땡인건지 나중에 계속 인수인계할생각안하나;

HJOW · Answer

음 요건 글펑 인정합니다.저런 가스라이터들이, 커뮤니티를 모니터링 안할 리가 없죠.

개발자의 실수에대한 책임

11개의 답변

커리어 목록