Changes คือสัจธรรมของ Software Development Project มันเป็นปัญหาคลาสสิกที่วนเวียนอยู่กับเราทุกคนและทุก Project เอาเป็นว่าตั้งแต่ทำงานมา 8 ปีกว่า ทุก Project ที่ผมเกี่ยวข้องด้วยไม่ว่าจะตำแหน่งหน้าที่อะไรก็ต้องเจอเรื่องนี้ทุกครั้งไป ครั้งนี้ก็ไม่ต่างกัน แหะๆ

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

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

• น่าจะดีนะถ้าไม่มี Change เกิดขึ้นใน Project ของเราเลย
• น่าจะดีนะถ้าเรามีกระบวนการจัดการ Change ที่ดีขึ้นกว่านี้
• น่าจะดีนะถ้าเราจะลดเวลาที่ใช้ในการสื่อสารกันระหว่าง Dev, QA และ Product Manager
• น่าจะดีนะถ้าเราจะมีวิธีการทำ Requirement Analysis แบบใหม่ที่ทุกคนมีส่วนร่วม
• น่าจะดีนะถ้าเราสามารถสร้างความรู้สึกเป็นเจ้าข้าวเจ้าของ Project นี้ให้กับทุกคนในทีม
• น่าจะดีนะถ้าเราสามารถลดความเข้าใจผิดเรื่องงานระหว่างกัน
• น่าจะดีนะถ้าเราทุกคนจะยิ้มได้เมื่อเกิด Change ขึ้น

เมื่อได้โจทย์แล้วก็ถึงเวลาคิดหาผลลัพธ์ซึ่งได้ออกมาแบบนี้ครับ …

คำเตือน: โปรดใช้วิจารณญาณในการอ่าน เชื่อ และนำไปปฏิบัติ

1. ตั้งกฎไว้เลยว่าเราจะไม่เริ่มทำงานถ้า Requirement ยังไม่เรียบร้อย
2. ทำ Requirement Analysis อย่างละเอียดตั้งแต่แรก
3. ใช้ Operational Concept มาช่วยในการทำ Requirement Analysis
4. กำหนดกฏเกณฑ์การรับ/ไม่รับ Change ที่แน่นอน ไม่ใช่ใครสั่งอะไรก็ต้องทำตาม
5. ให้ QA มาช่วยทำ Requirement Analysis แล้วเอา Dev มาเขียน UAT บ้างเพื่อแลกเปลี่ยนมุมมอง Requirement Analysis จะได้สมบูรณ์ขึ้น
6. Dev และ QA และ Product Manager ต้องช่วยกันกำหนดหัวข้อสำคัญที่ต้องพิจารณาเวลาคุยถึง Requirement หรือ Design เช่น เรื่อง data format, exception, condition, state diagram และ data flow
7. ทำ Pair Implementation ซะเลย เอา Dev และ QA มานั่งทำงานไปพร้อมกัน Dev เขียนโค๊ดไป QA เตรียม Test Case, Test Data เสร็จแล้วก็ลองเทสตรงนั้นเลย เจ๊งก็แก้ทันที ไม่ต้องเสียเวลารออะไรต่ออะไรกัน
8. แบ่งงานเป็นส่วนย่อยๆเพื่อสร้าง Focus ที่ชัดเจนขึ้น ไม่ต้องคิดมาก ไม่ต้องคิดไกล ไม่ต้องพูดนอกเรื่องเวลาทำ Requirement Analysis หรือ Design
9. มี Standup Meeting เพื่อลดเวลาในการสื่อสาร เวลาในการรอใครต่อใครตอบคำถามระหว่าง Dev, QA และ Product Manager
10. ดึง Product Manager เข้ามาช่วยยืนยันความถูกต้องของงานบ่อยๆ เพื่อลดการเกิด Change ขนาดใหญ่
11. ไม่ต้องเสียเวลารอคำตอบ ไม่ต้องเสียเวลาคุยอะไรมากหรอก ทำๆไปก่อนแหละ (แต่ทำงานเล็กๆนะ) ถ้าผิดค่อยมาแก้ทีหลัง
12. เผื่อ Buffer ไว้สำหรับ Change พวกนี้บ้าง
13. ทำ Code Review และ Test Review เพื่อยืนยันความถูกต้องและความเข้าใจที่ตรงกันก่อนทำงานขั้นต่อไป
14. ขอเวลาวันละ 10 นาทีมา Review พวก Design/Implementation/Test Case กันหน่อยว่าไม่มีอะไรเปลี่ยนแปลง
15. ไม่รับ Change ทันที เอาไปใส่ Product Backlog ไว้แล้วค่อยว่ากันวันหลัง
16. อยากให้มีมุมมองของลูกค้าเพิ่มเข้ามาบ้าง ขอให้ Support Engineer มาช่วยแล้วกัน
17. จัดลำดับความสำคัญของ Requirement หน่อยก็ดีนะ จะมี Change ทั้งทีจะได้คุ้มค่าที่จะเสียเวลาทำหน่อย
18. มีข้อมูล/หลักฐาน/ตัวเลขอะไรก็ได้ที่บอกเราได้ว่าถ้ารับ Change ตัวนี้แล้วจะส่งผลกระทบแค่ไหนกับงานโดยรวม Change Management จะได้มีหลักการมากขึ้น
19. เอาส่งเมล์แนบเอกสารที่อยากให้รีวิวมันไม่ได้ผล ก็เปลี่ยนเป็นเดินไปหาที่โต๊ะคนที่เราอยากให้รีวิวเอกสารให้ แล้วอธิบายให้เค้าฟังว่าอะไรเป็นอะไร ขอความเห็นเค้าตรงนั้นเลย
20. คุยๆๆ เรื่อง Requirement หรือ Design แล้วก็ปล่อยให้คำพูดและความคิดหายไปกับสายลม … อย่าให้เป็นแบบนั้น … อัดเสียงไว้บ้างหรืออัดวิดีโอก็ได้ (iPhone มีกันแทบทุกคน) จัดกลุ่มให้เป็นหมวดหมู่ เก็บไว้เป็น Requirement Analysis and Design document (รูปแบบใหม่)
21. ไม่รับ Change อะไรทั้งสิ้น (เบื่อ)

