팀의 프로세스를 통제 할 수 없습니까?

저는 소프트웨어 개발 팀의 리더 (최근에 새로운 팀을 통제했습니다)이며 궁극적으로 높은 생산성, 우수한 품질 및 체계적인 우선 순위를 유지해야합니다.

팀에 6 명의 선임 개발자가 있지만 여기서는 혼란스러워합니다. 상황은 회사의 약 10 개의 서로 다른 접점에서 JIRA 요청을 처리해야하며 모두 서로 다른 비즈니스 단위 또는 고객을 나타냅니다.

내가 가진 문제는 내 일이 주로 하루 종일 불을 피우고 모든 사람의 문제가 해결되도록하는 것입니다. 불행히도, 우리 회사의 문화는 높은 생산성 (빠른 릴리스)이지만 낮은 품질 (제작 버그)이었으며 고객은 갑작스러운 결과 지연을 수용하지 않습니다.

이것을 처리하는 좋은 방법은 무엇입니까? 나는 많은 이론을 가지고 있지만 실제로 내 상황에서 일한 경험이있는 사람의 대답을 찾고 있습니다.

다음은 작동 방식에 대한 작은 목록입니다.

• 각 개발자는 해당 응용 프로그램과 상호 작용하는 특정 응용 프로그램 및 서비스를 담당합니다.
• 릴리스는 일반적으로 클라이언트가 시뮬레이트 된 프로덕션 서버에서 테스트 한 다음 라이브 서버에 배포합니다.
• 각 응용 프로그램은 평균 50-80 명이 사용하며 총 8 개의 응용 프로그램이 사용됩니다.

감사

고객이 결과가 갑자기 지연되지 않습니다

음, 그들은 그들이 얻는 열악한 품질을 받아 들여야합니다.

당신이 이 (! 또는 기타 생산) : 일을 서두르는 것은 품질에 영향을 미친다는 것을이를 변경하기 위해해야 할 것은 소프트웨어 개발의 현실을 허용하도록 클라이언트를 얻을 수있다.

잘못되고있는 것들, 깨진 것들, 그들이 불평했던 시간들에 대한 큰 목록을 만드십시오. 그들에게 이러한 문제의 이유를 설명하고 그 변화를 위해 무엇을하고 싶은지 이야기하십시오. 팀이 실시간 응용 프로그램을 지원하고 수정하는 데 소요 한 시간의 백분율을 설명하십시오. 그에 대한 데이터를 수집하지 않는 경우 지금 시작해야합니다 (고객에게 정보를 제공하기 전에 한 달 동안 수집하십시오).

한 방에있는 주요 이해 당사자들에게 "X를 고정 시키길 원합니까 , 아니면 Y를 전달하길 원하십니까? 둘 중 하나의 시간 만 있습니다"라고 말합니다. 확인 그들을 우선 순위를 설정하기위한 책임 및 용량을 제한 한 것을 취소한다. 그들이 새로운 것을 요구한다면, 그것을 달성하기 위해 현재 로드맵에서 무엇을 기꺼이 희생 할 것인지 물어보십시오.

팀에게 "문제를 올바르게 처리"하는 데 필요한 시간과 리소스를 문의하십시오 (기본 버그 수정 및 코드 품질 / 아키텍처 등의 더 큰 문제 해결 측면에서). 이해 관계자가 우선시해야 할 사항 목록에 해당 항목을 포함하십시오.

내가 현재 직장에서 한 가장 좋은 일은 한 방에 동시에 상위 8 명의 이해 관계자를 확보하고 요청 된 새로운 기능을 나타내는 16 개의 색인 카드 더미를 배치하는 것이 었습니다. 나는 테이블에서 물러서서 말했다. "한 번에 하나를 전달할 수 있습니다. 어떤 순서로 주문 하시겠습니까?" 중간에 갇히지 않고 비즈니스 우선 순위에 대해 서로 토론 하게하십시오.

멈추고 떨어 뜨리고 굴립니다. 화재에는 연료가 필요하며 종종 공황 형태로 나타납니다. 자신과 팀을 순서대로 관리 할 수있는 시간을 마련하십시오. 개발자를 평가하고 숙련되지 않았거나 원하는 결과를 얻을 수있을만큼 열심히 노력하지 않는 것이 있는지 확인하십시오. 누가 약간 머물 필요가 있고 나머지는 가야하는지 결정합니다. 프로그래머가 업무를 수행 할 수 있도록 지원 및 도구를 평가하십시오. 사운드 테스트, 검토, 소스 제어 및 문서를 준수해야합니다. 좋은 도구를 가진 좋은 사람들은 좋은 일을하기 위해 책임을 져야합니다.

팀이해야 할 일, 현재 진행중인 작업 및 완료시기를 알 수있는 시스템이 있어야합니다. 이를위한 많은 방법론, 이론, 소프트웨어, 드라이 지우기 보드 및 스티커 메모, 문서 및 이메일. 모든 사람이 그것에 충실하게하여 무언가를 만드십시오. 모든 사람이 시스템에 어떤 정보를 가지고 있다면 그것을 따르는 것이 더 동기 부여가됩니다.

