임베디드 프로그래머의 타 부서와의 업무들

지난번에는 라우터 개발에 대해 제가 진행했던 업무들에 대해 소개를 해드렸습니다.

그래서 이번에는 그 내용들을 토대로 왜 kernel이나 device driver로 가는게 좋은지 소개해 볼까 했는데 그것보다 우선 타 부서와의 업무는 어떻게 되는지 알려드리는 것이 좋을 것 같아 준비해 봤습니다 ㅎ

 

지난 글은 프로그래머로써, SW팀원으로써 개인적인 업무 내용들이고요.

사실 회사라는 것이 한 사람, 한개의 부서만으로 돌아가는 것이 아니라는 것은 여러분들도 잘 아실 것이라 생각됩니다.

임베디드 시스템은 전자기기를 만드는 곳이 대부분이다 보니 제조업에 속하는 곳들이 많이 있습니다.

저도 제조업에서만 프로그래머를 하고 있고요.

 

이번 글에서도 제 주관적인 경험을 가지고 설명을 드릴까 합니다. 따라서 다른 회사들과 다를 수 있으며, 가이드 라인 정도로 생각하고 봐주시면 감사하겠습니다.

 

회사 조직에는 경영기획, 영업, 연구소, 제조, 생산, A/S 등 다양한 부서들이 있습니다.

이 중 연구소에 H/W(hardware), S/W(software) 팀이 있고요. 임베디드 프로그래머는 S/W 팀에 속합니다. 보통 S/W보다는 FW(firmware)라는 단어를 많이 씁니다. 그래서 팀도 FW1팀, FW2팀으로 나뉘기도 하고요.

전자기기가 만들어지는 큰 업무 순서는 아래와 같습니다.

1. HW팀이 회로 설계, 테스트를 통해 테스트 제품 제작

2. SW팀이 테스트 제품으로 bring up, 기능 점검, 기능 구현 등 시작

3. 테스트 제품이 어느 정도 안정화 됐다면 HW팀에서 정식 제품 제작

4. SW팀이 정식 제품으로 고객사 요구 사항에 맞게 모든 기능 점검 및 구현

5. 4번 단계에서 어느 정도 구현이 됐다고 판단되면 QA팀에 검증 요청

6. QA 검증시 나오는 문제와 아직 남은 기능들을 SW팀이 구현

7. 고객사 인증 전 QA와 최종 테스트 진행

8. 고객사 인증 진행

9. 인증 진행 중 나오는 문제 사항 대응

10. 고객사 인증 완료 후 제품 출시

11. 제품 출시 후 고객 문의 대응 - 고객 문의는 고객사가 받아서 전달해 줍니다

 

QA팀은 연구소와 같이 있기도 하고 별도로 떨어져 있기도 합니다. 어느 부서에 속해 있느냐에 따라 QA가 힘을 가지고 있을 수도 있고, 없을 수도 있는데 아무래도 연구소에 같이 있게 되면 힘이 없는 편 입니다.

대기업은 만드는 물량이 많다 보니 QA가 연구소 보다 힘이 쎄고요. 그만큼 책임감이 막중 합니다. 중소기업은 고객사 일정 맞추기 바빠 사실 QA가 힘이 없는 편이 많고요…

 

여튼 1~11가지 정도로 업무 순서를 정리해 봤는데

1, 2번이 동시에 진행되고, 3, 4번이 동시 진행되다가 4, 5, 6이 동시 진행된다고 보시면 됩니다.

타 부서와의 업무 협조는 보통 팀장님들을 거쳐서 진행되는 경우가 많은데 첫 시작이나 중요한 사항이 아니라면 실무자들끼리 진행하는 경우가 많습니다.

2, 4번 단계에서 HW 문제라고 판단되면 HW팀에 문의도 해야 되고, 5~7번 단계에서도 HW 문제이면 HW팀에 QA가 잘못 테스트 한 것이면 QA팀에 올바른 정보와 함께 간단하게 교육도 해줘야 하고요.

신입분들은 크게 신경 안쓰셔도 되는 사항이지만 중소기업가면 그런 것 없이 해야 되는 경우도 있습니다 ㅎ

 

프로그래머니까 코딩만 하면 되지. 코딩만 잘하면 되는 것 아냐!? 라고 생각하시겠지만 아쉽게도 아닙니다 ㅎㅎ 물론! 기본적인 타 부서와의 협조가 있는데 무시하고 코딩만 하시는 분들도 많습니다.

예를 들면 메일 하나 보내놓고 있는다거나 다른 사람을 시켜서 처리하거나 등등 의외로 사람과 대화하고 부딪히는 것을 잘 못하는 분들이 많더라고요.

내 사수가 내 선임이 이러면 참… 코딩을 무지하게 잘하면서 저러면 욕은 들먹지만 그런 분들 많이 못봤습니다 ㅎㅎ;;

 

11번 같은 상황은 자주 없는데 생기면 골치 아픕니다.

보통은 QA와 A/S팀이 고객사와 대응 하면서 자료도 만들어 주고, 교육도 시켜주면서 고객사쪽 A/S팀이 대응을 하거나 내가 다니는 회사의 A/S팀에서 대응하고 끝나거든요.

그런데 문제 사항이 개발자들까지 온다는 것은 큰 문제입니다.

예를 들면 제품이 빵! 하고 터졌다거나 불탔다는 기사 한번쯤은 보셨을 것 입니다.

바로 그런 사항들이고요… 또는 B2B로 제품이 나간 상황에 개발자들 오라고 해! 라는 상황이 생깁니다 ㅎㅎ;;

그러면 영업 직원, QA 직원, SW 직원 셋트로 나가요. 이 상황은 정말… 식은 땀이… 시간이 걸려도 문제만 명확하게 해결되면 타 부서 분들도 좋게 봐주시고, 대외적으로 회사 기도 살려주는 격이라 내 자신에 대한 능력을 뽐낼 수 있는 기회지만 해결되기까지의 그 순간은… 와우!! ㅎㅎㅎ

 

정리해 보자면 프로그래머라고 해서 코딩만 하는 것이 아니다.

진급할 수록 사람들과 부딪혀야 하고, 여러 상황에 대한 대처능력도 필요합니다.

따라서 대화 능력, 대인 관계가 필요하다는 것이죠 ㅎㅎ

물론! 본인은 그런쪽은 못하겠다! 하면 다른 사람을 시키던지 할 것 입니다. 그러나 그렇게 되면 본인에 대한 평가가 낮아질 수 있고, 특히 연봉 협상 때 불리하겠죠 ㅎㅎ

아 물론! 코딩을 무지하게 잘하면 그런 문제는 안생깁니다. 무지하게 잘한다가 어느 정도냐? 남들보다 빨리 문제 해결을 한다던지 내 윗 사람들이 못한 것을 한다던지 말 그래로 내가 속한 조직에 누구보다도 코딩을 잘하는 것을 말합니다 ㅎㅎ

 

회사 생활을 한다는 것. 사회 생활을 한다는 것은 어쩔 수 없이 사람과 살아야 하는 것을 내포하고 있다고 생각됩니다. 평소 사람들과 대화하는 것이 어렵고, 귀찮다고 하더라도 상대방이 어떤 생각을 하고 언행하는지 정도는 스스로 데이터를 쌓아 보시기 바랍니다. 그러면 한 두마디만으로도 원활한 대인 관계를 유지할 수 있습니다.

 

궁금한 사항은 언제든 댓글 남겨 주세요~~