PM chọn cho một thiết lập quá phức tạp mà không ai có kinh nghiệm với [đã đóng]

Gần đây tôi đã bắt đầu một dự án dường như không quá khó để thực hiện, khái niệm này là một ứng dụng khá đơn giản, phải chấp nhận đầu vào mọi lúc và sau đó (có thể là 10 lần một ngày) và cố gắng thực hiện một số thao tác trên chúng và thu thập tất cả các kết quả cuối cùng. Ứng dụng này sau đó sẽ có được một cổng web mặt trước mà khách hàng có thể sử dụng để xem kết quả, không chính xác là khoa học tên lửa.

Để làm điều này, ban đầu tôi đã sử dụng thông minh các thư viện đồng thời tích hợp sẵn của Python ( ThreadPoolExecutor) và sử dụng thư viện dễ sử dụng cho giao diện người dùng (Tôi đã chọn Flask vì nó dễ dàng cho người mới bắt đầu và tương đối dễ bảo trì và kiểm tra).

Khi chúng tôi đang thực hiện được nửa dự án, Thủ tướng tuyên bố chúng tôi phải sử dụng các khả năng xếp hàng tin nhắn của bên thứ ba thay vì các luồng và phải thực hiện cân bằng tải, điều cuối cùng đã xảy ra là cuối cùng chúng tôi bắt đầu làm việc với Celery, Redis, RabbitMQ, Nginx, uWSGI và một loạt các dịch vụ bên thứ ba lớn khác mà không ai có kinh nghiệm thực sự với.

Cuối cùng, điều này dẫn đến một loạt các mã spaghetti, các nhiệm vụ không thể kiểm chứng (vì sự phức tạp của các thư viện bên thứ ba, việc vá mã thậm chí không hoạt động) và một loạt các vấn đề đau đầu vì thậm chí không ai biết giá trị gia tăng của các dịch vụ này là gì .

Trước khi bạn nói "Có, bạn nên sử dụng các dịch vụ đó", hãy nhớ rằng không ai biết cách sử dụng những dịch vụ này hoặc thậm chí biết những gì họ làm ngoài việc giới thiệu mã bị mắc kẹt trong tình trạng chủng tộc.

Tôi nên làm gì với cái này? Tại thời điểm này, nó chỉ đơn giản là quá tốn kém để trở lại với những gì chúng ta đã có và PM đã hết hạn sử dụng các dịch vụ này, mặc dù sản phẩm cuối giờ đã tệ hơn so với lúc ban đầu. Thậm chí có bất kỳ sử dụng trong việc thảo luận điều này với anh ta? Tôi có yêu cầu thêm thời gian không? Hoặc câu trả lời gay gắt, tôi chỉ quá ngu ngốc cho công việc của mình?

Khi chúng tôi đã đi được nửa dự án, Thủ tướng tuyên bố chúng tôi phải sử dụng các khả năng xếp hàng tin nhắn của bên thứ ba thay vì các luồng và phải thực hiện cân bằng tải

Đây không phải là một điều thích hợp để một PM đơn phương "tuyên bố". Hai lý do:

1. Các quyết định thiết kế nên được đưa ra bởi một nguồn lực kỹ thuật và chỉ đáp ứng với NFR . Vì vậy, hãy lịch sự hỏi PM của bạn nếu có NFR mới và nếu bạn có thể vui lòng có thông tin chi tiết.

2. Nếu một NFR được giới thiệu nửa chừng trong dự án, có lẽ nó nên được thực hiện thông qua kiểm soát thay đổi . Kiểm soát thay đổi là rất quan trọng từ góc độ quản trị; nó không chỉ là một đầu vào cho các yêu cầu của bạn, mà còn là một đầu vào quan trọng cho các trường hợp thử nghiệm của QA, cẩm nang triển khai và hỗ trợ của hoạt động, và (đây là phần thực sự quan trọng) lịch trình của Thủ tướng . Nếu yêu cầu mới giới thiệu nhiều công việc hơn, nhóm phát triển phải có cơ hội truyền đạt các ước tính phát triển mới và Thủ tướng sẽ phải quyết định liệu họ có thể sống với ngày mới, thêm tài nguyên hay đẩy lùi các bên liên quan đã giới thiệu NFR.

