효과적인 소프트웨어 생산을 위한 8가지 규칙

경력을 쌓는 동안 여러 실제 소프트웨어 프로젝트에 참여했으며 의사 결정, 채택 관행, 팀 구축, 채용, 기술 배포 등 모든 수준에서 작업이 수행되는 방식을 관찰했습니다. 분명히 다른 접근 방식은 다른 결과를 낳았습니다. . 개선 지향적인 유형의 사람이기 때문에 업무에 도움이 되는 가장 효과적인 방법과 가장 실용적인 트릭을 발견하고 수집했습니다.

관찰을 통해 배우는 것은 어렵고 긴 방법입니다. 나는 대신 책에서 이 지식을 더 일찍 선택하게 되어 매우 기쁩니다. 불행히도, 나는 주제에 대해 아무것도 찾지 못했습니다. 그래서 나는 이런 종류의 지식을 구하는 다른 사람들과 내 경험을 공유하기로 결정했습니다. 바라건대, 몇 년 동안의 개인 연구를 절약할 수 있습니다.

이 기사에서는 유지 관리가 5-10배 적은 견고하고 안정적인 소프트웨어 제품을 생산하여 평균적인 산업 성과를 능가하는 방법을 배웁니다. 지난 10-15년 동안 나는(개인적으로는 물론 내 팀도) 모든 기대치를 초과했고 성공의 흔적을 남겼다고 거짓 겸손 없이 말할 수 있습니다. 관리자는 더 행복할 수 없습니다.

일단 우리 팀이 불가능할 정도로 짧은 시간 안에 중요한 프로젝트를 진행했고, 그 결과 우리는 고위 경영진으로부터 "고성과 팀" 상을 받았습니다. 이 모든 것이 밤과 주말을 지치지 않고 지치게 합니다. 그냥 정상적인 작업입니다.

효과적인 소프트웨어 생산 지식 자체가 힘입니다. 사실 평범한 말로 설명해도 많은 사람이 이해할 수 없는 일종의 흑마법이다. 무료로 받으실 수 있습니다. 소프트웨어 생산 마술사로 인식되고 싶다면 계속 읽으십시오.

이것은 누구를 위한 것입니까?

여기서 중요하고 중요한 면책조항을 하겠습니다.

생산성 향상이 필요한 사람들에게 이 문제를 설명합니다. 삶의 모든 것이 생산성에 관한 것은 아닙니다. 모든 소프트웨어 프로젝트도 아닙니다. 실적으로 평가받지 못하는 경우가 있습니다. 분명히, 이러한 관행은 도움이 되지 않을 것입니다.

이러한 기술은 팀 리더, 설계자 및 프로젝트 관리자에게 가장 유용하지만 선임 소프트웨어 개발자도 이점을 얻을 수 있습니다.

규칙 1: IT 사고방식 이해

IT 산업은 과학, 기술, 예술 및 비즈니스가 혼합된 산업입니다. 충분한 수준에서 이러한 측면을 이해하지 않고는 그곳을 탐색하기가 매우 어렵습니다. 가장 큰 문제는 산업 자체가 상당히 복잡하다는 것입니다. 따라서 모범 사례도 복잡합니다. 성공하려면 많이 연습하고 많이 배우고 지식을 검증해야 합니다.

놀라운 기술 업데이트 속도는 그것을 두 배로 어렵게 만듭니다. 10년 전에 배운 것은 더 이상 필요하지 않습니다. 따라서 빠른 속도로 배워야 합니다.

이상을 종합하면 IT 분야에서 성공하는 것은 타고난 능력이나 감정이 아니라 어려운 실천적 사례라고 할 수 있습니다. 절대 "직관을 따르거나" 자신을 포함하여 느낌에만 의존하지 마십시오.

그렇다면 그 아이디어는 고려해 볼 가치가 있습니다. 그렇지 않으면 이 경로를 선택하여 팀의 삶을 개선하는 방법에 대한 매우 훌륭하고 상세한 설명을 요구하십시오. 이 테스트를 통과하면 환경에 적합함을 실험적으로 증명하는 간단한 개념 증명 프로젝트를 예약하십시오.

여기에서 이해해야 할 중요한 것은 소프트웨어 문제를 해결하는 방법이 많기 때문에 옳고 그른 해결책이 없다는 것입니다. 그러나 솔루션에 대한 좋은 이해와 나쁜 이해가 있습니다.

어떤 사람이 아이디어를 세부적으로 명확하게 표현하거나 이 솔루션을 채택하여 팀의 성공과 연결되어 다른 팀원을 설득할 수 있다면 우리는 이 사람의 비전에 의존할 수 있으며 성공 가능성이 높습니다.

규칙 2: 소프트웨어 생산과 소프트웨어 개발 방법론을 혼합하지 마십시오

소프트웨어 생산은 소프트웨어 개발을 기반으로 합니다. 그러나 이 둘은 완전히 다른 목표, 사고 방식 및 관행을 가지고 있습니다. 이러한 영역 중 하나의 문제를 다른 영역의 방법으로 해결하려고 하면 우스꽝스러운 결과가 나옵니다. 차이점을 이해하고 이러한 세계 각각에 적절한 방법을 사용하는 것이 중요합니다.

