เรื่องเล่าต่อจาก รายงานพิเศษ: Thai Programmer Crisis (แบไต๋ไฮเทค)

จริงๆ ผมพูดและนำเสนอความคิดในรายงานนี้ไปเยอะนะ แต่คงเพราะเวลาในการออกมีน้อยเพียง 5 นาที แถมมีส่วนที่ทำสรุปไว้แล้ว เลยได้ออกบางส่วนไม่ได้ทั้งหมด ผมเข้าใจได้นะ เพราะประเด็นมันเยอะมาก จนคนมานั่งฟังคงร้องบอกว่า “เออ พอเหอะ กูเข้าใจแล้ว”

ปัญหาเรื่องนี้มันมีหลายมิติ คุยกันทั้งวันก็ไม่จบ แถมจะกลายเป็นมานั่งปรับทุกข์ชีวิตสายวิชาชีพนี้กันเปล่าๆ

ส่วนตัวผมคิดว่าเพราะขั้นตอนวิธีการพัฒนาซอฟต์แวร์ในไทยโดยบริษัททั่วไป ยังไม่มีความชัดเจนและแนวทางในการทำงานที่เป็นมาตรฐาน ใช้การลองผิดลองถูกกันเยอะ หรือใช้มาตรฐานวิธีการทำงานจากงานแนวๆ สายอาชีพอื่นมาใช้ ซึ่งก็อาจจะออกแนวดันทุรังให้จบๆ ไปได้ แต่สุดท้ายงานก็ตกอยู่กับคนระดับปฎิบัติงานด้านล่าง (ข้อมูลนี้ได้มาจากเพื่อนๆ ในสายอาชีพผมหลายๆ คนที่มานั่งปรับทุกข์กันอยู่เรื่อยๆ)

ส่วนตัวผมเจอเพื่อนๆ ที่เขียนโปรแกรมเข้าขั้นใช้ได้ตอนเรียนจบ ซึ่งในรุ่นผมค่อนข้างหายากอยู่แล้ว แต่สุดท้ายก็ไม่ทำงานสายนี้ ไปสมัครเป็นทหาร ไปเป็นพ่อค้าขายมะลิ ขายข้าวแกง หรือไปขายหมูปิงก็มี เพราะสบายกว่า เสียสุขภาพน้อยกว่า ทำงานจบวันนึงก็คือจบ กลับบ้านอยู่กับครอบครัวแล้วไม่โดนตามงานตอนดึกๆ แถมเงินที่ได้ก็ไม่หนีกันมาก (หรืองานบางตัวก็รายได้ดีมากๆ) ซึ่งตรงนี้เป็นเรื่องที่ถ้าไม่ลองก้าวออกจากสายอาชีพนี้เพื่อนๆ ผมเค้าอาจจะไม่ค้นพบความสุขในแบบที่เค้าต้องการ (ส่วนผมยังสนุกกับการแก้ไขปัญหาอยู่ ไม่แน่ใจว่าหมดไฟเมื่อไหร่ ฮาๆๆๆ)

บางครั้งมันไม่ใช่เรื่องค่าตอบแทนและสภาพแวดล้อมการทำงานอย่างเดียว แต่อาจจะอยู่ที่วิธีการทำงาน ที่สร้างความภาคภูมิใจในฐานะคนที่สร้างงานเหล่านั้นขึ้นมาด้วย หากแต่คนที่จ้าง คนที่สั่งงานไม่เห็นคุณค่าในฐานะคนสร้างงานแล้ว ก็ยากที่จะทำให้พวกเค้าเหล่านั้นทำงานให้เราได้เต็ม 100% (หรือมากกว่า) เมื่อคนเหล่านี้หมดความภาคภูมิใจในการทำงานนั้นๆ ผมคิดว่าก็ไม่มีใครอยากอยู่ในวิธีการทำงานนั้นๆ และอาจะลากยาวไปถึงชีวิตในสายอาชีพนี้ ที่วันๆ ถูกกดอยู่ในความไม่ภาคภูมิใจในตัวเองสักเท่าไหร่หรอกครับ

