기술자가 아닌 사람에게 왜 작업이 생각보다 훨씬 오래 걸리는지를 설명하는 방법? [닫은]

거의 모든 개발자는 비즈니스 측면에서 다음과 같은 질문에 대답
해야합니다.이 간단한 연락 양식을 추가하는 데 2 ​​일이 걸리는 이유는 무엇입니까?

개발자가이 작업을 추정하면 다음 단계로 나눌 수 있습니다.

• 데이터베이스를 약간 변경
• 속도를위한 DB 변경 최적화
• 프론트 엔드 HTML 추가
• 서버 측 코드 작성
• 검증 추가
• 클라이언트 측 자바 스크립트 추가
• 단위 테스트 사용
• SEO 설정이 작동하는지 확인
• 이메일 확인 구현
• 속도를 위해 코드를 리팩토링하고 최적화
• ...

기술적으로 비전문가에게는 설명하기 어려울 수 있습니다. 기본적으로 전체 작업을 HTML을 모으고 데이터를 저장할 테이블을 만드는 것으로 간주합니다. 그들에게는 최대 2 시간이 될 수 있습니다.

왜 추정치가 비 개발자에 비해 높은지 설명하는 더 좋은 방법이 있습니까?

당신은 당신의 질문에 방금했습니다.

작업을 개별 단계로 나누고 각 단계에 대한 견적을 제공하십시오. 이것은 모든 옵션을 고려했으며 모든 경우를 다룰 수 있음을 나타냅니다.

타임 스케일이 너무 크면 파인트 포트에 쿼트를 넣는 것보다 구체적인 데이터로이 부분에 필요하지 않은 부분 (예 : 이메일 확인)에 대해 논의 할 수 있습니다.

이것을 충분히 자주 수행하면 언뜻보기에 눈을 맞추는 것보다 개발에 더 많은 것이 있다는 것을 희망적으로 가르쳐 줄 것입니다.

작업을 나열하는 것은 거의 완벽한 일이지만 엔지니어에게는 완벽한 의미의 작업은 비 기술적 인 사람에게는 거의 의미가 없다는 것을 명심하십시오. 예를 들어, 위의 목록에서 "속도에 맞게 DB 변경 최적화"는 코드 프로파일 링, 느린 포인트 찾기, 전문가와 함께 검토 또는 전문가에게 던지기 등의 시간이 많이 걸리는 작업 일 수 있음을 알고 있습니다. 제품에 특정한 사전 정의 된 테스트 세트. 그리고 너무 느린 지역을 고치는 방법을 찾으려고 노력하는 동안 책상에 머리를 두드리는 일이 아니라면 몇 시간이 걸릴 것입니다.

그러나 "최적화"라는 단어가 아니라면 "DB"라는 단어에서 프로젝트 관리를 잃어 버렸을 수도 있습니다.

나는 일반적으로 비즈니스 측면에서 위험을 설명하는 단어와 함께 BIG 단계 측면에서 프로젝트 관리 에이 물건을 표현합니다. 목록을 가져 와서 프로젝트 관리와 이야기하고 있다면 다음과 같이 정리합니다.

1. 첫째,이 부분에는 사용자가 보는 웹 페이지와 무거운 작업을 수행하는 서버의 두 부분이 있습니다. 이 기능이 작동하려면 두 부분이 모두 있어야합니다.
2. 첫 번째 부분은 사용자에게 적합한 웹 페이지를 만드는 것입니다 (프런트 엔드 HTML 추가, 클라이언트 측 자바 스크립트 추가). 여기서 중요한 점은 웹 페이지가이 제품의 일부인 것처럼 보이며 지원하는 모든 브라우저에서 작동해야하고 매끄 럽어야한다는 것입니다. 이것은 사용자가 보는 것이므로, 나빠 보인다면 사용자는 우리 제품이 나쁘다고 생각할 것입니다. 이를 개발 한 다음 테스트하려면 X 일이 걸립니다.
3. 다음으로, 작업을 수행하는 웹 페이지 아래에 물건이 있어야합니다. 이 경우 기능에 대한 설명을 여기에 삽입 해야 함을 의미 합니다 (맵-데이터베이스 변경, 서버 측 코드 작성, 이메일 확인 구현, 유효성 검사 추가, 단위 테스트 사용). 나는 이것을 함께 던질 수 없다. 코드가 개발 된 후 테스트되면 모든 사용자의 데이터가 손상 될 위험이 있습니다. 즉,이 새로운 기능을 사용하지 않는 사용자의 경우에도 단순한 새로운 기능이 제품 전반에 걸쳐 제품의 명성을 손상시킬 수 있습니다. 우리의 개발 관행은 이것을 다룹니다-우리는 일어나지 않도록 많은 테스트를 수행합니다. 그러나 그것은 제대로 테스트하기 위해 계획을 세워야한다는 것을 의미합니다. Y 일이 걸립니다.
4. 우리 제품에는 속도가 큰 문제입니다. 일이 빨리 일어나지 않으면 사용자는 제품이 좋지 않다고 생각할 것입니다. 따라서이 모든 내용을 작성한 후에는 작업을 수행하고 성능 측면에서 동등한 지 확인해야합니다. 이것은 웹에 큰 영향을 미칩니다. 사람들이 사이트가 느려지는 것을 발견하면 동일한 요구를 충족시키기 위해 다른 제품으로 빠르게 전환 할 것입니다. 느리고 깨진 것의 차이를보기가 실제로 어렵 기 때문입니다. 이러한 종류의 작업은 일반적으로 Z 일이 소요됩니다 (속도에 따라 DB 변경 최적화, 속도에 대한 리팩토링 및 코드 최적화)

