Là một nhà phát triển, bạn có thể chỉ bắt đầu xây dựng các tính năng và sản phẩm. Tuy nhiên, trước khi sử dụng bàn phím, bạn nên suy nghĩ về những gì người dùng của bạn cần. Bạn có quy trình để hiểu và ưu tiên nhu cầu của người dùng cũng như những điểm khó khăn không? Làm cách nào bạn có thể xoay vòng hoặc lặp lại các tính năng sản phẩm của mình dựa trên phản hồi của người dùng và thử nghiệm khả năng sử dụng?

In cuộc nói chuyện này, Veerle, Trưởng phòng Khoa học Dữ liệu tại Analytic Health đã chia sẻ về cách xây dựng phần mềm từ đầu từ quan điểm thiết kế lấy người dùng làm trung tâm. Tìm video sự kiện có dấu thời gian trong phần đầu tiên và đoạn ghi âm trong phần thứ hai.

Ghi sự kiện ảo

Xây dựng phần mềm từ đầu, phương pháp lấy người dùng làm trung tâm

• 02: 15 Giới thiệu
• 04:54 Quy trình phát triển phần mềm nhanh
• 11:07 Thiết kế lấy người dùng làm trung tâm (UCD)
• 22:44 Những thách thức với phát triển phần mềm
• 32:18 Kinh nghiệm diễn giả và mẹo
• 44:26 Kết thúc
• 46:33 Câu hỏi?

Blog sự kiện & bản ghi

Host: Chúng ta có thể bắt đầu. Xin chào tất cả mọi người, chào mừng đến với Sự kiện Codementor. Đối với những bạn đang tham gia sự kiện thứ hai với chúng tôi, xin chào một lần nữa. Tên tôi là Maggie. Cảm ơn một lần nữa vì đã tham gia ngày hôm nay. Thực sự tuyệt vời khi có tất cả các bạn ở đây với chúng tôi và tôi thực sự vui mừng được ở đây cùng với diễn giả Veerle của chúng tôi, để lắng nghe cô ấy, chia sẻ nhiều hơn về kinh nghiệm của cô ấy, xây dựng phần mềm từ đầu và cách tiếp cận lấy người dùng làm trung tâm.

Nếu bạn có bất kỳ câu hỏi nào trong suốt sự kiện, vui lòng giơ một bàn tay ảo để cho cô ấy biết. Ngoài ra, bạn cũng có thể nhập chúng trực tiếp trong một cuộc trò chuyện và chúng tôi sẽ đảm bảo rằng chúng tôi tiếp cận được nhiều người trong số họ nhất có thể tại phần Hỏi và Đáp ở cuối. Veerle, sân khấu là của bạn.

Veerle: Chào mọi người. Cảm ơn Maggie đã chào đón tôi. Hôm nay tôi sẽ nói với bạn điều gì đó về việc xây dựng phần mềm từ đầu, phương pháp lấy người dùng làm trung tâm. Hãy để tôi chia sẻ màn hình và kéo bản trình bày của tôi lên.

Như Maggie đã nói, và trong đoạn chat đã nói, nếu có bất kỳ câu hỏi nào, bạn cứ giơ tay lên và thoải mái ngắt lời tôi và tôi sẽ trả lời câu hỏi đó ngay lập tức. Sau phần trình bày, chúng tôi cũng sẽ có một phần hỏi đáp. Vì vậy, nếu bạn đặt câu hỏi của bạn thông qua trò chuyện, chúng tôi sẽ trả lời chúng sau.

Veerle: Vì vậy, ngày nay, xây dựng phần mềm từ đầu - cách tiếp cận lấy người dùng làm trung tâm. Chúng ta thực sự sẽ nói về điều gì hôm nay? Đầu tiên, tôi sẽ giới thiệu ngắn gọn. Bạn biết ai đang nói chuyện, cũng có thể hiểu thêm về công ty của tôi và sau đó chúng ta sẽ đi vào quy trình phát triển phần mềm nhanh nhẹn và quy trình đó trông như thế nào. Sau đó, chúng ta sẽ nói về những thách thức thường xảy ra khi bạn đang xây dựng phần mềm. Sau đó, tôi sẽ nói về những kinh nghiệm và học hỏi của tôi mà tôi cảm thấy rằng chúng tôi có được trong chính công ty của chúng tôi. Tôi sẽ hoàn thành một cách nhanh chóng. Và như tôi đã nói, tại phần Hỏi - Đáp, tôi sẽ giải đáp mọi thắc mắc của bạn. Sau bài thuyết trình này, tôi cũng sẽ chia sẻ các slide thuyết trình với các bạn. Vì vậy, nếu có bất cứ điều gì bạn muốn ghi chú lại, hãy lưu ý rằng tôi sẽ chia sẻ mọi thứ sau đó.

Giới thiệu

Veerle: Vậy tôi là ai? Tôi là Veerle. Tôi đang gọi điện từ Hà Lan hôm nay. Tôi sống ở đó và tôi đã tốt nghiệp với tư cách là nhà khoa học dữ liệu vào năm 2015 từ trường đại học Dilbert. Sau đó, tôi bắt đầu làm việc tại nhiều công ty với tư cách là nhà khoa học dữ liệu. Tôi đã làm việc tại một công ty năng lượng lớn. Đó là công việc đầu tiên của tôi. Và sau đó vào năm 2018, tôi đã tham gia vào lĩnh vực chăm sóc sức khỏe hoặc lĩnh vực dược phẩm với tư cách là một nhà khoa học dữ liệu.

Khi tôi làm việc ở đó, tôi đã có ý tưởng thành lập công ty của riêng mình. Vì vậy, tôi thành lập doanh nghiệp của riêng mình, Hypebright, và tôi đã thực hiện một số tư vấn về khoa học dữ liệu ở đó. Và trong thời gian đó, tôi đã gặp đối tác kinh doanh hiện tại của mình, Greg, người mà tôi hiện đang điều hành Analytics Health. Tôi là một nhà phát triển. Tôi phát triển chủ yếu ở R và Shiny, nhưng cũng có Node và Vue.

Đó là một cái nhìn tổng quan cơ bản về tôi. Sau đó, một chút nữa về công ty của chúng tôi. Vì vậy, cùng với đối tác kinh doanh của tôi, Greg và người đứng đầu hoạt động của chúng tôi, Jana, chúng tôi phát triển các công cụ và ứng dụng web cho lĩnh vực chăm sóc sức khỏe. Vì vậy, chúng tôi thu thập và phân tích dữ liệu chăm sóc sức khỏe để lấy giá trị từ dữ liệu, vì chúng tôi tin rằng chúng tôi có thể đẩy nhanh sự đổi mới trong lĩnh vực chăm sóc sức khỏe bằng cách cấp quyền truy cập vào các nguồn dữ liệu chất lượng cao. Và bằng cách cung cấp cho các chuyên gia chăm sóc sức khỏe những công cụ họ cần để phân tích dữ liệu. Chúng tôi thu thập dữ liệu chăm sóc sức khỏe từ Vương quốc Anh hàng ngày, tất cả đều thông qua các nguồn dữ liệu mã nguồn mở. Và chúng tôi cũng sử dụng dữ liệu bán hàng nội bộ từ các công ty dược phẩm. Hầu hết các công cụ chúng tôi phát triển đều được phát triển trong R, chẳng hạn như chúng tôi có các ứng dụng Shiny và chúng tôi có các API cũng nằm trong R. Bên cạnh đó, chúng tôi có các ứng dụng trong Node và Vue.

Veerle: Như bạn có thể thấy, chúng tôi có ba loại ứng dụng. Chúng tôi có Phân tích dược phẩm và Dữ liệu đám mây dược phẩm, sau đó chúng tôi có Cổng thông tin dược phẩm. Pharmly Cloud Data là thị trường cung cấp dữ liệu chăm sóc sức khỏe của chúng tôi, vì vậy đây là nơi bạn có thể truy cập vào tất cả các nguồn dữ liệu chăm sóc sức khỏe chất lượng cao của mình ở Vương quốc Anh. Giờ đây Pharmly Analytics là một ứng dụng được xây dựng dựa trên dữ liệu đó để cung cấp cho bạn thông tin chi tiết về dữ liệu thực sự và Pharmly Portal là nơi tập hợp tất cả các ứng dụng đó về cơ bản. Về cơ bản, đó là trang chủ của chúng tôi, trang chủ của các sản phẩm Pharmly mới của chúng tôi, chúng tôi cũng đã phát triển một số ứng dụng dành riêng cho một số khách hàng của chúng tôi, chủ yếu là các công ty dược phẩm.

Quy trình phát triển phần mềm nhanh

Hãy bắt đầu quá trình phát triển nhanh nhẹn. Vậy bạn xây dựng phần mềm bằng cách tiếp cận lấy người dùng làm trung tâm như thế nào? Và bây giờ câu hỏi đầu tiên xuất hiện trong đầu, tại sao chúng ta cần một quá trình để bắt đầu? Bởi vì chúng ta chỉ có thể xây dựng phần mềm, phải không? Chúng tôi có thể chỉ cần bắt đầu viết mã và xây dựng các tính năng, nhưng chúng tôi cần một quy trình vì quy trình này giúp bạn điều chỉnh kỳ vọng giữa các nhà phát triển, các thành viên trong nhóm của bạn, các bên liên quan hoặc người dùng của bạn, nhưng nó cũng giúp bạn chính thức hóa cách bạn nên giải quyết các yêu cầu mới hoặc với lỗi hoặc với những suy nghĩ mới.

Nếu bạn có một quy trình hoặc một kế hoạch, thì cuối cùng, nó sẽ ngăn chặn việc làm lại không cần thiết. Bên cạnh đó, nó giúp bạn ở trong phạm vi ngân sách và rõ ràng là một quá trình giúp bạn lập kế hoạch. Vì vậy, tôi nghĩ rằng có một quy trình là một ý tưởng thực sự tốt nếu bạn đang xây dựng phần mềm của mình.

Và sau đó là câu hỏi, tại sao chúng ta lại quan tâm đến tư cách là một nhà phát triển?

