앱 및 웹사이트를 개발하는 소규모 인도 소프트웨어 회사의 기술적 부채 증가: 누가 책임지고 있습니까?

저는 인도 소프트웨어 서비스 업계에서 10년 동안 일해 왔으며 그 동안 좋은 프로젝트가 완료되고 놀라운 일을 하는 것을 보았습니다. 저는 스켈레탈 팀이 지구 반대편의 사람들에게 사랑받는 제품을 만들기 위해 고통스러운 조건에서 지칠 줄 모르고 일하는 것을 보았습니다. 그리고 지난 10년 동안 몇 가지 놀라운 프로젝트를 진행하면서 좋은 추억을 쌓았지만, 여러 가지 이유로 인해 프로젝트가 내리막길을 걷고 소프트웨어 제품이 모두 엉망이 되는 것도 목격했습니다. 내 주변과 내가 10년 동안 알고 지낸 사람들 주변에서 바라던 것보다 더 많은 시간이 발생했습니다.

프로젝트가 잘못되고 있다는 이야기가 많이 나왔습니다. 전체 계층 구조가 정글의 먹이 사슬처럼 서로를 쫓는 방법에 대한 밈이 인터넷에 떠돌고 있습니다. 어떤 사람들은 버그가 있는 코드를 작성했다고 프로그래머를 비난하고, 다른 사람들은 이행 불가능한 비현실적인 약속을 한 경영진을 비난합니다. 어떤 사람들은 이 산업의 기술적 전제 조건과 종속성을 이해하지 못하는 고객을 비난하기도 합니다. 그러나 나는 기술 부채 또는 코드 부채에 대해 이야기하는 사람이 거의 없으며 서로 손가락질하지 않고 문명화된 방식으로 이 문제를 처리하는 것을 들어본 적이 없습니다. 내 주변 사람들, 내가 참석한 이벤트 또는 내가 읽은 지역 블로그에서 이 기술 부채라는 용어를 본 적이 한 번도 없습니다.

저는 미국 실리콘 밸리에서 블로그와 저널을 읽을 때만 이 용어를 접했습니다. 이것은 인도의 중소 소프트웨어 개발 회사에서 일하는 대부분의 프로그래머와 소프트웨어 경영진이 지금까지 이 용어를 들어본 적이 없다는 것을 의미합니다. 그럼 용어 자체를 설명하는 것으로 시작하겠습니다. 기술 부채 또는 코드 부채는 시간이 더 오래 걸리는 더 나은 접근 방식을 사용하는 대신 지금 쉬운(제한된) 솔루션을 선택함으로써 발생하는 추가 재작업의 내재된 비용을 반영하는 소프트웨어 개발의 개념입니다.

간단하게 하기위해 정리해보겠습니다. 가장 효율적이고 최적의 빌드 방법을 선택하는 것이 아니라 특정 모듈 또는 전체 시스템을 빌드하는 쉬운 옵션을 선택하여 상승했을 수 있는 프로그래밍 및 설계 문제를 해결하는 데 드는 비용을 계산하는 개념입니다. 소프트웨어 개발 분야에서, 당신의 게으름과 지각이 당신을 깨물기 위해 되돌아오는 이러한 현상은 다른 곳보다 훨씬 더 자주 발생합니다. 마치 카르마가 프로그래머들에 의해 사회적인 표현을 받은 것과 같습니다.

제발, 저를 오해하지 마십시오. 저는 모든 코드 빚을 프로그래머에게 돌리는 것이 아닙니다. 인도의 소규모 소프트웨어 개발 회사 프로젝트의 90% 이상에서 확실히 발생하는 코드 부채에 책임이 있는 여러 주체가 있습니다. 그 중 몇 가지를 간략하게 살펴보겠습니다.

1. 참을성 없고 지나치게 똑똑한 고객

