Làm thế nào để cứu một dự án trẻ và sắp chết?

Tôi đang đăng bài nặc danh này vì tôi không muốn gặp rắc rối tiềm ẩn.
Tôi có một vấn đề lớn.
Gần đây tôi đã tham gia một đội chưa đầy một năm. Tôi đã ở đây từ một tháng trong dự án bắt đầu. Cấu trúc công ty trông như thế này:

• Chủ sở hữu (phi kỹ thuật)
  • Quản lý dự án (phi kỹ thuật)
    • Nhà phát triển chính (Kỹ thuật, nhưng xấu về nó)

Dự án này là một trang web sử dụng ASP.Net mà Nhà phát triển chính đã thiết kế một kiến ​​trúc khủng khiếp cho. Bạn sẽ phải chú ý đến nó, nhưng về cơ bản, cách chúng tôi được yêu cầu để xây dựng các trang web đang cho chúng tôi thời gian tải hơn 3 phút trên một trang web qua VPN ở chế độ Gỡ lỗi.

Nó đã xoắn ốc đến mức mà các đồng nghiệp khác đồng ý rằng họ dành nhiều thời gian trong ngày để chờ tải trang hơn là phát triển thực tế.

Bây giờ vấn đề lớn là điều này. Quản lý dự án không biết công nghệ và thừa nhận nó. Ông đặc biệt tuyên bố rằng ông tin tưởng Nhà phát triển chính để đưa ra các lựa chọn chính xác về kiến ​​trúc ứng dụng.

Không ai trong nhóm biết ý kiến ​​của Chủ sở hữu sẽ là gì, nhưng mọi người đều sợ tạo ra làn sóng trong nền kinh tế này (đặc biệt là bản thân tôi).

Bạn sẽ làm gì?

Vấn đề này có thể được chứng minh cho người quản lý dự án bằng các thuật ngữ phi kỹ thuật. Đặt trang web của bạn trong một cửa sổ trình duyệt trước PM và yêu cầu anh ta chơi xung quanh với nó một lúc. Sau khoảng hai lần tải trang, nhà phát triển chính sẽ được gọi lên thảm, nếu mọi thứ tệ như bạn nói.

Thủ tướng có thể không có kiến ​​thức phát triển chuyên ngành để hiểu tại sao nó xấu, nhưng anh ta có thể tự nhận mình là người dùng trang web nói chung. Các trang web khác hiển thị tải thông tin tương tự trong một phần nhỏ thời gian của bạn và của bạn đang tải qua mạng cục bộ từ máy chủ ở phòng bên cạnh.

Nếu điều này không bay, sau đó đi đến chủ sở hữu. Chủ sở hữu là một người có tiền, nhưng anh ta sẽ nhanh chóng có thể thấy rằng một trang web chậm mà không ai sẽ truy cập == không có tiền. Thiết lập cùng một bản trình diễn, và trước khi tải trang đầu tiên, anh ta nên gọi CẢ HAI là Thủ tướng và Người dẫn đầu trên tấm thảm của mình.

Nếu bạn lo lắng về việc một anh chàng tạo sóng, thì hãy nhờ nhiều nhà phát triển sẵn sàng nói lên mối quan tâm của họ. Thành thật mà nói, trong một công ty phẳng như của bạn, nếu sản phẩm bạn đang phát triển là một quả bom, bạn sẽ nghỉ việc dù bạn có lên tiếng hay giữ im lặng. Vì vậy, nhìn vào nó theo cách đó, bạn không có gì để mất ngoài một vài tuần hoặc vài tháng với công ty. Nếu đó là một vấn đề, hãy lên lịch cho một số "cuộc hẹn với nha sĩ" và tìm kiếm việc làm mới trước khi phát hiện ra mối quan tâm của bạn, vì vậy nếu bạn mất việc này, bạn hãy bắt đầu vào thứ Hai tuần sau.

Giả sử các tuyên bố của bạn là chính xác, bạn có Nhà phát triển chính không đủ năng lực và Người quản lý dự án không đủ năng lực (ít nhất là ở mức độ mà anh ta không thể khẳng định các kỹ năng của nhóm). Khỏe. Bạn có các tùy chọn chính xác giống như các nhà phát triển trên mọi đội ở mọi nơi trên thế giới.

1. Bạn có làm việc mà không chăm sóc sức khỏe của công ty.

2. Tìm việc ở nơi khác.

3. Đưa ra những gợi ý hợp lý cho Trưởng nhóm, Thủ tướng và Chủ sở hữu và hy vọng họ được thông qua.

Bạn có thể tự do thực hiện bất kỳ sự kết hợp nào ở trên.

Nếu bạn muốn tích cực bảo đảm sức khỏe của dự án, bạn sẽ phải làm việc với các nhà phát triển khác để đưa ra một khuôn khổ mới trong thời gian rảnh rỗi và chứng minh cho các thành viên còn lại biết tại sao nó vượt trội và công việc cũ nên được bỏ rơi ủng hộ nó.

