March 26, 2008 at 4:30 pm · Filed under Lập trình, Ruby
Từ hồi tớ học Ruby, lại bị tiêm nhiễm thêm một thói quen vừa tốt vừa xấu. Đó là khi thực hành giải mấy bài toán vớ vửn đơn giản, tớ toàn bị ám ảnh phải làm sao để code của mình ít dòng, ít chữ cái nhất có thể. Dần dần CodeGolf trở thành chỗ chơi của mình lúc nào không biết.
Thói quen đó xấu, là bởi vì nhiều khi … mất thời gian. Có nhiều bài chỉ mang tính ôn tập lại mấy cái chức năng của Ruby, thì mình lại bỏ ra 1 tiếng đồng hồ vò đầu bứt tai xem có cách nào ngon và ngắn hơn không.
Nhưng từ khi có thói quen đó, thấy đầu óc mình được optimized hẳn. Trước khi làm gì cũng bỏ ra vài trăm mili giây để đánh giá xem có cách nào nhanh hơn không, và nhờ đó mà nhiều khi lại tiết kiệm được thời gian. Quan trọng nhất là nó thay đổi tư duy của mình khi lập trình: đó là có nhiều cách để giải quyết 1 vấn đề, và không có cách nào là ngắn nhất cả, chỉ có cách ngắn nhất tạm thời, hoặc nói chính xác là “cách ngắn hơn”. Kể cả khi tớ tìm được cách để giải 1 bài mà chỉ dùng có 1 dòng code, tớ cũng chả thấy hài lòng: “chắc chắn còn cách cần ít chữ cái hơn”.
Tất nhiên khi lập trình thì có nhiều tiêu chí để nói code của mình đã được “tối ưu hoá” (không kể đến việc phải giải quyết được vấn đề):
- Chạy nhanh nhất.
- Ít dòng code nhất.
- Thuật giải rõ ràng và đẹp.
Gần như không có ai đạt được cả 3 tiêu chí đó 1 lúc cả. Và thường mọi người khi giải quyết vấn đề thường dựa vào tiêu chí thứ nhất và tiêu chí thứ ba nhiều hơn.
Giờ thì tớ muốn nhét thêm cái tiêu chí thứ 2 đó và phương trình của tớ:
code-tối-ưu = nhanh + đẹp + ngắn
Hồi gì học Ruby trên mạng, tớ gặp 1 bài khá đơn giản như sau:
Cho 1 dãy số từ 1 đến 100. In ra lần lượt cho từng số:
- Fizz nếu số đó chia hết cho 3
- Buzz nếu số đó chia hết cho 5
- FizzBuzz nếu số đó chia hết cho 15
- nếu không phải các trường hợp trên thì in ra chính số đang xét.
Bài này có thể gọi là “siêu dễ”. Thế nhưng mà phần lớn dân tốt nghiệp lập trình không giải được bài này (hô hô).
Cách đơn giản nhất là mà phần lớn học viên ở rubylearning.org đưa ra là như sau:
1.upto(100) do |number|
if number % 15 == 0 then
puts 'FizzBuzz'
elsif number % 5 == 0 then
puts 'Fizz'
elsif number % 15 == 0 then
puts 'Buzz'
else
puts number
end
end
Như vậy là 11 dòng code. Có thể gọi đây là bản thô, chưa tinh xảo.
Một học viên khác (Marcos Ricardo) có vẻ đã quen với việc lập trình trong python từ trước, đưa ra lời giải khá là “pythonish” như thế này:
1.upto(100) do |number|
message = ''
message << "#{'Fizz' if(number % 3 == 0)}#{'Buzz' if(number % 5 == 0)}"
puts message.empty? ? number.to_s : message
end
Như vậy là đỡ đi 1 lệnh điều kiện number % 15, vỏn vẹn 5 dòng.
Tớ thích cách này, vì trông nó rất là … nói chung là mã miếc các thứ lằng nhằng trông prồ. Với cả cách sử dụng lồng biểu thức khá là hay. Nhưng liệu mình có làm được cách nào ngắn gọn hơn và hay hơn không nhỉ?
Cùng lúc đó tớ đang học Drupal. Trong Drupal có 1 cái hệ thống xét loại menu item dựa trên thuộc tính khá là hay: sử dụng cờ (flag).
Các thuộc tính của menu item được biểu diễn dưới dạng các hằng, chứa giá trị thập phân tương ứng với các cờ nhị phân. Và mỗi loại menu đều là một tập hợp nhất định của 1 số thuộc tính nhất định. Chỉ cần cộng các cờ nhị phân của các thuộc tính này sẽ xác định được giá trị định nghĩa của mỗi loại menu item.
Áp dụng với bài toán fizzbuzz này, nếu tớ sử dụng 2 cờ là “chia hết cho 3″ và “chia hết cho 5″, thì tớ chỉ cần cộng giá trị của 2 cờ này với nhau sẽ biết được liệu số này có chia hết cho 3, cho 5, cho cả 2 hay không cho số nào cả. Lời giải của tớ cho bài này trong Ruby chỉ có 2 dòng như sau:
a = nil, 'fizz', 'buzz', 'fizzbuzz'
1.upto(100) { |a[0]| puts a[(a[0]%3 == 0 ? 1 : 0) + (a[0]%5 == 0 ? 2 : 0)] }
Dòng đầu tiên tớ định nghĩa “loại” cho các số.
Ở dòng thứ 2, trong quá trình xét từ 1 đến 100, tớ gán luôn số đang xét cho a[0]. Sau đó tớ cộng tổng của 2 cờ a[0]%3 và a[0]%5, và lôi giá trị “loại” của nó ra từ chính mảng a.
Đến lúc này bạn Marcos Ricardo lại có 1 cách nữa, chỉ mất 1 dòng
1.upto(100) {|number| puts "#{'Fizz' if(number % 3 == 0)}#{'Buzz' if(number % 5 == 0)}".empty? ? number.to_s : "#{'Fizz' if(number % 3 == 0)}#{'Buzz' if(number % 5 == 0)}" }
Ngắn thì ngắn thật. Nhưng hơi bị rối mắt. Và mặc dù cho độ ngắn của lời giải này vượt lời giải của tớ, độ “đẹp” và “nhanh” của nó thì không bằng của tớ được.
Đó là bởi vì cách này phải dùng tới 4 lệnh điều kiện, trong khi của tớ chỉ mất có 2. Và nó phạm phải nguyên tắc DRY (Don’t Repeat Yourself - đừng tự lặp lại mình). Lời giải của tớ thì không mắc phải vấn đề như vậy. Nó hoàn toàn không bị lặp lại, và hoàn toàn có thể được mở rộng để đáp ứng được những yêu cầu mới của bài toán nếu có.
Ví dụ như mở rộng thêm điều kiện cho bài toán như sau:
Cho 1 dãy số từ 1 đến 100. In ra lần lượt cho từng số:
- Fizz nếu số đó chia hết cho 3
- Blah nếu số đó chia hết cho 4
- Buzz nếu số đó chia hết cho 5
- FizzBuzz nếu số đó chia hết cho 15
- FizzBlah nếu số đó chia hết cho 12
- BlahBuzz nếu số đó chia hết cho 20
- FizzBuzzBlah nếu số đó chia hết cho 60
- nếu không phải các trường hợp trên thì in ra chính số đang xét.
Giả sử tớ thích dùng cách “thô” (cái cách mà mất những 11 dòng lúc nãy), tớ sẽ phải thêm đến 4 lệnh điều kiện nữa, và độ dài của chương trình khéo phải đến 20 dòng. Và nếu dùng cách “1 dòng” như trên thì chắc phải mất đến 14 câu điều kiện nhồi nhét vào trong 1 dòng đó. Còn nếu dùng cách của tớ? Chỉ mất 2 dòng và 3 câu điều kiện:
a = nil, 'Fizz', 'Buzz', 'FizzBuzz', 'Blah', 'FizzBlah', 'BlahBuzz', 'FizzBuzzBlah'
1.upto(100) { |a[0]| puts a[(a[0]%3 == 0 ? 1 : 0) + (a[0]%5 == 0 ? 2 : 0) + (a[0]%4 == 0 ? 4 : 0)] }
Như vậy có thể coi lời giải của tớ có độ tối ưu hơn so với các lời giải khác cho đến … 1 tuần sau đó, khi tớ khám phá ra bài viết này:
Oh, Go Ahead. Overthink FizzBuzz
Trong đó có lời giải chỉ mất 1 dòng, mà trông vẫn ngắn gọn, chỉ cần 1 lệnh điều kiện:
(1..100).map {|i| srand(1781773465) if (i%15)==1; [i, "Fizz", "Buzz", "FizzBuzz"][rand(4)]}
Hãy nhìn kĩ nhé: srand(1781773465), và tác giả nói tìm ra con số 1781773465 mất 12 tiếng. Để nói thêm về cách làm này, có lẽ cho tớ khất đến một bài viết sau, vì có lẽ nó … quá sáng tạo (đối với tớ) (tất nhiên nếu mở rộng đề bài như tớ nói ở trên thì có lẽ nó hơi bị mất công, nhưng thực sự cách làm này quá sáng tạo và không ai … dám nghĩ đến). Ta sẽ nói đến lời giải này khi tìm hiểu về Pseudorandom number generator (thuật toán mô phỏng tạo số ngẫu nhiên) trong một bài viết sắp tới của tớ nhé 
OK, tớ cuốn xuống phần comment của bài viết, và bắt gặp thêm 1 lời giải 1 dòng nữa, và số kí tự còn ngắn hơn lời giải vừa rồi:
puts (1..100).map{|i|(s=(i%3==0?’Fizz’:”)+(i%5==0?’Buzz’:”))==”?i:s}
I’m speechless!! Sao cách giải đơn giản như vậy mà mình không nghĩ ra!! Và lại còn có bác ngồi mất 12 tiếng để tìm ra con số seed cho hàm random nữa chứ. =))
Và còn đây nữa:
1.upto(100){|i|puts"FizzBuzz#{i}"[i%3<1?0:i%5<1?4:8,i%15<1?8:4]}
Nhìn cách này chỉ muốn đập đầu vào tường! Những cách sáng tạo nhất và ngắn gọn nhất lại là những cách dựa trên những kiến thức cơ bản nhất.
Giờ nhìn lại miếng code 2 dòng mình viết trông thật tội. Áp dụng những cái quá phức tạp cho một bài đơn giản, trong khi có những cách cơ bản khác mà vẫn đạt được độ ngắn như thế. Tuy thế nhưng mà cũng rút ra được khá là nhiều bài học quan trọng:
1. Phải nắm vững lí thuyết và thực hành thành thạo trước khi bắt tay vào làm cái gì.
2. Phức tạp hơn chưa chắc đã là tốt hơn.
3. Nên nhìn nhận vấn đề một cách đơn giản, dựa trên những gì mình đã biết và đã học.
Nghĩ lại thì trò “code 1 dòng” này khá là bổ ích, vì nó vắt kiệt bộ não của lập trình viên và thúc đẩy sự sáng tạo, đồng thời cũng khiến cho việc lập trình trở nên thú vị hơn. Tớ tin chắc là còn có nhiều cách ngắn hơn cho bài này, nhưng có lẽ cũng nên biết điểm dừng thôi nhỉ :P. Tổng thời gian tớ dành ra cho bài toán này:
lời giải đơn giản nhất: 3 phút
tham khảo lời giải của người khác: 30 phút
lời giải 2 dòng: 5 phút
tìm kiếm bài viết liên quan: 30 phút
đọc bài viết và comments của bài “Overthink FizzBuzz”: 30 phút
viết bài blog này: 30 phút
Tổng cộng là 2 tiếng 8 phút 
omfg!
March 22, 2008 at 10:28 pm · Filed under Phần mềm
Tớ có thói quen là đọc được cái gì hay ho, thi thường nhét vào Google Notebook để sau này tiện tra cứu đọc lại. Hôm nào cũng đều đặn tạo 1 Notebook mới với tiêu đề là ngày đó (ví dụ 2008 Mar 22).
Nhưng mà giả sử thấy 1 cái biểu đồ to thế này mà note vào thì … bó tay (click vào).
Hồi trước hình như tớ cũng có lục lọi được 1 cái addon trong firefox tên là ClipIt, hình như cũng take note được hình ảnh. Nhưng mà tớ lại hơi đòi hỏi một chút. Tớ muốn search được cả nội dung bên trong hình ảnh đó. Ví dụ như tớ không muốn bỏ sót cái biểu đồ trên khi tớ search "Google advertising revenue".
Evernote làm được tất cả các thứ này, và còn tuyệt vời hơn. Chỉ có điều hiện giờ nó vẫn đang trong giai đoạn beta và bạn chỉ có thể đăng ký xếp hàng để được họ mời bạn dùng thử bản beta này. Tớ nhận được invitation của họ từ 2 tuần trước, và trong 2 tuần đó tớ không động tay vào google notebook 1 lần nào nữa khi cần ghi chú điều gì mới. Giờ mọi người cùng "lượn" qua 1 vòng xem nó thế nào nhé
Trước hết, Evernote hỗ trợ bạn ghi chú cả online lẫn cục bộ trên máy và đồng bộ với phiên bản online. Có nghĩa là bạn có thể chọn dùng nó cùng với web browser để ghi chú các trang web, hoặc bạn có thể download 1 bản chạy trên máy trạm để ghi chú từ bất kì ứng dụng nào. Sau này khi bạn cần tra cứu lại bạn có thể dùng search engine trên mạng hoặc bằng phần mềm của nó.
Tớ thì tớ down về máy (dùng vista) để chạy. Giao diện khá là đơn giản và thân thiện.
Bạn có thể tổ chức các ghi chú của bạn bằng các tag và các notebook. Đồng thời bạn cũng có thể dễ dàng tìm lại theo ngày tháng thông qua cột phía bên phải. Như vậy nghĩa là tớ chỉ cần 1 notebook và chả cần phải tạo mới cho mỗi ngày nữa.
Nếu bạn có tablet thì việc ghi chú còn dễ dàng hơn. Evernote có chức năng nhận dạng chữ viết trong các hình ảnh, nên bạn có thể dễ dàng tìm kiếm lại các note mà bạn ghi chép bằng tay (tất nhiên là mới chỉ nhận biết được chữ cái tiếng Anh thôi 
).
Còn như cái biểu đồ tớ nói ở trên, các bước take note rất là dễ dàng
Chọn 1 phần (hoặc toàn bộ) biểu đồ sử dụng Clipper của Evernote (nút bên trái để ghi chú đoạn văn bản đang được chọn, nút bên phải để cắt hình ảnh trong khung màn hình hiện tại) .
Sau đó nếu tớ muốn thêm thắt ghi chú bằng tay của mình vào, chỉ cần nhất phím D trên bàn phím, và tha hồ phóng bút.
Chữ tớ hơi xấu nhỉ 
Giờ click vào nút OK của khung Clipper, biểu đồ sẽ được đưa vào Evernote. Tiếp theo chỉ việc thêm tag là xong.
Evernote tất nhiên có thể nhận dạng được cả chữ viết, và bất cứ văn bản nào có mặt trong 1 tấm hình. Giờ nếu tớ quay trở lại cửa số Evernote và search "advertising revenue", biểu đồ này sẽ chình ình hiện ra ngay.
Còn nếu bạn muốn biết đầy đủ các tính năng tuyệt vời của Evernote, tốt nhất nên đăng ký 1 chân để dùng thử bản Beta, và xem clip này
Hạn chế duy nhất của Evernote cho đến giờ mà tớ biết, đó là không chạy được trên Linux. Tất nhiên là bạn vẫn có thể sử dụng web interface của nó, nhưng rõ ràng là chức năng không đầy đủ bằng.
March 12, 2008 at 12:28 am · Filed under Giải trí
Xem cái này mới biết nhiều thằng sáng tạo dã man!
March 10, 2008 at 12:01 am · Filed under Blogging
Bài này là tớ dùng Windows Live Writer để viết. Thực sự bất ngờ vì tính năng đầy đủ của phần mềm này. Bạn chả cần phải vào blog của mình, log in, tìm link post bài và gõ vào cái WYSIWYG của nó nữa. Dùng WLW (Windows Live Writer) bạn sẽ chủ động nhìn thấy ngay bài post của bạn trông như thế nào lúc soạn mà không cần phải truy cập vào trang blog của mình thường xuyên.
Bạn cũng có thể chèn ảnh vào từ ổ cứng mà không cần phải tỉ mẩn upload nó lên trước và căn lề chỉnh lối:
Có nhiều effect và option để bạn hiệu chỉnh cho ảnh của mình trong bài viết:
Bạn cũng có thể cài thêm một vài plug-in nữa để thêm tính năng sửa bài. Ví dụ ảnh sau là được xử lý bởi plugin Polaroid:
Các tính năng sửa bài của Wordpress đều đủ cả:
Và còn nhiều tính năng hay ho nữa. Bạn có thể tìm hiểu cách cài đặt và sử dụng tại viettut.info.
March 8, 2008 at 1:35 pm · Filed under Lập trình, Software Engineering
Một trong những cái đau đớn nhất của việc làm việc theo nhóm, đó là: phải làm cùng 1 chú leader gà con đầu óc rỗng tuếch và quan liêu.
Điều đau đớn thứ hai, đó là khi mình thẳng thắn chỉ ra chỗ sai của hắn, thì những thằng cùng nhóm khác bỏ ngoài tai và quay ra liếm đ’t thằng leader.
Cũng phải công nhận mình chả giỏi giang gì nên mới sa chân vào những cái nhóm làm việc như thế, và cũng chả phải thằng có tinh thần teamwork lắm khi hay chê bai chỉ trích đứa khác. Tự làm mọi thứ 1 mình thì lại thấy workload quá lớn mình không kham nổi. Qua lần này rút ra một vài kinh nghiệm về làm việc nhóm.
Nếu bạn được chọn làm leader:
- Luôn nhớ rằng “you are leading people, not managing them”. Thử đặt mình vào vị trí 1 thằng developer, sẽ rất khó chịu khi bị chú leader không có trình độ chuyên môn mà cứ áp đặt những cách làm rất trâu bò và thiếu mềm dẻo cho mình. “Leader” khác “manager” ở chỗ, leader cần trình độ chuyên môn cao hơn, biết nhiều về chi tiết kĩ thuật hơn, và thực sự xét về mặt quyền lực thì ngang hàng với các thành viên khác, chỉ có thêm trách nhiệm “dẫn đầu đàn” và “điều phối hoạt động” cho toàn nhóm. Mọi quyết định là do đa số trong nhóm cùng nhau nhất trí, chứ không bị áp đặt bởi một ai cả.
- Vấn đề deadline cần được đối xử một cách tế nhị, nhất là đối với một project dính dáng đến phần mềm, ứng dụng web .v.v. Gia công phần mềm nó khác với việc “đánh cho xong bản report” hay “thắt cà vạt trong vòng 30 giây”. Bạn chỉ có thể đặt ra các mốc thời gian dự định mềm dẻo, chứ khó có thể kiểm soát được một hạn định cụ thể cho một dự án dù nhỏ hay to. Trên thực tế, việc cho ra sản phẩm chậm hơn hạn định dự kiến 3 tháng - 6 tháng là chuyện bình thường, và thậm chí đã có thể coi là “best practice”. Đó là do trong quá trình gia công, không thể lường được hết các thay đổi về mặt kĩ thuật, cũng như lỗi chương trình .v.v. Không nhận thức được điều này, và o ép các thành viên cùng nhóm khác phải hoàn thành trước deadline dĩ nhiên sẽ dẫn đến thất bại của dự án.
- Nếu được phép lựa chọn thành viên, thà chọn ít nhưng chất lượng còn hơn chọn nhiều mà thằng nào cũng làng nhàng. Tớ bị rơi vào hoàn cảnh này nhiều lần. Ghét nhất là phải học lớp nào mà thày không cho chọn nhóm, mà chỉ định nhóm cho từng thành viên. Kết quả là vào toàn nhóm ất ơ. Một nhóm có 6 đứa chẳng hạn, thì 3 đứa là “free rider” (cùng nhóm cho lấy lệ, chứ chả đóng góp gì sất!). Cuối cùng thì cả đội chán nản và một mình mình phải è cổ ra làm hết phần của bọn nó, hay nói cách khác là biến thành “servant” chứ chả phải “leader”. Hiện tại đang làm 1 cái project lèm nhèm của 1 đứa châu Phi nó lead. Do không có hiểu biết về chính lĩnh vực của cái dự án, nên nó toàn lôi bạn bè vớ vỉn vào, rồi chia 2 nhóm, 1 nhóm design (trong đó có thằng lít đờ) và 1 nhóm coder cho trang web. Trong khi mấy cha coder è cổ ra đọc documentation và “vừa xây vừa phá vừa sửa”, thì mấy ông designer thiết kế 1 cái logo mà tớ dùng paint tớ còn vẽ được đẹp hơn, rồi dựng ra 1 cái layout cho trang web mà trông như blog của mấy bạn 9x và cứ nghĩ chỉ việc thay image cho cái default theme của drupal là mọi thứ sẽ hiện ra như ý muốn. Nhưng đâu có đơn giản thế! Cuối cùng việc code cái template rồi lại sẽ phải vào tay bọn coder thôi!
- Gạch đầu dòng cuối cùng, và cũng là quan trọng nhất: Nếu không có trình độ kĩ thuật bằng bọn cùng nhóm, thì nên tập cách lắng nghe. Xét cho cùng thì nếu trình độ không bằng bọn khác thì cũng khó mà có thể đảm đương làm leader được, vì nói chả ai nghe. Nếu muốn người khác nghe mình, thì phải nghe người khác nói trước đã. Hồi trước tớ đọc trong Rich dad Poor dad, có ví dụ về ông Ford. Tớ cũng chả nhớ rõ chi tiết lắm, nhưng đại loại là có người chê Henry Ford (sáng lập ra hãng xe ô tô Ford) là giàu thì có giàu thật, nhưng trình độ văn hóa chưa quá lớp 3. Thế là Ford mới thách người kia hỏi bất cứ câu gì ông cũng trả lời được. Và khi được hỏi về lĩnh vực nào, Ford liền mời cố vấn của mình về vấn đề đó ra giải đáp đâu ra đấy. Tóm lại là, leader giỏi không hoàn toàn đòi hỏi trình độ kĩ thuật phải cao hơn người khác. Mà cái quan trọng là biết chọn người giỏi làm việc cùng mình, và biết nghe ý kiến của người ta, chứ không phải lúc nào cũng coi mình là nhất, và mọi người phải theo ý mình. Chả ai muốn bị một thằng dốt hơn mình giật dây cả.
Còn nếu bạn không phải (hoặc không muốn) làm leader, sau đây có lẽ là vài lời khuyên cho bạn khi phải làm việc theo nhóm:
- Biết nói “không” khi cần thiết. Nếu bạn được mời vào làm cùng một project hứa hẹn lương lậu các thứ rất hấp dẫn đến mấy, nhưng nhìn vào đội hình các team mates mà khấp khểnh, thì nên cân nhắc kĩ trước khi đồng ý. Đến lúc “sa chân vào vũng lầy” không rút ra được, thì bạn sẽ bị dằn vặt vì đã để mình phí thời gian vào nhưng thứ vô ích và vì cảm giác mình bị kẻ khác lợi dụng.
- Biết thẳng thắn đưa ra ý kiến của mình và chả phải sợ bố con thằng nào cả. Nếu bạn gặp leader giỏi, ý kiến của bạn tức khắc được trân trọng dù đúng hay sai. Còn nếu gặp leader tồi, thì lại càng phải thẳng thắn, vì càng thẳng thắn thì cơ hội bị “đá đít” ra khỏi group càng cao. Và khi bị đá đít ra rồi thì bạn rảnh tay để làm việc khác mà không lo gì về trách nhiệm đối với group cũ cả. Hơn nữa thẳng thắn là đức tính tốt, còn “nói lươn nói lẹo”, ba phải cho vừa lòng kẻ khác thì là một biểu hiện của sự hèn nhát.
- Luôn có tinh thần học hỏi người giỏi hơn, và giúp đỡ người kém hơn. Sẽ chả phải hay ho gì nếu bạn chỉ ngồi một chỗ và than trời vì group của bạn toàn thằng kém hơn mình. Tốt nhất là nên xắn tay lên và giúp đỡ họ giỏi hơn bằng mọi cách có thể. Còn nếu bạn là “chú gà con xấu xí” trong nhóm, thì cũng chả việc gì phải mất tự tin. Nếu bạn không tỏ ra kiêu kì và bảo thủ, người giỏi hơn sẽ sẵn lòng chỉ dạy cho bạn. Nếu biết tiếp thu những cái giỏi và lọc ra những cái sai thì chả mấy chốc mà bạn giỏi bằng hoặc hơn người ta.
- Đừng ôm đồm trách nhiệm, chỉ cần làm tốt phận sự của mình và giúp đỡ người khác đúng mức. Nếu công việc của bạn được giao là “code cái template”, thì cứ code cho tốt cái đã. Còn nếu các thành viên khác không chịu làm việc, thì cũng chả việc gì phải lo lắng để mà làm hết các phần việc khác cho bọn nó. Chuyện thất bại là chuyện bình thường, và chả có gì đáng xấu hổ cả khi bạn đã cố gắng hết sức cho phần việc của mình. Tớ thì tớ thường hay lo bọn cùng nhóm nó không chịu làm việc, kéo điểm của mình xuống. Nên cuối cùng toàn là tớ lo việc type cái report, làm cái powerpoint và viết sẵn cái script cho bọn kia nó đọc lúc presentation. Nhưng từ giờ nhất định chả phải coi nặng chuyện điểm chác nữa, chỉ làm phần việc của mình, thời gian còn lại để làm việc khác có ích hơn.
Còn đây là một vài lời khuyên chung cho cả leader lẫn thành viên bình thường:
- Chỉ nên nêu ý kiến khi mình thật sự có kiến thức về những cái mình định nói. Nếu ba hoa bốc phét về một vấn đề mà mình không biết chắc thì sẽ làm giảm uy tín của bản thân, sau này nói chả ai muốn nghe nữa.
- Luôn có tinh thần tích cực khi tham gia. Không nên bàn lùi hay quá bi quan về tiến độ của dự án.
- Trong đầu luôn phải tính toán cả những trường hợp xấu nhất (thất bại). Nếu bạn chưa lo xong các vấn đề nền tảng thì đừng nghĩ ngay tới việc quảng cáo cho sản phẩm khi thực sự chưa làm ra được nó. Và đừng quá nghiêm khắc khi kế hoạch của bạn thất bại, mà nên nhìn lại vấn đề một cách tích cực, đưa ra nhận xét và rút ra bài học.
- Tìm và thống nhất phong cách làm việc phù hợp nhất. Ví dụ như nếu các thành viên nhà ở xa nhau, hay không thể xếp lịch cho meeting được, thì nên tìm phương cách khác để communicate với nhau, ví dụ như sử dụng bulletin board, instant messenger .v.v. Có rất nhiều web app hỗ trợ project management miễn phí. Không phải cứ lúc nào cũng mặc vest và dắt díu nhau đi họp một cách formal là tỏ ra chuyên nghiệp. Chuyên nghiệp hay không là ở năng suất, không phải do hình thức.
- Và lời khuyên cuối cùng: tốt nhất hãy làm sao để bạn có thể hoàn thành công việc một mình, hoặc cùng lắm thì chỉ cần group nhỏ (dưới 4 người). Nếu bạn đang chuyên về flash chẳng hạn, thì hãy cố mở rộng sang web designing bằng XHTML/CSS, rồi theming in Drupal, Joomla, Wordpress .v.v. và cố master ít nhất 1 ngôn ngữ lập trình web nữa. Tất nhiên làm việc được một mình là trường hợp lí tưởng, còn không thì cùng làm với vài ba người thân cận nhất mà bạn tin tưởng được. Càng cho thêm các thành viên mà độ tin cậy chưa cao thì rủi ro của dự án lại càng lớn.
Tớ kết lại bài viết này bằng câu sau, trích trong bài phỏng vấn với Steve McConnell khi nói về software engineering, ý nghĩa thì cũng quá rõ ràng rồi nhỉ
a quarter of the projects are canceled before they’re completed and another 50 percent are completed over budget or behind schedule. And 25 percent are completed on time and on schedule, but the piece that’s always missing from those surveys is how much of the original functionality was delivered in that 25 percent that was on time and on budget.
Next entries »
