Một buổi cà phê trò chuyện (coffee chat) kéo dài khoảng 30–45 phút, không chính thức, ngồi ở quán cà phê hoặc gọi video. Không có bảng trắng, không có hội đồng, không có câu hỏi mẹo. Tôi kể về sản phẩm chúng tôi đang làm và vì sao lại làm nó, còn họ kể về công việc hiện tại và điều họ muốn làm tiếp theo. Cuối buổi, cả hai đều biết có nên nói chuyện sâu hơn hay không. Với tôi, tuyển dụng giống bài toán ghép cặp hơn là bài toán sàng lọc, và đây là cách nhanh nhất tôi biết để hai bên trao đổi đúng những thông tin cần cho việc ghép cặp đó.

Vì sao tôi chịu khó làm việc này

#

Tôi không còn coi những buổi này là tuyển dụng nữa. Đó chỉ là những cuộc trò chuyện, và thỉnh thoảng lại có một cuộc dẫn tới việc tuyển được người, có khi mười tám tháng sau, khi hoàn cảnh của người đó thay đổi. Những nguồn ứng viên đều đặn mang lại người giỏi đều được xây từ những mối quan hệ như vậy, chứ không phải từ tin đăng tuyển.

Những buổi cà phê này cũng giải quyết luôn vấn đề của bản mô tả công việc (JD). Bản mô tả công việc thì kiểu gì cũng phải viết chung chung. Còn khi ngồi cà phê, ứng viên có thể hỏi những câu thật sự quan trọng với họ: sáu tháng đầu thế nào thì được coi là thành công, tôi sẽ làm việc với ai, bài toán kỹ thuật khó nhằn nhất của đội lúc này là gì. Được nghe câu trả lời thành thật cho những câu hỏi đó, người ta thường tự biết mình có hợp hay không.

Hơn nữa, một buổi cà phê cho người ta tận mắt thấy văn hóa công ty bạn, thay vì chỉ nghe kể. Bạn có chuẩn bị trước không, có thật sự tò mò không, có tôn trọng thời gian của người khác không: những điều đó nói lên nhiều hơn bất kỳ trang tuyển dụng nào. Chiều ngược lại cũng thế. Cách một người cư xử trong một cuộc nói chuyện thoải mái cho bạn biết làm việc cùng họ sẽ ra sao, rõ hơn hẳn một buổi phỏng vấn mà họ đã tập dượt kỹ.

Hình thức này phát huy tác dụng nhất trong mấy trường hợp: khi tiếp cận một người hoàn toàn không tìm việc, khi muốn làm quen trước với một người được giới thiệu trước khi bắt đầu quy trình chính thức, và khi nói chuyện với ai đó đang cân nhắc rẽ hướng sự nghiệp, chẳng hạn từ người làm chuyên môn (IC) lên quản lý, từ startup sang tập đoàn, hoặc ngược lại. Khi thị trường nhân lực khan hiếm, chừng đó trường hợp đã bao gồm gần hết những người bạn muốn tuyển.

Tôi tổ chức một buổi như thế nào

#

Tin nhắn đầu tiên quyết định tất cả. Tin nhắn chung chung sẽ bị xóa ngay. Hãy tìm hiểu kỹ về người đó trước, và nói thẳng mục đích của mình:

“Chào Sarah, mình có xem bài nói của bạn về hệ thống phân tán ở QCon và mấy bài blog của bạn về event sourcing. Bên mình ở [Company] cũng đang vật lộn với những bài toán tương tự trong lúc mở rộng hạ tầng thanh toán. Bạn có muốn đi cà phê 30 phút không? Không phải phỏng vấn đâu, chỉ là mình tò mò muốn nghe góc nhìn của bạn và kể bạn nghe bên mình đang làm gì.”

Tin nhắn này hiệu quả vì nó cụ thể, nói rõ mục đích ngay từ đầu, và mang lại cho người nhận một thứ gì đó (một cuộc trò chuyện về những bài toán thú vị) chứ không chỉ xin thời gian của họ. Sau đó hãy làm cho mọi thứ thật dễ dàng: đưa ra vài khung giờ để họ chọn, chọn một chỗ tiện cho họ hoặc một công cụ gọi video không cần cài đặt, và gửi lời mời qua lịch hẳn hoi để không ai phải đoán giờ đoán chỗ.

