Helu mọi người, nhìn tới nhìn lui thì sắp hết năm rồi, thời gian qua nhanh như chó chạy ngoài đồng, hết năm này cũng là thời điểm kỉ niệm 1 năm mình bước chân vào "nghề" lập trình freelance. Kiểu kỳ này crazy vler ấy vừa làm công ty, vừa làm freelance, vừa làm đồ án tốt nghiệp, còn học nốt 3 môn :v Theo cái plan năm tới của mình là đi làm full time, thời gian rảnh nâng skills chuyên môn cũng như ngoại ngữ thì có vẻ như khả năng cao là mình sẽ không làm freelancer nữa. Vì vậy, tối chủ nhật hôm nay rảnh rỗi note ra một số quan điểm cá nhân mà bản thân mình rút ra được sau 1 năm "hành nghề". Nghe tới con số một năm thì chắc nhiều ông đang nghĩ ít vler chia sẻ cc nhỉ :v . Nhưng mà thôi méo mó có hơn không, bài viết này coi như note cá nhân hoặc cho các bạn đang có ý định làm freelance đọc cũng được.
Sau đây là 7 quan điểm mình rút ra được sau quãng thời gian làm freelancer.
1. Không bao giờ được phá giá
Tại sao mình lại đưa quan điểm này lên trên đầu, bởi vì phá giá đang là cái thực trạng nát nhất của ngành freelance ~~ Lướt những group lập trình, code thuê có thể thấy chi phí làm một dự án ở đây rẻ hơn từ 1/2 cho tới 1/10 cái giá thực mà đáng lẽ dự án đó có thể nhận. Mặc dù khách hàng tìm kiếm bên triển khai dự án công nghệ vẫn biết là "tiền nào, thì của nấy" thôi nhưng khách thì không muốn hoặc không có khả năng chi trả, freelancer thì toàn ông sinh viên làm kiếm thêm được đồng nào hay đồng ấy, lại còn source sẵn thì đầy, tool tạo thì tràn lan, những dự án thuộc dạng phổ thông chắc không cần code, mua source hay dùng công cụ chắc là song, lấy rẻ rẻ làm xong bàn giao xong là quit thôi. Việc này lâu dần biến chất lượng cũng như giá thành của lập trình viên freelance rơi xuống vực, giá rẻ thì lấy đâu chất lượng cao, không những thu nhập giảm mà chất lượng cũng giảm luôn 
( càng lâu càng nguy hiểm. Nếu muốn nâng giá trị bản thân thì cố gắng không được phá giá nữa, khách bảo giảm X triệu anh em mình vào việc luôn thì hãy nhớ mình cũng có cái giá của mình chứ :v
2. Không bao giờ được deal giá trên khả năng của team hoặc yêu cầu dự án
Nghe có vẻ ngược lại với quan điểm bên trên, nhưng với cá nhân mình vẫn đúng. Tưởng tượng khi ngồi deal với khách hàng mà ông anh bên kia luôn miệng kiểu: "tiền bên anh không thiếu, cứ đúng chức năng đúng thời gian thì nhiều cũng oke em ạ", "dự án này cần nhanh, tiền không phải vấn đề, em cứ cho anh báo giá anh gửi kế toán là xong luôn", ... bla bla. Đấy ngồi nghe mấy anh chém thế thì ai chẳng thích toàn nghĩ trong đầu con số trên trời, toàn kiểu tiền của công ty anh kia chứ có phải của anh kia đâu mà mình lo, cao lên. Việc deal giá trên khả năng của team bạn hoặc trên chất lượng dự án sẽ mang lại một số hệ lụy sau:
- Khiến bạn bị atsm về khả năng: Việc deal cao thành công một vài dự án sẽ khiến bạn bị atsm về khả năng cũng như giá thành của những dự án về sau. Điều này làm cho bạn rất khó sinh tồn ở thể giới freelance nơi mà một dự án chục team báo giá, hơn nữa khi rời xa con đường freelace deal lương full time ở những công ty sẽ khiến bạn bị offer kiểu ngáo giá, việc này khá là nguy hiểm
- Không đảm bảo được chất lượng dự án: Một dự án tiền không phải vấn đề thì chắc chắn vấn đề sẽ tới từ chỗ khác, những dự án như thế này thường là khách khá sốt ruốt muốn sản phẩm xong nhanh nhất có thể những vẫn ngon với lại nhiều chức năng, deadline được đẩy vào liên tục, tính năng thêm bớt như cơm bữa, tính năng khó kiểu gì cũng có, đa phần các đội freelancer kĩ năng thường không cao, có ít kinh nghiệm sử lý task khó sẽ bị ngợp ở đây, dự án đã run được một thời gian rồi, bỏ đi thì không được mà gồng tiếp thì mệt vler, bạn sẽ hối hận là đáng lẽ lúc đầu nên deal giá phải chăng với một plan phù hợp, estimate deadline vừa sước thôi chứ
- Vỡ hợp đồng thì cũng vỡ mồm: Dự án chi phí cao, mà lại đòi làm nhanh nhưng chất lượng phải tốt, bên triển khai thích tiền nên nhận nhứ cũng không có nhiều thứ để đảm bảo sẽ hoàn thành yêu cầu của bên khách hàng, thì sẽ có cái tỉ lệ nào đấy mà team bạn bị "vỡ hợp đồng" (kiểu như đền hợp đồng ý) vi phạm cái gì đó, hay bug gì siêu to trên môi trường production, lúc ấy đen lắm thì phải điền tiền bằng tiền hợp đồng, mà thường thường thì dự án tới giai đoạn thanh lý hợp đồng hoặc run production rồi thì gần như tiền hợp đồng team chắc tiêu cũng hết rồi :v thôi gom lại mà trả thôi
3. Luôn yêu cầu cọc và luôn đòi nốt tiền dự án vào lần nghiệm thu thứ 2
Này trước mình đã luôn bị ám ảnh bởi những dự án mà báo giá lên xuống, em cứ bắt đầu làm đi, sang tuần là giải ngân thôi. Xong rồi kiểu sang tuân bùng kèo, hoặc yêu cầu chốt nó khác một trời một vực với yêu cầu đưa ra lúc tuần trước. Ơ thế công sực làm từ lúc lấy yêu cầu tới giờ vứt đi à? Còn chưa kể bao bị kiểu đi báo giá dạo ý, báo giá không phải là đưa con số đâu mà là một bản các tính năng lơn, tính năng con, màn hình, estimate giá, estimate thời gian làm mất mịa nó một buổi chứ ít đâu. Xong rồi có những dự án mà kiểu như không bao giờ được release ấy, kiểu mà sửa lên sửa xuống, sửa trái sửa phải nhưng khách vẫn chưa oke, những lúc kiểu này bực vler. Sau bao lần tự nhủ phải làm gì đi cho xong đi chứ thì mình đã rút ra là:
- Nhất định phải lấy cọc và dự án sẽ chỉ bắt đầu triển khai sau khi đã nhận cọc thôi: Tránh tình trạng báo giá dạo này code dạo như bên trên có đề cập ấy, tiền cọc tùy kinh tế cũng như độ thân thiết giữa team bạn và khách (giao động khoảng 30-50%)
- Bắt buộc phải lấy nốt tiền vào lần nghiệm thu thứ 2: Là sao? Khi phát triển sản phẩm theo agile thì thường 1-2 tuần sẽ deploy tính năng mới cho khách xem và góp ý một lần, cái này oke không sao, nhưng chỉnh sửa vô lý quá thì estimate thêm thời gian, chỉnh sửa không có trong hợp đồng thì estimate thêm tiền. Cứ thế tới lúc sản phẩm hoàn thành thì nghiệm thu lần 1 (kiểu bàn giao lần 1 ấy) lúc ý cho khách một khoảng thời gian chính xác (mình tường để 1 tuần) và cho khách 1 cái file excel. Để làm gì? Khách test chán đi rồi tất cả những yêu cầu chỉnh sửa, cập nhật của cả dự án note hết vào file excel đó (kiểu gì đó cũng sẽ là một file dài vler) nhưng càng dài thì càng tốt càng chứng tỏ khách quan tâm tới việc sản phẩm phải hoàn thành. Sau khi nhận file excel động thái của team bạn nên là đòi nốt tiền của dự án trước khi triển khai chỉnh sửa theo file excel đó. Để làm gì? Như mình nói bên trên ý tránh tình trạng sản phẩm mãi mãi không thể release thì mình phải giúp khách hàng quyết đoán khoản sửa cái gì thành cái gì và phải nghiêm túc với quyết định ấy, chịu trách nghiệm với những quyết định ấy bằng chi phí cơ hội, nếu khách không thanh toán, quyết đoán rằng sản phẩm sẽ bỏ ngỏ lại thôi. Nghe thì có vẻ tiêu cực nhưng việc này sẽ giúp cả bên mình lần bên khách hàng. Tránh những đòi hỏi vô lý cũng như sửa tới sửa lui không cần thiết, những sửa đổi tời từ logic nghiệp vụ thì nên trải qua những đo lường
4. Estimate chi tiết tới đâu lúc làm đỡ khổ tới đó?
Bên trên có nói về cái báo giá, cái ấy chính là estimate của bạn tới dự án này, hãy làm nó thật sự chi tiết. Để làm gì? Để lúc làm bớt khổ, không bị rơi vào tình trạng kiểu "Ơ, chức năng abc, xyz không có à em?", "Chức năng này không phải thế này đâu, thế này mới đúng cơ", ... bla bla hoặc tránh trường hợp deal dự án làm trong 1 tháng nhưng 1 tháng ấy vì bị push thêm nhiều "tính năng này dễ lằm không tốn thời gian đâu" nên bị vỡ deadline nữa. Hoặc là kiểu cùng một tính năng nhưng chi phí web cỏ yêu cầu chất lượng google ấy. Thì file báo giá của team mình thường cực kì chi tiết, tưởng là file excel với các cột sau:
- Hệ thống: Đây gần như là số lượng hệ thống độc lập phải giải quyết, tường là các role lớn không liên quan đến nhau (kiểu người mua, người bán chẳng hạn)
- Chức năng lớn: Mỗi hệ thống sẽ có những chức năng lớn đây là những chức năng lớn của hệ thống, thường thì đọc những mục này là biết hệ thống làm gì cho phía backend, là những mục lớn trong menu của phần front end
- Màn hình: Mỗi chức năng lớn sẽ có những màn hình bên trong, mỗi màn hình gần như sẽ làm một việc cụ thể (kiểu như tạo sản phẩm, xem danh sách đơn hàng) Số màn hình sẽ giúp khách hình dung được hình dạng của hệ thống họ sắp nhận được cũng sẽ giúp team ước lượng được quy mô của dự án
- Khối trên màn hình: Mỗi màn hình sẽ có nhiều khối mà mỗi khối phải được nêu tên cụ thể cũng như tính chất của nó (Kiểu như màn hình thêm sản phẩm sẽ có input tên, giá, có upload ảnh, bla bla)
- Luồng quan trọng: Luồng quan trọng sẽ ngang hàng với chức năng lớn vì mỗi chức năng lớn sẽ chỉ có một vài luồng quan trọng thôi, những luồng này thường là logic cốt lõi của hệ thống mà khách sẽ mô tả theo kiểu non tech mĩnh sẽ phải biến no thành ngôn ngữ mà khách cũng đọc được, team cũng đọc được)
- Thời gian ước tính: Thời gian ước tính (thường bên mình sẽ làm theo màn hình hoặc chức năng lớn) là thời gian dự tính sẽ hoàn thành chức năng đó, đây cũng là cơ sở để báo khách thời điểm nào thì sẽ sẵn sàn cho tính năng nào, cũng là một cái để lúc triển khai không bị kiểu quy luật 80/20 (80% thời gian đầu chơi đã rồi 20% cuối vắt chân lên mà chạy)
- Giá tiền: Cái này khả quan trọng nhé, estimate đến cỡ màn hình là đẹp (thường thì sẽ bị một chút ngược đời là các ông sẽ cầm số tiền mong muốn của dự án chia cho màn hình rồi điền vào) cái này thì không nên, vì mỗi màn hình sẽ phải bỏ công sức sử lý là khác nhau hơn nữa là độ quan trọng cũng sẽ khác nhau. Nhiều trường hợp thực tế là khách cầm báo giá đọc xong muốn giảm chi phí nên sẽ loại bỏ màn hình cũng như chức năng phụ, lúc này bạn nhận ra là để mấy cái màn dễ dễ bằng giá với màn khó khó (ơ lỗ à?)
- Chốt lại hàng cuối là tổng tiền với tổng thời gian nhé, mấy cái chi phí khuyến mãi đi kèm cũng ghi nốt phía cuối (kiểu như tên miền hay máy chủ)
5. Chỉ làm những chức năng mà khách thực sự cần
Mấy ông làm freelancer có tâm toàn kiểu như skill có đến đâu mang đến đấy ra làm mới bõ, cái này cái kia đã lẽ không cần nhưng phải bỏ vào mới thể hiện được năng lực của mình, hiệu ứng các thứ phải tung trời, overnight làm mấy cái bay bay bắt mắt vler. Xong lúc bàn giao khách kiểu: "Mấy cái này anh không cần đâu, anh muốn có đơn giản thôi, bỏ đi cho anh". Ơ ngon, ai bảo rảnh quá làm gì. Làm freelance chỉ làm những chức năng mà khách cần thôi, làm chức năng mà khách không cần thì khách sẽ không biết ơn, hơn nữa nếu có lỗi trong những chức năng được thêm thắt đó vào thì phản tác dụng nhé, không những không được cảm ơn mà còn bị chửi.
6. Luôn liệt kê đầy đủ những dịch vụ khuyến mãi, đi kèm
Nhiều khi khách không lường được mức độ phức tạp của dự án, hoặc không biết được những tiểu tiết đi kém, và bạn cũng không muốn giải thích cho khách vì sợ giải thích khách cũng không hiểu nhưng mà đây là một việc không nên. Tất cả những chức năng mình mất công mình phát triển, hoặc chi phí bên là mình mất tiền mình bỏ ra thì đều cần được liệt kê một cách rõ ràng, những chức năng tiểu tiết kiểu quên mật khẩu hay là xác nhận email nếu bạn không nói khách cũng không biết, nhưng nếu liệt kê thì sẽ rất nhiều, và mình phải làm bằng thật thì cũng phải liệt kê đầy đủ để khách có cái nhìn tổng quan nhất về quy mô dự án, tránh tình trạng lúc nào cũng nghĩ dự án này có gì đâu, đăng hàng lên bán được là được. Hoặc những chi phí bên lề kiểu mua ssl, hay dịch vụ bắn email, ... dự án nhỏ thì chẳng đáng mấy nhưng liệt kể ra rồi chỉ cho khách biết đây là tặng kèm theo dự án thì khách sẽ rất oke đó.
7. Phải có lịch cố định họp trực tiếp của team
Teamwork có hiểu nhau tới đâu, chia công việc hợp lý tới đâu thì lúc phát triển vẫn sẽ có những khúc mắc hoặc hiểu lầm về chức năng mà chỉ có gặp trực tiếp mới giải quyết được, làm sao để những phần việc của mỗi thành viên work được với những thành viên khác nhiều khi cũng là những câu chuyện trừu tượng mà phải ngồi cạnh nhau mới ra vấn đề. Hơn nữa để đảm bảo được deadline chung, keep được tiến độ chung thì lịch họp offline của team cần được rõ ràng và cố định cái này không áp dụng cho mấy ông một mình một ngựa cân dự án hoặc nhưng team ở cùng nhau như team mình đâu nhé 
Viết đến đây mỏi tay vler mà cũng không nghĩ thêm được gì nữa ( chắc stop ở đây thôi, freelance là một nghề khá hay không những giúp kiếm thêm thu nhập linh hoạt cho các bạn sinh viên hoặc ngoài giờ làm mà còn nâng skill khá tốt, hơn nữa lâu dần sẽ có một network khá oke có thể tiến tới làm freelance full time, nên bài viết này dành cho những bạn có ý định làm freelance thôi ạ.