IT 프로젝트에서 팀의 워크플로 구성

안녕하세요 친구. 특히 아웃소싱 분야에서는 같은 상황이 자주 발생합니다. 다양한 프로젝트에서 팀의 명확한 작업 흐름이 부족합니다.

가장 중요한 것은 프로그래머가 고객과 서로 소통하는 방법을 이해하지 못한다는 것입니다. 고품질 제품을 개발하기 위한 지속적인 프로세스를 구축하는 방법. 근무일과 스프린트를 계획하는 방법.

그리고 이 모든 것은 궁극적으로 마감 기한을 놓치고, 초과 근무를 하고, 누가 책임을 져야 하는지에 대한 끊임없는 대결, 그리고 모든 것이 어디에서 어떻게 진행되는지에 대한 고객 불만으로 이어집니다. 이 모든 것이 프로그래머 또는 전체 팀의 변경으로 이어지는 경우가 많습니다. 고객 상실, 명예 훼손 등

한때 저는 이러한 모든 즐거움이 있는 그런 프로젝트에 참여하게 되었습니다.

아무도 프로젝트(대규모 서비스 시장)에 대한 책임을 지고 싶어하지 않았고 매출도 형편없었으며 고객은 단순히 찢어지고 좌절했습니다. 한번은 CEO가 나에게 와서 필요한 경험이 있다고 말했으므로 여기 카드가 있습니다. 프로젝트를 직접 맡아보세요. 만약 당신이 망치면 우리는 프로젝트를 종료하고 모두를 쫓아낼 것입니다. 그것은 잘 될 것이고, 멋질 것이고, 당신이 적절하다고 생각하는 대로 이끌고 발전할 것입니다. 그 결과 나는 프로젝트의 팀장이 되었고 모든 것이 내 어깨에 떨어졌습니다.

제가 가장 먼저 한 일은 당시 제 비전에 맞는 워크플로를 처음부터 개발하고 팀을 위한 업무 설명을 작성하는 것이었습니다. 그것을 구현하는 것은 쉽지 않았습니다. 하지만 한 달 정도 지나면 모든 것이 안정되고 개발자와 클라이언트도 익숙해졌고 모든 것이 조용하고 편안하게 진행되었습니다. 이것이 단순한 '찻잔 속의 폭풍'이 아니라 상황에서 벗어나는 실제적인 방법임을 팀에게 보여주기 위해 나는 최대한의 책임을 맡아 팀에서 불쾌한 루틴을 제거했습니다.

벌써 XNUMX년 반이 지났고, 프로젝트는 초과근무 없이, "쥐 경주"나 온갖 스트레스 없이 발전하고 있습니다. 예전 팀에 있던 몇몇 사람들은 그런 식으로 일하기 싫어서 떠나기도 했고, 반대로 투명한 규칙이 생겨서 매우 기뻐하는 사람들도 있었습니다. 그러나 결국 팀의 모든 구성원은 매우 의욕이 넘치고 프런트엔드와 백엔드를 모두 포함하여 거대한 프로젝트를 완전히 알고 있습니다. 코드 베이스와 모든 비즈니스 로직을 모두 포함합니다. 심지어 우리는 단순한 "노젓는 사람"이 아니라 우리 자신이 비즈니스에서 좋아할 만한 많은 비즈니스 프로세스와 새로운 기능을 생각해내는 수준까지 이르렀습니다.

우리 측의 이러한 접근 방식 덕분에 고객은 우리 회사에 또 다른 마켓플레이스를 주문하기로 결정했습니다. 이는 좋은 소식입니다.

이것이 내 프로젝트에서 작동하므로 누군가에게도 도움이 될 것입니다. 따라서 프로젝트를 저장하는 데 도움이 된 프로세스 자체는 다음과 같습니다.

“My Favorite Project” 프로젝트의 팀워크 과정

a) 내부 팀 프로세스(개발자 간)

