Phải làm gì nếu sếp luôn hoãn các quyết định lớn về yêu cầu và thiết kế tổng thể?

Khi bắt đầu một dự án mới, sếp của tôi luôn tránh đưa ra quyết định cố định. Anh ấy thường nói: ok, hãy bắt đầu viết một cái gì đó và càng chung chung càng tốt. Khi bạn hoàn thành, chúng tôi xem cách chúng tôi tiếp tục. Lập luận của ông về cơ bản là bạn không bao giờ biết và "phát triển nhanh".

Để giữ câu hỏi chung chung nhất có thể: bạn sẽ làm gì nếu sếp không muốn đưa ra quyết định?

Chỉ cần bám vào nó và viết mã có thể trải qua quá trình tái cấu trúc nặng và viết lại một phần vài tuần sau đó? Hoặc tiếp tục thảo luận cho đến khi ông chủ thực hiện ít nhất một vài quyết định? Đây là chiến lược hiện tại của tôi. Bởi vì nó giống như một định luật vật lý, đến một lúc nào đó cần phải cung cấp một cái gì đó. Hoặc bởi vì ông chủ của sếp muốn xem kết quả hoặc bởi vì một số thứ đang trở nên lố bịch vào một lúc nào đó.

Tôi cũng quan sát rằng ông chủ của tôi đang chỉ trích gần như tất cả mọi thứ. Ngay cả những lời đề nghị dựa trên ...

Xây dựng nguyên mẫu

Chỉ cần bắt đầu vẽ màn hình mà không làm gì lúc đầu (có lẽ bạn có đủ để làm điều đó không?)

Bạn sẽ có thể làm cho nó hoạt động một phần từ từ, và cuối cùng cấu trúc lại một số mã xấu khi nó trở nên rõ ràng hơn những gì bạn đang cố gắng làm.

Đó là một vấn đề phổ biến mà họ không biết những gì họ muốn cho đến khi họ nhìn thấy một cái gì đó và nhận ra đó không phải là những gì họ muốn. Tôi đã phát hiện ra rằng khi ai đó muốn bạn bắt đầu xây dựng 'một khung' hoặc một cái gì đó 'chung chung' như những gì anh ta đang nói với bạn, bạn sẽ gặp rắc rối nếu bạn thử. Các khung đã được viết, bạn không cần phải làm điều đó.

Có một số vấn đề mà tôi đã thu thập được từ tin nhắn của bạn: 0-Đây không phải là công việc của bạn để quản lý dự án và đó không phải là công việc của bạn để thu thập các yêu cầu của người dùng cuối. 1-Sếp không biết các yêu cầu chính xác 2-Sếp không nói chuyện với người dùng cuối về các yêu cầu 3-Sếp đang ném thuật ngữ mà anh ta không thực sự hiểu nhanh 4-Bạn đang tìm ra một giải pháp nào đó được nhận lại viết nhiều lần và bạn không hài lòng về nó

Đối với 1,2 và 3, có rất ít điều có thể được thực hiện về điều này nếu bạn không phải là người cao cấp. Tuy nhiên, những điều sau đây có thể được thực hiện:

A - Yêu cầu anh ấy chia sẻ với bạn kế hoạch dự án. Anh ta có thể có một hoặc sẽ xây dựng một cái cho thấy các nhiệm vụ và thời hạn. Một trong những điều này nên là về phân tích và thu thập yêu cầu. Nếu không đề nghị nó.

B - Chuẩn bị một số tài liệu tham khảo về tầm quan trọng của các yêu cầu đối với sự thành công của dự án phần mềm

C - Chuẩn bị cho anh ta 1 trang về Agile là gì và không.

D - Chuẩn bị cho anh ấy một danh sách các đầu vào điển hình cho giai đoạn thiết kế và thuyết phục anh ấy về giá trị của mỗi.

E - Đề xuất bổ sung một nhà phân tích kinh doanh và / hoặc người lập mô hình dữ liệu cho nhóm. Những vai trò như vậy sẽ phải ngồi với người dùng cuối và sẽ giúp bạn có được thông tin cần thiết hoặc ít nhất là một phần tốt của nó.

F - Xem cách các nhà phát triển khác hợp tác với anh chàng này.

Đối với số 4, bạn có thể đề nghị anh ta sử dụng phương pháp tạo mẫu hoặc trình tạo mã có thể giúp anh ta, bạn và người dùng để họ suy nghĩ về các khía cạnh chức năng của ứng dụng. Hầu hết các công cụ không tạo GUI hoàn hảo, nhưng ít nhất bạn có thể nắm bắt được chức năng cần thiết.

Trong mọi trường hợp, hãy đảm bảo rằng bạn ghi lại rõ ràng từng lần lặp và gửi email cho anh ấy về những gì bạn đã nhận được, những gì bạn đã làm (một cách chi tiết) và kết quả là gì. Hãy chắc chắn rằng bạn quy kết quả cho nguyên nhân thích hợp như (thiếu yêu cầu, v.v.).

Thật không may, một số người không chấp nhận lời khuyên. Vì vậy, hãy cẩn thận cách bạn giao tiếp với anh ấy.

Điều này sẽ không tốt!

Chúc may mắn.

Tôi đã từng có một ông chủ như thế - thực tế tôi sẽ nói đùa rằng phương châm của ông là "sự thiếu quyết đoán là chìa khóa cho sự linh hoạt".

Dù bạn làm công việc phát triển nào, có lẽ bạn đang ở vị trí tốt hơn để giải quyết vấn đề của khách hàng so với sếp của bạn. Nếu bạn không biết vấn đề của khách hàng là gì đang cố gắng giải quyết (điều này không giống với thông số kỹ thuật), thì có ai đó không thực hiện đúng yêu cầu của họ.

