หากใจชั้นนั้นดั่งพสุธา ลอยลาฟ้าไกลไร้เขตขันต์
ส่วนเทอนั้นเปรียบดั่งพนาวัล มีฝันและทางที่ต้องเดิน
ร้าวรานเพราะชั้นเอาแต่เหิน ก้าวเดินของเทอกับส่วนเกิน
ผ่านมาดั่งฝันพลั้งใจเพลิน หมางเมินถึงคราวด้วยเศร้าใจ

บางทีคนเราก็ยอมที่จะทำผิดพลาดซ้ำรอยอดีตในวันรุ่งขึ้น
เพียงขอแค่วันนี้มีความสุขกับสิ่งชั่วคราวก็เพียงพอ…

ชั้นก็ไม่รู้ว่าวันใหม่ของชั้นจะเป็นอย่างไร
แต่ขอแค่ให้วันนี้ชั้นยิ้มได้เหมือนคนทั่วไปก็เพียงพอ…

“ไม่รู้จักฉัน ไม่รู้จักเธอ…”

ผมหายไปนานอีกแล้วเนอะ วันนี้มา Update Technology สั้นๆ ครับ

ใครตาม Blog ผม จะได้ยินเรื่อง Technology Shift และ Platform กลางนภากาศ (Cloud Platform)

ตอนนี้ ผมมาพิสูจน์ว่า สิ่งที่ผมคาดการณ์ไว้ เริ่มเป็นจริงแล้ว

ถึงแม้นผมยังไม่เป็น Architecture ของ iCloud ที่เป็นจุดที่ผม Focus ว่ามันคือ ต้นแบบ ของ Platform กลางนภากาศ

แต่วันนี้ผมได้เจออีกตัวนึงครับ —> Yahoo Cocktails

ก็ผมยังไม่ได้ลงรายละเอียดมาก แต่นี่คือยุคของต้นแบบครับ เทคโนโลยีตัวนี้ต้องอาศัยอย่างน้อย 3 ปีในการทำให้นิ่ง

และทุกคนจะได้เห็น Web 3.0 จริงๆ กันซักที ไม่ใช่ของพวก MKTSuck ที่เอามาหลอกขายไปเรื่อยๆ

นั้นแปลง่ายๆว่า อีกอย่างน้ยอ 3 ปี เราถึงจะเป็น Web 3.0 หรือ Personal Cloud นั้นเองครับ

สวัสดีครับทุกท่าน คงใช้เวลาไม่นานกล่าวคำอาลัย คุณลุง Steve Jobs นะครับ.

ก็เป็นคนที่มีอิทธิพลในการคิดตามหลัก Zen ของผมอยู่ไม่น้อย

ก็… สู่สุขคติ ครับ.

พฤษภกาสร อีกกุญชรอันปลดปลง
โททนต์เสน่งคง สำคัญหมายในกายมี
นรชาติวางวาย มลายสิ้นทั้งอินทรีย์
สถิตทั่วแต่ชั่วดี ประดับไว้ในโลกา

กล่าวคำอำลากันแล้ว ก็วันนี้ก็ถือเป็นวาระพิเศษแล้วกันครับ

เราจะมาเจาะลึก iCloud กัน… เพื่อรำลึกถึงลุง Jobs.

ถ้าใครเป็นแฟนตัวยงของ Blog นี้ คงจำเรื่อง Technology จะ Shift ได้

และถ้าใครอยู่มานานกว่านั้น คงจำได้ว่า ผมเขียนถึง Platform กลางนภากาศ

ในครั้ง เริ่มพูดเรื่อง CRM ใหม่ๆ

ใช่ครับ วันนี้เราจะมี deep in detail กัน

เพราะภาพก็ชัดแล้วในขณะนี้ ด้วย iCloud

-

ผมคงไม่ต้องเกริ่นคำว่ายุค Post PC อีกเนอะ เพราะมันมาถึงแล้ว

เด็กรุ่นต่อไป อาจจะรู้จักแต่การคุยกับ iPad ผ่าน Siri เพื่อเขียนรายงาน

และลืมไปแล้วว่า พวกเราเคยใช้ Word, Excel และ Power Point

ถ้าอ่านแล้วยังคิดเรื่องพวกนี้ไม่ได้ แนะนำให้อ่าน Blog ผมใหม่ทั้งหมดอีกครั้ง

เพื่อคิด Deep in Detail ว่าอนาคตจะเกิดอะไรขึ้น

หรือหากยังไม่เข้าใจอีก ผมคงต้องขอโทษ ผมอาจจะเป็นผู้ส่งสารที่ไม่ดีนัก

-

แล้ว Post PC เกี่ยวอะไรกับ iCloud…

เกี่ยวสิครับ เพราะ gadget ของเราก็มีตั้งเยอะแยะ

แล้วจะทำอย่างไรให้เรา centralized ข้อมูลได้อยู่ที่เดียว

ไม่ใช่ถ่ายรูปกะกิ๊กบน iPhone แล้วจะเอาไปโชว์ผ่าน iPad แต่มันต้องเสียเวลา transfer

อย่างงี้ไม่ไหวนะครับ เสียเวลาในการ manage มากๆ

