Gu cá nhân

Gần đây các bài viết xoay quanh AI và tác động của nó lên kỹ sư phần mềm, hay ngành phần mềm nói chung, ngày càng nhiều. Một trong những yếu tố hay được nhắc đi nhắc là là “taste”. Vậy “taste” ở đây là gì, trong ngữ cảnh ngành phần mềm liệu nó sẽ có vai trò như thế nào?

Đối với mình, “taste” có thể nhìn nhận qua hai khía cạnh chuẩn mực chất lượng (quality standard) và gu cá nhân (personal preference). 

Chuẩn mực chất lượng là gì? Có nhiều cách để định nghĩa, ở đây, mình sẽ định nghĩa quality standard là những quy tắc đo đếm được mà chúng ta dùng để đánh giá một phần mềm là tốt. Nhưng tiêu chí này có thể bao gồm nhưng không giới hạn ở những điều sau:

  • Tốc độ và sự ổn định: Ứng dụng phải chạy nhanh, mượt mà, không có lỗi vặt.
  • Giao diện người dùng (UI) trực quan: Các nút bấm, menu được đặt ở vị trí hợp lý, dễ tìm, dễ hiểu. Người dùng không cần phải “học” cách sử dụng một tính năng cơ bản.
  • Trải nghiệm người dùng (UX) liền mạch: Luồng sử dụng sản phẩm phải logic và không gây khó chịu. Mọi tương tác đều cho cảm giác trôi chảy và có chủ đích.
  • Sự chỉn chu trong chi tiết: Từ con chữ (typography) dễ đọc, khoảng cách giữa các thành phần được căn chỉnh hợp lý, cho đến những hiệu ứng chuyển động (animation) tinh tế.

Trước đây, để đạt được chuẩn mực thì đòi hỏi một hoặc nhiều người có kinh nghiệm và tay nghề cao cùng phối hợp. Nhưng giờ đây, khi AI đang tự động hóa khâu sinh code rất nhiều, thì chi phí cần thiết để đạt được những chuẩn mực này sẽ càng ngày càng thấp. Những tiêu chí chất lượng trong quá khứ sẽ trở thành yêu cầu tối thiểu của bất cứ phần mềm nào được tạo ra. 

Và khi đó, để một phần mềm trở nên khác biệt thì “gu cá nhân” của người phát triển sẽ thành quan trọng. Gu cá nhân trong phần mềm lúc này sẽ phản ánh thông quan:

  • Phong cách thẩm mỹ: Sản phẩm của bạn theo đuổi sự tối giản (minimalism) của Apple, sự phá cách (brutalism) hay sự vui tươi, màu sắc?
  • Triết lý sản phẩm: Những giá trị mà bạn tin tưởng và gửi gắm vào sản phẩm. Bạn ưu tiên sự đơn giản hay sự đa tính năng? Bạn muốn người dùng dành nhiều thời gian trên ứng dụng hay hoàn thành công việc nhanh nhất có thể?
  • Giọng văn (Tone of Voice): Những thông điệp, thông báo lỗi, … sẽ có tông giọng như thế nào?

Đây là những lựa chọn không có đúng, sai tuyệt đối. Nó phụ thuộc vào tầm nhìn của người sáng tạo và đối tượng người dùng mà họ hướng tới. Đây chính là thứ AI không thể tự quyết định được.

Bạn có thể yêu cầu AI tạo ra 100 mẫu thiết kế giao diện, nhưng chính bạn, với “gu” của mình, mới là người chọn ra phương án duy nhất thể hiện đúng tinh thần sản phẩm và có khả năng kết nối với người dùng. Bạn có thể dùng AI để viết nội dung, nhưng chính bạn phải định hình giọng văn và thông điệp cốt lõi.

Tính ra, gu cá nhân không phải một chủ đề mới. Khi làm lâu trong ngành, bạn sẽ thấy các lập trình viên kinh nghiệm cũng hình thành những lựa chọn riêng về cách thiết kế class, interface, API, modules, … Nhưng điều này thường chỉ xuất hiện khi kinh nghiệm đủ dày, vì gu cá nhân chỉ được hình thành sau rất nhiều lựa chọn tại những thời điểm khác nhau trong quá khứ, và mỗi lựa chọn đều tốn nhiều thời gian và công sức để triển khai.