Phác thảo một số bố cục trang hoặc xây dựng một nguyên mẫu không / bán chức năng. Nhưng làm một cái gì đó. Không rõ từ bài đăng của bạn cho dù bạn đang xây dựng phần mềm ứng dụng khách hoặc ứng dụng web đầy đủ, nhưng cái hay của cái sau là bạn có thể phát hành sớm, phát hành thường xuyên. Bắt đầu với xương trần và làm việc từ đó. Một khởi đầu sai lầm sẽ không có hại nếu nó có một số cuộc đối thoại trôi chảy và một số quyết định được đưa ra.

Chúng tôi có một câu nói xung quanh $ WORK (ứng dụng web nội bộ) cho khách hàng của chúng tôi: "Tôi sẽ cung cấp cho bạn một cái gì đó để bạn có thể cho tôi biết những gì bạn muốn." Hãy chuẩn bị để ném bản thảo đầu tiên đi, nhưng bạn có thể ngạc nhiên về mức độ hiếm khi bạn thực sự phải làm.

Chỉ ra cho anh ấy rằng những cuốn sách Agile đề nghị hoãn các quyết định miễn là bạn có thể nhưng không nhiều hơn thế . Mọi quyết định đều có một điểm mà nó phải được đưa ra, và có lẽ bạn đang ở đó ngay bây giờ.

Mặt khác, cũng tự đặt câu hỏi. Bạn có thực sự cần phải quyết định lớp kiên trì nào bạn sẽ sử dụng cho ứng dụng này không? Hoặc bạn có thể bắt đầu viết nó vào CSV và giữ cho nó đủ trừu tượng để đưa ra quyết định đó sau này không?

Viết tài liệu đặc tả của riêng bạn và tổ chức đánh giá nơi bạn giải thích và anh ấy ký tắt. Sau đó, bạn sẽ trở thành ông chủ, và ông chủ của bạn sẽ chuyển sang các vấn đề quản lý giữa các cá nhân hơn là các vấn đề kỹ thuật.

Tham gia vào 'quản lý đi lên' nói chuyện với sếp và khách hàng của bạn, tìm ra một số giải pháp, chọn giải pháp tốt nhất cho nhóm của bạn để thực hiện, tìm ra sai sót trong những vấn đề khác và 'quản lý' người quản lý của bạn để đưa ra quyết định 'đúng'.

Và tất nhiên hãy chắc chắn rằng anh ấy nghĩ rằng đó là tất cả ý tưởng của anh ấy / cô ấy. (đặc biệt là khi tất cả gặp trục trặc!)

Bạn cần thiết kế và thực hiện một cái gì đó. Vì sếp của bạn sẽ không đưa ra quyết định, sau đó tự đưa ra quyết định. Dành thêm một chút thời gian để ghi lại các quyết định và giả định của bạn trước khi bạn thực hiện chúng. Gửi cho bất cứ ai nó có thể quan tâm bao gồm cả ông chủ của bạn. Hy vọng rằng, danh sách đó bao gồm nhiều hơn sếp của bạn vì nó sẽ gây áp lực nhỏ cho anh ấy để đưa ra một số quyết định vì anh ấy biết rằng những người khác biết rằng bạn đã sẵn sàng để tiếp tục. Bạn sẽ ngạc nhiên về việc bạn nhận được phản hồi nhanh như thế nào khi bạn đưa ra quyết định bằng văn bản, đặc biệt nếu bạn đưa ra quyết định mà người khác không đồng ý. Trong khi đó, tôi sẽ tiến hành các quyết định bạn đưa ra cho đến khi được nói khác đi.

Nếu bạn đã kết thúc lãng phí thời gian để thực hiện những gì ông chủ của bạn không muốn, thì đó là ở anh ấy chứ không phải bạn vì anh ấy nhận thức được con đường bạn sẽ đi.

Ngoài ra, một số người gặp khó khăn khi bắt đầu, nhưng một khi họ thấy điều gì đó hữu hình thì tâm trí họ lại lao vào. Có thể ông chủ của bạn cũng như vậy và bạn nói với anh ta những gì bạn dự định làm bằng văn bản sẽ khiến tâm trí anh ta đi theo.

Tự đưa ra quyết định và bắt đầu viết mã. Tất nhiên, phát triển một cách linh hoạt sẽ giúp ích (đọc các Nguyên tắc, Nguyên tắc và Thực tiễn Agile của Robert C Martin nếu bạn chưa có) nhưng tất cả sự linh hoạt trên thế giới sẽ không giúp ích nếu không có quyết định nào được đưa ra. Bạn có thể thấy bạn phải phát triển những gì bạn nghĩlà cần thiết, và sau đó sửa đổi nó theo yêu cầu. Thường thì khách hàng / ông chủ không biết họ muốn gì cho đến khi họ nhìn thấy hoặc cho đến khi họ thấy thứ họ không muốn. Điều này có thể sẽ đưa bạn ra ngoài phạm vi trở thành một nhà phát triển, nhưng đó là cuộc sống. Tôi thường thấy rằng tôi và các đồng nghiệp của tôi đang thực hiện các dự án kinh doanh một cách hiệu quả. Đôi khi những điều này không được đặt câu hỏi và những quyết định mà tôi đã thực hiện bắt đầu thúc đẩy kinh doanh, hoàn toàn là vì không ai khác sẽ đưa ra quyết định. Hãy chắc chắn liệt kê TẤT CẢ các giả định và quyết định của bạn (không có trường hợp ngoại lệ) và trình bày những điều này cho sếp của bạn.