ทั้งหมดนี้เป็นแค่แนวคิดของผมเอง อาจจะมีทั้งถูกและผิด หรืออาจจะผิดหมดเลย แล้วแต่มุมมองและสถานการณ์ที่แต่ละคนเจอ … “Ideas are not solutions.” แนวคิดไม่ใช่ทางออกนะครับ ที่เหลือที่ต้องทำคือเลือกแนวคิดที่เหมาะสมที่สุดไปประยุกต์ใช้กับงานของเอง จะหยิบไปใช้เดี่ยวๆ จะหยิบไปใช้หลายๆอัน จะเอาไปคิดต่อยอดเป็นแนวคิดใหม่ๆ หรือจะเอาหลายๆแนวคิดมารวมกัน ก็แล้วแต่จินตนาการเพื่อนๆจะสรรค์สร้าง

ป.ล. ผมใช้กระบวนการคิดที่เรียกว่า Productive Thinking เพื่อพยายามจะแก้ปัญหานี้ครับ คร่าวๆ Productive Thinking ประกอบด้วยสองส่วน หนึ่ง Creative Thinking คือการคิดและรวบรวมแนวคิด (Idea) ต่างๆให้ได้มากที่สุดโดยไม่พิจารณาและตัดสินว่ามันดีหรือไม่ดี กับสอง Critical Thinking คือการที่เรามาพิจารณาเจ้าแนวคิดทั้งหมดที่เรารวบรวมไว้ทีละอันเพื่อดูว่าจริงๆแล้วอะไรที่เหมาะกับสถานการณ์ที่เราเจออยู่มากที่สุดเพื่อนำมาซึ่งทางออก (Solution) ของปัญหา ซึ่งทั้งหมด 21 ข้อข้างบนนั้นมาจาก Creative Thinking ของผม … ส่วน Critical Thinking ผมยกให้เป็นหน้าที่ของเพื่อนๆครับ

การอ่านชีวประวัติ แนวความคิดและหลักการดำเนินชีวิตของคนเก่งเป็นหนึ่งในเรื่องที่สนุกสำหรับผมครับ เป็นอีกทางหนึ่งที่ช่วยให้เราได้เปิดมุมมองให้กว้างขึ้น บางครั้งก็จะได้อะไรดีๆมาปรับใช้กับชีวิตเราเอง พอดีผมไปอ่านเจอบทความที่มีชื่อว่า “The Way I Work” จาก Inc.com (ชอบเวปนี้มาก) ซึ่งส่วนตัวคิดว่าเป็นเรื่องที่น่าสนใจมากครับที่เราจะได้เรียนรู้ว่าคนที่สร้างเนื้อสร้างตัว สร้างธุรกิจที่มั่นคงขึ้นมา (ทั้งหมดเป็นธุรกิจบน Internet) นั้นเค้าทำได้อย่างไร เค้ามีหลักการอะไรในการทำงานและการใช้ชีวิต ผมขอถ่ายทอดต่อมาโดยใช้ตารางข้างล่างครับ

The Way I Work

The Way I Work เป็นซีรี่ย์ที่มีหลายบทความเขียนโดยนักธุรกิจรุ่นใหม่หลายต่อหลายคน แต่ที่โดนใจผมที่สุดมีอยู่สามคนครับ หนึ่ง Jason Fried ผู้ก่อตั้ง 37signals บริษัทสร้างซอฟต์แวร์เกี่ยวกับ Project Management และอื่นๆ คนนี้ผมชอบมาก เค้ามีแนวคิดที่ไม่เหมือนใคร ไม่ได้บ้านะ คือคิดด้วยตัวเอง ทำตามที่ตัวเองคิด แล้วก็ประสบความสำเร็จได้ด้วยความคิดที่ค่อนข้างจะขวางโลกนั่นแหละ

