오버 헤드 API / 기술을 어떻게 다루나요?

11

나는 대부분의 사람들이 이런 상황에 처한 것 같아

초기 프로젝트 계획이 시작됩니다. 요구 사항이 요약되어 있습니다. API / Frameworks를 통한 아키텍처 검토 및 정렬 후 피팅 기술이 선택됩니다. 개발이 시작됩니다.

그런 다음 시작됩니다. 간단한 지원 작업을 수행하자마자 프레임 워크 / API가 역효과를 일으키기 시작하고 어떤 작업을 수행하는 대신 기술에 맞서 싸우게됩니다. 연구 시간이 급증하고 포럼이 조용하고 아무런 조치도 취하지 않은 것으로 나타 났으며 작업 할 내용이 있어도 제대로 완료되었는지 확실하지 않습니다.

이러한 상황에서 어떻게 관리합니까? 해킹을 원하십니까? 더 조사하고 경영진에게 무엇을 말합니까?

technology research

— 코더
소스

+1 : 정말 좋은 질문입니다. +10의 가치가있는. 나는 같은 경험을했습니다.

— Jim G.

좋은 질문입니다. "leverage"와 "synergy"와 같은 단어가 타사 제품을 판매하는 데 사용 된 것을 여러 번 보았습니다. 그래서 당신은 그것에 갇히게됩니다. 그리고 그들은 당신 아래에서 그것을 빼냅니다. (MS는 그 일을 좋아합니다.) 한편, 원래 복음 전파자들은 오랫동안 사라졌습니다.

— 마이크 던 라비

9

프로토 타입, 프로토 타입, 프로토 타입 !!

팀이 특정 프레임 워크에 익숙하지 않은 경우, 문제점을 파악할 수 있도록 무언가 프로토 타입을 프로토 타입하십시오.

Matt Raible (Java Web framework comparator guy)은 가능한 경우 일주일 동안 프레임 워크 작업을 제안합니다.

프로토 타이핑에는 프레임 워크 및 기타 요인에 대한 커뮤니티 지원 조사가 포함됩니다.

— 마틴 버 부르크
소스

프로토 타입의 경우 +1 덕트 테이프와 함께 붙이고 막대기로 올려 놓아도 실제로 작동하는 것이 있고 5 분 동안 그대로두면 충돌이 발생할 수 있습니다.

질문에 표시된대로 초기 프로젝트 계획이 시작되면 프로젝트 진행이 이미 제공되어 이미 고객에게 판매되었음을 의미합니다. "프로토 타이핑"이없고 시간 단위의 비용이이 WBS에 도입되면 프로토 타이핑이 없습니다. 이상적으로는 솔루션을 판매하기 전에이 문제가 발생하기를 원할 것입니다. 따라서 하나 이상의 프로젝트가 역할을 수행하기 전에. 프로젝트가 시작되기 오래 전에 필요한 시간과 평가의 일부로 "프로토 타이핑"을하고 싶습니다. 솔루션을 원하기 때문에 대부분의 고객에게는 어려움이 따릅니다.

— edelwater

en dan willen ze ook nog de exacte 서버 사양 van te voren ....

— edelwater

6

외부 종속성 관리는 많은 IT 프로젝트의 단점입니다. 몇 년 전 제가 함께 일한 숙련 된 프로그래머들은 항상 소스 코드 라이센스를 구매해야한다고 주장함으로써 항상 의존성을 통제 할 수있었습니다.

개인적으로, 그것은 나의 접근 방식이 아닙니다. 나는 생각의 학교를 넘나 드는 약속 아래있는 경향이있다. 목을 내 밀어야 할 때가 있지만 99 % 확신을 얻기 위해 사전에 사적인 조사를합니다. 일반적으로 기술을 제공 할 수 있도록 종종 제 시간에 개인 프로젝트를 수행합니다. 실제로 프로토 타입, 테스트, 검증 및 약속합니다.

내가 체포되는 상황이 있습니다. 역 추적이거나 창의력이 있어야합니다. 풍부한 경험을 가진 창조적 인 마음을 갖는 것이 여기에 도움이되지만 다른 사람들과 대화하는 것도 도움이됩니다. -항상 프로그래머는 아닙니다. 때로는 해결책이 정말 이상한 곳에서 나옵니다.