Veerle: Tại sao chúng ta quan tâm đến một quá trình như vậy? Tại sao chúng tôi quan tâm đến việc lấy người dùng làm trung tâm? Bởi vì suy cho cùng, việc duy nhất chúng ta làm là viết mã, đúng không? Tuy nhiên, tùy thuộc vào ngữ cảnh, bạn với tư cách là nhà phát triển thực sự có thể tham gia vào tất cả các phần của quy trình. Vì vậy, bạn có thể là thành viên của một nhóm với tương tự như 20 nhà phát triển và một vài nhà thiết kế UX và hàng chục người quản lý dự án và tất cả những điều đó. Khi đó, vai trò của bạn rõ ràng sẽ rất khác so với một vai trò nào đó, chẳng hạn như trong công ty của chúng tôi, nơi chúng tôi có một nhóm phát triển nhỏ chỉ 1-3 nhà phát triển trong đó bạn rất gần gũi với người dùng. Vì vậy, là một nhà phát triển, tùy thuộc vào lĩnh vực kinh doanh mà bạn đang kinh doanh, bạn có thể tham gia vào các phần khác nhau của quy trình.

Bên cạnh đó, nếu bạn biết về quy trình và nếu bạn hiểu về quy trình, bạn cũng có thể cảm thấy ít thất vọng hơn khi một số quyết định trong quá trình thay đổi. Tôi nghĩ tất cả chúng ta đều nhận ra cảm giác rằng chúng ta đã phát triển một thứ gì đó, và sau đó hai tuần nó cần phải thay đổi. Bạn biết đấy, bạn đã làm ra điều gì đó, bạn đã nỗ lực vào nó. Và sau đó vài tuần, mọi thứ cần phải khác 180 độ. Thật là bực bội. Và đặc biệt nếu bạn không biết điều đó đến từ đâu, thì việc hiểu lý do tại sao bạn cần thay đổi điều đó cũng không giúp ích được gì cho bạn. Vì vậy, cũng tham gia vào quá trình này khiến bạn nhìn thấy bức tranh toàn cảnh hơn. Nó làm cho bạn hiểu tại sao bạn đang làm mọi việc. Và tại sao bạn đang phát triển theo một cách nhất định.

Veerle: Sau đó, tôi nghĩ rằng bạn luôn cung cấp phần mềm như một nhóm. Không quan trọng đội ngũ đó lớn hay nhỏ, bạn đang cùng nhau xây dựng một sản phẩm. Vì vậy, tôi nghĩ công bằng hơn là bạn được đầu tư vào quá trình này. Toàn bộ nhóm đang làm để xây dựng sản phẩm phần mềm đó. Và nó không chỉ quan trọng đối với các dự án phần mềm lớn của bạn hoặc chỉ khi bạn đang làm việc trong một công ty, mà các dự án phụ của bạn cũng có thể được hưởng lợi từ một cách tiếp cận phù hợp bởi vì ngay cả các dự án phụ của bạn, bạn cũng có thể quản lý theo cách mà bạn có thể thực hiện cuối cùng là sản phẩm mà người dùng của bạn hài lòng.

Tôi không nghĩ là tôi đã đề cập đến, nhưng bản thân tôi là một bậc thầy về scrum. Vì vậy, tôi có rất nhiều kinh nghiệm với phương pháp nhanh nhẹn và tôi thực sự yêu thích nó và chúng tôi sử dụng liên công ty này để hợp lý hóa các dự án của mình và tôi chắc chắn cũng sẽ giới thiệu nó, nếu bạn đang phát triển phần mềm.

Veerle: Vậy đo la cai gi? Nếu chúng ta đang tìm hiểu về phát triển phần mềm nhanh nhẹn là gì, thì về cơ bản chúng ta đang nói về các chu kỳ nhỏ hoặc ít lần lặp lại mà bạn đang thực hiện. Ví dụ, bạn thấy ở đây một sự lặp lại như vậy trên màn hình. Bạn bắt đầu lặp lại bằng cách lập kế hoạch và thích, về cơ bản tìm hiểu các yêu cầu là gì. Sau đó, bạn bắt đầu thiết kế tính năng đó. Sau đó, bạn bắt đầu viết mã. Sau đó, bạn phát hành, bạn nhận được phản hồi về tính năng này và bạn thực hiện lại tất cả. Vì vậy, vòng lặp lặp đi lặp lại nhỏ liên tục này, thông thường một chu kỳ mất khoảng hai tuần hoặc vài thứ. Vòng lặp lặp lại nhỏ này giúp bạn tham gia về cơ bản cho người dùng và các bên liên quan của bạn. Và đó là một cách tuyệt vời và một cách hiệu quả để cung cấp phần mềm hữu hình, ngay từ rất sớm. Bởi vì cứ hai tuần một lần, bạn muốn phát hành một thứ gì đó, mặc dù nó giống như một nút nhỏ hoặc đó là sự thay đổi kiểu dáng ứng dụng của bạn hoặc bất cứ thứ gì bạn muốn phát hành càng nhanh càng tốt để nhận được phản hồi của cô ấy càng tốt. Và điều đó rất quan trọng nếu bạn đang phát triển một phần mềm lấy người dùng làm trung tâm.

Tại sao chúng ta cần phải nhanh nhẹn?

Veerle: Như tôi đã nói, đó là một cách hiệu quả để cung cấp phần mềm hữu hình càng sớm càng tốt. Giống như hai tuần một lần hoặc một cái gì đó giống như bình thường. Bởi vì bạn thích làm việc trong những lần lặp lại nhỏ này, như liên tục thu thập phản hồi, chẳng hạn như hai tuần một lần, bạn cũng có thể nhanh chóng bắt đầu thay đổi các yêu cầu của người dùng.

Và tôi nghĩ rằng việc có những loại chu trình và công cụ này mang lại cho bạn nhiều sự minh bạch và phản hồi liên tục, vì vậy bạn có thể cải thiện sản phẩm của mình. Bên cạnh đó, thông thường trong khoảng thời gian ngắn như vậy, bởi vì bạn đang thu thập phản hồi, bạn thực sự đang tương tác với các bên liên quan và người dùng của bạn bởi vì bạn cần phải kiểm tra phần mềm nếu người dùng thích nó.

Vì vậy, có sự tham gia cao ở đó. Nó cũng tuyệt vời cho sự mong đợi vì thông thường, bạn biết đấy, chính xác là trong hai tuần tới, chúng tôi sẽ làm điều này và điều kia. Và sau đó các bên liên quan của bạn biết, vào cuối hai tuần này, tôi có thể mong đợi nút này ở đây hoặc ở đó, nơi các chức năng này hiện diện.

Veerle: Và tôi nghĩ sẽ ít nản lòng hơn khi làm việc trong những loại chu kỳ nhỏ hơn này so với những dự án lớn. Bởi vì nếu bạn có một dự án lớn và giả sử, dự án này sẽ mất tám tháng, hãy làm đi, hãy vui vẻ. Ý tôi là, tôi nghĩ điều đó khá khó khăn nếu bạn nói, tốt, tám tháng, tôi cần phải làm gì? Tôi sẽ tổ chức điều đó như thế nào? Vì vậy, hãy cắt nó thành các bit nhỏ hơn. Sau đó, bên cạnh sự nhanh nhẹn. Có một triết lý khác mà nếu bạn có liên quan một chút, bạn thực sự sẽ biết và chúng tôi gọi đó là thiết kế lấy người dùng làm trung tâm. Thiết kế lấy người dùng làm trung tâm giống như một phương pháp khác bên cạnh nhanh nhẹn, cũng là về tỷ lệ của nó ở đây.

Chỉ tập trung thực sự vào người dùng và đó là thiết kế các tính năng và chức năng của bạn để về cơ bản phù hợp với người dùng nhất có thể. Vì vậy, trước tiên bạn sẽ xem, được rồi, người dùng của tôi cần gì? Bạn cố gắng đồng cảm với họ và bạn sẽ xác định giống như các yêu cầu của một tính năng hoặc chức năng mà họ sẽ hình thành hoặc đưa ra ý tưởng về nó.

Đó là động não, sau đó bạn đang xây dựng một nguyên mẫu và sau đó bạn sẽ kiểm tra nó. Nguyên tắc thiết kế lấy người dùng làm trung tâm này không phải là về viết mã, mà nó là về tương lai, tương lai này, điều này sẽ hoạt động như thế nào đối với người dùng của tôi? Họ sẽ thích nó chứ? Và làm thế nào để tôi có thể thiết kế tốt nhất? Trọng tâm là khác nhau ở đây.

Thiết kế lấy người dùng làm trung tâm (UCD)

Veerle: Tại sao chúng ta cần một cái gì đó như UCD hoặc, thiết kế lấy người dùng làm trung tâm? Chà, vì nó về cơ bản giảm thiểu phỏng đoán bằng cách cung cấp cơ chế chống lại các quyết định thiết kế có thể được tìm thấy ở các độ tuổi mà điều này là do bạn liên tục đưa ra các thiết kế, bạn sẽ đưa nó trở lại người dùng của mình để người dùng của bạn có thể thực sự hiểu biết. Hoặc bạn có thể hiểu liệu người dùng của bạn có thích nó hay không. Vì vậy, cuối cùng, UCB cung cấp cho bạn một sản phẩm hữu ích và ý nghĩa hơn. Và đó là bởi vì bạn đã thực hiện tất cả thử nghiệm đó và nhận được phản hồi đó. Vì vậy, nó cũng giảm thiểu nơi bạn làm việc. Bởi vì nếu bạn biết người dùng của mình sẽ nghĩ gì về tính năng này, thì rõ ràng phản hồi của bạn sẽ hy vọng sẽ có kết quả, wow, điều này thật tuyệt. Điều đó giúp bạn tiết kiệm một số công việc. Nó cung cấp một cách để mang lại trải nghiệm chất lượng. Vì vậy, sau đó chúng tôi nói về sự nhanh nhẹn và thiết kế lấy người dùng làm trung tâm.

Có gì khác biệt? Nhanh nhẹn có thực sự lấy người dùng làm trung tâm không?

Veerle: Thành thật mà nói, chúng ta đang nói về toàn bộ cuộc thảo luận này giữa agile và UCD. Nhưng điều tôi muốn nói với bạn ngày hôm nay là nếu bạn nhìn vào hai triết lý mà bạn sẽ thấy trong nhanh, đó là tập trung vào việc nhanh chóng phát hành nội dung, đảm bảo rằng bạn làm hài lòng khách hàng và số dư vốn chủ sở hữu của UCD trong đó sẽ là như, được rồi, chúng tôi cần tạo hoặc suy nghĩ về người dùng cuối của chúng tôi.

Chúng tôi cần đảm bảo rằng họ có trải nghiệm tốt nhất có thể khi sử dụng sản phẩm của chúng tôi. Và tôi nghĩ nếu bạn có thể kết hợp cả hai, nếu bạn có thể kết hợp phương pháp trở nên linh hoạt, như nhanh chóng đưa ra phản hồi liên tục, hãy tập trung vào bản thân hữu hình. Và nếu bạn có thể kết hợp UCB với sự tập trung cao độ thì không sao, bất cứ thứ gì tôi thiết kế đều cần phải phù hợp với người dùng của tôi, vì họ sẽ sử dụng sản phẩm.