Bây giờ nếu thực sự có một NFR trung thực và không có xung quanh nó, thì cũng có thể thích hợp để yêu cầu các tài nguyên mới hoặc khác nhau, những người quen thuộc với các công nghệ đang được giới thiệu hoặc yêu cầu ngân sách đào tạo cho một số hiện có của bạn tài nguyên. Vì vậy, có một khía cạnh chi phí là tốt.

Nếu bạn nói ngôn ngữ của Thủ tướng - lịch trình và chi phí - Tôi nghĩ bạn sẽ nhận được nhiều lực kéo hơn là nói về cách các nhà phát triển cảm nhận về thiết kế kết quả. Những điều đó có tác động thực sự.

Một thủ tướng nên biết rõ hơn là giới thiệu những thứ như thế này một cách nhanh chóng mà không cần quản trị, không kiểm soát và không có sự đồng thuận. Nếu họ không nhận được nó, bạn có thể cần phải leo thang lên quản lý sản phẩm hoặc quản lý chương trình, vì anh ấy đang đặt chất lượng và lên lịch có nguy cơ không cần thiết.

Điều gì sẽ là ngu ngốc là để cho mình nhận được cái chết diễu hành .

Những gì bạn đang mô tả là bạn đã mất cảm giác quan trọng. Không có cảm giác kiểm soát và không có cách rõ ràng trở lại nó.

Điều cuối cùng bạn nên làm là làm việc chăm chỉ, giữ bình tĩnh và chịu đựng một cách lặng lẽ cho đến khi cuối cùng họ thừa nhận rằng dự án đã bị tiêu diệt.

Điều bạn nên làm là suy nghĩ thật kỹ về những gì bạn có quyền mong đợi.

Nếu họ muốn bạn sử dụng các công nghệ mà bạn không hiểu, bạn nên dành thời gian để tìm hiểu chúng. Đừng xấu hổ về những gì bạn không biết. Sử dụng sự thiếu hiểu biết của bạn như một món ăn. Khi họ yêu cầu bạn sử dụng một cái gì đó hỏi tại sao. Đừng chấp nhận 'bởi vì'. Đừng chấp nhận "thực hành tốt nhất hiện đại". Đừng chấp nhận 'khả năng mở rộng quy mô' mà không đạt được kỳ vọng thực tế, có thể kiểm chứng.

Bằng cách kiểm chứng tôi có nghĩa là họ PHẢI cho bạn biết có bao nhiêu yêu cầu mỗi ngày / giờ / phút mà họ muốn nó có thể thực hiện được. Làm rõ rằng bạn có ý định xây dựng một cái gì đó để thực hiện hệ thống này theo các thông số kỹ thuật đó.

Bằng cách này, bạn có thể sử dụng bản dùng thử miễn phí 30 ngày để chứng minh rằng điều wiz bang mới nhất mà họ muốn là xứng đáng hoặc nếu bạn tốt hơn nên tuân theo những gì bạn đã biết.

Bây giờ hãy ghi nhớ. Nó không phải là các công cụ giới thiệu mã bị mắc kẹt trong điều kiện chủng tộc. Các bạn đã làm điều đó. Bạn cần học CÁCH bạn đã làm điều đó để bạn có thể hoàn tác điều đó.

Và không. Nó không quá tốn kém để trở lại những gì bạn đã có. Thủ tướng không thể có những gì họ muốn chỉ bằng cách yêu cầu nó. Bạn phải đẩy lùi cho đến khi bạn có thể sử dụng hiệu quả những gì Thủ tướng muốn hoặc chứng minh đó không phải là những gì dự án cần.

