PM [닫힌] 경험이없는 지나치게 복잡한 설정을 선택하는 PM

최근에 나는 만들기가 너무 어려워 보이지 않는 프로젝트를 시작했습니다.이 개념은 매우 간단한 응용 프로그램으로, 매번 입력을 받아들이고 (하루에 10x 정도), 일부 작업을 수행하고 모든 결과를 수집하려고했습니다. 끝에. 이 응용 프로그램은 고객이 로켓 과학이 아니라 결과를 보는 데 사용할 수있는 프론트 엔드 웹 포털을 얻게됩니다.

이를 위해 처음에는 Python의 내장 동시성 라이브러리 ( ThreadPoolExecutor)를 현명하게 사용 하고 프론트 엔드에 사용하기 쉬운 라이브러리를 사용했습니다 (초보자에게는 쉽고 유지 보수가 쉽고 테스트하기 쉬운 Flask를 선택했습니다).

프로젝트가 반쯤 진행되면 PM은 스레드 대신 써드 파티 메시지 큐 기능을 사용해야하고로드 밸런싱을 구현해야한다고 결론을 내렸다. 결국 결국 Celery, Redis, RabbitMQ, Nginx, uWSGI와 협력하기 시작했다. 그리고 아무도 실제로 경험 한 적이없는 다른 대규모의 타사 서비스도 있습니다.

결국 이것은 많은 스파게티 코드, 테스트 할 수없는 작업 (타사 라이브러리의 복잡성, 코드 패치가 작동하지 않았기 때문에) 및 두통이 발생합니다. .

"예, 해당 서비스를 사용해야합니다"라고 말하기 전에 아무도 이러한 서비스 를 사용하는 방법을 모르 거나 경쟁 조건에 처한 코드를 도입하는 것 외에는 무엇을하는지 아는 사람이 없습니다.

이것에 대해 어떻게해야합니까? 이 시점에서 우리가 가진 것으로 되돌리려면 너무 많은 비용이 들며, 최종 제품이 처음보다 나빠졌지만 PM은 이러한 서비스를 사용하기 시작했습니다. 그와 논의 할 때도 쓸모가 있습니까? 더 많은 시간을 요청합니까? 아니면 가혹한 대답, 나는 내 직업에 너무 바보입니까?

우리가 프로젝트의 절반이되자 PM은 스레드 대신 써드 파티 메시지 큐 기능을 사용해야하고로드 밸런싱을 구현해야한다고 밝혔다.

이것은 PM이 일방적으로 "상태"하는 것이 적절하지 않습니다. 두 가지 이유 :

1. 기술 결정은 NFR 에 대한 응답으로 만 설계 결정을 내려야합니다 . 따라서 새로운 NFR이 있는지, 세부 정보를 가질 수 있는지 PM에게 정중하게 문의하십시오.

2. 프로젝트 중반에 NFR을 도입하는 경우 변경 관리 를 통해 수행해야합니다 . 거버넌스 관점에서 변경 제어는 매우 중요합니다. 그것은 단지 당신의 필요 조건에 입력 할뿐만 아니라 QA의 테스트 케이스에 중요한 입력하지 않을, 운영 '배포 및 지원 핸드북, 그리고 (여기가입니다 정말 는 PM의 중요한 부분) 일정 . 새로운 요구 사항이 더 많은 작업을 도입하는 경우 개발 팀은 새로운 개발 견적을 전달할 기회를 가져야하며 PM은 새로운 날짜로 살 수 있는지, 더 많은 리소스를 추가하거나 도입 한 이해 관계자를 밀어 넣을 수 있는지 결정해야합니다. NFR.

이제 선의의 NFR이 있고 해결 방법이 없다면 도입되는 기술에 익숙한 새로운 또는 다른 리소스를 요청하거나 기존의 일부에 대한 교육 예산을 요청하는 것이 적절할 수도 있습니다. 자원. 따라서 비용 측면도 있습니다.

PM의 언어 (일정 및 비용)를 말하면 개발자가 결과 디자인에 대해 어떻게 느끼는지에 대해 말하는 것보다 더 큰 관심을 끌 것입니다. 그것들은 실제 영향을 미칩니다.

