개발자가 불가능한 요구 사항을 어떻게 거부해야합니까? [닫은]

내가 직면 한 문제는 다음과 같습니다.

Spark, 다양한 iOS 응용 프로그램에 사용할 수있는 프레임 워크 개발 작업을 할당합니다. 요구 사항은 다음과 같습니다.

• UI 조작에 사용되는 엄지 손가락의 두께를 감지 할 수 있어야합니다.
• 이 정보를 사용하면 UI의 모든 요소가 자동으로 정렬되고 크기가 조정되어야합니다 .
• 더 큰 엄지 손가락의 경우 요소가 화면 중앙 가까이에 배치되어야합니다.
• 엄지 손가락이 작 으면 요소가 화면 모서리 가까이에 배치되어야합니다.
• 엄지 손가락이 크면 모든 글꼴이 작아야합니다. (이 경우 성인을 가정합니다.)
• 엄지 손가락이 작 으면 모든 글꼴이 커야합니다. (이 경우에는 젊은 사람을 가정합니다.)

요약:

이 프레임 워크는 프로그래밍 방식으로 사용자 친화적 인 사용자 인터페이스를 만드는 데 필요합니다. 프레임 워크는 필요한만큼 많은 프로젝트에 사용할 수있는 방식으로 개발되어야하므로 개발자 친화적이어야합니다.

나는이 작업을 수행 한 개발자이므로 내 질문은 다음과 같습니다.

• 이러한 요구 사항이 조금 어리 석다는 것을 어떻게 설명 할 수 있습니까?
• 실제 프로젝트 개발에 집중하는 것이 더 낫다는 것을 어떻게 설명 할 수 있습니까?
• 이것이 가능하더라도 그러한 것을 개발하지 않는 것이 좋겠다고 어떻게 설명 할 수 있습니까?
• 이 프로젝트에 공손하고, 부드럽게, 정중하게 거절하는 방법은 무엇입니까?
• 3 년의 경험이있는 개발자라도 이것이 가능하지 않다는 것을 어떻게 설명 할 수 있습니까?

장치가 원하는 기능을 지원하지 않고 지원할 수 없어 물리적 으로 구현할 수없는 일련의 요구 사항이있는 경우 요구 사항을 만드는 사람에게이를 설명해야합니다.

당신은 존중하고 요구 사항이 구현할 수없는 이유를 설명해야합니다 (터치 스크린은 엄지 손가락이나 스타일러스를 구별 할 수없는, 즉 그것은 손가락 폭을 감지하기 위해 충분한 해상도를 가지고 있지 않습니다..) - 일을 계속 사실 을 가리키는 기존 문서가있는 경우

감정적 인 논쟁에 가담하지 말고 시원하고 전문성을 유지하십시오. 자신의 요구 사항이 바보라고 말하는 사람은 결코 승리 전략이 아닙니다.

기능의 실제 목표를 이해할 수 있는지 확인하십시오. 왜 기능이 요구 사항으로 간주되는지 확인하십시오. 이를 통해 필요를 해결하는 다른 더 나은 기능으로 이어질 수 있습니다. (감사합니다 @spoike)

@ DarkStar33은 의견을 제시하여 연구를 수행하고 프로젝트 비용과 소요 시간에 대한 실제 견적을 제공합니다. 결과는 너무 비싸고 가치가 있기 때문에 시간이 오래 걸리는 것으로 가정합니다. 숫자와 데이터로 무장하면 데이터를 백업하는 데 도움이 될 수 있지만, 여전히 다른 방식으로 (일부로) 충족 될 수 있는지 비즈니스 목표를 살펴볼 것입니다.

이러한 요구 사항은 어리 석거나 어리 석거나 어리석지 않습니다. 이것은 터치 스크린 사용자에게있어 매우 중요한 문제입니다. 더 큰 손가락을 가진 사람들은 대상을 정확히 찾아 내기가 매우 어려워 작은 손가락으로 이해하지 못하는 경우가 많습니다.

