Làm thế nào để quản lý một dự án khi nó bị đóng băng trong một khoảng thời gian vô hạn

Question

Ngay bây giờ, tôi rất thất vọng vì tôi đang trong quá trình phát triển một số cơ chế tuyệt vời để tối ưu hóa hệ thống tính toán bằng cách giảm số lượng phép tính từ khoảng nửa triệu đến vài nghìn. Phải mất rất nhiều thời gian kiểm tra và phân tích dữ liệu, viết những thứ xuống, làm một vài xét nghiệm và nói chung chỉ làm công việc của tôi. Sau đó, chúng tôi đã có một cuộc họp dự án. Tôi đã giải thích những gì tôi muốn làm, bao nhiêu thời gian nó sẽ mất và bao nhiêu nó có thể cải thiện dự án và thậm chí làm cho nó có thể tạo ra các tính năng mới. Sau đó, nó đã được quyết định rằng nó chỉ là quá nhiều thời gian để làm điều này tất cả trước thời hạn tiếp theo. (Một hạn chót sẽ phải được gia hạn nếu tôi được phép tiếp tục.) Một động não nhanh làm rõ rằng có một công việc dễ dàng có thể được sử dụng thay thế, điều này sẽ trì hoãn việc tối ưu hóa thêm vài tháng nữa.

Vâng, khó khăn!

OK ... Tôi vừa viết ra sự thất vọng. Bây giờ câu hỏi ... Bây giờ tôi có toàn bộ thiết kế này trong đầu. Phần lớn nó chỉ là sơ đồ và các mẩu giấy tờ với văn bản viết tay trên đó, một số bản in và thậm chí một vài câu hỏi ở đây tại SO. Những ý tưởng này sẽ bị đóng băng trong một thời gian, nhưng tôi sẽ cần nhớ lại chúng trong tương lai. Tôi có thể có được một ngày, có thể hai để dọn dẹp các ghi chú và bắt đầu ghi chép mọi thứ.

Vì vậy, tôi cần lời khuyên về cách ghi nhớ tốt nhất thiết kế của mình, ví dụ: 4 tháng kể từ bây giờ. Hoặc thậm chí một năm nữa kể từ bây giờ ... Điều quan trọng nhất để viết ra là gì? Hoặc tài liệu? (Xét một khoảng thời gian ngắn mà tôi có ...) Bất kỳ đề xuất nào?

Tại sao? Khác nữa, tôi sẽ lại thất vọng sau bốn tháng nữa. :-)

Answer 1

Điều đó tùy thuộc vào những gì phù hợp với bạn - và cách bạn muốn học. Tôi thích sử dụng biểu đồ, vì vậy trong trường hợp tôi đã thiết kế một thuật toán tuyệt vời (mặc dù không có gì phức tạp như thế này!) Tôi làm như sau:

1) Vẽ thuật toán ra trên giấy hoặc viết ra bất cứ điều gì .

2) Thêm chú thích vào nó để nó làm cho hoàn thành ý nghĩa cho bạn.

3) Mô tả thuật toán cho người khác chỉ từ những gì bạn đã vẽ. Điều này ngăn cản bạn điền vào chỗ trống từ kiến ​​thức của riêng bạn về thuật toán.

4) Nếu có khoảng trống trong mô tả của bạn, hãy thêm chi tiết bổ sung khi bạn đi, để tài liệu trở thành bản ghi toàn diện về mô tả của bạn.

5) Đặt bản vẽ đi trong một tuần và xem liệu nó có hợp lý hay không. Tại thời điểm này nó vẫn còn đủ quen thuộc để thêm các chi tiết còn thiếu.

Cho dù điều đó có đủ rõ ràng trong thời gian một năm hay không hoặc liệu bạn có muốn sử dụng nó hay không - vẫn còn để được nhìn thấy.

Hy vọng điều đó sẽ hữu ích!

Answer 2

Trong thiết kế cũ, trải nghiệm của tôi luôn có vẻ cũ khi bị mờ đi. Trong những tháng tới, mã hiện tại sẽ thay đổi, các yêu cầu sẽ thay đổi và bạn sẽ thay đổi thành lập trình viên. Có lẽ bạn nên viết một lời giải thích ngắn gọn và giả định rằng bạn sẽ cần phải hoàn toàn làm lại nó trong tương lai.

