Case study on ERP project (ตอนจบ)

Posted by natty, Jan 27 2010, 11:19 AM

สืบเนื่องจาก Case study on ERP project (Semi Final): หลังจากปรับความเหมาะสมของตัวเอง มีตอนหนึ่งเก๋บอกเอาไว้ว่า

กลับมาตามสัญญาค่ะ มีหลายสิ่งหลายอย่างเกิดขึ้นมากมายใน โปรเจค และตอนนี้ก็เหมือนจะเห็นผลแล้วว่า สรุปเราควรเดินไปทางไหน
สรุปว่าก่อนนะคะว่า โปรเจค fail โดยดุษฎีไม่มีข้อแก้ตัว

แต่ก่อนจะไปที่รายละเอียด เก๋อยากจะย้ำให้ทุกคนเข้าใจว่า project ที่เราสรุปได้ว่ามัน fail ยังดีกว่า project ที่ยืดเยื้อหาคำตอบไม่ได้ ว่าสรุปแล้วเป็นงัย?
คำว่า success และ fail เป็นคำตอบที่มีประโยชน์ ที่จะทำให้ชีวิตก้าวต่อไปข้างหน้าได้ค่ะ

เก๋ขอสรุปการดำเนินงานสั้นๆ ของโปรเจคนี้ ในฐานะรักษาการผู้จัดการโครงการ (อยากจะสั้นๆ จริงๆ แต่ไม่รู้จะสั้นได้อย่างใจหรือเปล่า)
ครั้งแรกของโครงการ เก๋ไม่ได้เข้ามาตั้งแต่ต้น แต่ดู architecture และความเป็นไปได้คร่าวๆ บวกกับ vision ของบริษัท คิดว่า ไม่น่าจะเป็นไปได้ที่จะเสร็จ ตั้งแต่ตอนนั้นแล้ว เลยทำ cost-benefit analysis เสนอ director ว่า เราจะเสียเงินเท่าไหร่ (โดยที่ผลกำไรเก๋ยกให้เป็นหน้าที่ director ท่านคิดเอง เพราะเก๋ไม่ทราบได้ เพราะในความคิดเก๋ benefit มันไม่น่าจะเยอะกว่า cost ที่ลงไป)

ทำไมคิดแบบนั้น?
- เพราะ ERP ที่ใช้นำมา extend ได้ยาก (ไม่มี service, api ต้องต่อ db ตรงอย่างเดียว)
- มีกระบวนการหลายอย่างที่ไม่ match กับองค์กร (พอจะเห็นรางๆ และถามๆ มาในตอนนั้น แต่ก็ยังไม่สามารถตอบได้แน่ชัด เพราะเพิ่งเข้ามาในโปรเจค) ต้องแก้ปัญหาอีกหลายอย่างสำหรับส่วน core ERP นี้
- ทีมมีจำนวนคนไม่เพียงพอ ประกอบกับ skill ในการพัฒนาโปรแกรมยังไม่เพียงพอที่จะทำระบบขนาดใหญ่ ต้องมีการ training กันอีกหลายส่วน
- มีตัว plugin ที่ต้องทำมากเกินไป และ plugin บางตัว ก็ทำเพื่อแก้ปัญหา ERP ซึ่งจะมีผลกระทบในอนาคตหากมีการปรับ version ของ ERP
- implementer อยู่ไกลมาก ติดต่อกันไม่สะดวก และเค้า concern เฉพาะปัญหาตรงตัว core ERP ไม่ได้สนใจว่า เราจะมี plugin เสริม อีกสักกี่ตัว
-.....
(หมายเหตุ plugin คือ ซอฟท์แวร์ที่มีต่อกับ ERP เพื่อเติมกระบวนการทำงานให้ครบถ้วน ดังนั้น plugin ไม่ได้มีขนาดเล็กอย่างที่คิด แต่มันคือ ระบบหลายๆ อันค่ะ)
และผลสรุปออกมาว่า เรายังต้อง implement ต่อไป ด้วยเหตุผลที่ว่า เพื่อที่จะให้กระบวนการของเราเป็นมาตรฐานสากล ... และโดนตำหนิว่า พวกเราเป็นพวกไม่ยอมเปลี่ยนแปลง ....
ดังนั้น เราก็ทำดีที่สุดในหน้าที่เราแล้ว จึงรับคำสั่งมาดำเนินการต่อ โดยพยายามประสบความสำเร็จกับตัว plugin ให้มากที่สุด (เรื่อง integration ค่อยคิด เพราะปัญหาตรง core ERP ก็ยังไม่ได้แก้)

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

ทุกอย่างดำเนินซ้ำๆ มาแบบนี้ เกือบ 2 ปี

จนกระทั่งเกิดความเปลี่ยนแปลงดังนี้
- มี director ใหม่เข้ามาใน IT
- มีการแต่งตั้งผู้รักษาการผู้จัดการโครงการ

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