หรือการมี playlist ที่ชอบ แต่ต้องนั้นย้ายระหว่าง iPad, iPhone และ Mac

สุดท้ายปวดหัวตาย ไม่รู้ว่า Original อยู่ตรงไหน copy กันกี่ master

ทุกอย่างจะหมดไปด้วยการเอาไอ้พวกนั้นใส่ Cloud

-

พูดถึง Cloud ใครๆก็ทำได้

Google ก็เป็น Cloud ผมมี Google+ Gmail และใช้ Google docs

Facebook ก็เป็น Cloud ผมมี add friend สาวๆไว้มากมาย

แต่ทำไมหล่ะ ทำไมต้อง iCloud???

-

แล้วทำไม Technology มา Shift ที่ iCloud ???

-

ก็เพราะ Apple ได้ “บงการ” ความรู้สึกผู้ใช้งานตั้งแต่ Hardware จนถึง User Interface

ทำให้มีอำนาจเบ็ดเสร็จในการกำหนดอารมณ์การใช้งานของผู้ใช้งาน

ซึ่งต่างจาก Google หรือ Microsoft หรือ Facebook

ที่ทำตัวครึ่งๆ กลางๆ จับปลาหลายมือ มีหลาย partner

-

เมื่อควบคุมได้หมด ก็สร้างสถาปัตยกรรม ที่สวยงามได้ตามใจชอบ

โดยไม่ต้องแยแส Partner และใส่ใจกับ Politic การแบ่งผลประโยชน์ของพวกนั้น…

-

ที่ผมสนใจ iCloud เพราะมันเป็นการ integrate ตั้งแต่ OS level (ถ้าผมไม่เข้าใจผิด)

ผมยังไม่มีเวลาไป search ดู architecture ของมันมากนัก

และก็ไว้ใจว่า Apple รวมทั้ง ศาสดา Jobs คงไม่งี่เง่า ทำอะไรซ้ำซากเหมือนคนอื่น

-

ใช่ครับ หัวใจมันอยู่ที่ integration ตั้งแต่ OS Level

ผมเคยพูดไว้แล้วครับว่า Web Application เป็น Synchronious

คือการ interface นั้น คุณต้องสนใจมันตลอดเวลา

มันยังไม่มีการ Push ให้คนมาสนใจมันในบางเวลาได้

อย่างน้อยคุณก็ต้องอยู่หน้า Browser จึงจะสังเกตุเห็นมัน

-

แต่ในโลกแห่งความจริง เราทำงานกับแบบ Asynchronious มากกว่า

เช่นพูดไป อีกชาตินึงก็ได้ กว่าเพื่อนเรามันจะสำนึกได้และตอบกลับ…

-

ดังนั้น การมี Push จึงเป็นสิ่งที่ถูกต้อง และการเลือกได้ว่าจะรับ Push

หรือไม่รับ Push ตอนไหน แบบไหน โต้ตอบอย่างไร จึงเป็นสิ่งที่ควรทำ

และสิ่งนี้แหละ มันทำให้ต้องเกิด integration ใน OS level

-

ถูกครับ Web Architecture ตอบโจทย์ของยุค Post PC ที่มนุษย์ต้องสมาธิสั้นไม่ได้

-

การสมาธิสั้น ก็ไม่ต่างจากการทำงานแบบ Multi-Tasking ซึ่งเป็นสิ่งที่ require กันใน

Enterprise Business ในปัจจุบัน…

พนักงาน 1 คน ต้อง run ได้ 10 project โดย performance ที่ดี และนั่งทำงานถึง 3 ทุ่มทุกวัน

เพื่อกำไรขององค์กรที่มากขึ้น บนต้นทุนที่น้อยลง

-

การ sync ข้อมูลใน OS level ทำให้ device ฉลาดพอที่จะเลือกช่วงเวลาที่

bandwidth เพียงพอในการ sync

-

การ Push ข้อมูลใน OS level ทำให้ ผู้ใช้สามารถเลือก เวลาและวิธีที่อยากให้ Push ได้

เช่นคุณอยู่ใน BTS ที่คนแน่น จนไม่มีที่พอจะเอามือไปหยิบมือถือขึ้นมา

คุณก็เลือกให้มัน Push ผ่าน siri เพื่อแหกปากผ่าน small talk ให้คุณฟัง

หรือ คุณอยู่ในห้องประชุม คุณก็เลือกให้มันสั่น

หรือคุณนอน คุณก็สั่งให้มันตอบกลับไปเลยว่า นอนอยู่ ไว้ตอบพรุ่งนี้

โจทย์พวกนี้ Web Application ที่เป็น thin client ตอบไม่ได้

-

แต่ ด้วยการ design Push Architecture บน OS Level

จะทำให้ Device เหล่านี้ตอบได้…

-

ผมตื่นเต้นมาก ที่เห็น Siri ยิ่งได้เห็น Demo

แต่จะตื่นเต้นกว่านี้ ถ้าเค้าพัฒนา Artificial Intelligence ไปไว้บน Cloud

ทำไมนะเหรอ???

-

