Làm thế nào để bạn thuyết phục quản lý để vứt bỏ một nguyên mẫu?

Tôi thích tạo mẫu như một cách hiệu quả nhanh chóng để đặt UI trước người dùng.

Tuy nhiên, nhiều lần, ban quản lý nhận được cái mỏ của họ, và nguyên mẫu bị kéo vào đá và hét vào phát triển luồng chính.

Làm thế nào để bạn quản lý quản lý để không làm điều này?

Sử dụng một công cụ như Microsoft SketchFlow hoặc tạo nguyên mẫu của bạn bằng một số ngôn ngữ hoặc nền tảng khác, khiến cho việc tích hợp vào phát triển chính gần như không thể.

Ngoài ra còn có một bài tiểu luận joelonsoftware về hiển thị ảnh chụp màn hình và nguyên mẫu, trong đó anh ta làm cho các khía cạnh không được thực hiện và không được làm việc rõ ràng bị phá vỡ / không được thực hiện, làm cho nó rõ ràng nơi công việc vẫn cần phải được thực hiện.

Hệ quả quan trọng Hai. Nếu bạn hiển thị một người không lập trình màn hình có giao diện người dùng đẹp 100%, họ sẽ nghĩ rằng chương trình gần như đã hoàn tất.

...

bạn có thể làm gì về điều này? Một khi bạn hiểu Bí mật Iceberg, thật dễ dàng để làm việc với nó. Hiểu rằng bất kỳ bản demo nào bạn làm trong phòng tối có máy chiếu đều sẽ có tất cả về pixel. Nếu bạn có thể, hãy xây dựng giao diện người dùng của bạn theo cách mà các phần chưa hoàn thành trông chưa hoàn thành. Ví dụ: sử dụng chữ nguệch ngoạc cho các biểu tượng trên thanh công cụ cho đến khi chức năng ở đó. Khi bạn đang xây dựng dịch vụ web của mình, bạn có thể muốn xem xét thực sự bỏ các tính năng khỏi trang chủ cho đến khi các tính năng đó được xây dựng. Bằng cách đó, mọi người có thể xem trang chủ đi từ 3 lệnh đến 20 lệnh khi nhiều thứ được xây dựng hơn.

Vì vậy, hãy thử tạo các nguyên mẫu của bạn trong Photoshop thay vì Visual Studio, hoặc một cái gì đó dọc theo các dòng đó.

Đừng nguyên mẫu với mã làm việc. Nguyên mẫu bằng bút chì và giấy, hoặc một phần mềm tương đương .

Sử dụng Mockups cho cảm giác như vẽ, nhưng vì nó là kỹ thuật số, bạn có thể điều chỉnh và sắp xếp lại dễ dàng. Các đội có thể đưa ra một thiết kế và lặp lại theo thời gian thực trong quá trình họp.

Sử dụng giấy có lợi ích là các thành viên trong nhóm có thể dễ dàng nhảy vào và mọi người hiểu rằng đó chỉ là một tờ giấy trắng. Điều này làm cho nó có vẻ ít quý giá hơn.

Không bao giờ thỏa hiệp chất lượng mã của bạn.

Viết mã rác là một nền kinh tế sai lầm.

Như các áp phích khác đã đề nghị bạn có thể đạt được điều này bằng cách sử dụng các công cụ cụ thể để mô phỏng.

Tuy nhiên, có nhiều lý do khác nhau để xây dựng các nguyên mẫu. Đôi khi bạn có thể hiển thị những gì bạn cần mà không cần viết mã, nhưng thường thì đây không phải là trường hợp. Một bên liên quan có thể muốn bạn chứng minh tính khả thi kỹ thuật của một tính năng.

Xây dựng điều hoàn toàn gọn gàng nhất bạn có thể để chứng minh tính năng / chứng minh khái niệm. Để lại bất cứ điều gì khác.

Đối với tính năng UI, đảm bảo bạn không phát triển bất cứ thứ gì trên máy chủ - hoàn toàn không chạm vào nó. Phát triển lại giả / giả được xây dựng trong.