관리를 다루는 데있어 핵심은 정직입니다. 일찍 그리고 자주 이야기하십시오. 큰 배달 전날 관리자 / 고객을 실망 시키면 아마추어처럼 보이게되므로 마지막 순간까지 그대로 두지 마십시오. 마감 기한 2 개월 전에 관리자가 몇 가지 기능을 삭제하거나 배송 지연을 선택해야한다는 점은 당시에는 인기가 없었지만 나머지 조직은 업무를 수행하고 계획을 수립 할 수있었습니다. . 이를 수행 할 수있는 열쇠는 시간과 작업 추정치를 추적하는 좋은 작업 관리 시스템을 갖추는 것입니다. 당신의 관점을 뒷받침 할 확실한 증거를 가지고 있으면 당신의 말을 잘들을 수 있습니다.

— 마이클 쇼
소스

나는 당신이 여기에 언급 한 것과 똑같은 일을 많이했으며 그것은 저에게 매우 효과적이었습니다. 내가 아는 한, 내가 일한 고객은 내가 기대했던 것보다 일반적으로 초과했기 때문에 내가 제공 한 것에 매우 만족했다. 또한 상황이 어떻게 진행되고 있는지, 문제가 발생한시기와 그 영향에 대한 커뮤니케이션에 감사했습니다.

— Ken Henderson

2

"이러한 상황에서 어떻게 관리합니까?" 내가 본 / 경험 한 것 :

내가 프톨레마이오스에 동의하는 1 번 포인트 : 정직하게 :

그것이 실제로 문제가되는 경우 : 그 방으로 가서 문제를 말하고 분노의 응답을 기다렸다가 새로운 계획 / 해결을 위해 노력하십시오. (남자는 개인적으로 화를 내지 않습니다).

이 상황만을 다루는 IT 과정이 있습니다. 당신은 배우와 함께 배치되며 그들은이 뉴스를 듣고 화가 클라이언트를 배치합니다. 당신은 그 주위에 많은 팁을 얻습니다. 어리석게 들릴지 모르지만 아마도 그렇게 한 후에야 그 가치를 알 수 있습니다. 나는 그 상황에서 기억하기 위해 80 점이있는 시트를 남겼습니다 ... (및 연습).

이러한 상황은 일반적으로 예산이 빡빡하고 판매가 "가장 낮은 제안"으로 수행되고 고객이 승인 한 계획이 고객이 수락하기 전에 5 배로 줄어드는 현재 상황 일 것입니다. 당신은 전문가이기 때문에 그렇지 않으면 10 명의 다른 사람들이 기다리고 있습니다 ") 등 ...

-또 다른 측면은 측면 사고 일 수 있습니다. 이런 방식으로 수행 할 수없는 경우 고객에게 동일한 가치를 제공하는 완전히 다른 것을 제안하십시오. 기술이 전혀 작동하지 않거나 거래 / 파산 등에서 벗어날 경우 ... 고객이이를 구매하면 결국 동일한 가치를 제공 할 수 있습니다. 그러나 그것을 가져 오는 것도 꽤 어렵습니다. (일부는 다른 사람에게는 그렇지 않음). 당신은 이것을 위해 정말로 경험이 많은 사람들이 필요합니다. 마찬가지로 기술이 아직까지는 그렇지 않다는 것입니다. 몇 개월이 걸리므로 고객에게 재 계획을 세우고 조직에 미치는 영향을 수용하도록 설득해야합니다 ...

-또 다른 '학습자'는이 방향으로 진행되는 것을 알게 되 자마자 선임 선배들을 불러내는 것입니다. 그들은 종종 문제가있는 프로젝트를 처리했으며 이러한 상황에서 실제로 도움이됩니다. 종종 문제가있는 프로젝트에서 문제가있는 프로젝트로만 이동합니다.

-또 다른 교훈은 특히 건축 프로젝트가 대규모 프로젝트에서 검증 채널을 통과하도록하는 것입니다. 서명은 엉덩이를 덮을 수 있습니다. (모든 이메일을 LOL에 저장하십시오)

— 에델 워터
소스