ต่อไป Siri ตัวจ้อที่ฉลาดนี้ จะไม่ใช่แค่จ้อ เพราะคำสั่งของคุณอย่างเดียว

แต่จะจ้อ โดยวิเคราะห์ผ่าน พฤติกรรมการใช้งานของคุณ ซึ่งถูกเก็บไว้บน Cloud

ทำให้เจ้า Siri นี้รู้ใจคุณมากขึ้น

-

นอกจากนั้น การเก็บทุกอย่างไว้บน Cloud จะเป็นการทำให้ personalized ของคุณ

ถูกเก็บอยู่บน โลก digital

ซึ่งเป็นโลกที่ข้อมูลของคุณถูกนำมาทำ analytic และ data mining ได้ผ่านสมองกล

แทนที่จะผ่านสมองของคุณอย่างเดียว

-

พูดง่ายๆว่า ถ้า Siri ไปอยู่บน Cloud คุณก็จะได้เลขาส่วนตัวนั่นแหละ

-

และนี่คือ Platform กลางนภากาศที่ผมเห็นภาพลางๆเมื่อ 2ปีก่อน

ผมมาเห็นภาพชัดตอนนี้ ที่ศาสดา Jobs เปิดตัว iCloud

แต่ผมรอที่จะให้มันเสร็จจริงในอีก 3ปี 5ปีไม่ได้แล้ว

-

อย่างลืมว่า Apple ต้องบุคห้องนั่งเล่นของคุณ

Siri จะฉลาดพอที่จะส่งรายการ TV บน Youtube ที่คุณชอบ

ผ่านมาทาง Apple TV ถ้าคุณอยู่บ้าน หรือผ่านทาง iPhone ถ้าคุณอยู่นอกบ้านได้หรือไม่

ต้องตามดูกันต่อไปครับ

-

สวัสดี และยินดีต้อนรับสู่ยุค Post PC

-

เช่น การกำหนดปฏิทินการทำงานขององค์กร ซึ่งแน่นอนว่า ซอร์ฟแวร์พื้นฐานทุกตัวที่เกี่ยวกับการทำ Transaction นั้น มาตรวจสอบปฏิทิน เพื่อให้รู้ว่าวันใดบ้างเป็นวันหยุด นักขัตฤกษ์ หรือวันใดบ้างเป็นวันเสาร์อาทิตย์ แล้ววันเหล่านั้น จะอนุญาติหรือไม่อนุญาติ ให้ผู้ใช้งานทำ Transaction ซึ่งโดยทั่วไปแล้วแต่ละ Application ขององค์กรในปัจจุบัน จะมี function แยกเฉพาะสำหรับการกำหนดค่าปฏิทินวันหยุด ซึ่งทำให้แต่ละ Application นั้น ต้อง maintain ค่าเหล่านี้ด้วยตัวเอง สมมุติง่ายๆว่า องค์กรเรามีระบบอยู่ 30 ระบบ แสดงว่าการตั้งค่าปฏิทินนั้นต้องทำถึง 30 ครั้ง ซึ่งแต่ละครั้งก็มีโอกาสที่จะเกิด Human Error ได้ แล้วสมมุติอีกว่า แต่ละ Applicationต้องทำงานร่วมกับโปรแกรมอื่น เช่น Run Batch ต่อจาก Application อื่นๆ แล้วหากมี Application หนึ่งกำหนดวันหยุดผิด ทำให้โปรแกรมทำงานผิดพลาด และอาจเป็นที่มาของปัญหาหลายๆอย่าง เช่น ยอดเงินไม่ตรง การบันทึกบัญชีผิดพลาด การตัดชำระมีเกินจริง และนี่แหละคือความสำคัญในการจัดระบบเบียบ Software เป็นบริการมาตรฐาน เพื่อลดความซ้ำซ้อนในการพัฒนา, ลดความผิดพลาดที่เกิดขึ้นในการตั้งค่า function งานที่ซ้ำซ้อนกัน และลดความเสียหายทางธุรกิจ

แม้นว่าคำว่า Services (บริการ) นั้น จะเป็นแนวคิดที่มาจากมุมมองทางด้านเทคโนโลยีก็ตาม แต่แท้จริงแล้วการแบ่ง Software เป็น Services นั้น จะไม่มีประสิทธิภาพเลย หากเราไม่คำนึงถึง Business Vision (วิสัยทัศน์ทางธุรกิจ) แท้จริงแล้ว คำว่า Services นั้น ถูกบิดเบือนโดยเหล่า Vendor IT ต่างๆ เพื่อเป็นการ หลอกขาย เครื่องมือการพัฒนาและเชื่อมต่อ Software ที่มุ่งเน้นไปในเรื่อง Business Process (กระบวนการทางธุรกิจ), Orchestration (การเรียงร้อยบริการทางธุรกิจต่างๆ) หรือ Web Services แล้วก็มีหลากหลายองค์กรที่ตกเป็นเหยื่อของ Vendor IT เหล่านี้ โดยซื้อเทคโนโลยีและเครื่องมือการพัฒนา SOA ไป โดยที่ขาดความรู้ความเข้าใจในการออกแบบ Services ตามวิสัยทัศน์ทางธุรกิจ ซึ่งจะเป็นตัวกำหนดขอบเขตว่า Services ใด ต้องถูกบริหารจัดการโดยกลุ่มธุรกิจใดในองค์กร เพราะอะไร และเพื่ออะไร

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

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