Nếu bạn cần nỗ lực để làm cho UI phù hợp với phong cách của phần còn lại của ứng dụng thì đừng bận tâm. Nếu nó trông đủ tốt mà không cần bất kỳ nỗ lực nào thì hãy thay đổi màu sắc để làm cho nó nổi bật, hoặc thậm chí có thể là một hình mờ để cho thấy rằng nó là một nguyên mẫu.

Tôi đã tìm thấy những người có khả năng gây ra các nguyên mẫu biến thành mã sản xuất là những người bán hàng. Họ sẽ bán sản phẩm của bạn cho khách hàng mới - nếu không có tính năng mới này, khách hàng sẽ không ký. Bạn không thể đổ lỗi cho họ, họ có mục tiêu. Hãy cẩn thận với họ; hãy chắc chắn rằng họ không bắt bạn lấy ra những thứ chỉ ra rằng đó là nguyên mẫu. Bạn phải giữ vững lập trường của mình - dù sao họ cũng không nên làm khách hàng hiểu lầm.

Quản lý của bạn có thể bắt đầu buộc bạn phải biến một nguyên mẫu thành từng mảnh mã sản xuất, nếu bạn làm theo lời khuyên đầu tiên của tôi đừng bao giờ viết mã crappy, bạn sẽ không gặp vấn đề gì. Dần dần, bạn xây dựng phần mềm, không thỏa hiệp.

Sau đó, nếu quản lý bắt đầu buộc bạn phải giảm chất lượng, bạn phải tự hỏi tại sao. Họ có thụ động không? Yếu? tuyệt vọng? Không ai trong số những điều đó là lý do tốt để gắn bó tại một công ty.

Khá đơn giản thực sự. Nói với họ rằng họ cuối cùng sẽ mất khách hàng yêu thích của họ nếu cuối cùng họ đưa ra lỗi lộn xộn này để trình diễn.

Và vâng, yêu cầu họ nắm lấy cơ hội của họ nếu họ thực sự biết rõ hơn.

Cuối cùng: Xin đừng nói rằng nguyên mẫu có các lỗi cụ thể A, B và C. Sau đó, bạn sẽ được thực hiện để sửa lỗi đó và ban quản lý sẽ tuyên bố họ chuyển năng lượng vào để sẵn sàng sản xuất phần mềm.

Có thể với những phần thưởng hiệu suất và tài trợ cổ phiếu trong tương lai những ngày này, họ sẽ lắng nghe.

Sidestep vấn đề ở nơi đầu tiên. ĐỪNG HOÀN THÀNH NÓ. Điều đó có nghĩa là tôi không làm cho nó trông đẹp hoặc giống như nó phù hợp với các phong cách hiện có trên trang web. Mục tiêu chỉ đơn giản là để có được phiên bản hoạt động thô sơ nhất có thể để bạn có thể thấy rằng luồng UI rất cơ bản hoạt động. Nếu bạn ném kiểu trang web hiện có lên nó hoặc đánh bóng quá mức, họ sẽ cho rằng bạn chỉ có thể "cắm nó vào". Quản lý giống như Pakleds từ Star Trek. Họ chỉ muốn bạn "làm cho nó đi." Bạn càng sẵn sàng để làm cho nó dường như, họ sẽ sẵn sàng hơn để nghĩ rằng nó là.

Nếu điều đó không giải quyết được vấn đề của bạn, hãy kiếm một công việc tại ít nhất một công ty có thương hiệu nổi tiếng trong một năm. Đặt email và số của bạn vào một sơ yếu lý lịch trực tuyến và bạn sẽ chống lại các nhà tuyển dụng bằng một cây gậy, điều này cho phép bạn nói với họ "hoàn toàn không" với sự tự tin của một nhà phát triển biết họ đang làm gì và có thể có một công việc mới ngày mai, nơi hy vọng chuyên môn của bạn về vấn đề này được thực hiện nghiêm túc hơn.

Tôi hiện đang làm việc trên một cơ sở mã không chỉ có hai mà là ba ngăn xếp của Rails, .NET và Java. Lý do chúng tôi có được Rails đã giải quyết là vì một nguyên mẫu đã được thực hiện trong Rails và chú chó hàng đầu tại công ty đã nói "làm cho nó đi". Chúng ta cần nói không đôi khi. Miễn là chúng ta không làm việc đó mọi lúc họ nên coi trọng chúng ta.

