Làm cho những người không lập trình hiểu được quá trình phát triển

Khi bắt đầu một dự án cho một công ty không phải chủ yếu là một công ty lập trình, một trong những kỳ vọng là có một sản phẩm hoàn chỉnh cuối cùng không có lỗi và làm mọi thứ cần thiết ngay lập tức. Tuy nhiên, điều đó hiếm khi xảy ra.

Một số cách để quản lý kỳ vọng và giải thích cho những người không lập trình về cách phát triển phần mềm khác với các loại phát triển sản phẩm khác là gì?

Ngày nay, khá nhiều người có máy tính đã gặp phải khái niệm "lỗi", vì vậy bạn có thể bắt đầu từ đó. "Cách khó chịu nhất mà một ứng dụng từng làm bạn thất bại là gì? Nhân số đó với mười và bạn sẽ có trải nghiệm người dùng của chúng tôi nếu chúng tôi không dành đủ tài nguyên để kiểm tra và bảo trì."

Và đừng đánh giá thấp giá trị của việc thiết lập mối quan hệ làm việc tốt với những người không lập trình. Nếu bạn có thể chứng minh rằng phán đoán của bạn có thể được tin cậy, họ sẽ nghiêm túc với bạn khi bạn báo động rằng X sẽ thất bại một cách ngoạn mục nếu bạn không làm Y pronto, ngay cả khi họ không hoàn toàn hiểu lý lẽ của bạn.

Một cách tiếp cận mà tôi thấy thành công là:

Chúng ta đều biết rằng một máy tính chỉ làm và chính xác những gì nó được bảo phải làm.

Lập trình là cách mà chúng ta nói với một máy tính bây giờ chúng ta phải làm gì sau này .

Điều này có nghĩa là cách hành xử của bạn bây giờ là do ý định kết hợp của tất cả những người đã viết bất kỳ mã nào đang chạy trên máy của bạn. Khi bạn xem xét sự phức tạp của hệ điều hành, trình điều khiển, môi trường lập trình, thư viện, v.v., dễ dàng nhận thấy rằng trong hầu hết các hệ thống phải có tới 20 nghìn người tham gia và có thể có hơn 100 nghìn.

Mã được viết bởi mỗi người phản ánh sự hiểu biết, động lực, ý định và khả năng của riêng họ. Do hoạt động hoàn hảo của hệ thống yêu cầu tất cả các mã được viết bởi những người 20k này tương tác không có lỗi - rằng tất cả các mã phải đồng ý về ý nghĩa và diễn giải của hành vi được yêu cầu, thực tế không phải là chúng tôi có lỗi, nhưng rằng chúng tôi có rất ít trong số họ.

IMO, tôi đã thấy rằng tính minh bạch được cung cấp bởi các quy trình nhanh (ví dụ Scrum, Crystal, v.v.) đi một chặng đường dài hướng tới cách phát triển hoạt động cho các bên liên quan trung bình.

Giải thích bằng phép ẩn dụ là một sự trừu tượng bị rò rỉ, nhưng đây là một số ý tưởng thường làm việc với tôi:

Lưu ý rằng không có giải thích nào trong số này giải thích công việc cẩu thả.

Hãy nghĩ về một chương trình máy tính như một cái máy, trong đó mỗi biến là một phần chuyển động. Điều đó làm cho ngay cả một chương trình tầm thường trở thành một cỗ máy bao gồm hàng trăm bộ phận chuyển động.

Khi điều đó thất bại, tôi nhận ra một thực tế là trong khi về mặt toán học có thể chứng minh rằng một chương trình không có lỗi, thì nó cần một lượng lớn thời gian và sẽ không đáng để nỗ lực.

Cuối cùng, tôi hỏi nếu Intel và Microsoft không thể tránh được lỗi, họ mong đợi chúng ta như thế nào?