วัตถุประสงค์

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

หนังสือเล่มนี้มีวัตถุประสงค์เพื่อแสดงแนวคิดในการ “นิยาม Services” สำหรับองค์กรระดับ Enterprise หรือ Project ต่างๆ เพราะเกิดการอวดอ้างเกินจริง ของเหล่าบรรดา Vendor IT ในการประยุกต์ใช้ SOA โดยผลักดันให้องค์กรสนใจเทคโนโลยีที่จะนำมาใช้ มากไปกว่า กระบวนการในการออกแบบ Process และนิยาม Services ที่จำเป็นสำหรับแต่ละองค์กร

โดยมุ่งเน้นไปที่การออกแบบในระดับ Conceptual (ระดับแนวคิด) จากแง่คิดและวิธีการในการนิยาม Services และความเหมาะสมในการนิยาม Services นั้นๆ ตามกระบวนการทางธุรกิจ ว่า Services นี้มีเพราะอะไร เพื่ออะไร สำหรับใคร ให้บริการใครและทำไมต้องเป็นแบบนั้น แต่ไม่ได้ลงรายละเอียดว่า แต่ละ Services ควรมี Parameter อย่างไร หรือว่า Services เหล่านี้ควรประยุกต์ใช้ด้วยเทคโนโลยีใด
นอกจากนั้น ยังเสนอผลกระทบจากการใช้แนวคิด SOA, Life-Cycle ของ Services ต่างๆที่จะกิดขึ้น เช่นเริ่มนิยาม Services, Services นั้นถูกใช้งาน, Services นั้นถูกปรับปรุง และ Services นั้นถูกเลิกใช้งาน และวิธีบริการจัดการ Services ตาม Life-Cycle ของมัน

ผมห่างหายไปนานเนอะ เพราะติดสาว ฮาๆ

แล้วตอนนี้โดนสาวหักอกแล้วก๊าบบบบ เลยกลับมาทำงาน up blog เต็มที่

กลับมาแล้วครับ พร้อม Series ใหม่ Politic Architect Note

-

ทำไมต้องขึ้น Series ใหม่ ว่างเหรอ? อยากเท่ห์? คิดยังไง?

ถ้าใครจำกันได้ ผมเคยพูดถึง Layer ใหญ่ๆที่เป็นโครงสร้างที่ Drive IT ดังนี้

IT > Business > Politic > Philosophy >Religion

ใช่ครับ Blog ของผมจะไต่จาก IT ขึ้นไปเรื่อยๆ

ซึ่งมันก็สะท้อนถึงการงานและอายุของผมที่เพิ่มขึ้น

และตอนนี้ ผมก็ขึ้นมาถึงห่วงข้อที่ 3 ของ Layer ใหญ่ๆที่ Drive IT ในขณะนี้แล้ว

Layer นี้คือ Politic…

-

ใครจำได้ ผมเคยเขียน Blog เรื่องที่ว่า PM ไม่ใช่แปลว่า Project Manager

แต่มันแปลว่า Politic Management

ใช่แล้วครับ หลังจากที่โดนจับไปเป็น PM ตอนนี้ผมลึกซึ้งกับคำนี้

มากกว่าตอนที่เขียน Blog เรื่องนั้นซะอีก

และ Blog Series นี้ จะขอถ่ายทอดมุมมองเฉพาะของ PM

ให้เข้าใจว่า PM ต้องคิดยังไง และต้องทำยังไง

และทำไม PM จึงต้องดัน Project ให้เดินต่อไป ทั้งๆที่รู้ว่ามีปัญหา…

-

เริ่มต้น ตอนโน้น เป็น Programmer…

“จุดนี้มีปัญหา จุดนั้นมีปัญหา PM รู้บ้างมั้ย ทำไมยังดันต่อไป

ขึ้นไปแล้ว ต้องตามเช็ดตามล้าง มีปัญหา โน่น นี่ นั่น แมร่งจะดันทำเหี้ยอะไร”

คำบ่นประจำ ที่ผมเคยชอบด่า พวก PM ที่แมร่งไม่รู้เรื่องเทคนิค…

-

ใช่แล้วครับ มีพวกบ้า ที่ชอบคิดว่า PM แมร่งแค่ Manage Resource ไม่ต้องรู้เรื่อง Detail ก็ได้

และก็พวกบ้าๆพวกนี้นี่แหละ ที่เป็นผู้ใหญ่ เป็นผู้บริหาร ฝังตัวอยู่ในองค์กร

และชอบเขียนตำราตามมหาลัย

ปล่อยพวกบ้าๆนัันไว้ก่อน ไว้เราจะพูดถึงใน ภาคต่อไปของ series นี้

-

ตอนนี้กลับมาสนใจคำว่า PM กันดีกว่า

PM ถูกเขียน Roles & Responsibility โง่ๆว่า

“บริหารจัดการโครงการ ดูเรื่องการจัดสรรค์ resource ให้พอและตรง timeline”

