아주 적은 시간에 중요한 기술적 결정을 내리는 방법


36

회사에서 WPF 응용 프로그램을 Linux / Android / iOS로 이식하기 위해 사용할 도구 및 플랫폼에 대해 매우 진지한 결정을 내리는 데 2 ​​일이 걸렸습니다.

분명히 나는 ​​2 일이면 모든 가능한 옵션과 시도, 프로토 타입 제작 등을 읽는 데 충분하지 않다고 말할 수 있습니다. 말할 수 있습니다. 약간 도움이되지 않습니다 .2 일이 있습니다. 2 일 후에 결정이 내려 질 것이다. 기간.

한쪽에서 나는 좌절하고 다른 쪽에서이 접근법에 진실이 있다고 생각합니다. 그렇지 않으면 벤치 워크, 샘플 실행 등 다운로드 된 SDK, 프레임 워크, API, 블로그 기사 등 수십 가지에 묻혀 있습니다. 그 과정에서 모든 것이 무엇인지 잊어 버렸습니다.

여전히 잘못된 결정으로 인해 회사에 막대한 비용이 소요 될까봐 두렵습니다. 그렇다면 그러한 결정을 내리는 "이상적인"프로세스는 무엇이라고 생각하십니까?


4
이틀 안에 결정을 내리는 것이 거의 불가능한 곳에 쓰십시오. 그리고 나쁘지 않은 결정을 내리고 결정이 최선이 아니라는 것을 문서화하십시오. 다시 말해, 엉덩이를 가리십시오. Qt5 가 고려 될 수 있습니다. 또는 제품을 HTML5 웹 응용 프로그램으로 만들 수 있습니다 ( libonion 또는 FastCGI와 같은 일부 HTTP 서버 라이브러리 사용 )
Basile Starynkevitch

2
@gnat 나는 하나 이상의 가능한 답변이 여전히 있지만 우리 모두가 다른 경험에서 얻을 수있는 주관적인 질문이라는 것에 동의하지 않습니다.
Flot2011

9
많은 경우 '최상의 옵션'이 없으며 PHP 웹 응용 프로그램으로 작성할 수 있으며 작동합니다. 또는 Qt 프로그램으로 작성할 수 있으며 작동합니다. openGL 게임 인터페이스 UI 일 수 있습니다. 이것들은 모두 수용 가능한 선택입니다. 트릭은 하나를 선택한 다음 작동하도록 설정하는 것입니다. 일단 무언가를 선택하면 의심으로 자신을 마비시키지 마십시오.
gbjbaanb

5
예제의 경우 Xamarin이라는 확실한 기술이 있기 때문에 매우 나쁜 예입니다. .NET 백엔드 코드를 유지하고 UI를 무언가로 바꾸십시오. 주어진 모든 경우를 처리합니다. 따라서 이것은 ".NET 용 크로스 플랫폼 시스템에 대해 이제 아무것도 알고 있습니다"의 경우입니다.
TomTom

7
2 일이 충분하지 않다고 말하는 것은 그리 건설적이지 않습니다. 3 일이면 충분할까요? 아니면 실제로 2 개월을 보내고 싶습니까? 그리고 당신의 결정이 얼마나 좋을까요? ~~~~ 만약 당신이 일주일이 필요하고 이것이 수백 시간의 개발 시간을 쉽게 절약 할 것이라고 확신한다면, 이것을 언급하십시오. 도움이되지는 않지만 이해 관계자가 비즈니스 사례를 좋아할 가능성은 항상 있습니다.
데니스 Jaheruddin

답변:


48

당신이 가진 모든 것이 2 일이고 모든 대안을 프로토 타입하거나 읽을 수있는 시간이 없다면 실제로 2 가지 옵션 만 있습니다.

  1. 알고있는 사람에게 조언을 구하십시오. 이것은 반드시 개인에게 물어 보는 것이 아니라 2 일 동안 블로그와 기사를 검색하여 정보를 조금 더 잘 알지 못하는 결정을 내릴 수있는 충분한 정보를 수집하는 데 소요됩니다.

  2. 모든 주요 옵션에 대해 약간의 연구를 한 다음 하나를 선택하십시오. 때때로 리더십은 잘못된 결정을 두려워하지 않는 것을 의미하며, 종종 결정을 내리는 것보다 확고한 결정을하는 것이 더 중요합니다.