Bản thân buổi nói chuyện chỉ cần một khung sườn lỏng lẻo. Mở đầu bằng vài phút hỏi han thật lòng và lý do bạn liên hệ. Tiếp theo là câu chuyện của họ: công việc hiện tại, điều họ thích, điều khiến họ bực mình, điều họ mong muốn ở chỗ làm tiếp theo. Ở đoạn này, việc của bạn chủ yếu là lắng nghe. Sau đó đến lượt bạn: sứ mệnh của công ty, những thách thức thật mà đội đang gặp, kể cả những phần khó khăn, vì ứng viên đánh giá cao sự minh bạch và nhận ra ngay khi bạn đang chào hàng. Đoạn đáng giá nhất là phần trò chuyện cởi mở gần cuối: cần những điều kiện gì thì họ mới cân nhắc chuyển việc? Kết thúc bằng các bước tiếp theo rõ ràng, kể cả khi bước tiếp theo chỉ là “mình giữ liên lạc nhé”.

Trong vòng 24 giờ, hãy nhắn lại một lời ngắn gọn có nhắc tới một chi tiết cụ thể trong buổi nói chuyện, và làm đúng những gì bạn đã hứa, dù là giới thiệu một người, gửi một liên kết hay bất cứ thứ gì. Chính phần việc nhàm chán sau buổi gặp này mới thể hiện rõ nhất văn hóa của bạn.

Nếu bạn làm việc này thường xuyên, hãy giữ một bảng tính đơn giản ghi lại những người đã nói chuyện và thỉnh thoảng hỏi thăm họ, kể cả khi không có vị trí nào đang tuyển. Và đây cũng không nhất thiết là việc riêng của quản lý. Nhiều buổi cà phê hay nhất lại là khi các kỹ sư của bạn đi cà phê với những người giỏi trong mạng lưới quen biết của chính họ. Những lời giới thiệu chất lượng thường đến từ đó.

Những câu hỏi đáng dành thời gian

#

Những câu tôi hay hỏi:

• “Gần đây bài toán thú vị nhất mà bạn từng làm là gì?”
• “Ở công việc tiếp theo, bạn muốn điều gì khác đi?”
• “Bạn hay học theo cách nào? Bạn muốn phát triển chuyên môn ra sao?”
• “Bạn có câu hỏi nào để đánh giá xem chỗ này có hợp với mình không?”

Những câu tôi sẽ hỏi nếu ngồi ở phía bên kia bàn:

• “Thách thức lớn nhất mà đội đang đối mặt lúc này là gì?”
• “Anh/chị đánh giá thế nào là thành công ở vị trí này?”
• “Con đường thăng tiến ở đây như thế nào?”
• “Vì sao anh/chị vào công ty này? Điều gì khiến anh/chị ở lại?”
• “Có điều gì khi làm ở đây mà có thể khiến tôi bất ngờ không?”

Nếu bạn là người được mời

#

Phần lớn những người tra “coffee chat là gì” lại đang ngồi ở phía bên kia bàn so với tôi: có ai đó vừa mời họ đi cà phê, và họ muốn biết mình sắp bước vào chuyện gì. Dưới đây là những điều tôi muốn nói với bạn, từ phía người hay gửi lời mời.

Đây không phải buổi phỏng vấn. Không ai chấm điểm bạn, cũng chẳng có bài kiểm tra nào, nên bạn không cần chuẩn bị sẵn câu trả lời. Dù vậy, đây vẫn là lần gặp đầu tiên và ấn tượng ban đầu vẫn quan trọng, nên hãy coi nó như gặp một người đồng nghiệp tương lai, chứ không phải gặp bạn của một người bạn. Điểm khác với phỏng vấn là ở đây bạn được phép tò mò, và người ta mong bạn hỏi cũng nhiều như bạn trả lời.

Về trang phục, hãy mặc như khi bạn đi làm ở công ty đó vào một ngày bình thường. Nếu không biết họ mặc thế nào thì cứ chọn phong cách lịch sự mà thoải mái (smart casual), không bao giờ sai. Nếu gặp qua video, hãy bật camera và tìm một phòng yên tĩnh; mấy chuyện đó quan trọng hơn chiếc áo bạn mặc.