소프트웨어 개발은 ​​예술과 공예의 결합입니다. 아트 구성 요소는 자동화 도구 및 소프트웨어 개발 방법론에 관계없이 항상 존재합니다. 따라서 개발 작업을 해결하려면 최대 집중과 다른 모든 주의를 산만하게 하는 신호로부터 보호해야 합니다.

숙련된 개발자에게 동기를 부여하는 가장 좋은 방법은 모든 인적 요소를 제외하고 순수한 기술 형식으로 작업을 제시하는 것입니다. 모든 요구 사항은 기술 언어로도 표현되어야 합니다. 단독 연구 단계에서 목표를 향해 탐색할 수 있도록 쉽게 검증할 수 있어야 합니다.

이와 대조적으로 소프트웨어 생산은 비즈니스 관리 영역에 더 가깝습니다. 한 쪽에서는 고객이 필요로 하는 것이 무엇인지 알고 있고 다른 쪽에서는 어떤 팀 리소스를 사용할 수 있는지 알고 있습니다. 따라서 이제 목표를 달성하기 위해 팀의 노력을 지시하려고 합니다. 한편, 진행 속도를 예측하고 상사에게 잘 알려진 계획을 제시할 수도 있습니다. 고객의 희망 사항을 이해하고, 팀의 강점을 이해하고, 공식적인 계획과 일정을 전달하는 데 중요한 기술입니다.

즉, 소프트웨어 개발의 많은 역할이 팀 리더, 설계자, 분석가 및 프로젝트 관리자와 같이 비즈니스와 기술 간의 다리를 구축하는 두 가지 세계에서 모두 작동하고 있다는 점을 강조하고 싶습니다. 이러한 역할을 하는 사람들은 현실의 두 평면 사이를 쉽게 걸을 수 있어야 하며 비즈니스에 대해 이야기할 때와 예술을 할 때를 이해할 수 있어야 합니다.

규칙 3: 영구 저장소를 인간 기억의 확장으로 사용

인간의 기억력은 용량면에서 놀랍지만 한계가 있습니다. 당신은 예측할 수 없는 정확성과 지속 시간으로 사물을 기억하고, 잊어버리면 마음대로 기억할 방법이 없습니다.

이것이 우리가 예측 가능한 속도로 이동하기 위해 영구 메모리 저장소를 사용하는 이유입니다. 이것은 사실 이후에 만들고 다른 사람들이 사용할 수 있도록 사용자 설명서와 같은 형식적인 문서에 관한 것이 아닙니다. 이것은 소프트웨어 개발 프로세스를 진행하는 데 도움이되는 작업 중에 문서를 말 그대로 메모리의 외부 확장으로 사용하는 것입니다.

사소하지 않은 작업이나 여러 사람이 관련된 작업에 직면할 때마다 생각과 계획을 문서화하는 것이 좋습니다. 최대한 저렴하게 해보세요. 회사 로고가 있는 공식 문서를 작성하지 마십시오. 좋은 도구는 프로젝트 공간이 있는 회사 위키입니다. 작업 또는 문제에 대한 전용 페이지를 만듭니다(30초). 그런 다음 아이디어가 있거나 다른 사람들과 토론하려고 할 때마다 업데이트하십시오.

회의에서 "잠깐만, 이거 내려놓을게"라고 말하고 10~30초 동안 그것을 글로 표현한다. 글은 광범위하지 않아야 하지만 전체 아이디어를 종이에 옮기는 것처럼 완전하고 일관성이 있어야 합니다. 나중에, 당신이나 당신의 구절을 읽는 다른 사람은 당신이 지금 이해하고 있는 만큼 명확하게 이해해야 합니다. 이 트릭을 사용하면 많은 시간을 절약할 수 있지만 즉시 문서화할 수 있습니다.

이 기술은 두 가지 용도로 사용됩니다.

첫째, 성공으로 가는 길을 돌에 세게 눌러 진행 상황을 잠급니다. 누군가가 무언가를 잊어버리거나, 같은 것을 반복해서 반복하거나, 이미 협상된 동일한 것을 재협상할 위험이 더 이상 없습니다.

둘째, 마음을 비우고 잔소리하던 문제를 버리십시오. 이제 당신의 마음은 다음 도전에 굶주려 있습니다. 생산성이 얼마나 향상되었습니까!

이는 모든 규모의 프로젝트 또는 작업에 적용됩니다. 더 큰 공간의 경우 프로젝트가 발전함에 따라 점진적으로 증가하는 페이지 계층 구조가 있는 더 큰 공간을 갖게 됩니다. 여기서 중요한 개념은 빠른 메모리 덤프 프로토콜을 설정하는 작업을 시작하기 전에 문서 공간과 구조를 준비하는 것입니다!

기술적 비유를 선호하는 사람들을 위해 나는 우리의 마음을 처리 능력은 엄청나지만 작동 메모리는 제한된 프로세서에 비유할 것입니다. 기본적으로 한 번에 한 가지만 생각할 수 있습니다. 이 비유에서 문서는 영구적인 저장소 역할을 하는 반면 마음은 반복적인 접근 방식으로 복잡한 문제를 해결합니다. 어느 시점에서 다음 반복을 시작하고 이전 문서를 읽고 현재 상태를 작동 메모리에 로드하기로 결정하고 잠시 동안 그것에 대해 생각하고 새로운 발견으로 코드와 문서를 업데이트합니다. 완료될 때까지 단계적으로.