Tôi đã trả lời một câu hỏi tương tự chi tiết hơn , nhưng ý chính là, "Lập trình giống như xây dựng một nhà máy hoặc một dây chuyền lắp ráp."

Cách truyền thống để nói rằng đó là Tam giác quản lý dự án: ba tiêu chí cạnh tranh về phạm vi, chi phí và tiến độ; thường được biểu thị là "giá rẻ, nhanh, tốt - chọn hai".

Khi kết thúc quá trình thiết kế, phát triển và triển khai, kỳ vọng rằng một sản phẩm tương đối không có lỗi thiết kế và hoạt động với một chức năng được chỉ định là hoàn toàn hợp lý. Kỳ vọng tương tự là hoàn toàn không hợp lý đối với một dự án, quy trình hoặc nghề nghiệp.

Những gì chuyên nghiệp dựa trên khoa học, cứng hay mềm, không trải qua quá trình khám phá, hình thành các khái niệm không chính xác và không chính xác, theo các chiến thuật kém tối ưu (hoặc chỉ đơn giản là sai), khám phá những gì hoạt động thông qua thử và sai, và lặp lại xử lý hết lần này đến lần khác cho đến khi hết tài nguyên hoặc đạt được mức hiệu suất đủ?

Không có quá trình nào là không có sai sót, mặc dù nó có thể tiếp cận một cách bất thường các mức chất lượng cao hơn.

Điều đó đúng với nghề y, nơi các chiến thuật thường liên quan đến phỏng đoán và giao thức, và phần lớn hoạt động về cơ bản là gỡ lỗi cho một cỗ máy chủ yếu là đi đường. Điều này đúng với kỹ thuật dân dụng và kiến ​​trúc nơi các ứng dụng của vật liệu chế tạo mới phải được xác nhận thực địa và có thể thất bại đột ngột sau nhiều năm phục vụ mặc dù tuân thủ nghiêm ngặt các tiêu chuẩn. Điều này đúng với lĩnh vực ô tô nơi tuổi tác và thay đổi trong điều kiện vận hành thường ảnh hưởng đến hiệu suất đến mức hỏng hóc, không có lỗi của các dịch vụ kỹ thuật hoặc sửa chữa được áp dụng. Phát triển phần mềm về cơ bản không khác biệt so với những ngành nghề này ở những khía cạnh như vậy, nó chỉ có một phần trọng tâm lớn hơn liên quan đến việc tạo ra những cỗ máy mới, có mục đích.

Nếu bạn có bất kỳ sự quen thuộc nào với việc phát triển phần mềm hi-rel, chẳng hạn như điều khiển lò phản ứng hạt nhân, truyền thông không gian sâu hoặc thiết bị cấy ghép y tế (v.v.), bạn có thể giải thích cách cấu trúc chi phí và thời gian giao hàng cho cấp quản lý dự đoán và QA đó có thể có cường độ lớn hơn những gì các doanh nghiệp điển hình có thể chi trả cho các dự án phần mềm của họ.

Bạn có thể so sánh nó với một cái gì đó họ có thể nhìn thấy và nếu có thể, sử dụng hàng ngày.

Ví dụ, ô tô. Ô tô bắt đầu như những thiết bị kém tinh tế và đáng tin cậy hơn chúng ta có ngày nay. Trong khi xe hơi đã được sản xuất hơn 100 năm, nhưng phần mềm có lẽ dài khoảng một nửa. Xe có sẵn với sự tùy biến đáng kể, một số bao gồm trong giá (như lựa chọn màu sắc), một số khác như kích thước động cơ, loại truyền động, bánh xe / lốp, mức độ cắt là những trình điều khiển chi phí đáng kể.

