보스가 항상 요구 사항과 전체 디자인에 대한 주요 결정을 연기하는 경우 어떻게해야합니까?

새 프로젝트를 시작할 때 상사는 항상 정해진 결정을하지 않습니다. 그는 보통 다음과 같이 말합니다. 좋아, 그냥 무언가를 쓰기 시작하고 가능한 한 일반적입니다. 당신이 끝나면 우리는 어떻게 계속되는지 살펴 봅니다. 그의 주장은 기본적으로 당신이 "민첩한 개발"을 결코 알지 못한다는 것입니다.

가능한 한 일반적인 질문을 유지하려면 : 상사가 의사 결정을 원하지 않는 경우 어떻게해야합니까?

몇 주 후에 리팩토링 및 부분 재 작성이 발생할 수있는 코드를 작성하고 코드를 작성하면됩니다. 아니면 상사가 최소한 몇 가지 결정을 내릴 때까지 계속 논의합니까? 이것은 현재 나의 전략입니다. 물리 법칙과 비슷하기 때문에 어떤 시점에서 무언가를 전달해야합니다. 보스의 보스가 결과를보고 싶어하거나 물건이 언젠가는 말도 안되기 때문에.

또한 상사는 거의 모든 것을 비판하고 있습니다. 자신에 근거한 제안조차도 ...

프로토 타입 제작

처음에는 아무것도하지 않는 화면을 그리기 시작하면됩니다 (아마도 충분할까요?).

부분적으로 느리게 작동하게하고, 수행하려는 작업이 더 명확 해지면 결국 불량 코드의 일부를 리팩터링해야합니다.

그들이 무언가를보고 그들이 원하는 것이 아니라는 것을 깨달을 때까지 그들이 원하는 것을 모르는 것이 일반적인 문제입니다. 누군가가 당신이 단지 당신에게 말하는 것과 같은 '프레임 워크'나 '제네릭'을 만들기를 원할 때, 당신이 시도하면 문제가 생길 것입니다. 프레임 워크는 이미 작성되었으므로 그렇게 할 필요는 없습니다.

메시지에서 수집 한 몇 가지 문제가 있습니다. 0- 프로젝트를 관리하는 것은 귀하의 일이 아니며 최종 사용자 요구 사항을 수집하는 것은 귀하의 일이 아닙니다. 1- 보스가 정확한 요구 사항을 알지 못함 2- 보스가 요구 사항에 대해 최종 사용자와 이야기하지 않음 3- 보스가 실제로 민첩성을 이해하지 못하는 용어를 던지고 있음 4- 재 해결 방법 여러 번 쓰고 당신은 그것에 대해 행복하지 않습니다

1,2 및 3은 노인이 아닌 경우에 대해 할 수있는 일이 거의 없습니다. 그러나 다음을 수행 할 수 있습니다.

A-프로젝트 계획을 공유해달라고 요청하십시오. 그는 업무와 마감일을 보여 주거나 건설 할 것이다. 이 중 하나는 분석 및 요구 사항 수집에 관한 것이어야합니다. 제안하지 않으면.

B-소프트웨어 프로젝트의 성공에 대한 요구 사항의 중요성에 대한 참조를 준비하십시오.

C-Agile의 존재 여부에 대한 1 페이지를 준비하십시오.

D-디자인 단계에 대한 일반적인 입력 목록을 준비하고 각각의 가치를 확신시킵니다.

E-비즈니스 분석가 및 / 또는 데이터 모델러를 팀에 추가하도록 제안하십시오. 이러한 역할은 최종 사용자와 함께 있어야하며 필요한 정보 나 그 일부를 얻을 수 있습니다.

F-다른 개발자들이 어떻게이 사람을 만났는지보십시오.

# 4의 경우, 프로토 타이핑 방식이나 코드 생성기를 사용하여 응용 프로그램의 기능적 측면에 대해 마음을 사로 잡을 수 있도록 제안 할 수 있습니다. 대부분의 도구는 완벽한 GUI를 생성하지는 않지만 최소한 필요한 기능을 캡처 할 수 있습니다.

모든 경우에 각 반복을 명확하게 문서화하고 수신 한 입력, 수행 한 작업 (상세한 내용) 및 결과에 대해 이메일로 보내십시오. 결과가 (요구 부족 등) 적절한 원인에 기인하는지 확인하십시오.

불행히도 어떤 사람들은 조언을 받아들이지 않습니다. 따라서 당신이 그와 의사 소통하는 방법에주의하십시오.

이것은 잘되지 않습니다!

행운을 빕니다.

나는 그런 상사를 가졌었다. 사실 그의 좌우명은 "무결성이 결정의 유연성"이라는 농담이었다.

