동료가 프로세스를 무시할 때 어떻게 설득력이 있습니까?

내가 겪고있는 문제 :

1. 팀원은 기능 / 기술 문서가 준비되지 않은 상태에서 프로젝트를 시작합니다. 회사 프로세스에서 시작하기 전에 문서가 있어야한다고 지시하더라도 말입니다.
2. 우리 팀원은 값이 싸고 구조화되지 않은 솔루션을 받아들이고 프로젝트 관리에 '제한된 시간'이 있다고 언급 할 때 두 번 생각하지 않고 소프트웨어에 실제로 나쁜 해킹을 구현할 것 입니다.
3. 우리 팀원은 다른 팀의 미완성 프로젝트와 함께 작동하는 프로젝트 (테스트 및 미완성)를 시작합니다. (추가 작업이 많이 발생 함).
4. 소프트웨어의 개선 및 전체 단계가 제대로 계획되지 않았으며 백엔드 개발자가 작업을 시작해야 할 때 프런트 엔드 / 디자인이 끝나지 않는 경우가 종종 있습니다.

이 문제는 여기서 일을 시작한 이래로 여러 번 끝없이 논의되었습니다. 모두가 동의했고 결론 은 프로세스 를 시행 해야 한다는 것 입니다. 즉, 모든 것이 처리 될 때까지 백엔드 개발자가 시작되지 않습니다.

이러한 문제가 계속 발생하고 있습니다. 작업 자체와 일부 동료에게 정말 화가 났을 때까지 실제로 동기 부여가되었습니다.

우리 팀원들은 많이 불평하지만 서로에게만 불평합니다. They keep on going - whatever the situation is. 결과?

1. 나는 안전하지 않다, 아마 나인가?
2. 이것은 단지 일이 진행되는 방법입니까?

내 질문? How can I say no against work ignoring the process if everyone else seems to mindlessly accept?.

그것은 항상 나쁜 것을 찾고있는 성가신 개발자처럼 보이지 않습니다.

모두가 정말로 동의 했습니까 ?

한때 프로세스 개선을 원하는 상황이있었습니다. 우리는 다른 프로세스의 제안을 만들었고 모두가 동의하는 것처럼 보였습니다.

그러나이 과정을 따르고 싶을 때마다 '더 중요한 문제'로 인해 예외가 발생했으며 항상 첫눈에 합리적으로 들렸습니다. 따라서 사실상 그 과정은 사실상 따르지 않았지만 모든 사람들은 '원칙적으로 우리는 그 과정을 따르고있다'고 생각했습니다.

문제는 개선을 제안하면 동의하지 않는 사람 (개선을 좋아하지 않는 사람)이 없다는 것입니다. 그러나 비용을 제시하면 일반적으로 많은 의견 차이가 있습니다. 그리고 일을하는 편리한 방법을 잃어 버리는 것은 대부분의 사람들에게 큰 비용입니다.

이를 입증하기 위해 나는 '질문을 구현하고, 버그를 제거하고, 개선 된 프로세스를 따르고, 책상을 청소하고, 정시에 도착하는'모든 것을 우선 순위로 정하십시오. '

프로세스가 끝나고 책상 청소가 끝나고 5 분 늦지 않았습니다. 그래서 기본적으로 그들은 내가 제안한 것과 완전히 다른 것에 동의했습니다.

품질에 대한 비용을 지불하고 싶지 않은 문제 일 수 있습니다. 그것은 그들이 당신에게 비판을 징징 거리는 것으로 합리화하게 만들지 모르지만, 내 경험으로는 그렇지 않습니다. 기술 부채는 그렇게 눈에 띄지 않을 수 있으며 상황에 따라 쉽게 설명 할 수 있지만 결국 현실이 뒤 따릅니다.

바라건대, 그때까지 그들이 깨달았거나, 당신이 잡스를 바꿨습니다.

아마도 당신 일 것입니다

당신은 매우 체계적이고 체계적인 코딩 방식을 선호하는 것 같습니다. 팀원들은보다 "일을 끝내는"접근 방식을 갖고있는 것 같습니다. 이제는 "시간 낭비"로 이어질 수 있으므로 일부 구조가 제대로되어 있고 부주의 한 작업에 대한 변명의 여지가 없습니다. 그러나 소프트웨어 프로젝트는 유동적 인 경향이 있으며 너무 많은 구조를 적용하면 조직의 오버 헤드가 많이 발생합니다.

아마도 당신은 모두 중간에서 만나 더 민첩하고 상호 적이지만 구조화 된 접근법을 시도해야합니다.

이 사람들에 대한 책임은 누구에게 있습니까? 누군가가 그들을 고용하고 누군가가 그들을 해고하거나 책임을 질 수 있습니다.