สอง Matt Mullenweg จะว่าไปผมเป็นหนี้บุญคุณเค้าเลยนะ ก็คนนี้เป็นคนเขียน WordPress ระบบที่ผมใช้ทำ Chapterpiece.com นี่แหละ ฮ่าๆ จากเด็กนักเรียนธรรมดาที่เริ่มต้นเขียน Open-source software จากในห้องนอนมาเป็นเจ้าของหนึ่งใน CMS ที่ได้รับความนิยมมากที่สุดในโลก จากคนๆเดียวกลายเป็นบริษัทที่มีทีมงาน 40 คนจากทั่วโลก เก่งมากๆ

สุดท้าย Rashmi Sinha หญิงเก่งจากอินเดียที่มาได้ดิบได้ดีที่ซานฟรานซิสโก สหรัฐอเมริกา คนนี้เป็นผู้ก่อตั้ง SlideShare.net เวปไซต์ที่เป็นแหล่งรวบรวมและแบ่งปัน Slide หรือ Powerpoint นั่นแหละ (ผมก็เป็นคนนึงที่ใช้บริการ SlideShare เหมือนกัน) ด้วยใบปริญญาเอกสาขาจิตวิทยามาเป็นเจ้าของเวปไซต์ที่มีสมาชิกมากกว่า 50 ล้านคน น่าทึ่งเนอะ

	Jason Fried @37signals.com	Matt Mullenweg @wordpress.org	Rashmi Sinha @slideshare.net
ตื่นนอน	6.38 ทุกเช้าและไม่ใช้นาฬิกาปลุก	1 ชั่วโมงหลังจากพระอาทิตย์ขึ้นและไม่ใช้นาฬิกาปลุก	ไม่มีข้อมูล
สิ่งแรกที่ทำ	ชงชาและผ่อนคลายซักหน่อย	พยายามไม่เข้าใกล้คอมพิวเตอร์อย่างน้อยก็ 1 ชั่วโมง	(เมื่อถึงออฟฟิศแล้ว) เช็คอีเมล์ ถ้ามีเรื่องด่วนก็จะตอบกลับทันที
อาหารเช้า	กินวาฟเฟิลกับถั่วพิตตาชิโอ้ ถ้าวันไหนหนาวๆก็กินข้าวโอ๊ตอุ่นๆ	ไม่กิน กาแฟก็ไม่ชอบ	ไม่มีข้อมูล
ออกกำลังกาย	ไปโรงยิมตอนเช้า ประมาณ 1 ชั่วโมง	ไม่มีข้อมูล	ไปโรงยิมหลังเลิกงาน
สถานที่ทำงาน	ก็แล้วแต่ บางครั้งทำงานที่บ้าน 1 สัปดาห์ เบื่อแล้วก็เข้าออฟฟิศ 1 สัปดาห์	เข้าออฟฟิศสัปดาห์ละหนึ่งครั้ง ที่เหลือทำงานที่บ้าน	ทำงานที่ออฟฟิศทุกวัน
มาถึงออฟฟิศ	ประมาณ 10.30	ไม่มีข้อมูล	ราวๆ 9.30-10.00
ทำอะไรบ้าง	เขียน (เขียนบล็อกเมื่อมีอารมณ์จะเขียน)	เดินทางไปร่วมงาน WordCamps	ประชุมกับทีมงาน
	คิดหาทางทำให้อะไรๆมันง่ายขึ้น	คิดถึงการพัฒนา Wordpress	คิดอะไรใหม่ๆให้ SlideShare
	บ่ายๆก็จะอ่านหนังสือหรือเปิดเวปดูนู่นนี่ (หาความรู้เข้าสมอง)	เขียนโค๊ด	คุยกับลูกค้า นักโฆษณา และนักธุรกิจ
		เขียนบล็อกเมื่อมีอารมณ์จะเขียน	เป็นพี่เลี้ยงให้นักธุรกิจใหม่ๆ
หลักการทำงาน	"Less is less" น้อยคือน้อย พยายามทำอะไรให้น้อยแต่มีประสิทธิภาพ	เวลาทำงานคือ 24 ชั่วโมง อยากทำ/ไม่ทำตอนไหนก็ได้	ชอบลองผิดลองถูก แก้ไข และทำใหม่มากกว่าจะเสียเวลาคิดนานแต่ไม่ลงมือทำซักที (คิดนานก็ผิดอยู่ดี)
	เกลียดการประชุม	พยายามเลี่ยงประชุมตอนเช้า (เร็วสุดขอซัก 11 โมงละกัน)	ไม่รับโทรศัพท์เบอร์แปลกๆ
	กำจัดสิ่งรบกวนออกไปให้ได้มากที่สุด	พยายามลดเวลาที่ใช้กับการรับส่งอีเมล์ (ลองดูโปรแกรมนี้ Rescue Time)	คุยกับทีมที่เดลีผ่าน Skype
		สร้างสมาธิด้วยการฟังเพลงเดิมซ้ำๆเป็นร้อยรอบ ปิดอีเมล์และ IM ด้วย	ใช้โปรแกรมชื่อ Pivotal Tracker เพื่อติดตามความคืบหน้าของงานทั้งที่ซานฟรานซิสโกและเดลี
		เวลาที่ดีที่สุดในการทำงานคือช่วงสายๆและดึกมากๆ (ตี1-ตี5)	ไม่คุยเรื่องงานที่บ้าน
		ให้ความสำคัญกับการนอน นอนได้ตลอดเวลาที่บ้านหรือที่ทำงาน กลางวันหรือเย็น