위에서 말했듯이 나는 사람들이 한 번에 많은 작업을 처리하도록 권장하지 않습니다. 반대로 할 일은 적을수록 좋습니다. 그러나 실제로 인간에게 최적화된 작업 상황은 많지 않으며 멀티태스킹이 필요할 수 있으며 이를 어떻게든 처리해야 합니다. 위의 트릭은 더 잘 처리하는 데 도움이 됩니다.

규칙 4: 형식적인 시간 추정에 시간을 낭비하지 마십시오

두 개의 프로젝트가 같지 않습니다. 다음에 유사한 프로젝트를 수행할 때 다른 고객, 다른 목표, 다른 팀을 갖게 됩니다. 어쩌면 다른 기술일 수도 있습니다. 표준 도구 및 구성 요소를 사용하더라도 구성 및 아키텍처를 사용자 지정해야 합니다. 소프트웨어 프로젝트를 처리할 때 50%에서 100% 사용자 지정 작업이 포함된다는 점을 염두에 두십시오. 연구, 토론, 사고, 시도 및 기타 예측할 수 없는 활동이 필요합니다. 실제로 동일한 프로젝트 유형으로 표면에 나타나는 것과 이전에 수행한 작업에서 엄청난 차이를 경험할 수 있습니다. 확장하여 새로운 프로젝트 유형은 정확하게 추정하는 것이 거의 불가능합니다.

예측할 수 없는 상황이라면 프로젝트 관리자는 어떻게 프로젝트 일정을 제시하고 준수해야 합니까?

문헌에 설명된 한 가지 공식적인 방법이 있습니다. 즉, 전체 프로젝트를 더 작은 단계로 분할하려면 각 단계에 소요되는 시간을 추정한 다음 개별 조각의 작업 길이를 결합하여 총 프로젝트 길이를 계산합니다. MBA 과정에서 가르치는 이 방법 뒤에는 수많은 이론이 있습니다.

그러나 불행하게도 아무리 많은 수학도 그것을 구할 수 없습니다. 이 방법은 시간이 얼마나 걸리는 것은 말할 것도 없고 완전히 사용할 수 없고 비실용적일 정도로 부정확하기로 악명이 높습니다. 방법론에 열광하는 사람들 사이에서도 조정 없이 형식적인 계산 방법을 사용하는 프로젝트 관리자를 본 적이 없습니다. 회사에서 그런 방법 사용을 엄격히 강요했는데도! 실제로 최고의 성과를 내는 관리자는 아래와 같이 완전히 다른 대체 방법을 사용합니다.

훌륭한 프로젝트 관리자는 프로젝트 유형, 환경, 관련된 자원, 조직 유형 및 실제 프로젝트 기간에 영향을 미치는 기타 모든 작업 측면을 주의 깊게 살펴봅니다. 물론 아무도 자신의 실수로부터만 배울 필요는 없습니다. 이러한 관찰은 직간접적으로 수행될 수 있습니다. 예를 들어, 책을 통해 또는 다른 사람들이 수행한 프로젝트를 연구하거나 심지어 지식인을 사람에게 전달함으로써. 이러한 통계적 최상위 수준 지식은 개인 프로젝트 일정 탐색을 향상시킵니다.

위에서 설명한 방법의 두 가지 중요한 결과를 강조하고 싶습니다.

첫째, 추정 정확도는 경험에 따라 향상됩니다. 어떤 강력한 방법론으로 무장한 경험이 없는 사람이 그것을 잘할 수 있는 방법은 없습니다. 둘째, 가장 좋은 추정치라도 여전히 통계적 측면에서만 유효합니다. 즉, 어떤 프로젝트는 4~12개월 정도 걸릴 수 있습니다. 이것이 맞다고 가정하면 프로젝트가 평균 8개월 동안 실행될 확률이 50%라는 것을 이해해야 합니다.

통계적 예측을 이해하는 것은 놀라운 효과가 있습니다. 현명한 관리자는 그런 프로젝트에 12개월 추정치를 넣은 다음 일찍 완료하여 모두를 놀라게 할 것입니다. 즉, 팀이 프로젝트 일정을 하루까지 따를 것이라고는 아무도 예상하지 못했습니다.

프로젝트 관리자와 그들의 상사에 대한 일반적인 조언은 공식적인 시간 추정 방법론에 시간을 낭비하지 말라는 것입니다. 대신 프로젝트 기간에 대한 통계 정보 수집을 장려하고 이 정보를 회사 전체에 공유하십시오. 나는 그러한 접근 방식이 전사적으로 구현되어 기적적인 예측 정확도를 가져온 회사를 알고 있습니다.

규칙 5: 작업 전환 및 우선 순위 조정 비용 이해

인간의 마음은 놀랍도록 자연적으로 만들어졌습니다. 놀라운 일이지만 한계가 있습니다. 즉, 특정 영역과 특정 유형의 작업에서 탁월하도록 설계되었습니다.

개발자의 마음은 확실히 소프트웨어 개발의 큰 자산입니다. 프로젝트 관리자로서 당신은 그것을 더 잘 이해하는 데 관심이 있고 그것을 가장 잘 수행할 수 있는 위치에 두시겠습니까?

너무 많은 이론을 피하면서 간단한 용어로 말합시다. 이론은 당신 자신이나 다른 사람의 경험으로부터 배울 필요가 있기 전까지만 당신을 데려간다는 것을 기억하십시오.

