워크플로우 단순화: "플랫" 스타일 프로젝트 관리 가이드

평면 조직이 더욱 인기를 얻으면서 이와 관련된 방법과 과정도 함께 주목받고 있습니다. 이 블로그는 평면 조직 구조 자체가 아니라 프로젝트 관리 영역 내에서 평면 조직이 어떻게 기능하는지에 대해 논의합니다. 평면 조직에서 배운 프로젝트 관리 원칙은 가장 평면적인 회사에서 가장 계층적으로 구조화된 조직에 이르기까지 채택될 수 있습니다.

“평면적”이 되는 것이 유행이지만 왜 해야 할까요?

“왜 평면 프로젝트 관리에 관심을 가져야 하나요?”라는 질문을 할 수 있습니다. 프로젝트 관리자에게 답은 간단합니다: 덜 위임하고, 상태를 덜 확인하며, 덜 감독합니다. 이는 당신이 좋아하는 일에 더 많은 시간을 할애할 수 있음을 의미합니다... 만약 당신이 정말로 작업 지시를 즐긴다면(그런 경우라면 여기서 읽기를 멈춰야 합니다). 관리되는 사람에게도 마찬가지로 명확합니다: 왜 누군가가 계속해서 당신의 상태를 캐묻고 “어떻게 일을 올바르게 해야 하는지” 조언해야만 할까요? 다시 말하지만, 만약 당신이 그런 것을 정말로 좋아한다면 이 스타일이 당신에게 맞지 않을 수 있습니다. 여기서의 아이디어는 관리자가 덜 관리를 필요로 하고 모두가 자신의 일을 원하는 대로 할 수 있는 자율성과 자유를 가지며 괴롭힘을 받지 않는 것입니다.

전제 조건

프로세스를 시작하기 전에 이것을 실제로 작동시키기 위한 세 가지 주요 전제 조건이 있습니다: 신뢰, 투명성, 그리고 소통.

여기

그림 1. 신뢰, 투명성, 소통

신뢰: 서로를 신뢰하는 것은 성공적인 평면 프로젝트 구조의 핵심입니다

투명성: 모두가 자신이 무엇을 하고 있는지 완전히 투명하게 공개할 필요가 있습니다. 이는 다음과 같은 매체를 통해 자신의 작업을 소통함으로써 이루어질 수 있습니다:

1. 코드 커밋
2. 위키 페이지
3. 이슈 추적 시스템
4. 에스프레소 머신 (즉, 새로운 물 냉각기)

소통: 모두가 서로와 소통할 수 있는 능력을 가져야 하며, 그렇게 할 것을 권장받아야 합니다.

신뢰가 있을 때 투명성이 있습니다. 투명성이 있을 때 사람들은 안전하다고 느끼기 시작합니다. 사람들이 안전하다고 느끼고 자신의 작업에 대해 개방적이게 될 때 권장될 때, 소통은 자연스럽게 일어납니다.

구현

이제 우리는 전제 조건을 다루었으니 평면 프로젝트 관리의 구현에 대해 논의할 수 있습니다.

프로젝트 리더: "하지만 평등한 구조에서는 아무도 상사가 없다고 생각했어요?" 명령과 통제에 꼭 필요한 사람은 없지만, 촉진자가 있어야 한다는 것이 중요합니다. 프로젝트 리더를 모두가 같은 박자로 연주하도록 보장하는 지휘자로 생각하세요.

분명한 목표와 목적: 프로젝트 목표는 프로젝트 시작부터 명확하게 전달되어야 합니다. "우리의 목표는 무엇인가요? 우리가 달성하려는 것은 무엇인가요? 이 위젯을 누가 원하나요?"와 같은 질문은 정의되어야 하며, 위키 공간이 그러한 목적을 정의하기에 완벽한 장소입니다.

요구 사항 및 책임: 프로젝트 리더든 마케팅이든, 요구 사항은 문서화되어야 하며, 그렇지 않으면 평면적 프로젝트 관리 스타일에서 혼돈이 발생할 수 있습니다. 명확한 방향이 없으면 "보스"가 쉽게 들어와 정상적인 환경에서 조각을 주워 담을 수 있습니다. 평면적 환경에서는 명확하게 정의된 요구 사항이 없으면 사람들이 쉽게 길을 잃을 수 있습니다. Jira와 같은 문제 추적 시스템에서 이러한 요구 사항은 작업 또는 스토리로 기록될 수 있습니다. 표준 관행은 프로젝트 리더가 개인에게 작업을 할당하는 것입니다. 평평한 작업 환경에서는 할당되지 않은 작업 목록이 팀에 제시되어 팀원들이 스스로(또는 다른 사람에게) 이 작업을 할당할 수 있습니다. 이 시스템(즉, 모든 작업이 제시된 시스템)은 공유 Excel 워크시트만큼 간단하거나 Kanban 보드만큼 힙할 수 있습니다. 이것이 설정되면 누구나 보스가 아니어도 전체 프로젝트의 상태를 볼 수 있고 추적할 수 있습니다.