Nghiêm túc mà nói, chỉ đưa ra điều này là không chuyên nghiệp và gây chết người cho dự án.

Tôi đã từng đến đây. Nhiều hơn một lần. Nó làm cho bạn cảm thấy ngu ngốc. Đó thực sự không phải là nó. Bạn vừa bị lạc.

Nói chuyện với Thủ tướng. Thành thật. Đặt tất cả ra ngoài. Cho thấy bạn sẵn sàng học hỏi nhưng không muốn bị bắt đi xe. Không bao giờ bao giờ thiết kế hoặc mã dựa trên đức tin. Làm cho PM chỉ cho bạn cách làm những gì họ muốn. Đừng giả vờ bạn hiểu khi bạn không. Đừng nói rằng nó sẽ được thực hiện khi nó không. Nếu bạn sẽ tin vào một cái gì đó tin vào chính mình. Bạn phải sẵn sàng nói KHÔNG.

Nếu điều đó không hiệu quả, hãy đánh bóng sơ yếu lý lịch vì bạn sẽ cần nó sớm. Cách này hay cách khác.

Điều này thực sự nên có trên workplace.stackexchange.com, vì vấn đề không thực sự là một câu hỏi phát triển phần mềm, mà là về các mối quan hệ tại nơi làm việc.

Nếu bạn chắc chắn rằng cách tiếp cận đơn giản của bạn sẽ có hiệu quả và tạo ra kết quả làm việc khá nhanh, thì PM của bạn là một lực phá hoại trong công ty của bạn cần được loại bỏ. Tìm hiểu làm thế nào để đưa tin tức lên cấp trên anh ấy: Nhóm của bạn có một giải pháp đơn giản, hiệu quả, đã đạt được tiến bộ tốt và vì lý do không ai có thể giải thích PM của bạn buộc bạn phải thử một giải pháp phức tạp hơn nhiều, sử dụng vô số về các công cụ mà không ai biết, không ai hiểu, không ai biết liệu chúng có hữu ích không, và quyết định không thể chấp nhận được của PM của bạn đã gây ra cho bạn tất cả những rắc rối và khiến dự án bị trễ và không hoạt động.

Không biết bối cảnh và chiến lược sản phẩm mà quản lý của bạn theo đuổi, thật khó để trả lời khách quan câu hỏi của bạn.

Ở đây một số lý lẽ khách quan. Tuy nhiên, có thể đó không phải là điều bạn mong đợi:

• " Hãy nhớ rằng không ai biết làm thế nào để sử dụng các sản phẩm này chưa ".
• Chỉ sử dụng các công cụ và kỹ thuật được biết đến hoàn hảo sẽ đảm bảo năng suất cao. Nhưng nó sẽ hạn chế đáng kể khả năng đổi mới. Trên một số thị trường, nó có thể gây tử vong cho sản phẩm của bạn. Ví dụ, gần 30 năm trước, tôi đã đề xuất sử dụng windows 3.0 để phát triển phiên bản mới của sản phẩm CAD thành công trong MS-DOS. Người quản lý sản phẩm phản đối rằng đây không phải là môi trường đã được chứng minh, nó sẽ quá phức tạp và quá khó để học cho nhóm, và dù sao, " Windows sẽ không bao giờ là môi trường chính thống " ... Tôi cho bạn đoán sự thành công của Sản phẩm của anh 2 năm sau.
• Tất cả chỉ là vấn đề chi phí và lợi ích. Chi phí thử nghiệm so với lợi ích của khả năng mở rộng và khả năng triển khai được đảm bảo bởi bên thứ ba có kinh nghiệm với việc cài đặt lớn và khối lượng công việc nặng.
• Những hạn chế của việc thêm một công nghệ mới có thể được làm mịn, với đào tạo phù hợp hoặc hỗ trợ / huấn luyện ban đầu bởi một nhà tư vấn có kinh nghiệm.