• 모든 이슈는 Jira 시스템에서 생성됩니다.
• 각 작업은 가능한 한 많이 설명되어야 하며 엄격하게 하나의 작업만 수행해야 합니다.
• 모든 기능이 충분히 복잡하다면 여러 개의 작은 작업으로 나누어집니다.
• 팀은 기능을 단일 작업으로 작업합니다. 먼저, 우리 모두는 하나의 기능에 대해 함께 작업하고 테스트를 위해 보낸 후 다음 기능을 수행합니다.
• 각 작업은 백엔드 또는 프런트엔드에 대해 표시됩니다.
• 작업 유형과 버그가 있습니다. 정확하게 표시해야 합니다.
• 작업 완료 후 코드 검토 상태로 전환됩니다. (이 경우 동료를 위해 풀 요청이 생성됩니다.)
• 작업을 완료한 사람은 즉시 이 작업에 대한 시간을 추적합니다.
• 코드를 확인한 후 PR이 승인하고 그 후 이 작업을 수행한 사람이 독립적으로 이를 마스터 브랜치에 병합한 후 상태를 개발 서버에 배포 준비 완료로 변경합니다.
• 개발 서버에 배포할 준비가 된 모든 작업은 팀 리더(책임 영역)에 의해 배포되며, 긴급한 경우 팀 구성원이 배포하는 경우도 있습니다. 배포 후 배포 준비 완료부터 개발까지 모든 작업이 개발에서 테스트 준비 완료 상태로 전환됩니다.
• 모든 작업은 고객이 테스트합니다.
• 고객이 개발팀에서 작업을 테스트한 후 프로덕션 배포 준비 상태로 전환합니다.
• 프로덕션 배포를 위해 배포하기 전에만 마스터를 병합하는 별도의 분기가 있습니다.
• 테스트 중에 고객이 버그를 발견하면 수정을 위해 작업을 반환하고 상태를 수정을 위해 반환됨으로 설정합니다. 이런 방식으로 테스트를 통과하지 못한 작업과 새 작업을 분리합니다.
• 결과적으로 모든 작업은 생성에서 완료까지 진행됩니다. To Do → 개발 중 → 코드 검토 → 개발 배포 준비 완료 → 개발 QA → (개발로 반환) → 프로덕션 배포 준비 완료 → 프로덕션 QA → 완료
• 각 개발자는 사이트 사용자를 포함하여 독립적으로 자신의 코드를 테스트합니다. 코드가 작동하는지 확실하게 알려지지 않은 한 분기를 기본 분기에 병합하는 것은 허용되지 않습니다.
• 모든 작업에는 우선순위가 있습니다. 우선순위는 고객이나 팀 리더가 설정합니다.
• 개발자는 우선순위 작업을 먼저 완료합니다.
• 시스템에서 서로 다른 버그가 발견되거나 하나의 작업이 여러 전문가의 작업으로 구성된 경우 개발자는 서로 작업을 할당할 수 있습니다.
• 고객이 생성한 모든 작업은 팀 리더에게 전달되며 팀 리더는 이를 평가하고 고객에게 수정을 요청하거나 팀 구성원 중 한 명에게 할당합니다.
• 개발 또는 프로덕션 배포 준비가 완료된 모든 작업은 배포 수행 시기와 방법을 독립적으로 결정하는 팀 리더에게 전달됩니다. 각 배포 후에 팀 리더(또는 팀 구성원)는 이에 대해 고객에게 알려야 합니다. 또한 작업 상태를 개발/계속 테스트 준비로 변경합니다.
• 매일 같은 시간(저희 경우는 12.00시)에 전 팀원 간 회의를 진행합니다.
• 팀장을 포함하여 회의에 참석한 모든 사람은 어제 무엇을 했고, 오늘 무엇을 할 계획인지 보고합니다. 작동하지 않는 것과 그 이유. 이렇게 하면 팀 전체가 누가 무엇을 하고 있는지, 프로젝트가 어느 단계에 있는지 알 수 있습니다. 이를 통해 우리는 필요한 경우 추정치와 기한을 예측하고 조정할 수 있습니다.
• 회의에서 팀장은 프로젝트의 모든 변경 사항과 고객이 발견하지 못한 현재 버그 수준에 대해서도 이야기합니다. 모든 버그는 분류되어 각 팀원에게 할당되어 해결됩니다.
• 회의에서 팀 리더는 개발자의 현재 작업량, 전문 교육 수준을 고려하고 특정 작업과 개발자가 현재 수행 중인 작업의 근접성을 고려하여 각 사람에게 작업을 할당합니다.
• 회의에서 팀 리더는 아키텍처 및 비즈니스 로직에 대한 일반적인 전략을 개발합니다. 그 후 전체 팀이 이에 대해 논의하고 이 전략을 조정하거나 채택하기로 결정합니다.
• 각 개발자는 단일 아키텍처 및 비즈니스 로직의 프레임워크 내에서 독립적으로 코드를 작성하고 알고리즘을 구축합니다. 누구나 자신의 구현 비전을 표현할 수 있지만, 누구도 이런 식으로 하도록 강요하지 않습니다. 모든 결정은 정당합니다. 더 나은 솔루션이 있지만 지금은 그럴 시간이 없다면 코드의 특정 부분에 대한 향후 리팩토링을 위해 작업이 생성됩니다.
• 개발자가 작업을 맡으면 해당 작업을 개발 상태로 전환합니다. 고객과의 작업 명확화와 관련된 모든 의사 소통은 개발자의 책임입니다. 기술적인 질문은 팀 리더나 동료에게 물어볼 수 있습니다.
• 개발자가 작업의 본질을 이해하지 못하고 고객이 이를 명확하게 설명할 수 없는 경우 다음 작업으로 진행됩니다. 그리고 팀장은 현재의 것을 가지고 고객과 논의합니다.
• 매일 개발자는 클라이언트 채팅에 어제 작업한 작업과 오늘 작업할 작업에 대해 작성해야 합니다.
• 작업과정은 Scrum에 따라 진행됩니다. 모든 것이 스프린트로 나뉩니다. 각 스프린트는 XNUMX주 동안 지속됩니다.
• 스프린트는 팀 리더가 생성하고 채우고 종료합니다.
• 프로젝트의 마감 기한이 엄격한 경우 모든 작업을 대략적으로 추정하려고 노력합니다. 그리고 우리는 그것들을 스프린트로 합쳤습니다. 고객이 스프린트에 더 많은 작업을 추가하려고 하면 우선 순위를 설정하고 일부 다른 작업을 다음 스프린트로 이전합니다.