인간의 마음은 강력한 문제 해결 능력과 아이디어 생성 잠재력을 가지고 있습니다. 불행히도, 이 잠재력을 활용하는 것이 항상 가능한 것은 아닙니다. 주로 아이디어 생성을 지원하려면 문제의 모든 부분을 동시에 활성 메모리에 함께 보관해야 하기 때문입니다. 그렇기 때문에 복잡한 문제를 풀 때 중요하지 않은 부분은 잘라내고 동시에 메모리에 저장되는 요소의 수를 줄이기 위해 작업을 일반화하거나 재구성하는 단순화 단계를 거칩니다. 즉, 하나의 매우 좁은 복잡한 문제 또는 여러 개의 간단한 문제를 해결할 수 있습니다.

그러나 비율은 선형이 아닙니다. 동시에 하는 일의 수를 늘리면 문제 해결 능력이 급격히 저하됩니다. 그렇기 때문에 인류는 항상 삶의 최적화로 역할 분리를 사용하고 사용할 것입니다. 두 사람이 두 가지 작업을 따로 수행하면 두 작업을 동시에 수행하는 것보다 더 빠르게 돌파구를 찾을 수 있습니다.

또 다른 중요한 인간 정신 특성은 컴퓨터처럼 즉시 작업 사이를 전환할 수 없다는 것입니다. 사실, 마음대로 생각하는 것을 멈출 수는 없습니다. 새로운 개념에 대한 생각을 즉시 전속력으로 시작할 수는 없습니다. 이러한 종류의 정신적 관성은 항공 교통 관제사에 의해 완벽하게 설명됩니다. 레이더를 보고 전체 그림을 보고 있더라도 빠르게 작동하려면 메모리에 로드해야 합니다. 새 작업자가 교대 근무 시 이전 작업자를 교체하기 전에 화면을 보는 데 10분이 걸립니다.

더 나쁜 것은 우리가 마음대로 일을 잊을 수 없다는 것입니다. 우리가 배운 모든 것은 우리와 함께 머물렀다가 시간이 지나면서 점차 희미해져 새로운 지식에 사용할 수 있는 공간을 차지합니다. 그리고 더 나쁜 것은 이 효과가 때때로 "미완성된 일"이라는 느낌으로 인해 악화된다는 것입니다. 완료되어 미래에 필요하지 않은 것을 잊는 것이 훨씬 쉽습니다. 반면에 나중에 끝내기 위해 일을 미루면 뇌는 자연스럽게 "나중에 참조할 수 있도록" 표시된 정보를 붙잡고 새로운 지식이 그 자리를 차지하도록 내버려 두지 않습니다.

괜찮아. 이제 작업 전환에 대한 아이디어를 설명했으므로 실제(말하자면) 사고 실험에서 이것이 어떻게 작동하는지 살펴보겠습니다.

10명의 일반 개발자가 10개의 일반 작업(1인당 하나의 작업)을 수행하고 있다고 상상해 보십시오. 산만하지 않은 완벽한 환경에 그들을 가둘 수 있다고 가정하면 각 작업은 한 마음으로 일정 시간 안에 해결할 수 있습니다. 가장 긴 단일 작업을 완료하는 데 걸리는 시간만큼 모든 것이 완료됩니다.

이제 동일한 정신 실험을 반복해 보겠습니다. 이번에는 (중요한) 이유 없이 개발자 간에 작업 할당을 지속적으로 전환할 것입니다. 매일 각 개발자는 새로운 작업을 수행해야 합니다. 더 좋은 점은 매시간 스위치를 켜두는 것입니다. 얼마나 빨리 끝날 것 같습니까? 아마 절대.

첫 번째 시나리오의 프로젝트 관리자는 프로젝트를 효과적으로 실행할 수 있었습니다. 두 번째는 그것을 "실행"하는 데 성공했습니다. 그건 확실합니다...그들이 죽음을 조장했다는 의미에서 말이죠. 축하합니다. 이 프로젝트 죽이기 기술은 단순한 시간 낭비 외에도 직원의 사기를 0으로 떨어뜨리기 때문에 매우 효과적입니다.

대부분의 사람들은 위와 같은 순전히 학문적인 방식으로 제시될 때 위의 예에 동의할 것입니다. 그러나 실생활에서 그들은 작은 압력에도 갑자기 모든 것을 잊어 버립니다. 큰 보스가 진행 보고서를 요구하거나 고객이 특정 기능 구현 날짜에 대해 묻습니다. 거의 모든 외부 이벤트로 인해 프로젝트 관리자가 팀에 달려가 우려를 표명할 수 있으며, 그 후 작업 재할당 및 우선 순위 저글링이 뒤따릅니다. 여기저기서 약간의 시간을 벌려고 하다가 결국에는 프로젝트를 더 이상 궤도에서 벗어나게 만드는 결과를 낳습니다.

그것은 불행히도 꽤 자주 발생하는 실제 시나리오입니다.

좋은 관리자는 일어서서 정서적 충격파를 흡수하고 생산적인 미래 토론 항목으로 변환하여 이러한 사소한 방해로부터 팀을 보호합니다. 그것은 확실히 감정적으로 힘든 일이지만 팀이 좋은 작업 리듬을 유지하고 전달하도록 하는 유일한 방법입니다.