클라이언트와 서버 모델을 사용하면 UI 기술을 최소한의 중단으로 다른 UI로 교체 할 수 있습니다.


10
"잘못된 결정을 두려워하지 마십시오"+1 때로는 '분석 마비'에 걸리는 것이 전혀 결정하지 않는 것보다 나쁩니다. 우리는 모두 인간입니다. 최선을 다하고 인생을 즐기십시오.
semaj

1
vacillate : 다른 의견이나 행동 사이에서 번갈아 가거나 흔들리는 행위; 결단력이있다
TankorSmash

10
"더욱 분리되어 변경하기 쉬운 아키텍처를 생각해
냄으로써

2
@emodendroket Windows Workflow Foundation.
MetaFight

2
문제 가 주류가 아닌 경우 주류 솔루션이 제대로 작동하지 않을 것으로 기대하십시오. 디커플링과 유연성이 중요한 부분 입니다. 그들이해야 할 일을 예상하지 못한 것처럼 기대에 부응하는 대신 자신의 일을 쉽게 수행 할 수있는 프레임 워크 / 라이브러리를 찾으십시오.
jpmc26

19

스트림을 거스르는 것처럼 보이지만 최근 에 Ed Catmull의 Creativity, Inc. 라는 책을 읽었 으며이 상황을 다루는 정말 멋진 단락이있었습니다.

앤드류 스탠튼은 다음에 말했다. 앤드류는 사람들이 가능한 빨리 잘못해야한다는 것을 좋아합니다. 전투에서 두 언덕을 마주하고 어느 언덕을 공격할지 확실치 않다면 올바른 행동은 서두르고 선택하는 것입니다. 언덕이 잘못되었다는 것을 알게되면 돌아 서서 다른 언덕을 공격하십시오. 이 시나리오에서는 용납 할 수없는 유일한 행동이 언덕 사이 에서 진행됩니다.

나는 그것이 당신의 상황에도 적용될 수 있다고 확신합니다. 어쩌면 오늘 결정을 내리고 결정을 내릴 수 있습니다. 그것이 효과가 있다면, 당신은 이틀 안에 무언가 준비가되어있을 것입니다. "나는 이것을 골랐다. 나는 몇 가지 테스트를 실행했기 때문에 우리가 할 수있는 것을 보여줄 수있다 ...". 고른 솔루션이 가치가 없다는 것을 하루 만에 알게되면 다른 솔루션을 선택하고 다음날 그 솔루션을 사용할 수 있습니다. 최악의 시나리오는 두 플랫폼을 테스트하기 위해 이틀을 사용한다는 것입니다. 두 플랫폼 중 어느 것도 작동하지 않는다는 것을 알지만 궁극적으로 정답입니까? 잡초를 꺼내고 잘못된 선택을 제거하십시오. 따라서 다음 결정은 이전 결정보다 훨씬 낫습니다. 가장 좋은 시나리오는

분명히 당신은 이틀 안에 어떤 플랫폼도 마스터하지 않을 것이지만, 가능한 빨리 하나를 선택하면 그것이 어떻게 작동하는지에 대한 더 나은 관점을 제공 할 것입니다 (읽는 것보다 훨씬 더).


12
전 세계적으로 당신과 동의하지만 때때로 전쟁터에서 돌진하는 것은 꽤 자살입니다.
Flot2011

그러나 돌진을 언급 한 사람은 없습니다. 나는 오늘 상사에게 걸어달라고 말한 적이 없다. "여기 해결책이 있습니다. 대신 나는 머리에서 하나를 선택하고 그것을 실행하고 땜질하려고합니다. 단순히 그것에 대해 읽고 다른 사람과 토론하면 속임수가 없습니다. 나는 그것을 시도하고 그것을 시도하면 품질이 훨씬 높은 선택으로 이어질 것이라고 믿습니다.
Michal

