소프트웨어 엔지니어 성능 검토 설명

소프트웨어 엔지니어 성능 검토에 대한 다양한 접근 방식을 고려할 때 한 가지 질문이 떠오를 수밖에 없습니다. 다중 검토 모델을 사용해야 하는 이유는 무엇입니까? 간단한 대답은 소프트웨어 개발은 ​​종종 다양한 팀에서 일하는 수십 명의 개인을 포함하는 복잡하고 다면적인 프로세스라는 것입니다.

경영진과 이해 관계자는 특히 큰 조직과 팀에서 각 개발자의 자격과 책임에 대해 항상 잘 알고 있는 것은 아닙니다. 이것이 성능 검토가 소프트웨어 개발 프로세스 전체에서 각 소프트웨어 엔지니어의 책임, 역량, 기술 세트 및 역할을 이해할 수 있는 기술적으로 숙련된 전문가에게 맡겨야 하는 이유입니다.

그렇다면 성과검토를 하는 올바른 방법은 무엇일까요? 대답은 조직의 규모와 목표에서 엔지니어 성과의 보다 세부적인 측면에 이르기까지 다양한 요인에 따라 달라집니다.

경영성과 검토

관리자는 엔지니어링 성과 검토에서 주도적인 역할을 합니다. 많은 소규모 조직에서는 직속 관리자가 검토를 수행하는 유일한 사람일 수 있습니다. 대기업에서는 검토 프로세스가 더 복잡하고 다양한 역할과 부서에 더 많은 사람들이 참여하기 때문에 일반적으로 그렇지 않습니다. 규모가 큰 조직은 또한 소규모 조직보다 동료 평가와 자체 평가를 더 자주 사용하는 경향이 있습니다.

주요 기업이 20세기 후반에 이를 채택한 이후 성과 검토는 먼 길을 걸어왔지만 성과 검토의 역사는 일부 성과 검토 모델을 뒷받침하는 행동 심리학과 마찬가지로 이 기사의 범위를 벗어납니다. 대신, 이 부분은 경영진의 책임부터 시작하여 프로세스의 실질적인 측면에 중점을 둡니다.

접근 방식은 조직의 규모와 유형에 따라 다를 수 있지만 일부 기본 원칙은 전부는 아니지만 대부분의 검토 상황에 적용됩니다.

관리자가 성과 검토에 접근하는 방법

경영진은 검토 프로세스를 철저히 계획하고 관련된 모든 사람이 자신의 책임을 인식하도록 해야 합니다.

• 검토 프로세스는 미리 정의되어 관리자와 엔지니어가 참여하고 피드백을 제출할 수 있는 충분한 시간을 허용해야 합니다. 막판 피드백은 마감일을 맞추기 위해 급하게 제출할 수 있으므로 가치가 떨어질 수 있습니다.
• 경영진은 검토 프로세스의 목표, 목적 및 가치를 엔지니어 및 기타 이해 관계자에게 전달할 필요가 있습니다. 원활한 의사 소통은 프로세스에 대한 의심을 없애고 리뷰의 품질을 향상시켜야 합니다.
• 검토 템플릿 또는 양식은 사전에 동의해야 하며 수명을 염두에 두고 설계해야 합니다. 이상적으로는 검토 주기 간에 변경되어서는 안 되며 시간이 지남에 따라 검토 결과를 비교할 수 있습니다.
• 방법론은 편향을 최소화하고 높은 수준의 일관성을 보장하는 것을 목표로 해야 합니다. 모든 관리자와 엔지니어는 특정 작업을 수행하는 고유한 방식을 가지고 있지만 일관성은 개인과 개인의 편견 또는 선호도가 결과에 부당한 영향을 미치는 것을 방지합니다.
• 동료 검토 및 자체 평가를 사용할 때 경영진은 검토 프로세스의 무결성을 보장해야 합니다.

편견 완화 및 의심스러운 리뷰 처리

검토 프로세스에 대한 경영진의 막대한 영향으로 인해 관리자는 프로세스를 약화시킬 수 있는 잠재적인 편견 및 기타 문제를 염두에 두어야 합니다. 계획 단계가 잘 실행되고 전체 프로세스가 적절하게 설계되었더라도 경영진은 특정 원치 않는 관행을 제거하고 프로세스의 무결성을 보장해야 할 수도 있습니다.