PM은 거버넌스, 통제, 합의없이 이러한 것들을 즉석에서 도입하는 것보다 더 잘 알아야합니다. 그들이 그것을 얻지 못하면, 품질과 일정을 불필요하게 위험에 빠뜨리므로 제품 관리 또는 프로그램 관리로 이관해야 할 수도 있습니다.

어리석은 것은 자신이 죽음을 행진하게하는 것 입니다.

당신이 묘사하는 것은 비판적 느낌을 잃었다는 것입니다. 통제 의식이없고 그것에 대한 명확한 길은 없습니다.

마지막으로해야 할 일은 열심히 일하고 머리를 숙이고 마지막으로 프로젝트가 끝날 때까지 조용히 고통받는 것입니다.

당신이해야 할 일은 당신이 기대할 수있는 모든 권리에 대해 매우 열심히 생각하는 것입니다.

그들이 당신이 이해하지 못하는 기술을 사용하기를 원한다면, 당신은 그것들을 배울 시간을 기대해야합니다. 모르는 것을 부끄러워하지 마십시오. 당신의 무지를 곤경으로 사용하십시오. 그들이 당신에게 무언가를 요구할 때 이유를 물어보십시오. '왜냐하면'받아들이지 마십시오. '현대 모범 사례'를 수락하지 마십시오. 실제적이고 테스트 가능한 기대치를 얻지 않고서는 '확장 성'을 받아들이지 마십시오.

테스트 가능하다는 것은 그들이 하루 / 시간 / 분당 얼마나 많은 요청을 할 수 있는지 알려주는 것을 의미합니다. 해당 사양에 따라이 시스템을 실행하기 위해 무언가를 만들려고합니다.

이 방법으로 30 일 무료 평가판을 사용하여 원하는 최신 wiz bang이 그만한 가치가 있거나 이미 알고있는 것을 고수하는 것이 좋습니다.

이제 명심하십시오. 경쟁 조건에 시달리는 코드를 도입 한 도구는 아닙니다. 너희들 그렇게 했어 실행 취소 방법을 배워야 취소 할 수 있습니다.

그리고 아니 당신이 가진 것으로 되 돌리는 데 너무 많은 비용이 들지 않습니다. PM은 요구만으로 원하는 것을 가질 수 없습니다. PM이 원하는 것을 효과적으로 사용하거나 프로젝트가 필요하지 않다는 것을 증명할 수있을 때까지 뒤로 밀어야합니다.

진지하게, 이것에 포기하는 것은 비전문적이고 프로젝트에 치명적입니다.

나는 여기 사람이었다. 한 번 더. 그것은 당신이 바보처럼 느끼게합니다. 정말 그렇지 않습니다. 당신은 방금 잃었습니다.

PM과 대화하십시오. 솔직히 그것을 모두 배치하십시오. 배우고 싶지만 타고 가기를 원하지 않는다는 것을 보여주십시오. 결코 믿음을 기반으로 디자인하거나 코딩하지 마십시오. PM이 원하는 것을 수행하는 방법을 보여주십시오. 이해하지 못하는 척하지 마십시오. 그것이 끝나지 않을 것이라고 말하지 마십시오. 당신이 무언가를 믿는다면 자신을 믿는다. NO라고 기꺼이 말해야합니다.

그래도 문제가 해결되지 않으면 이력서를 빨리 ​​연마해야합니다. 한 가지 방법 또는 다른 방법.

이 문제는 실제로 소프트웨어 개발 문제가 아니라 작업장 관계에 관한 것이므로 실제로 workspace.stackexchange.com에 있어야합니다.

간단한 접근 방식이 효과가 있고 작업 결과를 빠르게 산출 할 것이라고 확신하는 경우 PM은 회사에서 제거해야 할 파괴적인 힘입니다. 뉴스를 그보다 높은 수준으로 올리는 방법을 알아보십시오. 팀에 좋은 진전을 보인 단순하고 효과적인 솔루션이 있었으며 아무도 PM을 설명 할 수없는 이유 때문에 다수를 사용하여 훨씬 더 복잡한 솔루션을 시도하도록 강요했습니다. 아무도 알지 못하고, 아무도 이해하지 못하고, 그들이 유용한 지 전혀 모르고, PM을 결정할 수없는 결정은 모든 문제를 일으켜 프로젝트를 늦게하고 작동하지 않게합니다.