b) 고객과 협력하는 과정

• 모든 개발자는 고객과 소통할 수 있고 또 그래야 합니다.
• 고객은 자신만의 게임 규칙을 강요할 수 없습니다. 우리가 해당 분야의 전문가임을 정중하고 친근하게 고객에게 분명히 하는 것이 필요하며, 오직 우리만이 업무 프로세스를 구축하고 이에 고객을 참여시켜야 합니다.
• 이상적으로는 기능 구현을 시작하기 전에 해당 기능(워크플로)에 대한 전체 논리적 프로세스의 흐름도를 만드는 것이 필요합니다. 그리고 확인을 위해 고객에게 보냅니다. 이는 결제 시스템, 알림 시스템 등과 같이 복잡하고 명확하지 않은 기능에만 적용됩니다. 이를 통해 우리는 고객이 원하는 것이 정확히 무엇인지 더 정확하게 이해하고, 해당 기능에 대한 문서를 저장하고, 고객이 나중에 우리가 요청한 것을 수행하지 않았다고 말할 수 있다는 사실에 대비할 수 있습니다.
• 모든 다이어그램/플로우차트/로직 등 우리는 이를 Confluence/Fat에 저장하고 고객에게 댓글에서 향후 구현의 정확성을 확인하도록 요청합니다.
• 우리는 기술적인 세부 사항으로 고객에게 부담을 주지 않으려고 노력합니다. 고객이 원하는 방식에 대한 이해가 필요한 경우 고객이 직접 모든 것을 이해하고 수정/수정할 수 있는 순서도 형태로 원시적인 알고리즘을 도출합니다.
• 고객이 프로젝트에서 버그를 발견하면 Zhira에서 해당 버그에 대해 자세히 설명해달라고 요청합니다. 어떤 상황에서, 언제, 테스트 중에 고객이 어떤 일련의 작업을 수행했는지. 스크린샷을 첨부해주세요.
• 우리는 매일, 최대 격일로 개발 서버에 배포하려고 시도합니다. 그런 다음 고객은 기능 테스트를 시작하고 프로젝트는 유휴 상태가 아닙니다. 동시에 이는 프로젝트가 완전히 개발 중이며 아무도 그에게 동화를 말하지 않는다는 것을 고객에게 표시합니다.
• 고객이 자신에게 필요한 것이 무엇인지 완전히 이해하지 못하는 경우가 종종 있습니다. 아직 확립되지 않은 프로세스로 스스로 새로운 비즈니스를 창출하고 있기 때문입니다. 따라서 매우 일반적인 상황은 전체 코드 조각을 휴지통에 버리고 애플리케이션 로직을 다시 설계하는 것입니다. 따라서 테스트로 모든 것을 절대적으로 다루어서는 안 됩니다. 테스트를 통해 중요한 기능만 다룬 다음 예약을 통해서만 다루는 것이 합리적입니다.
• 우리가 마감일을 지키지 못한다는 것을 팀이 깨닫는 상황이 있습니다. 그런 다음 작업에 대한 빠른 감사를 수행하고 즉시 고객에게 이를 알립니다. 상황을 벗어나는 방법으로 중요하고 중요한 기능을 제때에 출시하고 나머지는 출시 이후에 남겨 두는 것이 좋습니다.
• 고객이 머릿속에서 다양한 작업을 생각해 내기 시작하고 상상하고 손가락으로 설명하기 시작하면 우리는 전체 레이아웃의 동작을 완전히 설명하는 논리가 포함된 페이지 레이아웃과 흐름을 제공하도록 요청합니다. 그 요소.
• 어떤 작업을 수행하기 전에 이 기능이 계약 조건에 포함되어 있는지 확인해야 합니다. 이것이 초기 계약을 넘어서는 새로운 기능인 경우, 우리는 이 기능의 가격을 책정하고((예상 완료 시간 + 30%) x 2) 이를 완료하는 데 이만큼의 시간이 소요될 것임을 고객에게 알려야 합니다. 마감일은 예상 시간에 XNUMX를 곱하여 변경됩니다. 작업을 더 빠르게 수행해 보겠습니다. 좋습니다. 모두가 혜택을 누릴 수 있습니다. 그렇지 않다면 우리가 도와드리겠습니다.