고객이 기대하는 것을 더 잘 이해하십시오. 이것은 당신의 일의 일부가 아닐 수도 있습니다. 머리카락에 불이 붙은 척하고 고객이 불행하고 하늘이 떨어지는 척하는 다른 개인이있을 수 있습니다. 그것은 그들이하는 일이고 일부는 정말 잘합니다. 모든 것이 비상 사태라면 모든 것이 끝나지 않기 때문에 비상 사태가 아닙니다. 고객 occassionaly와의 토론에 참여하도록 제안하십시오. 그들이 개발 팀에 도착할 때마다 많은 '좋은 것'이 '거래 차단기'로 바뀌는 것을 알 수 있습니다. 기술 연락 담당자 나 다른 변명으로 도와주십시오. 유지할 수없는 약속을하는 것은 그들이 먼저 듣고 싶지 않은 것을 말하는 것보다 더 나쁩니다. 우리는 좋은 일을하고 싶어서 5 주가 아닌 8 주가 필요합니다. 그들은 장기적으로 더 행복 할 것입니다.

궁극적으로 고객에게 소프트웨어 개발에 대해 교육하고 프로세스에 최대한 참여시켜야합니다. 그들이 지금보고있는 것은 새로운 기능의 빠른 제공과 소프트웨어의 버그입니다. 그들은 전자에 만족하지만 후자는 행복하지 않을 것이다.

더 나은 프로세스를 사용하면 새로운 소프트웨어의 제공이 약간 지연되고 버그는 줄어든다는 점을 설명해야합니다 (제로가 없을 것입니다). 이것이 앞으로 나아갈 것이라는 합의를 얻을 수 있다면 개발에 대한 통제력을 다시 얻는 데 필요한 프로세스를 도입 할 수 있습니다.

애자일 프로세스를 사용하면 고객이 팀의 일부로 포함됨을 제안 (및 일부 구현 의무) 할 때 도움이 될 수 있습니다. 고객을 매우 밀접하게 참여 시키면 고객은 무엇이 효과적이고 직접 생산할 수 있는지 볼 수 있습니다.

나의 (제한된 경험) 의견 : 해결해야 할 두 가지 문제가 있다고 생각합니다. 첫째, 품질 과정. 스크럼 / 폭포 / 무엇을 사이에 사용하십니까? 스크럼에서 각 스토리에 대해 추가 작업을 추가 할 수 있습니다.

다른 문제는 소프트웨어의 모든 곳에 존재하는 대규모 주요 문제입니다. 기대치 관리. 즉, 누군가 X에게 전달하기 위해 버튼이 필요하다고 외치는 시간이 길어졌습니다.

프로세스에 추가 단계를 추가하고 이에 대해 큰 관심을 표명 할 수 있다면 [이 품질 프로세스를 구현하고 있습니다. 버그 수정 시간이 줄어 듭니다! 더 나은 품질의 결과! 큰 이메일 / 미팅 등을 알려주고] 결과를 정기적으로 제공 (ala scrum)한다는 아이디어는 전달하려는 사람들이 추가 프로세스 단계에서 가치를 배우고 그 가치를 볼 것이라는 아이디어입니다. 버그 수정 시간 단축 = 기능 구현 및 테스트에 더 많은 시간이 소요됩니다.

고객이 결과가 갑자기 지연되지 않습니까? 그들은 거의해야합니다. 그대로 계속 진행될 수 없음이 분명합니다. 추가 QA 단계를 추가 한 다음 필요한 경우 팀원을 더 추가 할 수 있습니까? 그러나 품질 단계는 절대적으로 필요합니다.

스크럼 또는 이와 유사한 기능을 사용하는 경우 1 주 스프린트를 목표로 정기 결과를 제공 할 수 있습니다. 그것은 빠른 처리만큼 사람들을 달래 게 할 것입니다.

희망이 어느 정도 도움이 될 것입니다.

당신이 묘사 한 것은 매우 정상 적이고 전혀 놀라지 않습니다.

• 고객은 일반적으로 엔지니어와 중요한 것에 대해 다른 사고 방식을 가지고 있습니다. 우리는 옳은 일을 좋아하지만 고객은 순도보다 시간 엄수를 보상하는 현실에 직면 해 있습니다. 경쟁력을 유지하려면 문제를 신속하게 해결해야합니다. 바로 이것이 바로 여러분에게 지불하는 것입니다.
• 우선 순위를 설정하는 것은 한 사람이 혼자 관리하기에는 너무 크고 털이 많으며, 중요한 문제에 대한 백 로그를 가지고 있으므로 (JIRA를 사용하고 있습니다) 각 관심 영역을 관리하는 중위가 임박한 작업을 맨 앞에 유지하는 데 가장 적합한 옵션입니다 일정.

걱정할 것이 없습니다. 즉, 우선 순위를 설정하는 개발 프로세스에 기술 프로세스를 포함시켜 일상적인 작업을 자동화함으로써 가능한 많은 관리 작업을 유료 고객에게 이전함으로써 많은 고통을 덜 수 있습니다. 가능한.