Làm thế nào để đưa ra quyết định kỹ thuật quan trọng trong thời gian ngắn

36

Tôi đã có 2 ngày để đưa ra quyết định rất nghiêm túc về các công cụ và nền tảng mà công ty tôi sẽ sử dụng để chuyển ứng dụng WPF của mình sang Linux / Android / iOS.

Rõ ràng tôi có thể chỉ cho người cao niên của mình rằng 2 ngày hầu như không đủ để đọc về tất cả các lựa chọn có thể, và về việc thử, tạo nguyên mẫu, v.v. Tôi có thể nói rằng, nó sẽ không giúp tôi một chút, tôi đã có 2 ngày, và Sau 2 ngày, quyết định sẽ được đưa ra. Giai đoạn.

Từ một phía tôi thất vọng, từ phía khác tôi nghĩ rằng có một sự thật trong cách tiếp cận này, nếu không tôi có thể dễ dàng thấy mình bị chôn vùi dưới hàng tá SDK, khung, API, bài viết trên blog, v.v. và quên trong quá trình tất cả là vì cái gì

Tuy nhiên, tôi sợ rằng một quyết định sai lầm sẽ khiến công ty phải trả giá đắt. Vì vậy, bạn nghĩ gì là một quá trình "lý tưởng" để đưa ra quyết định như vậy?

development-process time-management decisions

— Flot2011
nguồn

4

Viết ở đâu đó rằng quyết định gần như không thể thực hiện trong hai ngày. Sau đó cố gắng đưa ra một quyết định không quá tệ, và chứng minh rằng quyết định của bạn không phải là tốt nhất. Nói cách khác, che mông của bạn. Qt5 có thể được xem xét. Hoặc biến sản phẩm của bạn thành ứng dụng web HTML5 (có thể sử dụng một số thư viện máy chủ HTTP, ví dụ libonion hoặc FastCGI)

— Basile Starynkevitch

2

@gnat Tôi không đồng ý, đó là một câu hỏi chủ quan, ngay cả khi có nhiều hơn một câu trả lời có thể, tất cả chúng ta đều có thể có được từ kinh nghiệm của người khác.

— Flot2011

9

Không có 'tùy chọn tốt nhất' trong nhiều trường hợp, bạn có thể viết nó dưới dạng một ứng dụng web PHP và nó sẽ hoạt động. Hoặc bạn có thể viết nó dưới dạng chương trình Qt và nó sẽ hoạt động. Nó có thể là một giao diện người dùng giao diện trò chơi openGL. Tất cả đều là những lựa chọn chấp nhận được, mẹo là chọn một và sau đó thiết lập để làm cho nó hoạt động. Đừng làm tê liệt bản thân với những nghi ngờ một khi bạn chọn thứ gì đó.

— gbjbaanb

5

Ví dụ rất tệ bởi vì trong trường hợp ví dụ, có một công nghệ là một lựa chọn rõ ràng cho việc này - Xamarin. Giữ mã phụ trợ .NET, chỉ cần thay thế UI bằng một cái gì đó. Xử lý tất cả các trường hợp nhất định. Vì vậy, đây là một trường hợp "Tôi biết nhiều hơn về các hệ thống đa nền tảng cho .NET".

— TomTom

7

Nói rằng 2 ngày là không đủ thì không mang tính xây dựng. Là 3 ngày là đủ? Hay bạn thực sự muốn dành 2 tháng cho nó? Và quyết định của bạn có khả năng tốt hơn bao nhiêu? ~~~ ~ Nếu bạn nói rằng bạn cần một tuần và tự tin rằng điều này sẽ dễ dàng tiết kiệm hàng trăm giờ thời gian phát triển, hãy chắc chắn đề cập đến điều này. Nó có thể không giúp đỡ, nhưng luôn có cơ hội mà các bên liên quan thích trường hợp kinh doanh của bạn.

— Dennis Jaheruddin

48

Nếu tất cả những gì bạn có là 2 ngày và không có thời gian để tạo nguyên mẫu hoặc thậm chí đọc tất cả các lựa chọn thay thế thì thực sự chỉ có 2 tùy chọn:

hỏi ai đó biết và làm theo lời khuyên của họ Điều này có thể không nhất thiết có nghĩa là yêu cầu một cá nhân nhưng dành 2 ngày tìm kiếm thông qua blog và bài viết để thu thập đủ thông tin để đưa ra quyết định tốt hơn một chút so với không hiểu rõ.
Thực hiện một nghiên cứu nhỏ vào tất cả các tùy chọn chính và sau đó chọn một. Đôi khi lãnh đạo có nghĩa là không sợ đưa ra quyết định sai, điều quan trọng thường là đưa ra quyết định vững chắc hơn là bỏ trống.