c) 팀에서 허용되지 않는 것:

• 헌신하지 않음, 평정심 부족, 건망증
• “아침 먹이기.” 작업을 완료할 수 없고 방법을 모르는 경우 즉시 팀 리더에게 알리고 마지막 순간까지 기다리지 않아야 합니다.
• 아직 자신의 능력과 전문성이 입증되지 않은 사람을 눈여겨보고 자랑합니다. 입증된 경우 품위 있는 범위 내에서 가능합니다 :)
• 모든 형태의 속임수. 작업이 완료되지 않은 경우 상태를 완료로 변경하지 말고 클라이언트 채팅에 준비가 되었다고 기록하면 안 됩니다. 컴퓨터가 고장나고, 시스템이 충돌하고, 개가 노트북을 씹었습니다. 이 모든 것은 용납될 수 없습니다. 실제 불가항력 사건이 발생하는 경우 팀 리더에게 즉시 알려야 합니다.
• 전문가가 항상 오프라인 상태이고 근무 시간 중에 연락하기 어려운 경우.
• 팀 내 독성은 허용되지 않습니다! 누군가 동의하지 않는 일이 있으면 모두가 모여 집회를 열고 토론하고 결정합니다.

그리고 모든 오해를 풀기 위해 가끔 고객에게 묻는 몇 가지 질문/논문은 다음과 같습니다.

