개발을 의뢰받으면 생각하고 있는 것

처음에

자사 서비스를 내제로 애자일 개발하고 있는 경우의 이야기가 됩니다.

백 로그에서 who, why, what을 이해할 수 있습니까?

전회 qiita에 썼습니다만, 애자일로 내부 개발하고 있는 경우는,
무엇을 만드는 것이 아니라 무엇으로 만들 것인지를 전하는 것이 가장 중요하며,
엔지니어가 공기를 읽고 개발하는 데 필요합니다.

(Who)는 (What)을 실현하고 싶다면 (why)

엔지니어로서 의뢰를 받으면, 이렇게 문장으로 해보자
무엇을 해결하고 싶어서 백 로그를 썼는지 이해할 수 있을까 생각하고 있습니다.

why(배경이 되는 과제, 유저의 페인)를 이해할 수 없는 것은
아무도 원하지 않는 독특한 솔루션이 많다고 느낍니다.
납득할 때까지 의뢰해 온 사람에게 설명을 요구합시다.

의뢰한 대로 만들지 않는다. 고객에게 가치를 제공할 수 있는 최소한의 제품이 되었습니까?

개발 의뢰된 제품은 정말로 사용자에게 가치를 제공할 수 있을까요?

엔지니어라면 알겠지만 하나의 if 문을 추가하는 것만으로도 곱하면
엄청난 테스트 패턴이 필요합니다.
안이한 발상의 제품을, 단지 말한대로 실장해 가면
점점 기술적 부채를 쌓아 자신의 목을 조이게 됩니다.

만들고 싶은 충동을 억제하고 최소한으로 가치를 제공할 수 있는 방법(구조와 구현)을 함께 생각해
제안 · 설계하는 것도 엔지니어의 일이라고 생각합니다.

사내 엔지니어는 프로그램 제조 기계가 아닙니다.

이전에 소속했던 회사의 대표에게 이런 말을 들었던 적이 있습니다.

"엔지니어에게는 사탕과 무치가 필요하다. 사탕 보여주면 필사적으로 개발할 거야"

당시 저는 엔지니어 부문의 관리직이었기 때문에 내가 엔지니어라는 것을
잊어버린 발언이었지만, 충격적이어서 평생 잊을 수 없는 임팩트가 있었습니다.

의뢰받은 개발을 그대로 만드는 것만으로, 이렇게 엔지니어는 제조 머신이라고 생각되어 버립니다.
평소부터 로지컬한 일을 하고 있는 엔지니어야말로, 무엇으로 만드는지, 이것으로 고객에게 가치를 제공할 수 있는지, 최소한의 개발이 되어 있는지를 로지컬에 제안하는 힘이 필요하다고 생각하고 있습니다.