Trong tương lai, khi con người có thể đưa ra những lựa chọn và thực thi nhanh lựa chọn đó, một sự bùng nổ về gu cá nhân có thể xuất hiện khi ai cũng có thể xây dựng một phần mềm của mình và cho mình hoặc nhóm người giống mình.

Một tuần làm việc của Engineering Manager (p2)

Thứ tư – ngày không họp hành

Qua hai ngày đầu tuần thì hẳn các bạn sẽ đặt dấu hỏi, ủa, vậy EM thấy họp suốt ngày vậy thì còn làm gì khác không? Thật ra thì cũng có đấy. Ngoài các khoảng nghỉ giữa các cuộc họp thì EM sẽ có những tasks của riêng mình, và những tasks này thường sẽ tận dụng các khoảng thời gian rảnh giữa các meeting, hoặc là tận dụng no-meeting day để hoàn thành.

(1) Làm các tasks liên quan đến engineering. Cụ thể là viết thinking document hoặc design document để nêu hoặc phân tích một vấn đề nào đó. Các vấn đề phân tích mà vai trò EM phụ trách thường sẽ mang tính tổng quan hoặc chiến lược hơn so với các bài toán vận hành hàng ngày. Ví dụ như một vài vấn đề mình sẽ phải viết gần đây:

  • Chia sẻ quan điểm về vai trò của low-code platform trong tổ chức? Có nên dùng hay không? Nếu dùng thì nên dùng như thế nào?
  • Bài toán workflow automation là bài toán của ai (trong tổ chức lớn hơn), nên được giao cho ai?
  • Đề xuất cho một platform khác có liên quan đề platform của mình

(2) Thực hiện vai trò giám sát và coaching. Một trong những trách nhiệm lớn nhất của EM là phải giám sát và chịu trách nhiệm cho sự phát triển của team mình. Để thực hiện vai trò này thì bản thân cần liên tục theo dõi các kênh thông tin của team mình trên Slack để xem các thành viên đang trao đổi về vấn đề gì, có thể nhảy vào cùng trao đổi và tìm cách đưa cuộc thảo luận theo đúng hướng (nếu bản thân thấy chưa đúng hướng).

Ngoài ra cũng sẽ dùng các nội dung trao đổi này để mang ra thảo luận với từng cá nhân trong quá trình 1:1 để góp ý và chia sẻ quan điểm của mình. Sẽ có những tình huống bản thân thấy một thành viên A nào đó phản hồi chưa hợp lý, hoặc chưa trọn vẹn, ví dụ như bạn ấy đang giải thích về một vấn đề cho một người dùng non-tech nhưng lại dùng quá nhiều thuật ngữ kỹ thuật. Trong những tình huống như vậy thì mình sẽ cần ghi nhận và thảo luận với bạn ấy trong những buổi gặp mặt để bạn lưu ý hơn.

Bên cạnh đó, EM cũng sẽ cần phải giúp các thành viên phát triển thông qua việc thảo luận về career path, cũng như xác định độ ưu tiên cho các thành viên và cân bằng giữa nhu cầu phát triển bản thân và nhu cầu của công ty. Bên công ty mình thì trong thời gian gần đây có triển khai một hoạt động gọi là Plan & Priority, trong đó mỗi thành viên sẽ cần tự đặt ra các mục tiêu phát triển bản thân cũng như các ưu tiên trong sự nghiệp hiện tại. EM sẽ dựa vào nhu cầu của từng thành viên để từ đó có sự phân công các tasks phù hợp.

Ví dụ như nếu một bạn trong 6 tháng tới muốn đầu tư nhiều quanh hệ thống Data, vậy thì EM cần tìm cách để đưa bạn vào nhóm làm task liên quan đến Data nhiều hơn. Hoặc một bạn quan tâm đến DevOps thì EM cần tìm cách phân các tasks liên quan đến DevOps nhiều hơn cho bạn, …