• 프로세스의 모든 단계에서 역량과 기대치를 고려해야 합니다. 광범위한 브러시로 모든 팀 구성원을 검토하면 관리자나 동료가 지나치게 긍정적이거나 부정적인 리뷰를 제출할 수 있습니다. 동료가 특정 엔지니어의 특정 역량에 익숙하지 않아 의심스러운 리뷰를 제출했다고 가정합니다. 이 경우 경영진이 개입하여 이러한 검토가 전체 점수를 왜곡하지 않도록 해야 합니다.
• 관리자는 검토를 거부할 수도 있습니다. 특정 관리자가 소규모 엔지니어 팀의 작업과 연결되어 있지 않다고 가정합니다. 이 경우 균형 있고 상세한 검토에 필요한 컨텍스트와 지식이 부족할 수 있으므로 팀의 성과를 직접 검토해서는 안 됩니다.
• 특정 개인이나 직무에 대한 깊이 있는 지식이 부족한 검토자는 자신의 성과에 대한 검토를 제출하여 확인란을 선택해야 한다고 느낄 수 있으므로 내용이 많지 않고 검토 프로세스에 많은 가치를 추가하지 않는 검토가 생성됩니다.
• 편향되고 일방적인 리뷰도 결과를 왜곡할 수 있습니다. 관리자가 자신의 의사에 반하여 고용된 팀원을 검토하거나 프로젝트를 처리하는 팀이 특정 관리자의 승인을 받지 않은 경우 해당 검토가 객관적이지 않을 수 있습니다. 또는 검토자가 특정 성과 지표를 "선택"하여 개인이나 팀이 자신의 관심사에 맞기 때문에 더 좋게 보이게 할 수 있습니다.

이상적으로는 관리자와 경영진이 순전히 객관적인 사고 방식으로 검토를 수행할 수 있지만 편견이 존재합니다. 그러나 그것들을 알고 있으면 그 영향을 완화할 수 있습니다.

관리자가 소프트웨어 엔지니어를 검토하는 방식은 관리자의 성과와 전문성에 대한 귀중한 통찰력을 제공할 수 있음을 명심하십시오.

동료 리뷰

동료 리뷰는 관리자 리뷰에 비해 몇 가지 장점을 제공하지만 염두에 두어야 할 장단점이 있습니다.

동료들은 관리자보다 서로의 성과를 평가하는 데 더 나은 위치에 있는 경향이 있습니다. 그들은 팀 동료의 작업에 훨씬 더 많이 노출됩니다. 그들은 종종 같은 프로젝트에 참여하고 같은 사람들과 협업하기 때문에 팀의 역동성과 개별 엔지니어의 능력을 잘 파악하는 경향이 있습니다.

그러나 피어 리뷰도 편견의 영향을 받을 수 있습니다. 편견은 우정에 근거하여 긍정적으로 나타날 수도 있고, 개인적인 문제나 팀 구성원 간의 경쟁으로 인해 발생하는 부정적으로 나타날 수도 있습니다. Groupthink는 특히 긴밀하게 연결된 팀에서 검토 프로세스에 영향을 줄 수 있습니다. 사람들은 팀원을 대신하는 경향이 있기 때문입니다. 이러한 가능성을 감안할 때 피어 리뷰 템플릿과 설문지는 편향을 완화하는 방식으로 설계되어야 하며 가능할 때마다 특정 역량과 객관적인 기준에 초점을 맞춰야 합니다. 팀 구성원의 결과가 핵심 성과 지표를 추적하는 방법은 개인 특성에 대한 주관적인 질문이나 기타 개방형 질문보다 더 많은 가치를 추가하는 경향이 있습니다.

편견의 가능성은 핵심 질문을 제기합니다. 피어 리뷰는 익명이어야 합니까?

익명 및 공개 검토를 모두 지원하기 위해 유효한 주장을 할 수 있지만 다양한 조직 체계와 팀 규모를 고려하는 것이 중요합니다. 따라서 대부분의 조직이 익명의 리뷰를 선호하지만 결정적으로 옳고 그른 대답은 없습니다.

익명 vs. 공개 피드백

익명 피드백의 장점을 자세히 살펴보겠습니다.