Tôi nghĩ nếu bạn hợp nhất cả hai, điều đó thật tuyệt. Và điều tôi cũng muốn đề cập là, điều tuyệt vời nhất với những triết lý này, bạn không cần phải xem chúng là cố định. Giống như nếu nhanh nhẹn quy định bạn thực hiện bước một, hai và ba, thì điều đó không nhất thiết có nghĩa là bạn cần phải làm theo chi tiết 100%.

Điều đó cũng tương tự đối với UCB. Bạn có thể làm theo tất cả các bước này một cách chi tiết và hoàn toàn tự tham gia vào phương pháp luận, nhưng nó không giúp ích được gì. Nó nhiều hơn về suy nghĩ đằng sau nó. Và điều duy nhất mà phát triển nhanh muốn có là đảm bảo rằng bạn gần gũi với người dùng của mình, gần với thực tế.

Veerle: Bằng cách có những chu kỳ ngắn này, tôi đã yêu cầu phản hồi và bạn chỉ cần lưu ý để có thể kết hợp cả hai. Vì vậy, đó là lý do tại sao tôi luôn nói rằng bạn có quy trình UCD nhanh nhẹn này mà bạn có thể làm theo. Và đây chỉ là quá trình. Và như tôi đã nói, đừng xem nó đã cố định 100%, nhưng đây là quá trình mà bạn có thể làm theo để thực sự nhận thức được bản thân.

Vì vậy, trước tiên bạn bắt đầu bằng cách thu thập các yêu cầu để bạn có một nhận thức rõ ràng. Đây có lẽ là những gì người dùng của tôi muốn. Đây là những gì chúng tôi tìm kiếm, các bên liên quan của tôi muốn, vì vậy đây là những gì chúng tôi cần làm. Bạn cần tìm cho mình một cách chuẩn hóa để ghi lại các yêu cầu một cách cơ bản để mọi người trong nhóm của bạn biết các yêu cầu để biết chúng trông như thế nào.

Sau đó, bạn luôn bắt đầu với việc thiết kế mọi thứ. Vì vậy, nếu bạn có một yêu cầu, luôn tốt để có hình ảnh đại diện cho yêu cầu đó là gì. Đó không cần phải là một wireframe hoàn chỉnh hoặc một tác phẩm hoàn chỉnh, thậm chí có thể là một bản phác thảo cụ thể nhỏ mà chúng tôi sẽ thực hiện. Miễn là bạn có bất cứ điều gì mà bạn có thể tìm kiếm, và điều này sẽ giúp bạn hướng dẫn bất cứ điều gì bạn đang hướng tới.

Veerle: Và ngay cả khi bạn có một bản phác thảo, bạn có thể trình bày điều đó cho người dùng của mình và nói, này, bạn nghĩ gì về điều đó? Bạn biết đấy, đặc biệt, nếu tôi có thể nói chuyện cho doanh nghiệp của mình, chúng tôi đã phát triển một phần mềm dành riêng cho bạn. Vì vậy, chúng tôi biết người dùng của mình khá rõ. Chúng tôi nói chuyện với họ hai tuần một lần, và sau đó rất dễ dàng.

Nếu bạn có một bản phác thảo, mặc dù đó là một bản phác thảo nhanh chóng để đưa cho họ xem và sau đó xem, này, bạn có thấy nó hoạt động không? Hay bạn thích điều này? Và sau đó khi bạn có thiết kế, bạn thực sự có thể bắt đầu đào sâu vào mã. Vì vậy, bạn thực sự có thể bắt đầu xây dựng và tôi luôn khuyên người lớn viết mã các phương pháp hay nhất và làm cho mã nhất quán trong nhóm của bạn.

Hãy đảm bảo rằng bạn thuộc bất kỳ nhóm nào mà bạn có như một bộ quy tắc tiêu chuẩn mà bạn phải tuân theo có thể là những thứ như quy ước đặt tên, kiểu mã và những thứ đó, nhưng chỉ cần đảm bảo rằng nó, điều đó không quan trọng nếu người A hoặc người B đã viết mã, nhưng bạn có một dòng mã.

Veerle: Tôi thấy một câu hỏi từ Jen.

Jen: Tôi đang giơ tay cho một trong những người tham dự của chúng tôi. Vì vậy, Hyung, em xin lỗi. Tôi xin lỗi nếu tôi phát âm sai tên của bạn, bạn có muốn giơ tay và sau đó tự hỏi Veerle không? Ai đó có thể bật tiếng anh ấy và xem, được không. Vì vậy, bạn có thể nghe thấy tôi bây giờ?

Người tham dự: Vâng. Vì vậy, tôi chỉ có một câu hỏi. Tôi không có ý làm gián đoạn vì bạn đang tiếp tục, nhưng tôi chỉ không muốn bỏ lỡ điểm này trong trường hợp cuối cùng, nếu cuối cùng tôi đã đi. Vì vậy, tôi chỉ muốn kiểm tra thiết kế tập trung vào người dùng của bạn, nó giống như một chu kỳ nhận được nhỏ hơn trong quá trình sử dụng phản hồi trước khi bạn thực hiện một chu kỳ hoàn chỉnh.

Đúng? Vậy bạn có lời khuyên nào cho một số lượng lớn người dùng cuối không? Thích 5 hay 30? Ý tôi là, đây là điều mà tôi cũng đang gặp khó khăn vì bản thân tôi là một nhà phát triển độc lập. Và tôi cũng thấy rằng bạn chỉ có một đội ba người, vì vậy việc tập hợp nhiều người là rất khó khăn về mặt hậu cần. Vậy bạn có lời khuyên nào tốt cho lượng người dùng cuối không?

Veerle: Vâng. Vì vậy, điều đó cũng phụ thuộc vào bối cảnh. Vì vậy, các ứng dụng của chúng tôi, chẳng hạn, có dưới 100 người dùng. Vì vậy, điều đó có nghĩa là chúng tôi sẽ không hỏi 100 người về phản hồi của họ. Giống như nếu bạn có hàng nghìn người dùng, 100 đó có thể là một con số hợp lý. Vì vậy, nó phụ thuộc vào mức độ lớn của ứng dụng của bạn, bao nhiêu vấn đề người dùng đã hỏi nếu bạn có thể.

Tôi muốn nhắm đến, tốt, ở đâu đó, 1-5% cơ sở người dùng của bạn. Và sau đó thì không, và bạn cũng nên cân nhắc cẩn thận về những tính năng nào bạn sẽ thực hiện một nghiên cứu toàn diện, bởi vì đôi khi chỉ cần thực hiện nghiên cứu hiện có là đủ. Ví dụ: nếu bạn cần suy nghĩ về màu sắc của các nút hoặc vị trí đặt các nút đóng và những thứ tương tự, bạn có thể dựa trên nghiên cứu hiện có, và nếu không, chỉ cần đánh vần, xem bạn cần phải cân bằng giữa, được không, tính năng này sẽ hoạt động. để trở nên thực sự lớn, thực sự quan trọng và thực sự cơ bản? Có lẽ tôi nên hỏi một mẫu lớn hơn về cơ sở người dùng của mình, nhưng tất cả thực sự phụ thuộc vào ngữ cảnh. Điều đó có trả lời câu hỏi của bạn một chút không?

Người tham dự: Ư, tôi cung nghi vậy. Tôi hỏi vì đối với tôi, tôi đang liên hệ với người dùng cuối bằng tiếp thị trực tiếp trên Instagram, bạn biết đấy, vì vậy đôi khi nó rất mệt mỏi và tốn thời gian, nhưng tôi đoán nó thực sự phụ thuộc. Cảm ơn về câu trả lời của bạn.

Veerle: Không có gì. Được chứ. Một bàn tay khác.

Người tham dự: Tôi xin lỗi, chỉ để theo dõi điều đó. Tôi biết tôi là một phần của Komen, nhưng bạn đã nói, bạn biết đấy, nó thực sự phụ thuộc vào tính năng và giống như 1-5%, về phương pháp luận, bạn có thường sử dụng không, giả sử như khảo sát hoặc làm bạn phân phối các cuộc khảo sát để thích 5% người trong số này? Tôi không biết, 10% từ đó thực hiện phỏng vấn người dùng và những thứ tương tự.

Veerle: Vâng. Vì vậy, chúng tôi thực sự rất may mắn với người dùng của mình vì người dùng của chúng tôi rất tham gia vào sản phẩm của chúng tôi. Chúng tôi phát triển các sản phẩm rất chuyên biệt, dành cho một số người có hạn. Vì vậy, chúng ta có thể thoải mái tham gia các cuộc họp với họ, trình bày những gì chúng ta có trong đầu và thu thập phản hồi của họ.

Và chúng tôi sẽ nhận được tất cả những phản hồi này từ họ, nhưng đó là điều xa xỉ mà chúng tôi có. Ví dụ: nếu bạn có một ứng dụng thực sự lớn với hàng nghìn người trên đó và sắp có sẵn trong cửa hàng ứng dụng, đó sẽ là một câu chuyện khác vì rất khó để thu thập phản hồi từ mọi người vào thời điểm đó.

Nhưng đối với những khán giả lớn hơn, tôi sẽ thực hiện một số việc như thử nghiệm A / B hoặc thiết lập các cuộc khảo sát. Nhưng điều đó, một lần nữa, thực sự phụ thuộc vào bối cảnh, những gì bạn có thể làm tốt nhất.

Veerle: Vậy chúng ta đã ở đâu? Vì vậy, tôi đã ở giai đoạn thử nghiệm. Nếu bạn đã phát triển tính năng của mình, thì rõ ràng bạn phải kiểm tra nó. Bởi vì bạn không thể đưa mọi thứ vào sản xuất và sau đó chỉ hy vọng điều tốt nhất bạn cần để kiểm tra nó. Bạn có thể sử dụng các bài kiểm tra đơn vị cho các nhà phát triển, nhưng cũng chỉ một số bài kiểm tra người dùng. Bạn có thể thu hút một số người dùng trên đó và thu thập một số phản hồi.

