Table of Contents
(Bài dịch từ SmashingMagazine.com – tác giả Paul Boag)
Designer có thể code? Chủ đề chưa bao giờ có hồi kết trong các bài blog, chủ đề trên Twitter hay trong các buổi đối thoại. Nhưng việc các developer tham gia vào qui trình thiết kế nghe có vẻ không khả quan cho lắm. Đây thực sự là một thiếu sót lớn, bởi hiện tại số lượng các developer có thể tham gia vào các buổi thảo luận về thiết kế là không nhỏ – họ rất ‘đông’ nhưng không hề ‘nguy hiểm’.
Có một sự thật đáng buồn là có rất nhiều designer có thái độ hơi ‘elitist’ (tạm dịch là chủ quan duy ý chí) khi ‘thiết kế’. Vì luôn cho rằng chỉ designer mới có ý tưởng thiết kế tốt. Đây thật sự sai lầm.
Tất cả mọi người đều có khả năng đưa ra ý tưởng thiết kế tốt, kể cả những anh coder sần sùi, bụi bậm. Nhưng phải thừa nhận rằng, một designer được đào tạo bài bản chắc chắn sẽ đưa được giải pháp thiết kế hiệu quả hơn. Nhưng không có nghĩa là những người khác không nên trỏ mỏ vào. Là một designer, bạn cần phải ‘nuốt bớt’ niềm tự hào của mình vào trong và lắng nghe ý kiến của mọi người. Còn chần chờ gì bạn mà không ưu tiên các chàng coder của mình trong các buổi thảo luận.
Những rắc rối khi không có sự hiện diện của developer
Trở lại thời hoàng kim của Digg, trong cuộc trò chuyện giữa Daniel Burka (thiết kế chính cho Digg) và Joe Stump (một nhà phát triển của thương hiệu này). Họ kể câu chuyện về sự thay đổi thiết kế nút Digg mà Daniel trước đây từng giới thiệu. Daniel cho rằng đây là sự thay đổi rất rất nhỏ trong thiết kế. Cho đến khi nói chuyện với Joe, ông mới phát hiện ra rằng thay đổi ‘nhỏ’ này sẽ có một ảnh hưởng khủng khiếp về hiệu suất trang web, buộc Digg phải nâng cấp kiến trúc sức mạnh xử lý và server của họ.
Nhiều bạn có thể nhìn thấy những khó khăn của chính mình – đó là vấn đề không thể tránh khỏi khi để các developer ra khỏi qui trình thiết kế. Đôi khi sẽ trở thành thảm họa và dẫn đến những mẫu thiết kế quá hoàn hảo mà không thể thực hiện được, hoặc gây ra những rắc rối kỹ thuật không cần thiết. Trở lại cuộc chiến giữa các nhà developer & designer khi các developer đang đấu tranh để khắc phục vấn đề tạo ra bởi designer, những ngày fix bug bị tiêu tốn lãng phí và cứ lặp đi lặp lại – tất cả bởi vì họ đã không được tham gia ý kiến.
Đặc biệt, cũng nên cân nhắc trước những mẫu thiết kế khi đến tay khách hàng. Khách hàng đã ký hợp đồng dựa trên mẫu thiết kế và được thông báo sau đó rằng nó không thể được xây dựng. Điều này sẽ ảnh xấu đến tất cả mọi người. Đây là lý do tại sao chúng ta cần các tay developer tham gia vào quyết định một mẫu thiết kế. Những quyết định khi đó sẽ giúp các designer như mọc thêm cánh trong nhận thức.
Các developer sẽ giúp nâng cao hiểu biết về những chức năng ‘có thể’ làm ra được
Vấn đề ở chỗ chúng ta cần không cần developer tham gia chỉ để phản bác những ý tưởng không khả thi. Đôi khi phải ‘sàn lọc’ những ý tưởng của chính mình bởi những hạn chế kỹ thuật, đặc biệt nếu tự mình code. Nếu không biết một ý tưởng có thể xây dựng được hay không, thì câu trả lời có thể là ‘KHÔNG’.
Developer đôi khi sẽ phản đối một vài ý tưởng. Nhưng cũng có lúc họ sẽ xây dựng chúng và đưa làm ra những kết quả hơn chúng ta đã bao giờ nghĩ rằng họ làm có thể ra được. Tôi từng ở trong cuộc họp với các developer, họ đã đề xuất những thứ tôi thậm chí không biết là có thể làm ra dễ dàng. Nếu không tham gia buổi thảo luận đó, tôi chắc sẽ bỏ rơi trên những hiểu biết hay ho này.
Hơn nữa, sau khi đã học qua các qui trình. Bằng cách làm việc chặt chẽ với các developer, sự am hiểu về phát triển ứng dụng sẽ tăng lên. Sẽ vẫn là một designer, nhưng kiến thức về xây dựng một ứng dụng được tăng lên và thấy mình trở nên khách quan, sáng suốt hơn. Một ‘generalist’ thì không có gì xấu (tạm dịch là tổng hợp gia).
 |