Chuẩn bị mất khoảng nửa tiếng. Tìm hiểu xem công ty đó làm sản phẩm gì, và đọc qua những gì người mời bạn đã viết hoặc đã làm ra. Chuẩn bị sẵn một phần giới thiệu dài chừng hai phút về công việc hiện tại và điều bạn muốn làm tiếp theo, vì kiểu gì bạn cũng sẽ được hỏi câu đó. Mang theo hai, ba câu hỏi của riêng mình; danh sách ở phần trên là một điểm khởi đầu không tệ.

Còn nên nói chuyện gì: công việc của bạn, điều bạn thích ở công việc đó, và những gì bạn tò mò về công việc của họ. Chuyện lương thì để sau, trừ khi họ chủ động nhắc tới. Bạn hoàn toàn có thể hỏi thẳng xem họ có đang nghĩ tới vị trí nào cho bạn không, và nếu có thì quy trình tuyển dụng sẽ diễn ra thế nào.

Thường thì ai mời người đó trả tiền. Bạn cứ ngỏ ý trả, nhưng đừng giành nhau. Trong vòng một ngày, hãy gửi một lời cảm ơn ngắn có nhắc tới điều gì đó hai bên thực sự đã nói, vậy là bạn đã làm tốt hơn phần lớn mọi người rồi.

Còn nếu chính bạn muốn có một buổi coffee chat, cứ chủ động hỏi. Viết tin nhắn ngắn thôi, nói rõ vì sao bạn muốn gặp đúng người đó, và làm sao cho họ dễ nhận lời: “Chào bạn, mình vẫn theo dõi phần việc của đội bạn với tính năng tìm kiếm mới, và mình đang tính chuyển sang mảng platform engineering. Trong vài tuần tới, bạn có thể dành cho mình 30 phút đi cà phê hoặc gọi điện không? Mình sẽ sắp xếp theo lịch của bạn.” Với một lời đề nghị cụ thể như vậy, phần lớn mọi người đều đồng ý.

Những cách làm hỏng buổi cà phê

#

Cách nhanh nhất là biến nó thành một buổi phỏng vấn trá hình. Hễ bạn bắt đầu hỏi kiểm tra kỹ năng kỹ thuật hay lồng vào mấy câu hỏi hành vi là bạn đã phá vỡ thỏa thuận ngầm giữa hai bên, nên hãy để dành những thứ đó cho quy trình chính thức. Đứng thứ hai là chào hàng quá đà: những người ở lại lâu dài là những người đã biết rõ các khó khăn ngay từ lúc nhận lời. Đến mà không chuẩn bị, hoặc im bặt sau buổi gặp, thì gây hại âm thầm hơn; buổi cà phê nào cũng góp phần định hình những gì người đó kể về bạn với mạng lưới của họ.

Từ phía tôi, dấu hiệu đáng lo là một ứng viên không tò mò về bất cứ điều gì, một cuộc nói chuyện chỉ thuần túy trao đổi lợi ích, hoặc một người nhắc đến chỗ làm cũ nào cũng bằng cùng một giọng cay đắng. Ứng viên cũng nên có danh sách dấu hiệu của riêng mình: người đại diện công ty không giải thích được vì sao công việc này có ý nghĩa, những câu trả lời né tránh về tỷ lệ nghỉ việc hay định hướng của công ty, và bất kỳ ai chỉ lo chào mời bạn hơn là tìm hiểu bạn.

Không phải buổi cà phê nào cũng dẫn tới kết quả, và điều đó hoàn toàn bình thường, vì phần lớn là không. Mục đích là lần tới khi cần tuyển gấp cho một vị trí quan trọng, bạn không phải bắt đầu từ một tin tuyển dụng trống trơn, mà từ cả một loạt những cuộc trò chuyện thật. Hãy liên hệ bằng một lời mời đi cà phê, chứ không phải bằng một bản mô tả công việc.

Đọc thêm

#

Bài viết liên quan trên blog này:

• Dùng phương pháp STAR để phỏng vấn lập trình viên - khi buổi cà phê chuyển thành quy trình phỏng vấn chính thức
• Ba điều tôi ưu tiên khi mới làm quản lý kỹ thuật - điều gì giúp một đội làm việc tốt với nhau, cũng chính là thứ bạn đang tìm khi ghép cặp
• Vì sao bạn nên thực tập ở startup - bối cảnh hữu ích khi nói chuyện với người đang cân nhắc chuyển sang startup

Tài liệu bên ngoài:

• First Round Review: Hiring Engineers - các hướng dẫn tuyển dụng cho startup từ những người điều hành giàu kinh nghiệm
• Lara Hogan: “Questions for Our First 1:1” - viết cho các buổi gặp riêng 1:1, nhưng dùng khi đi cà phê cũng rất hợp
• Patrick McKenzie bàn về đàm phán lương - đáng đọc để hiểu góc nhìn của ứng viên
• Who: The A Method for Hiring - khung phương pháp tuyển dụng bài bản của Geoff Smart và Randy Street
• Harvard Business Review: Hiring and Recruitment - các bài viết dựa trên nghiên cứu về thu hút nhân tài

Vì sao họ bỏ họp

#

Điểm xuất phát của họ chắc bạn cũng thấy quen. Không ai chuẩn bị gì, họp thì bắt đầu muộn, và ai nói to nhất thì người đó thắng, bất kể đúng hay sai. Một tiếng sau bạn bước ra còn rối hơn lúc bước vào, và bắt đầu lục ngăn kéo xem còn viên paracetamol nào không.

Ban đầu Alan thử sửa lại cách họp: tối đa 15 phút, chương trình họp rõ ràng, họp xong bắt buộc phải có quyết định. Nhưng không duy trì được. Thảo luận cứ lan man, chẳng ai nhớ ai đã nói gì, còn người vắng mặt hay làm việc từ xa thì coi như chịu thiệt. Thế là họ chuyển hẳn sang viết.

Những lợi ích họ nêu ra, tôi thấy đều đúng. Viết buộc bạn phải chậm lại và suy nghĩ thật sự, nên cuộc thảo luận sâu hơn và lập luận chặt chẽ hơn. Mọi thứ được ghi lại rõ ràng, thay vì mỗi người nhớ một ít. Tranh luận không còn là cuộc thi xem ai ăn nói giỏi hơn. Và vì diễn đàn mở cho cả công ty, ai cũng có thể góp ý, chứ không chỉ những người tình cờ có mặt trong phòng họp.

GitHub làm diễn đàn chung của công ty

#

Diễn đàn đó chính là GitHub, một nền tảng vốn sinh ra để rà soát mã (code review), và Alan cứ thế vui vẻ “mượn” nó cho việc khác. Cách thiết lập đơn giản đến mức hơi ngại:

1. Tạo một tài khoản GitHub.
2. Tạo một kho mã (repository) riêng tư không chứa dòng mã nào (kho của họ tên là “Topics”).
3. Thêm một hệ thống nhãn (label) để phân loại các cuộc thảo luận.
4. Dùng tab Issues: issue đang mở là thảo luận đang diễn ra, issue đã đóng là quyết định đã chốt.

Họ đã vượt mốc 17,000 issue. Tức là có ngần ấy cuộc họp không bao giờ phải diễn ra, và, phần tôi thích nhất, họ có cả một lịch sử tra cứu được về lý do vì sao mỗi quyết định lại đi theo hướng đó. Nếu muốn lật lại một quyết định cũ, bạn có thể đọc trước xem lần trước những lập luận nào đã thắng.

Khi nào nên mở issue

#

Không phải quyết định nào cũng đáng mở một issue. Họ lọc bằng bốn câu hỏi: ai sẽ bị ảnh hưởng? có dễ quay lại không? gấp đến mức nào? mình có cần thêm bối cảnh trước khi quyết không?

Đại khái, quyết định nào tác động lớn và khó quay lại thì đưa lên diễn đàn, còn lại cứ để trên Slack. Họ dựa vào cách phân biệt “cửa một chiều” và “cửa hai chiều”. Quyết định một chiều là loại muốn quay lại thì quá tốn kém hoặc quá đau (ví dụ của họ là tăng giá), nên được xử lý đầy đủ bằng văn bản. Quyết định hai chiều thì dễ quay lại, tệ nhất cũng chỉ mất chút công sức, nên không cần thủ tục rườm rà.