Sau đó, bạn có thể phát hành, nhưng hãy phát hành một cách khôn ngoan vì chu kỳ hai tuần này thực sự nhằm mục đích phát hành càng nhanh càng tốt, bạn biết đấy, làm càng nhanh càng tốt, chúng tôi muốn xem kết quả ngay bây giờ. Nhưng bạn cũng nên làm điều đó một cách khôn ngoan. Vì vậy, hãy đảm bảo rằng bất kỳ thứ gì bạn phát hành đều có chất lượng cao, bởi vì bạn chỉ có thể cung cấp một sản phẩm phần mềm lấy người dùng làm trung tâm, nếu bạn cũng phân phối một sản phẩm chất lượng cao. Vì vậy, hãy đảm bảo rằng bất cứ thứ gì bạn phát hành đều thực sự tập trung vào người dùng và cung cấp cho người dùng trải nghiệm tốt nhất có thể.

Và sau đó rõ ràng là rất quan trọng. Hãy dành thời gian để nhận được phản hồi. Những gì tôi thấy quá nhiều xảy ra trong các phương pháp luận nhanh nhẹn này là nói rằng, chúng ta có chu kỳ phát triển này. Chúng tôi phát hành một số tính năng. Bây giờ là vấn đề của tốc độ cho những ngày cuối tuần, nhưng hãy dành thời gian của bạn để thực sự nhận được phản hồi về các tính năng mà bạn vừa phát hành để bạn có thể cải thiện chúng hoặc kết hợp phản hồi này trong các chu kỳ phát triển sau này của bạn. Vì vậy, hãy dành thời gian cho điều đó.

Những thách thức với phát triển phần mềm

Veerle: Vì vậy, sau đó, một vài thách thức mà bạn gặp phải như phát triển phần mềm. Một trong số đó là một khái niệm rất được biết đến là nợ kỹ thuật. Nó còn được gọi là nợ thiết kế hoặc nợ mã. Nó là một khái niệm trong phát triển phần mềm phản ánh chi phí ngụ ý của chi phí làm lại bổ sung bằng cách chọn một giải pháp dễ dàng.

Bây giờ, thay vì một cách tiếp cận tốt hơn, nếu chúng ta thực hiện. Và đây thực sự là một rủi ro khi bạn đang phát triển nhanh. Bởi vì như tôi đã nói, phát triển nhanh thường nhằm mục đích giải phóng càng nhanh càng tốt. Làm điều đó càng nhanh càng tốt. Chúng tôi muốn thấy kết quả rõ ràng sau hai tuần đó, nhưng thường dẫn đến việc các nhà phát triển dễ dàng lựa chọn.

Cuối cùng thì bạn sẽ hối hận. Bởi vì nếu bạn đưa ra lựa chọn ngay bây giờ và xây dựng trên đó, thì bạn đang gánh ngày càng nhiều nợ. Và rất khó để đền đáp điều đó. Vì vậy, Ward Cunningham, anh ta là một trong những tác giả của bản tuyên ngôn nhanh nhẹn. Anh ấy đã từng nói rằng một số vấn đề với mã giống như nợ tài chính, vì vậy bạn có thể vay ngược lại trong tương lai miễn là bạn trả hết. Ward sử dụng thuật ngữ này như một phép ẩn dụ và anh ấy gọi nó là món nợ kỹ thuật và đã đạt được động lực kể từ khi tôi nghĩ rằng mọi nhà phát triển phần mềm đều biết về khái niệm này, và nó vẫn là một vấn đề thực sự trong thế giới ngày nay bởi vì chúng ta luôn thấy nó.

Veerle: Vì vậy, những gì thực sự gây ra nợ kỹ thuật này. Chà, một trong số đó là về định nghĩa và yêu cầu, thời hạn quá chặt chẽ, quá nhiều áp lực. Như tôi đã nói, nếu mọi thứ được nhắm mục tiêu và thực hiện càng nhanh càng tốt, bạn có thể tìm được các giải pháp dễ dàng hơn. Và nó cũng đánh giá thấp thời gian cần thiết để hoàn thành một nhiệm vụ.

Bởi vì nếu bạn, đặc biệt là, nếu bạn làm việc trong những chu kỳ nhanh này từ trước, bạn lên kế hoạch như thế, nhiệm vụ này sẽ khiến tôi mất nhiều giờ như thế này. Và những gì đang xảy ra là chúng ta đánh giá thấp thời gian. Và cuối cùng, có một số khủng hoảng hoặc một số căng thẳng để thực sự đạt được thời hạn mà chúng tôi chọn cho giải pháp dễ dàng.

Đó cũng là sự thiếu kiến ​​thức và thiếu bài kiểm tra. Vì vậy, thực sự là gì, nếu bạn tóm tắt tất cả những điều này, nguyên nhân của các khoản nợ kỹ thuật là do quá trình phát triển phần mềm. Nếu bạn đảm bảo rằng bạn có một quy trình phát triển phần mềm vững chắc, nếu bạn tính đến tất cả những điều này, thì bạn có thể giảm thiểu số nợ kỹ thuật.

Nợ kỹ thuật, chúng ta đều đã thấy. Và bạn chỉ mất nhiều thời gian hơn để xây dựng các tính năng trên sản phẩm của mình. Nó nguy hiểm và có hại cho sản phẩm của bạn và bạn cần phải ngăn chặn nó. Và với tư cách là một nhà phát triển, bạn cũng đóng một vai trò trong việc này. Bạn có vai trò giáo dục những người còn lại trong nhóm của mình và bạn cũng có vai trò nhận ra rủi ro nợ kỹ thuật.

Kinh nghiệm diễn giả và mẹo

Veerle: Vì vậy, là một nhà phát triển, nếu bạn đang làm việc trong một nhóm, hãy lưu ý. Đó là khi bạn đang đưa ra một lựa chọn, hãy tự mình suy nghĩ xem, đây có phải là lựa chọn dễ dàng bởi vì tôi muốn cung cấp cái này nhanh nhất có thể? Hay nó là sự lựa chọn tốt nhất? Bởi vì, một lần nữa, các khoản nợ kỹ thuật, người dùng của bạn sẽ thấy điều đó bởi vì nếu người dùng của bạn đang mong đợi trải nghiệm 'tuyệt vời' đối với ứng dụng của bạn, nhưng bạn phải mất hàng tháng trời để xây dựng như nút bổ sung này, bởi vì bạn đã chọn một khuôn khổ không phù hợp với nó, thì người dùng của bạn sẽ không được hưởng lợi từ nó.

Sau đó, một thách thức khác mà chúng tôi thường gặp phải khi chúng tôi phát triển phần mềm nhanh là, được rồi, điều đó thật tuyệt. Và tất cả cách tiếp cận lấy người dùng làm trung tâm này và làm những gì người dùng muốn, nhưng tiếc là người dùng không phải lúc nào cũng biết họ thực sự cần gì vì có, người dùng muốn gì so với người dùng cần?

Veerle: Vì vậy, một người dùng có thể nói, "ồ, tôi muốn X", nhưng người dùng có thể không cần X, nhưng thực sự là Y. Vì vậy, hãy tưởng tượng như một vài năm trước, nếu bạn không biết rằng bạn cần một chiếc iPhone, nhưng bây giờ chúng ta , bạn biết đấy, đó chính xác là cách nó hoạt động. Chúng tôi không biết mình cần gì và nếu bạn đang xây dựng phần mềm, đúng vậy, công việc của bạn về cơ bản là tìm ra nó.

Bạn cần cố gắng tìm ra những gì người dùng hoặc bên liên quan thực sự cần thay vì chỉ giao các mặt hàng trên đường đi, vì điều đó rất dễ dàng, đặc biệt là các bên liên quan kinh doanh có thể không giống như người dùng thực tế của sản phẩm có thể nói, bạn nhé. , cho tôi tính năng này và tính năng kia và tính năng đó.

Và sau đó chúng tôi đang có một sản phẩm tốt. Nhưng hãy luôn cố gắng để trở thành nhà tư tưởng phản biện và cũng hỏi rằng điều này có thực sự là điều tốt nhất cho người dùng của chúng tôi hay không. Và một lần nữa, điều này quay lại, nếu bạn muốn xây dựng phương pháp tiếp cận lấy người dùng làm trung tâm, bạn cần hiểu người dùng của mình và làm thế nào bạn có thể làm điều đó trong khi bạn cũng có thể đặt câu hỏi. Vì vậy, câu hỏi của câu hỏi của riêng bạn thực sự.

Veerle: Được chứ. Vì vậy, bạn muốn cái này, nút này trong tập của bạn. Tại sao, tại sao bạn cần nó ở đó và nó sẽ giúp bạn như thế nào trong cuộc sống hàng ngày? Thay vì thích, nếu bạn đang thiết kế một ứng dụng để mua hàng tạp hóa trực tuyến, bạn có thể nói như, Tại sao bạn mua hàng tạp hóa trực tuyến, nhưng bạn cũng có thể hỏi những câu hỏi khác, chẳng hạn như, được rồi, bạn làm gì khi mua hàng tạp hóa trực tuyến?

Bạn làm gì trước khi mua sắm trực tuyến? Bạn làm gì sau khi bạn đi mua sắm? Điều gì không hiệu quả với bạn khi bạn mua hàng tạp hóa hoặc bạn ở cùng với ai khi bạn mua hàng tạp hóa theo hàng? Bạn tham khảo ý kiến ​​tư vấn của ai? Giống như bạn có thể hỏi tất cả các loại câu hỏi xung quanh đó để thực sự hiểu đây có lẽ là những gì người dùng của tôi cần. Thay vì chỉ xây dựng một ứng dụng để họ có thể mua hàng tạp hóa.

Sau đó, một thách thức khác rõ ràng là lựa chọn khung công tác phù hợp bởi vì nếu bạn bắt đầu vào một dự án phát triển phần mềm lớn, thì trong giai đoạn đầu, bạn cần phải lựa chọn khung công tác nào và khung công tác nào ở đây.

Ý tôi là, bạn sẽ chọn Vue hay bạn sẽ chọn React? Bạn đang tìm kiếm một ứng dụng Shiny? Có rất nhiều khuôn khổ mà bạn có thể chọn. Vì vậy, những gì bạn thực sự nên chọn? Bởi vì điều này cuối cùng cũng sẽ xác định khoản nợ kỹ thuật của bạn. Bởi vì nếu bạn mắc sai lầm ngay từ đầu trong việc chọn khung, bạn có thể vì đó là khung dễ nhất hoặc đó là khung mà bạn có nhiều kiến ​​thức nhất. Bạn có thể kết thúc với việc xây dựng một cái gì đó không phù hợp với bạn. Vì vậy, những điều bạn có thể muốn xem xét và điều quan trọng nhất trong việc lấy người dùng làm trung tâm, phát triển phần mềm, người dùng của bạn. Trước tiên, hãy nghĩ đến việc người dùng của bạn sẽ sử dụng sản phẩm như thế nào, họ sẽ mở nó trên PC của họ như thế nào? Làm thế nào để họ xem nó trên điện thoại di động? Và tùy theo đó mà chọn framework phù hợp nhất với nhu cầu.