แน่นอนว่าขึ้นชื่อว่า “ไอที” โลกของมันมีการเปลี่ยนแปลงอยู่ตลอดเวลา เพราะฉะนั้นงานสายงานอาชีพนี้ต้องพัฒนาตัวเองตลอดเวลา ไม่ใช่อยู่ไปวันๆ ได้ ส่วนตัวผมเองนั้น ทุกๆ วันหลังจากทำงาน ก็ต้องมานั่งอัพเดทตัวเอง เพื่อหาวิธีการแก้ปัญหาใหม่ๆ ที่ดีมากขึ้นหรือต้องเช็คว่าตัวซอฟต์แวร์ที่เรากำลังพัฒนาอยู่นั้น ในบางส่วนของระบบมีช่องโหว่หรือความผิดพลาดอะไรหรือไม่จากการเจอ bug จากส่วนพัฒนาที่ต่อยอดออกมา และรวมไปถึงแนวคิดใหม่ๆ ที่ทำให้เราทำงานได้ง่ายมากขึ้น ซึ่งทำให้งานนั้นออกมาเร็วทันใจลูกค้าด้วย

สุดท้าย นี่ไม่ใช่การบอกว่าสายอาชีพนี้ทำงานหนักที่สุดในโลกหรอก โลกนี้ยังมีงานอีกมากมายที่หนักกว่านี้เยอะ รับความเสี่ยงมากเดี่ยวเช่นกัน แต่นั้นไม่ใช่หมายความว่าเราจะไม่เอาปัญหาของสายอาชีพของเราออกมาตีแผ่หรือมานั่งคิดว่า “ทำไม” มันถึงเกิดปัญหาขาดแคลนหรือคนไม่อยากทำงานในสายอาชีพนี้ เพราะถ้ามันมีปัญหาและไม่ตีแผ่ออกมาแล้วซุกมันไว้ มันก็จะเป็นอย่างเดิม (เหมือนมี bug แต่ไม่ยอมแก้ ปล่อยๆ มันไปแบบนั้น) ผมเชื่อว่าถ้าสายอาชีพอื่นๆ อยากทำบ้าง ก็ต้องดิ้นกันไปตามช่องทางที่ตัวเองมีครับ

ผมเชื่อว่า “กรรมกรไอที” ไม่ได้เกิดมาเพราะคิดขึ้นเองโดยใครคนใดคนหนึ่ง แต่ถูกจัดตั้งโดยกลุ่มคนที่เห็นด้วยกับคำนี้จริงๆ นับตั้งแต่อดีตจนถึงปัจจุบัน และผมเชื่อว่ามีคนยังคิดแบบนี้ในอนาคตแน่ๆ

เอ้าาาา เอาเหอะ บ่นไปแล้วก็ทำงานกันต่อครับ อย่าไปคิดมาก ปัญหามันต้องแก้ไข ไม่ใช่ซุกไว้แล้วบอกว่า “ก็มันยังทำงานได้ปรกติดีนิ” ซึ่งมันไม่ใช่วิถีคนสายอาชีพของเรามั้งครับ และส่วนตัวผมยังอยู่ในสายอาชีพไอทีที่ยังใช้วิถีและวิชาที่ได้จากการเป็นโปรแกรมเมอร์อยู่เรื่อยๆ ทุกๆ วัน เพราะตอนนี้ไม่ได้นั่งโค้ดมันอย่างเดียวเท่านั้นแล้ว แต่ต้องเป็นได้มากกว่านั้นเพื่อเพิ่มมูลค่าของตัวเองตามแนวทางคนทำงานด้านไอทีที่เปลียนแปลงอยู่ตลอดเวลาครับ ;)

ส่วนเรื่องสาวๆ ในสายอาชีพนี้เนี่ย ออกแนวเฮฮา แซวกันเฉยๆ คือไม่มีใครคิดกันจริงจังมากมายจนเป็นปัจจัยในการเลือกหรือไม่เลือกทำงานในสายอาชีพนี้เท่าไหร่หรอกมั้ง -_-”