"내 회사는 ...을 요구합니다"는 약간의 시행 없이는 의미가 없습니다.

생산 프로세스를 허용하지 않는 시간 요구는 할 수 없습니다.

이러한 통제력 부족과 비현실적인 기대가 품질 저하의 원인 인 것 같습니다.

떠나거나, 수석 개발자가되거나, 아무것도하지 않거나, 자신이 좋아하는 사람들과 함께 일하기 시작할 수 있습니다. 다른 사람이 더 나은 방법을 찾아 변경하기 전까지는 올바른 절차를 따르겠다고 모두에게 알리십시오. "사이다 하우스 규칙"처럼 들립니다.

동료가 완전히 다른 프로세스를 따르기를 원하지 않는 것처럼 들리면 다른 결정을 내리기를 원할 것입니다. 물론, 그들이해야 할 일에 관한 규칙 (지침?)이 있으며, 그들은 무시합니다. 그러나 당신이 묘사하는 문제는 (프로젝트 작업을 시작하거나 사양을 거부하기 위해) 결정을 내려야하며 계속 진행하기로 결정한다는 것입니다. 규칙을 계속 상기 시켜도 해당 결정은 변경되지 않습니다. 그들은 당신만큼 규칙에 관심이 없습니다 . 그들은 유용하다고 느끼기를 원하며, 아니라고하더라도 유용하다고 느끼지 않습니다 .

행동을 바꾸고 싶다면 규칙에 대해 지속적으로 상기시키는 것이 효과적이지 않을 것입니다. 그들이 당신을 무시하게 할 가능성이 더 높습니다. 프로세스를 계속 진행하면서 프로세스를 더 유용하게 만들기 위해 프로세스를 변경하는 방법을 찾으십시오. 어떤 종류의 코드 검토를 구현하여 서로의 코드를 확인하고 서로 학습하여 해킹이 코드를 프로덕션 코드로 만들지 못하게 할 수 있습니까? 사양 (docs / ext.interfaces / front-end)이 처리되는 방식을 흑백 마감 / 미완성 결정에서보다 협력적인 프로세스로 변경할 수 있습니다. 끝 마칠 수 있습니까? 또한 요구 사항 이 변경 될 수 있음을 인정해야합니다.

대부분 그것은 당신이 아니며, 그들도 아니며, 과정입니다. 당신 (그리고 당신의 PM)이 사람들이 자신의 성격에 너무 대항 할 필요가없는 것들을 정리할 수있는 방법을 찾을 수 있다면, 그 과정은 훨씬 더 빨라질 것입니다.

이것은 팀장과 함께 비공개 세션으로 체크인하는 시점에 관한 것입니다. 바라건대 당신은 그 정보를 아주 비공식적으로 만들 수있는 리드와 충분히 좋은 관계를 유지하기를 바랍니다.

회의의 목적은 팀이 왜 일을하고 있는지 를 파악 하는 것입니다. 모두가 함께 모여 고개를 끄덕이고 웃으며 새로운 과정에 동의했다면 왜 여전히 바뀌지 않습니까? 단순한 걱정하지 않거나 무능한 것보다 훨씬 더 깊이 실행될 가능성이 높습니다. 육안으로 볼 수없는 운전자가있을 수 있습니다.

동료가 가능하다면 공황을 줄이고 기술 부채를 줄이고 제품 품질을 높이는 프로세스를 따르겠다고 가정하여 회의를 시작하십시오. 보이지 않는 힘은 무엇입니까?

디자인 및 UI 프로토 타입의 초기 작업 전에 많은 구현 / 통합이있는 것 같습니다. 회사는 그러한 사전 작업을 수행 할 수있는 사람들이 부족합니까? 어쩌면 당신은 자원 봉사 할 수 있습니다. 이해 관계자와 합의하는 데 문제가 있습니까? 어쩌면 팀이 그들과 의사 소통하는 새로운 방법을 찾거나 문서화에 대한 새로운 접근 방식을 취할 수도 있습니다.

리더에게 왜 그런지 물어 보면, 방어를 피하고 문제와 해결책에 중점을 둔 토론의 문을 열 수 있습니다.

또 다른 방법은 새로운 일을하는 방법을 개척 할 수 있는지 묻는 것입니다. 팀의 지원을 받아 문제를 해결하고 옹호하는 접근 방식을 취하도록하십시오. "시스템"을 사용하면 문제가 발생할 수 있으므로 관리가 필요합니다. 그러나 생산성이 높고 스트레스가없는 것으로 판명되면 상황을 바꾸는 좋은 사례를 제공하고 옹호자가 이길 수 있습니다.