반나절도 안되는 견적은 피하겠습니다. 그들은 당신이 무슨 말을하는지 알고 있다는 것을 어느 정도 신뢰해야 할 것입니다. 그리고 그들이 2 시간 밖에되지 않을 것이라고 생각한다면, SW 개발자의 삶에서 2 시간이 어떻게 생겼는지 정확히 안내하면서 2 시간 동안 함께 앉도록 초대하십시오. 약 2 시간 동안 문제 해결을 시작하기 위해 모두 고려해야 할 사항을 정확하게 보여줍니다.

가장 중요한 것은 다음과 같습니다.

• 고객 인식 및 제품 사용에 대해 가장 많이 이야기하고 구매하십시오. $의 언어-요점은 코드가 엉뚱한 방식으로 함께 해킹되면 결국 비즈니스를 잃을 것입니다. 이 기능에 대해서는 개발 관행이 열악한 경우 일부 후속 기능에서 코드를 확장 할 수 없게됩니다.
• 일련의 이벤트를 설정하십시오. 기술적이지 않은 다음 질문은 "우리보다 많은 개발자가 있다면 더 빨리 일어날까요? 그렇다면, 이것을 만들려면 40 시간이 걸리면 오늘 오후 40 명이 될 수 있을까요?"입니다. 물론 대답은 "아니오! 그러나 그것은 최고의 것이 아닙니다. 가장 좋은 방법은 여기에 논리적 단계가 있다는 것입니다. 일 A가 제자리에 올 때까지 B는 할 수 없습니다 (코드를 작성하지 않은 경우 실제로 최적화하거나 테스트 할 수는 없습니다 ...). A와 A '는 함께 할 수 있으므로, 저 똑똑한 사람을 살려 주면 1 주일에서 4 일로 시간을 단축 할 수 있고, 훌륭한 테스트 지원을 보장 할 수 있다면 아마도 3 일. 그곳에'
• 위험에 집중하고 현재로서는 일부 위험이 가치가 있다고 들으십시오. 이것이 바로 비즈니스 사람들이받는 큰 위험에 대한 보상입니다. 예를 들어, 회사에 짧은 시간에 엄청나게 많은 수의 서버를 준비 할 수있는 충분한 현금이 있기 때문에 시장 출시 속도가 좋지 않은 성능을 측정하는 경우 4 단계 (코드 / 데이터베이스 최적화)의 모든 항목을 건너 뛰라는 메시지가 표시 될 수 있습니다. ). 그것은 그들의 권리입니다-그 결정에 내재 된 위험을 설명하는 것은 당신의 일입니다.
• 그러나이 사람들을 믿지 않으면 서면으로 확인을 받으십시오. 대면 할 필요는 없으며 "내가 논의한 내용은 여기에 있습니다. 위험을 감수 할 것입니다. 지금 동의하지 않을 경우 알려주십시오. 연락이 없으면이 방법이 올바른 방법이라고 가정하겠습니다. " 제품 관리가 단기 기억 상실의 중심이 될 수 있다는 점을 감안하면 이는 모든 사람에게 도움이됩니다.

"5 파운드 봉지에 10 파운드의 쓰레기를 넣을 수는 없습니다"라는 말이 있습니다. 당신의 임무는 작업이 10 파운드이고 5 파운드 기간 내에 작업을 요구하고 있음을 보여주는 것입니다.