ด้านล่างวิดีโอตัวแรกนี่ดูดีมากสำหรับ Software Engineer เลยนะ นี่มันโลกความฝันที่หาได้ยากในบ้านเราครับ

Day in the life…Software Engineer

แบไต๋ไฮเทค – รายงานพิเศษ: Thai Programmer Crisis

เป็น Programmer/Developer งานมันเครียด

อาชีพ Programmer กับ Developer งานมันเครียด พาลเส้นเลือดในสมองจะแตกตาย ได้ง่ายๆ จะตายโดยไม่ได้ใช้ตังเนี่ยแหละ

หลังๆ เลยพยายามให้วันอาทิตย์คือ 1 วันใน 7 วันที่พักจริงๆ จังๆ ไม่ยุ่งกับงานเลย (ถ้าไม่ critical ระดับระบบล่ม มี critical bug นะ) คือได้พักวันนึงเต็มๆ นั่งอ่านโน้นนี่ ลองของไปเรื่อยๆ ได้หาอะไรใหม่ๆ ทำหรือเล่น หรือแบบเบื่อมากๆ ก็ไปเที่ยวแม่มเลย ใครมาอี๊ดๆ ติดต่องานวันนั้นจะไม่รับเลย จะให้อีเมลแจ้งเท่านั้น (มีเวลาตั้ง 7 วัน กูขอวันหนึ่งเหอะ กูขอหล่ะ)

คือไอ้ 1 วันที่ว่าเนี่ย อาจเป็น 1 วันที่ได้ศึกษาอะไรใหม่ๆ ด้วย งานด้าน IT มันต้องอัพตัวเองตลอด มันมีอะไรใหม่ เจออะไรมาก ทำอะไรได้บ้าง คือเราทำงานด้าน Solution มันต้องรู้อะไรใหม่ๆ ตลอด ศึกษาเรื่อยๆ ไม่ใช่หยุดอยู่กับที่ ไม่งั้นเราจะตามหลังแน่ๆ

ผมเชื่อแล้วว่า “คนที่เป็นโปรแกรมเมอร์ได้ยาวนานนั้น ต้อง Born to be จริงๆ”

WebKit != W3C

ผมนั่งงงว่า เมื่อไม่กี่ปีก่อนตอน IE6 คนใช้เยอะ ทุกคนหวังกับ W3C จะมาช่วยทำให้มันดีขึ้น เรียกร้องให้ใช้ Mozilla Firefox ที่เป็น Gecko Engine ที่ทำตาม W3C และ IE รุ่นใหม่ๆ ที่ Microsoft พยายามทำ Trident Engine ตัวใหม่ๆ ตาม W3C และในที่สุด IE10 ก็ทำตามมาตรฐาน W3C ได้ดีมากๆ รวมไปถึง Apple Safari และ Google Chrome ที่ใช้ WebKit Engine ที่ทำตาม W3C เช่นกัน

มาวันนี้ ทุกค่ายทำตาม W3C เป็นหลักแล้ว มีการสนับสนุน ออกคำแนะนำต่างๆ มากมาย และข่าวล่าสุด Opera ประกาศทิ้งเอนจิน Presto เปลี่ยนไปใช้ WebKit/Chromium ทั้งหมด ทำให้ค่าย Engine หลักในการพัฒนาตัว Render หน้าเว็บเหลือเพียง 3 Engine หลัก และทั้ง 3 ค่ายพยายามอย่างมากที่จะทำตาม W3C ทั้งหมด

แต่แล้วสิ่งที่ไม่คาดคิดก็คือ Developer วันนี้บอกว่า “ขอ WebKit ค่ายเดียวแล้วกัน ง่ายดี!!!”

ผมก็นั่งงงว่า อ้าว แล้วยังไงต่อดี แล้วเมื่อก่อนหวังกับ W3C ไว้ทำไมเมื่ออดีต สรุปทุกคนก็ติด loop ตัวเองซินะ แค่เปลี่ยนจาก IE6 มาเป็น WebKit แค่นั้น ><”