규칙 6: 시스템 설계를 개선하기 위한 방법으로 아키텍처 검토 사용

IT 산업은 과잉 및 과소 엔지니어링의 개념으로 작동합니다. 인터뷰에서 언급되면 모두가 과도하게 설계된 것은 나쁘다고 말합니다. 질문 자체가 "너무 많이"를 의미하는 "over"의 부정적인 의미를 전달하기 때문에 대답하기 쉽습니다. 실제 실용적인 지식은 아키텍처가 과도하게 설계되었을 때를 인식하고 초기 단계에서 방지하는 것입니다.

이에 대해 제가 검증한 몇 가지 조언을 드리겠습니다.

우선, 필요한 모든 기능을 제공하는 더 간단한 다른 솔루션이 있는 경우 솔루션이 과도하게 엔지니어링된 것으로 간주될 수 있습니다. 즉, 더 간단한 솔루션을 모른다면 누군가가 당신이 틀렸다는 것을 증명하지 않는 한 당신이 제공할 수 있는 가장 간단한 솔루션이 가장 좋은 것입니다.

상상의 아키텍트가 솔루션의 완벽함을 위해 진정으로 노력한다면 일반적인 아키텍처 검토에서 충분히 최적임을 보장합니다. 불행히도 아키텍처 검토에는 최소한 몇 명의 다른 자격을 갖춘 건축가가 필요합니다. 많은 경우에 사용할 수 없거나 비실용적일 위험이 있습니다. 동료 검토가 없으면 건축가는 일반적인 실수를 하기 쉽습니다. 그것들을 하나씩 검토하고 각각에 대해 가능한 해결책에 대해 논의해 봅시다.

가장 흔한 실수 중 하나는 비즈니스 목표를 염두에 두지 않고 설계하는 것입니다. 모든 작업 활동은 최종 소비자의 만족이나 회사의 성공 또는 유사한 비즈니스 요구와 연결되어야 합니다. 그러나 종종 그러한 목적을 염두에 두지 않고 전체 또는 부분적으로 설계된 아키텍처를 볼 수 있습니다. 추론은 부재하거나 가능한 한 많은 현대적인 종소리와 휘파람을 사용하는 것으로 요약됩니다.

이 경우 건축가는 소비자가 지불한 것을 하지 않습니다. 오히려 그들은 자신의 재미와 즐거움을 위해 멋진 장난감을 가지고 노는 것입니다. 이것은 공식 산업에서 결코 용납될 수 없습니다. 그럼에도 불구하고 꽤 자주 발생하는 것 같습니다.

때때로 문제는 건축가의 성격과 특정 기술이나 도구에 대한 집착에 있습니다. 그들은 단지 그것을 사용하기를 좋아하고 그들이 해결하고자 하는 비즈니스 요구 사항을 일관성 있게 설명할 수 없습니다. 그에 가까운 것은 사람들이 작은 조각으로 무언가를 만드는 것 외에는 아무것도 모르는 또 다른 경우입니다. 확실히 외부 이벤트는 디자인 세계에 뛰어들고 실제 고객에게 다시는 돌아오지 않으려는 충동을 촉발합니다. 초기 트리거가 유효한 비즈니스 입력일 수 있지만 현실과의 장기간의 분리는 작품의 유용성을 감소시킵니다.

이에 대한 치료법은 매우 간단하지만 자기 훈련이 필요합니다. 훌륭한 건축가는 펜과 종이가 왜 필요한지 명확하고 정직하게 답할 수 있을 때까지 펜과 종이를 만지면 안 됩니다. 그러한 필요는 다양한 형태로 나타날 수 있습니다. 형식적 요구 사항, 제품 개선에 대한 암묵적인 요구 또는 이전 설계의 효율성을 떨어뜨리는 새로운 기술의 출현일 수 있습니다. 어쨌든 건축가 자신이 원동력을 이해하는 한 공식적인 방아쇠가되어서는 안됩니다. 그런 다음 이 힘을 설계 품질의 궁극적인 검증으로 사용할 수 있습니다.

감지하기 어려운 또 다른 문제는 블록 아키텍처 사고와 관련이 있습니다. 그러한 사고방식을 가진 사람들은 모든 것에 대한 해결책이 있다고 믿으며 그 해결책은 항상 빌딩 블록으로 구현됩니다. 즉, 아키텍처를 전체적으로 평가하지 않고 기능을 구성 요소로 직접 변환합니다. 원하는 기능이 필요할 때 시스템에 원하는 기능을 제공하는 구성 요소를 첨부하기만 하면 됩니다. 대부분의 경우 이는 형식 요구 사항을 충족하지만 시스템을 일관성 없는 상태로 남깁니다. 새로운 블록은 개발, 지원 또는 회사의 라이선스 모델에 대한 기존 시스템 호환성을 기반으로 선택되지 않았습니다. 따라서 팀은 기존 구성을 수정하거나 기존 시스템 용량을 통해 이 기능을 구현하려고 합니다. 결과적으로 시스템 지원 및 유지 관리는 점차적으로 성능 저하로 이어지는 복잡한 악몽으로 변모합니다.