การพัฒนาธุรกิจ	ไม่มีแผนธุรกิจที่ใหญ่โตหรือยาวไกล	หาโอกาสเรียนรู้เรื่องธุรกิจจากผู้มีประสบการณ์	ติดตามตัวเลขการใช้งานทุกวัน เช่น จำนวนคนสมัครใหม่ จำนวนคนอัพเกรดมาเป็นลูกค้าที่จ่ายเงิน
	ไม่มีการตัดสินใจใหญ่และยาวเพราะส่วนใหญ่แล้วมันจะผิดทุกครั้งไป ตัดสินใจอะไรที่เล็กๆแล้วใกล้ตัวดีกว่า	ติดตามตัวเลขที่สำคัญทุกวัน เช่น จำนวนคนเข้า WordPress.com จำนวนคนดาวน์โหลด WordPress …
	ติดตามความคืบหน้าของเวปไซต์แบบเรียลไทม์ เช่น จำนวนคนสมัครใหม่ จำนวนคนยกเลิกบริการ …	อยากสร้างให้ WordPress อยู่ได้อีกนานๆซัก 10 - 30 ปี
		อยากทำให้ WordPress เป็นเหมือน Google, eBay, Amazon ที่ช่วยเป็นเครื่องมือให้ลูกค้าหาเงินได้มากกว่าที่บริษัทเหล่านั้นได้มา
การพัฒนาผลิตภัณฑ์	ไม่ค่อยสนใจเสียงบ่น เสียงเรียกร้องให้ทำนั่น อย่าทำนี่	พยายามพบปะพูดคุยกับลูกค้าให้มากที่สุดเพื่อเก็บข้อมูลความต้องการของพวกเขา	ใช้เวลาช่วงบ่ายพบลูกค้า
	ทำสิ่งที่เราอยากทำ สิ่งที่เราชอบแล้วคนอื่นก็จะชอบตามไปเอง	สร้าง WordPress ให้ตรงความต้องการเหล่านั้นมากที่สุด	ใช้ Agile Software Development ที่ SlideShare มี Scrum meeting ทุกเช้าวันจันทร์
			พยายามทำให้ช่วงเช้ามีเวลาให้กับงานเพื่อจะที่คิดอะไรใหม่ๆให้ SlideShare
			ชอบให้มีการระดมสมองและความคิดในการพัฒนาสิ่งใหม่ๆ
			พกกระดาษโน๊ตติดตัวเสมอใช้เพื่อจดความคิดใหม่ๆแล้วให้ทีมงานไปต่อยอด
พนักงาน	พนักงาน 16 คน	พนักงาน 40 คนทั่วโลก	มีสองออฟฟิศ ซานฟรานซิสโกและเดลี (อินเดีย)
	ไม่มีผู้จัดการ ไม่มีลำดับขั้นในบริษัท	ทุกคนทำงานที่บ้าน	มีห้องส่วนตัวแต่ไม่ใช้เพราะชอบทำงานใกล้ชิดทุกคนมากกว่า
	อย่าทำเหมือนพวกเขาเป็นเด็ก ตราบใดที่ทำงานเสร็จ ไม่ต้องสนใจว่าวันๆนึงเค้าจะทำอะไรบ้าง	คุยกันผ่าน Skype	จ้างคนที่ใช้ SlideShare อยู่แล้วเพราะคนเหล่านี้จะเข้าใจดีว่าอะไรคืออะไรและมีมุมมองของลูกค้าจริงๆด้วย
	พาไปเที่ยวบ้าง ปีละสองครั้ง	ร่วมงานกับคนที่สร้างแรงจูงใจในการทำงานให้ตัวเองได้ (self-motivated) และเป็นคนที่มีความสามารถแล้วปล่อยเค้าทำงานไป	มีปาร์ตี้เล็กๆทุกวันศุกร์เย็น ถึงงานจะยังไม่เสร็จเราก็ดื่มเบียร์กันได้
กลับบ้าน	6 โมงเย็น	ไม่มีข้อมูล	ประมาณ 1 ทุ่ม
งานอดิเรก	ทำสวน	อ่านหนังสือธุรกิจและนิยาย	เดินเขา
	ตีกลอง	นอน	เที่ยวชมธรรมชาติ
	ทำอาหาร	ฟังเพลงแจ๊ซ	อ่านหนังสือ นิยายล้วนๆ
		ถ่ายรูปสถานที่ต่างๆ