ปล. จะบอกว่า IE6 มันของ Microsoft มันก็ใช่ แต่ตอนนี้ทุกค่ายพยายามที่จะทำตามมาตรฐาน Open Stanard คือ W3C ก็ควรจะทำตามอันนี้หรือเปล่า ส่วน Engine ตัวไหนมันก็อีกเรืองหนึ่งหรือเปล่า อย่าลืมกรณี Java กับ MySQL ซิครับเหล่ามิตรรัก Developer ทุกท่าน ยังเจ็บไม่จำกันอีกเหรอ ><“

ในปีที่ผ่านมาเว็บที่ผมดูแลอยู่มี สถิติของ Web Browser ทั้งยี่ห้อและขนาดจอภาพมาให้ดูกัน

Chrome = 49%
Internet Explorer = 21%
Firefox = 14%
Safari = 8%
Android Browser = 5%
Other = 3%

1366×768 = 26%
1024×768 = 14%
1280×800 = 10%
1600×900 = 7%
1280×1024 = 6%
1920×1080 = 6%

IE6 = 3%
IE7 = 5%
IE8 = 55%
IE9 = 33%
IE10 = 5%

โดยจะเห็นว่าแนวโน้มของปีนี้ Chrome มาอันดับหนึ่งเลย ตามด้วย IE และ Firefox

สำหรับขนาดของจอภาพก็คงได้เวลาปรับตัวในการทำเว็บที่รองรับขนาดจอภาพที่ 1,280 pixel เป็นขนาดเริ่มต้นกันเสียที

สำหรับ การสนับสนุนใน IE6 และ IE7 นั้นก็ควรจะหยุดลงได้แล้ว คุณจะสนับสนุนเพียง 3-5% จาก 21% ของคนที่เข้าเว็บคุณเพื่อ? และควรมุ่งไปที่ IE8 เป็นส่วนเริ่มต้นและมุ่งทำให้แสดงผลได้ดีใน IE9 และ IE10 มากขึ้นน่าจะดีกว่า

สถิติอาจไม่ตรงกันสำนักอื่นๆ โปรดเปรียบเทียบกับภาพรวมของเว็บที่ดูแลกันเองและกำหนดทิศทางต่อไปในอนาคตครับ

เครื่องมือบริหาร Project สำหรับโครงการพัฒนาซอฟต์แวร์ขนาดเล็ก-กลาง ฉบับ 2012-2013

จาก เครื่องมือบริหาร Project ที่ใช้งานอยู่ตอนนี้ ที่เขียนไว้ในปี 2011 ก็ผ่านมาได้ปีกว่าๆ แล้ว แน่นอนว่าจากวันนั้นถึงวันนี้ก็มีการปรับเปลี่ยนการทำงานอยู่ตลอดเวลาเพื่อให้รับกับการเปลี่ยนแปลงใหม่ๆ ได้ สำหรับปี 2012-2013 นั้น ส่วนตัวแล้วมีการปรับเปลี่ยนการใช้เครื่องมือหลายๆ ตัวอยู่พอสมควร

ต้องขอปูพื้นก่อนสำหรับคนที่ไม่ได้อ่านตอนปี 2011 ว่างานหลายๆ ตัวและหลายๆ Project นั้นส่วนตัวแล้วนั้นทำงานร่วมกันหลายคน และมักจะมากกว่า 1 คนแน่นอน เพราะฉะนั้น การสื่อสารเป็นสิ่งสำคัญมากๆ บางครั้งต้องบันทึกช่วยจำต่างๆ มากมายเครื่องมือช่วยต่างๆ จึงจำเป็นอย่างมากในการอำนวยความสะดวก เพื่อไม่ให้ตกหล่น เพราะฉะนั้นลองมาดูว่าส่วนตัวผมนั้นใช้ส่วนไหนบ้าง