그러나 장치의 센서가 손가락 크기를 측정 할 수 없어서이 요구 사항을 구현할 수없는 경우 다음과 같이 작성하면됩니다. 불행히도 현재 사용 가능한 장치는 이러한 기능을 지원하지 않습니다.

나는 여기서 Devil 's Advocate를 약간 연주하고 실제로 사람의 엄지 손가락의 크기를 측정하는 것이 기술적으로 가능하다고 생각합니다. iPhone은 멀티 터치 장치입니다. 보정을 위해 사용자에게 엄지 손가락 또는 두 손가락을 화면에 나란히 놓고 이러한 터치 사이의 거리를 측정하도록 지시 할 수 있습니다.

물론 이것은 내 직관이 얼마나 실현 가능한지 확인하기 위해 테스트와 실험이 필요합니다. 더 나은 독서를 위해서는 엄지 손가락을 화면을 가로 질러 드래그해야 할 것입니다.

즉, 사용성 및 구현에 심각한 문제가 있습니다.

• 장치가 공유되면 어떻게됩니까? 보정은 언제 발생합니까?
• 프레임 워크로 구축 된 모든 응용 프로그램 에서 UI 요소 의 위치를 어떻게 동적으로 결정할 수 있습니까? 분명히 각 앱마다 UI와 레이아웃이 다릅니다.
• 현재 iOS 앱에 대한 간단한 설문 조사에 따르면 잘 설계된 앱은 사용 가능한 모든 수평 공간과 이미 공간 요소를 사용하므로 중요한 버튼이 최대한 크고 가장자리 근처에 배치됩니다. 장치의 전체 너비는 분명히 목록과 레이아웃에 사용됩니다.
• 가능하더라도 비용 / 이익 분석은 무엇입니까? 이러한 시스템에서 표준 UI 컨트롤에 비해 얼마를 얻을 수 있습니까? 이미 많은 앱에서 사용하는 것처럼 글꼴 크기에 대한 간단한 토글 컨트롤을 사용하는 것이 더 쉽지 않습니까?

당신이하는 일은 그것을 심각하게 취급하고 시간이 얼마나 걸리는지에 대한 견적으로 돌아와서 견적이 매우 높고 상세하여 확인하여 높은 숫자에 이의를 제기 할 수 없도록하십시오. 일단 당신이 그것을 보여 경제적이지 않을 것입니다 그들은 당신을 내버려 둘 것입니다. 특정 작업이 현재 하드웨어에서 지원되지 않고 실행 가능하지 않을 수도 있음을 지적하십시오. 이 규모의 프로젝트에 필요한 추가 인원을 추가하는 것을 잊지 마십시오.

애플 사람들은 이미이 모든 것들에 대해 깊이 생각했고 엄지 손가락 / 손가락 크기에 따라 크기를 조정할 수있는 인터페이스를 찾지 못했습니다.

사용자는 손가락 아래로 움직이는 목표물을 싫어합니다.

불가능한 요구 사항이 제공되는 데 어려움을 겪고있는 경우 걱정할 수없는 경우 즉시 불가능하다고 요구하는 것이 가장 좋습니다. 불가능한 프로젝트에 대해 사업 계획을 세울수록 프로젝트 실패로 인해 귀하를 비난 할 가능성이 높아집니다.

무엇보다도, 당신의 잘못이 아닌 것들에 대해 걱정하지 마십시오. 우리 모두는 우리가 통제 할 수있는 능력에 대해 걱정할만큼 충분합니다. 누군가가 그러한 프로젝트 실패에 대해 귀하를 책임지게한다면, 그것은 당신에게 불공정합니다. 당신은 카르마를 믿습니까?

불합리한 요청을 전환하는 한 가지 방법은 고객이 해결하려는 문제의 본질을 고객이 이해하도록 돕는 것입니다. 구어체 적으로 " 이유 스택을 터뜨리는 것"으로 알려진 계획 인터뷰 기법을 통해 , 당신은 "정중하고 지능적인 방법으로"재귀 적으로 "왜"를 계속 묻습니다.