กลางคืน	ทำงานบ้าง	สังสรรค์	กินข้าวแล้วนอน
	อ่านหนังสือ	ทำงาน	ไปโรงยิม
	ดูทีวี		สังสรรค์
			คุยงานกับทีมที่เดลีอีกนิดหน่อย

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

สวัสดีครับ … รายงานผลการจัดกิจกรรมครับ

Project Planning — How to

พวกเราใช้เวลาช่วงแรกของการพูดคุยมาทำความเข้าใจร่วมกันครับว่า Project Planning คืออะไร มีองค์ประกอบอะไร มีขั้นตอนอะไรบ้าง … ใช้เวลาประมาณ 1 ชั่วโมง ลองดูครับว่าเราคุยอะไรกันบ้าง

• Project คืออะไร = http://www.youtube.com/watch?v=f0Lqvvs5Dys&t=0m8s
• Project Management มีอะไรบ้าง = http://www.youtube.com/watch?v=f0Lqvvs5Dys&t=3m59s
• สามเหลี่ยมทองคำ = http://www.youtube.com/watch?v=f0Lqvvs5Dys&t=9m49s
• Project เกิดขึ้นมาได้อย่างไร = http://www.youtube.com/watch?v=AFX2fRsHluo&t=0m1s
• ที่มาของ Project Planning = http://www.youtube.com/watch?v=AFX2fRsHluo&t=8m14s
• Project Plan และองค์ประกอบสำคัญ = http://www.youtube.com/watch?v=VSlQgBH5X3I&t=0m1s
• Work Breakdown Structure = http://www.youtube.com/watch?v=VSlQgBH5X3I&t=6m55s
• Network Diagram + Estimation = http://www.youtube.com/watch?v=KT7uTKbPuZs&t=0m1s
• Critical Path = http://www.youtube.com/watch?v=KT7uTKbPuZs&t=10m25s
• Flexibility Matrix = http://www.youtube.com/watch?v=ury2TL2-RFg&t=0m1s

Problems

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

เรื่องมีอยู่ว่าบริษัท x เป็นบริษัทที่รับงานจากภายลูกค้ามาทำ (Outsource นั้นแล) โดยที่ธุรกิจไปได้สวยมีงานเข้ามาตลอด ดูเหมือนไม่มีปัญหาใช่มั้ย ไม่หรอก ปัญหามันคือว่ามีงานเข้ามามากเกินไปจนทำให้ทำกันไม่ทันเลยหนะซิ นี่ก็เลยเป็นปัญหาที่ทำให้ Project delays หลังจากที่วิเคราะห์สถานการณ์และปัญหาอย่างละเอียดแล้ว ดูเหมือนว่ามีเรื่องที่เราต้องช่วยกันคิดแก้ไปอยู่หลายประเด็น ดังนี้

• Overcommitment … มีหลายครั้งที่ทีมขายของ (Sales) ไปสัญญิงสัญญากับลูกค้าจะเวอร์เกินจริง ลูกค้าถามอะไรขออะไร ได้ครับตลอดเลยโดยหารู้ไม่ว่านั้นคือหายนะของทีมพัฒนาโดยแท้

 

• PM No Authority … เนื่องจากการจะทำงานกับ Project เนี่ยะมีคนหลายกลุ่มหลายแผนกที่มีส่วนร่วม อย่างที่เห็นก็ทีมขาย ทีมพัฒนา ทีม PM สถานการณ์ตอนนี้คือคนที่เป็น Project Manager ก็มือใหม่แถมยังมีเรื่องความอาวุโสเข้ามาเกี่ยวข้อง มันเลยเป็นเรื่องยากที่จะได้รับความร่วมมือและความช่วยเหลือจากหัวหน้างานทีมอื่น ไปๆมาๆ PM เลยต้องเอางานพวกนั้นมาทำเอง เศร้ามั้ยหละ

 

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

 

• No Commitment … นอกจากมี Overcommitment กับลูกค้าแล้ว ยังเจอปัญหา No Commitment กันภายในอีก ไม่มีใครยอมบอกว่าจะทำงานนี้ให้เสร็จเมื่อไร แบบนี้ PM จะวางแผนได้อย่างไรหละ?

 

• No Management Support … อันนี้ปัญหาใหญ่เหมือนกัน บางครั้ง PM ก็มีสิทธิมีเสียงมีขอบเขตอำนาจแค่ระดับหนึ่ง เมื่อเรื่องราวมันใหญ่โตเกินกว่านั้น เราคงต้องหวังพึ่งคนที่อยู่เหนือขึ้นไป แต่โลกของความจริงไม่สวยงามแบบนั้นหรอกเพราะเรามองไปแล้วไม่เจอใคร อะ ต่อให้เจอบางครั้งความช่วยเหลือมันก็ไม่เกิดเพราะ “พี่ไม่เห็นว่ามันจะเป็นปัญหาตรงไหนเลย” ฮ่าๆๆ