Veerle: Ví dụ: chúng tôi đã phát triển Cổng thông tin dược phẩm của mình, về cơ bản là một cổng thông tin với tất cả mọi thứ. Các ứng dụng nhỏ hơn. Đó là bởi vì mô hình hoặc mô hình định giá của chúng tôi sẽ cho biết, được rồi, người dùng hoặc khách hàng có thể chọn như các mô-đun khác nhau. Vì vậy, họ có thể đi từ mô-đun A, B và C, hoặc họ có thể chỉ đến mô-đun A hoặc chỉ C. Vì vậy, chúng tôi nghĩ, làm thế nào chúng ta có thể tốt nhất, khung công tác nào chúng ta có thể chọn tốt nhất để làm điều đó? Cuối cùng, chúng tôi đã chọn micro và cấu trúc. Và với cấu trúc micrô này, chúng tôi có giống như tất cả các ứng dụng độc lập này, về cơ bản là các mô-đun của chúng tôi.

Và sau đó, chúng giống như các ứng dụng nhỏ độc lập. Vì vậy, để nói, và nó giúp người dùng của chúng tôi về cơ bản chọn một gói về cơ bản, trong đó có thể nói rằng, tôi chỉ muốn thích phần này và phần đó và phần đó và tôi muốn có quyền truy cập vào nó. Và đó là lý do tại sao chúng tôi đưa ra quyết định, vì lợi ích của người dùng.

Cấu trúc, nhưng đối với bạn, nó có thể trông hoàn toàn khác bởi vì tất cả phụ thuộc vào ngữ cảnh của bạn và người dùng của bạn. Vì vậy, ngoài người dùng của bạn, bạn có thể muốn xem rõ ràng là cộng đồng phát triển. Có rất nhiều lời bàn tán về khuôn khổ mà bạn đang chọn? Có đủ người hoạt động không? Nếu tôi không biết bất cứ điều gì, tôi muốn duyệt tràn ngăn xếp.

Veerle: Tôi thực sự có thể tìm thấy thứ gì đó trên ngăn xếp tràn không? Và nó thực sự quan trọng hơn sự hỗ trợ từ các nhà phát triển khung công tác hoặc từ các nhà phát triển khác, rõ ràng là những thứ như là có đủ tài liệu kỹ thuật, được duy trì hay không. Nó có dễ hiểu không? Nó có bền vững không? Và rõ ràng bạn cần phải nhìn vào đội của mình.

Bạn có thể muốn xây dựng một ứng dụng và phản ứng, nhưng họ không ai trong nhóm của bạn biết về các khoản nợ. Sau đó, đó cũng là một sự lựa chọn vững chắc cho bạn, phải không? Vì vậy, tất cả đều là sự cân bằng giữa khi không thích. Và tình trạng hiện tại của khuôn khổ nghệ thuật trong cộng đồng nhà phát triển ngày nay so với những gì người dùng của tôi muốn và những gì phù hợp nhất với họ so với những gì tôi có thể làm cho mỗi người?

Tôi có kỹ năng đặt tên tài nguyên không?

Vâng. Sau đó, tôi đến với học hỏi của chúng tôi bởi vì có công ty riêng của bạn, bạn học được rất nhiều. Tôi có thể nói với bạn điều đó. Chúng tôi đã học được rất nhiều điều từ việc phát triển phần mềm. Chúng tôi đã học được rất nhiều điều từ việc mắc sai lầm. Chúng tôi vẫn đang học hỏi rất nhiều và tôi muốn chỉ chia sẻ những điều đã học được với bạn và kinh nghiệm của chính chúng tôi, vì vậy bạn cũng có thể hưởng lợi từ điều đó.

Veerle: Câu hỏi đầu tiên là, được rồi, chúng tôi là một đội nhỏ. Vâng, chúng tôi là một đội nhỏ. Vậy chúng ta có thể phát triển nhanh được không? Và có, bạn có thể. Ý tôi là, Trở thành một nhóm gồm 10 hoặc 50 người để thực hiện như một phương pháp luận nhanh nhẹn hoặc một cách suy nghĩ linh hoạt, bạn có thể ở bất kỳ quy mô nào. Và như tôi đã nói trước đó, bạn có thể điều chỉnh phương pháp luận và quy trình của mình cho phù hợp với môi trường cụ thể của bạn bởi vì bối cảnh rất quan trọng, bạn biết đấy, đối với chúng tôi trong công ty của chúng tôi, một công ty khởi nghiệp với một nhóm tương đối nhỏ người, mọi thứ và giải pháp có thể trông khác so với thành lập công ty đã có 25 năm và có nhiều nhóm phát triển.

Vì vậy, bối cảnh thực sự quan trọng. Khi bạn đang triển khai bất kỳ thứ gì, thực sự là bất kỳ quy trình phát triển phần mềm nào mà bạn đang chọn, nhưng bạn có thể làm được. Thành thật mà nói, tôi thích làm điều đó ngay cả trong một môi trường nhỏ như vậy, bởi vì nó chỉ giúp bạn tập trung giống như các chu kỳ nhỏ liên tục phát hành và nó giúp bạn thực sự nhanh chóng thấy được kết quả hữu hình.

Đó là lý do tại sao tôi thích nó rất nhiều. Chúng tôi làm mọi thứ như trong những chu kỳ nhỏ, nhưng đó rõ ràng không phải là cách chúng tôi bắt đầu ngay lập tức. Vì vậy, giả sử rằng bạn chỉ mới bắt đầu dự án lớn này cho một khách hàng hoặc bạn đang xây dựng một nỗ lực mới từ đầu. Rõ ràng là bạn không nhảy vào những chu kỳ nước rút ngắn như chúng ta gọi chúng ngay lập tức.

Veerle: Những gì chúng tôi thường làm là chúng tôi bắt đầu với nhiều cuộc họp khởi động. Vì vậy, đó là, chúng tôi chỉ có các cuộc họp động não về, được rồi, ứng dụng sẽ làm gì? Nó sẽ trông như thế nào? Chúng tôi cũng có các cuộc họp về, được rồi, kế hoạch dài hạn là gì? Bởi vì kế hoạch hai tuần sẽ không cắt giảm nó mỗi khi bạn cần đi.

Bạn cần phải biết rằng. Trong rất nhiều tháng nữa, tôi sẽ phát hành sản phẩm này. Hoặc trong nhiều tháng nữa, tôi sẽ tiếp thị sản phẩm này và chúng tôi có các cuộc họp khởi động mà không có các bên liên quan của chúng tôi. Vì vậy, đó chỉ là nhóm cốt lõi của chúng tôi. Chúng tôi nói về dự án mới, nhưng cũng với các bên liên quan để cùng động não với họ.

Sau đó, chúng tôi có, giống như, thông thường những gì chúng tôi làm giống như thiết kế lớn này. Vì vậy, chúng tôi bắt đầu với các bản phác thảo và sau đó chúng tôi có một nhà thiết kế UX thỉnh thoảng giúp chúng tôi và chúng tôi để anh ấy biến nó thành wireframe và chúng tôi đã có một thiết kế rộng rãi. Thông thường, chúng tôi cũng đưa thiết kế này cho khách hàng của mình, “Này, chúng tôi đã thiết kế cái này. Vì vậy, bạn giống như, đây là những gì bạn làm khác biệt. " Vì vậy, điều đó rất có giá trị khi có được điều đó và hãy đảm bảo rằng bạn giữ nguyên các thiết kế trong đó, bởi vì nếu bạn đang thu thập phản hồi trong quá trình thực hiện và nếu bạn đang đưa thiết kế của mình tới người dùng và nếu họ nói, à, không, tôi , Tôi không biết điều đó sẽ hoạt động như thế nào hay bất cứ điều gì, đặc biệt là.

Veerle: Nếu bạn có một sản phẩm chuyên dụng. Ý tôi là, chúng tôi sản xuất sản phẩm cho các công ty dược phẩm có nhu cầu rất cụ thể và công ty dược phẩm không phải là công ty khác. Vì vậy, đối với chúng tôi, điều rất quan trọng là giữ cho các thiết kế luôn năng động và thay đổi chúng khi chúng tôi tiếp tục. Và rõ ràng trước khi bắt đầu, bạn nên quyết định khuôn khổ của mình và đừng làm điều đó.

Giống như qua đêm, họ sẽ làm điều đó trong một cuộc họp kéo dài một giờ. Hãy suy nghĩ về nó. Xem nếu nó có ý nghĩa. Đảm bảo rằng bạn không phải gánh một khoản nợ kỹ thuật khổng lồ vì bạn đã đưa ra quyết định sai lầm và cũng luôn ghi nhớ người dùng của bạn, mục tiêu là sản phẩm. Và rõ ràng nó giống như sự cân bằng mong manh giữa thời gian mà bạn có các kỹ năng mà bạn có trong nhóm của mình, ngân sách mà bạn đã nói, à, đó là tất cả vấn đề khi đưa ra lựa chọn khuôn khổ này.

Vì vậy, tôi nghĩ rằng chúng tôi đã làm như vậy. Quá trình tiền xử lý chung như thế nào, và chúng tôi biết về các hóa đơn, chúng tôi biết mình sẽ sử dụng khuôn khổ nào. Chúng tôi biết rằng sẽ có vẻ như các bên liên quan hài lòng với ý tưởng này. Mọi người đều thích, tôi rất hào hứng khi bắt đầu. Sau đó, chúng tôi bắt đầu các chu kỳ nước rút của mình. Vì vậy, về cơ bản chúng tôi đã làm theo.

Veerle: Phần nào đó, các bước mà tôi đã đề cập trước đó, chúng ta nhận được một yêu cầu trên bảng có thể là bất kỳ loại bảng nào. Nó chỉ là quá trình suy nghĩ có thể giống như bảng git hoặc bảng dự án. Chúng tôi sử dụng ghi chú cho nó, nhưng bạn cũng thích JIRA hoặc bất kỳ loại phần mềm nào khác. Sau đó, chúng tôi, đặc biệt là đối với các tính năng nhỏ hơn, bởi vì nếu bạn có thể có một cái gì đó như thiết kế chung cho ứng dụng lớn của mình, bạn sẽ thấy điều đó bất cứ khi nào bạn thực hiện các tiện ích bổ sung nhỏ hoặc dựa trên phản hồi, bạn có thể nghĩ đến các tính năng khác mà bạn muốn để triển khai trong ứng dụng của bạn.