Cuối cùng, sự lựa chọn kinh tế là trách nhiệm của người quản lý sản phẩm của bạn. Thảo luận với anh ta những ưu và nhược điểm, để đảm bảo rằng anh ta đưa ra quyết định sáng suốt và không đánh giá thấp sự phức tạp thêm vào. Và nếu anh ấy tiếp tục theo dõi, hãy cố gắng đạt được kết quả tốt nhất của bạn: bạn không có gì để mất và trong trường hợp xấu nhất, bạn sẽ có một công nghệ mới trong CV của mình.

Có hai cách tiếp cận thư viện của bên thứ ba (và các thành phần khác):

1. Sử dụng càng nhiều càng tốt
2. Sử dụng càng ít càng tốt

Cách tiếp cận của tôi là (2). Nghe có vẻ như cách tiếp cận của bạn cũng vậy (2), nhưng người quản lý dự án thích cách tiếp cận (1).

Có ba cách bạn có thể xử lý tình huống này. Hoặc là bạn để Thủ tướng làm bất cứ điều gì Thủ tướng muốn, bạn cố gắng thuyết phục Thủ tướng thay đổi cách tiếp cận với thư viện của bên thứ ba hoặc bạn bỏ phiếu bằng chân và chọn một công việc khác.

Nếu bạn muốn thuyết phục Thủ tướng thay đổi cách tiếp cận, hãy xem xét các lập luận sau:

• Thời gian để học. Mỗi thư viện bên ngoài cần có thời gian để tìm hiểu, trong đó một lập trình viên có năng lực có thể viết chức năng mong muốn đặc biệt là nếu một thư viện khổng lồ được chọn chỉ để làm một việc rất đơn giản có thể được thực hiện trong vài trăm dòng mã.
• Khả năng thay thế.Nếu bạn có một thư viện bên ngoài, làm thế nào để bạn đảm bảo rằng nếu sự phát triển của nó bị dừng lại, bạn có thể thay thế nó bằng một thư viện tương tự khác? Giải pháp của tôi là tránh các thư viện bên ngoài bất cứ khi nào tôi có thể, và bất cứ khi nào không khả thi, tôi viết một trình bao bọc đơn giản để trừu tượng hóa phần giao diện lập trình mà tôi muốn. Thông thường giao diện tôi muốn đơn giản hơn nhiều so với giao diện mà thư viện cung cấp. Sau đó, mã của tôi truy cập vào thư viện bên ngoài chỉ thông qua trình bao bọc này, giúp việc thay thế trở nên dễ dàng. Xây dựng toàn bộ ứng dụng của bạn trên một số khung là một điều không nên. Phục vụ? Vâng, họ đã ở đây trong một thời gian dài và tiếp tục ở đây trong tương lai gần. Động cơ mẫu? Có, mặc dù chúng không thể thay thế chính xác (bạn thường chọn một và ở lại với nó), giá trị họ mang lại là rất lớn, vì vậy hãy chọn cẩn thận - và hãy nhớ rằng khi chuyển đổi các công cụ mẫu, bạn có thể có hai công cụ mẫu trong cùng một ứng dụng nhưng bạn thường không thể có hai khung trong cùng một ứng dụng. Struts Apache? Không, các khung đến với thời trang và đi ra khỏi thời trang một cách nhanh chóng và bạn thường không thể có hai khung trong cùng một ứng dụng.
• Phiên bản địa ngục. Bằng cách chọn một thư viện bên ngoài, bạn phải cập nhật nó để tránh các lỗ hổng bảo mật và việc cập nhật nó có thể phá vỡ mọi thứ. Các thành phần được thiết kế tốt (như Java JRE) tương thích với các phiên bản khác nhau, nhưng kinh nghiệm của tôi là hầu hết các thư viện đều tào lao do áp đặt phiên bản khổng lồ. Ngoài ra, thành phần X có thể yêu cầu Z phiên bản 1 và thành phần Y có thể yêu cầu Z phiên bản 2 và bạn không nhất thiết có thể liên kết Z phiên bản 1 và Z phiên bản 2 trong cùng một ứng dụng.
• Lỗ hổng bảo mật. Bằng cách chọn một thư viện bên ngoài, số lượng lỗ hổng bảo mật dễ khai thác đối với ứng dụng của bạn sẽ tăng lên. Một số người có thể cho rằng mã được phát triển nội bộ giống như bảo mật thông qua che khuất, nhưng sau đó tôi sẽ nói rằng nó vẫn là một hình thức bảo mật.
• Vấn đề giấy phép. Mỗi thư viện bên ngoài áp đặt giấy phép riêng của mình trên các phần của chương trình của bạn. Ví dụ: thư viện GPL không thể được sử dụng trong các chương trình không phải GPL và thư viện LGPL cũng yêu cầu phân phối mã nguồn cùng với các tệp nhị phân, có thể cần một lượng băng thông đáng kể.
• Thời gian khởi động ứng dụng. Mỗi thư viện lớn bên ngoài làm chậm thời gian khởi động ứng dụng của bạn. Bằng cách viết một thư viện gọn gàng, đơn giản, bạn có thể làm cho thời gian khởi động ứng dụng của mình nhanh hơn nhiều.
• Mức chiếm dụng bộ nhớ. Khi có X yêu cầu Y yêu cầu Z yêu cầu A yêu cầu B, bạn cần X + Y + Z + A + B trong bộ nhớ cùng một lúc. Bằng cách triển khai chỉ tương đương với X, hãy gọi nó là X ', trong nhà, bạn chỉ cần X' trong bộ nhớ. Và thường thì dấu chân bộ nhớ của X 'nhỏ hơn dấu chân bộ nhớ của X.
• Rủi ro lỗi. Càng có nhiều dòng trong thành phần bên ngoài, nguy cơ bạn sẽ gặp phải một lỗi sẽ khó khắc phục do số lượng mã lớn bạn cần hiểu. Nếu bạn làm việc trong nhà, bạn thường làm điều đó với ít dòng mã hơn (để làm những gì bạn cần, không có gì khác), và do đó, nguy cơ lỗi nhỏ hơn.
• Khả năng tùy biến. Nếu tôi tự viết các truy vấn SQL, tôi sẽ biết truy vấn đó trông như thế nào và nó hoạt động tốt như thế nào trên một công cụ cơ sở dữ liệu nhất định và các chỉ mục đã cho. Mặt khác, nếu truy vấn SQL được viết bởi một thành phần bên ngoài, tôi không biết gì về hiệu suất của nó. Tôi đã từng làm việc trong một công ty nơi mỗi trang web mất vài giây để tìm nạp. Tôi nghi ngờ nguyên nhân là thư viện Hibernate họ đã sử dụng tự động lấy quá nhiều dữ liệu từ cơ sở dữ liệu khi tất cả những gì bạn cần là một mục và không phải tất cả các mục liên quan đến mục cụ thể này. Tôi rời công ty trước khi phát hiện ra nguyên nhân thực sự của sự chậm chạp, bởi vì tôi không thích cách tiếp cận sử dụng số lượng lớn các thư viện hiện có.

Cẩn thận đặc biệt nếu một thư viện gọi chính nó là một khung . Điều này có nghĩa là thư viện yêu cầu bạn xây dựng toàn bộ ứng dụng của mình xung quanh chính nó. Bạn thường không thể có hai khung trong cùng một ứng dụng; họ sẽ chiến đấu với nhau mà không chung sống hòa bình. Thư viện tiện ích phát triển web? Vâng, xin vui lòng, có quá ít trong số này. Nếu tôi tìm thấy một thư viện tốt hơn những gì tôi sử dụng bây giờ, tôi có thể sử dụng thư viện mới tìm thấy trong mã mới trong khi tiếp tục sử dụng thư viện cũ trong mã cũ. Khung phát triển web? Một tiếng còi lớn KHÔNG!