Solutions

เจอปัญหารุมเร้าขนาดนี้ทำยังไงดี? โชคดีที่วันนั้นมีเพื่อนๆหลายคนที่มีประสบการณ์เจอเรื่องแบบนี้มาก่อน ข้อเสนอ แนวทางป้องกันและแก้ไขจึงพรั่งพรูออกมาเพียบ …

• Overcommitment หรอ … ป้องกันได้โดย (1) PM/Technical Staff/Sales มานั่งคุยกันก่อนว่าขอบเขตของความเวอร์อยู่ตรงไหน ฮ่าๆ เอาเป็นว่าตกลงร่วมกันก่อนว่าอะไร “พอ” จะทำได้หรือไม่ได้ (2) เวลาไปคุยกับลูกค้าถ้าเป็นไปได้ก็หิ้วกันไปทั้งสามคนเลย PM/Technical Staff/Sales มีอะไรจะได้มองหน้ามองตากันทัน (3) การประเมินผลงานของ Sales ไม่ควรจะจบแค่ขายงานได้นะเพราะจะไม่มีใครมารับผิดชอบความเวอร์ที่ไปบอกลูกค้าไว้ ทางที่ดีน่าจะประเมินผลงานร่วมกันเป็นทีมใหญ่เลย กำไรมากก็ได้ส่วนแบ่งมาก กำไรน้อยก็ได้ส่วนแบ่งน้อย (4) เรื่องผลตอบแทนของ Sales ถ้าเป็นไปได้ก็ควรแบ่งจ่ายนะครับ เช่น ขายงานได้เอาไป 5% ทำงานผ่านไปครึ่งทาง 5% งานเสร็จ 5% แบบนี้จะได้อยู่ร่วมหัวจมท้ายกับทีมด้วย แต่ถ้ามันป้องกันไม่ทันแล้วหละ Sales โม้ไปแล้ว ทีมพัฒนาทำไม่ได้จริง มีคำแนะนำว่าต้องกล้าบอกความจริงกับลูกค้าไปครับ ก็ต้องขอความเห็นใจและหาทางออกร่วมกัน

 

• PM No Authority หรอ … ถ้าตามงานแบบไม่เป็นทางการแล้วไม่ได้ผลก็คงต้อง (1) ขอความช่วยเหลือจากหัวหน้า (2) จัดประชุมเพื่อตามงานโดยให้หัวหน้าเรา (CEO, GM, MD, ใครก็ได้) เข้าด้วย พยายามทำให้มันเป็นทางการครับ เอางานมาวางแล้วก็ Track ตรงนั้นแหละ (3) ถ้าหัวหน้าๆไม่มีเวลากัน ก็ส่งอีเมล์ทวงงานไปโดย cc ทุกคนในโลก (อันนี้อาจจะเวอร์ไป) โดยเฉพาะหัวหน้าเรา เอาเป็นว่าเป็นการกดดันทางอ้อมผ่านอีเมล์ครับ เขียนด้วยถ้อยคำที่สุภาพหน่อยละกันครับ ฮ่าๆ (4) ดื้อนักใช่มั้ย … ลากเข้าวงเหล้าครับ จบ

 

• No Process + No Commitment + No Management Support … มีสาเหตุมาจากเรื่องเดียวกันคือหัวหน้าไม่ค่อยจะให้ความร่วมมือ หรืออีกนัยหนึ่งหัวหน้าไม่คิดว่าเรื่องที่เราบ่นๆอยู่เนี่ยะ “ไม่ใช่ปัญหา” อืม ข้อนี้น่าสนใจ พวกเราได้ข้อสรุปกันว่าลองใช้ Risk Management เข้ามาช่วยซิ ทำยังไง? ก็ตอนเริ่ม Project เราควรต้องมี Kick-off meeting ที่จะเชิญหัวหน้าทุกคนที่เกี่ยวข้องเข้ามาคุยกันว่างานนี้จะทำอะไร ใครรับผิดชอบส่วนไหน และมีความเสี่ยงอะไรที่อาจจะเกิดขึ้นได้บ้าง ตรงนี้คือการทำ Risk Identification ครับ เก็บข้อมูลเหล่านี้ลงใน Excel Spreadsheet ก็ได้ ในไฟล์นี้จะมีรายละเอียดของความเสี่ยงแต่ละตัวเช่น ความเสี่ยงคืออะไร มีโอกาสที่จะเกิดขึ้นแค่ไหน เกิดแล้วส่งผลกระทบแค่ไหน มีวิธีป้องกันไม่ให้เกิดเป็นปัญหาอย่างไร แล้วถ้าเกิดปัญหาขึ้นมาจริงๆจะทำยังไงดี ประโยชน์ที่ได้จากตรงนี้คือเราทำหน้าที่ของเราแล้วครับนั่นคือแจ้งให้หัวหน้าทราบถึงความเสี่ยงของ Project จากนั้นเราก็ต้องคอยติดตามดูด้วยว่าความเสี่ยงพวกนี้มันเลวร้ายลงมั้ย มีอะไรที่กลายเป็นปัญหาแล้วบ้าง แล้วก็เอาข้อมูลตรงนี้อัพเดทให้หันหน้ารู้เรื่อยๆครับ ถ้าหัวหน้าคิดว่าไม่เป็นปัญหา เราก็คงทำอะไรไม่ได้เพราะเรื่องบางเรื่องมันอยู่นอกเหนือความรับผิดชอบของเรา เมื่อ Project เกิด Delay ขึ้นมาจริงๆ อย่างน้อยเราก็ไม่ได้ผิดที่ไม่แจ้งปัญหาให้ทราบแต่เนิ่นๆครับ … ไม่อยากจะพูดว่าผิดเพราะบางคนไม่คิดว่ามันเป็นปัญหา ไม่หาทางป้องกันแก้ไข … แต่จะมีเหตุผลอื่นมาแก้ต่างให้คนนั้นนั้นมั้ยหละ? ฮ่าๆ

