애플리케이션 / 오피스ㆍ협업

회사가 개발자를 고문하는 16가지 방법

Andrew C. Oliver  | InfoWorld 2013.04.08

 
11. 가짜-스크럼 일일 회의
최악의 죄인들을 위해 마련된 특별한 지옥이 있다. 바로 관리 상황 업데이트를 위한 일일 스크럼(scrum) 회의다. 이 회의는 중요한 개발 사항을 전달하는 자리가 아니다. 경영진에게 그들이 일을 하느라 매우 바쁘고 그래서 계속 회사에 붙어 있어야 한다는 점을 납득시키기 위해 최소 5~6분씩 이야기하는 자리다.  이 회의는 보통 12명 이상이 참석하는데 사실 그들 대부분 그 자리에 있을 필요가 없다. 30분에서 45분, 혹은 그 이상 회의가 진행되는데 (실제 스크럼 회의는 5~6분 정도면 끝난다), 말하지 않는 참석자들은 다들 정신이 나가 있기 마련이다.
 
더 최악은 모두가 작업간 전환(context switching)이 있을 것임을 알기 때문에 이런 회의 전에 일을 하지 않는다는 점이다. 회의 후 점심식사도 또 한 시간은 걸리는데 당장 열심히 일할 필요가 없기 때문이다. 기본적으로 이런 회의는 팀의 오전 전체를 잡아먹고 사기를 저하시키며 아무런 결론도 나지 않는다. 뭔가 빠르게 실행하는 법을 익히던가 아니면 회의를 취소하라.
 
12. 형식주의
형식주의는 양복을 차려 입는 것에 그치지 않고 생각지도 못한 방식으로 드러난다. 역설적으로 평상시 환경이 격식 수준을 설정하기 더 까다로워 더 어렵지만, 개발자들은 양복 입는 환경에 대해 오랫동안 강하게 저항해왔다.
 
필자가 J보스(Jboss)에서 일할 때 세 명의 개발 이사들이 차례로 필자에게 양복 셔츠와 바지 조합을 입지 말고 차라리 마트에서 괜찮은 옷을 사라고 돈을 주겠다고 했었는데, 그들의 제안은 진심이었다. 그들은 만약 J보스(구멍 난 샌달 군단)가 양복을 차려 입고 나타나면, 경영진이 점차 개발자들에게 정장을 다시 강요할 것이라는 걱정을 하고 있었던 것이다.
 
이 캐주얼 환경은 사실 인위적인 구조다. 최근 필자는 “이게 우리가 욕을 더 이상 못한다는 의미인가요?”라고 즉각 되물었던 인사 관리자를 채용하면서 기준을 정하려고 했었다. 그 때 필자가 생각했던 기준은 이거였다. “아니 욕은 좋아. 언제 어디서나 이유가 있건 없건 매일 욕을 달고 사니까. 단, 고객만 옆에 없다면 말이야”
 
사람들이 (가령 더러운 농담을) 이야기하는 방식과 사람들이 생각하는 방식 (“가장 기술적으로 타당한”) 사이에는 캐주얼한 환경과 형식적인 환경 사이의 차이가 있다. 이러한 차이는 더 많은 규칙을 요구하는 더 큰 환경 때문에 발생하기도 하고 혹은 사람들이 절차, 발언, 복장 등에 있어서 격식과 과도한 '형식주의'를 너무 좋아해서 나타나기도 한다. 개발자들에게 형식주의를 위해 모든 것을 틀에 맞추라고 하는 것은 그들의 정신과 생각에 대한 학대다.
 
13. 인질 사태로의 경영
부하 테스트가 실패하면 경영진은 근본 원인과 그 해결방안을 듣고 싶어할 것이다. 그들은 이미 구축된 것을 걷어낼 수 있다고 위협하기도 하는데 이는 개발 절차를 망치는 완벽한 길이다. 경영진이 너무 세세하게 관리하고 동시에 과도하게 권위를 주장하는 것은 프로젝트 테스트의 일반적인 반복 과정에 방해만 될 뿐 아니라 개발자들이 무언가를 시도하거나 의도치 않은 주의를 끄는 것을 기피하게 만든다.
 
연관된 기능성을 이해하지 않은 채 과감하고 즉각적인 파괴행동으로 개발자를 위협하는 것은 기껏해야 급조된 제품을 양산하는 결과로 이어질 뿐이다. 프로젝트가 공황상태에 빠진 고객이나 경영자에게 휘둘리도록 하는 것은, 그 상황이 개발자들의 통제를 벗어난다 하더라도 설사 미리 경고를 했더라도 그 결과에 책임을 지게 되도록 만든다. 목표와 데드라인 가이드는 프로젝트를 완료하기 위해 존재하는 것인데 흔들리는 회오리바람은 이를 파괴시킨다.
 
14. 우리는 이 부근을 묻는다
의심스러운 기기가 제한된 포트를 통해 스카이프(Skype)에 접속하려는 시도를 발견한 개발자가 있다고 가정하자. 그는 이것이 규칙에 위반되는지 모르고 있다. 그는 가이드라인에 대해 문의했지만 어떤 세부 지침도 제공되지 않았다. 축하한다. 당신의 회사는 방금 모호하고 사전 공지 되지 않았거나, 문서화 되지 않은 제약을 지키지 않았다며 개발자를 처벌했다. 이 사건으로 인해 그가 회사를 나갈 가장 빠른 길을 찾는다고 해서 놀라지 말기 바란다.
 
15. 세부사항이라고, 세부사항
잘난 체 하는 상사: “고객이 수정을 문의했는데 그걸 시간 안에 추가할 수 있나?”
코더: “아니오. 중대한 아키텍처 수정이 필요합니다. 우리는 시작하기 전에도 물어봤고 그런 류의 확장을 가능케 하는데 시간을 쓰지 말라는 이야기를 들었습니다”
 
요구조건들이 애초부터 정해지는 일은 드물다. 그러나 앞서 경우처럼 있음직한 변화를 고려하지 않고 최단 경로를 택하도록 개발자들을 압박하는 것은 훗날 그 요구가 제기됐을 때 개발자들을 곤란한 상황에 처하게 만든다.
 
16. 그냥 어떻게 작동하는지 말해
몇몇 관리자들은 원인에 대한 가설을 제기하기를 거부하고 적절한 조사도 없이 문제에 대한 즉각적인 솔루션만을 요구한다. 보통 “당신 전문가 아닌가? 이걸 그냥 설명하거나 해결할 순 없나?”라는 식의 언어적 공격과 같이 오기도 한다. 그러나 솔루션을 찾기 위해서는 그 원인을 조사하고 가설을 설정하고 테스트해야 한다. 우리는 결코 결론으로 앞서갈 수가 없다. 문제 해결 방법은 추측과 확인 이후에 오는 것이다. editor@idg.co.kr
Sponsored

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.