경영진이 추구하는 맥락과 제품 전략을 알지 ​​못하면 객관적으로 질문에 대답하기가 어렵습니다.

여기에 몇 가지 객관적인 주장이 있습니다. 그러나 예상 한 결과가 아닐 수도 있습니다.

• " 아직 이 제품을 사용하는 방법을 아무도 모른다 " 는 점을 명심하십시오 .
• 완벽하게 알려진 도구와 기술 만 사용하면 생산성이 높아집니다. 그러나 혁신 능력이 상당히 제한 될 것입니다. 일부 시장에서는 제품에 치명적일 수 있습니다. 예를 들어, 거의 30 년 전에는 Windows 3.0을 사용하여 MS-DOS에서 성공한 새로운 버전의 CAD 제품을 개발할 것을 제안했습니다. 제품 관리자가이 그것을 "고, 어쨌든 팀을 위해 배우고, 너무 복잡하고 너무 어려울 것으로 입증 된 환경 아니라는 것을 반대 Windows가 주류 환경 없을 것 "... 나는 당신의 성공을 생각하자 2 년 후 그의 제품.
• 그것은 모두 비용과 이익의 문제입니다. 실험 비용과 확장 성 및 배포 가능성의 이점은 대규모 설치와 많은 작업량을 경험 한 타사에 의해 보장됩니다.
• 적절한 기술 교육을 받거나 숙련 된 컨설턴트의 초기 지원 / 코칭을 통해 새로운 기술 추가의 단점을 완화 할 수 있습니다.

궁극적으로 경제적 인 선택은 제품 관리자의 책임입니다. 그와 함께 장단점을 논의하여 그가 정보에 입각 한 결정을 내리고 추가 복잡성을 과소 평가하지 않도록하십시오. 그가 자신의 궤도에 머무르면 최선을 다하려고 노력하십시오. 느슨하게 할 것이 없으며 최악의 경우 이력서에 새로운 기술이 생깁니다.

타사 라이브러리 (및 기타 구성 요소)에는 두 가지 접근 방식이 있습니다.

1. 최대한 많이 사용하십시오
2. 가능한 적게 사용하십시오

내 접근 방식은 (2)입니다. 접근 방식도 (2) 인 것처럼 들리지만 프로젝트 관리자는 접근 방식을 좋아합니다 (1).

이 상황을 처리 할 수있는 세 가지 방법이 있습니다. PM이 원하는 PM을 수행하도록하거나 PM이 타사 라이브러리에 대한 접근 방식을 변경하도록 발언하거나 발로 투표하고 다른 직업을 선택하십시오.

PM에게 접근 방식을 변경하도록 설득하려면 다음 인수를 고려하십시오.