• 익명성은 개방성과 독창적인 사고를 장려할 수 있습니다. 대부분의 팀이 무언가 또는 누군가에 대해 긍정적인 생각을 한다면 반대 의견은 인기가 없을 수 있습니다. 익명의 검토자는 동료를 적대시하지 않고 다른 관점을 제시할 수 있습니다.
• 익명 피드백에는 귀중한 정보가 포함될 수 있습니다. 한 전문가가 같은 사람에 대한 익명의 공개 피드백을 수집한다고 가정해 보겠습니다. 공개 검토에서 인용하기를 꺼릴 수 있는 문제를 제기하기 위해 익명의 의견을 인용할 가능성이 있습니다. 몇 가지 추가 포인트는 특히 팀의 나머지 사람들에게 분명해지기 전에 문제가 제기되는 경우 큰 가치가 있습니다. 이 조기 경고는 경영진과 검토자가 새로 식별된 결점을 해결하고 수정할 기회를 주어 더 심각한 문제로 확대되지 않도록 합니다.
• 관계를 유지하는 것은 익명 피드백의 또 다른 중요한 측면입니다. 사람들은 부정적인 의견에 다양한 방식으로 반응하므로 익명을 유지하면 응집력을 유지하고 팀원 간의 마찰을 예방할 수 있습니다.
• 리뷰가 필수가 아닌 경우 일반적으로 사람들이 익명 리뷰에 참여하도록 설득하는 것이 더 쉽습니다.

그러나 익명의 피어 리뷰에는 몇 가지 단점이 있습니다.

• 익명은 두 가지 방법을 모두 차단합니다. 그것은 솔직한 리뷰를 장려하지만 일부 사람들은 부정직한 리뷰를 통해 의제를 홍보하기 위해 그것을 남용하도록 부추길 수 있습니다. 누군가가 자신의 익명을 사용하여 개인 취향에 따라 동료를 훼손할 위험이 있습니다. 반대로 익명성은 자격이 없는 사람들에게 긍정적인 리뷰를 제출하는 데 사용될 수 있습니다. 리뷰어가 다른 팀원을 희생시키면서 오랜 동료와 친구를 보호할 수 있기 때문입니다.
• 공개 리뷰는 더 많은 비중을 차지할 수 있습니다. 한 개인이 수십 명의 익명의 검토자 중 한 명으로부터 몇 줄의 부정적인 피드백을 받았다고 가정합니다. 피드백은 신뢰할 수 있고 존경받는 팀원으로부터 동일한 피드백을 받는 것만큼 영향력이 없을 가능성이 있습니다. 직원들은 가까운 사람의 피드백을 진지하게 받아들일 가능성이 훨씬 더 높습니다.
• 일부 조직, 즉 소규모 조직에서는 익명성을 보장하기 어려울 수 있습니다. 매일 함께 일하는 5명으로부터 총 4개의 리뷰를 받는 사람은 누가 어떤 리뷰를 제출했는지 알 수 있을 것입니다. 이로 인해 사람들이 리뷰를 익명이 아닌 것으로 취급하여 익명화의 요점을 무력화할 수 있습니다.
• 사람들이 공개 리뷰를 제출하도록 하는 것이 더 어려울 수 있지만 리뷰어는 이름이 첨부된 것을 알고 진지하게 받아들일 가능성이 더 큽니다. 따라서 검토 프로세스를 형식적으로 처리하기보다 상세하고 객관적이며 균형 잡힌 피드백을 제공하는 데 더 많은 시간을 할애할 수 있습니다.

자체 평가

자체 평가 또는 자체 평가는 성과 검토에서 일반적으로 사용되는 또 다른 접근 방식입니다. 다른 리뷰 모델과 마찬가지로, 그들은 자신의 논쟁을 제시할 수 있습니다.

자가 평가는 일반적으로 직원 관리에 의해 정기적으로 요구되며 목표가 시간 경과에 따른 진행 상황과 변경 사항을 추적하는 데 사용하는 것이라면 의미가 있습니다. 월별 평가를 의무화하는 조직은 거의 없지만 연간, 격년 및 분기별 자체 평가가 일반적입니다. 엔지니어에게 정기적으로 피드백을 제공하도록 요청하는 것은 특히 높은 수준의 자율성을 가지고 운영되는 팀 및 개인을 상대할 때 도움이 될 수 있습니다. 검토자는 이러한 정기 평가를 사용하여 해결해야 할 잠재적인 문제를 전달하고, 특정 문제를 극복한 방법을 설명하고, 성과를 개선한 방법과 이유를 자세히 설명하고, 성과 개선을 방해하는 요인을 식별할 수 있습니다.