Bạn có thể tự bảo vệ mình bằng cách đưa ra các kiến trúc tách rời hơn và do đó dễ thay đổi hơn - ví dụ: mô hình máy khách / máy chủ sẽ cho phép bạn thay thế công nghệ UI của mình bằng công nghệ UI khác với sự gián đoạn tối thiểu.

— gbjbaanb
nguồn

10

+1 cho "đừng sợ đưa ra quyết định sai" Đôi khi, việc bị cuốn vào 'tê liệt phân tích' còn tệ hơn là không đưa ra quyết định nào cả. Chúng ta đều là con người. Làm tốt nhất của bạn và có được với cuộc sống.

— semaj

1

vacillate: xen kẽ hoặc dao động giữa các ý kiến hoặc hành động khác nhau; thiếu quyết đoán

— TankorSmash

10

+1 cho "che đậy bản thân bằng cách đưa ra các kiến trúc tách rời hơn và do đó dễ thay đổi hơn"

— Darth Egregious 20/1/2015

2

@emodendroket Windows Workflow Foundation.

— MetaFight

2

Nếu vấn đề của bạn không phải là vấn đề chính, đừng hy vọng các giải pháp chính sẽ giải quyết tốt. Đây là nơi tách rời và linh hoạt là rất quan trọng . Tìm kiếm các khung / thư viện giúp bạn dễ dàng thực hiện công việc của riêng mình thay vì khiến bạn đánh lừa điều gì đó theo mong đợi của họ khi họ dường như không lường trước được những gì bạn cần làm.

— jpmc26

19

Có vẻ như tôi đang đi ngược dòng, nhưng gần đây tôi đã đọc cuốn sách Creativity, Inc. của Ed Catmull và có một đoạn thực sự hay để giải quyết tình huống này:

Andrew Stanton nói tiếp. Andrew thích nói rằng mọi người cần phải sai nhanh nhất có thể. Trong một trận chiến, nếu bạn phải đối mặt với hai ngọn đồi và bạn không chắc chắn nên tấn công ai, anh ta nói, hành động đúng đắn là nhanh lên và chọn. Nếu bạn phát hiện ra đó là ngọn đồi sai, hãy quay lại và tấn công người khác. Trong kịch bản đó, quá trình hành động duy nhất không thể chấp nhận được là chạy giữa những ngọn đồi.

Tôi chắc chắn rằng nó có thể được áp dụng cho tình huống của bạn là tốt. Có lẽ bạn có thể đưa ra quyết định ngay hôm nay bằng cách chọn một và bắt đầu làm việc với nó. Nếu nó hoạt động, thì bạn sẽ có thứ gì đó sẵn sàng trong hai ngày đó và bạn sẽ nói - "Tôi đã chọn cái này và tôi có thể cho bạn thấy những gì chúng ta có thể làm với nó vì tôi đã chạy thử nghiệm vài lần ...". Nếu bạn nhận thấy trong một ngày rằng giải pháp được chọn là hoàn toàn không xứng đáng, thì bạn có thể chọn một giải pháp khác và làm việc với ngày hôm sau. Trường hợp xấu nhất là bạn sẽ sử dụng cả hai ngày để kiểm tra hai nền tảng, phát hiện ra rằng cả hai đều không hoạt động - nhưng cuối cùng đó là câu trả lời đúng, phải không? Loại bỏ cỏ dại, loại bỏ những lựa chọn sai lầm có thể, vì vậy mọi quyết định tiếp theo sẽ tốt hơn nhiều so với quyết định trước. Trường hợp tốt nhất là bạn

Rõ ràng là bạn sẽ không làm chủ bất kỳ nền tảng nào trong hai ngày, nhưng chọn một ASAP chắc chắn sẽ cho bạn một viễn cảnh tốt hơn về cách thức hoạt động của nó (nhiều hơn là chỉ đọc về nó) và sẽ đưa bạn đến một câu trả lời tốt hơn.

— Michal
nguồn

12

Mặc dù tôi đồng ý với bạn ở cấp độ toàn cầu, đôi khi việc lao về phía trước trên chiến trường là khá tự tử.

— Flot2011

Không ai đề cập đến vội vã mặc dù. Tôi chưa bao giờ nói đi bộ với ông chủ hôm nay và nói - "Đây là giải pháp. Ngay tại đây và ngay bây giờ." Thay vào đó tôi đang đề xuất chọn một cái trong đầu và thử chạy nó và sửa lại nó. Chỉ cần đọc về nó và thảo luận với ai đó sẽ không làm điều đó. Tôi tin rằng đi trước và thử nó sẽ dẫn đến sự lựa chọn có chất lượng cao hơn nhiều.