당신이 놓친 유일한 것은 시간 추정치입니다. 각 작업에 대한 시간 견적을 작성하고 이러한 모든 것들이 제공 한 견적에 어떻게 결합되는지 보여줍니다. 예상 시간이 4 시간을 초과하지 않도록하십시오. "하루"또는 "10 시간"이라고하는 작업이 있으면 작은 하위 작업으로 분류하십시오.

2h make some changes to Database
2h add front end HTML
   write server side code
     4h input validation
     4h database inserts
2h add validation
2h add client side javascript
   use unit tests
     2h client-side tests
     3h server-side tests
2h make sure SEO is setup is working
2h implement email confirmation
2h optimize DB changes for speed
2h refactor and optimize the code for speed

이제 품목별 비용 청구서가 있습니다. 모든 작업에는 총 27 시간이 소요됩니다.

이제이를 고객에게 보여주고 "각각의 비용으로 수행해야하는 작업"이라고 말할 수 있습니다. 시간은 비용이며 경영진은 비용을 이해하기 때문에 "비용"이라는 단어를 사용하십시오. 결국 두 가지 최적화 작업을 중단 할 수는 있지만 결과는 부정적인 영향을 미치며 전체 추정치의 15 %에 불과합니다.

또한 당신의 시간 / 일이 현실적으로 무엇인지 설명해야합니다. 예를 들어 기술 지원을 요청하거나 데이터베이스를 유지 관리하는 등의 요청을받은 경우이를 추정값으로 계산하십시오. "글쎄요, 하루에 7.5 시간 동안 좋은 코딩을 할 수 있습니다"라고 말하지 마십시오. 아마도 5 또는 6과 비슷할 것입니다.

그런 다음 가장 중요한 것은 진행 상황을 추적하는 것입니다. 하루에 5 시간 코딩을 할 수 있다고 가정하십시오. 그런 다음 월요일에 처음 두 작업 (제 예에서)을 시작하고 세 번째 작업을 마치고 화요일에 네 번째 작업을 시작할 수 있습니다. 수요일에 참석자들이 올 때이를 보여줄 수 있도록 점검 목록을 작성하여 "금요일까지 어떻게 진행될 것입니까?"라고 말합니다.

내 대화에 대한 슬라이드를보십시오. 위기 예방 : 몇 년 전에 OSCON에서 준 프로젝트 추정 및 추적 . 슬라이드 21, "주 계획"을보십시오. 도 있습니다 샘플 속도 차트 .

그들에게 묻다:

어떻게 하시겠습니까? 어떤 모듈을 변경 하시겠습니까? 몇 줄의 코드입니까? 보안 영향은 무엇입니까? 데이터베이스 스키마가 변경 되었습니까? DB를 변경하면 몇 개의 파일이 영향을 받습니까? 마지막 양식을 추가하는 데 얼마나 걸립니까? 양식을 추가하기위한 평균 (산술 평균)은 얼마입니까? 가장 긴 것은 무엇입니까? 가장 긴 시간보다 1 분 정도 덜 걸릴 것으로 예상합니다. 마지막 N 양식을 추가하는 데 걸린 시간을 모르는 경우이 추정값은 한 자릿수까지만 정확합니다.

나는 그들의 소프트웨어가 10,000 개의 다른 부품을 가진 100 톤의 기계와 같다고 설명 할 수있다. 대부분은 복잡한 방식으로 연결되어있다. 이 기계에 1 인치 크기의 부품을 장착하려면 약간의 엔지니어링이 필요하므로 기계가 파손되지는 않지만 더 좋은 대답은 다음과 같습니다.

더 나은 코드 아키텍처를 가지고 있다면 이와 같은 작업을 쉽게 수행 할 수 있습니까? 그리고 대답은 대부분의 소프트웨어 팀이 훌륭한 건축가가 아니라는 것입니다 (단순하고 건축적인 템플릿을 모으지 않았거나 모든 문제를 예상하기에 충분하게 문제 도메인의 마스터가 아니기 때문에) 항상 훌륭한 엔지니어는 아닙니다 따라서 그들은 견적을하거나 약속을한다고 확신하지 않습니다.

좋은 건축물과 큰 건물을 짓기위한 공학을 모으는 데 20 세기가 걸렸 듯이 소프트웨어 공학 도구는 아직 주류에 도달하지 못했습니다. 그들은 개발되고있다 : 새로운 사고 방식이 필요하다. wiki.hackerspaces.org/Hacking_with_the_Tao에서 Zen Code를 참조하십시오.