커뮤니케이션을 진행하고 특정 문제를 "추적"하는 데 중요한 도구 중 하나는 Barrett이 "이유"스택을 생성하는 것입니다. 이것은 단순히 "왜 그렇게 되었습니까?"라는 질문을 계속하기위한 것입니다. 프로젝트 요구 사항에 대해. 그는이 기술이 어떻게 발굴 할 수 있는지에 대한 전형적인 예를 들었다. "한 번은 고객과 함께 프로세스의 특정 단계에서 데이터를 인쇄해야한다는 요구 사항이 있었기 때문에 그 이유를 물었습니다." "답변은 데이터를받는 데 필요한 부서가 데이터를 입력해야한다는 것이 었습니다. 데이터가 자동으로 응용 프로그램으로 전송 될 수는 없었습니다."

목표는 기능의 핵심 비즈니스 가치에 도달하는 것입니다.

• 수익 보호
• 수익 증대
• 비용 관리
• 브랜드 가치 증대
• 제품을 현저하게 만드십시오
• 고객에게 더 많은 가치 제공

( 오이 위키의 항목 )

이 기능이 이러한 범주 중 하나에 맞지 않으면 고객이 더 중점을 두어야 할 사항이 있거나이 사고 과정을 통해 문제를 해결하는 방법에 대해 조언 할 수 있습니다. 보다 의미있는 방식으로 해결하려고합니다. 실제 문제는 종종 해결하도록 요청한 문제보다 더 높은 수준의 추상화에 있습니다.

스캔 엄지 크기 예를 사용하려면

클라이언트 : UI 조작에 사용되는 엄지 손가락의 두께를 감지하려고합니다.

개발자 : 왜 그렇게 하시겠습니까?

클라이언트 : 이 작은 버튼을 탭하려고 할 때 종종 잘못된 것을 치고, 우리의 소프트웨어는 나와 같은 큰 손을 가진 많은 건설 노동자에 의해 사용됩니다. 손가락 크기에 맞게 UI를 교정 할 수 있다면 사용하기가 더 쉬워 질 것입니다.

개발자 : 사용 편의성이 확실히 고객에게는 가치가 있지만, 왜 UI를 교정하고 싶습니까? 이것을 사용하는 사람들이 손이 큰 것으로 알려진 경우 해당 사용 사례에 맞게 디자인을 조정하지 않겠습니까?

클라이언트 : 그런 식으로 생각한 적이 없습니다 . 손이 작은 사람도 깔끔한 디자인을 사용할 수 있다고 생각합니다!

면책 조항-귀하의 요청이 가능한지 여부를 알 수 없으며 가능한 경우 요청 시간을 결정하고 해당 피드백을 관리자에게 제공해야합니다. 그러나 나는 적어도 표준 프레임 워크를 사용하는 것이 불가능하다는 가정 으로이 답변을 작성하고 있습니다. 실제로 무언가를 할 수 없거나하지 않아야 할 때 더 일반적인 경우로 내 대답을 확장하고 있습니다.

그냥 아니라고 말해.

이 스레드에는 많은 '아니오'라고 대답하지 않습니다. 나는 부드럽고 복종적인 태도라고 믿습니다. 이런 식으로 생각하십시오-저는이 팀의 기술 전문가이며 다른 팀원들은 불가능하거나 지나치게 복잡하고 잠재적으로는 불가능하다고 생각하는 일을하려고합니다. 거절하는 것은 나의 책임입니다.

물론 나는 부드럽게 말하지 않아야한다. " 아니오 " 라고 말하기 전에 "가능한지 조사하는 것"을 제안하면서 "이것을 강력히 추천 할 수 있습니다" . 그러나 나는 그것이 내 직업이기 때문에 궁극적으로 거절 할 것입니다.

이것에 대한 많은 비유가 있습니다

