Làm cách nào tôi có thể ước tính các dự án khi tôi cần bao gồm một lộ trình học tập cho công nghệ mới?

Đôi khi, có những dự án nghiên cứu và phát triển mà không có gì được biết trước về công nghệ, khái niệm và khách hàng. Tuy nhiên, người quản lý vẫn cần ước tính thời gian. Tôi có thể làm gì để tạo ra các ước tính hữu ích?

Thành thật mà nói, như Nassim Nicholas Taleb viết trong cuốn sách The Black Swan: 'chúng ta không thể dự đoán được'. Chủ yếu là do những điều chưa biết. Nói chung, tốt nhất là truyền đạt chính điều này, thực tế là bạn không thể dự đoán, thay vì truyền đạt ước tính.

Như Taleb viết: tốt hơn là nói đúng, hơn là sai chính xác. Vì vậy, hãy chắc chắn truyền đạt thực tế rằng bạn gặp khó khăn trong việc ước tính và sử dụng những thứ như 'học đường cong trong công nghệ mới' làm một trong những lý lẽ. Điều này có nghĩa là phạm vi ước tính của bạn sẽ lớn: 'dự án này sẽ có giá từ 100k đến 500k.'

Bằng cách nói một điều như vậy, người yêu cầu bạn ước tính điều gì đó nhận ra rằng mọi thứ không đơn giản như vậy.

Điều đầu tiên tuyệt đối bạn cần là một số ý tưởng về phạm vi. Càng cụ thể càng tốt, nhưng bất kỳ hình thức yêu cầu nào cũng có thể được sử dụng để đưa ra các ước tính ban đầu. Yêu cầu của khách hàng, tầm nhìn và phạm vi, và các tài liệu khái niệm có thể được sử dụng sớm. Khi các yêu cầu và môi trường hoạt động bắt đầu trở nên rõ ràng hơn, thì các ước tính sẽ được cải thiện. Hiểu rõ hơn về khách hàng (đặc biệt là các giao diện giữa khách hàng và tổ chức đang phát triển), nhóm thực hiện công việc, công nghệ được sử dụng, kiến ​​trúc hệ thống và thiết kế chi tiết sẽ góp phần ước tính chính xác hơn. Điều này có thể nhìn thấy trong hình nón của sự không chắc chắn.

Nếu bạn đang sử dụng một công cụ mô hình hóa tham số, chẳng hạn như SLIM hoặc COCOMO (chỉ dành cho Trung cấp hoặc Nâng cao, vì Basic không tính đến trình điều khiển chi phí), thì cần có các yếu tố điều chỉnh cho sự không quen thuộc của công nghệ. Ví dụ, COCOMO có một số lượng lớn trình điều khiển chi phí , bao gồm một số trình điều khiển đặc biệt hướng đến sự quen thuộc với nền tảng đích cũng như ngôn ngữ và công cụ được sử dụng để phát triển hệ thống. SLIM cũng chiếm kinh nghiệm chung của nhóm phát triển, bao gồm những cân nhắc về các công cụ và công nghệ đang được sử dụng.

Với kỹ thuật này, đầu ra của các công cụ mô hình hóa thường được xác nhận bởi vì chúng đã được sử dụng thành công để ước tính các dự án phần mềm trước đó trong nhiều năm trong nhiều tổ chức. Tuy nhiên, đầu ra chỉ tốt như đầu vào của công cụ.

Nếu bạn không sử dụng các mô hình tham số để ước tính, bạn sẽ chỉ cần xem xét các yếu tố này khi đưa ra ước tính của mình. Nó trở thành một cuộc gọi phán xét, nhưng bạn có thể xem xét các hoạt động như đọc tài liệu, thiết lập môi trường phát triển mới và phát triển các ứng dụng mẫu trên nền tảng đích hoặc với các ngôn ngữ đích.

Trong những trường hợp này, bạn sẽ cần chia nhỏ các ước tính của mình theo nhiệm vụ và có thể sử dụng phán đoán chuyên môn của mình để sao lưu dự phòng. Hy vọng rằng, bạn có dữ liệu lịch sử và bằng chứng cụ thể khác để dựa trên ước tính của bạn. Mặt khác, nó là một trận chiến khó khăn hơn.

Tách thời gian đào tạo và nghiên cứu lớn từ thời gian phát triển. Chia dự án thành nhiều dự án phụ có kết thúc có hậu. Hãy chắc chắn rằng bạn tạo ra một bằng chứng về khái niệm sau khi đào tạo.

Nếu bạn chưa quen với công nghệ, bạn sẽ không bao giờ đến gần với thời gian phát triển thực tế. Nâng cao điều này như một rủi ro khi bắt đầu dự án và hãy hào phóng trong ước tính của bạn. Điều này áp dụng cho các công nghệ cốt lõi mà bạn và nhóm của bạn không quen thuộc.

Phụ thuộc, tôi đã sử dụng FPA ( Phân tích điểm chức năng ) hầu hết thời gian, nhưng chúng tôi đã tham gia vào "sự phát triển web enterprizey" này, ý tôi là, bạn biết đấy, Forbes 500 công ty web.

Ở đó, nhiệm vụ có thể luôn được chia thành hai phần: một phần rất phù hợp với FPA: bạn có giao diện đầu vào, giao diện đầu ra, tệp logic bên trong (còn gọi là bảng / loại cơ sở dữ liệu sẽ được xuất) và bạn có các hệ thống không xác định, phức tạp này .

Trong phiên bản dễ, tác vụ phức tạp là một thành phần đã được viết, nó chỉ khó và không biết giao diện với nó.

Phiên bản cứng là khi nó cần được viết, sau đó ước tính dựa trên thí điểm, COCOMO, bất cứ điều gì.

Tuy nhiên, hai điều quan trọng:

1. Mỗi loại hệ thống dự toán phải có thời gian hiệu chuẩn cho tổ chức của bạn. Bạn không bao giờ phát triển một mình, ít nhất là có một khách hàng đang chờ mã của bạn (hoặc bạn sẽ không tuyệt vọng về điều này, viết mã cho riêng bạn). Câu hỏi không phải là "nó có thể được phát triển nhanh như thế nào?", Mà là "nó có thể được phát triển nhanh như thế nào với tất cả các bạn?"

2. Có lần tôi có một người quản lý đọc cuốn tiểu thuyết Black Swan đó và phát cuồng vì nó. Anh ấy nói với chúng tôi rằng không thể ước tính được, và tôi đã thực hiện chính xác thông thường của mình để ước tính + -10% không ngừng ...

Tôi thực hiện các dự án phù hợp với mô tả đó thường xuyên và tôi chưa tìm ra điều này! Rất may, nơi tôi làm việc tôi được ban cho vĩ độ để làm những gì tôi cần và không có giới hạn thời gian vô ích. Các dự án không phải lúc nào cũng thành công và đó chỉ là một phần của công việc với rất nhiều điều chưa biết. Công ty đạt được kiến ​​thức mỗi lần mặc dù.

Xin lỗi, điều đó không giúp được gì cả.

Ước tính sẽ mất bao lâu để thực hiện một dự án tương tự bằng cách sử dụng công nghệ quen thuộc. Nhân với 4. Thêm một số thời gian học tập.

Nếu ước tính quá ngắn bạn sẽ trông ngây thơ và kiêu ngạo. nếu ước tính quá lớn bạn sẽ trông không biết gì và không đủ năng lực. Chọn một cách khôn ngoan.