และผู้บริหารก็ได้เห็นปัญหาชัดขึ้นว่า ปัญหาไม่ได้อยู่ที่เราไม่ยอมเปลี่ยนแปลง แต่อยู่ว่าว่า บางอย่างมันเปลี่ยนแปลงไปเป็นแบบนั้นไม่ได้ ด้วยเหตุผลทางกฏหมาย ภาษี ของประเทศไทยที่ไม่เหมือนที่อื่น ดังนั้น การจะนำโปรแกรมจากประเทศอื่นมาใช้ เป็นสิ่งที่เป็นไปได้ยากอยู่แล้ว ประกอบกับที่ไม่สามารถ customize ได้ และไม่ provide service ให้อีก ก็ยิ่งไปกันใหญ่

cost-benefit analysis ถูกเอามาคิดอีกรอบ และผลก็เสียเงินไม่ต่างจากการคิดครั้งแรกมาก... (สรุปว่าจริงๆ รู้ล่วงหน้ามา 2 ปีแล้วแต่ไม่มีใครทำอะไร)

สิ่งที่ natty ทำผิดพลาดในโปรเจคนี้ (บทเรียน)
- การที่ทราบมาตั้งแต่ต้นว่าโปรเจคมีความเป็นไปได้ต่ำ แต่ก็ยังดั้นด้นทำต่อไปเพราะคิดว่า software process สามารถช่วยให้บางอย่างดีขึ้นได้ (จริงๆ เป็นเพราะลาออกไม่ได้ 55)
"Agile คือ direction แต่ไม่ใช่ solution"
- การ apply agile โดยยังไม่ประสบความสำเร็จในการ buy-in ผู้บริหาร หรือแม้แต่ผู้ใหญ่ในแผนก ต้องให้เค้าเห็นประโยชน์ก่อนค่ะ
- ดำเนินงานไปตามคำสั่งโดยเชื่อว่า น่าจะมีทางประสบความสำเร็จ (มั้ง) โดยที่เห็นชัดทางทฤษฎีอยู่แล้วว่าไม่มีทางเป็นไปได้ แต่ทำงานตามแบบคนไทยคือ ทำตามคำสั่ง เค้าให้ทำอะไรก็ทำ ไม่อยากมีปัญหากับใคร ในเมื่อทำเต็มที่แล้ว เคยบอกไปแล้ว คุณไม่เชื่อก็ตามใจ บลาๆๆๆ

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

no silver bullet นะคะ เราอยากจะ apply process อะไรก็ได้ ที่เหมาะกับองค์กรของเรา แต่เราก็ต้องปรับทุกอย่างให้เข้ากัน เพื่อให้ประสบความสำเร็จ แบบเป็น "solution" ค่ะ

การบ้าน: blog หลัง narisa tech talk -- Agile practice

Posted by natty, Sep 1 2009, 07:58 PM in Software Process

blog ก่อนงาน ไม่ได้เขียนเป็นเรื่องเป็นราว แต่ไปตอบกระทู้พี่ข้าวโพดหวาน เกี่ยวกับ Agile process practice in Thai culture.

Agile
ชอบ session ของ พี่ข้าวโพดหวานมากที่สุด และก็ไม่ผิดหวังจริงๆ เพราะก่อนงาน ก็ตั้งใจจะไปฟังอันนี้มากที่สุดเช่นกัน หลังจากกลับมา ได้แนวคิดในการทำงานหลายๆ อย่าง ที่บริษัทตอนนี้ ได้ลอง apply agile practice บางอย่างเข้าไปแล้ว แต่ก็ยังไม่สมบูรณ์

deadline quality budget scope เป็นมิติที่ทำให้มองเห็นความเป็นไปของโปรเจคเป็นอย่างดี และทำให้เห็นได้ชัดว่า ต้องเพิ่มเติมในด้านใด จึงจะทำให้โปรเจคมีกระบวนการที่สมบูรณ์มากยิ่งขึ้น
Agile process practice มีประเด็นหลักๆ เพื่อผลในการสร้างแรงจูงใจ ความสนุกในการทำงาน เป็นแนวคิดที่เป็นผลทางจิตวิทยา เพื่อให้ความรู้สึกของคนที่ทำงานถูกกระตุ้น และ focus กับงานมากขึ้น และยังทำให้ผู้บริหารมองเห็นภาพการทำงานของทีมได้มากขึ้น เพราะมีผลลัพธ์ที่วัดได้ง่าย

การทำ user story เป็นการแบ่งงานให้เป็นชิ้นเล็ก และทำให้ทีมเกิดการประสบความสำเร็จบ่อยครั้ง เพราะ scope ที่ทำไม่ใหญ่เกินไป สิ่งที่ได้คือ ผู้พัฒนามีกำลังใจในการทำงาน เพราะสามารถทำงานเสร็จได้ ผลงานก็มีประสิทธิภาพ เพราะทำงานเล็กๆ นี้ตั้งแต่การออกแบบจนถึง test และมี user มีส่วนร่วม ซึ่งประเด็นนี้ ก็เกิดผลดีกับ user ทำให้รู้สึกมีส่วนร่วมในโปรเจค และทำให้ไม่เกิด requirement แปลกในตอนหลัง และด้วยความที่แต่ละ user story มีการให้คะแนนเป็น point และผู้พัฒนาก็มีการให้คะแนนเป็น point ด้วย ทำให้วัดผลการทำงานออกมาได้เป็นตัวเลข เมื่อทำ burn down chart ออกมา ทีมเองก็เห็นประสิทธิภาพของตัวเอง แถมเอาไปให้ผู้บริหารดูได้อีกว่า velocity ในการทำงานเป็นอย่างไร เพื่อที่จะได้สนับสนุนได้ถูกต้อง ดีกว่าการแค่ไปบอกว่า คนไม่พอ ทำงานหนักเกินไป เป็นต้น