LOCI: ai làm gì

#

Mỗi cuộc thảo luận đều phân vai theo mô hình LOCI: Lead, Owner, Consulted, Informed.

Lead chịu trách nhiệm về thành công của quyết định và đảm bảo cả đội hiểu rõ bối cảnh. Ngay từ đầu, Lead nói rõ mình muốn tham gia sâu đến đâu, sau đó tin tưởng giao cho Owner, chịu trách nhiệm về những gì đội làm ra, và chỉ lên tiếng khi thực sự không đồng ý. Mỗi thảo luận chỉ có đúng một Lead.

Owner là người chốt quyết định cuối cùng và kéo dự án đi tới. Owner giữ cho những người tham gia luôn nắm được tình hình và góp ý đúng hạn, tìm hiểu vấn đề, mở và đóng issue, rồi thông báo quyết định. Nếu vướng một bức tường không tự vượt qua được thì Owner tìm đến Lead. Mỗi quyết định chỉ có đúng một Owner.

Consulted là những người mà ý kiến của họ thực sự ảnh hưởng tới việc cân nhắc được mất. Họ phải góp ý kịp thời, dù chỉ để nói “tôi không có gì thêm”, và phải lên tiếng cảnh báo (đẩy lên Lead nếu cần) khi thấy quyết định đang sai nghiêm trọng. Alan giới hạn nhóm này khoảng sáu người, vì càng thêm người góp ý thì càng tốn thêm thời gian.

Informed thì đơn giản là những người được báo tin, thường là sau khi quyết định đã chốt. Đây là giao tiếp một chiều, không ai chờ họ phản hồi. Owner là người quyết định ai bị ảnh hưởng đủ nhiều để cần được thông báo.

Đó là cách làm cho từng quyết định. Với cả một dự án, tôi ghi những điều này ra một lần, thành một kế hoạch truyền thông dự án: ai cần được biết điều gì, bao lâu một lần, và ai là người báo cho họ.

Một issue gồm những gì

#

Issue nào cũng dùng chung một mẫu (template). Mẫu này vừa giúp suy nghĩ rõ ràng hơn, vừa ngầm dạy các bạn mới vào nghề cách bóc tách một vấn đề:

• Phạm vi (Scope): lý do có cuộc thảo luận này, kèm một dòng hay bị xem nhẹ là “issue này KHÔNG bàn về…”
• Bối cảnh và tài liệu: đường dẫn tới các thảo luận và tài liệu trước đó
• LOCI: ai là Lead, Owner, Consulted, Informed
• Hạn chót: góp ý trước khi nào, khi nào đóng issue, khi nào cần có giải pháp
• Đề xuất giải pháp: một phương án cụ thể, hoặc vài lựa chọn để cân nhắc
• Câu hỏi: hỏi thẳng từng người cụ thể để xác nhận hoặc bác bỏ từng giả định cụ thể, để issue không thành lá thư bỏ vào chai thả trôi

Quy tắc viết để mọi thứ không bị ì

#

Tranh luận bằng chữ cũng có thể lê thê y như tranh luận bằng miệng, nên họ đặt ra quy tắc. Viết ngắn gọn. Họ trích lời Boileau: “Điều gì đã nghĩ thấu thì sẽ nói ra rõ ràng.” Nếu bạn không viết được nó ra một cách đơn giản, tức là bạn vẫn chưa thực sự chắc. Mọi thứ viết ra đều phải qua phép thử “Thì sao?”: nếu bình luận của bạn dẫn tới hệ quả gì mà người đọc chưa thấy ngay, hãy nói thẳng ra.

Với Owner, việc theo sát về sau quan trọng không kém lúc mở đầu. Phải giữ cho cuộc thảo luận bám vào “câu hỏi triệu đô”, tức đúng cái điểm vướng thực sự quan trọng, thay vì để nó tan vào tiểu tiết. Thường xuyên tóm tắt lại những gì đã thống nhất và những gì còn bỏ ngỏ. Còn nhắc nhở qua Slack thì chỉ là phương án cuối cùng, dành cho những phần góp ý đã quá hạn hoặc chuyện thực sự gấp.