• 회계사 님, 추수 감사절 저녁을 세금 공제로 내립니다
• 셰프 씨, 닭을 카운터에 밤새두고 생고기를 제공하고 싶습니다.
• 변호사, 나는 아이들이 침실을 정리하지 않아 고소하고 싶다
• Mechanic 씨, 전기 자동차에 터보 차저를 설치하십시오

이러한 모든 사람들에게 바보, 낭비, 위험 또는 잘못된 작업을 수행하도록 요청할 수 있습니다. 그리고 당신은 그들 모두가 이러한 행동에 대해 조언하고 궁극적으로 거부하기를 기대할 것입니다 (적어도 나는 희망합니다). 이 전문가들 중 누구라도 "흠 .. 이건 나쁘지 않다"고 대답하지 않고 "흠.

동료들은 당신의 정직성을 소중히 여기고 존중할 것이며, 당신이 알지 못하는 무언가를 따르지 않고 유용한 피드백을 제공하면 모든 사람에게 많은 시간과 돈을 절약 할 수 있습니다.

타겟 플랫폼이 허용하지 않는 것을 구현할 수 없다고 클라이언트에게 알리는 것이 너무 어렵지 않아야합니다. 그러나 물러서서 스스로에게 물어보십시오.이 끔찍한 요구 사항의 논리는 무엇입니까? 내가 읽을 수있는 것에서 그들은 사용자 친화성에 매우 관심이 있습니다. 그런 다음 그들에게 물어보십시오. "우리는 사용자 친화적 인 인터페이스를 원합니다." 그런 다음 할 수있는 것과 할 수없는 것으로 인도하십시오. 그들이 쉬운 사용자 인터페이스를 원한다면 사용자가 글꼴 / 아이콘 크기를 설정하는 것과 같은 쉽고 저렴한 방법이 있다고 말하십시오 (IoS에서 가능하다고 가정합니다). 사용자가 설정 탭을 통해 응용 프로그램의 글꼴 크기 / 아이콘 크기 및 배열을 제어하도록 할 수 있습니까? 엄지 손가락 크기로 사람의 나이를 추측하는 것보다 더 쉽고 정확해야합니다! 관리자가 원하는 마지막 것은 OS가 이미 제공 한 것과 동일한 것을 달성하는 불필요하고 부풀어 오르기 어려운 코드입니다. 클라이언트에게 사용자가 응용 프로그램을 제어하는 ​​것보다 응용 프로그램을 제어하는 ​​것을 선호한다고 말하십시오.

제 답변은 시도되지 않은 기술 중 일부를 살펴보고 가능한지 알려주는 것입니다. 이러한 발견을 바탕으로 잠재적 인 개발 계획을 시작할 수 있습니다.

나는 당신이 다른 사람에게 한 사람의 엄지 손가락을 말할 수 있다고 생각하지 않지만 손가락을 사용하는 시간을 알기 위해 손가락에서 충분한 치수를 얻을 수 있습니다. 실제 문제는 엄지 손가락의 각도로 인해 화면의 다른 공간보다 더 이상 화면 공간에 닿지 않을 수 있습니다. 엄지 손가락으로 전화를 사용하는 사람은 없으며 엄지 손가락을 인쇄하는 것처럼 화면에 평평하게 놓습니다.

회사를 떠나십시오. 그것을하는 방법을 알아 내십시오. 지금보다 더 많은 돈을 팔아 팔아라.

요구 사항에 관해서는 일반적으로 다음과 같이합니다. 특정 요구 사항을 실현하는 데 걸리는 시간을 추정하려고합니다.

불가능할 수있는 요구 사항이있는 경우 가능 여부를 확인하는 데 며칠 또는 시간을 요청하십시오. 귀하의 경우 질문은 "사용자의 손가락이 얼마나 두꺼운지를 결정할 수 있습니까?"입니다.