แต่นั่งอยู่หัวสุดของ Project และงานก็ง่ายๆ

ใคร ต้องทำอะไร ต้องทำเมื่อไหร่ และเสร็จเมื่อไหร่ แค่นั้น

-

ง่ายมะ การเป็น PM แค่เข้าไปพูดว่า

“คุณ Programmer ครับ งานนี้ต้องเสร็จตอนนี้นะครับ

ถ้าไม่เสร็จ ผมคงต้อง escalation (ฟ้องนายคุณ) ตาม Process นะครับ”

เพราะ Roles & Responsiblity เขียนไว้ง่ายๆแค่นี้…

แล้วถ้า PM แมร่งคิดโง่ๆ ได้แค่นี้ Project คงไม่เสร็จหรอกครับ

บ้าไปแล้ว…

คงมีแต่การฆ่าฟัน (เพราะเอาแต่ฟ้องกันไปกันมา) และล้มตาย…

-

ถ้าใครคิดว่าเป็น PM แล้วงานง่ายๆ มีหน้าที่โง่ๆ แค่นี้

ผมคงขอให้เค้าเลิกคิด เพราะ PM โง่ๆพวกนี้ คงอายุงานไม่ยืนหรอกครับ

ยกเว้นเค้าเป็น “คนโปรด” ของผู้ใหญ่ในองค์กร

และเชี่ยวชาญในการโยนขี้ และเขวี้ยงขี้ใส่ชาวบ้าน

“การจะเป็นคนโปรดได้ ก็แค่เชี่ยวชาญในการใช้คำหวาน

และ Manage ความพึงพอใจของผู้บริหาร ยิ่งถ้ามีผู้บริหารโง่เขลา

การดำรงชีวิตการทำงานแบบนี้ยิ่ง ‘โครงง่าย’ “

-

อย่าไปพูดถึง PM แย่ๆ ที่ทำตัวเห้ๆ และคิดโง่ๆเลยครับ

ผมมาเจาะลึกถึงความเป็น PM และ Hidden Roles&Responsiblity

ที่ไม่ได้เขียนไว้ดีกว่า

-

คุณเป็น PM คุณแค่จัดการ Resource ให้ได้ Deliverables ตรงกับ Timeline

แต่…

ถ้าสมมุติ Programmer กับ BA ทะเลาะกัน ปัญหานี้ไม่จบ

ถูก escalation ขึ้นมาตามโครงสร้างของ Project

สุดท้าย PM ต้องขึ้นนั่งบังลังค์พิพากษา

เอิ่ม แล้ว PM เหี้ยอะไร จะรู้ใส้ในของรายละเอียดวพกนี้ฟร่ะ

“ฟันผิด ฟันถูก แล้วจะทำยังไง

แล้วถ้าฟันไปฝ่ายไหน อีกฝ่ายไม่พอใจ แล้วเค้าจะทำงานให้ Project นี้ อย่างเต็มที่มั้ย

เหี้ยแล้วไง ชีวิต PM”

อันนี้คือ Hidden Agenda ใน Roles & Responsibility ของ PM

-

ถ้าปัญหาข้างต้นเกิด มีทางเลือกโง่ๆคือ escalation ขึ้นไป ให้ผู้ใหญ่

ทั้งด้าน IT และ Business มาร่วมตัดสินใจ

ถ้าเกิดว่ามันเกิดขึ้นไม่บ่อยก็ดี เพราะผู้ใหญ่จะช่วยได้

แต่ในการทำงานจริง ถ้า Programmer และ BA ขึ้นต้นกันด้วยคำว่า

“กรูเกลียดมรึงแล้ว” เหตุการณ์แบบนี้จะเกิดขึ้นเป็นประจำ

เพราะพวกนี้ แมร่งก็จะหาเรื่องกันนั่นแหละ

แล้วถ้า PM เลือกที่จะ escalation ทุกครั้ง

ผู้ใหญ่จะมองอย่างไร PM แมร่งทำเหี้ยอะไร ไม่แก้ปัญหา

มีเรื่องเหี้ยอะไรก็ฟ้องนาย ให้ผู้ใหญ่เห็น

ไม่เห็นช่วยแก้ไขปัญหาของ Project ได้ อย่างงงี้จะมี PM ทำไม

แล้วคนทำงานก็คงไม่พอใจ เพราะมีอะไร ก็เอาแต่ฟ้องนาย

ทำเรื่องให้ใหญ่ ให้ผู้ใหญ่มาตัดสิน

คนทางนี้ PM มีแต่เจ๊งกับเจ๊งครับ…

-

สุดท้าย PM ก็ไม่สามารถเลือกวิธี escalation ได้

และต้องขึ้นนั่งบรรลัง พิพากษาเอง

แล้ว PM เหี้ยอะไร จะบอกว่า ไม่รู้ detail ได้

แค่จัด Resource ให้ตรงกับ Timeline พอ

ไอ้พวกงี่เง่า เมิงเลิกคิดแบบนี้ซะทีเหอะ มันเป็นวิถีแห่งความชิบหาย

ถ้า PM จะไม่รู้ detail ของงาน แค่ manage resource ให้ตรง timeline