Owner cũng ẩn đi những bình luận không giúp cuộc thảo luận tiến lên. Ai cũng phải thạo cách định dạng trên GitHub, từ tiêu đề, chú thích cuối trang, bảng cho tới phím tắt, vì khi viết thì hình thức gần như quan trọng ngang nội dung.

Không cần đồng thuận, không có khán giả

#

Có hai quy tắc giữ cho cách làm này không biến thành kiểu quyết định theo hội đồng.

Thứ nhất, Owner ra quyết định theo kiểu mà Alan gọi là “nhà độc tài sáng suốt”. Họ tìm hiểu các ý tưởng, cân nhắc rủi ro, chất vấn đồng nghiệp, nhưng không đi tìm sự đồng thuận và cũng không bắt buộc phải làm theo mọi điều người khác nói. Alan nói thẳng họ không phải một nền dân chủ: nhân viên nào cũng là cổ đông, và lợi ích của công ty đặt trên lợi ích của một đội hay một cá nhân. Khi Owner đã khá chắc về một hướng đi, họ quyết, mọi người cùng làm thử, và khi đã thấy được tác động thì cùng nhìn lại xem quyết định đó đúng hay sai.

Thứ hai, số người tham gia được kiểm soát. Quy tắc “hai chiếc pizza” của Jeff Bezos cũng đúng với cách làm việc bất đồng bộ (async): issue càng đông người thì mỗi người càng góp ít. Quá khoảng sáu người là hiệu ứng khán giả xuất hiện, và chất lượng góp ý đi xuống. Chuyện thông báo cũng theo cùng tinh thần đó. Alan tin rằng ai cũng đã tự cấu hình thông báo GitHub cho mình (vào Settings, rồi tick “Web and Mobile” ở cả “Participating” lẫn “Watching”), nên việc gắn thẻ (tag) thẳng tên người trong phần Câu hỏi được giữ ở mức tối thiểu.

Những gì tôi học được

#

Bạn không bao giờ kể lại được trọn vẹn một cuộc họp cho người vắng mặt, nhưng một quyết định đã viết ra thì ai cũng đọc được. Alan không nói đây là hệ thống tốt nhất hay duy nhất, chỉ là hệ thống hợp với họ: ít bị ngắt quãng hơn, ít hiệu ứng khán giả hơn, và quyết định được đưa ra sau khi đã lùi lại một bước để nhìn, với đầy đủ dữ kiện trên giấy. Tôi chưa định chuyển mọi quyết định của đội mình sang GitHub issue, nhưng cái mẫu dưới đây thì sẽ vào thẳng kho mã của chúng tôi.

Mẫu đề xuất, dùng làm mẫu issue (issue template) trên GitHub

#

Hãy lưu nội dung dưới đây thành tệp .github/ISSUE_TEMPLATE/decision.md trong kho mã mà bạn dùng làm diễn đàn, và mỗi lần có người mở issue mới, GitHub sẽ gợi ý sẵn mẫu này. Các mục trong mẫu là của Alan; phần LOCI và nhãn là tôi thêm vào.

---
name: Quyết định
about: Đề xuất một quyết định và thu thập góp ý bằng văn bản
title: "[Quyết định] "
labels: decision
---

## Phạm vi
- Mục tiêu của issue này là ...
- Issue này KHÔNG bàn về ...

## Vì sao tôi mở issue này

## LOCI
- Lead:
- Owner:
- Consulted:
- Informed:

## Mốc thời gian
- Góp ý trước ngày:
- Chốt quyết định trước ngày:

## Bối cảnh và tài liệu

## Đề xuất

## Câu hỏi

Nên dùng GitHub Issues hay GitHub Projects?

#