TDD เป็นแนวคิดในการทำงาน ที่ทำให้เกิด scope ไม่ออกนอกลู่นอกทาง เป็นเหมือนการการปัญหาที่ถูกตั้งโจทย์เอาไว้แล้ว ในแต่ละ user story นั้น ก็จะมีการเขียน test ไว้เหมือนเป็น spec จากนั้น ก็เอา spec นี้ไปแก้ปัญหาต่อให้สามารถทำงานได้ การทำ test ใน ruby ที่พี่ข้าวโพดหวานทำให้ดูในงานนั้น เป็นอะไรที่ยอดเยี่ยมมาก เพราะแสดงให้เห็นว่า ในอนาคตนั้น เราสามารถให้ user เป็นคนช่วยเราเขียน test ได้โดยที่ไม่จำเป็นต้องเข้าใจวิธีการ coding เลย แถมยังสามารถเก็บเอาไว้เป็น document ได้อีกด้วย เพราะมันคือ การเขียน spec นั่นเอง

แต่ไม่ว่าอย่างไรก็ตาม การ apply process ใหม่เข้าสู่องค์กร ต้องอาศัยความใจเย็น และค่อยเป็นค่อยไป พยายามอย่ายัดอะไรให้กับทีมมากเกินไปจนทุกคนรู้สึกว่าชีวิตวุ่นวาย แนวคิด agile ไม่ได้ต้องการให้ทุกอย่างมันวุ่น แต่ต้องการทุกอย่างมันง่าย ความสามารถของคนในทีมก็มีส่วนสำคัญ การ training เป็นสิ่งที่จำเป็นสำหรับทีม เพราะหากเค้ารู้หน้าที่ใน role ของตัวเอง ก็สามารถ apply process ได้ง่ายขึ้น

ทุกอย่างที่จดไว้ อยู่ที่ juacompe หมดเลย เด๋วค่อยมาเติมอีกค่ะ ตอนได้ lecture กลับมา

Agile process practice in Thai culture (Narisa Tech Talk 09)

Posted by natty, Aug 5 2009, 06:48 PM

previous:
Morning talk



เตรียมสำหรับ narisa tech talk ค่ะ
อยากทราบปัญหาการนำ agile process มาใช้ในไทย, ใช้เป็นข้อมูลในการพูดในงาน software park annual conference




entry ที่เกี่ยวข้อง
ประสบการณ์เล็กๆ ที่อยากแบ่งปัน กับการทำงานในโปรเจค
Morning talk

Morning talk

Posted by natty, Jul 23 2009, 08:32 PM in Software Process

Morning talk

previous: ประสบการณ์เล็กๆ ที่อยากแบ่งปัน กับการทำงานในโปรเจค

Morning talk คงเป็นวิธีธรรมดาๆ ที่ใคร หลายๆ คนใช้กันอยู่แล้ว แต่ Morning talk ที่มีประโยชน์ และชักจูงใจของทีมให้อยากจะ Morning talk และรู้สึกว่ามันมีประโยชน์ คือ การที่ไม่ใช่แค่ "รายงานความคืบหน้า" แต่จะต้องเป็นการ shout and scrum scream and scrum (ยืมคุณ juacompe มา) คือ เป็นช่วงเวลาที่เปิดโอกาสให้ทีมได้พูดแล้ว และเป็นช่วงเวลาที่ lead จะเข้ามามีส่วนร่วมในการแก้ปัญหาได้ ประโยชน์หลักๆ ของ Morning talk คือ การทำให้ทีมได้วางแผนการทำงานที่จะทำต่อไป จะเป็นรายวัน รายสองวัน หรือรายสัปดาห์ก็อยู่ที่ความเหมาะสม แต่จริงๆ แล้ว Morning talk ควรเกิดขึ้นทุกวัน วันละไม่เกิน 10 นาที เพื่อติดตามสิ่งที่เกิดขึ้นในโปรเจค (ทีมของ natty มี Morning talk แบบพบกันทุกคน ทุกโปรเจค เพียงสัปดาห์ละ 2 ครั้ง คือ จันทร์ และ ศุกร์ ซึ่งจะเหมือนรายงานความคืบหน้ามากกว่า แต่ในโปรเจคย่อยๆ จะมี Morning talk ทุกวัน แต่สมาชิกไม่เรียกว่า morning talk แต่เรียกกว่า คุยกันตอนเช้า เพราะพอเรียกว่า Morning talk จะเกิดความเครียดซะงั้น ^O^)