Đôi khi bạn đi đến những thiết kế cần thiết. Tất cả chúng ta đều học nhà thiết kế UX sáng tạo để làm điều gì đó cho chúng ta hoặc chúng ta tạo ra các bản phác thảo nhanh chóng, nhưng hãy đảm bảo rằng bạn có bất kỳ yêu cầu nào mà bạn có, như sự hiểu biết rõ ràng về điều này, được rồi, đây là những gì nó trông như thế này. Sau đó, chúng tôi thực sự phát triển, đó là một phần thú vị. Và sau đó, những gì chúng tôi làm để đảm bảo rằng chúng tôi trong toàn bộ nhóm của chúng tôi có giống như một cách chuẩn hóa để viết mã và gửi các dự án của chúng tôi. Chúng tôi cũng đã cố gắng tiêu chuẩn hóa việc sử dụng các thư viện và gói, vì người A có thể thích một thư viện cụ thể và người B và những người khác, nhưng điều đó thật tuyệt. Nếu bạn có thể đi đến một điểm chung, bạn biết đấy, không phải lúc nào mã cũng có vẻ hoàn toàn khác nhau.

Và sau đó chúng tôi cũng thực hiện một số thử nghiệm, hiển nhiên. Vì vậy, chúng tôi kiểm tra các chức năng. Chúng tôi xem nó có tích hợp một tính năng mới không, không phá vỡ bất cứ điều gì khác. Nếu các yêu cầu được đáp ứng, rõ ràng là sau đó chúng tôi phát hành, rõ ràng là khi các nhiệm vụ rơi vào chúng tôi sẽ phát hành cho phiên bản sản xuất. Và đôi khi trước khi thực sự phát hành, chúng tôi sẽ đặt nó lại.

Veerle: Nhận một số phản hồi từ người dùng của chúng tôi trước khi chúng tôi thực sự phát hành, bởi vì đôi khi một tính năng dành riêng cho một khách hàng hoặc người dùng cụ thể như chúng tôi thực sự nói với họ. Được chứ. Bạn có hài lòng với điều đó không? Vì vậy, nếu bạn cần thay đổi trước khi chúng tôi thực sự phát hành, thì chúng tôi có thể thay đổi phản hồi và giai đoạn phát hành một chút.

Vì vậy, một lần nữa, điều đó phụ thuộc vào tình huống của bạn và vâng. Và vì vậy khi nó được phát hành, chúng tôi nhận được phản hồi, về cơ bản, tất cả đều xung quanh. Vì vậy, hàng ngày chúng tôi nhận được phản hồi về ứng dụng của mình. Chúng tôi cũng hoan nghênh phản hồi từ người dùng của chúng tôi, rõ ràng. Nếu họ nói bất kỳ ý tưởng hoặc lỗi tính năng mới nào, chúng tôi sẽ sửa chúng trong chu kỳ tiếp theo.

Có một chút vòng lặp nhanh trong quy trình của chúng tôi. Và sau đó là một số bài học. Tôi muốn chia sẻ nó với bạn. Tôi có khá nhiều vì chúng tôi đã học được rất nhiều. Cách học số một của tôi là đừng mắc kẹt trong khuôn khổ hoặc quy trình cụ thể này. Bạn không tuân theo phương pháp nhanh hay phương pháp UCD, như từng bước 100%, nó không phải là đen trắng.

Veerle: Được chứ. Bạn cần phải làm những gì hiệu quả cho nhóm của bạn. Ví dụ: thông thường khi bạn đang làm việc nhanh với các nhiệm vụ nhỏ hơn, bạn có thể có rất nhiều nhiệm vụ trên đĩa của mình. Vì vậy, bạn có thể cho rằng một thành viên trong nhóm có 10 nhiệm vụ phải hoàn thành trong chu kỳ hai tuần. Nhưng thực sự thì chúng tôi không thích điều đó trong nhóm của mình cho lắm, chúng tôi thích có một bộ phim sử thi lớn hơn, về cơ bản chúng tôi gọi nó là một chủ đề lớn, nơi chúng tôi làm việc sau đó.

Vì vậy, chúng tôi gọi nó là một sử thi và về cơ bản đó là một nhiệm vụ rất lớn, chúng tôi tập hợp tất cả các nhiệm vụ liên quan vào. Vì vậy, nó chỉ giúp chúng tôi thoải mái hơn khi làm việc. Vì vậy, bất cứ điều gì bạn làm, bất kỳ quy trình nào bạn chọn, hãy làm những gì phù hợp với bạn thì cũng đừng mắc sai lầm. Và đừng nói, tôi biết nó sẽ kết thúc với các khoản nợ kỹ thuật. Tôi đã bảo hiểm chắc chắn. Tôi không biết bất kỳ dự án tự nào mà không có bất kỳ mức độ chuyên sâu về kỹ thuật nào. Bạn sẽ luôn có một chút bởi vì những lựa chọn bạn đưa ra lúc đầu sẽ đến, bạn biết đấy, chúng là những lựa chọn bạn đưa ra sẽ quyết định những lựa chọn trong tương lai bạn có thể thực hiện. Điều này sẽ luôn xảy ra, nhưng bạn có thể hạn chế điều này và cố gắng điều chỉnh nó, nhưng hãy luôn lưu ý rằng điều này sẽ xảy ra.

Sau đó, bất kỳ quy trình nào bạn chọn, có thể bạn phát minh ra quy trình của riêng bạn vì bạn, nó phù hợp với bạn. Tôi không quan tâm. Bạn cần trao đổi rõ ràng với các bên liên quan của mình. Bạn cần đảm bảo rằng các bên liên quan của bạn biết bạn đang làm gì và quy trình của bạn trông như thế nào, bởi vì điều đó ngăn chặn sự thất vọng trên trang web của họ.

Veerle: Vậy thì tôi đang hướng đến sự bảo vệ. Tôi nghĩ rằng rất nhiều người có xu hướng làm mọi thứ hoàn hảo. Họ sẽ không đi, mà là một động lực để làm điều đó. Đó là một bước nhỏ. Vì vậy, nếu bạn đang phát triển phần mềm, hãy cố gắng làm điều đó như tôi không biết, trước tiên hãy đảm bảo rằng chức năng ở đó. Và sau này, bạn có thể tối ưu hóa chức năng bổ sung. Ví dụ: nếu bạn muốn tạo một tính năng, trong đó bạn có thể thêm danh sách mua sắm hoặc thứ gì đó, trước tiên hãy đảm bảo rằng chức năng đó ở đó để thêm danh sách và thêm ít danh sách. Và sau đó, có thể tiếp theo, bạn có thể tập trung vào việc thực sự thay đổi biểu tượng hoặc màu sắc hoặc tắt danh sách, bạn biết đấy, chẳng hạn như thực hiện những thay đổi được cá nhân hóa hơn này.

Vì vậy, tập trung vào việc nhanh chóng phát hành ít nhất một thứ gì đó để bạn có thể nhận được phản hồi và sau đó bạn có thể hoàn thiện cách thức, bởi vì nếu bạn đang hướng đến sự hoàn hảo ngay lập tức, bạn có thể phát triển thứ gì đó mà người dùng của bạn thực sự không muốn, bạn biết đấy và như tôi đã nói trước đó, thay vì tập trung vào các yêu cầu của các bên liên quan và chỉ thực hiện danh sách mong muốn, hãy tập trung vào động lực trong dòng, bởi vì cuối cùng các bên liên quan, tôi sẽ yêu cầu bạn phát triển bản thân cho sản phẩm.

Họ yêu cầu bạn phát triển thứ gì đó vì bạn có chuyên môn trong việc phát triển phần mềm. Vì vậy, họ nói rằng họ muốn A, B và C trong danh sách của họ, không có nghĩa là họ biết rõ nhất. Điều đó không có nghĩa là ABC thực sự là điều tốt nhất. Vì vậy, tôi luôn cố gắng lấy động lực cơ bản đó để bạn thực sự có thể giúp họ sản xuất hoặc giúp sản phẩm trở thành một sản phẩm tốt hơn.

Veerle: Sau đó, một điều khác: đừng đánh giá thấp nghiên cứu của chúng tôi. Nhưng cũng đừng đánh giá thấp những nghiên cứu hiện có, mạnh mẽ. Bạn không cần phải phát minh lại bánh xe. Rất nhiều nghiên cứu về trải nghiệm người dùng đã được thực hiện về cách bạn có thể làm mọi việc một cách tốt nhất. Bạn cũng có thể nghĩ, nhìn, bạn tự nghiên cứu, các ứng dụng tương tự. Nhìn vào họ, xem họ làm mọi thứ như thế nào.

Họ không nhất thiết phải làm mọi thứ từ đầu. Sau đó, tôi nghĩ rằng với mọi dự án, dự án phụ nhỏ hay lớn hoặc dự án cho một công ty hoặc làm việc để lập kế hoạch là điều quan trọng. Nếu bạn chỉ đi vòng quanh, như tôi sẽ nói, và chỉ cần xây dựng các tính năng ở đây và ở đó, và cứ làm như bạn, làm ơn. Và điều này sẽ không cung cấp cho bạn mặc định.

Phân phối hoặc phần mềm lấy người dùng làm trung tâm. Và sau đó, nếu bạn đang chọn quy trình phát triển phần mềm nhanh nhẹn này mà chúng ta có, giống như những chu kỳ ngắn này, những lần lặp lại này không bị mắc kẹt trong tầm nhìn hai tuần này, bởi vì đôi khi bạn đang làm việc trong một dự án nhanh nhẹn, nếu tôi nhóm, hai tuần, đó là thời gian dành cho bạn đã có hai tuần là tất cả mọi thứ ở đó.

Và sau đó tất cả bắt đầu lại. Nhưng đừng quên đi bức tranh toàn cảnh, lớn hơn, hãy luôn biết bạn đang hướng tới điều gì và đó giống như cách tự đại diện tốt nhất có thể cho người dùng của bạn. Vì vậy, đừng quên điều đó. Và sau đó, nếu bạn muốn ngăn những thứ như nợ kỹ thuật và nếu bạn muốn ngăn việc đưa ra quyết định quá nhanh, vì lợi ích của thời gian, hãy đảm bảo rằng nếu bạn đang ước tính thiết kế cho một tính năng hoặc chức năng mà bạn kết hợp thêm.