네, 무자비하게 먹이를 주는 바로 그 손을 물어뜯는 것부터 시작하겠습니다. 소규모 아웃소싱 소프트웨어 개발 프로젝트 시장은 거대하고 고도로 세분화되어 있습니다. 이 세계화된 시장을 완벽하게 정당화하는 진정으로 좋은 회사가 있는 반면, 다른 사람들은 규제되지 않고 통제되지 않는다는 이유만으로 이 완벽하게 좋은 배열을 먹여살리는 기생충 회사일 뿐입니다.

이것은 고객이 필요에 따라 파트너가 될 올바른 회사를 선택하는 데 실수를 하도록 이끕니다. 제대로 된 심사 능력이 없는 것이 그들의 잘못은 아니지만, 쓰레기 회사와 진짜 쓰레기 회사를 구별하는 기본적인 거리 영리함이 없는 그들을 탓할 사람은 아무도 없다. 이제 재능이 부족한 팀과 함께 진행하기로 동의하면 비현실적인 기대와 일정에 목이 메입니다. 뿐만 아니라 그들 중 일부는 디자인과 프로그래밍에 대한 자신의 제안을 가져옴으로써 자신이 얼마나 똑똑한지 보여주기까지 합니다. (#notallclients )

당신이 소프트웨어 개발 회사의 고객이라면, 그들이 일을 하도록 내버려 두시기를 겸손하게 요청합니다. 의사나 변호사에게 가서 당신이 구글링한 내용과 그것이 당신의 문제에 대해 말한 것을 말하고 그들의 얼굴에 나타난 반응을 보십시오. 자기 분야의 전문가는 멍청한 놈이 자기 분야에 대해 조언하는 것을 좋아하지 않습니다. 소프트웨어 엔지니어도 예외는 아닙니다.

좋은 소프트웨어 개발 팀을 찾았고 그들이 유망해 보인다면 그들에게 공간을 제공하면 프로젝트에서 코드 부채를 줄이는 결과를 초래할 모서리를 자르고 싶은 충동을 느끼지 않을 것입니다. 그리고 대부분의 경우 그 코드 부채를 지불하는 고객이 무엇인지 생각해보십시오. "변경 요청"이라는 말을 들어본 적이 있습니까? 나는 당신의 대부분이 내기! 이상적인 시나리오에서, 당신은 당신의 삶에서 그런 말을 들어서는 안 됩니다. 그러나 그런 일은 거의 일어나지 않습니다. 그리고 그 말을 가장 많이 들을수록 당신은 소프트웨어 회사의 고객이 되는 것에 더 많이 망쳤습니다.

2. 게으르고 사악한 관리자

여기서 관리자라고 하면 소프트웨어 개발 회사 측에서 프로젝트 관리 위치에 있는 사람입니다. 프로젝트 관리자든, 팀장이든, 배달 팀장이든, 회사 소유주이든, 프로젝트를 마무리하고 지불금을 받기 위해 빨리 손을 씻으려 한 적이 있다면 당신은 당사자입니다. 당신의 프로젝트에 있는 이 막대한 기술 부채에 대해서도 책임을 져야 합니다.

여기서 가장 슬픈 부분은 여러분이 막대한 기술 부채를 지불하지 않는다는 것입니다. 고객이 표준 이하의 제품을 사용하여 비용을 지불하거나 실제로 더 많은 비용을 지불하여 청소합니다. 그리고 클라이언트가 아닌 경우에는 필요한 것보다 훨씬 많은 시간을 일해야 하므로 가난한 프로그래머가 비용을 지불해야 합니다. 그러나 이러한 중간 사람은 거의 없으므로 제 말에 따르면 그들은 이 기술 부채 주제에서 가장 책임 있는 주체가 되어야 합니다.

당신이 그들 중 한 명을 고용한다면 그들이 가져야 할 가장 큰 자질은 도덕성입니다. 그들의 도덕적 나침반이 올바른 방향을 가리키고 있다면 책임을 지고 프로젝트에 유리한 올바른 결정을 내릴 것입니다. 그러면 결국 기술 부채가 줄어들 것입니다. 이것은 Jack Ma가 올바른 리더를 위해 일하는 것을 선택하는 것에 대해 말한 유명한 인용문을 생각나게 합니다. 이 시나리오에 매우 적합합니다.

3. 프로그래머

그래, 나도 너희들을 비난하는 것으로 이 주제를 끝내지 않겠어! 하지만 이봐, #notall프로그래머 맞지? 네, 하지만 프로그래머의 거의 94%가 그렇습니다. Tech Mahindra의 CEO인 CP Gurani는 2년 전 IT 졸업생의 94%가 해당 직무에 적합하지 않다는 충격적인 폭로를 발표했을 때 생각했습니다. 그가 그 숫자에 어떻게 도달했는지 정확히 알지 못하지만 인도 공대 출신이고 지난 10년 동안 전체 IT 공학 생태계를 목격했기 때문에 나는 Gurani 씨의 말에 동의하는 경향이 있다고 말할 수 있습니다.

나는 그것이 94%인지 90%인지 80%인지 논쟁하려는 것이 아닙니다. 그러나 비유를 하자면, 반죽을 만들기 위해서는 밀가루, 물, 소금 한 꼬집이 필요하고 샤파티를 만들기 위해서는 밀대를 사용해야 한다는 사실을 우리 모두가 알고 있는 것과 같습니다. 그러나 우리 중 실제로 식용 차파티를 만들 수 있는 사람은 거의 없습니다. 그것은 죽은 간단한 과정이지만 여전히 그것을 능가하기 위해서는 약간의 재능과 많은 연습이 필요합니다. 프로그래밍의 경우도 마찬가지입니다. 우리 모두는 조리법을 알고 있지만 실제로 그 기술을 마스터하는 데 걸리는 한 소매를 걷어붙이고 손을 더럽히고 연습한 사람은 거의 없습니다.

따라서 평범한 프로그래머가 프로젝트를 맡는 경우에도 그는 나중에야 깨닫지 못할 기술 부채가 포함된 코드를 자신도 모르게 작성하게 됩니다. 그리고 대부분의 프로그래머가 해당 직무에 적합하지 않은 상황에서 업계가 전반적으로 어떻게 긍정적으로 작동하는지 궁금하다면, 그것은 그들의 효율적인 관리자와 어려운 방식으로 배운 경험 많은 선배들 때문입니다. 그들은 최적의 코드를 작성하는 위험한 경로를 탐색하는 신선한 손과 마음을 돕고 프로젝트의 선적을 실현 가능하게 만들고 부담스러운 부채에서 벗어나도록 합니다. 그리고 결국 적절한 그루밍과 훈련을 통해 신입사원들이 자신의 일을 잘하게 하거나 IT 업계를 포기하게 됩니다.

따라서 결론적으로 저는 이 협업의 모든 주요 당사자가 코드 부채를 컴파일하는 책임을 공유해야 한다고 생각합니다. 다시 말하지만, 이 기사를 업계에 잘못된 모든 것에 대한 테이크다운 기사로 받아들이지 마십시오. 공포와 영웅의 공평한 몫을 가진 세계의 다른 산업과 같습니다. 이 일을 한 지 10년이 지난 후에도 나는 여전히 내 인생에서 다른 일을 하지 않을 것입니다. 저는 이 직업을 사랑하고 전 세계 고객의 흥미진진한 프로젝트를 진행하는 작은 회사가 되는 것을 좋아합니다.

목적은 3명의 이해 관계자 모두가 더 책임감을 갖게 하고 잘못된 협업으로 인해 그들에게 타격을 입히고 있는 이 근본적인 소프트 손실을 알게 하는 것이었습니다. 소프트웨어 개발 팀이 기술 부채를 정확하게 계산하고 측정하려면 Agile 방법론 또는 Waterfall 방법론을 기반으로 하는 엄격한 프로세스 모델을 따를 수 있습니다. 이러한 훈련된 접근 방식을 따르면 해당 개정 및 수리 스프린트를 개별적으로 표시할 수 있으며 단계가 끝나면 얼마나 많은 스프린트가 필요한지 정확하게 계산할 수 있으며 쉽게 도달할 수 있습니다. 그 이유.

사무엘 베켓의 다음과 같은 결론적인 인용문으로 이 글을 마치겠습니다.