1. โทรศัพท์!
เรื่องพื้นฐานมากๆ เพราะความชัดเจนในการสื่อสารสำคัญ ซึ่งการโทรศัพท์นั้นเหมาะกับสถานะการณ์บางอย่างที่ต้องการการตอบสนองที่รวดเร็ว ออกแนวว่าด่วนสุดๆ  เพราะบางครั้งส่งอีเมลไป ไม่เข้าใจหรือไม่ชัดเจน โทรคุยอธิบายอาจจะชัดเจนกว่าใช้เวลาสั้นกว่า และน้ำเสียงทำให้การสื่อสารนั้นดูนุ่มนวลกว่าตัวหนังสือใน E-Mail กว่าในบางครั้ง

2. E-Mail
เป็นการใช้ในด้านการยืนยัน หรือแจ้งรับทราบร่วมกันเป็นกลุมเป็นหลัก ซึ่งปรกติจะใช้เป็นส่วนหนักในการคุยงาน สร้างหลักฐานร่วมของการทำงาน ในบาง Project ใช้อีเมลโต้ตอบกันไป-มาเยอะมากเพื่อสรุปและแจ้งรับทราบให้ทุกกรณีเพื่อไม่ให้ตกหล่น

3. IM

  • GTalks – ด้วยความที่ใช้บนระบบ Webbased ได้ด้วย ประกอบกับตัวอักษรล้วนๆ รวดเร็วไม่ต้องมีอะไรมากมาย จึงเหมาะมากๆ กับการโต้ตอบ ไป-มาระหว่างคนสองคน (แถมมี logging chat ด้วยสะดวกดี)
  • Windows Live Messenger – ตอนนี้รวมและย้ายไปใช้ Skype แทนแล้ว
  • Skype – ใช้คุยทั้ง Skype Account และ Microsoft Account (Windows Live Messenger) รวมไปถึงประชุมสายเพื่อลดต้นทุนการโทรศัพท์
  • Google+ Hangouts – ถ้าใช้ Skype สำหรับประชุมสายผ่านโทรศัพท์ ตัว Hangouts ก็เป็นส่วนของการประชุมสายผ่านทาง Webcam นั้นเอง
  • Line/WhatsApp/IM+ Pro – App สำหรับ Chat บนมือถือ เหมาะสำหรับเวลาติดต่อที่ต้องการความรวดเร็วกว่า Skype และ GTalks แน่นอนว่ามันติดอยู่กับโทรศัพท์มือถือ เพราะฉะนั้นจะค่อนข้างไวกว่าในการโต้ตอบ
  • Facebook Chat – ส่วนตัวแล้วเหมาะกับฝากข้อความเป็นหลัก ใช้แทน SMS ได้ดี และคนในทีมใช้ Facebook กันทุกคน เพราะฉะนั้นจึงเหมาะกับการฝากข้อความหรือเน้นย้ำมากกว่า

4. Project Sharing CodeBitbucket หรือ Github

จากปี 2011 มาปี 2012 นั้นในทีมได้ย้ายจาก Github ที่เป็นระบบ Project Sharing Code ที่มีผู้ใช้งานอยู่ทั่วโลก ได้รับความไว้วางใจาก Developer มากมาย มาใช้ Bitbucket ที่มีค่าใช้จ่ายด้านการบริหารจัดการ Project Sharing Code แบบ private ที่มีต้นทุนแปรผันตามขนาดทีมที่ใช้งาน ซึ่งประหยัดมากกว่าจำนวน Repositories แบบ Github ที่ผมต้องเสียเงินเพื่อเช่าใช้แบบ private เดือนละประมาณ $12/month อยู่ โดยปรกติแล้วทำงานกันจะเป็นทีมขนาดเล็ก เพราะฉะนั้นถ้าจำนวนคนใน Project ไม่เกิน 5 คนก็ไม่มีค่าใช้จ่ายต่อเดือนแต่อย่างใดสำหรับ Bitbucket ทำให้ประหยัดลงไปได้มาก มีอยู่หลายเดือนที่ต้องเสียเงินให้กับ Github มากกว่า $12/month เพราะมี Private Repositories มากกว่าที่กำหนดไว้ และถ้า Project ไหนจบแล้วก็ต้องลบออกทำเป็น copy source ไว้ด้านนอกเพื่อประหยัดพื้นที่ไว้สำหรับ Repositories ตัวต่อไป ซึ่งในทางการทำงานบางครั้งก็ไม่สะดวกถ้าเรามี Project ที่เราต้องดูแลต่อในอนาคตเราต้องกันพื้นที่ส่วนนี้เป็น Repositories ค้างไว้ ซึ่งแน่นอนว่าถ้าเราลดต้นทุนในส่วนนี้ได้ ก็ประหยัดลงไปได้พอสมควรเลย

