일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- Specification
- 와인버그
- 교훈들
- Open Computer Vision Library
- 인간
- Python
- 품의
- 회고
- 페북글
- xper
- 안좋은기억
- 원격면접
- build
- 개저씨
- MacOS X
- 애자일
- 스펙
- OpenCV
- 보석들
- 코딩 테스트
- 인사과
- Computer Vision
- 직무의사유화
- 개인성향
- 김창준
- Documentation
- 맥
- Agile
- 인사
- 엔지니어
- Today
- Total
목록엔지니어 (3)
세상을 놀라게 하자!
서로 다른 욕구 대부분의 경우 개발자들은 사람과 상호 작용을 다루는 일에 서투릅니다. 경영진은 사람과 친숙치 않은 사람과 일을 함께 하는데 서툽니다. 개발자들은 경영진이 쉽게 일을 생각한다 느끼고 경영진은 개발자들이 일을 성실하게 하지 않는다고 느낍니다. 그런데 정말 그것이 사실일까요? 왜 경영진은 개발팀이 보기에 촉박한 일정을 제시할까요? 경영진의 ‘욕구’를 생각해봅시다. 일반적인 경영에서는 제품의 출시로 매출이 나오면 성공이라 생각하지요. 그래서 빠르게 개발이 되어서 시장의 반응을 알고 싶어합니다. 또는 개발 기간 = 임금 비용이기 때문입니다. 즉 경영진에게 가치가 있는 일이란 가능한 적은 비용은 적게 들이고 빨리 시장에 물건을 내놓아 매출을 만드는 것입니다. 그리고 의외로 많은 시간을 고민고민해서 ..
과연 개발자의 업무 평가를 제대로 하는 것이 가능할 것인가라는 주제는 논의가 많습니다. 그럼 반대로 '개발자의 업무평가를 하지 않는 것은 가능할까'라는 질문을 해보면 어떨까요? 아마도 초조해 하시는 분들은 관리자들일 확률이 클겁니다. 인사고과도 매겨야 되는데 어떻게 하란 말인가라고 말이죠. 반면에 일반 개발자들은 그냥 평범할 수도 있을 겁니다. 대부분 그런 것과 상관 없이 일해왔을 확률이 크기 때문입니다. 어떤 조직은 '일정 준수'에 대해 책임을 묻겠다는 조직이 있긴 합니다만, 하나 궁금한 것이 있습니다. 그 일정 엔지니어들이 잡은 것인가요? 책임을 진다는 것은 그 의사 결정에 참여해야 의미가 있습니다. 만약에 엔지니어가 잡지 않은 일정에 대해 책임을 지라 하고 고과를 매기겠다면 이것은 남이 변을 보다 ..
최근 제가 속한 Group의 사람이 자신의 건강이 매우 나빠지고 있고 계속 공학일을 해야 하는지 상담을 하려 하는 글을 올렸습니다. 개인적으로 이것이 남의 모습이 아니라 나의 모습이라고 하는 생각이 들었습니다. 뇌 해마조직의 이상이라는 것이 그리 쉽게 오는 것이 아닌데 과다한 스트레스를 받아가며 연구에 집중하는 것 때문에 생기는 일이라며 의사는 그에게 휴식을 권하고 있습니다. 일반적으로 직무에 의해 스트레스 혹은 일을 계속 할 수 없는 상태가 된다면 이것을 방지하기 위해 직장이 어떤 조치를 취했는지를 확인해야 합니다. 결국 회사 일로 그리 된 것이니 한 사람이 희생 되었다면 다음 희생자를 막아야 하기 때문이지요. 하지만 노동법이 아무리 규제하고 있어도 정작 사업주 혹은 연구 일정의 촉박함은 생명의 단축을..