6
@ Flot2011 비록 MBA가 있다면, 당신은 현재 위치를 유지하고 언덕에 맞서 싸울 모든 부대를 보냅니다. 그들이 모두 죽으면, 오, 잘, 당신은 더 많은 병력을 얻고 계속하지만 이번에는 일반적으로 당신의 경험이 당신을 훨씬 더 많이 만든다고 ...
gbjbaanb

1
"한 번에 최대한 빨리 프로토 타입을 선택하면이 상황에서 매우 나쁜 조언이됩니다. 예, 프로토 타이핑은 중요하지만 시간이 많이 걸립니다. 사소한 문제는 종종 두 가지 이상의 해결책을 가지고 있으며, 이틀만으로 여러 기술을 프로토 타이핑하기에는 충분하지 않습니다.
meriton-파업에

@meriton 나는 당신이 의미하는 바를 느낍니다-프로토 타이핑은 시간이 많이 걸린다는 데 동의합니다. 나는 "프로토 타이핑 (do prototyping)"을 명시 적으로 언급하지 않았다. 그래서 나는 땜장이 라는 단어를 신중하게 선택했다 . 의사 결정자는 모든 세부 사항을 올바르게 얻을 수는 없지만 시행 착오를 통해 의사 결정의 질을 확실히 향상시킬 수 있습니다.
Michal

10

gbjbaanb는 몇 가지 좋은 점을 지적합니다. 방금 조금 추가한다고 생각했습니다.

완벽한 정보에 근거한 결정을 내릴 시간이 충분하지 않은 것은 분명합니다. 유일한 선택은 미래의 고통을 최소화 할 결정을 시도하는 것입니다. 나는 제안 할 것이다 :

  1. 상황의 특성을 명확하게 문서화하십시오. 관리자에게 이메일을 보내고 관리자와 이해 관계자에게 참조하십시오. 배정 된 문제는 까다 롭지 만 모든 것을 기꺼이 제공 할 것이라고 설명하십시오. 그러나 시간 제약이 엄격하면 찾은 결과가 최적임을 보장 할 수는 없습니다.

  2. 크고 활발한 온라인 커뮤니티가있는 프레임 워크 / 플랫폼을 찾으십시오. 마지막으로 원하는 것은 모호한 프레임 워크 만 디버깅하는 것입니다.

  3. gbjbaanb가 이전에 언급했듯이 느슨하게 결합 된 아키텍처를 사용하여 포팅 고통과 위험을 완화하십시오. 선택한 기술 중 하나를 사용하여 모든 것이 배 모양으로 바뀌면 쉽게 교체 할 수 있습니다.

나는 전에 당신의 상황에 있었고 결국 정치적 악몽으로 변했습니다. 시스템이 마술처럼 작동하지 않을 때 사람들은 손가락을 가리 키기 시작했고 일이 추해졌습니다. 그렇기 때문에 제 1 추천은 당신이 불가능한 승률에 대해 최선을 다 했다는 것을 명확하게 문서화하는 입니다.

행운을 빕니다 :)


17
다시 : # 1. 멍청한 패자를 좋아하는 사람은 아무도 없기 때문에 불가능한 상황에 대비하여 최선을 다했다는 것을 강조하면 팀을이기는 선구적인 승자처럼 보입니다! 경영진은 그런 종류의 것을 좋아합니다. 또한 큰 재 작성이 작동하지 않는 데는 여러 가지 이유가 있습니다. 한 기술을 다른 기술보다 선택하는 것이 일반적으로 가장 적은 문제입니다.
gbjbaanb

네, 약간 위스키라는 것을 깨달았습니다.
MetaFight

개인적으로, 나는 불확실성의 심각성을 명시하지 않기 때문에 "최적이 아닌 것"보다 더 구체적 일 것입니다. "완벽 할 필요는없고 충분하다"는 정신을 가진 관리자는 기술이 충분하지 않을 수도 있다는 말을 알지 못하면서이 경고를 무시할 것입니다.
meriton-파업에