Veerle: Vì vậy, nếu bạn nói, được rồi, cả hai điều này sẽ khiến tôi mất 10 giờ để hoàn thành nó. Tôi không biết nó là 50% hay gì đó, có thể là 15, bởi vì, bạn đang đánh giá thấp. Và chúng tôi đã học được rằng luật pháp chúng tôi vẫn làm, chúng tôi vẫn đánh giá thấp, mọi thứ sẽ mất thời gian. Tuy nhiên, như tôi đã nói, hãy luôn thiết kế các tính năng của bạn.

Ngay cả khi đó chỉ là một vết xước nhanh, bạn không cần phải làm khung dây hoàn chỉnh hoặc bất cứ điều gì bạn không cần, đặc biệt là một nhà thiết kế UX để làm những việc này, ngay cả khi bạn đang tự phát triển một dự án của riêng bạn, hãy đảm bảo rằng bạn thực hiện một bản phác thảo nhanh chóng để bạn biết những gì bạn đang làm.

Thúc

Sau đó, kết thúc nhanh chóng, nhưng tôi đã nói với bạn hôm nay trước khi chúng ta đi vào câu hỏi. Tôi nghĩ rằng điều chính mà bạn có thể có từ bản trình bày này là không nhảy thẳng vào mã. Bạn biết đấy, hãy suy nghĩ, lập kế hoạch, nhận yêu cầu trước khi bắt đầu thực sự bắt đầu viết mã. Và tất cả chúng tôi đều thích làm điều đó với tư cách là nhà phát triển.

Tôi biết, nhưng họ đã lùi lại và tập trung vào những gì có thể tốt nhất cho bạn ở đây. Và dự án đó nhỏ hay lớn không quan trọng. Tất cả chúng ta đều cần một quá trình. Tất cả chúng ta đều cần thiết kế và chúng ta đều cần lấy người dùng làm trung tâm. Nếu chúng ta thực sự muốn phần mềm của chúng ta thành công. Và sau đó xây dựng bản thân đúng đắn, là một nỗ lực của cả nhóm, bạn biết không?

Veerle: Đừng quá cô lập với tư cách là một nhà phát triển. Tôi đã nghe mọi người nói những điều như, vâng, tôi là một nhà phát triển. Tôi không cần biết bất cứ điều gì về. Ồ, tôi là một nhà phát triển. Tôi không cần biết bất cứ điều gì, tôi không biết, mọi thứ hoạt động như thế nào, giao diện người dùng trông như thế nào giống như tôi chỉ viết mã. Nhưng tôi nghĩ rằng bạn chỉ có thể xây dựng phần mềm sai lệch nếu bạn hiểu được bạn đang xây dựng chính nó, nơi đặt tên cho người dùng của bạn và nếu bạn hiểu toàn bộ quy trình và nếu bạn làm điều đó với tư cách một nhóm, chẳng hạn như các nhóm ở đó là có lý do , chủ đề ở đó, anh ấy đi, chúng hoạt động tốt.

Và bởi vì các cá nhân trong nhóm, hãy chắc chắn rằng sẽ có nhiều thất bại hơn từ từng thành viên trong nhóm. Đó là lý do tại sao các đội ở đó. Vì vậy, xin vui lòng, ngay cả với tư cách là nhà phát triển, hãy xây dựng một phần mềm như một nỗ lực của cả nhóm và không chỉ tập trung vào huấn luyện viên của bạn, hãy cố gắng hiểu người dùng của bạn. Và nó thực sự sẽ giúp ích.

Veerle: Và sau đó nó đúng. Giống như, làm điều đó một lần nữa. Nhận phản hồi. Xem những gì bạn có thể cải thiện vì phần mềm không bao giờ hoàn thiện. Bạn có thể có định nghĩa về kết thúc. Bạn có thể có một định nghĩa về hoàn thành. Bạn có thể có định nghĩa về bản phát hành đầu tiên, nhưng phần mềm chưa bao giờ hoàn thiện. Luôn có những thứ cần cải thiện.

Vì vậy, nếu bạn lặp đi lặp lại điều đó, bạn sẽ thực sự ngày càng tốt hơn ở mỗi bước. Và đó là kết thúc chính của tôi. Có câu hỏi gì nữa không? Tôi nghĩ rằng có rất nhiều điều xảy ra trong các cuộc trò chuyện, mà tôi chưa đọc, nhưng tôi sẽ kéo lên. Vì vậy, hãy để tôi xem những gì chúng tôi có.

Q & A

Host: Vì vậy, tôi tin rằng câu hỏi đầu tiên là từ Wayne. Wayne, bạn có muốn tự bật tiếng và tự đặt câu hỏi không?

Wayne: Xin chào, mọi người thế nào? Cảm ơn rât nhiêu. Trước hết, đó là một bản trình bày thực sự, thực sự tốt. Chỉ là một câu hỏi nhanh, thực sự. Tôi bị hấp dẫn bởi cách tiếp cận theo từng giai đoạn mà bạn có mà bạn đã trình bày trong một trong những trang trình bày trước đó của mình xung quanh giai đoạn thiết kế. Và tôi tò mò muốn biết, làm thế nào để bạn kiểm tra điều đó?

Giai đoạn thử nghiệm bạn đang thực hiện giống như những thử nghiệm nhỏ? Bạn đang sử dụng các thiết kế? Bạn có QA về vấn đề đó không và bạn xây dựng điều đó vào AC của mình như thế nào?

Veerle: Vì vậy, như tôi đã nói, chúng tôi là một đội rất nhỏ, vì vậy chúng tôi không có một đội toàn diện. Chúng tôi kiểm tra thiết kế bằng cách đến gặp khách hàng của chúng tôi, điều mà chúng tôi may mắn làm được.

Họ cũng là người dùng của chúng tôi. Chúng tôi đủ may mắn để có được những người dùng tận tâm như vậy giúp chúng tôi xây dựng sản phẩm của mình. Vì vậy, chúng tôi đến với họ và tất cả bắt nguồn như thế này là thiết kế. Bạn có thích nó không? Bạn có muốn xem bất kỳ thay đổi nào, v.v. không? Nếu bạn đang làm việc cho một lượng khán giả lớn hơn, tôi chắc chắn sẽ làm điều gì đó với thử nghiệm AB.

Vì vậy, nếu bạn muốn tìm hiểu nhanh, nếu thiết kế của bạn phù hợp với một nhóm người nhất định, hãy chỉ tập hợp con, về cơ bản là đối tượng lớn của bạn vào một thanh nhỏ hơn, sau đó hiển thị cho họ một phiên bản của ứng dụng hoặc phiên bản khác của ứng dụng và làm một số thử nghiệm về điều đó. Và hiển nhiên, vì việc kiểm tra thiết kế của bạn cần có thời gian. Bạn nên thực hiện chu trình đó trước khi bạn thực sự phát triển. Vì vậy, các yêu cầu thiết kế luôn chu kỳ dài trước khi bạn thực sự phát triển chu kỳ. Bởi vì nếu sự phát triển của bạn, nếu bạn đang phát triển, bạn cần biết điều này là, điều này sẽ là tám. Đó là những gì tôi sẽ nói. Câu trả lời đó có đáp ứng được câu hỏi của bạn không?

Người tham dự: Vâng. Ừ, không, không sao đâu. Tốt rồi. Tôi biết không có câu trả lời rõ ràng nào cho điều này đôi khi tôi nghĩ bạn hoàn toàn đúng. Bạn đang xác nhận chắc chắn với cơ sở người dùng và khi bạn thực hiện lặp lại, bạn sẽ nhận được phản hồi. Vâng, cảm ơn bạn rất nhiều. Cảm ơn bạn.

Host: Vì vậy, nếu bất kỳ ai khác có bất kỳ câu hỏi nào, hãy thoải mái giơ tay ảo của bạn và sau đó Veerle có thể biết. Đối với câu hỏi tiếp theo, anh ấy đã hỏi trong việc xây dựng một sản phẩm phần mềm, việc lựa chọn khung làm việc có thực sự quan trọng không? Ngoài ra khi sử dụng một khuôn khổ, cách tiếp cận kiến ​​trúc tốt nhất là gì? Đôi khi một dự án trở nên quá tải khi nó phát triển về quy mô lớn. Ví dụ, có một thành phần cấu trúc tốt. Rất muốn nghe ý kiến ​​của bạn và cách bạn xử lý vấn đề này.

Veerle: Sự lựa chọn của khuôn khổ có quan trọng không? Đúng vậy, bởi vì không phải mọi khuôn khổ đều phù hợp với những việc bạn muốn làm. Ví dụ, như tôi đã nói, một số thứ chúng tôi phát triển trong Shiny của mình, những thứ khác chúng tôi phát triển trong Vue và đó là lý do bởi vì, ứng dụng Vue giống một loại hệ thống CRM hơn, điều này không thực sự phù hợp với một ứng dụng Shiny trong khi các ứng dụng Shiny của chúng tôi mang phong cách bảng điều khiển hơn, giống như các nhóm.

Vì vậy, đúng vậy, khuôn khổ mà bạn chọn, chắc chắn có thể giới hạn những gì bạn có thể làm với một ứng dụng. Vì vậy, nó là quan trọng. Và rõ ràng là khi một dự án phát triển và ngày càng lớn hơn, nó có thể rất áp đảo và điều đó không thực sự quan trọng bạn đang sử dụng khuôn khổ nào. Nhưng nếu dự án của bạn phát triển, bạn cần đảm bảo rằng bạn thực hiện trong các thành phần, không lặp lại nguyên tắc khô khan và bạn làm cho nó dễ quản lý và hiệu quả nhất có thể.

Vì vậy, ngay cả khi bạn chọn Shiny, nếu bạn chọn Vue, nếu bạn chọn Lưu ý, hãy cố gắng làm điều đó trong các thành phần, cố gắng chia nó thành nhiều phần nhỏ hơn để thực sự quản lý được. Cấu trúc thành phần. Vâng. Tôi chắc chắn sẽ giới thiệu điều đó. Và tôi nghĩ mọi khung công tác ngày nay đều hỗ trợ kiểu cấu trúc đó. Vì vậy, tôi hy vọng rằng trả lời câu hỏi.

Host: Được chứ. Cảm ơn vì đã trả lời điều đó. Vì vậy, chúng tôi có một vài câu hỏi khác từ Donjung, bạn có muốn tự tắt tiếng hay không. Tôi nghĩ, không sao. Tôi nghĩ anh ấy đã nói trong cuộc trò chuyện rằng anh ấy muốn tôi đặt câu hỏi thay cho anh ấy. Vì vậy, câu hỏi này là làm thế nào để bạn đảm bảo rằng người dùng luôn có động lực để cộng tác và cung cấp phản hồi, đặc biệt nếu họ là người dùng lần đầu tiên? Bạn có cung cấp bồi thường? Nếu có. Bạn sẽ có lời khuyên nào để thúc đẩy người dùng cuối của bạn nhận được phản hồi?