Có nhiều tính năng, chất lượng và trình điều khiển chi phí cho xe hơi và phần mềm. Sau đó, bạn có thể thảo luận về cách công nghệ phần mềm, sự sẵn có về chuyên môn, thậm chí có thể là nơi nó được xây dựng sẽ tạo ra sự khác biệt lớn. Các chu kỳ phát triển phù hợp (ví dụ, các mô hình hàng năm với những thay đổi nhỏ, thay đổi cơ thể / động cơ / nền tảng khoảng ba năm một lần) được thúc đẩy bởi sự kết hợp giữa nhu cầu của khách hàng và quy trình thiết kế phức tạp. Một số sản phẩm bắt đầu nhỏ và trông bẩn thỉu (nghĩ về Honda Accord), nhưng được cải thiện hàng năm cho đến khi chúng được xếp hạng hàng đầu.

Ô tô đã thu hồi (thường tốn kém hơn so với nâng cấp phần mềm) và cải tiến gia tăng dưới dạng chạy thay đổi danh sách các bộ phận của chúng (nghĩ rằng sửa lỗi) và thường chúng cần hỗ trợ dài hạn (nghĩ khả năng tương thích lùi / tiến). Phần lớn chi phí của chiếc xe của bạn đến sau khi bạn lái nó về nhà. Phần lớn chi phí phần mềm xuất hiện sau khi phát hành sản phẩm ban đầu khi bạn cập nhật và nâng cấp khách hàng.

Trong một số trường hợp, bạn có thể tham khảo các sản phẩm nổi tiếng bao gồm phần mềm hoặc các sản phẩm phần mềm khác. Ví dụ: điện thoại có chu kỳ phát hành, cập nhật và phương pháp thêm chức năng sau khi bán ban đầu để tạo thêm doanh thu. Điện thoại là một minh họa tuyệt vời về khả năng tương thích tiến / lùi. Quá nhiều, và mọi người sẽ không bỏ cái cũ để mua cái mới. Quá ít và khách hàng rất muốn có một chiếc điện thoại mà họ sẽ không ghét trước khi hợp đồng hết hạn.

Các sản phẩm như Windows, Microsoft Office, trình duyệt web và trang web đều là những phần mềm có thể được sử dụng trong các cuộc thảo luận. Chúng đã được cập nhật theo chu kỳ hàng năm hoặc ba năm, nhưng có thể có cập nhật tự động thường xuyên hơn. Họ có lỗi và lỗ hổng bảo mật ảnh hưởng đến khách hàng ở các mức độ khác nhau, nhưng là một phần của cảnh quan bất chấp những nỗ lực tốt nhất của chúng tôi. Khách hàng có thể nhận được các bản sửa lỗi miễn phí, nhưng thường trả tiền cho các cải tiến, thường là một gói, đôi khi là một mô-đun riêng lẻ hoặc thông qua khóa cấp phép.

Các nhà lãnh đạo ngành công nghiệp như Microsoft, Apple, Google và Amazon đều cung cấp khách hàng tương đối rẻ cho người dùng. Nhưng họ có chi phí rất lớn cho phép những sản phẩm đó. Kinh nghiệm của họ cho thấy phần mềm đắt tiền, nhưng có giá trị và mang lại lợi nhuận. Họ thường thỏa hiệp giữa chất lượng, có tất cả các tính năng họ muốn và tham gia vào thị trường khi thời điểm thích hợp. Không phải mọi sản phẩm họ làm ra đều thành công và đôi khi họ biến chó thành người chiến thắng bằng cách đổi tên, cải thiện tiếp thị và bán hàng, hoặc cắt lỗ và sử dụng những gì họ học được trong các sản phẩm sau này.