3
대신 구체적인 위험을 파악하여 관리 부서에 전달할 것입니다. 예를 들면 : "우리는 현재의 지식을 바탕으로 기술 A가 최선의 선택이라고 생각합니다. 그러나 마감 시간이 짧기 때문에이 접근 방식이이 시스템에서 예상되는 작업 부하를 처리 할 수 ​​있는지 확인할 수 없었습니다." 그런 다음 경영진은 위험을 수용하거나 추가 분석을 주문하여 위험을 줄일 수 있습니다.
meriton-파업에

포인트 1은 +1입니다. 2. 성숙하고 잘 발달 된 커뮤니티가있는 솔루션을 찾으십시오. 하나 이상의 솔루션을 사용하는 경우 언제든지 온라인 포럼, 블로그를 탐색하고 질문을 게시하고 자신에게 적합한 것을 찾을 수 있습니다. 최고
Arnab Bhagabati

5

그들이 모자에서 후보자를 뽑는 것보다 더 많은 일을 할 시간이 거의 없기 때문에 다음과 같은 접근법을 채택 할 것입니다.

다음과 같은 기술을 선택하십시오.

  • 대규모 사용자 기반 보유
  • 모든 채널을 통해 적극적으로 지원
  • 적극적으로 개발되고 있습니다

정의상, 이것은 최첨단 기술을 배제 할 것이지만, 좋을 수도 있습니다.

또한 개발자가 Fred가 과거에 사용해 왔기 때문에 추가 분석없이 기술 X 를 사용하려는 충동에 저항하십시오 . 완벽하게 적합하지는 않으며 Fred가 더 친환경적인 목초지로 이동하면 도메인 전문가가 있습니다.


기술 X가 충분히 적합하고 Fred가 다른 개발자를 기꺼이 교육하려는 경우 그렇게하는 것이 팀을 시작하는 좋은 방법 일 수 있습니다.
CVn

확실히 – 다른 박스를 체크하면 ...
Robbie Dee

4

2 일은 그런 종류의 결정을 내리기에 매우 짧은 기간이지만 다음 2 일 목록에서 결정해야하기 때문에,

  1. 대상 플랫폼은 무엇입니까
  2. 현재 앱에서 포팅하는 데 많은 노력이 필요할 수있는 사용자 지정 / 타사 구성 요소는 무엇입니까? 예 : 차트 구성 요소, 그리드 구성 요소,보고 구성 요소 등
  3. 현재 앱이 세계에 어떻게 연결되고 보안이 처리되는 방식 (데이터베이스 연결 / 웹 서비스 등)
  4. 배포 방법 및 업데이트 제공 방법

이제 모든 대상 환경에 사용할 수있는 대안을 찾아야합니다.

각 대안에 대해 현재 앱에서 사용중인 연결 / 보안을 사용하기위한 지원을 찾으십시오.

그런 다음 각 사용자 지정 / 타사 구성 요소에 대해 각 구성 요소를 쉽게 사용할 수 있는지 확인하십시오.

그런 다음 발견 한 각 대안에 대해 어떻게 배포 할 수 있는지 생각해보십시오.

나는 이틀 동안 당신이 다루어야 할 범위가되어야한다고 생각하며, 당신이 해결책을 제공 할 수있는 결과에 근거합니다.


4

새로운 것을 배우고 실험하기를 좋아하는만큼 시간 제약 조건에서 최선의 선택은 항상 작업하기가 더 편하거나 편안하다고 느끼는 것을 추구하는 것입니다. 당신이 아는 것을 고수하십시오.

장기적으로는 최상의 옵션을 선택하지 않았다는 것이 분명 해지더라도, 개발 한 모든 것은 계속 귀중한 것이며 여전히 완전히 사용 가능하고 휴대 가능한 일종의 현장 지식을 감 쌉니다. 사용하기로 선택한 편안한 컨텍스트, 도구, 플랫폼이 방해가되지 않고 실제로 중요한 것을 확인할 수 있기 때문입니다.