자체 평가의 한계 완화

불행히도, 자가 평가는 몇 가지 심각한 결점을 가지고 있으며, 가장 명백한 것은 편향입니다. 어떤 사람들은 자신의 성과를 과장하거나, 업무의 결함을 밝히기를 거부하거나, 성과를 저해하는 문제를 나열할 가능성이 높습니다. 다른 사람들은 자신에 대해 너무 비판적일 수 있습니다. 두 경우 모두 결과가 왜곡될 수 있습니다.

조직은 어떻게 결점을 완화할 수 있습니까? 관리자는 편견을 설명하고 영향을 최소화하기 위해 자체 평가 양식과 질문을 설계할 수 있습니다.

• 너무 많은 주관성을 허용하는 개방형 질문을 피하십시오.
• 주관적인 목표와 가치보다는 가시적인 결과에 집중하세요.
• 검토자가 처리하는 중요한 책임에 더 높은 가치를 부여합니다.
• 핵심 성과 지표와 수량화 가능한 목표를 강조합니다.
• 조직의 핵심 가치를 반복하고 그에 따라 성과를 평가하십시오.

엔지니어가 자체 평가 양식에 포함되지 않은 문제를 해결할 수 있도록 의견 섹션을 제공하십시오..

360도 평가

360도 피드백 프로세스는 이전에 논의된 여러 모델을 결합하여 보다 광범위한 피드백을 제공하고 검토자의 강점과 약점을 식별합니다. 360도 시스템에서 직접적인 성과 리뷰, 동료 엔지니어(동료), 관리자, 클라이언트 및 기타 소스의 리뷰를 표로 작성하여 단일 결과를 생성하고 이해하기 쉬운 형식으로 검토자에게 제공합니다.

이 접근 방식은 여러 소스의 피드백을 보장하고 기본 성과 지표 및 기술 이상을 다루기 때문에 많은 시나리오에서 유용할 수 있습니다. 엔지니어의 성과에 대한 개요를 제공하여 경영진이 한 눈에 귀중한 통찰력을 얻을 수 있도록 합니다. 또한 조직이 모든 검토 결과를 각 직원과 공유하지 않기로 결정한 경우 대신 360도 피드백 결과를 공유할 수 있습니다.

이 접근 방식은 기본 팀 기술을 평가하고 엔지니어의 성과, 행동, 커뮤니케이션 및 기타 원하는 기준에 대한 팀 피드백을 제공합니다. 그러나 기술적 능력, 개별 프로젝트에 특정한 기술 또는 세부적인 성과 지표를 평가하는 데는 적합하지 않습니다. 일반적으로 다양한 배경과 검토 대상자의 참여 수준을 가진 많은 사람들이 참여하기 때문에 360도 피드백은 소프트웨어 엔지니어의 성과의 일부 측면을 평가하기에는 너무 주관적일 수 있습니다.

소프트웨어 엔지니어 성능 검토에 포함할 사항

이해관계자에게 가치를 창출하고 실행 가능한 정보를 제공하는 성과 검토에는 무엇이 포함되어야 합니까? 리뷰는 포괄적이어야 합니까, 아니면 가까운 시일 내에 작업할 몇 가지 항목에 초점을 맞춰야 합니까?

대답은 조직 유형과 검토 범위에 따라 다르지만 대부분의 성과 검토에는 일부 사항이 포함되어야 합니다.

속도와 반복

개발자가 작업을 완료하는 속도는 반복적인 소프트웨어 개발을 처리하는 방식과 마찬가지로 모든 성능 검토에서 필수적인 지표입니다. 단일 프로젝트에서 작업하는 대규모 팀, 한 프로젝트와 클라이언트에서 다른 프로젝트로 자주 이동하는 개인, 소방 작업을 처리할 때는 속도와 반복이 중요합니다. 실행에 착수하는 소프트웨어 엔지니어의 능력은 프로젝트를 성사시키거나 중단시킬 수 있습니다.

코드 품질 및 코드 검토