— Michal

6

@ Flot2011 mặc dù nếu bạn có bằng MBA, bạn ở lại vị trí của mình và gửi tất cả quân đội của mình để chiến đấu trên một ngọn đồi. Nếu tất cả họ đều chết, ồ, bạn sẽ nhận được nhiều quân hơn và tiếp tục nhưng lần này nói rằng kinh nghiệm của bạn với tư cách là một vị tướng khiến bạn trở nên ... xứng đáng hơn với mức lương khủng khiếp hơn.

— gbjbaanb

1

"Chọn một ASAP, sau đó nguyên mẫu" đánh vào tôi như một lời khuyên rất tồi trong tình huống này. Vâng, tạo mẫu là quan trọng, nhưng cũng tốn thời gian. Các vấn đề không tầm thường thường có nhiều hơn 2 giải pháp khả thi và 2 ngày không đủ để tạo ra một số công nghệ.

— meriton - đình công

@meriton Tôi cảm thấy những gì bạn muốn nói - Tôi đồng ý, việc tạo mẫu rất tốn thời gian. Tôi đã không nói rõ "làm nguyên mẫu" - đó là lý do tại sao tôi cẩn thận chọn từ tinker - khám phá nền tảng, viết một số mã nhỏ, mở một số tệp triển khai cơ bản, xem cách nó hoạt động bên trong. Cơ hội là người ra quyết định sẽ không nhận được tất cả các chi tiết đúng nhưng bằng cách dùng thử và lỗi, anh ấy / cô ấy chắc chắn có thể cải thiện chất lượng của quyết định.

— Michal

10

gbjbaanb làm cho một số điểm rất tốt. Tôi chỉ nghĩ rằng tôi sẽ thêm một chút.

Rõ ràng là bạn không có đủ thời gian để đưa ra quyết định hoàn toàn sáng suốt. Lựa chọn duy nhất của bạn là thử và đưa ra quyết định sẽ giảm thiểu nỗi đau trong tương lai. Tôi muốn đề xuất:

Tài liệu rõ ràng về bản chất của tình huống: Gửi email đến người quản lý của bạn và CC người quản lý của họ và các bên liên quan. Giải thích rằng vấn đề bạn đã được chỉ định là một vấn đề khó khăn nhưng bạn sẵn sàng giải quyết tất cả. Nhưng lưu ý rằng, với các hạn chế về thời gian, bạn không thể đảm bảo kết quả của mình là tối ưu.
Tìm một khung / nền tảng với một cộng đồng trực tuyến lớn và tích cực. Điều cuối cùng bạn muốn là bị mắc kẹt khi gỡ lỗi một khung tối nghĩa.
Như gbjbaanb đã đề cập trước đây, hãy giảm thiểu những khó khăn và rủi ro khi chuyển bằng cách sử dụng một kiến trúc ghép lỏng lẻo. Nếu mọi thứ trở thành hình quả lê với một trong những lựa chọn công nghệ của bạn, điều này sẽ giúp việc trao đổi nó dễ dàng hơn.

Tôi đã ở trong hoàn cảnh của bạn trước đây và cuối cùng nó đã biến thành một cơn ác mộng chính trị. Khi hệ thống không hoạt động một cách kỳ diệu, mọi người bắt đầu chỉ tay và mọi thứ trở nên tồi tệ. Đó là lý do tại sao khuyến nghị số 1 của tôi là ghi lại rõ ràng rằng bạn đã cố gắng hết sức để chống lại tỷ lệ cược không thể .

Chúc may mắn :)

— Siêu tốc
nguồn

17

Re: # 1. Không ai thích một kẻ thất bại thảm hại, vì vậy, hãy nhấn mạnh rằng bạn đã làm tốt nhất có thể trước những tình huống không thể, sau đó bạn trông giống như một người chiến thắng chủ động trong đội chơi đang đi! Quản lý thích kiểu đó. Ngẫu nhiên, có nhiều lý do tại sao việc viết lại lớn không hoạt động, sự lựa chọn của một công nghệ so với công nghệ khác thường là vấn đề ít nhất.

— gbjbaanb

Vâng, tôi nhận ra đó là một chút than vãn nên tôi đã sửa đổi nó.

— MetaFight