2

선택해야 할 요소의 목록을 작성하십시오. 성능 보안 비용 사용 편의성 X 개발자의 시장 출시 시간 등

이 작업에는 1 시간 미만이 걸리며 (실제로 15 분 미만이 소요됨) 경영진과 함께 앉아 우선 순위를 정해야합니다. 우선 순위와 관련하여 제안을 통해 다소 선택을 유도 할 수 있지만 우선 순위와 귀하가 동일 할 가능성은 적습니다. 이제 기술에 대해 평가할 사항을 알았습니다.

인터넷 검색을 기반으로 문제에 대한 일반적인 솔루션을 3-4 개 선택하십시오.

그런 다음 각 선택이 자신의 상위 3-4 우선 순위에 얼마나 잘 부합하는지 충분히 추측 할 수 있도록 충분히 읽으십시오. 각 선택 사항에 숫자 값을 지정하십시오. 각 우선 순위 시간의 등급에 해당 우선 순위에 설정된 값 (숫자 1의 경우 10, 숫자 2의 경우 8, 숫자 4의 경우 숫자 3 4의 경우 6 또는 원하는 숫자)을 곱하여 계산하십시오. 이제 각 가능성에 대한 숫자 점수가 있습니다. 일반적으로 할당 된 우선 순위를 가장 잘 충족하는 것이 분명합니다. 더 좋은 것은 이제 당신이 당신의 선택을 증명하기 위해 그들에게 가져갈 분석적인 것이 있습니다. 그들은 당신이 그것을 지원하기 위해 숫자가 있기 때문에 그들은 일반적으로 당신의 선택에 구입합니다. 숫자가 지원하지 않으면 다른 것을 선호하는 이유를 스스로에게 물어보고 가장 좋은 숫자를 사용하거나 지정된 숫자를 다시 방문하십시오.

선택의 진정한 자존심이 무엇인지에 집중함으로써 많은 연구 시간을 줄일 수 있습니다. 당신은 아마 하루 안에 추측을 할 수 있고 필요하다면 시험판 버전을 다운로드하고 상위 2 가지 가능성을 취하기 위해 하루를 남길 수 있습니다.


설명한 것을 "Analytic Hierarchy Process"라고합니다. 무역 연구 수행에 사용 된 가장 일반적인 기술입니다. 그것의 장점은 상당히 객관적인 방식으로 최상의 옵션을 결정하는 데 도움이되고 모든 이해 관계자 의견을 고려한다는 것입니다. 웹 사이트가이 기술을 얼마나 복잡하게 만드는지보고 놀랐습니다. 웹 사이트에 의해 보여지는 명백한 복잡성이 당신을 좌우하지 않도록하세요. 사용하기 매우 쉽습니다. 어쨌든, 좋은 예를 찾을 수 없었기 때문에 Wikipedia가 en.wikipedia.org/wiki/Analytic_hierarchy_process 만큼 좋은 출발점이라고 생각합니다 .
Dunk

1
스프레드 시트에 구조를 설정하는 데 10 분도 걸리지 않으며 (가장 복잡한 부분은 우선 순위를 비교할 요소를 결정하는 것임) 쉽게 입력하기가 쉽습니다.
HLGEM

정말 쉽습니다. 또한 모든 사람이 각 범주에 값을 할당하여 모든 사람이 가장 중요하게 생각하는 것을 결정하여 각 범주에 가중치를 적용 할 수있는 설문 조사를 수행합니다. 결국 소프트웨어 팀은 프로세서 속도와 메모리가 항상 최우선 과제라고 생각하지만 하드웨어 사용자는 배터리 수명이 중요하기 때문에 반대 의견을 갖는 것으로 보입니다. 물론 고객은 일반적으로 정격 중량의 절반 이상을 계산하며 소프트웨어 또는 하드웨어 문제에 대해 과감하게 생각하지 않습니다. 온라인 설명은 그렇지 않은 경우 정말 복잡해 보입니다.
Dunk
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.