-

คำว่า บริหารจัดการ มันเป็นศิลป์ ไม่ใช่เป็นศาสตร์

คุณไม่สามารถบอกว่า A + B แล้วจะได้ C เสมอไป

ไม่ใช่ ให้ resource ทำให้ได้ตรง timeline แล้วจะได้ deliverable เสมอไป

มันต้องบริหารจัดการ Emotion ของผู้คนใน Project ด้วย

ทำไงให้ทุกคนใน Project แสดงศักยภาพให้ได้มากที่สุด

และทำไงให้ทุกคนใน Project Deliver ผลงานที่ดีที่สุดของเค้า

และทำไงให้สิ่งที่เค้า Deliver นั้นตรงกับ Timeline

แล้วส่งต่อให้อีก resource นึงอย่างสวยงาม…

มันคือ ศิลปะ…

-

ยิ่งไปกว่านั้น ทำอย่างไรถ้าคนในโครงการเจอปัญหาเชิงเทคนิค

ถ้าเค้าแก้ไขงานเค้าไม่ได้ จะทำอย่างไร

ทุกอย่างกระทบกับ Timeline

และทำอย่าง ต้องใช้ความเชี่ยวชาญ

PM คงอยู่นิ่งไม่ได้ และต้องหาทางแก้ปัญหานั้นอย่างรวดเร็ว

เพราะอะไรที่กระทบกับ Timeline คืออะไรที่ PM ต้อง concern

ยิ่งถ้า PM ช่วยแก้ปัญหาเชิงเทคนิคได้และทำให้ Resource เชื่อถือ

PM คนนั้นจะมีบารมี และ Resource จะมีใจให้ในการทำงาน

และส่งมอบผลงานที่ดีที่สุดที่เค้าทำได้ออกมาทุกครั้ง

และนี่คือหน้าที่ของ PM

เพราะคุณภาพ และเวลา คือสิ่งที่ PM ต้องรับผิดชอบ

เป็น PM ไม่รู้ Detail ได้ไง เลิกคิดโง่ๆ กันซะทีเหอะ

-

“ถ้าคนที่ทำงานให้เรา ทำไม่ได้

มันเป็นหน้าที่ของเราที่จะไป Cover งานเค้า

ไม่ว่าด้วยวิธีใดก็ตาม และต้องทำให้เค้าพอใจ

ถ้าเรามีบารมีในหัวใจเค้า เค้าจะมอบงานที่ดีที่สุดของเค้าให้เรา

และนี่คือหัวใจของการบริหารจัดการ”

และไม่ใช่แค่ คนๆเดียว แต่เราตัดบริหารจัดการความพึงพอใจ

ของ Resource ทุกคนใน Project เพื่อให้เค้าทำงานที่ดีที่สุดของเค้า

ให้กับโครงการของเรา และนี่คือหน้าที่ของ PM

-

มันไม่มีสูตรสำเร็จในการบริหารจัดการ เพราะมันไม่ใช่ศาสตร์

แต่มันเป็นศิลป์ ที่ทุกคนต้องศึกษาเอาเอง ทำอย่างไรให้ได้บารมี

และทำอย่างไร ให้คนทุกคนมอบใจให้เรา และทำงานเพื่อโครงการ

และนี่คืองานของเรา…

-

สุดท้ายนี้ อย่าคิดว่าเป็น PM มันง่าย แค่ชี้นิ้วสั่งนะครับ

ถ้าพวกชี้นิ้วสั่ง มันต้องมีลิ้นไว้สำหรับชะเลีย เพื่อความอยู่รอด ก็แค่นั้น…

-

และนี่คือ Politic Management ที่มันเป็นศิลป์ไม่ใช่ศาสตร์

ไม่มีคัมภีร์เฉพาะ มีแค่หลักปรัชญาที่ต้องมาประยุกค์ใช้

ใครที่อยากเป็น PM ต้องผ่านด่านนี้ไปให้ได้

-

สวัสดีครับ…

(และอีกไม่นานจะอาจจะมีข่าวดี ว่าผมจะรวมเล่น เรื่องที่เขียน พร้อม Review ความละเอียดใหม่

ไม่รู้ว่าถ้าทำเป็น e-book แล้วจะมีใครอ่านมั้ย???” และคงแจกฟรีครับ ^^)

-

ก็ช่วงนี้ขยัน up blog เพิ่มขึ้นนะครับ สำหรับผม

ก็อย่างที่ blog เก่าๆ ผมเคยบอกครับว่า Technology จะ Shift อีกครั้ง

ซึ่งการ Shift ครั้งนี้ จะ Shift ตั่งแต่ Architecture เลยครับ

Web Technology อาจจะเป็นคำว่าอดีตไปแล้ว…

-

จั่วหัวได้น่ากลัวอีกแล้วครับ Blog ผมวันนี้

ปากดีมากเลย Web Technology จะเป็นอดีต

แล้วคำพูดต่อมาคือ HTML5 ไม่มีอนาคต

และสุดท้าย HTTP จะถูกใช้น้อยลง และน้อยลง…

-

เรื่องมันก็เกิดจากการได้กลับไปคุยกับผู้เป็นอาจารย์ของกระผม