| Đưa các developer vào qui trình thiết kế sẽ tiết kiệm những giờ làm việc vô nghĩa |
Các developer cũng quyết định một thiết kế
Lý do lớn nhất để lôi kéo các developer là họ sẽ người hoàn tất cho các quyết định thiết kế. Có một sự thật là, một anh developer khi bắt đầu đào sâu vào việc build up một dự án, anh ta sẽ phải đưa ra những quyết định ảnh hưởng đến tinh chỉnh và cập nhật ít nhất 20% so với thiết kế ban đầu. Các designer hiếm khi có thời gian để xem xét tất cả các tình huống của một trang web. Thì phần còn lại rơi vào tay các developer.
Khi được tham gia các cuộc thảo luận thiết kế ban đầu, các developer sẽ được ngồi ở một vị trí tốt hơn để lắp vào những lỗ hổng này. Và khi cần thỏa hiệp về mẫu thiết kế, họ sẽ được ở một vị trí tốt hơn để thực hiện những cuộc gọi.
Quyền hạn của các developer về mẫu thiết kế
Lý do cuối cùng mà phải đưa các developer trong quá trình này: Chính những người này sẽ gắn bó nhiều hơn với các dự án. Đến khi, đang ở giai đoạn cuối của một chuỗi dài ngoằn của việc dev, họ ra quyết định thay đổi một vài thứ, nhưng tiếng nói của họ không còn được ‘nghe’, vì ý kiến được đưa ra quá muộn. Điều này làm cho họ cảm thấy mình không có quyền hạn gì trên dự án. bằng cách tham gia ngay từ đầu, các developer sẽ cảm thấy được kết nối nhiều hơn với công việc và cũng được đánh giá cao hơn.
Câu hỏi đặt ra sau đó, là làm thế nào để các developer và designer ngồi chung với nhau trong quá trình này?
Vậy chúng ta mong chờ điều gì?
Sự tham gia của một developer trong quá trình thiết kế không phải là khoa học tên lửa. Nó sụp đổ nếu cứ mời họ vào tất cả buổi họp về thiết kế.
Cứ để các developer tham gia vào các bài thiết kế mà bạn thực hiện với khách hàng. Khuyến khích họ tham gia vài đợt thử nghiệm về ‘usability’ của bạn và tham gia ngay từ lúc khởi đầu của dự án. Làm càng sớm, bạn sẽ càng có lợi. Đặc biệt, chỉ cho họ các thiết kế của bạn sớm, trước khi mà khách hàng nhìn thấy nó. Thông thường, một khách hàng sẽ ký hợp đồng trên một thiết kế và sau đó các nhà phát triển sẽ phát hiện ra rằng nó không thể xây dựng được! Bạn sẽ quay lại nói chuyện với khách hàng của mình thế nào đây?
Tất nhiên, các cuộc họp có sự xuất hiện của các developer càng nhiều, thì thời gian cho lập trình sẽ ‘ít lại’. Chúng ta phải cân bằng về việc này. Sẽ có những cuộc họp sẽ trở nên tiêu cực nếu né tránh việc phải tốn thêm thời gian thực hiện.
Một điều bạn có thể làm mà không ảnh hưởng đến thời gian của các developer. Là cứ để designer và developer ngồi gần nhau. Khi đó, người này sẽ bình luận về công việc của người kia. Khi anh developer có thể nhìn qua màn hình của cô nàng designer, dĩ nhiên sẽ lên tiếng nếu họ không thích những gì họ nhìn thấy!
Có thể nói, đây là tất cả về phá bỏ các rào cản giữa vai trò và khuyến khích việc hợp tác trong công việc nhiều hơn, không chỉ giữa các developer và desginer mà còn giữa các nhân viên trong bất kỳ ngành nghề nào. Chúng ta càng hiểu rõ những gì các đồng nghiệp mình làm thì càng giảm bớt cái tôi của mình, lẽ dĩ nhiên kết quả công việc sẽ tốt hơn.
Không cho các developer tham gia ngay từ lúc thiết kế cũng giống như che bớt tầm nhìn của bạn về những thứ dự án đang chạy và khả năng khác mà nó có thể làm. Trong thực tế, bất cứ ai – dù copywriter hoặc chuyên gia SEO – nếu không được tham gia, cuối cùng đểu ảnh hưởng công việc chúng ta. Đúng không?