Morning talk แก้ปัญหาใดบ้าง
โอกาสสำหรับทีม

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

โอกาสสำหรับ lead

• ได้ติดตามงานของทีมโดยไม่ทำให้ทีมรู้สึกไม่ดีเหมือนโดนจิก เพราะเป็นการคุยกันตามนัดหมาย
• เป็นโอกาสที่ดี ที่จะตักเตือนทีม โดยไม่ให้เกิดความเครียด
• หากคุณไม่ได้รับการยอมรับให้มีส่วนร่วมในโปรเจคมากนัก หรือคุณเป็น lead เพิ่งเข้าใหม่ นี่เป็นโอกาสสร้างสัมพันธไมตรี
• มีโอกาสรับรู้ปัญหาที่เกิดขึ้นในโปรเจคในเวลาที่ยังไม่สายเกินไป
• ให้กำลังใจทีมที่ทำงาน ชักจูงใจให้เกิดความสุข ให้ข้อคิดดีๆ ในการทำงาน (สำคัญมากนะคะ หากคุณรู้ตัวว่าเป็น lead ข้อนี้ required ค่ะ!)

การ communicate เป็นสิ่งที่สำคัญกับการทำงานเป็นทีมมาก ไม่ว่าจะเป็น communication ภายใน หรือ ภายนอก ซึ่งจะมีวิธีการลดความกดดัน ลดการขัดแย้ง เพิ่ม synchronization เพื่อไม่ให้เกิดอารมณ์และความรู้สึกไม่ดีในการทำงาน ซึ่งหากเกิดระยะยาว จะกระทบกับงานแบบที่แก้ไขยาก (และเมื่อไหร่ที่มันกลายเป็นปัญหา มันจะยิ่งซ่อนลึกจนหาจุดจะแก้ไม่เจอ) ซึ่ง Morning talk เป็นวิธีหนึ่งในจำนวนหลายๆ วิธีสำหรับ communication ในการทำงาน

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

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

ผลดีของ Morning talk ไม่สามารถเกิดขึ้นได้ตั้งแต่ครั้งแรกที่นำมาใช้ค่ะ จะต้องเกิดจากการหล่อหลอมความรู้สึก อาศัยเวลา คนที่เป็น lead อาจจะต้องอดทนเพื่อรอให้ผลดีเกิด แน่นอน แรกๆ สิ่งที่ได้จาก Morning talk คือ การได้เห็น progress ของงาน แต่เรื่องของความรู้สึก ต้องใช้เวลาในการปรับค่ะ ไม่ว่าวิธีอะไรก็ตาม หากเราเอาไปใช้กับทีมแล้วทำให้วิธีการทำงานเค้าเปลี่ยน มันจะถูกมองในแง่ร้ายเสมอ แต่หากเราเริ่มต้นกับคนใหม่ๆ ก็จะง่ายกว่า

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

ครั้งหน้า จะมาต่อในหัวข้อถัดไปค่ะ

entry ที่เกี่ยวข้อง
ประสบการณ์เล็กๆ ที่อยากแบ่งปัน กับการทำงานในโปรเจค


ป.ล. ส่งท้าย

ดีใจที่มีคนติดตามค่ะ

หากใครคาดหวังจะทราบเกี่ยวกับรายละเอียดของ project อาจจะผิดหวังนะคะ เพราะ natty จะเขียนให้เกี่ยวข้องกับ background ของบริษัท หรือรายละเอียดงาน Project ให้น้อยที่สุดเท่าที่จะทำได้ ดังนั้นใครอยากทราบรายละเอียด project แบบนอกรอบ ก็มาคุยหลังไมค์กันได้ค่ะ

หรือหากใครคาดหวังจะได้วิธีการทำงานตามทฤษฎี แนะนำให้ไปอ่านหนังสือในหัวข้อที่เกี่ยวข้องแทนค่ะ เพราะสิ่งที่ natty เขียน มาจากประสบการณ์ที่เคยทำแล้วประสบความสำเร็จ ซึ่งเป็นเพียงวิธีการหนึ่งที่อาจจะมีประโยชน์กับคนอื่น และยังค้นคว้าต่อไปเรื่อยๆ ค่ะ เพราะบอกแล้วว่า no silver bullet

ประสบการณ์เล็กๆ ที่อยากแบ่งปัน กับการทำงานในโปรเจค

Posted by natty, Jul 22 2009, 08:40 PM in Software Process

หลายคนคงทราบแล้วว่า natty ทำงานเกี่ยวกับ ERP project อยู่ ก่อนหน้านี้เคยมาบ่นๆ ให้ฟังเกี่ยวกับความวุ่นวาย วันนี้กลับมาอีกครั้ง กับความสำเร็จค่ะ

Project นี้ เป็นการ implement ERP ที่ได้มาจากส่วนกลาง และทำระบบเสริมรอบๆ ตัวของ ERP นี้ (ประมาณ 7 ระบบ มีส่วนเกี่ยวข้องกับการ integration ทั้งหมด)
เนื้อหาของ blog จะไม่อ้างอิงถึงปัญหาหรืองานในรายละเอียด แต่เน้นการเอาประสบการณ์มาแบ่งปันกัน วิธีการทำงาน สิ่งที่เป็นประโยชน์ที่ค้นพบด้วยตัวเอง ไม่เน้นเทคนิคค่ะ