Tôi đã làm việc trong một tình huống tương tự, trong đó nhà phát triển chính thực sự là đối tác trong công ty đã tạo ra "lõi" của phần mềm và ngoại trừ một người bạn thân làm việc trực tiếp với anh ta, các nhà phát triển khác không được phép chạm vào cốt lõi.

"Các quyền hạn" cũng tạo ra các quy tắc như mỗi mô-đun chỉ có thể có một bảng cơ sở dữ liệu, vì nó sạch hơn theo cách đó. Và kết quả từ đó, các danh sách thả xuống hiện có đã được tạo bằng cách chọn "DISTINCT" từ các bảng trong cơ sở dữ liệu, thay vì có một bảng riêng.

Có một số bản vá lỗi nổi xung quanh vì nhóm thực hiện phải hoàn thành công việc và sản phẩm sẽ không hoạt động. Các bản vá này gây ra nhiều vấn đề khi chúng sửa và được tùy chỉnh (hack) cho mỗi lần cài đặt.

Cách tiếp cận của tôi là lấy một phần nhỏ của thông số kỹ thuật rằng lõi không hỗ trợ và viết một bản vá nhỏ, tốt, chung cho nó. Một cái gì đó làm hài lòng nhóm thực hiện, nhưng không đe dọa như "Chúng ta cần thay đổi hoàn toàn suy nghĩ của mình". Do sự thù địch giữa nhóm thực hiện và các nhà phát triển cốt lõi, phải mất nhiều tháng để thuyết phục nhóm thực hiện rằng cách tiếp cận của tôi tốt hơn so với hack của họ. Nhưng một khi họ thấy rằng tôi sẽ lắng nghe họ và thực hiện các điều chỉnh bổ sung để hỗ trợ họ, họ rất vui mừng và đứng về phía tôi. Phải mất một tháng nữa để nhà phát triển chính chấp nhận bản vá, nhưng một khi anh ta thực hiện nó đã thực sự mở ra sự giao tiếp giữa tất cả chúng ta về những cách tốt hơn để thiết kế các phần khác của hệ thống.

Nó không bao giờ là một con đường ngắn để thay đổi suy nghĩ của mọi người, đặc biệt là nếu bạn cần giữ mối quan hệ dân sự với họ. Nhưng nếu bạn tiếp cận nó đúng, bạn có thể có được sự tôn trọng mà không xúc phạm sếp của bạn.

Mong rằng sẽ giúp!

Câu trả lời và giải pháp rất đơn giản. Dường như mọi người đều nhận thức được vấn đề. Do đó, việc bạn đi khắp nơi chỉ ra vấn đề không có giá trị với bất kỳ ai. Trong thực tế, nó chỉ làm cho bạn trông giống như một người đánh cá. Nếu bạn muốn thêm giá trị thì bạn cần chỉ ra giải pháp và xây dựng trường hợp kinh doanh để thay đổi giải pháp của bạn. Sau đó, bạn có thể chỉ ra vấn đề với một giải pháp tương ứng. Một bản demo cũng sẽ đi một chặng đường dài trong việc chứng minh giải pháp của bạn. Tất nhiên, điều này có thể có nghĩa là làm việc vào thời gian riêng của bạn, nhưng tất cả phụ thuộc vào mức độ quan trọng của nó.

Trước hết, tôi thực sự khuyên bạn nên đảm bảo sự thật của mình rằng đó là sự cố kiến ​​trúc ứng dụng chứ không phải vấn đề trong cấu hình VPN. Tôi đã thấy VPN cấu hình kém gây ra vấn đề chính xác này. Bạn có biết chắc chắn rằng ứng dụng chậm trong văn phòng không?

Nếu bạn đã loại trừ mạng, tôi sẽ đi với đề xuất của KiethS và để PM kéo lên trang.

Nghe có vẻ như kinh doanh, hoặc ít nhất là dự án sẽ sớm hoàn thành. Không muốn bỏ cuộc, tôi sẽ cố tránh xa nó càng nhanh càng tốt, vd. tình nguyện / yêu cầu làm việc trên các dự án khác đi. Hy vọng theo thời gian, bạn sẽ dành ít thời gian hơn cho thảm họa này và nhiều hơn nữa cho các dự án khác có cơ hội làm việc. Bạn không muốn bị coi là "anh chàng làm việc trong dự án không làm việc". Đó là tất cả về bảo vệ danh tiếng của bạn.

