@SoftyChoco Blog

제가 겪어본 사람 중, 꼼꼼하고 책임감 있는 기획자가 있었습니다.기획자가 입사한지 얼마 되지도 않았는데, 같이 협업을 하면 소통도 잘 되고 일의 흐름도 좋았습니다.얼마 안있어 팀에 없어선 안될 존재가 되었습니다.덕분에 그 기획자는 팀장 역할까지도 맡을 수 있게 되었습니다.하지만, 역할에 맞게 일도 늘어다면서 야근이 잦아지고, 버거워지기 시작했습니다.결국, 시간이 지나 기획자와 그 팀은 무너져 갔죠.단지, "꼼꼼함과 책임감"으로 인해, 다른 사람에게 기존의 업무를 "위임"하지 못했던것이 가장 큰 이유였습니다. 혹시 이런 이야기가 낯설지 않다면, 아마 이 글을 읽으시는 분도 '일을 놓지 못하는' 책임감 강한 팀장일지도 모릅니다.하지만, 이제는 실무보다는 '팀이 일을 잘하도록 판을 짜는 것'에 집중해야 합니다..

저도 그렇지만, 많은 사람들이 '적당히 하고 넘어가자'라는 유혹에 빠지실겁니다.'이만하면 됐겠지', '월급 받는 만큼만 일하자'라는 생각은 달콤하죠.이런 유혹은 시간이 지나, 선택의 갈림길에서 '애매함'으로 다가옵니다.하지만, 실패를 했더라도 명확한 마침표를 찍을 수 있는 방법입니다.바로 무슨 일이든 '최선'을 다하는 것.예를 들어 채용공고를 적당히 살펴보고 면접에서 제대로 대답하지 못해 '운이 없었다'라는 생각만 반복하게 된다면, 탈락은 반복되고 자신감만 떨어집니다.또한, 너무 많은 영역이 부족했고, 운이라고 치부했기 때문에 개선보다는 또 같은 방법을 시도할겁니다.하지만, 반대로 지원하는 회사에 대한 정보(채용공고, 블로그, 시장상황 등 전반)를 분석하고 예상 질문/답변을 생각해보는 것처럼 최선을 다했..

개요 소프트웨어 개발 생명주기의 하나로, 폭포수 모델을 기반으로 확장된 형태. 폭포수 모델을 기반으로 검증(제품을 올바르게 만들고 있는가) 확인(올바른 제품을 만들고 있는가) 에 강조를 두었으며, 설계와 대응되는 테스트를 사전에 고려하여 문제가 발생할 여지를 줄여주는데 목적을 둔다. 단기적/초기 생산성은 낮아 보일 수 있으나, 후반부 재작업 감소로 전체 프로젝트 생명주기 관점에서는 비용 효율적일 수 있다.구성 * (그림으로 작성) V자 형태로 구성하며, 최하단에는 구현을 기반으로 왼쪽은 설계(정적 검증 활동), 오른쪽은 테스트(동적 확인 활동)를 그린다. 각 요소는 대응되는 테스트가 있다는 것을 어필한다. - 요구사항 분석 (인수 테스트 대응) - 시스템 설계 (시스템 테스트 대응) - 아키텍쳐 설계..

최선이라고 생각했던 그건, 사실 최선이 아니라 자기위안입니다.“최선을 다해봤는데, 이 직업은 제 길이 아닌 것 같아요.”상담을 하거나 동료들과 대화를 나누다 보면, 생각보다 많은 분들이 이런 고민을 털어놓습니다.자신은 정말 열심히 했는데 회사에서 알아주지 않을 때,아무리 잘하려고 애써도 마음처럼 결과가 나오지 않을 때,그리고 주변 동료들은 너무나 수월하게 일을 처리하는 것처럼 보일 때.타인과의 비교 속에서 스스로를 깎아내리며 '나는 이 일을 할 자격이 없나 봐'라는 자괴감에 빠지곤 합니다.충분히 공감되는, 너무나 인간적인 감정입니다.하지만 우리는 정말, 최선을 다해본 것이 맞을까요?우리가 '최선을 다했다'고 말하는 순간들을 가만히 들여다보면, 그 최선이 지극히 '주관적'인 경우가 많습니다. - '내 방식..

개요소프트웨어 개발 생명주기 모델 중 하나로 가장 고전적인 모델.각 단계가 순차적으로 진행되며, 다시 이전단계로 되돌아가기가 어렵기 때문에 "폭포수 모델"이라고 이야기 함.모델 구조가 간단하며 각 단계별로 산출물이 나오기 때문에 요구사항이 명확하고, 변경될 일이 없는 작은 프로젝트에 적합함.구성도타당성 검토 > 계획 > 요구사항 분석 > 설계 > 구현 > 테스트 > 유지보수작업 방식타당성 검토기술적, 법적으로 문제가 없는지 검토하는 단계산출물: 타당성 검토 확인서계획프로젝트의 범위, 일정, 자원 등을 수립하는 단계산출물: 프로젝트 계획서요구사항 분석고객 요구사항을 분석하고, 명세하는 단계산출물: 요구사항 명세서설계요구사항 명세서를 기반으로 DB 구조, 시스템 구조 등을 설계를 진행하는 단계산출물: 시스템..

