Làm thế nào để bạn đối phó với các API / công nghệ vượt trội

Tôi đoán hầu hết mọi người đã ở trong tình huống này.

Kế hoạch dự án ban đầu bắt đầu. Các yêu cầu được vạch ra. Sau khi xem xét kiến ​​trúc và sắp xếp thông qua API / Khung, công nghệ phù hợp được chọn. Sự phát triển bắt đầu.

Và rồi nó bắt đầu. Ngay khi bạn cần thực hiện một số điều được cho là đơn giản hỗ trợ, framework / API bắt đầu phản tác dụng và thay vì thực hiện bất kỳ công việc nào bạn kết thúc để chống lại công nghệ. Thời gian nghiên cứu, các diễn đàn im lặng, dường như không có gì được thực hiện và ngay cả khi bạn có việc gì đó để làm việc, bạn không thực sự chắc chắn rằng nó đã được thực hiện đúng.

Làm thế nào để bạn quản lý trong những tình huống này? Bạn có đi hack, bạn có nghiên cứu thêm không, bạn nói gì với quản lý?

Nguyên mẫu, Nguyên mẫu, Nguyên mẫu !!

Nếu nhóm của bạn không quen thuộc với một khung cụ thể thì hãy tạo nguyên mẫu một cái gì đó trong đó để đánh giá điểm đau ở đâu.

Matt Raible (anh chàng so sánh khung Java Web) đề nghị làm việc với một khung trong một tuần nếu có thể.

Tạo mẫu bao gồm điều tra sự hỗ trợ của cộng đồng đằng sau một khuôn khổ và các yếu tố khác

Quản lý các phụ thuộc bên ngoài là nguyên nhân của nhiều dự án CNTT. Nhiều năm trước, các lập trình viên giàu kinh nghiệm mà tôi làm việc cùng luôn đảm bảo rằng họ có quyền kiểm soát đối với các phụ thuộc của họ - Thông thường bằng cách nhấn mạnh rằng giấy phép mã nguồn đã được mua.

Cá nhân, đó không phải là cách tiếp cận của tôi. Tôi có xu hướng được hứa hẹn, hơn trường học tư tưởng. Có những lúc tôi phải thò cổ ra, nhưng tôi đã nghiên cứu riêng trước để chắc chắn 99% - thường làm một dự án tư nhân thường xuyên trong thời gian riêng của tôi để đảm bảo công nghệ có thể cung cấp. Trong nguyên mẫu có hiệu lực, thử nghiệm, xác nhận sau đó hứa.

Có những tình huống tôi bị bắt gặp - và phải quay lại hoặc sáng tạo. Có một đầu óc sáng tạo với nhiều kinh nghiệm rộng rãi sẽ giúp ích ở đây, nhưng nói chuyện với người khác cũng vậy. - và không phải lúc nào cũng lập trình viên. Đôi khi các giải pháp đến từ những nơi thực sự kỳ lạ.

Đối với việc đối phó với quản lý, chìa khóa là sự trung thực. Nói chuyện sớm, và thường xuyên. Đừng để đến phút cuối cùng vì buông lỏng người quản lý / khách hàng vào ngày trước khi giao hàng lớn chỉ khiến bạn trông như tài tử. Có thể nói 2 tháng trước hạn chót mà các nhà quản lý cần lựa chọn giữa việc bỏ một vài tính năng và / hoặc trì hoãn việc vận chuyển có thể không phổ biến vào thời điểm đó, nhưng nó cho phép các thành viên còn lại thực hiện công việc và lên kế hoạch . Chìa khóa để có thể làm điều này là có một hệ thống quản lý tác vụ tốt theo dõi thời gian và ước tính nhiệm vụ. Có bằng chứng vững chắc để sao lưu quan điểm của bạn khiến bạn có nhiều khả năng được lắng nghe.

"Làm thế nào để bạn quản lý trong những tình huống này?". Những gì tôi đã thấy / có kinh nghiệm:

điểm số 1 tôi đồng ý với Ptolemy: hãy trung thực:

Nếu đó thực sự là một vấn đề: đi đến căn phòng đó, nói vấn đề, ngồi lại để chờ phản ứng tức giận và sau đó ... làm việc hướng tới một kế hoạch / giải pháp mới. (anh chàng không giận bạn cá nhân).

Có những khóa học CNTT chỉ giải quyết tình huống này. Bạn được đặt với các diễn viên và họ đặt khách hàng tức giận khi nghe tin này. Bạn nhận được rất nhiều lời khuyên xung quanh nó. Nghe có vẻ ngu ngốc nhưng có lẽ chỉ sau khi làm xong bạn mới nhận thấy giá trị của nó. Tôi đã để lại một tờ có 80 điểm để ghi nhớ trong những tình huống đó ... (và thực hành).

Tình huống này có lẽ còn điển hình hơn, vì vậy ngày nay ngân sách eo hẹp, doanh số được thực hiện theo "ưu đãi thấp nhất", kế hoạch bạn đưa ra được cắt giảm 5 lần trước khi được khách hàng chấp nhận ... (bao gồm cả nguyên mẫu đó kể từ khi "anh ta đang tuyển dụng bạn bởi vì bạn là chuyên gia và nếu không thì có 10 người khác đang chờ ") v.v ...

- Một điều nữa có thể là suy nghĩ bên: nếu không thể thực hiện theo cách này, hãy cố gắng đề xuất một cái gì đó hoàn toàn khác biệt cung cấp cùng một giá trị cho khách hàng. Nếu công nghệ không hoạt động AT ALL / bị hỏng / nhảy ra khỏi thỏa thuận / v.v ... Nếu khách hàng mua vào điều này, nó có thể mang lại giá trị tương tự vào cuối. Nhưng mang nó cũng khá khó. (đối với một số và hoàn toàn không dành cho những người khác). Bạn cần những người thực sự có kinh nghiệm cho việc này. Một tình huống tương tự là Công nghệ KHÔNG YÊN TỚI nó ... phải mất vài tháng ... Vì vậy, bạn cần thuyết phục khách hàng thay thế và chấp nhận việc thay thế và tác động đến tổ chức của mình ...

- Một "bài học kinh nghiệm" khác là gọi những người đàn anh cao cấp ngay khi bạn nhận thấy rằng nó đi theo hướng này. Họ thường đã xử lý các dự án gặp khó khăn và thực sự hữu ích trong những tình huống này. Thường thì họ chỉ đi từ dự án gặp khó khăn đến dự án gặp khó khăn.

- Một bài học kinh nghiệm khác là để cho các công cụ kiến ​​trúc của bạn đi qua các kênh xác minh đặc biệt là trên các dự án lớn hơn. Một chữ ký có thể bao gồm mông của bạn. (lưu tất cả e-mail LOL của bạn)