ปัญหาที่เหลือที่เตรียมไว้ไม่ได้คุยเลยครับ หมดเวลาก่อน ฮ่าๆ

Thank You

กิจกรรมเมื่อวานสนุกมากครับ ขอบคุณเพื่อนๆทุกคนที่สละเวลามาร่วมงานนะครับ อีกสองเดือนเจอกันใหม่ หัวข้อกิจกรรมไว้ค่อยตกลงกันอีกทีนะครับ

เอ เต้ แอน โบ๊ต ตี๋ ตั๋ง

ติ แจง มอน ปู ภัท เม่น … 1 โหลพอดี

ปล. สู้ๆนะโบ๊ต ทุกคนเป็นกำลังใจให้ครับ

ลงทะเบียนครบตามจำนวนเรียบร้อยแล้วครับ 15 คน ขอบคุณที่ให้ความสนใจกันนะฮะ หลังจากได้รวบรวมผลจากแบบสอบถามและอีเมล์ ลักษณะการจัดกิจกรรมน่าจะออกมาเป็นแบบนี้ครับ

Project Planning — Introduction

จากแบบสอบถามนะครับ มีเพื่อนบางคนที่ไม่ได้เป็น Project Manager ซึ่งเป็นคนที่มีส่วนรับผิดชอบโดยตรงกับ Project Planning ประกอบกับมีน้องบางคนที่มีประสบการณ์การทำงานกับ IT Project มาน้อยกว่า 1 ปีด้วย ผมเลยจะขอใช้เวลาช่วงแรกพูดถึงเรื่องราวทั่วไปของ Project Planning ก่อนครับ หวังว่าจะช่วยให้การพูดคุยในช่วงหลังมีอรรถรสมากขึ้น

อืม … ตอนแรกเลยตั้งใจจะให้ช่วงนี้มี Workshop ด้วยนะ คือแบ่งกลุ่มแล้วให้ทุกคนมีส่วนร่วมในการลองทำ Project Planning จริงๆ (ผมจะหากรณีศึกษาตัวอย่างมาให้ลองกัน) แต่มีเพื่อนบางคนกลัวว่าเวลาจะไม่พอ (เห็นด้วยครับ ฮ่าๆ) เอาเป็นว่ามีกรณีศึกษามาแล้วพวกเราช่วยกันทำไปพร้อมๆกันแล้วกันเนอะ คงลดเวลาลงได้บ้าง

Project Planning — Common Problems

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

• Project นี้มันใหญ่มากเลยทำยังไงดี?
• เห้ย Developer ส่งงานช้าอีกแล้วเวลา Test เหลือนิดเดียวเอง ทำยังไงให้เสร็จทันเนี่ยะ?
• เฮ้อ Estimate ทีไรมั่วตลอดเลย ทำไงดี อยากได้ตัวเลขที่มันเชื่อถือได้หน่อยอะ
• งานไม่เดินเลยครับ ทำไม Plan อะไรไว้แล้วมันไม่มี Progress เลยหละ … เราจะไปตามเรื่องกับใครได้บ้าง?
• Project Planning … สมชื่อคือแพลนแล้วมันก็อยู่ “นิ่งๆ” เลย อยาก Track project ต้องทำยังไงบ้างอะ?
• โห พี่ครับ Solution แบบนี้ไม่เคยมีใครทำเลยนะ จะทำได้ป่าวก็ไม่รู้ Requirement ก็ไม่นิ่ง แบบนี้ผมจะ Plan ยังไงหละ?
• แทนที่ว่า Outsource งานออกไปแล้วจะเหนื่อยน้อยลง ป่าวเลย!!! ส่งงานให้ก็ช้าแถมคุณภาพบัดซบ Project จะดีเลย์แล้วเนี่ย ปวดหัวมาก
• ถ้ามีข้อสงสัยเพิ่มเติม กรุณาฝากคำถามไว้ด้วยจ่ะ … (ขอเวลาเตรียมตัวก่อนนิดนึง ฮ่าๆ)
  

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