저는 면접관으로서 지원자를 만날 땐, 약점을 물어봅니다.이 질문에 지원자들의 흔한 답은, "생각을 못 해봤네요."나 "제 약점은 이러이러합니다." 라는 대답입니다.그나마 그중의 일부 지원자는, "제 약점은 이러이러 하지만, 이런 부분을 통해 개선하고 있습니다."와 같은 답변을 해서 자기 객관화와 성장 가능성을 어필하지만, 이 또한 반쪽짜리 답변입니다.왜 이런 답변이 '반쪽짜리'일까요?자기 객관화와 개선 의지는 분명 훌륭한 덕목입니다.하지만, 채용이라고 하는 것은 '지원자'만의 이야기가 아니라, '회사와 지원자가 어떻게 어우러지는지'를 알아보는 자리입니다.결국 위 답변들에서는 '우리 회사와의 연결고리'가 빠져있습니다.개인의 노력만으로 성장하겠다는 다짐은 어디에서나 할 수 있는 이야기입니다.그리고 그 답변은..

팀원이 정말 이해한 게 맞을까요?간혹 팀원이 어려운 문제가 있어 질문을 해오는 경우가 있습니다. 그럴 때, "A 방법을 사용하면 돼요" 라고 답을 주면 팀원이 "네 알겠습니다."라는 답변을 하고 문제가 해결되었을거라고 생각하는 팀장들이 있습니다. 그리고 며칠 뒤, 여전히 해결되지 못한 상태로 "A 방법에 대해서 찾아봤지만, 잘 모르겠습니다 ㅠㅠ"라는 팀원을 다시 만나거나, 문제가 더 커지고 나서 알게되는 경우가 발생하는 상황이 있습니다. 왜 이렇게 된 걸까요? 이런 상황은 이런 경우 발생합니다. - 너무 바쁜 팀장 - 자존감이 낮아진 팀원의 인정 욕구 - 팀장&팀원 서로간의 이해 부족 팀원 입장에서 보면 이렇습니다. 팀원: '이 문제에 대해 잘 모르겠다... 팀장님이 바쁘지만 용기내서 물어봐야겠다'..

정말로 비판적인 사고를 하고 계신가요? 흔히 채용공고에서 "비판적인 사고를 하시는 분"이라는 내용을 볼 수 있습니다. 근데 정작 이걸 잘못 이해하시는 분들이 있습니다. "나는 다른 사람들의 이야기에 반박하는걸 좋아하니까, 비판적인 사고를 하는 사람이야!" 라며 자신이 그런 사람임을 이야기하죠. 비판적인 사고라는 것은, 나 혹은 타인의 주장이 틀리지 않았는지, 맞는 주장이더라도 혹시 또 다른 관점은 없는지, 나아가 더 나은 해결책은 없는지 등을 검증하는 것입니다. 그리고 이 과정에서 있어 반드시 필요한 하나가 있는데요. 바로 "더 나아가고자 하는 생각"이에요. 더 나아가고자 하는 생각 없이 비판만 한다면, 그건 비관적인 사고입니다. 자신이 하고 있는게 비판적인지, 비관적인지 잘 판단해보세요. 비판적인 사고..

혹시 불안해서, 다른 역할을 하고싶은 생각이 든적 있나요?간혹 자신의 업무가 맞지 않다고 생각해서, 다른 역할이나, 다른 업종으로 바꾸는게 답이라고 생각하는 분들을 만나곤 합니다.흔히 이야기하는 상황은 이렇습니다.다른 사람들과 협업하는게 너무 어려워, 그냥 나 혼자 일할 수 있는 직무로 바꿔야하나?내가 다른사람들에 비해 기술적으로 너무 부족한 것 같은데, 누구나 다 아는 건데 나만 모르는 것 같아...이쯤 되면 그냥 개발자가 나랑 안맞는걸까? IT 업계를 떠나야하나...사실 이런 고민은 생각보다 많은 분들이 하고 있습니다.새로운 도전을 위해 직무를 바꿔보려는 것 이라면 좋은 일이지만, 단순히 불안감을 회피하기 위해서라면 조금 더 생각해볼 필요가 있습니다.사실 이런 고민들이 드는 이유는 단지 불안감으로 인..

취업/이직 시 처음에는 여러가지 방법으로 이력서를 찾아보고 적게 된다. 그리고 서류, 면접에서 몇 번 떨어지다 보면, 점점 이도저도 아닌 이력서가 되어가는 경우가 있다.왜 이런 경우가 발생하는 걸까?먼저 이력서의 경우, 불합격으로 인해 주변의 피드백을 받는 경우가 많다주변의 피드백이 면접관으로써 실력있는 한 사람이라면 괜찮지만, 주로 비슷한 연차거나, 면접관으로써의 실력이 없는 사람들 여러명에게 받는 경우이다. 이력서는 "채용공고에 맞는 역량"을 "내가 경험해온 것"으로 녹여내야하는데, 사람마다 어필하는 방식이나 표현이 다르고 중요하게 생각하는 부분이 다르다.예를 들어 기술적인 역량이 중요한 회사에 다니는 경우, 자신의 이력서는 기술적인 역량으로 합격했기에 기술적인 역량을 어필하라고 한다. 협업 실패를 ..