작업을 나열하는 것은 거의 완벽한 일이지만 엔지니어에게는 완벽한 의미의 작업은 비 기술적 인 사람에게는 거의 의미가 없다는 것을 명심하십시오. 예를 들어, 위의 목록에서 “속도에 맞게 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 단계 (코드 / 데이터베이스 최적화)의 모든 항목을 건너 뛰라는 메시지가 표시 될 수 있습니다. ). 그것은 그들의 권리입니다-그 결정에 내재 된 위험을 설명하는 것은 당신의 일입니다.
• 그러나이 사람들을 믿지 않으면 서면으로 확인을 받으십시오. 대면 할 필요는 없으며 “내가 논의한 내용은 여기에 있습니다. 위험을 감수 할 것입니다. 지금 동의하지 않을 경우 알려주십시오. 연락이 없으면이 방법이 올바른 방법이라고 가정하겠습니다. ” 제품 관리가 단기 기억 상실의 중심이 될 수 있다는 점을 감안하면 이는 모든 사람에게 도움이됩니다.

답변

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