ใช่ครับ ขุนพลสะท้านภพนั่นเอง เราใช้เวลาคุยกันสั้นๆ ประมาณครึ่งชั่วโมง

แต่สิ่งที่อัดอยู่ในการคุยนั้นคือ Keyword ซึ่ง encapsulated คำพูดร้อยพันในคำๆเดียว

และวันนี้ผมก็คงจะ share สิ่งนั้นให้ทุกคนทราบ

-

“ตอนนี้เด็กที่จบมาแล้วทำ Web Technology ก็จะเหมือนกับ

คนรุ่นพี่ที่จบมาแล้วทำ Client-Server โดยไม่คิดว่า มันจะเปลี่ยนเป็น Web Technology”

ขุนพลสะท้านภพพูดไว้…

ใช่แล้วครับ สมัยตอนผมฝึกงานกับเค้า เค้าก็บอกว่า Client – Server มันเป็นอดีตไปแล้ว

จะให้มานั่งเขียน Java Swing มันบ้ารึป่าว เค้าเลยจับผมทำ SOA ตั่งแต่เมื่อ 5ปีที่แล้ว

พอผมจบมา ผมก็เป็นคนยุค Web Technology รุ่นแรกๆ ที่ตลาดขาดแคลน

สุดท้าย ไอ้คนยุค Web Technology พ่วง SOA นี่แหละ ทำให้ผมมีหน้ามีตาจนทุกวันนี้ได้…

แต่วันนี้ มันไม่ใช่วันของ Web Technology อีกต่อไป

-

ตั่งแต่ไอ้ “จานผี” ของท่านศาสดาออกมา กฏของ Computer ข้อนึงก็ถูกฉีกทิ้งไป

กฏนั้นคือคำว่า “Boot Strap” ใช่ครับ iPad ไม่ต้องบูท พร้อมใช้เสมอ

และผมก็คิดว่ามีคนบ้าๆ หลายคน จ่ายตังซื้อ iPad มาวางคู่กะ notebook

เพราะเค้าไม่อยากกลับบ้าน เปิดคอม แล้วรอคอมบูต เพื่อจะเล่นเน็ต

-

แต่คุณรู้มั้ยครับ iPad ไม่ได้ฉีก เฉพาะกฏคำว่า Boot Strap

แต่ iPad กำลังจะฆ่า HTTP Protocol…

-

เน้นย้ำครับ HTTP Protocol ซึ่งสื่อถึง กำพรืดของ Web Technology ทั้งหมด

เล่าก่อน HTTP Protocol นั้นเป็น Stateless Protocol ซึ่งนั้นก็หมายถึงว่า

ตัวมันไม่จำ State ในการทำงาน ดังนั้นจึงเหมาะกับการทำงานแบบ Real-time

เพราะตัว protocol ไม่มี state ดังนั้น state จะอยู่แค่ที่ฝั่ง Server กับ Browser เท่านั้น

มันก็จะมีข้อดีตรงที่ ทำอะไรแล้วมันออนไลน์เลย รวดเร็ว เหมาะสำหรับ PC ตั้งโต๊ะที่ต่อสายแลน

-

แต่… จานผี iPad ของเรา พาสายแลนไปจาก ชีวิตเรา…

ไม่มีสาย อะไรก็คล่องตัวขึ้น…

ถ้าให้คุณคิดว่าคุณจะลงทุนซื้อ notebook ให้ sales ทุกคนเพื่อความคล่องตัว…

คล่องตัวจริงเหรอ อยู่ต่อหน้าลูกค้าแล้ว boot windows นี่อายเค้านะ ลูกค้ารอนะ…

แต่ถ้าลงทุนซื้อ iPad ให้ sales ทุกคน เพื่อความคล่องตัวหล่ะ นอกจากไม่ต้องบูตแล้ว

ยังมีข้อดีตรงที่ ถือแล้วหน้าตาดีขึ้น 10% ดึงดูดลูกค้าได้มากขึ้น ดูเราเป็น brand มีระดับ

ดังนั้น จานผีคือ mobile internet device ที่จะ replace notebook แน่นอนครับ

(ถึงตรงนี้ต้องเน้นย้ำว่าสำหรับ non-geek นะครับ ส่วน geek ที่ชอบ i7 ก็แบบ notebok กันต่อไป)

-

จานผีมาแล้ว….!!!

สิ่งที่มาพร้อมกับ จานผี iPad ก็คือ การไม่มีสาย และการต้องอยู่ในที่อับสัญญาณ

ใช่แล้วครับ ที่อับสัญญาณ เทคโนโลยีอย่าง http ที่เป็น stateless protocol ก็หมดท่าสิครับ

เพราะมันเก็บ state ไม่ได้… ถ้า connection หลุด ก็เน่าเลยสิครับ… transaction ที่ทำค้างไว้…

-

แล้วทำไงหล่ะ ???

enhance http protocol ให้เป็น stateful protocol ???

ถ้าทำแบบนี้ ก็คือเพิ่ม overhead ที่ฝั่ง browser และ server ครับ