Nhưng vâng, bất cứ điều gì bạn làm với một nguyên mẫu, hãy chắc chắn rằng nó bắt đầu thực sự xấu xí.

Đừng lo lắng về điều đó.

Nếu bạn ngồi xuống và ném các điều khiển UI cho một "nguyên mẫu", thì chính xác là không có lý do gì bạn nên tự động vứt bỏ thiết kế đó. Nếu nó đủ tốt để hiển thị quản lý, thì đó là nơi tốt để bắt đầu khi mã hóa chương trình "thực".

Chuyển từ một nguyên mẫu sang một giao diện người dùng "bóng bẩy hơn" không gì khác hơn là một loạt các bước hoàn toàn chính đáng. Bạn phải thêm một nút thứ hai. Bạn đã nhận được phản hồi từ người dùng rằng họ tìm thấy thứ tự khó hiểu. Nhóm tiêu chuẩn của tổ chức của bạn đã đưa ra một thay đổi nhỏ. Bạn phải thay đổi kích thước của hộp văn bản để quốc tế hóa.

Không một trong những lý do đó là "tốt, nó chỉ là một nguyên mẫu." Trong thiết kế giao diện người dùng hoặc bằng mã hoặc bằng văn bản, MỌI THỨ có thể sống mãi mãi. Và những người không nên có tất cả những lý do rất chính đáng để giết họ.

Và quản lý có lẽ không quan tâm.

Trên thực tế, nếu lý do bạn không bỏ UI của mình vào mã hiện tại là "Tôi phải viết lại nó trong khung chính xác của chúng tôi", thì điều đó đã đủ lý do. Và nếu không, có lẽ bạn nên thảo luận về khung UI, nhưng đó là một câu hỏi khác.

Tôi đã từng gặp vấn đề này, cho đến khi, tôi nhận ra đó không phải là vấn đề mà là cách giải phóng bản thân khỏi các tiêu chuẩn phát triển khá lỗi thời áp đặt cho hầu hết các cửa hàng.

Vì vậy, bạn nói với quản lý của bạn rằng bạn đang viết một nguyên mẫu, bạn chọn các công nghệ phù hợp nhất với bạn, cho lĩnh vực có vấn đề này và sau đó bạn viết phần mềm với đầy đủ kiến ​​thức mà nó sẽ đưa vào sản xuất.

Bạn thoát khỏi sự nhàm chán của "các ứng dụng phải có trong java 1.6 bằng cách sử dụng Web (chèn công cụ quản lý J2EE đắt tiền của sự lựa chọn quản lý)" và các tiêu chuẩn đặt tên vô nghĩa, v.v.

Các ngôn ngữ nguyên mẫu hiện tại mà tôi lựa chọn là "php" (hoàn toàn mở rộng ra môi trường sản xuất nhiệm vụ nặng nề - chỉ cần hỏi Facebook) và sự kết hợp rất thanh lịch của Groovy / Java với Tomcat hoặc Jetty.

Sự kết hợp Groovy / java là tuyệt vời để phát triển nhanh chóng. Groovy rất hay khi sử dụng nhanh để phát triển nhưng hoạt động như một con ốc sên lão khoa, tuy nhiên việc dễ dàng tái lập các phần quan trọng về hiệu năng trong Java thuần túy. Kết hôn ứng dụng với Tomcat hoặc Jetty có nghĩa là không bao giờ phải đối phó với EJB và nỗi kinh hoàng J2EE khác nữa.

Ưu điểm chính của việc có một nguyên mẫu hoạt động trái ngược với bản phác thảo được đề xuất bởi một số áp phích là phản hồi của người dùng. Nguyên mẫu là một cách tuyệt vời để khiến doanh nghiệp thực sự tham gia vào thiết kế. Một khi họ nhận ra họ có thể nói những điều như "không nên lĩnh vực đó trên màn hình chính" và xin chào! Có nó trên màn hình chính ở bản demo tiếp theo họ mở ra và tham gia vào thiết kế mang lại nhiều năm kinh nghiệm kinh doanh quý giá cho dự án.