Role ของ natty ตอนนี้ คืออะไร? จริงๆ ไม่มี role เป็นทางการ เนื่องจากปัญหาด้านการเมือง แต่ natty ของตั้งตัวเองเป็น project lead ละกันค่ะ เราไม่จำเป็นต้องให้ใครกำหนด Role ให้เรานี่คะ ประเมินตัวเองได้ว่าตอนนี้เราทำอะไรอยู่ role นี้เกิดจากความคาดหวังของ management บางคน ไม่ได้ถูกสั่งให้เป็นอย่างเป็นทางการ เรียกว่า รู้อยู่คนเดียวว่าเป็น lead ทำงานเหมือนเป็น lead บทบาทเดียวกัน แค่อำนาจมันมีน้อย และคนในทีมไม่ได้รู้ด้วย ^O^

Project นี้มีแววจะ fail ตั้งแต่แรกๆ ที่ natty เข้ามา คือ Project ใช้เวลามาประมาณเกือบปี และ natty ก็เข้ามาหลังจากนั้น ตั้งแต่ natty อยู่ใน Project นั้น จนถึงตอนนี้ ก็ปีนึงแล้ว project จาก status fail เปลี่ยนมาเป็น กำลังจะ go-live ค่ะ ซึ่งทุกอย่างเกิดอยู่ในสถานการณ์การเมืองที่ย่ำแย่ การทำงานที่เครียด การไม่มีกระบวนการอะไรเลยในการทำงาน ไม่มีการจัดการโปรเจค กลับกลายมาเป็น โปรเจคที่มีการจัดการอย่างเป็นระบบเท่าที่ทำได้ สิ่งแวดล้อมในการทำงานที่ดี ความร่วมมือจากคนในทีม และกำลังเดินหน้าไปสู่เส้นชัย

ที่พูด ไม่ได้จะบอกว่า ทุกอย่างมันมาถึงจุดนี้ได้เพราะ natty ทุกคนในโปรเจคสำคัญและมีคุณค่าหมด เพราะคนออกไปแต่ละที ก็วูบกันไป แต่ ก็ไม่มีใครเถียงได้เช่นกัน ว่าถ้า natty ไม่เข้ามาทำโปรเจคนี้ ป่านนี้สภาพจะเป็นอย่างไร? ดังนั้น natty ไม่อายที่จะบอกว่าตัวเอง เป็นส่วนหนึ่งของความสำเร็จครั้งนี้แน่นอน ทุกอย่างเริ่มต้นจากความเชื่อมั่นเล็กๆ จาก management บางคน ที่มีความเชื่ออย่างแรงกล้า ว่า นักเรียน AIT ต้องสร้างสิ่งดีๆ ให้โลกได้ ที่เหลือ natty บอกตรงๆ ว่า สดค่ะ natty เองก็ไม่ได้มีประสบการณ์อะไรที่จะ lead project ได้ แค่ได้รับโอกาสที่ดี ไม่ได้เก่ง มีหลายเรื่องที่เพิ่งเรียนรู้จากสิ่งที่ทำ จนตอนนี้เรียกได้ว่า แทบจะเห็นภาพเกือบทุกอย่างในโปรเจคแล้ว เพราะว่าเจ็บมาเยอะมาก จากความเชื่อมั่นเล็กๆ ของคนกลุ่มหนึ่ง ตอนนี้ natty เชื่อว่าสิ่งที่สร้างมาเป็นปี กำลังจะแสดงพลังให้คนกลุ่มใหญ่ได้เห็นแล้วจริงๆ ค่ะ

ดังนั้น จึงเห็นว่า สิ่งที่เกิดขึ้น น่าจะเป็นประโยชน์กับใครหลายๆ คน อย่างที่บอกค่ะ ไม่มีใครบอกได้หรอกว่าอะไรคือ Best practice สำหรับการจัดการ project หรือ software process หรือที่เรียกว่า no silver bullet เพราะแต่ละที่ก็มีหลายๆ สิ่งที่ต่างกันไป ซึ่งเป็นตัวแปรที่สำคัญทั้งสิ้น ดังนั้น อยู่ที่การนำทฤษฎีไปประยุกต์ใช้ให้เหมาะกับเหตุการณ์มากกว่าค่ะ

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

Morning talk
Google Calendar
SVN
Project management Website
Task board
Evening progress
Scrum
Agile เล็กๆ
Gantt chart วางแผนงาน และ maintain
Monthly report
Software design
MSN

เป็นที่รู้จักกันทุกอย่างนะคะ และก็ดูเหมือนไม่มีอะไร จริงๆ ถ้ามีอยู่ในหนังสือใครๆ ก็ทำได้ทั้งนั้นค่ะ