이 문제에 대한 간단한 해결책은 없습니다. 시스템 엔지니어링은 예술이고 새로운 구성 요소를 추가해야 하는지 또는 피할 수 있는지 여부를 예측할 수 없기 때문입니다. 가장 좋은 방법은 시간이 지남에 따라 누적되는 유지 관리 및 아키텍처 문제의 백로그를 유지한 다음 전체 시스템 아키텍처를 주기적으로 검토하는 것입니다. 이 주기적인 검토를 통해 새로운 기술을 고려할 수도 있습니다. 따라서 아키텍처 검토의 일반적인 목적은 문제를 수정하는 것이 아니라 원하는 개선 사항의 잠재적인 실행 가능성과 노후화의 불가피성에 대비하여 전체 시스템의 잠재적 실행 가능성을 평가하는 것입니다.

규칙 7: 가치 있는 팀 플레이어

대부분의 IT 업계 전문가들은 인터뷰에서 자신이 좋은 팀 플레이어인지 또는 팀에서 잘 일하는 지 질문을 받았습니다. 그러나 문헌에서 이에 대한 명확한 정의를 본 사람은 아마 아무도 없었을 것입니다. 분명히 그러한 사람은 일반적으로 팀의 성공에 기여할 것이지만 그러한 성공을 보장하는 독특한 개인적 자질을 실제로 정의할 수 있는 사람은 거의 없습니다.

나는 다양한 수준에서 일하는 많은 사람들을 관찰하고 그들의 개인적인 자질이 프로젝트 진행에 어떻게 영향을 미치는지 보았습니다. 팀워크에 가장 도움이 되는 개인적 자질에 대해 다음과 같은 사항을 제시하고자 합니다.

의사 소통

물론 첫 번째이자 가장 중요한 품질은 의사 소통 능력입니다.

의사 소통 능력이 전혀 없는 사람을 상상해 보십시오. 확실히 팀원들로부터 피드백을 받지 않으면 완전히 쓸모 없게 됩니다. 이것은 너무 명백해서 아무도 인터뷰 중에 이 기술을 실제로 측정하지 않습니다. 이는 사람이 말을 잘할 수 있는 한 기술이 충분히 좋은 수준임을 의미합니다.

의사 소통은 이진 예/아니오 기술이 아닙니다. 정보 전송 창에 가깝습니다. 넓을수록 정보 교환이 빠르고 명확해집니다.

그 창의 개방 범위는 인구에 따라 크게 다르기 때문에 그러한 창의 너비 측정은 팀 플레이어의 중요한 특성입니다. 우리는 이 맥락에서 정보를 전달하는 것에 대해 이야기하고 있지만 부드러운 대화나 사람들을 격려하거나 대화와 의사 소통을 통해 동기를 부여하거나 조직화하는 것은 아닙니다.

커뮤니케이션 스타일도 중요하지 않습니다. 정보는 구두, 텍스트, 그림 또는 혼합된 방식으로 전달될 수 있습니다. 그 사람은 빠르거나 느리게 말할 수 있습니다. 그들은 당신의 눈을 바라보고 항상 웃고 있는 것처럼 다정할 수도 있고, 시선을 돌리고 단조로운 목소리로 말할 수도 있습니다. 스타일은 동료에 대한 개인적인 인식에 영향을 줄 수 있지만 의미를 명확하게 이해하는 한 모든 스타일로 충분합니다.

의사 소통 능력을 감지하고 측정하는 실제 사례로 이동합시다.

일반적으로 의사 소통 기술에는 두 가지 주요 측면이 있습니다. 첫째, 정보를 공유하려는 의지입니다. 어떤 사람들은 공유하기를 열망하지만 다른 사람들은 정보를 숨기려고 합니다. 그 성향은 다소 자연스럽지만 자기 동기 부여와 훈련을 통해 천천히 변경할 수 있습니다. 일종의 정보 공유 의지를 보이는 사람이 미래에도 그것을 보여줄 것이라고 가정하는 것이 안전합니다. 그렇기 때문에 그 특성은 팀에서 후보자의 미래 성공을 예측하는 데 좋습니다.

실생활에서 정보를 숨기려는 사람들은 쉽게 눈에 띕니다. 그들은 일반적으로 실제로 필요한 정보 대신 의도적으로 쓸모없는 정보를 제공하려고 합니다. 또는 정보의 흐름을 내부로 돌리고 "알 필요가 있는" 상황에 대한 답변을 최소화하기 위해 예비 질문을 합니다. 그들의 전술이 무엇이든 결국에는 원하는 정보를 얻지 못했다거나 정보를 얻는 데 너무 많은 추가 노력이 필요하다는 느낌을 받게 될 것입니다.

어떤 유형의 열린 사람은 질문을 더 잘 이해하기 위해 예비 질문을 한 다음 가장 편리한 방식으로 답변을 전달할 수 있으므로 의도를 이해하는 것이 중요합니다. 정보를 숨기려는 사람은 대화를 방해하기 위해 추가 질문을 하고 처음 질문에는 대답하지 않습니다.

의사 소통 기술의 또 다른 부분은 청취자에게 조율하는 능력입니다.