Tôi nghĩ rằng PM của bạn đang nhắm đến một hệ thống khó quản lý sẽ tạo ra nhiều công việc bảo trì trong khi nó đang hoạt động, vì vậy nó sẽ đảm bảo thu nhập của bạn.

Cá nhân, bạn dường như bị mắc kẹt với python, chỉ cần quên python một thời gian, không mã hóa python trong một năm, tìm hiểu công cụ mới, bạn sẽ thấy có những ngôn ngữ khác có thể làm tương tự, và có lẽ tốt hơn.

Như những người khác đã nêu, hãy tìm hiểu các công cụ trước khi bạn bắt đầu viết mã với chúng. Có thể gợi ý rằng sẽ tốt khi đánh giá ngăn xếp cần thiết với nhau, dựa trên nghiên cứu các công cụ khác nhau có vẻ phù hợp với nhiệm vụ. Hoặc có thể hỏi làm thế nào anh ta đưa ra danh sách đó, anh ta có thể có sự giúp đỡ từ một người cập nhật.

Các nhà phát triển không nên sợ học cách sử dụng các thư viện, khung, công nghệ mới, v.v. kinh nghiệm với, hoặc thậm chí để yêu cầu nhóm làm như vậy nếu họ ở vị trí đưa ra quyết định kỹ thuật có thẩm quyền cho nhóm.

Tuy nhiên, không hợp lý khi hy vọng rằng bạn có thể tạo ra một công nghệ mới (hãy để một vài công nghệ mới cùng một lúc) vào ngăn xếp của bạn và tiếp tục tiến bộ. Thời gian đáng kể nên được lên kế hoạch để tìm hiểu về cách tiếp cận mới và tìm ra một thiết kế tốt để kết hợp các phần mới, trong đó không có tiến triển thực sự nào trên sản phẩm thực tế (từ những người thực hiện công việc học tập / thiết kế này , có thể có hoặc không phải là toàn bộ đội, mặc dù nếu không có lẽ cần phải có nhiều thời gian theo lịch trình hơn cho những người đã học để chuyển kiến ​​thức cho các thành viên còn lại của đội). Đó là chi phí để thực hiện loại thay đổi lớn này. Học các công nghệ mới là một phần công việc của nhà phát triển, nhưng đó không phải là điều chỉ xảy ra với chi phí thời gian bằng không.

Có vẻ như điều đó đã không xảy ra từ câu hỏi. Mọi người đã cố gắng bằng cách nào đó thực hiện việc xây dựng các triển khai tốt trên các công nghệ hàng đầu mà họ không hiểu. Tất nhiên mã kết quả là khủng khiếp.

Hãy cố gắng thuyết phục PM của bạn rằng công ty sẽ cần dành nhiều thời gian hơn cho việc này. Nó sẽ hoặc ở dạng dừng lại ngay bây giờ, học hỏi và đánh giá các công nghệ mới, tìm ra một thiết kế tốt và dọn dẹp mớ hỗn độn hiện tại. Hoặc nó sẽ đến dưới dạng lãng phí nhiều thời gian hơn cho các lỗi, bảo trì, phát triển tốn kém hơn, v.v.

Không thể nói liệu các lựa chọn kỹ thuật được mô tả trong câu hỏi (cân bằng tải, hàng đợi tin nhắn, v.v.) có thực sự phù hợp hay không. Tôi không nghĩ rằng "không ai trong nhóm có kinh nghiệm làm việc với điều này trước đây" là một lý do chính đáng để loại trừ hoàn toàn quyết định, nhưng nó làm tăng chi phí ngắn hạn khi đưa ra quyết định đó (có thể thay đổi " "quyết định tốt nhất cho bối cảnh) và nếu Thủ tướng của bạn không xem xét điều đó và hy vọng nhóm sẽ ngay lập tức làm việc hiệu quả như những người có kinh nghiệm thì bạn nên đẩy lùi những lý do đó; họ sẽ thiết lập lịch trình dự án rất phi thực tế, điều này không được ai quan tâm nhất.