속도가 핵심 메트릭이지만 가격이 비싸면 가치가 떨어집니다. 코드의 품질은 가장 중요해야 하며 촉박한 마감일을 맞추기 위해 손상되어서는 안 됩니다. 품질이 낮은 코드는 나중에 나머지 팀이나 조직에 골칫거리가 될 수 있습니다.

코드 검토는 누군가가 다른 사람이 작성한 코드를 검토하도록 합니다. 시간이 많이 걸리기는 하지만 이 프로세스는 간단하고 품질을 보장하고 유지하는 좋은 방법입니다. 지속적인 코드 검토를 통해 조직은 개발자가 작성한 모든 코드 라인을 전체적으로 검토할 필요가 없습니다. 코드 검토자는 설계 및 기능에서 스타일 및 문서에 이르기까지 다양한 문제와 주의가 필요한 중요한 영역을 식별할 수 있는 고도로 숙련된 개인이어야 합니다.

내부 커뮤니케이션 및 책임

커뮤니케이션은 기술적인 기술이 아니지만 소프트웨어 엔지니어의 작업 품질에 큰 영향을 미칠 수 있습니다. 엔지니어는 동료, 팀 리더, 이해 관계자 및 고객과 정기적으로 의사 소통하며 높은 수준의 책임과 전문성을 보여야 합니다.

의사 소통이 원활하지 않으면 작업의 품질이 저하되고 사소한 문제가 더 크고 비용이 많이 드는 문제로 확대될 수 있습니다. 전문적이고 시기적절한 의사소통은 기본이며 검토를 받아야 합니다. 가장 인상적인 기술 기술도 책임을 지고 효과적으로 의사 소통해야 할 필요성만큼 중요하지 않습니다.

채용, 리더십 및 계획

선임 소프트웨어 엔지니어와 팀 리더는 종종 채용에서 중요한 역할을 하므로 이들의 성과 측면도 검토하는 것이 중요합니다. 팀장이 잘못된 채용 결정을 내리면 팀 전체와 조직 전체에 영향을 미칠 수 있습니다.

특히 팀 구성원이 부정적인 피드백을 제공하기를 꺼리는 경우 리더십을 측정하고 검토하기 어려울 수 있습니다. 따라서 검토 프로세스를 통해 상사에 대한 아첨하지 않는 평가에 대한 보복 가능성을 방지할 수 있도록 해야 합니다.

계획은 또 다른 주관적인 범주입니다. 리더는 팀 목표와 목표의 적절한 계획과 실행을 보장해야 합니다. 그러나 이러한 측면에서 그들의 성과는 부하직원과 상사 모두 다른 팀원들에게 달려 있습니다. 목표와 기한을 놓친 것은 명백한 위험 신호이지만 검토 프로세스는 프로젝트를 정상 궤도에 올리기 위해 시기적절한 조치를 취하지 못한 관리 부실, 필요한 시간이나 자원의 부족과 같이 이를 야기했을 수 있는 다양한 요인을 고려해야 합니다. 기한을 맞추다..

성과 검토는 쉽지 않습니다 - 더 어렵게 만들지 마십시오

각 조직은 특정 요구 사항에 맞는 성과 검토 모델을 만들어야 합니다. Google이나 Apple이 무언가를 하고 있다고 해서 반드시 다른 회사나 팀에서 작동하는 것은 아닙니다.

성능 검토에는 많은 계획과 신중한 고려가 필요합니다. 한편으로는 복잡성과 철저함, 다른 한편으로는 실용성과 유용성 사이에서 올바른 균형을 이루는 것이 필요합니다. 소규모 조직은 프로세스를 너무 복잡하고 어렵게 만들지 않고 성과 검토를 수행할 수 있습니다. 마찬가지로, 큰 조직은 프로세스를 최대한 간결하게 만들기 위해 최선을 다해야 합니다.

검토 프로세스 자체를 검토하는 것을 잊지 마십시오. 분기별 또는 연간 기준으로 검토를 수행하는지 여부에 관계없이 다음 검토를 진행하기 전에 가장 최근의 검토를 검토하십시오. 절차가 순조롭게 진행되었습니까? 유용한 정보를 찾았습니까? 미흡한 점을 파악하고 보완하며 지속적으로 검토 프로세스를 개선하기 위해 노력합니다.