ซึ่งผมก็ไม่เข้าใจว่า html5 จะมีโหลด offline ไปทำไม ปัญหามันไม่ได้อยู่ตรงนั้น

แต่ปัญหามันอยู่ตรง http protocol ที่ต้องไป…

-

ถ้า http protocol ไป แล้วอะไรจะไปตามบ้าง…

ก็อะไรที่ on top อยู่บนมันไงหล่ะ

HTML5, Web Browser, SOAP, Restful, UDDI, …

ใช่แล้วครับ ไอ้พวกนี้ ไปหมดเลย…

-

ขอขยายความ HTTP นิดนึงครับ

HTTP มันเป็น Protocol แบบโปรย มันก็คือไม่มีการ fix เส้นทางในการวิ่งอันไหนเร็วก็ส่งทางนั้น

ก็ดีก็คือสิ่งข้อมูลได้สะดวก แต่ข้อเสียก็คือเรื่อง security เพราะคุณเจอ Man in The Middle ได้ตลอด

HTTP ไม่ได้แบ่งว่าอันไหนสำหรับ User Interface อันไหนสำหรับ System Interface

SOAP ยังวิ่งปนกับ HTML เลย… ไอ้บ้า เอาหน้าจอที่ user ใช้มาวิ่งท่อเดียวกับ transaction เรื่องกะตัง…

นี่ถ้าเอา SOAP ไปวิ่งบน ESB อีกนะ เฮ้อๆๆๆๆๆๆๆๆๆๆๆๆ เละเทะไปหมด

ใช่ครับ protocol ใหม่ควรมีการแบ่ง public cloud, protected cloud, private cloud และ personal cloud

HTTP เป็น stateless อันนี้คงไม่ต้องพูดแล้วมั้ง ถ้าสัญญาณ internet หายก็จบกัน

HTTP ไม่มีวิธีการ encryption ที่เป็นมาตรฐาน… อันนี้ไม่ใช่ https นะครับ เพราะ https คือการหุ้ม http ไปทั้ง

protocol แต่มันไม่ใช่การกำหนด security privacy ใน protocol ครับ

-

คำพูดสุดท้าย ลาก่อน HTTP…

-

อะไรจะมาแทน HTTP???

สิ่งที่มาแทน แน่นอนต้องติดต่อกันได้แบบ Asyncrhonous หรือ event notification หรือ stateful นั่นเอง

และสิ่งที่มาต้องอยู่บน Tablet และเป็น “สิ่งที่ศาสดายอมรับได้” เพราะเจ้าตลาด Tablet คือศาสดา…

-

สิ่งที่มานั่นก็คือ Proprietary Application บนจานผีแต่ละชนิด (iPad, Android, … ผมยังไม่เห็นผู้เล่นอื่นในตลาดนี้)

เพราะ Application พวกนี้ เขียนด้วยภาษาเฉพาะ Platform เราจะย้อนกลับไปยุค Proprietary ของ Client-Server อีกครั้ง…

เป็นสงครามของ Platform แบบใหม่ ที่ไม่รู้ว่าใครจะเป็นผู้ชนะ (ถ้ายุค Cli-Serv ผู้ชนะคือ Microsoft)

แต่ Platform เหล่านี้ต้องประมวลผลแบบ event-driven ซึ่งเป็น asynchronous

แต่เราโชคดีที่พระเจ้าสร้าง XML ขึ้นมาเป็นภาษาสำหรับส่งข้อมุลกลาง

ดังนั้น ถึงจะ Proprietary แต่ก็ยังโยน XML ไปมาระหว่างกัน แค่ Schema ไม่เหมือนกัน…

คำว่า Proprietary จึงลดลง เพราะ iPad หรือ Android ก็ใช้ Scheman ร่วมกันได้

แค่คนละ engine ในการ process xml และคนละภาษาในการ Coding ก็แค่นั้น

-

ตอนนี้ผมยังมองไม่เห็นอะไรที่จะมาแทน HTTP ครับ

เพราะมาตรฐานยังไม่เกิด จนกว่ายุค Proprietary จะแผ่วลง

ก็เหมือนกับตอน Cli-Serv แหละครับ คนต้อง Suffer กันมากๆ จนสุดท้ายเกิด

Internet และ HTTP เป็นมาตรฐานกลาง จนกลายเป็น ยุคของ Web Technology

-

แต่ผมใบ้ให้ครับว่า ถ้ายุคนั้นมาถึง คุณจะได้เห็นการเปลี่ยนโฉมหน้าของ Network ขนานใหญ่

เพราะ Protocol เปลี่ยน คุณจะได้เห็นการเปลี่ยนการแบ่ง layer ของ Network ใหม่

อย่างที่ผมบอก User Interface ไม่ควรวิ่งรวมกับ System Interface ครับ

นอกจากนั้นมันยังเพิ่ม Permission เพื่อรองรับ Public Cloud, Protected Cloud, Private Cloud และ Personal Cloud

-

สุดท้าย อีก 10 ปีเป็นอย่างต่ำ คำว่า Aspect-Oriented และ Artificial Intelligence จะมาถึง…

ubiquitous computing ที่แท้จริงจะมาถึง…

-

สวัสดีครับ…

-