어떤 개발 작업을 하든지 상관없이 상사보다 고객의 문제 를 해결할 수 있는 더 나은 위치에있을 것입니다 . 클라이언트가 어떤 문제를 해결하려고하는지 모르는 경우 (사양과 동일하지 않음) 누군가 요구 사항을 제대로 수집하지 않은 것입니다.

일부 페이지 레이아웃을 스케치하거나 비 기능적 프로토 타입을 제작하십시오. 그러나 무언가를하십시오. 풀 클라이언트 소프트웨어 또는 웹 응용 프로그램을 구축하는지 여부는 명확하지 않지만 후자의 장점은 출시 초기에 출시되는 경우가 많습니다. 베어 본으로 시작하여 거기서부터 작업하십시오. 잘못된 시작은 대화가 흐르고 일부 결정이 내려지면 아무런 해가 없습니다.

우리는 고객을위한 $ WORK (내부 웹 앱)에 대해 다음과 같이 말합니다. 첫 번째 초안을 버릴 준비를하라. 그러나 당신이 실제로 얼마나 드물게해야하는지 놀랄 수도있다.

애자일 서적은 당신이 할 수있는 한 그 결정을 연기한다고 제안 한다 . 모든 결정에는 결정이 내려져야 할 시점이 있으며 지금 당장있을 수 있습니다.

다른 한편으로, 또한 자신에게 질문하십시오. 이 앱에 사용할 지속성 계층을 결정해야합니까? 아니면 CSV로 작성하여 나중에 결정을 내릴 수있을 정도로 추상화 된 상태로 유지할 수 있습니까?

자신의 사양 문서를 작성하고 설명 할 때 검토를하여 서명하십시오. 그러면 당신은 보스가 될 것이며, 당신의 보스는 기술적 인 문제가 아닌 더 많은 대인 관계 관리 문제로 이동할 것입니다.

'상위 관리'에 참여하여 상사 및 고객과 대화하고, 일부 솔루션을 파악하고, 팀이 구현할 최상의 솔루션을 선택하고, 다른 솔루션에서 결함을 찾은 다음 관리자가 '올바른'결정을 내릴 수 있도록 '관리'하십시오.

그리고 물론 그것이 그의 생각이라고 생각하십시오. (특히 모든 것이 잘못되었을 때!)

무언가를 디자인하고 구현해야합니다. 당신의 상사는 결정을 내리지 않기 때문에 스스로 결정하십시오. 의사 결정과 가정을 구현하기 전에 약간의 시간이 더 걸립니다. 상사를 포함하여 문제가있는 사람에게 보내십시오. 바라건대, 그 목록에는 상사보다 더 많은 것이 포함되어 있기 때문에 다른 사람들이 당신이 진행할 준비가되었음을 알고 있기 때문에 약간의 결정을 내 리도록 압력을 가할 것입니다. 서면으로 의사 결정을 내릴 때, 특히 다른 사람들이 동의하지 않는 결정을 내릴 때 얼마나 빨리 피드백을 받는지 놀랄 것입니다. 그 동안에는 달리 언급 할 때까지 귀하가 내린 결정을 진행할 것입니다.

당신이 당신의 상사가 원하지 않는 것을 구현하는 데 시간을 낭비했다면, 당신이하려는 길을 알고 있었기 때문에 그것은 당신에게 있지 않습니다.

또한 어떤 사람들은 시작하는 데 어려움을 겪지 만, 일단 눈에 보이는 것을 본 후에는 마음이 떠오를 것입니다. 아마도 당신의 상사가 그와 같고 당신이 서면으로 계획 한 것을 말하면 그의 마음이 갈 것입니다.

스스로 결정하고 코딩을 시작하십시오. 물론 유연한 방법으로 개발하면 도움이 될 것입니다 (로버트 C 마틴의 민첩한 패턴, 원칙 및 관행을 읽으십시오).하지만 의사 결정이 없으면 세상의 모든 유연성이 도움이되지 않습니다. 당신은 당신이 생각 하는 것을 개발해야 할 수도 있습니다.필요에 따라 수정하십시오. 종종 고객 / 보스들은 그들이 볼 때까지 또는 그들이 원하지 않는 것을 볼 때까지 그들이 원하는 것을 알지 못합니다. 아마도 개발자가 될 수있는 범위를 벗어나게 될 것입니다. 그러나 그것은 인생입니다. 나는 종종 나와 동료들이 효과적으로 비즈니스 결정을 내린다는 것을 알게됩니다. 때로는 이것에 의문의 여지가 없으며, 내가 결정한 결정은 순수하게 다른 사람이 결정을 내리지 않기 때문에 사업을 추진하기 시작합니다. 모든 가정과 결정 (예외 없음)을 나열하고이를 상사에게 제시하십시오.