1. Khởi nghiệp StuJob (Student Job)

Giới thiệu: StuJob - Cộng đồng sinh viên, được xây dựng từ sinh viên và vì sinh viên. Mục đích cung cấp môi trường học tập thực tiễn với doanh nghiệp, cộng tác và hỗ trợ sinh viên có công việc phù hợp mà đảm bảo được các quyền lợi chính đáng của đôi bên.

Story  1:  Chính genZ còn khó làm việc với genZ
Tóm tắt: Burning Out, Trì Hoãn, Biến mất không một lời nhắn và trách nhiệm trong công việc.

Story 2: Công ty khởi nghiệp (Startup) có cần phòng hành chính nhân sự từ lúc mới thành lập  không?

Story 3: Tuổi tác có thể là căn cứ để người khác vượt quyền vì sự đối nghịch về quyền lực (Power Dynamics)

2. Khởi nghiệp StuTrans (Dự án con của StuJob - lĩnh vực Chuyển đổi số)

Story 1: Khi việc kiếm tiền quá dễ với Startup ngay những ngày đầu!!!

Story 2: Mục tiêu cuối cùng vẫn là phát triển sản phẩm và làm hài lòng khách hàng.

Story 3: Startup nên biết sợ việc tự đầu tư một khoảng nào đó (không cần thiết)

3. Khởi nghiệp StuDes (Dự án con của StuJob - lĩnh vực kĩ thuật số)

Story 1: Khi sản phẩm bị trễ hẹn với khách hàng, ai là người chịu trách nhiệm ?

Story 2: Cần làm gì khi nhận dự án không đủ năng lực xử lý? (hoặc có thể nói khi kì vọng vượt xa năng lực)

4. Leadership (Tổng hợp những cái sai của tôi khi làm lãnh đạo)

• Tôi đã không bảo vệ nhân viên của mình

• Tôi đã không thực hiện được cam kết của mình

• Tôi đã gây cản trở công việc của mọi người vì bản thân thiếu kiến thức

• Tôi đã thị uy với nhân viên( kick/ đuổi) bằng quyền hạn( AUTHORITY) của mình (Coercive - psychologists John French and Bertram Raven)

1. Dự án môn DPL302m (Dự án làm sản phẩm với Makeup Beauty Transfer)

• Backend cần hoàn thành trước

>> Vẫn có thể hoàn thành song song giữa FE và BE nhưng phải define rõ từng phần/ nhiệm vụ và trách nhiệm để tránh đùn đẩy việc cho nhau, nhất là khi mọi người không hình dung được mọi người cần làm gì.

• Hãy phân tích rõ cấu trúc thư mục, chi tiết các chức năng, quyền hạn cho từng thư mục trước khi bắt đầu code

>> Có thể sử dụng User Story Mapping để hiểu được từng giai đoạn của user mà chia ra các function cho phù hợp với nhu cầu. (demo)

• Github : hãy quy tắc với nhau các cú pháp push, pull, clone (comment) để quản lý code hợp lý hơn

>> Nhớ pull trước khi sửa một cái gì đó trong local để tránh conflict, tránh tạo quá nhiều branch trùng lắp code

• Hãy tuân thủ các quy tắc của một buổi họp

>> Trước khi bắt đầu buổi họp cần có Agenda( một văn bản trước cuộc họp, thông tin về những gì có trong buổi họp, mình sẽ thảo luận cái gì, bạn bạc gì, có biểu quyết gì quan trọng không, hoặc khách mời là ai và vai trò của họ trong cuộc họp là gì, ...). Kết buổi họp phải có plan cho cuộc họp tiếp theo + meeting minute (bản tóm tắt cuộc họp, có thể là quyết định gì đã được chốt, giải pháp hoặc vấn đề gì đó đã thảo luận xong... văn bản này sẽ được 1 người nào đó được phân công rõ trong mục vai trò của agenda trước đó).

• Backend cần chuẩn bị trước data cho bảng demo

>> Đơn giản là không có data thì demo cái gì ? (đơn giản nhưng dễ bị xem nhẹ)

• Khi lên plan, nên phòng trừ các Event cũng như lịch làm việc của teammate

>> Dù biết đây là trách nhiệm của mọi người (vì đã accept cái plan đó) nhưng tỉ lệ hoàn thành việc trong những hoàn cảnh bất ngờ này sẽ là khó thực hiện hơn, lúc đó sẽ tốn thời gian của mọi người khi phải họp và thay đổi plan nhiều lần.

• Làm gì khi có đồng đội liên tục delay công việc và từ chối trách nhiệm cho một sự cố nào đó.

>> Rõ ràng, không thể thị uy bằng quyền hạn rồi. Giải pháp ở đây sẽ là cần nhìn nhận những mặt mà team có thể khai thác được từ cá nhân đó. Ví dụ: mối quan hệ, tiền bạc, ... Những điều này có thể là sẽ hơi khó nhìn thấy khi đây là lần đầu tiên mà team làm việc cùng, nên vì thế hãy trò chuyện + giúp họ hòa nhập hơn với team thay vì cô lập và thị uy bằng quyền hạn. Còn sau đó thì ....(không có sau đó :> )

=> Mục tiêu chung vẫn sẽ là không làm ảnh hưởng đến kế hoạch mà team đã đặt ra ban đầu.