สุดท้ายขอฝากวิธีเดินทางไปยังจุดนัดหมายที่ Art Element: School of Art อย่างละเอียดครับ

แบบประหยัดก็รถเมล์

1. ลง MRT ศูนย์ประชุมสิริกิต์แล้วออกประตูตลาดคลองเตยครับ
2. จากนั้นเดินตรงไปแยกคลองเตยแล้วเลี้ยวซ้ายจะเจอป้ายรถเมล์ให้ขึ้นรถเมล์
3. สาย 22 / 45 / 46 /115 / 116 / 149 / 507 ได้หลายสายครับ บอกเค้าลงตรงป้ายองค์การโทรศัพท์ (รถมันจะผ่านจุดสังเกตทางด้านซ้ายมือเรียงลำดับดังนี้ 1.โชว์รูม BMW 2.สี่แยกเกษมราษฎร์ 3.คาร์ฟูร์ พระรามสี่ ฝั่งขวาเป็นโลตัส 4 สถานีโทรทัศน์ช่องสาม ตึกมาลีนนท์)
4. พอถึงตึกมาลีนนท์ก็กดกริ่งลงได้เลยครับ
5. จากนั้นให้เดินข้ามถนนเข้ามาที่ซอยอุทัยฟาร์มซึ่งจะอยู่ระหว่างองค์การโทรศัพท์กับตึก Green Tower ถ้าข้ามสะพานลอยให้หน้าเข้าป้ายรถเมล์แล้วเลี้ยวมาทางขวามือแล้วเดินตรงมาจะเจอซอยแรกเลยครับ (ก่อนถึงตึก Green Tower)
6. เดินเข้ามาประมาณ 50 เมตรก็เจอแล้วครับ อยู่ทางซ้ายมือ

แบบด่วนก็มอเตอร์ไซค์

1. ลง MRT ศูนย์ประชุมสิริกิต์แล้วออกประตูตลาดคลองเตยครับ
2. จากนั้นเดินตรงไปแยกคลองเตย เจอวินมอเตอร์ไซค์ ขึ้นเลยบอกว่าไปซอยอุทัยฟาร์มตรงตึก Green Tower ครับ 30 บาท

แบบมาเป็นกลุ่มก็แท๊กซี่

1. ลง MRT ศูนย์ประชุมสิริกิต์แล้วออกประตูตลาดคลองเตยครับ
2. เรียก Taxi แล้วดูตามแผนที่ครับ บอกว่าไปตรงข้ามช่อง 3

แล้วเจอกันครับ

ปล. เพื่อนๆที่มีชื่ออยู่ใน waitlist ไม่ต้องกังวลครับ จัดครั้งหน้าได้ไปแน่นอน

ผ่านไปแล้วหนึ่งนะครับสำหรับการพบปะพูดคุยกันของสมาชิก Chapterpiece ครั้งที่แล้วเราคุยกันเรื่อง Agile Development — First Chapter วันนั้นสนุกมาก เสียดายที่มัวแต่เม้าท์จนลืมถ่ายรูป … ครั้งนี้ไม่พลาด

อีกหนึ่งหัวข้อที่เพื่อนๆให้ความสนใจเท่ากับ Agile Development — First Chapter นั่นคือ Project Planning — How To และเพื่อให้กิจกรรมของเรามีอย่างต่อเนื่อง ผมขอเชิญผู้สนใจเข้าร่วมพูดคุยกันในหัวข้อนี้เลยครับ … ลองดูหัวข้อก่อนนะถ้าอยากให้เพิ่ม/ลดตรงไหนบอกได้เลย

จุดประสงค์ก็เหมือนเดิมครับคือแบ่งปันความรู้ ประสบการณ์ทั้งดีและไม่ดีในเรื่อง Project Planning กลุ่มเป้าหมายก็ได้หมดครับ ทุกเพศ ทุกวัย ทุกตำแหน่ง ทุกอาชีพ นักเรียน นักศึกษาก็ต้อนรับนะครับ … คนที่สนใจลงทะเบียนจองที่นั่งได้ที่นี่เลย ฝากทำแบบสอบถามด้วยนะครับ ผมจะได้ปรับเปลี่ยนหัวข้อการพูดคุยให้ตรงกับความต้องการของเพื่อนๆมากที่สุด

เรื่องสถานที่ ต้องขอบคุณ Art Element: School of Art ที่อำนวยความสะดวกให้เราได้ใช้สถานที่ฟรี มีทั้งห้องแอร์ โปรเจกเตอร์ และมีร้านกาแฟข้างล่างด้วย … เพียบพร้อมสุดๆ ขอบคุณเจ้าของสถานที่มากๆครับผม

ปล. ครั้งนี้ขอจำกัดผู้เข้าร่วมงานไว้ที่ 15 คนครับ สำหรับคนที่พลาดครั้งนี้ก็ลงชื่อใน Wishlist ได้ครับ เดี๋ยวจัดรอบสองให้