"개발자에게 이렇게 대할 경우 개발에 도움 안된다" 라는 주제로 몇가지 경우를 정리해봤습니다. 몇몇 항목은 개발자 뿐만 아니라 직원 또는 부하직원에게 해선 안될 불필요한 경우들입니다. 오늘 문득 이런 상황들을 정리해 봐야 겠다는 생각에 간추려 본 것으로 추후 편집 될 수 있습니다.
1. 수정사항이나 개선사항을 버그라고 표현하는 경우.
버그를 버그라고 이야기해도 개발자 입장에서는 썩 기분 좋은 일이 아닌데 수정사항이나 개선사항 조차도 버그라고 이야기 하면 개발자와 거리를 두는 격이 될 것입니다.
2. 그동안 시켜온 많은 업무 지시 사항들은 잊고 뭘 했는 지 묻는 경우.
지시 사항이나 기획에 의해서 일을 하고 있을 텐데 그 동안 무슨 일 해냐고 묻는 것은 개발자의 기분도 상하게 할 뿐만 아니라 지시자에 대한 신뢰도 무너지게 될 것입니다.
3. 조직 내에 존재하지 않거나 현재 존재하지 않는 인물에 빗대어 의견을 묻는 경우
내가 아는 사람이 말하길 이건 한 5일이면 개발한다던데 당신은 얼마나 걸릴 것 같습니까?
전에 일하던 개발자가 이렇게 말하던데 당신은 왜 이렇게 이야기 합니까?
어떤 일을 하거나 어떤 관계에 있더라도 타인과 비교해서 나를 평가절하 한다면 기분 나쁜 것은 당연합니다. 조직 내에 존재하지 않은 사람이 내린 판단은 조직 내의 시시콜콜한 사정을 알지 못하고 내린 결론일 것이므로 도움이 되지 않는 것이며 이런 말로 인해 개발자는 자신의 기술과 인격을 신뢰하지 않는다고 판단할 것입니다.
4. 회사의 부정적인 경영 상황을 이야기 해서 일 할 의욕을 떨어뜨리는 경우
회사의 비전을 이야기 해서 의욕을 가지고 일하게 하는 것이 일반적이지만 회사 상황에 대해 부정적인 말을 하는 경우 개발자는 개발 의욕이 떨어지게 될 것이고 이직을 고민하게 될 것입니다. 어찌보면 계속 근무를 해야 할지 이직을 해야 할지 정확하게 판단할 수 있도록 도움을 주는 고마운 말일 수 있겠습니다.
5. 열심히 일했거나 성과가 높을 때 그만한 혜택은 없고 더 많은 업무를 지시하는 경우
능력 발휘를 잘 하는 사람이나 근무시간 이외 시간을 투자해서 일하는 사람에게 업무를 중과하는 것과 이에 대한 보상 시스템이 없는 경우 점진적으로 업무의 하향 평준화가 될 것입니다.
6. 개발 공간을 별도로 분리하지 않고 타 부서와 근접한 곳에서 개발 업무를 하게 할 경우
개발 공간이 손님 또는 고객들이 드나들고 전화 업무가 많은 부서들과 함께 하는 곳일 경우 개발자의 집중력과 개발의 연속성을 떨어뜨릴 것입니다.
7. 지나치게 많은 회의를 하고 속사포 처럼 수시로 업무 지시를 하는 경우
이럴 경우는 체계적으로 일을 처리하는 곳에서는 일어날 수 없는 상황입니다. 또한 회의가 많으면 수시로 업무를 지시하면 그 만큼 개발 기간 대비 개발 시간을 줄이는 것이고 결국 개발자는 실제 개발 시간이 아닌 개발 기간 대비해서 나온 성과에 대한 책을 져야 할 것입니다.
8. 기획의 완성도가 부족한 상태에서 개발 업무를 추진하는 경우
되도록이면 기획의 완성도를 높여서 업무를 추진해야 하는 것이 상식입니다. 기획의 완성도가 떨어지면 어째꺼나 개발을 해야 하므로 개발자가 부족한 기획을 체워야 하므로 기획을 하게 만드는 꼴이 됩니다. 개발자가 보완한 기획이 잘되면 문제가 없겠지만 잘못되면 개발자 마음대로 만들었다는 질책을 받을 수 있고 역할 분담으로 인해 나올 수 있는 효율과 체계는 사라지게 될 것입니다.
9. 개발자의 본래 해야할 일과 동떨어진 업무도 병행해서 일하게 할 경우
조직의 규모가 클 경우 분업화가 잘 되서 이런 일이 없겠지만 중소규모의 조직에서는 개발자가 다른 업무도 하는 경우가 많습니다. 심지어 개발과 상관관계가 없는 서비스 업무를 하게 되는 경우도 있습니다. 이런 경우 개발의 효율은 당연히 떨어지고 추가로 배당 받은 업무에 대한 책임도 저야 하니 개발자가 오래 버틸 수 있는 근무 환경이 아닙니다.
10. 개발자와 회의 없이 결정된 사항을 예고도 없이 급작스럽게 지시하는 경우
일의 순서를 무시하고 진행된 일은 문제가 생기게 마련입니다. 개발자를 당황하게 만들면 일도 제대로 진행되지 않을 뿐더러 이런 상황이 반복되면 개발자는 이직을 고려하게 될 것입니다.
웹프로그래머의 홈페이지 정보 블로그 http://hompy.info
(0) 
(0)
1. 수정사항이나 개선사항을 버그라고 표현하는 경우.
버그를 버그라고 이야기해도 개발자 입장에서는 썩 기분 좋은 일이 아닌데 수정사항이나 개선사항 조차도 버그라고 이야기 하면 개발자와 거리를 두는 격이 될 것입니다.
2. 그동안 시켜온 많은 업무 지시 사항들은 잊고 뭘 했는 지 묻는 경우.
지시 사항이나 기획에 의해서 일을 하고 있을 텐데 그 동안 무슨 일 해냐고 묻는 것은 개발자의 기분도 상하게 할 뿐만 아니라 지시자에 대한 신뢰도 무너지게 될 것입니다.
3. 조직 내에 존재하지 않거나 현재 존재하지 않는 인물에 빗대어 의견을 묻는 경우
내가 아는 사람이 말하길 이건 한 5일이면 개발한다던데 당신은 얼마나 걸릴 것 같습니까?
전에 일하던 개발자가 이렇게 말하던데 당신은 왜 이렇게 이야기 합니까?
어떤 일을 하거나 어떤 관계에 있더라도 타인과 비교해서 나를 평가절하 한다면 기분 나쁜 것은 당연합니다. 조직 내에 존재하지 않은 사람이 내린 판단은 조직 내의 시시콜콜한 사정을 알지 못하고 내린 결론일 것이므로 도움이 되지 않는 것이며 이런 말로 인해 개발자는 자신의 기술과 인격을 신뢰하지 않는다고 판단할 것입니다.
4. 회사의 부정적인 경영 상황을 이야기 해서 일 할 의욕을 떨어뜨리는 경우
회사의 비전을 이야기 해서 의욕을 가지고 일하게 하는 것이 일반적이지만 회사 상황에 대해 부정적인 말을 하는 경우 개발자는 개발 의욕이 떨어지게 될 것이고 이직을 고민하게 될 것입니다. 어찌보면 계속 근무를 해야 할지 이직을 해야 할지 정확하게 판단할 수 있도록 도움을 주는 고마운 말일 수 있겠습니다.
5. 열심히 일했거나 성과가 높을 때 그만한 혜택은 없고 더 많은 업무를 지시하는 경우
능력 발휘를 잘 하는 사람이나 근무시간 이외 시간을 투자해서 일하는 사람에게 업무를 중과하는 것과 이에 대한 보상 시스템이 없는 경우 점진적으로 업무의 하향 평준화가 될 것입니다.
6. 개발 공간을 별도로 분리하지 않고 타 부서와 근접한 곳에서 개발 업무를 하게 할 경우
개발 공간이 손님 또는 고객들이 드나들고 전화 업무가 많은 부서들과 함께 하는 곳일 경우 개발자의 집중력과 개발의 연속성을 떨어뜨릴 것입니다.
7. 지나치게 많은 회의를 하고 속사포 처럼 수시로 업무 지시를 하는 경우
이럴 경우는 체계적으로 일을 처리하는 곳에서는 일어날 수 없는 상황입니다. 또한 회의가 많으면 수시로 업무를 지시하면 그 만큼 개발 기간 대비 개발 시간을 줄이는 것이고 결국 개발자는 실제 개발 시간이 아닌 개발 기간 대비해서 나온 성과에 대한 책을 져야 할 것입니다.
8. 기획의 완성도가 부족한 상태에서 개발 업무를 추진하는 경우
되도록이면 기획의 완성도를 높여서 업무를 추진해야 하는 것이 상식입니다. 기획의 완성도가 떨어지면 어째꺼나 개발을 해야 하므로 개발자가 부족한 기획을 체워야 하므로 기획을 하게 만드는 꼴이 됩니다. 개발자가 보완한 기획이 잘되면 문제가 없겠지만 잘못되면 개발자 마음대로 만들었다는 질책을 받을 수 있고 역할 분담으로 인해 나올 수 있는 효율과 체계는 사라지게 될 것입니다.
9. 개발자의 본래 해야할 일과 동떨어진 업무도 병행해서 일하게 할 경우
조직의 규모가 클 경우 분업화가 잘 되서 이런 일이 없겠지만 중소규모의 조직에서는 개발자가 다른 업무도 하는 경우가 많습니다. 심지어 개발과 상관관계가 없는 서비스 업무를 하게 되는 경우도 있습니다. 이런 경우 개발의 효율은 당연히 떨어지고 추가로 배당 받은 업무에 대한 책임도 저야 하니 개발자가 오래 버틸 수 있는 근무 환경이 아닙니다.
10. 개발자와 회의 없이 결정된 사항을 예고도 없이 급작스럽게 지시하는 경우
일의 순서를 무시하고 진행된 일은 문제가 생기게 마련입니다. 개발자를 당황하게 만들면 일도 제대로 진행되지 않을 뿐더러 이런 상황이 반복되면 개발자는 이직을 고려하게 될 것입니다.
웹프로그래머의 홈페이지 정보 블로그 http://hompy.info
(0) (0)