• 배울 시간. 각 외부 라이브러리는 학습하는 데 시간이 필요합니다.이 시간에 유능한 프로그래머는 특히 수백 줄의 코드로 수행 할 수있는 매우 간단한 작업을 수행하기 위해 거대한 라이브러리를 선택한 경우 원하는 기능을 작성할 수 있습니다.
• 교체 성.외부 라이브러리가있는 경우 개발이 중지 된 경우 다른 유사한 라이브러리로 대체 할 수 있는지 어떻게 확인합니까? 내 솔루션은 가능할 때마다 외부 라이브러리를 피하는 것이 가능하며 가능하지 않을 때마다 원하는 프로그래밍 인터페이스의 일부를 추상화하는 간단한 래퍼를 작성합니다. 일반적으로 원하는 인터페이스는 라이브러리가 제공하는 인터페이스보다 훨씬 간단합니다. 그런 다음 내 코드는이 래퍼를 통해서만 외부 라이브러리에 액세스하므로 쉽게 교체 할 수 있습니다. 일부 프레임 워크에서 전체 응용 프로그램을 작성하는 것은 큰 일이 아닙니다. 서블릿? 예, 그들은 오랫동안 여기에 있었고 앞으로도 계속 여기에 있습니다. 템플릿 엔진? 그렇습니다. 정확하게 교체 할 수는 없지만 (보통 하나를 고르고 그대로 유지), 가져 오는 가치는 엄청납니다. 따라서 템플릿 엔진을 전환 할 때 동일한 응용 프로그램에 두 개의 템플릿 엔진이있을 수 있지만 일반적으로 동일한 응용 프로그램에 두 개의 프레임 워크가있을 수는 없습니다. 아파치 스트럿츠? 아니요, 프레임 워크는 빠르게 유행에 빠지거나 빠르게 사라집니다. 일반적으로 동일한 응용 프로그램에 두 개의 프레임 워크를 가질 수 없습니다.
• 지옥 버전. 외부 라이브러리를 선택하면 보안 취약점을 피하기 위해 외부 라이브러리를 업데이트해야하며 업데이트하면 문제가 발생할 수 있습니다. 잘 디자인 된 구성 요소 (예 : Java JRE)는 다른 버전과 호환되지만 내 경험에 따르면 대부분의 라이브러리는 거대한 버전 지옥을 강요하기 때문에 쓰레기입니다. 또한 구성 요소 X에는 Z 버전 1이 필요하고 구성 요소 Y에는 Z 버전 2가 필요할 수 있으며 동일한 응용 프로그램에서 Z 버전 1과 Z 버전 2를 반드시 연결할 수있는 것은 아닙니다.
• 보안 취약점. 외부 라이브러리를 선택하면 응용 프로그램에 대해 쉽게 악용 할 수있는 보안 취약성이 증가합니다. 일부는 사내에서 개발 한 코드가 모호함을 통해 보안과 유사하다고 주장 할 수 있지만, 여전히 보안의 한 형태라고 말할 수 있습니다.
• 라이센스 문제. 각 외부 라이브러리는 프로그램의 일부에 자체 라이센스를 부여합니다. 예를 들어, GPL 라이브러리는 비 GPL 프로그램에서 사용할 수 없으며 LGPL 라이브러리는 바이너리와 함께 소스 코드를 배포해야하므로 상당한 양의 대역폭이 필요할 수 있습니다.
• 응용 프로그램 시작 시간 각각의 큰 외부 라이브러리는 응용 프로그램의 시작 시간을 느리게합니다. 사내에서 간단한 마른 라이브러리를 작성하면 응용 프로그램의 시작 시간을 훨씬 빠르게 할 수 있습니다.
• 메모리 풋 프린트. X가 Y를 요구하고 Z가 A를 요구하고 B가 필요하면, 동시에 메모리에 X + Y + Z + A + B가 필요합니다. X와 동등한 기능 만 구현하여 사내에서 X '라고 부르면 메모리에 X'만 있으면됩니다. 그리고 일반적으로 X '의 메모리 풋 프린트는 X의 메모리 풋 프린트보다 작습니다.
• 버그 위험. 외부 구성 요소에 줄이 많을수록 이해해야 할 엄청난 양의 코드로 인해 수정하기 어려운 버그가 발생할 위험이 높아집니다. 사내에서 작업을 수행하는 경우 일반적으로 코드 줄이 적어 (필요한 작업 만 수행) 다른 작업을 수행하므로 버그 위험이 줄어 듭니다.
• 커스터마이즈 가능성. SQL 쿼리를 직접 작성하면 쿼리의 모양과 주어진 데이터베이스 엔진 및 지정된 인덱스 집합에서 쿼리의 성능을 알 수 있습니다. 반면에 SQL 쿼리가 외부 구성 요소에 의해 작성되면 성능에 대해 아무것도 모릅니다. 나는 각 웹 페이지를 가져 오는 데 몇 초가 걸렸던 회사에서 일했습니다. 필요한 것은이 특정 항목과 관련된 모든 항목이 아닌 하나의 항목 일 때 데이터베이스에서 너무 많은 데이터를 자동으로 가져 오는 데 사용 된 Hibernate 라이브러리 인 것 같습니다. 나는 많은 수의 기존 라이브러리를 사용하는 접근 방식이 마음에 들지 않기 때문에 속도 저하의 진정한 원인을 발견하기 전에 회사를 떠났습니다.

라이브러리가 프레임 워크를 호출하는 경우 특히주의하십시오 . 즉, 라이브러리를 사용하려면 전체 애플리케이션을 자체 빌드해야합니다. 일반적으로 동일한 응용 프로그램에 두 개의 프레임 워크를 가질 수 없습니다. 그들은 평화롭게 공존하지 않고 서로 싸울 것입니다. 웹 개발 유틸리티 라이브러리? 예, 제발,이 중 너무 적습니다. 지금 사용하는 것보다 더 나은 라이브러리를 찾은 경우 새 코드에서 새로 찾은 라이브러리를 사용하면서 이전 코드에서 이전 라이브러리를 계속 사용할 수 있습니다. 웹 개발 프레임 워크? 큰 호닝 NO!