หลายคนไม่ทราบว่า Bitbucket นั้นเป็นระบบที่รองรับ Git Version Control System แบบเดียว Github เช่นเดียวกัน ซึ่งเป็น Source Code Versioning แบบ distributed version control system โดยแต่ละคนไม่เพียงได้ข้อมูลล่าสุดของไฟล์งานต่างๆ เท่านั้น แต่ได้ทั้งมา Repository ไปด้วยเพราะฉะนั้นถ้า Server ตัวหลักมีปัญหา (ในที่นี้หมายถึง Server Bitbucket) ตัวเครื่อง Client ก็สามารถทำงานได้อยู่ พอ Server ตัวหลักกลับมาทำงานได้ปรกติก็จะสามารถส่ง Source กลับไปได้โดยข้อมูลที่แก้ไขไป-มานั้นยังคงอยู่และพร้อมให้ Server สามารถรับข้อมูลล่าสุดต่อไปได้ทันที เหมาะกับ Project ทุกขนาดที่ต้องใช้การแชร์ Source โปรแกรมมากกว่า 1 คนขึ้นไป เพื่อป้องกันการแก้ไขทับไปมาระหว่างคนในทีม ช่วยเรื่อง Backup และ Recovery ได้ดีมากๆ

ซึ่งแน่นอนว่าระบบเป็นแบบ Webbase เพราะฉะนั้นมันจึงมี Issue/Milestone/Version ที่ช่วยติดตามงานต่างๆ ได้ดีมากขึ้น โดยถ้าเป็นใน Github เราสามารถใช้ Label ได้อิสระ แต่ใน Bitbucket เราจะไม่สามารถกำหนด Label ได้ แต่กำหนดเป็น Kind ที่ตั้งค่ามาให้เรามาเลยโดยเพิ่มเติมไม่ได้อยู่ 4 แบบ คือ bug, enhancement, proposal และ task ซึ่งโดยรวมจริงๆ ก็เพียงพอสำหรับใช้งานอยู่แล้วตามรูปแบบทั่วไปที่ใช้ๆ กันอยู่แล้ว

สำหรับบันทึกช่วยจำนั้นใน Bitbucket ก็มี Wiki มาให้แบบเดียวกับ Github ส่วนใหญ่เอาไว้แจ้งข้อมูลทั่วไปพวก FTP, Databases Access หรือเอกสารของลูกค้าต่างๆ ที่เป็น Features หรือข้อตกลง เป็นหลัก ซึ่งรวมไปถึงคู่มือหรือการแก้ไขปัญหาต่างๆ ที่เกิดขึ้น

5. Documents/Spreadsheet (เอกสารแชร์กับลูกค้า)

จากเมื่อปี 2011 ที่ผ่านมาใช้ Google Docs ในปี 2012 ที่ผ่านมาเริ่มปรับเปลี่ยนมาใช้ Microsoft Office Web Apps มากขึ้นเรื่อยๆ เหตุผลง่ายๆ คือลูกค้าเข้าใจส่วนติดต่อ (UI) ของ Microsot Office มากกว่า แถมมีข้อดีคือสามารถเปิดเอกสารผ่าน Microsoft Office ตัวปรกติบนเครื่องได้และบันทึกกลับเข้ามาใน Web Apps ได้โดยสะดวก แต่ก็ยังใช้ผสมกันทั้ง Google Docs และ Office Web Apps ขึ้นอยู่ที่ Project ที่กำลังทำงานอยู่ว่าลูกค้าถนัดตัวไหน ซึ่งเหตุผลในหลายๆ ส่วนเอกสารบางตัวใน Wiki ของ Bitbucket ก็ถูกนำมาใส่ในส่วนนี้เช่นกัน เพราะลูกค้าคงใช้ Bitbucket ไม่เป็น เพราะฉะนั้นงั้นก็ควรใช้อะไรที่ง่ายๆ ที่เข้าถึงได้สะดวกกว่านั้นเอง