background ของทีมนี้คือ
- ไม่มีความรู้เรื่อง OOP
- ไม่เข้าใจ MVC
- ไม่มีประสบการณ์ทำงาน เป็นเด็กใหม่ทั้งสิ้น
- ไม่รู้จัก version control
- ไม่เคยต้องรายงานการทำงาน ไม่เคยถูกคุมโดยแผน
- ไม่เข้า Software process เช่น scrum, Agile
- สุดท้าย project นี้ ไม่มี Project manager จนกระทั่งถึงบัดนี้ ก็ยังไม่มี

ถึงตรงนี้แล้ว ลองย้อนกลับไปอ่านด้านบนอีกรอบนะคะ ว่าเราทำอะไรกันไปบ้าง และลองจินตนาการไหมคะ ว่าทำกันเข้าไปได้งัย
ใครที่มีประสบการณ์ทำงานโปรเจค คงทราบดีว่า การทำงานแบบไม่มี role และอำนาจที่ชัดเจน จะลำบากยังงัย ซึ่งโปรเจคนี้ ก็ดำเนินมาในสถานการณ์นั้นค่ะ
จนกระทั่งถึงตรงนี้แล้ว มีคนออกจากโปรเจคเพราะมีปัญหา และ ทนไม่ได้ ไป 4 คนแล้ว ตอนนี้เหลือ 4 คน (ในจำนวนนี้เป็นน้องจบใหม่ 1 คน) และต้องทำให้โปรเจคเสร็จตามแผนเดิม หรือไม่ ก็ late ได้ไม่เกิน 2 เดือน

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

คุณคิดว่าพวกเราที่เหลือ ทำได้ไหมคะ?

ตอบให้เลยว่า ทำได้

หวังว่า ทิ้งไว้ตรงนี้แล้ว ทุกคนคงเริ่มอยากรู้แล้วใช่ไหมคะ ว่าทำอย่างไร ทุกอย่างเกิดบนพื้นฐานของค่าตอบแทนเท่าเดิม (บอกได้ว่าน้อยกว่าที่อื่น คนในทีมพร้อมออกจะได้ทุกเมื่อ) เวลาทำงานเพิ่มจากเดิมนิดหน่อย ไม่มี OT ไม่ bonus ไม่มีรางวัลอะไรจะได้ทั้งนั้น เรียกว่าอยู่กันด้วยใจ

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

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

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

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

จะมาต่อในตอนหน้าอีกค่ะ โดน site admin (juacompe) กดดันมา ฮ่าๆๆๆ ต้องเขียนให้จบเป็นเรื่องเป็นราวได้แน่ๆ

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

Post แรกที่นี่

Posted by natty, Feb 24 2009, 12:56 AM in General

เนื่องจากวันนี้บ้าพลัง หา topic แรกใน narisa.com ของคุณ juacompe แต่ก็หาไม่เจอ เจอแต่ post แรกในวันที่สมัคร แค่อยากรู้ความเป็นมาของคนเก่งเท่านั้นเอง ฮ่าๆ เลยเริ่มรู้สึกว่า หายากเหมือนกันแฮะ เสียไป 3 ชั่วโมง

เลยเอา Post แรกของตัวเองมาแปะบ้างดีกว่า ไม่ค่อยแน่ใจเหมือนกันว่าใช่ไหม แต่ดูจากระยะเวลาแล้ว น่าจะใช่ แต่หายากนิดนึงเลย เพราะว่าตอนสมัครก็มาอ่านเฉยๆ ไม่ได้โพสต์ รออยู่พักนึงแล้วจึงจะโพสต์ ไม่รู้จะรออะไรเหมือนกันค่ะ สงสัยช่วงนั้นป๊อดอยู่ เพราะว่าตอนสมัครไม่ได้อยากจะถามอะไร แต่อยากจะร่วมครอบครัว narisa.com แถม topic แรกที่ตั้ง ก็หลังจากนั้นอีกเป็นเดือน และอยู่ในหมวดภาพประทับใจ ไม่ได้เกี่ยวอะไรกับวิชาการเลย ฮ่าๆๆๆ

แปะไว้เผื่อวันนึงอยากจะหาขึ้นมาบ้าง อิอิ

จะเขียนกราฟใช้อะไรดีครับ ช่วยแนะนำหน่อยครับ Jun 6 2007, 07:40 PM

My new blog

Posted by natty, Sep 16 2008, 09:32 AM in General

ตอนนี้ natty มี blog ใหม่แล้ว สามารถตามไปเยี่ยมเยียนกันได้นะคะ ที่ http://nattyait.wordpress.com/
ยังมีไม่กี่โพสต์เอง แต่ก็คงจะเพิ่มเรื่อยๆ ค่ะ

JasperServer on Resin

Posted by natty, Aug 27 2008, 02:22 PM in Configuration

จากตอนที่แล้ว เกี่ยวกับ install Resin มาต่อกันด้วยการใช้งาน JasperServer บน Resin ค่ะ
ปกติแล้ว JasperServer จะสามารถ install ได้โดย install Tomcat ไปด้วยเลย แต่ก็มีหลายๆ ครั้ง ที่เราอยากจะใช้ JasperServer บน AS ตัวอื่น เช่น JBoss หรือ Resin
สำหรับเนื้อหาครั้งนี้ จะกล่าวถึง JasperServer on Resin ค่ะ