Nếu bạn đang tính dùng GitHub để quản lý dự án theo nghĩa rộng hơn, thì nên biết hai phần này làm hai việc khác nhau. GitHub Issues là nơi diễn ra cuộc thảo luận, và khi issue đã đóng thì là nơi lưu lại quyết định. Còn một GitHub Project là một bảng công việc, ở dạng cột kiểu Kanban (board) hoặc dạng bảng tính (table), đặt chồng lên các issue của một hay nhiều kho mã, với các trường (field) do bạn tự định nghĩa như trạng thái, người phụ trách hay hạn chót. Với một diễn đàn ra quyết định như của Alan, chỉ cần nhãn và danh sách issue là đủ. Hãy thêm một Project khi bạn muốn thấy mọi quyết định đang mở trên cùng một màn hình, sắp xếp theo ngày phải chốt, và khi bạn bắt đầu theo dõi cả các đầu việc phát triển, bàn giao sản phẩm ở cùng chỗ đó. Đó cũng là lúc phần lớn các đội rốt cuộc dùng cả hai.

Ý tưởng

#

Quầy đồ ăn đường phố ở Hàn Quốc không có địa chỉ. Một quán pojangmacha (kiểu lều bán đồ ăn, đồ nhậu ven đường) dựng ở đâu thì bán ở đó, và nếu bạn chưa biết chỗ từ trước thì có lên mạng tìm cũng chịu. Ứng dụng của chúng tôi đưa các quầy này lên bản đồ, theo đúng nghĩa đen. Vậy là vừa có lợi cho người bán, vừa có lợi cho bất kỳ ai đang đi lùng một đĩa tteokbokki lúc nửa đêm.

Cuối tuần hôm đó

#

Hackathon do Lunit Global tổ chức, và họ cho mượn luôn văn phòng để làm địa điểm. Các đội đến từ đủ mọi lĩnh vực, phần lớn chúng tôi thức trắng làm xuyên đêm, còn ban tổ chức thì lo cho mọi thứ chạy trơn tru. Đúng kiểu sự kiện mà bạn ngẩng đầu lên thì đã 4 giờ sáng lúc nào không hay.

Đội của chúng tôi

#

Đội gồm Sharon Levy, Jonothan Sue, tôi và Tiaan van der Riel. Mỗi người có một thế mạnh riêng, nên chia việc chẳng mấy khó khăn. Tôi nghĩ bài thuyết trình (pitch) thuyết phục được ban giám khảo là vì vấn đề này không cần giải thích nhiều. Chỉ cần nói ra câu “các quầy đồ ăn đường phố đang vô hình trên mạng” là giải pháp tự hiện ra.

Bước tiếp theo

#

Chúng tôi đang chuẩn bị phát hành ứng dụng lên các kho ứng dụng. Nó khởi đầu chỉ là một dự án làm cho vui trong một cuối tuần, nhưng vấn đề nó giải quyết là có thật, nên giờ mà dừng thì thấy phí.

Nếu đây là lần đầu bạn đi hackathon

#

Nếu bạn chưa đi hackathon bao giờ, tôi khuyên bạn nên thử một lần. Bạn cùng những người chưa từng làm chung dựng lên một sản phẩm thật nhanh, biết được mình thực sự chịu áp lực ra sao, và thỉnh thoảng bạn ra về với một thứ đáng để làm tiếp. Tệ nhất thì bạn cũng được một cuối tuần ăn vặt miễn phí, cộng thêm một bản mẫu (prototype) chạy được mà chẳng ai nhờ làm.

Vài điều nên biết trước khi đi:

• Chọn một vấn đề mà bạn giải thích được trong một câu. Nếu ban giám khảo mất cả phút đầu chỉ để hiểu vấn đề là gì, thì tới lúc bạn trình bày giải pháp họ đã không còn nghe kỹ nữa.
• Chia vai trò thật sớm, tốt nhất là ngay trong giờ đầu tiên: ai lập trình, ai thiết kế, ai lo phần thuyết trình (pitch). Để tới 2 giờ sáng mới bàn chuyện này thì tốn kém hơn nhiều.
• Làm luồng demo trước. Cho cái luồng duy nhất bạn sẽ trình diễn trên sân khấu chạy trơn tru từ đầu tới cuối, rồi hẵng thêm những thứ khác.
• Tập pitch thành tiếng, chạy cùng bản demo thật, ít nhất hai lần. Bài pitch gần như lúc nào cũng dài hơn bạn tưởng.
• Ngủ một chút. Chỉ cần chợp mắt vài tiếng thôi, các quyết định buổi sáng lẫn bài pitch đều khá hơn thấy rõ.

Liên kết:

#

https://lnkd.in/drMXUgPB