1. 귀하의 품질 기준은 무엇입니까?
2. 프로젝트에 문제가 있는지 여부를 어떻게 판단합니까?
3. 시스템 변경/개선에 대한 당사의 모든 권장 사항 및 조언을 위반함으로써 모든 위험은 귀하에게만 부담됩니다.
4. 프로젝트에 대한 주요 변경 사항(예: 모든 종류의 추가 흐름)은 버그가 나타날 수 있는 가능성이 있습니다(물론 수정하겠습니다).
5. 프로젝트에서 어떤 종류의 문제가 발생했는지 몇 분 안에 이해하는 것은 불가능하며, 즉시 해결하는 것은 더더욱 불가능합니다.
6. 우리는 특정 제품 흐름(Zhira의 작업 - 개발 - 테스트 - 배포)에 대해 작업합니다. 이는 채팅의 전체 요청 및 불만 흐름에 응답할 수 없음을 의미합니다.
7. 프로그래머는 전문 테스터가 아닌 프로그래머이므로 프로젝트 테스트의 적절한 품질을 보장할 수 없습니다.
8. 생산 작업의 최종 테스트 및 승인에 대한 책임은 전적으로 귀하에게 있습니다.
9. 이미 작업을 수행한 경우 현재 작업을 완료할 때까지 다른 작업으로 즉시 전환할 수 없습니다. 그렇지 않으면 버그가 더 많아지고 개발 시간이 늘어납니다.
10. (휴가 또는 질병으로 인해) 팀 구성원 수는 적지만, 할 일이 더 많아지고 물리적으로 귀하가 원하는 모든 것에 응답할 시간이 없습니다.
11. 개발팀에서 테스트된 작업 없이 프로덕션에 배포하도록 요청합니다. 이는 개발자가 아닌 귀하의 위험일 뿐입니다.
12. 귀하가 불분명한 작업, 올바른 흐름, 디자인 레이아웃 없이 설정하는 경우 귀하를 대신해 저희가 추가 작업을 수행해야 하기 때문에 훨씬 더 많은 노력과 구현 시간이 필요합니다.
13. 발생에 대한 자세한 설명과 스크린샷이 없는 버그에 대한 작업은 무엇이 잘못되었는지, 이 버그를 어떻게 수정할 수 있는지 이해할 수 있는 기회를 제공하지 않습니다.
14. 이 프로젝트는 성능과 안전성을 향상시키기 위해 지속적인 개선과 개선이 필요합니다. 따라서 팀은 이러한 개선에 시간의 일부를 소비합니다.
15. 시간당 초과 근무(긴급 수정)가 있기 때문에 다른 날에 보상해야 합니다.

일반적으로 고객은 소프트웨어 개발에서 모든 것이 그렇게 간단하지 않으며 욕구만으로는 충분하지 않다는 것을 즉시 이해합니다.

일반적으로 그게 전부입니다. 많은 협상과 모든 프로세스의 초기 디버깅을 뒤에 남겨두었지만 결과적으로 모든 것이 잘 진행되었습니다. 이 과정이 우리에게 일종의 '은탄'이 됐다고 할 수 있다. 프로젝트에 온 새로운 사람들은 모든 프로세스가 설명되어 있고 다이어그램 형태의 문서 및 아키텍처가 우리 모두가 여기서 무엇을 하고 있는지에 대한 아이디어를 즉시 제공했기 때문에 첫날부터 즉시 작업에 참여할 수 있었습니다.

추신: 우리 측에는 프로젝트 관리자가 없다는 점을 분명히 하고 싶습니다. 고객의 편입니다. 전혀 기술자가 아닙니다. 유럽 ​​프로젝트. 모든 의사소통은 영어로만 이루어집니다.

프로젝트에 참여하는 모든 사람에게 행운을 빕니다. 지치지 말고 프로세스를 개선하려고 노력하십시오.

내 소스 블로그.

출처 : habr.com