중앙 집중식 설계 저장소: 중앙 집중식 설계 저장소는 이러한 스타일의 프로젝트 관리를 생성하고 유지하는 데 핵심입니다. 각 팀원의 설계를 “상사”에게 지속적으로 보고하거나 집계하는 일은 없습니다. 사람들이 서로의 작업을 볼 수 없다면, 검사와 균형이 이루어지지 않습니다. 각 팀원은 다른 팀원을 위한 검사자입니다. 소프트웨어 세계에서, 이는 풀 리퀘스트를 생성하고 동료들이 코드 리뷰를 통해 당신의 작업을 검사하게 함으로써 공식적으로 이루어집니다(상사가 관문 역할을 하는 것과 대비됩니다). 회로도 캡처나 레이아웃에서도 비슷한 과정을 통해 이를 달성할 수 있습니다. 이 블로그는 설계를 Git 저장소에 커밋하는 것(즉, 새로운 “SVN” 또는 “CVS”)에 대해 논의합니다. 이 경우, 소프트웨어 엔지니어링 관행을 따라 개발 브랜치에 커밋한 다음 풀 리퀘스트를 발행하게 됩니다. 이 주제에 대한 자세한 정보는 Atlassian의 Git 튜토리얼에서 풀 리퀘스트 만드는 방법을 참조할 수 있습니다.

예시: 임베디드 시스템 위젯

이 예에서는 임베디드 시스템 위젯을 구성하는 다양한 요구 사항이 포함된 작은 프로젝트를 설정했음을 볼 수 있습니다. 이 경우 프로젝트는 "Blinky LED" 보드를 구축하기 위한 요구 사항을 포함하는 Epic입니다.

그림 2. “Fancy Blinky LED PCB”를 구축하기 위한 설계 요구 사항이 포함된 Epic

이 프로젝트 공간에는 각각의 구성 요소가 구성 요소 리드에 할당된 기계, 전기, 소프트웨어 "구성 요소"가 있습니다.

그림 3. 프로젝트의 모든 구성 요소와 구성 요소 리드에 대한 뷰

그림 4. 여러 구성 요소를 포함하는 작업의 예

전기는 Altium을 사용하여 코드를 Git 서버(Bitbucket인 경우)로 푸시합니다.

그림 5. 회로도 설계의 Git 커밋

소프트웨어 및 기계 엔지니어도 마찬가지입니다. 이 특정 프로젝트에는 세 명의 팀 멤버만 있지만, 구성 요소 리드(즉, 프로젝트의 그 부분에 대해 책임을 지는 사람)가 있는 한 무수히 많은 팀 멤버를 포함할 수 있습니다.

이 위키 공간은 제품 개념, 구현 또는 검증 단계에 참여하는 모든 사용자 간의 대화가 발생할 수 있도록 합니다.

그림 6. 제품에 대한 정보(작업 포함)가 담긴 위키 페이지

스프레드시트, 작업 목록, 위키 페이지, 이메일 스트림 등이든, 프로젝트 촉진자와 팀 나머지 구성원이 프로젝트 내에서 일어나는 모든 것을 볼 수 있는 능력을 갖추는 것이 중요합니다. 이를 통해 모든 사람이 서로에 의해 책임을 지게 되며 단일 관리자에 의해 책임지는 것이 아닙니다. 우리 회사 내에서는 칸반 보드가 프로젝트 활동을 시각화하는 가장 좋은 방법이라는 것을 발견했습니다.

그림 7. 예제 프로젝트의 작업이 담긴 칸반 보드

마지막으로, 팀 구성원이 문제를 발견하면 주저하지 않고 다른 팀원에게 작업을 생성하고 할당할 수 있는 권한을 느껴야 합니다. 버그를 발견했거나 소프트웨어 구현을 지원하기 위해 추가 하드웨어가 필요한 경우에 상관없이, 그들은 주도적으로 요청을 시작하고 상향식이 아닌 수평적으로 진행할 수 있는 편안함을 느껴야 합니다.

결론

마이크로매니지먼트는 이제 구식이 되었습니다. 프로젝트를 상하 구조가 아닌 평면적으로 관리하는 것이 유행이 되었을 뿐만 아니라 모두에게 압박을 줄여줍니다. 프로젝트 매니저는 상태 추적에 덜 집중하고 디자이너는 그러한 상태 보고서를 생성하는 데 덜 시간을 소비합니다. 이 글은 프로젝트 관리에 평면적 접근 방식의 원칙과 그 구현이 어떤 모습인지를 설명했습니다. 전체 기업 구조를 평탄화할 필요는 없으며, 위에서 언급한 원칙들을 채택하고 바로 시작하기만 하면 됩니다.

다음 PCB 디자인에서 Altium이 어떻게 도움을 줄 수 있는지 더 알고 싶으신가요? Altium의 전문가와 상담하세요 또는 Altium Designer의 포괄적인 부품 라이브러리가 디자인 및 시뮬레이션 도구와 직접 연동되어 필요한 기능을 갖춘 임베디드 시스템을 쉽게 설계할 수 있는 방법에 대해 계속 읽어보세요.

팀을 이루고 절약하세요

새로운 Altium Designer^® 좌석을 추가할 때특별 할인을 받으세요