Skip to toolbar

สรุปความรู้ที่ได้จาก Project ที่ทำหลายระบบ

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

เริ่มต้นจากไปทำ API ส่วนเดียว

ในตอนแรกที่ทางบริษัทได้รับงานมาเราได้มีส่วนเข้าไปช่วยงานทำ API สำหรับให้ทางทีมงานที่เป็นแผนกภายใน ขอเรียกทีมนี้ว่าทีม M แล้วกันโดยมี senior dev มาคุยงานกัน ตอนประชุมครั้งแรกทางทีมก็ขนกันไปฟัง requirement และมีหัวหน้าไปด้วย ซึ่งผมได้เรียนรู้อะไรเยอะเยะจากเขา และกับตัวโปรเจ็คนี้

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

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

สรุปใน part นี้

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

เริ่ม Implement และความไม่ชัดเจน

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

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

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

สรุปใน part นี้

  • พยายามทำความเข้าใจโค้ดและ logic เดิมก่อนเราสามารถเรียนรู้อะไรหลายๆอย่างจากโค้ดเดิมได้อีกด้วย ทั้งการออกแบบว่าดีไม่ดีอย่างไร เราจะได้เห็นว่าตอนแรกเขาออกแบบอย่างไรแล้วมีการปรับเปลี่ยนอะไรบ้าง ตรงจุดนี้มันจะรวมถึงการน้องคนในทีมของเขาเป็นอย่างไรด้วยครับ
  • สืบเนื่องมาจากข้อข้างบนขอขยายความหน่อย หัวหน้าที่โหดแค่ไหนเราสามารถดูจากโค้ดได้ครับ อย่างของบริษัทผมอยู่นั้น ถ้าไม่ผ่านคือไม่ผ่าน ต้องเขียนเทสคุมหรือต้องมี standard เพราะถ้าไม่ทำแต่แรกมันจะเละ หลายๆคนก็น่าจะรู้อยู่แล้วว่าเหตุการณ์นี้จะเกิดทุกครั้งถ้าเราไม่เริ่มทำครับ
  • อย่าคิดแค่จะใช้ service ตัวเองสะดวกแต่ต้องคิดว่า เอาเครื่องมืออะไรมาตอบโจทย์กับงาน เพราะจากที่ผมได้มีโอกาสร่วมงานกับโปรเจ็คนี้โดยทางทีมของผู้ว่าจ้างนั้นเขาเลือกเครื่องมือบางอย่างที่ไม่เหมาะกับงานทำให้ การจะปรับเปลี่ยนนั้นทำได้ยากเพราะโดยคุมด้วย service ที่เลือกครับ
  • แต่ข้อดีคือเราได้เรียนรู้เครื่องมือใหม่ๆที่เขาเลือกนั่นแหละ และทำให้เราได้เรียนรู้อีกว่า การเลือกเครื่องมือผิด ชีวิตมันจะบัดซบขนาดไหน อย่างเวลาทีมบริษัทเราจะเลือกใช้ก็ต้องหา pro / con มาเถียงว่าใช้เพราะอะไร แล้วค่อยตัดสินใจเลือกกัน หรือไม่ก็ได้ความรู้จากโปรเจ็คที่ผ่านมาว่าอันไหนดีไม่ดีครับ

PM ไม่ดีเป็นอย่างไร

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

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

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

ใช้งบประมาณเท่าไร ต้องคุมงบประมาณเพราะการขอเวลาขอ Dev จะเป็นการที่ต้องจ่ายเงินเพิ่มเข้าไปใน Project ต้องเท่าไรถึงจะคุมหรือเพียงพอ

Lead dev ไม่ดีเป็นอย่างไร

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

  • ไม่เรียนรู้ระบบใหม่ๆ หรือระบบของตัวเอง
  • นอกจากไม่เรียนรู้ระบบตัวเองแล้วไม่พยายามพัฒนาให้ตัวเองเข้าใจมากขึ้น กลับกลายเป็นปล่อยให้ vender ทำ ซึ่งกลายเป็นฝากชีวิตตัวเองไว้กับ vender
  • ดูแลทีมไม่ได้เลย ทีมทำพลาดเอามาด่าให้คนอื่นเห็นอีก ทั้งๆที่งานของน้องก็ควรจะผ่านตาของทีม lead บ้าง

เรียนรู้เวลา UAT กับลูกค้าของลูกค้า

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

Tip & Trick

ตรงนี้จะรวมเป็นพวกเกร็ดเล็ก เกร็ดน้อยที่จดๆไว้ตอนที่ผมทำผิดพลาดและโดนด่าเลยจดเตือนตัวเองไว้ว่าจะไม่ทำพลาดแบบนั้นอีกครับ

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

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


Deprecated: Theme without comments.php is deprecated since version 3.0.0 with no alternative available. Please include a comments.php template in your theme. in /home/zp1291/domains/oxygenyoyo.com/public_html/wp-includes/functions.php on line 4913

ฝากข้อคิดเห็น

This site uses Akismet to reduce spam. Learn how your comment data is processed.