6. Cloud Storage Sharing/Sync

เป็นการปรับเปลี่ยนครั้งใหญ่โดยส่วนตัว โดยย้ายมาใช้ SkyDrive แทน Dropbox ด้วยเหตุผลด้านค่าใช้จ่าย ด้วยราคาต่อหน่วยพื้นที่เก็บไฟล์ที่ราคาไม่สูงมากนัก แถมยังมีตัวเลือกในการเช่าพื้นที่เพิ่มเติมที่มีหลายระดับราคามากกว่า ซึ่งตัว App ที่เป็นตัว Sync File เพื่อทำงานรวมกับระบบ Cloud นั้นทำงานได้ดีพอๆ กับ Dropbox แล้ว และยังเข้ากันได้ดีกับ Windows 8 และ Windows Phone 8 ด้วย (บน iOS และ Android ก็ใช้งานได้ดีเช่นกัน)

โดยในส่วนของ Cloud Storage พวกนี้จะถูกใช้สำหรับเก็บเอกสารต่างๆ ทั้งส่วนตัวและลูกค้าที่เป็น Word, Excel หรือ PowerPoint ที่เป็นไฟล์โยนไป-มาในอีเมล โดยปรับเปลี่ยนมาใช้การ Share ผ่าน link เป็นหลักเพื่อความรวดเร็วในการรับ-ส่งและยังแก้ไขได้ง่ายกว่าการแนบไฟล์ตามปรกติที่ทำๆ กันมาที่บางครั้งก็ไม่รู้ว่าไฟล์ไหนเป็นไฟล์ตัวล่าสุด ทำ snapshot และ versioning แบบเปรียบเทียบกับของเก่าได้ยากกว่า อีกทั้งระบบพวก cloud storage พวกนี้ยังมีส่วนของการค้นหาและสำรองข้อมูลไว้บน Cloud อีกชุดเพื่อความปลอดภัยของข้อมูลด้วย

ข้อดีที่สำคัญอีกอย่างของ Cloud Storage (ทั้ง SkyDrive และ Dropbox) ที่เหนือกว่าการเก็บไฟล์แบบเดิมๆ บนเครื่องก็คือยังสามารถเข้าถึงได้จากมือถือผ่าน App ที่มีให้ดาวน์โหลดบน Store ของแต่ละค่ายเอง หรืออุปกรณ์อื่นๆ ที่เข้า Internet ได้ผ่านทาง Web Browser ได้ด้วย แต่ข้อดีของ SkyDrive ที่ปรับเปลี่ยนมาใช้ก็เพราะสามารถทำงานร่วมกับ Office Web Apps ได้ดีกว่า Dropbox อยู่เยอะ แต่ข้อเสียของ SkyDrive คือระบบ versioning ที่รองรับแต่เฉพาะไฟล์ของ Micorosoft Office เป็นหลัก ไม่รอบรับไฟล์รูปแบบอื่นๆ เหมือน Dropbox อาจจะต้องเลือกการใช้งานให้ถูกกับประเภทสักหน่อยเท่านั้นเอง

กล่าวโดยสรุปจากทั้งหมดที่กล่าวมาทั้ง 6 ส่วนนี้ จะเห็นว่าแต่ละส่วนช่วยในเรื่องของการบันทึก ช่วยจำ และการติดต่อสื่อสาร อีกทั้งยังช่วยในการสำรองข้อมูลต่างๆ ให้การทำงานของเรานั้นราบรื่นมากที่สุด เพราะฉะนั้นลองนำไปปรับใช้ในทีมกันดูนะครับ น่าจะช่วยในการประสานงานกันในทีมดีมากขึ้น แถมยังปลอดภัยต่อข้อมูลที่ตกหล่นอีกด้วย