사람마다 주제 이해 수준이 다르고 의사 소통 방식이 다르며 특정 세부 사항에 대한 관심도 다를 수 있습니다. 의사 소통이 똑똑한 일부 사람들은 청취자의 이해 능력과 특정 정보를 전달하기 위해 답변을 준비하는 능력에 따라 대화 흐름을 변경합니다. 그러한 준비 과정에서 청중의 관심을 좁히기 위해 몇 가지 예비 질문을 할 수 있습니다. 의사 소통의 차이점을 "해결"하는 능력은 거의 모든 경우에 이해를 얻을 수 있기 때문에 정말 훌륭한 기술입니다. 반면에 융통성 있는 말을 하는 사람은 때때로 해결할 수 없는 오해의 막다른 골목에 갇힐 수 있습니다.

강점과 약점 이해하기

팀 플레이어에게 필수적인 또 다른 개인 자질에 집중합시다.

대부분의 사람들은 협업을 촉진하고 생산성을 높이려면 팀 환경이 일반적인 주변 환경보다 더 우호적이어야 한다는 데 동의할 것입니다. 따라서 팀에서 각 구성원의 강점과 약점을 파악하여 업무를 적절하게 분배하고 약점을 강점으로 보완하는 것이 중요합니다. 이 길의 첫 번째 단계는 모든 구성원이 서로의 실력을 정직하게 측정하는 것입니다. 심리적으로 이것은 우리가 자연스럽게 자신의 약점을 다른 사람들에게 숨기고 자신을 보호하는 경향이 있기 때문에 어려울 수 있습니다.

여기에 화기애애한 팀 분위기가 도움이 됩니다.

따라서 새 멤버는 팀 규칙을 플레이해야 합니다. 불행히도 어떤 사람들은 우호적인 환경에서도 경계를 늦출 수 없습니다. 그들은 평생 동안 외로운 늑대처럼 행동합니다. 이것은 그들보다 강합니다. 슬프게도 그러한 태도는 팀 노력에 기여하지 않습니다.

인터뷰에서 이러한 외로운 늑대를 식별하는 쉬운 기술이 있습니다. 그들은 자신이 아무것도 모른다는 사실을 결코 인정하지 않습니다. 물론 사람들은 자신의 모든 능력을 보여주고 어려운 문제 하나하나를 해결하기 위해 최선을 다하는 것을 좋아합니다. 그러나 누구에게나 지식의 한계는 있습니다. 우리의 한계는 우리의 기술을 형성합니다. 한계를 인정하지 않는다는 것은 후보자가 자신을 모든 일에 동등하게 능숙하고 아무 것도 하지 않는 만능 만능인으로 자처한다는 것을 의미합니다.

전문가를 고용할 때 그러한 사람들을 피하고 싶을 것입니다. 게다가, 그 오만한 태도는 종종 또 다른 위험 신호, 즉 도움을 요청하지 않으려는 특성과 함께 나타납니다. 도움을 요청할 수 있는 능력은 팀워크에 절대적으로 중요합니다. 그것 없이는 우리는 빨리 발전하고 발전할 수 없습니다. 그런 완고한 사람은 회사 자원과 시간을 소모하고 어려운 일과 무기한 싸우지만 팀원에게 도움을 요청하지 않습니다. 면접에서 그러한 후보자를 탐지하는 쉬운 트릭이 있습니다. 의미가 없는 질문을 하거나 말도 안되는 용어를 언급하십시오. 평범하고 이상적으로 호기심 많은 사람은 모른다고 말하고 그것이 무엇인지 물을 것입니다. 방어적인 사람은 옳고 그른 대답이 없고 "모른다"고 실격시키지 않는다고 강조하더라도 절대 그렇게 하지 않을 것입니다.

규칙 8: 팀워크 조직에 중점을 둡니다.

위의 이전 주제와 마찬가지로 팀워크 구성에 대한 정보가 거의 없습니다. 팀워크가 더 낫다는 것은 누구나 알고 있지만 팀을 구성하고 유지하는 방법은 여전히 ​​미스터리로 남아 있습니다. 그러나 팀 빌딩의 모든 측면을 다루는 것이 불가능하더라도 여기에서 최소한 몇 가지 핵심 팀 빌딩 기술을 탐구할 수 있습니다.

전문성 구축

각 IT 프로젝트는 고유합니다. 성공하려면 프로젝트 세부 사항을 배우고 마스터해야 합니다. 여기에는 기술 지식과 비기술 지식이 모두 포함될 수 있습니다. 비기술적 지식의 예로는 관리, 고객, 기술 지원 팀 등을 위한 개인 네트워크가 있습니다. 특수 기술 지식은 일반 IT 기술에 추가 세부 정보입니다.

예를 들어 프로젝트를 빌드하려면 Maven을 알아야 할 수 있습니다. 그러나 정확한 빌드 구조, 속성 및 필터링의 위치는 여전히 프로젝트마다 다릅니다. 모든 유형의 지식과 마찬가지로 이러한 세부 사항을 마스터하는 데는 시간이 걸립니다. 더 많은 시간을 투자할수록 더 나은 성과를 낼 수 있습니다. 시간은 당신이 가진 가장 귀중한 자원입니다. 팀 구성원이 가능한 한 오랫동안 동일한 기능 영역에 집중하여 전문 지식을 활용하고 더 많이 개발하여 팀 성과를 지속적으로 향상시키길 원합니다.

불행히도, 그것을 무기한으로 하는 것은 불가능합니다. 한편으로 사람들은 지루할 수 있습니다. 다른 한편으로, 당신은 그들의 전문성을 잃어 예기치 않게 프로젝트를 위험에 빠뜨릴 위험이 있습니다.