PM은 운영 중 많은 유지 보수 작업을 수행하여 수입을 보장하는 관리하기 어려운 시스템을 목표로하고 있다고 생각합니다.

개인적으로, 당신은 파이썬에 갇혀있는 것처럼 보이고, 잠시 동안 파이썬을 잊어 버리고, 1 년 동안 파이썬으로 코딩하지 말고, 새로운 것을 배우십시오. 동일하고 더 나은 다른 언어가 있다는 것을 알 수 있습니다.

다른 사람들이 말했듯이, 도구를 사용하기 전에 도구를 배우십시오. 해당 작업에 적합한 다른 도구의 연구를 기반으로 필요한 스택을 함께 평가하는 것이 좋습니다. 또는 그 목록을 어떻게 작성했는지 물어보십시오. 그는 최신 사람의 도움을 받았을 수도 있습니다.

개발자는 새로운 라이브러리, 프레임 워크, 기술 등을 사용하는 법을 배우는 것을 두려워해서는 안됩니다. 이는 개발자의 직무 설명의 핵심 부분이며, 누군가가 가지고 있지 않은 제 3 자와 함께 작업하는 팀을 제안하는 것은 누군가에게 완벽하게 합리적입니다 팀이 팀에 대해 권위있는 기술적 결정을 내릴 수있는 위치에있는 경우 팀에 대한 경험 또는 요구를 요구합니다.

그러나, 하지 그냥하자 (혼자 새로운 기술을 당길 수 있다고 기대하는 것이 합리적 한 번에 여러 가지 새로운 기술을)를 스택에 넣고 계속 진행하십시오. 새로운 접근 방식의 장단점을 배우고 새로운 제품을 통합하기위한 좋은 디자인을 파악하는 데 상당한 시간이 계획되어 있어야합니다.이 과정에서 실제 제품에 대한 실제 진전이 예상되지 않습니다 (이 학습 / 디자인 작업을 수행하는 사람들로부터) 팀 전체가 아닐 수도 있지만, 팀이 아닌 다른 팀에게 지식을 전달하는 법을 배운 사람들을 위해 더 많은 시간을 계획해야 할 수도 있습니다. 이것이 이런 종류의 주요한 변화를 일으키는 비용입니다. 새로운 기술을 배우는 것은 개발자의 일의 일부이지만 시간이 전혀 들지 않는 일이 아닙니다.

그것은 질문에서 발생하지 않은 것처럼 들립니다. 사람들은 자신이 이해하지 못한 기술을 바탕으로 어떻게 좋은 구현을 만들려고 노력하고 있습니다. 물론 결과 코드는 끔찍합니다.

회사가 당신의 오후 설득하려고 합니다 이것에 더 많은 시간을 할애 할 필요가 있습니다. 그것은 지금 멈추고, 새로운 기술을 배우고 평가하며, 좋은 디자인을 찾고, 현재 구현 엉망을 정리하는 형태 일 것입니다. 또는 버그, 유지 관리, 비용이 많이 드는 개발 등에 더 많은 시간을 낭비하게됩니다.

질문에 설명 된 기술적 선택 (로드 밸런싱, 메시지 대기열 등)이 실제로 적절한 지 여부를 말하기는 불가능합니다 . "팀에서 아무도이 일을 해본 경험이 없다"고 판단하는 것이 절대적으로 결정을 배제 할만한 좋은 이유라고 생각 하지는 않지만 결정을 내리는 데 소요되는 단기 비용 이 증가합니다 ( " 상황에 대한 최선의 결정 "), 그리고 PM이이를 고려하지 않고 경험있는 사람들처럼 팀이 즉시 생산성을 발휘할 것으로 기대하는 경우, 그 근거를 뒤로 밀어야합니다. 그들은 매우 비현실적인 프로젝트 일정을 수립 할 것이며, 이는 누구에게도 가장 큰 관심사가 아닙니다.