(3) Thực hiện vai trò lên kế hoạch. Lập và thực thi kế hoạch là một trong những vai trò quan trọng mà EM cần phải đảm đương, đặc biệt là việc lên kế hoạch dài hạn với chu kỳ 3-6 tháng trở lên. Trong một tổ chức lớn như nơi bản thân đang làm việc, việc có những chiến lược và kế hoạch dài hạn 2-3 năm là cần thiết vì nhiều lý do. Nhiệm vụ của EM lúc này là phải hiểu được platform hoặc team mình đang phụ trách đang đứng ở đâu trong bức tranh toàn cảnh của công ty, phòng ban của mình để tự đó đưa ra được các kế hoạch phù hợp.

Trong vai trò này, bản thân sẽ cần phải tham gia chuẩn bị những thứ như

  • Budget planning. Dự toán xem hạ tầng của team đang quản lý cần kinh phí bao nhiêu trong 6 tháng – 1 năm tới.
  • OKR planning. Mỗi 6 tháng một lần, sẽ phải thống nhất OKR của team để review với các manager cùng các stakeholders liên quan.
  • Vision and Strategy docs. 1 năm một lần sẽ cần phải review lại về chiến lược dài hơi của team, platform để coi team đang ở đâu và cần phát triển theo hướng nào.
  • Execution plan. Tham gia vào soạn thảo các kế hoạch thực thi ở phía engineering từ một kế hoạch lớn ảnh hưởng đến nhiều bộ phận khác nhau.

(4) Các task khác lặt vặt không tên. Tùy vào quy mô và quy trình của tổ chức mà số lượng task lặt vặt có thể nhiều hoặc ít, nhưng sẽ có kha khá các tasks có thể kể tên như: review và approve request xin quyền từ team, support một bạn user của platform, xin budget engagement, …

Thế nào là một ứng dụng tốt?

Đọc bài viết gốc: http://coding-geek.com/what-is-a-good-application/

Gần đây, tôi ứng tuyển vào một vị trí kỹ thuật ở công ty đang làm hiện tại. Một trong những câu hỏi mà người phỏng vấn hỏi tôi đó là “Thế nào là một ứng dụng tốt?”.

Hơi bất ngờ vì tôi chưa thực sự nghĩ về điều này trước đây. Vì thế tôi nghĩ đây sẽ là một bài tập tốt cho bản thân mình khi tổng hợp lại góc nhìn của mình về “Thế nào là một ứng dụng tốt?”. Thời điểm được phỏng vấn, tôi đã đưa ra một câu trả lời từ góc nhìn của một dân kỹ thuật. Và bây giờ, tôi lại nghĩ về câu hỏi đó một lần nữa, và đây là những suy nghĩ mới nhất của tôi cho câu hỏi này.

Continue reading “Thế nào là một ứng dụng tốt?”

Social Proof – Nhiều người tin thì chưa hẳn là điều đúng

Trong lần đầu sang Singapore công tác, tôi học được một quy tắc ứng xử của người dân Singapore đó là khi đi trên thang cuốn thì sẽ đứng bên trái, và chừa phía bên phải để những người vội vã có thể chạy lên. Và vô hình chung, tôi vừa nhìn thấy họ làm điều đó thì tôi cũng làm theo. Tại sao vậy? Tại vì chúng ta chịu sự tác động của Social Proof, hay nôm na là hiệu ứng bầy đàn.

Social Proof là một hiệu ứng ám chỉ việc một cá nhân sẽ có khuynh hướng ứng xử tương đồng với tập thể mà người đó thuộc về. Ở trong một tập thể mà ai cũng bỏ rác đúng nơi quy định, thì tự khắc chúng ta cũng sẽ làm điều tương tự nếu không sẽ bị đào thải. Nhưng nếu trong một tập thể nơi mọi người bỏ rác lung tung, tự khắc chúng ta sẽ cảm thấy “kỳ kỳ” khi bản thân mình lại làm điều đúng.

Và chính như hai ví dụ đó nêu ra, Social Proof có tác động tích cực khi “tập thể” đang hành xử theo chiều hướng tốt, đang tin vào điều đúng. Nhưng ngược lại, chúng ta cũng phải ý thức được rằng, khi nhiều người xung quanh chúng ta cùng tin vào một thứ, không có nghĩa là đó chắc hẳn là điều đúng và chúng ta phải làm theo.

Là một người lý trí, chúng ta cần phải luôn tự có phán xét đúng, sai của riêng mình.

Bài viết liên quan: Social Loafing