실제로이 질문은 조금 더 복잡합니다. " 즉시 상호 작용할 수 있도록 첫 번째 터치 후 사용자의 손가락 이 200 밀리 초 미만으로 얼마나 두껍게 결정될 수 있습니까?" ( 첫 번째 로 두 번째 또는 ...로 대체 하고 200ms에서 300ms 또는 무엇이든 ...)

이 질문에 대답하는 데 1 개월이 걸릴 수도 있습니다. 어쩌면 이것이 가능할지라도 80 %의 경우에만 잘 작동하는 매우 복잡한 알고리즘이 필요합니다.

내가 어디로 가는지 알아?

사람들은 종종 해당 분야에 대한 전문 지식과 경험이 낮기 때문에 가능성에 대해 잘못된 가정을합니다. 그러므로 직감으로 논쟁 할 수는 없지만 사실이 필요합니다.

다른 이해 당사자들이이 기능이 2 년이 걸리고 2014 년 이전에 iPhone 10이 도착해야한다는 것을 알고 있다면, 요구 사항이 빠르게 줄어 듭니다.

복잡해 보이지만 전혀 불가능하지는 않습니다. 터치 스크린이 엄지 손가락 가운데 손가락 또는 스타일러스를 구별 할 수없는 지점; 사용자는 초기화 (세션 시작 등) 할 때 몇 번의 움직임 등을 사용하여 크기를 교정하기 위해 엄지 손가락을 넣은 다음 가운데 손가락 등을 묻습니다.

나는 할 수 없다고 말하기 전에 다른 방법으로 근본 문제를 해결하려고 노력하고 있습니다.

예를 들어, 사용자가 종종 작은 버튼을 클릭하려고하면 놓치는 경우 버튼 주위의 영역을보고이를 사용하여 다른 모든 클릭을 다시 교정 할 수 있습니다.

이와 같은 독창적 인 솔루션을 제시하는 것은 아마도 손가락 너비를 마술로 계산하도록 요청하는 것 이상입니다 (API에 있지 않다는 것을 알 수 있습니다).

버튼 주위에 놓치는 부분을 놓아 놓치기가 여전히 어려울 수 있으므로 더 많은 시간을 예상하십시오.

그것이 그의 감정을 상하게 할 정도로 거절하지 마십시오. 기술 제약으로 인해 60 %의 시간이 매번 작동한다는 점을 분명히하십시오.

그리고 그가 그러한 사업에 관련된 비 실용성과 비용을 깨닫고 나면 예산 내에서 텍스트 크기를 변경할 수있는 설정을하는 것과 같은보다 실용적인 접근 방식을 제안하십시오. 그리고 러시아인들은 연필을 우주로 가져 갔다.

향후 프로젝트를위한 솔루션과 디자인이 아니라 문제와 요구 사항을 설명하도록하십시오.

내가 좋아하는 것은 팀 관점에서 문제에 접근하는 것입니다. 이 경우 프로젝트 관리자와 나는 해결책을 제시해야합니다. 나는 또한 열린 마음을 가지고 있음을 보여주고 싶습니다. 듣는 것이 불가능하다고 생각되는 것을 들으면 나와 프로젝트 관리자 사이에 오해가있을 가능성이 있습니다. 또는 아마도 우리는 그 아하 순간에 도달하지 못했습니다.

우리가 도약하기로 결정하고 열린 대화를 나눈 후에는 문제를 경제적 인 문제로 다루는 것이 가장 쉽다는 것을 알게되었습니다. 기술에서 무한한 양의 자원이 주어지면 거의 모든 것이 가능합니다. 해야 할 일을 논의하면서 여러 번 정중하게 "아니오"라고하는 가장 쉬운 방법입니다. 그리고 그것은 가능한 오해를 없애는 방법이 될 것입니다. 솔직히 말해서, 우리는 확실히 아니오라고 말하지 않습니다. 그리고 어쨌든 말의 목적은 무엇입니까? 일을 할 가치가 없다면, 우리가하고 싶은지 아닌지는 중요하지 않습니다.