วิธีการที่ทำ ล้อจากการ deploy JasperServer บน JBoss ค่ะ เนื่องจากพยายามหา resource แล้ว หาไม่ได้ หากใครมี resource ที่น่าสนใจเกี่ยวกับเรื่องนี้ ก็สามารถเอามาโพสต์ได้ค่ะ เพราะอาจจะมีวิธีที่ดีและง่ายกว่านี้ และเข้าใจง่ายกว่านี้ค่ะ

ก่อนอื่นต้องทำการ install Resin ก่อนนะคะ สามารถอ่านได้จาก Resin Installation and Third-party Database Configuration

จากนั้นก็เริ่มติดตั้งเพื่อใช้งาน JasperServer on Resin (บน Windows ค่ะ)
1. ดาวน์โหลด JasperServer จาก http://sourceforge.net/project/showfiles.php?group_id=162962
2. เราจะทำการ config โดยไม่ใช้วิธีการ deploy WAR file แต่จะไปตั้งค่าใน resin.xml ให้ชี้ไปยัง JasperServer directory แทน ดังนั้น เมื่อดาวน์โหลดเสร็จ ด้านในจะมี WAR file ให้เราทำการแตก War file นั้น เป็น jasperserver directory แล้ววางไว้ที่ resin-3.2.0\webapps\ROOT\
3. เพิ่มบรรทัดต่อไปนี้ ลงใน resin-3.2.0\conf\resin.xml เพื่อให้ชี้ไปยัง JasperServer directory

4. install MySQL ในเครื่องด้วยนะคะ
5. เข้าไปที่ <unpacked-war-dir>/scripts/mysql (JasperServer directory ที่ถูกแตก zip) และพิมพ์คำสั่งดังต่อไปนี้ เพื่อเป็นการสร้าง database

การ install database เพื่อใช้งานกับ JasperServer สามารถอ่านเพิ่มเติมได้จาก jasperserver-3.0-bin\docs\JasperServer-Install-Guide
แต่ว่าตอนเก๋ทำจริงๆ เก๋ไปเอาตัว install ที่ลง jasperserver พร้อมๆ กับ tomcat และ database เพื่อจะเอาแค่ตัว database เพราะตอนที่ใช้ script database ตัวที่บอกด้านบน มันมีปัญหาทำให้รันไม่ได้ พอ install ได้ตัว database เสร็จ ก็ถอน JasperServer ตัวนั้นออก เอา database เก็บไว้อย่างเดียว

6. สร้างไฟล์ jasperserver/WEB-INF/resin-web.xml ดังนี้
jasperserver/WEB-INF/resin-web.xml

7. copy log4j ลงไปใน C:\resin-3.2.0\lib เนื่องจาก JasperServer requires log4j ด้วย
8. เข้า http://localhost:8080/jasperserver โดยใช้ username: jasperadmin, password: jasperadmin

Resin Installation and Third-party Database Configuration

Posted by natty, Aug 27 2008, 01:41 PM in Configuration

ทำได้แล้วค่ะ ดำน้ำไปเรื่อยๆ หาข้อมูลไม่ได้เลยจริงๆ

จะบอกเป็นขั้นเป็นตอนอย่างละเอียดๆ เลยนะคะ คิดว่าสักวันคงมีหลายๆ คนอยากจะใช้งานแบบนี้เหมือนกัน

เริ่มด้วยการ install Resin และใช้งานร่วมกับ database ก่อนนะคะ

ทำไมต้องใช้ Resin?
Quercus is Caucho Technology's fast, open-source, 100% Java implementation of the PHP language. Performance is 4x mod_php and is comparable with PHP accelerator performance. Quercus uses Resin-IoC/WebBeans to integrate with Resin services.

นั่นคือทำให้เราเขียนภาษา PHP ร่วมกับ Java ได้ใน Resin server จริงๆ Resin คือ Servlet container ที่เอามา deploy WAR file ได้ แต่ทำมาพิเศษให้สามารถรัน .php ได้ (จากคุณ cblue ค่ะ)

วิธีการ install resin (บน windows นะคะ)
ลิงค์ที่เกี่ยวข้อง
http://www.caucho.com/download/resin-3.2-reference.pdf
http://quercus.caucho.com/quercus-3.1/doc/quercus.xtp
http://www.jfrn.gov.br:83/java_tut/index.xtp
http://quercus.caucho.com/quercus-3.1/
http://quercus.caucho.com/quercus-3.1/examples/index.xtp

1. ดาวน์โหลด Resin server ได้ที่ http://www.caucho.com/download/ จะได้มาเป็น zip file ให้แตกซิบนั้นแล้วเอาไปวางใน path ที่ต้องการ เช่น C:\resin-3.2.0
2. วิธีการ start server ให้เข้าไปที่ resin/ directory และ start จากตัว resin application และลองเข้าผ่าน http://localhost:8080
3. ลองทดสอบสร้างไฟล์ php โดยสร้างไฟล์ hello-world.php แหละ WEB-INF/resin-web.xml ดังนี้ และลองเข้าผ่าน http://localhost:8080/hello-world.php