팀의 성과에 큰 지장을 주지 않으면서 단점을 극복할 수 있는 방법이 있는지 봅시다.

팀원들 사이에 초점 영역을 분배하고 그들이 전문성을 쌓도록 하십시오. 어느 시점에서 그들은 이 프로젝트의 범위에서 이해할 수 있을 만큼 충분히 높은 수준에 도달합니다. 추가 학습 노력은 이 시점에서 크게 향상되지 않습니다. 의욕과 도전이 없으면 똑똑한 사람들은 지루해지고 자신의 일을 싫어하기 시작합니다.

다른 곳에서 학습 가능성을 열어 이를 방지하십시오. 그들에게 프로젝트와 회사의 기술 스택에 대한 정보를 제공하고 새로운 도전을 시작하십시오. 그들의 관심이 프로젝트의 범위 내에 있다면, 당신은 팀을 계속 도전하게 하고 동시에 유용한 팀 기술을 확장하는 두 배의 보상을 받습니다. However, any self development is good to avoid boredom, even if it doesn't intersect with immediate project needs. As long as the team expert brains are engaged, they keep supporting already-learned project areas in the back of their minds.

When leaving the company, team experts take a big portion of expertise with them. One of the countermeasures you can use is to widely disseminate documentation that can be updated on the fly. Think of the “persistent memory storage” mentioned earlier.

Still, a project manager would love to duplicate knowledge in team member heads if possible. Having two of every expert would be a simple solution for that, albeit twice as expensive. But there is a leaner way to do it. The trick is to let most of your developers develop expertise in multiple areas, so that each project aspect is covered by at least one deep expert. At the same time, chose a few senior members to grow the breadth along with the depth of their expertise. Usually, this role is best played by a team development lead or an architect. The team lead interacts with all team members and participates in all task implementations. They can tap into each and every aspect of the project, understanding all of its internals. This way, even if you lose one of the experts, the leader can take over and keep on the project progressing until you can hire and train the replacement.

Another flavor of same idea is to cross-train developers in adjacent areas, letting them to observe, learn, and occasionally try their peers' work. Keep in mind that this cross-training needn't be extensive, so it doesn't disrupt focus on developers' primary tasks and doesn't impede productivity. Developing expertise across leadership and cross-training developers builds you a cushion of protection against unforeseen life culprits and allow you some time to maneuver with project resources.

Minimizing Distraction

Software development is a chain of complex and creative problem solving. Even though, with industry development, these complex problems get more and more automated, the work doesn't become easier. It still involves a large amount of art and individual insight, which is very hard to predict and sometimes even harder to wrangle.

Developers are the edge of the weapon. Their concentration is equivalent to the hardness of the weapon's tip. Increase their focus and you'll cut through problems like a hot knife through butter. Distract them and you'll end up clumsily poking at the butter with a blunted stick.

This cannot be over emphasized: Non-problem-solving work can be intensified with motivation or extra effort. For problem solving work, you need maximum detachment from the mundane world. It is difficult to leave all everyday problems behind, and a good project manager should build a quiet development environment in both the physical and mental senses. A developer's workplace should be analogous to a sensory deprivation tank.

Physically, this is implemented as a closed work space. Every team member should have a cube at least where they can dive into solitude. It is preferable to avoid loud noises and aisle conversations. Quick interpersonal communications should be maintained by emails and chats. Large groups should use closed rooms for their meetings to not distract others. This is a pretty standard picture for office life as it used to be.

Unfortunately, the open space paradigm is being adopted more and more widely even in large offices. I would warn against his fad. Even worse, together with open spaces, top management encourages in-place team conversations. That is, in essence, shouting to a person in another row over an uninvolved team member's head. A developer that is interrupted by loud conversation twenty times a day won't have a shred of concentration left. Certainly a major performance killer.

Allowing for a Learning Curve

Knowledge itself is power. This is especially true for such a complex industry as IT. Every task here has its regular cycle: learn, research, implement. The learning phase in particular is invaluable. Not only does better understanding allow better and faster implementation, there are certain knowledge thresholds that must be passed in order to achieve something at all. Of course, there is no point in over-learning either. Each skill should match the production need and not much above it.

However, often, developers are pressured in the opposite direction; to stop learning and to do nothing but produce. Learning is perceived as wasted effort, as it doesn't move the task progress bar. This seems like a really easy problem to solve, sitting at home and reading this article. Yet in the real life, the slightest work pressure turns every manager into that demanding idiot who insists that everybody “stop learning and start doing something already.” I swear, I have heard those exact words so many times throughout my career… A good manager and team leader should understand that learning is an important part of the process even if it doesn't directly increment the progress bar.

Building a Competitive Development Workshop

The tips and tricks presented above are a subset of effective software production expertise. By understanding and applying them in real life, you'll improve your production effectiveness little by little. If you think they are largely unconnected and lacking a theoretical base, you are absolutely right.

I would like to highlight that building a competitive development workshop is not a single-discipline task. It requires knowledge and expertise in multiple adjacent areas. Building such expertise is a hard work. There is no single theoretical base or idea that would solve all your problems at once. Believing in such a silver bullet just serves to distract you from the real goal.

Try out these tips at work to see if they are worth adopting permanently. If you find them useful (or not), leave a comment below and share your experience!