Có lẽ hãy thử đưa chúng đi qua, từng người một hoặc trong các nhóm nhỏ một cách lý tưởng, sử dụng các trường hợp phần mềm bạn phải phát triển. Khi họ mô tả các trường hợp sử dụng, xác định các điểm trong trường hợp những điều khác nhau có thể xảy ra (trường hợp bất ngờ nhưng không phải là không hợp lý). Bắt đầu liệt kê chúng, yêu cầu một số giải thích rõ ràng và minh họa tất cả các quyết định và phương hướng cần thực hiện hoặc giải quyết, và sự đánh đổi được thực hiện khi làm như vậy. Tiếp tục đi cho đến khi chúng bị bối rối và không thể cho bạn một câu trả lời. Làm cho họ hiểu rằng, những gì bạn đang làm với họ, chính xác là những gì bạn làm cả ngày, có thể là của riêng bạn, có thể với định hướng ít rõ ràng hơn, cả hai quyết định khóa học và viết mã, cho hàng trăm hoặc hàng ngàn trường hợp sử dụng có thể hoặc thậm chí không được đặt ra bởi bất cứ ai. Và khi có ' Trong trường hợp bạn không nghĩ về bản thân mình, bạn không thể đảm bảo chương trình sẽ làm gì. Có lẽ nó làm điều "đúng", có thể lưu ý. Và đó là một lỗi. Và đó là lý do tại sao việc viết phần mềm cần có thời gian. Bạn càng có ít thời gian, càng ít trường hợp bạn có cơ hội xem xét và điều chỉnh, và càng có nhiều khả năng chương trình sẽ không làm điều "đúng" trong một tình huống không xác định.

Chi phí và thời gian.

Thời gian

Đặt kỳ vọng rằng bạn sẽ cung cấp X trong Y lượng thời gian. Nó sẽ không có gì hơn, không có gì ít hơn. Sau đó cho họ biết phiên bản tiếp theo sẽ có trong thời gian nào. Lúc đầu, họ có thể ngạc nhiên khi tin rằng việc xây dựng X mất một lượng thời gian Y - đây là nơi bạn giải thích thời gian thực hiện và sự phức tạp của việc xây dựng một phần mềm. Nếu họ không ngạc nhiên, hoặc bạn ước tính rất ít thời gian hoặc họ biết rõ hơn bạn nghĩ về việc xây dựng phần mềm.

Giá cả

Đây là từ cuốn sách Code Compete của Steve McConnel (trích dẫn từ bộ nhớ, vì vậy xin lỗi tôi nếu tôi không thể truyền đạt nó với hiệu ứng tương tự) - Khách hàng dễ dàng yêu cầu các tính năng mới. Là người quản lý sản phẩm, bạn không nên nói với những gì khách hàng yêu cầu. Bạn nên ước tính cần bao nhiêu nỗ lực và chi phí để xây dựng tính năng mới đó. Họ sẽ dần hiểu rằng tính năng mới này không thực sự đáng tiền / thời gian hoặc có lẽ họ thậm chí không yêu cầu nó. Tôi không gợi ý rằng bạn sử dụng vũ khí này để dọa họ, nhưng sử dụng nó một cách trung thực và nó có thể giúp lái xe về nhà.

Phép ẩn dụ là sự trừu tượng bị rò rỉ, nhưng chúng là bước nhỏ đưa bạn đến gần hơn với sự hiểu biết.

Yêu thích của tôi là phần mềm xây dựng thường là một quá trình tương tự như kiến ​​trúc nhà. Tuy nhiên, chính xác hơn khi nghĩ về nó như là tạo ra một hệ thống in ra bản thiết kế được kiến ​​trúc tùy chỉnh dựa trên một số tham số và xây dựng một hệ thống khác nhau cho mỗi người dùng. Trong cuộc nói chuyện đam mê đó là siêu kiến ​​trúc.

Tôi đã phát hiện ra rằng nó thực sự có thể giúp ích khi bạn chỉ cho họ biết ý nghĩa của việc viết mã. Hiển thị các bên liên quan về cơ sở mã mà bạn đang làm việc. Ngay cả khi bạn đã chọn tên biến và tên phương thức tốt, hầu hết mọi người sẽ nghĩ bạn đang sử dụng một loại ma thuật đen nào đó. Có lẽ họ sẽ hiểu, tại sao bạn cần nhiều hơn "một vài ngày" để triển khai một tính năng mới cho phần mềm của họ.