Cá nhân, tôi sẽ cụ thể hơn "không tối ưu", vì không chỉ định mức độ nghiêm trọng của sự không chắc chắn. Một người quản lý với tâm lý "không cần phải hoàn hảo, chỉ cần đủ tốt" sẽ hoàn toàn bỏ qua cảnh báo này, không biết rằng bạn có ý nói rằng công nghệ có thể không đủ tốt.

— meriton - đình công

3

Thay vào đó, tôi sẽ xác định các rủi ro cụ thể và chuyển chúng lên quản lý. Ví dụ: "Dựa trên kiến thức hiện tại của chúng tôi, chúng tôi nghĩ rằng công nghệ A là lựa chọn tốt nhất. Tuy nhiên, do thời hạn ngắn, chúng tôi không thể xác minh rằng phương pháp này có thể xử lý khối lượng công việc dự kiến của hệ thống này." Quản lý sau đó có thể chấp nhận rủi ro hoặc giảm thiểu bằng cách yêu cầu phân tích thêm.

— meriton - đình công

+1 cho điểm số 2. Tìm kiếm một giải pháp có một cộng đồng phát triển và phát triển tốt đằng sau nó. Nếu bạn ổn hơn một giải pháp như vậy, bạn luôn có thể duyệt các diễn đàn trực tuyến, blog, đăng câu hỏi, v.v. tốt nhất

— Arnab Bhagabati

5

Vì họ thực sự đã cho bạn ít thời gian để làm nhiều hơn là chọn ứng viên ra khỏi mũ, nên tôi áp dụng cách tiếp cận sau.

Chọn các công nghệ:

Có một cơ sở người dùng lớn
Có hỗ trợ tích cực (thông qua bất kỳ kênh nào)
Đang được tích cực phát triển

Theo định nghĩa, điều này sẽ loại trừ bất kỳ công nghệ cạnh chảy máu nào, tuy nhiên nó có thể tốt.

Ngoài ra, chống lại sự thôi thúc đi với công nghệ X mà không cần phân tích thêm đơn giản vì Fred, nhà phát triển đã sử dụng nó trong quá khứ. Nó không chắc là phù hợp hoàn hảo, và nếu Fred chuyển sang đồng cỏ xanh hơn, sẽ có chuyên gia tên miền của bạn.

— Robbie Dee
nguồn

Mặc dù nếu công nghệ X phù hợp đủ tốt và Fred sẵn sàng giáo dục các nhà phát triển khác, thì làm như vậy có thể là một cách tốt để khởi động nhóm.

— một CVn

Chắc chắn - nếu nó đánh dấu vào các ô khác ...

— Robbie Dee

4

2 ngày là một khoảng thời gian rất ngắn để đưa ra quyết định như vậy, nhưng vì bạn phải thực hiện nó trong danh sách 2 ngày sau đây,

Các nền tảng mục tiêu là gì
Các thành phần tùy chỉnh / bên thứ ba được sử dụng trong ứng dụng hiện tại là gì mà nó có thể đòi hỏi nỗ lực đáng kể để chuyển. ví dụ: thành phần biểu đồ, thành phần lưới, thành phần báo cáo, v.v.
Ứng dụng hiện tại kết nối với thế giới như thế nào và bảo mật được xử lý như thế nào (kết nối cơ sở dữ liệu / dịch vụ web / v.v ...)
Cách thức phân phối và cách cập nhật được cung cấp

Bây giờ bạn cần tìm giải pháp thay thế bạn có thể sử dụng cho tất cả các môi trường đích

Đối với mỗi lựa chọn thay thế, hãy tìm ra sự hỗ trợ cho từng người để sử dụng kết nối / bảo mật mà ứng dụng hiện tại đang sử dụng.

sau đó cho từng thành phần tùy chỉnh / bên thứ ba tìm hiểu xem có dễ sử dụng thay thế cho từng thành phần không.

Và sau đó nghĩ về cách phân phối có thể được thực hiện cho từng phương án bạn tìm thấy.

Tôi nghĩ trong 2 ngày, đây sẽ là phạm vi bạn có thể bao quát và dựa trên kết quả bạn có thể cung cấp giải pháp.

— Bồ nông bay thấp
nguồn

4

Nhiều như tôi muốn tìm hiểu và thử nghiệm những thứ mới, trong thời gian hạn chế, lựa chọn tốt nhất là luôn tìm kiếm bất cứ thứ gì hoặc cảm thấy thoải mái hơn khi làm việc. Dính vào những gì bạn biết.

Ngay cả khi về lâu dài, rõ ràng bạn không chọn tùy chọn tốt nhất, bất cứ điều gì bạn phát triển vẫn tiếp tục có giá trị và bao bọc một loại kiến thức lĩnh vực vẫn hoàn toàn có thể sử dụng và di động. Và đó chính xác là vì bối cảnh, công cụ, nền tảng thoải mái mà bạn đã chọn sử dụng tránh xa mọi thứ và khiến bạn thấy điều gì thực sự quan trọng.