Veerle: Chúng tôi có cung cấp bồi thường không? Không, chúng tôi không. Bạn nhận được một cuộc trò chuyện đáng yêu với chúng tôi. Đó là sự bù đắp và bạn sẽ nhận được một sản phẩm sau đó. Vì vậy, tôi nghĩ đó là động lực tuyệt vời, nhưng một lần nữa, chúng tôi có một cơ sở người dùng rất chuyên dụng. Đó không phải là trường hợp nếu bạn đang phát triển vì tài năng hoặc vì cá nhân. Vì vậy, để nói rằng, những gì tôi sẽ làm sau đó nếu bạn đang làm những việc giống như khảo sát, tôi nghĩ rằng nó luôn hoạt động nếu bạn muốn một số khoản bồi thường cho một cuộc khảo sát, mặc dù nó có thể là điểm cộng thêm trong tài khoản tiết kiệm mà bạn có, hoặc, có thể nó giống như một tính năng bổ sung đang được mở khóa hoặc một lời cảm ơn nhỏ. Bạn cũng có thể làm gì, ngay cả khi bạn đang nói chuyện với khách hàng, hãy làm điều gì đó đơn giản, đưa cho họ một ly cà phê Starbucks, bạn biết đấy, bạn có những phiếu thưởng trực tuyến như thế này mà bạn có thể làm. Chỉ cần cung cấp cho họ một lời cảm ơn bạn. Nói rằng bạn thực sự coi trọng phản hồi của họ. Và cũng cố gắng tạo động lực cho mọi người bằng cách tạo quỹ khảo sát, bạn biết đấy, hãy đưa ra phản hồi một cách vui vẻ.

Bạn thường thấy những thứ như thế này mà bạn có thể đưa ra một khuôn mặt cười hoặc một khuôn mặt rất, rất điên. Làm những việc mà mọi người hấp dẫn để nhanh chóng làm, đừng hỏi họ như 7 tỷ câu hỏi và không đặt ra yêu cầu. Văn bản của bạn cần phải được áp dụng cho 300 bảng điều lệ. Không ai sẽ làm cho nó trở nên nhiều nhất có thể. Và tôi hy vọng rằng điều đó sẽ thúc đẩy mọi người thực sự giúp đỡ bạn. Và cũng cho mọi người biết bạn đã làm gì với phản hồi đó, bởi vì không có gì thúc đẩy người dùng hơn là nếu bạn nói, được rồi, tôi muốn thấy tính năng này mà nếu bạn có thể nói vài tuần sau, Này, chúng tôi đã xây dựng Cái này dành cho bạn. Đi kiểm tra nó ra. Vì vậy, hãy cố gắng theo dõi xem ai đã thực sự cung cấp cho bạn thông tin phản hồi đó. Hãy cố gắng trả lại điều đó cho họ. Đó là một cách thực sự tốt đẹp tôi nghĩ.

Veerle: Anh ấy cũng có một câu hỏi tiếp theo. Về cơ bản, các thử nghiệm của chúng tôi đã thực hiện bằng cách sử dụng phương pháp UCD cung cấp cho bạn kết quả rõ ràng hơn về hướng thiết kế từ một thiết kế chính thức hoặc hai phần thiết kế cụ thể. Chúng tôi phải hiểu rằng người dùng của chúng tôi có thể thiếu sự quan tâm, sức mạnh đó với một lịch trình kiên nhẫn.

Điều đó chắc chắn đúng. Vâng, một lần nữa, thực sự phụ thuộc vào bối cảnh, bạn biết đấy, bạn có thể muốn hiển thị cho cùng một người dùng 3, 4, 5 tùy chọn khác nhau về cách thiết kế có thể trông như thế nào, điều này rõ ràng là rất nặng nề đối với người dùng vì điều đó mất rất nhiều về thời gian hay bạn sẽ phân chia cơ sở người dùng của mình với hy vọng được coi là tốt, về mặt đồ họa giống loại mẫu mà bạn vừa cung cấp với thiết kế A, B, C, DE mà bạn biết. Nếu bạn thanh toán các khoản nợ trên cơ sở thống kê rõ ràng, bạn có thể nhận được câu trả lời mà bạn đang tìm kiếm.

Nhưng vì nó thực sự phụ thuộc vào bối cảnh, cách bạn có thể quản lý điều đó tốt nhất. Nếu có bất kỳ câu hỏi nào tiếp theo, hãy cho tôi biết sau đó một câu hỏi khác từ Steve đã được gửi cho tôi.
Câu hỏi: Bạn đề xuất công cụ nào cho wireframe hoặc phác thảo?

Tôi nghĩ rằng wireframe đang phác thảo. Figma đang viết. Tốt. Và bạn cũng có những mô hình giả, Figma. Tôi nghĩ có lẽ khó hiểu hơn một chút nếu bạn không phải là một UX designer, việc này không khó, nhưng nó đòi hỏi một chút kỹ năng và các mock-up, ai cũng có thể thực sự làm được điều đó. Và nếu bạn không có quyền truy cập vào các mô hình hoặc Figma, bạn cũng có thể đơn giản là tạo ra sự thoải mái hoặc điều gì đó, bạn biết không?

Miễn là bạn có một ý tưởng chung, nó không cần phải hoàn hảo. Không cần phải chính xác 100%. Miễn là bạn có một ý tưởng chung về những gì nó sẽ trông như thế nào.

Câu hỏi: Sau đó, một câu hỏi. Với tư cách là người phụ trách kinh doanh, làm thế nào chúng tôi có thể đảm bảo khung phù hợp được nhà phát triển sử dụng?

Tôi không biết liệu một người kinh doanh có nhất thiết phải biết liệu đó là khuôn khổ tốt nhất hay không, một người kinh doanh. Nó phụ thuộc vào loại người kinh doanh bên và nó là. Tôi nghĩ bạn nên để khuôn khổ lựa chọn cho những người thực sự có kinh nghiệm với khuôn khổ nhất. Tôi muốn nói rằng các nhà phát triển, nhưng một lần nữa, đây là một nỗ lực của cả nhóm. Và với tư cách là một nhóm, bạn cần phải quyết định về khuôn khổ. Đừng để một người trong cả nhóm nói, được rồi, đây sẽ là khuôn khổ mà bạn cần để tất cả đồng ý về khuôn khổ mà bạn sẽ sử dụng.

Và khuôn khổ bạn sẽ sử dụng phụ thuộc vào rất nhiều thứ, kỹ năng của nhóm nắm giữ dữ liệu, tất cả những thứ, như tôi đã đề cập, bạn biết đấy. Đừng để đó là quyết định của một người. Và tôi, chúng ta gần như khuất bóng. Tôi xem nếu chúng ta đã hết thời gian. Tôi có thời gian cho một câu hỏi. Một câu hỏi cuối cùng.

Câu hỏi: Tôi là nhà phát triển phần mềm đã tích lũy được một số kiến ​​thức chuyên sâu về kỹ thuật, làm cách nào để tìm người hợp tác?

Làm thế nào bạn có thể tìm thấy người để làm việc cùng? Bạn có thể hỏi, chẳng hạn như những người làm nghề tự do muốn giúp bạn, bạn có thể tìm, xem nếu có thể, chẳng hạn như tôi không biết, hãy liên hệ với kết nối hoặc Codementor, có thể là như vậy.

Trên Codementor, bạn có rất nhiều nhà phát triển có thể giúp bạn hoặc hỗ trợ bạn trong các dự án của bạn. Nếu anh ấy có LinkedIn thông qua mạng xã hội, chỉ là, có rất nhiều nhà phát triển ngoài kia và những nhà phát triển đó có thể thực sự hợp tác với bạn. Vì vậy, chúng tôi chắc chắn sẽ xem xét các loại nền tảng cho các khoản nợ.

Đó là nó. Điều tôi muốn chia sẻ với bạn. Một điều cuối cùng là, LinkedIn của tôi. Hãy giữ liên lạc với tôi. Gửi cho tôi một yêu cầu kết nối hoặc cho tôi theo dõi. Đôi khi tôi chia sẻ những điều có thể về ngôn ngữ lập trình của chúng tôi, cũng như về sự phát triển phần mềm và cách chúng tôi thực hiện công việc tại công ty của mình.

Vì vậy, nếu bạn nghĩ nó thú vị, vui lòng liên hệ với đó và sau đó cảm ơn bạn rất nhiều vì đã dành thời gian và cho tất cả các câu hỏi của bạn. Và nếu bạn có thêm bất kỳ câu hỏi nào muốn tôi hỏi mà tôi không thể trả lời ở đây, bạn luôn có thể liên hệ với tôi trên LinkedIn. Cảm ơn bạn.

Host: Đáng kinh ngạc. Cảm ơn rất nhiều về buổi nói chuyện tuyệt vời này, Veerle. Đối với việc dành thời gian để trả lời các câu hỏi và công cụ của mọi người. Cuộc nói chuyện tuyệt vời. Và cá nhân tôi đã học được rất nhiều điều từ điều này. Vì vậy, một lần nữa xin cảm ơn mọi người đã tham gia sự kiện của chúng tôi và cảm ơn rất nhiều đến diễn giả của chúng tôi, thực sự đã dành cho buổi trò chuyện ngày hôm nay. Vì vậy, tôi hy vọng mọi người thích điều này và tiếp tục theo dõi sự kiện tiếp theo của chúng tôi, có tiêu đề làm thế nào để vượt qua hội chứng kẻ mạo danh trong công nghệ. Nó sẽ diễn ra vào tuần tới vào ngày XNUMX tháng XNUMX, nếu mọi người quan tâm đến việc tham gia và tôi hy vọng sẽ thấy mọi người ở đó, chúng tôi đã đăng một số thông tin trong cuộc trò chuyện đó.

Thông tin thêm về sự kiện ảo dành cho nhà phát triển

Sự kiện này được tổ chức bởi các sự kiện Codementor, một cộng đồng nhà phát triển và nền tảng sự kiện ảo để chia sẻ và tìm hiểu các công cụ và khái niệm mới. Tìm hiểu thêm về Codementor sự kiện tại đây ->

Nguồn: https://www.codementor.io/blog/cme-usercentric-dmirs6ed92