WEB-INF/resin-web.xml

hello-world.php


3. ตัวอย่างด้านบน มาจาก http://quercus.caucho.com/quercus-3.1/examples/index.xtp ซึ่งมีตัวอย่างการใช้งานกับ Java file ด้วย ถ้าอยากทราบเพิ่มเติม ก็ให้ทำตาม tutorial ดังกล่าวนะคะ

การ config เพื่อใช้งาน Resin กับ MySQL
Resin สามารถใช้งาน PDO ได้ โดยมีวิธีการตั้งค่าดังนี้

1. เพิ่ม code ต่อไปนี้ลงใน WEB-INF/resin-web.xml

จาก code ด้านบน หมายความว่า ตั้งค่า jndi ให้ติดต่อกับ MySQL database ที่ชื่อ test

วิธีการติดต่อกับ Third party สามารถอ่านได้จาก http://caucho.com/resin-3.0/db/thirdparty.xtp

2. นำ mysql-connector-java-xxx.jar ไปใส่ไว้ใน C:\resin-3.2.0\lib
2. ลองทดสอบการใช้งาน โดยลองสร้าง database ชื่อ test และสร้าง ตารางชื่อ user มี column ชื่อ name, surname แล้วใส่ข้อมูลภายใน
3. สร้างไฟล์ tesyMy.php และลองรันผ่าน http://localhost:8080/tesyMy.php อ้างถึง JNDI ด้านบนที่เรา config ไป โดยใช้ java:comp/env/jdbc/mysql

tesyMy.php


สามารถศึกษาตัวอย่างวิธีการใช้ PDO ได้จาก http://quercus.caucho.com/quercus-3.1/exam...s-pdo/index.xtp

การกำหนด PATH การ รัน Web application
ทั้งหมดที่กล่าวมาด้านบน เรานำไฟล์วางไว้ใน C:\resin-3.2.0\webapps\ROOT โดยตรง และสร้าง C:\resin-3.2.0\webapps\ROOT\WEB-INF เพื่อเอา resin-web.xml ไปใส่ไว้ แต่ในการทำงานจริงๆ แล้วนั้น เราก็ต้องการสร้าง folder เพื่อเก็บ web ของเราให้เป็นหมวดหมู่ โดยเราต้องทำการตั้งค่าเพิ่มเติมใน C:\resin-3.2.0\conf\resin.xml เพื่อให้มี pointer ชี้ไปยัง application ของเรา เช่น หาก folder ของเราชื่อ test เราต้องเพิ่มการตั้งค่าใน resin.xml ดังนี้

โดยวิธีนี้ จะทำให้ การรัน web application บน server ของเรา ไม่จำเป็นต้อง pack เป็น WAR file และนำไป deploy เหมือนใน JBoss หรือ Tomcat

แต่หากเราต้องการ deploy WAR file ลงไปใน Resin เราต้องทำการเพิ่มบรรทัดต่อไปนี้ลงไปใน C:\resin-3.2.0\conf\resin.xml

คือเป็นการชี้ไปว่า ให้ทำการ deploy test.war ที่ path ที่กำหนดด้วย

Case study on ERP project (Semi Final): หลังจากปรับความเหมาะสมของตัวเอง

Posted by natty, Aug 25 2008, 05:44 PM in General

ขอโทษทุกๆ คนด้วยนะคะ ไม่ได้มาเล่าซะนานเลย

และแล้วก็กลายเป็นตอน semi final ซะงั้น ทำให้คนอ่านงงไปเลย จริงๆ เป็นเพราะเก๋ปรับตัวเองให้อยู่ในที่ที่เหมาะสม จะได้ไม่เหนื่อย วันๆ เลยไม่ต้องสู้รบปรบมือสักเท่าไหร่แล้ว

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

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

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

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

ตอนนี้สิ่งที่ทำคือ ก็พยายามให้ทำงานกับเป็นคู่ๆ เหมือน concept ของ Pair programming ค่ะ เพราะแต่ละคนไม่ได้จับคู่กันแค่งานในโปรเจค มันมีงานนอกโปรเจคใหญ่นี้ด้วย อีกประมาณ 10 โปรเจค กับจำนวนคนประมาณ 7 คน (คนที่เหลือทำแต่โปรเจคใหญ่) - -* ก็ค่อนข้างจะไม่เป็นไปตามหลักทฤษฎีเท่าไหร่ แต่ก็ต้องทำไปตามที่เหมาะสมค่ะ

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

ตอนนี้มีคนที่บริษัทได้มาอ่านแล้ว เลยไม่อยากเขียนมาก เดี๋ยวกลายเป็นประเด็น เอาแค่นี้พอหอมปากหอมคอดีกว่า

จะมาเล่าอีกที ตอนโปรเจคเดินทางเสร็จแล้ว หรือ fail ไปแล้วนะคะ มันเป็นไปได้ทั้งสองทางเลย หรือไม่ถ้ามีประเด็นอะไรก็จะมาเล่าอีกค่ะ