Đừng thất vọng với các dự án cụ thể, hãy tập trung năng lượng của bạn vào việc cải thiện với tư cách là nhà phát triển. Và mang theo kinh nghiệm đó với bạn.

Answer 3

Tài liệu yêu cầu chi tiết mô tả tất cả các yếu tố đầu vào và đầu ra có lẽ là một trong những cách tốt nhất để bắt đầu. Nếu nó là một thiết kế mã rất độc đáo, metacode có thể là một bước tiến tốt. I E.

[Meta Object] 

    [Return String(string param1, string param2)] 

     Return param1 + " " + param2 

    [Return Integer(integer param1, integer param2, integer param3)] 

     Return (param1 + param3)/param2 

[End Meta Object] 

Làm cho nó giống giống với ngôn ngữ của bạn w/o thử nghiệm hoặc bất cứ điều gì, chỉ cần có được logc lý thuyết trên giấy (notepad) cách mà bạn có một bảng mùa xuân khi/nếu bạn đã bao giờ phải quay trở lại với nó ... sau đó ghi lại ánh sáng ban ngày của nó.

Answer 4

Xét về sự thất vọng - thường cố gắng xem dự án dưới dạng hành trình thay vì đích đến.

Nếu bạn chú ý, bạn đã có rất nhiều dự án cho đến nay - những điều bạn đã học về công nghệ và doanh nghiệp, tạo các mô-đun mã bạn có thể sử dụng lại, bạn sẽ xây dựng mối quan hệ với các thành viên trong nhóm hoặc người dùng, đã phạm sai lầm bạn sẽ không làm lại và cứ như vậy. Nó có thể giúp bạn cá nhân để viết một danh sách những gì bạn biết bây giờ mà bạn đã không ở đầu của dự án.

Cuối cùng công ty có thể chưa triển khai dự án nhưng phần lớn lợi ích tích lũy cho bạn với tư cách là một người và nhà phát triển vẫn ở đó. Thật vậy, thường bạn học nhiều hơn về các dự án mà đi sai và trong các công ty mà không phải là tuyệt vời hơn khi mọi thứ đang chạy như một giấc mơ.

Như với phần còn lại của cuộc sống, bạn càng có nhiều sự hài lòng từ những thứ này sang ngày khác và bạn càng tập trung vào chỉ những thành tích của vùng chọn, bạn càng hạnh phúc. Tôi không nói rằng việc phân phối dự án không tốt - đó rõ ràng là lý do tại sao chúng tôi viết mã - nhưng không hoàn toàn nằm trong tầm kiểm soát của chúng tôi, vì vậy bạn cần phải thực tế và cân bằng về mức độ bạn cho phép tác động đến bạn.

(Các liên kết bắt buộc để một cái gì đó Joel hoặc Jeff đã viết: http://www.codinghorror.com/blog/archives/001297.html)

Answer 5

Nếu bạn đã tìm thấy các giải pháp một lần, rất có thể là cao, bạn sẽ tìm ra giải pháp thậm chí 4 tháng xuống dòng cho cùng một vấn đề. Những gì bạn PHẢI không bỏ lỡ là vấn đề thực tế.

Bạn nên viết xuống tất cả các vấn đề tối ưu hóa là vấn đề nguồn hoặc sự cố thực tế. Bạn phải lưu giữ gọn gàng các lưu ý về những vấn đề này.

Bây giờ, lần tiếp theo [nói 4 tháng xuống dòng] khi bạn muốn quay lại điều này một lần nữa. Bạn chỉ cần đọc vấn đề vấn đề từ ghi chú của bạn, và bộ não của bạn sẽ bắt đầu làm việc theo hướng thẳng như trước đây.

Để làm cho nó tốt hơn nữa, bạn có thể thử đi qua các ghi chú vấn đề một lần trong một hoặc hai tháng. Điều này sẽ đào tạo não của bạn hướng tới các giải pháp như bạn sẽ mọi thời gian kết thúc với các giải pháp giống như bạn đã làm lần đầu tiên.

Ngoài ra nếu bạn có thể viết xuống vấn đề hoặc mối quan tâm thực sự thúc đẩy bạn đủ để đấu tranh cho giải pháp, nó sẽ là tuyệt vời.