Chủ sở hữu có muốn một sản phẩm tốt hay không? Tôi rất nghi ngờ rằng câu trả lời là "Có" ... và do đó, bạn cần phải lên tiếng. Bạn cần ghi lại kiến ​​trúc hiện tại và sau đó (với dữ liệu mệnh lệnh tốt), cho thấy cách sản phẩm không đáp ứng với mong đợi hiệu suất phù hợp. Bạn nói rằng tất cả đồng nghiệp của bạn đều biết nó hoạt động kém - à ... còn khách hàng thì sao? Họ đang nói gì? Sử dụng một công cụ đo lường hiệu suất và xác định những gì mất quá nhiều thời gian. Nhiều công cụ thậm chí sẽ đi xuống để cho bạn thấy mỗi cuộc gọi chức năng mất bao lâu. Từ tất cả các dữ liệu này, bạn nên có đủ đạn dược để nói chuyện với người quản lý dự án của mình và lãnh đạo kỹ thuật về lý do tại sao mọi thứ không phải là cách họ nên và làm thế nào một số tái cấu trúc chính có thể cần thiết để tăng tốc độ sản phẩm.

Sau đó (chỉ sau khi nói chuyện với Thủ tướng và lãnh đạo), điều này NÊN đủ để bắt đầu thực hiện một số thay đổi. Nếu Thủ tướng không bị thuyết phục vào thời điểm đó, thì bạn cần phải quyết định xem đây có thực sự là nơi bạn muốn đến hay không. Nếu vậy, có thể là một cuộc họp với chủ sở hữu. Nếu không, hãy chuẩn bị hồ sơ đó.

Hãy chắc chắn rằng bạn ghi chép lại từng bước trên đường đi.

Về mặt kỹ thuật tôi đồng ý với các đề xuất ở trên. Mặt khác, tôi cảm thấy rằng nó giống như một vấn đề quan hệ hơn là một vấn đề kỹ thuật.

Nếu bạn muốn đi theo con đường suôn sẻ, nói chuyện với nhà phát triển chính sẽ là một lựa chọn phù hợp. Tôi sẽ không nói chuyện trong văn phòng mặc dù. Có một tách cà phê bên ngoài sẽ làm cho mọi thứ một chút không chính thức và thoải mái hơn.

Nếu điều đó không hiệu quả, bạn có thể thử nói chuyện với Thủ tướng và sau đó là chủ sở hữu.

Nếu không có việc gì, tôi khuyên bạn nên tìm một công việc mới.

Trung thực - và càng nhiều chiến thuật càng tốt.

Bắt đầu với nhà phát triển chính và làm việc theo cách của bạn nếu bạn phải. Cố gắng tham gia vào các khía cạnh tốt hơn trong tính cách của họ - Nếu bạn dẫn dev thích giải quyết vấn đề / thích tiết kiệm trong ngày / thích hiệu quả / v.v. hãy giải quyết vấn đề trong vấn đề đó - Sẽ không hại gì khi chỉ ra những trường hợp mà họ đã có thành công trong quá khứ như là động lực bổ sung.

Nếu bạn không tạo ra một số sóng, có lẽ bạn đã chết trong nước.

Có thể đưa các vấn đề trở lại mức có thể đo lường được và theo cách phi kỹ thuật để người quản lý dự án và chủ sở hữu có thể hiểu được.

Ví dụ: bạn đã đề cập đến thời gian tải chậm hơn 3 phút, tôi sẽ giả sử rằng có một yêu cầu về hiệu suất ở đâu đó trong thông số kỹ thuật, một cái gì đó đơn giản như "trang sẽ được tải trong vòng 1 giây". Một cái gì đó như thế này là có thể đo lường được và không thể bác bỏ. Nếu nguyên nhân gốc rễ của vấn đề này được tìm thấy là kiến ​​trúc tinh ranh, thì người quản lý dự án và / hoặc chủ sở hữu nên bước vào để buộc một số thay đổi.

Nếu không, thì bạn có một vấn đề mang tính hệ thống trong công ty của bạn, nơi phân tích ban đầu được thực hiện kém và không có đủ quy trình để nắm bắt các loại vấn đề này. Hãy xem xét việc nhảy tàu!

Đàn ông đích thực lên tiếng mà không oán giận hay xúc động. Đó là mẹo.

Lý do duy nhất hợp lệ ai đó có thể gặp bạn vì đã lên tiếng, là nếu bạn gặp phải sự bực bội:

NHÀ PHÁT TRIỂN LÃNH ĐẠO KHÔNG CÓ SỰ THẬT NÀO LÀM GÌ. Tôi biết điều này sẽ xảy ra, nhưng không ai lắng nghe tôi blah blah blah.

trong khi

Mô hình mã sai vì khó bảo trì và chậm. Chúng ta cần có chiến lược về việc tiến lên phía trước và khắc phục hai vấn đề này.

Cái trước là một trận chiến để hủy diệt, cái sau là một trận chiến vì hòa bình, và về lâu dài sẽ thu hút bạn sự tôn trọng của một người vì trung thực.

Nếu người đứng đầu dự án coi điều này là ưu tiên hàng đầu, mà anh ta chắc chắn có thể xem xét mình có thể bị sa thải, thì chỉ cần nói,

Đừng bắt tôi phải chịu trách nhiệm cho những việc tôi không chịu trách nhiệm thực hiện. Tôi chỉ thành thật.