— Ando
nguồn

2

Lập danh sách các yếu tố nên chọn, những thứ như: Bảo mật hiệu suất dễ sử dụng Khả năng sử dụng khả năng X để làm thời gian quen thuộc của nhà phát triển Y với thị trường, v.v.

Việc này sẽ mất ít hơn một giờ (thực sự chỉ mất chưa đến 15 phút), sau đó ngồi xuống với quản lý và để họ ưu tiên các yếu tố đó. (Cơ hội ưu tiên của họ và của bạn là như nhau mặc dù bạn có thể hướng dẫn lựa chọn của mình phần nào với các đề xuất như ưu tiên.) Bây giờ bạn đã biết phải đánh giá gì về công nghệ.

Chọn ba hoặc bốn giải pháp phổ biến cho vấn đề của bạn dựa trên tìm kiếm trên internet.

Sau đó đọc đủ để đưa ra dự đoán tốt về mức độ mỗi lựa chọn phù hợp với 3-4 ưu tiên hàng đầu của họ. Gán một giá trị số cho mỗi lựa chọn. Làm toán bằng cách nhân tỷ lệ của từng lần ưu tiên theo giá trị được đặt trên mức ưu tiên đó (10 cho Số 1, 8 cho số 2, 6 cho số 3 4 cho số 4 hoặc số nào bạn thích). Bây giờ bạn có một số điểm cho mỗi khả năng. Nói chung sẽ rõ ràng đáp ứng tốt nhất các ưu tiên được giao. Thậm chí tốt hơn bây giờ bạn có một cái gì đó phân tích để đưa cho họ để chứng minh sự lựa chọn của bạn. Họ thường sẽ mua theo sự lựa chọn của bạn bởi vì bạn có những con số để hỗ trợ nó. Nếu các số không hỗ trợ thì bạn cần phải tự hỏi tại sao bạn thích số khác và đi với số tốt nhất hoặc xem lại các số đã gán.

Bằng cách tập trung vào những gì các nhà tiên tri thực sự của sự lựa chọn, bạn có thể cắt giảm rất nhiều thời gian nghiên cứu. Bạn có thể đoán trong vòng một ngày và sau đó còn một ngày để có 2 khả năng hàng đầu và tải xuống các phiên bản dùng thử nếu cần và chơi một chút với chúng.

— HLGEM
nguồn

Những gì bạn mô tả được gọi là "Quy trình phân cấp phân tích". Đây là kỹ thuật phổ biến nhất tôi từng thấy được sử dụng để thực hiện các nghiên cứu thương mại. Sức mạnh của nó là nó giúp quyết định lựa chọn tốt nhất theo cách khá khách quan và đưa tất cả các ý kiến của các bên liên quan vào tài khoản. Tôi đã ngạc nhiên khi thấy các trang web làm cho kỹ thuật này dường như phức tạp như thế nào. Đừng để sự phức tạp rõ ràng được hiển thị bởi các trang web làm ảnh hưởng đến bạn, nó thực sự rất dễ sử dụng. Dù sao, vì tôi không thể tìm thấy một ví dụ hay, tôi cho rằng Wikipedia cũng là điểm khởi đầu tốt như bất kỳ en.wikipedia.org/wiki/Analytic_hierarchy_ process .

— Dunk

1

Chỉ mất chưa đến mười phút để thiết lập cấu trúc trong bảng tính (phần phức tạp nhất là quyết định các yếu tố bạn muốn so sánh các ưu tiên) và sau đó thật dễ dàng để điền vào.

— HLGEM

Nó thực sự là dễ dàng. Chúng tôi cũng thực hiện các cuộc khảo sát trong đó mọi người gán giá trị cho từng danh mục để xác định xem mọi người nghĩ gì là quan trọng nhất để chúng tôi có thể áp dụng trọng số cho từng danh mục. Xét cho cùng, nhóm phần mềm cho rằng tốc độ và bộ nhớ của bộ xử lý luôn là ưu tiên hàng đầu, nhưng những người làm phần cứng dường như có ý kiến trái ngược vì thời lượng pin rất quan trọng đối với họ. Tất nhiên, khách hàng thường tính ít nhất một nửa trọng số xếp hạng và không đưa ra ý kiến trái chiều về các mối quan tâm về phần mềm hoặc phần cứng. Các mô tả trực tuyến có vẻ thực sự phức tạp khi nó không.

— Dunk