ก่อนอื่นต้องบอกก่อนว่าผมทำการเป็น Software Engineer ครับ งานที่ทำก็ทำ software เขียน code ต่างๆ หรือบางทีพวกเราก็โดนเรียกว่า dev ( software developer ) ครับ บทความนี้ผมก็จะแทนตัวเองว่าผมเป็น dev ไปเลยแล้วกัน
Table Of Content
- ที่มาของบทความนี้
- USE CASE
- PM คือใคร
- วันๆ PM คิดอะไรอยู่
- PM คาดหวังอะไรกับ DEV
- แล้ว DEV ความหวังอะไรกับ PM
- สรุป
ที่มาของบทความนี้
คือการทำงานในแต่ละวัน พวกเราที่เป็น Dev ก็จะได้ทำอะไรหลายๆ อย่างแหละครับ ที่ไม่แน่ๆ ไม่ใช่แค่เขียน code ไปวันๆ แน่นอนครับ
และการทำงานหลายๆ อย่าง เราก็มีโอกาสที่จะได้เจอกับคนมากหน้าหลายตา หลายๆ หน้าที่ความรับผิดชอบ ไม่ว่าจะเป็น PO, PM, BA, Develer ด้วยกันเอง, User, Tester, Partner, DevOps, Infra, Partner และอื่นๆ
จะเห็นได้ว่ามันมีคนหลายกลุ่มมากๆ ในการสร้าง Software ขึ้นมา แต่ละคนก็มีความต้องการของตัวเอง เช่น
PO อยากได้โปรดักต์ใหม่ ก็ไปคิดมาว่าอยากได้อะไร
PM ก็เอามาตั้งเป็นโปรเจกต์ แตก scope, วาง timeline, ของบเพื่อเอามาสร้าง product
BA ก็ไปเอา scope มาแตก detail แปลงภาษาธุรกิจเป็นภาษาที่ Dev จะเข้าใจ
Dev ก็เอามาทำการ Dev บางครั้งก็ต้องมีคุยกับ devops หรือ infra เพื่อขอเครื่อง server, pipeline
จากนั้นก็ส่งงานที่ทำเสร็จแล้วใน Tester ไปทำการ Test
Test เสร็จแล้วก็ส่งให้ Partner ไปใช้งาน และทำการ sign off เอกสารรับงาน
แล้วก็ส่ง product ที่ทำเสร็จแล้วนี่ไปให้ Release team ปล่อยของออกไปให้
ที่ผมร่ายยาวๆ มาเนี่ย ก็เพื่อจะบอกว่าการทำ software 1 ชิ้น ถ้าเป็นองค์การใหญ่ๆ มันมีผู้คนเข้ามาเกี่ยวข้องเยอะมากๆ และปกติแล้วมันก็ไม่ได้โลกสวยนะครับ แต่ละคนก็มีความต้องการของตัวเอง อยากได้ทรัพยากรไม่ว่าจะเป็นเงิน หรือเวลามากที่สุดเท่าที่จะเป็นไปได้
แต่ว่าโครงการใดๆ ก็ตามแต่ ทรัพยากรที่มีให้มันมีจำกัดครับ อย่างโครงการ “คนละครึ่ง” มีเวลาเพียง 1 เดือนในการพัฒนางี้ โครงการจะรอดไม่รอดผมมองเห็นคนที่เป็น Keyman สำคัญอยู่ 1 คนครับ นั่นก็คือ PM นั่นเองครับ
PM ( Project Manager ) คือใคร
ในมุมของ Dev ที่มองเข้าไปหา PM นะครับ ผมมองว่า PM คือคนที่ต้องบริหารโครงการ คือคนที่คอยควบคุม Rythm ของการพัฒนาซอฟต์แวร์ เขาจะเป็นคนที่ทำหน้าที่วางแผนโครงการว่าการที่มันจะสำเร็จได้ มันต้องทำอะไรบ้าง ใช้เวลาเท่าไหร่ ใช้เงินเท่าไหร่ ใครเกี่ยวข้องบ้าง ( ที่ผมเกริ่นไว้ตอนแรก ) ใครต้องทำอะไร ความเสี่ยงของโปรเจกต์คืออะไร โปรเจกต์ดำเนินไปตามเวลาไหม ช้ากว่าที่กำหนดไว้ไหม ถ้าช้าไปต้องทำอย่างไร หรือถ้าโปรเจกต์เร็วกว่าที่คาดหวังไว้ ทำไมถึงเร็วเกินไป มันสอดไส้อะไรไหม มีคุณภาพหรือเปล่า PM ที่เก่งๆ ที่ผมเคยเจออะนะ เขาคุมได้หมดเลย เรียกว่าเป็นตำแหน่งที่สร้างความประทับใจได้มากทีเดียว
วันๆ PM คิดอะไรอยู่
ผมอยากเข้าใจ PM ครับ ก็เลยไปหาคอร์ดลองไปนั่นเรียนดู เลยเอามาแชร์ครับ
ถ้าตามทฤษฎี project management triangle เลย เขาจะสนใจข้อกำหนดอยู่ 3 อย่าง ตามในรูปด้านบนครับ
Scope : คือ Task ทั้งหมดที่ต้องทำให้เสร็จ และส่งงานให้กับ Stake Holder ซึ่งอาจจะเป็นลูกค้า หรือหน่วยงานที่ต้องคอยดูแล product นั้นๆ ที่ทำเสร็จไปแล้ว
Time : เวลาที่ต้องทำให้เสร็จ อะไรต้องทำเสร็จก่อนหลัง อะไรทำพร้อมกันได้
Cost : ทรัพยากรที่ต้องใช้ อาจจะเป็นเงินที่ต้องจ้าง developer ค่า server ค่า cloud
ถ้าในระหว่างที่โปรเจกต์ดำเนินไป และมี change เข้ามา และต้องปรับข้อใดข้อหนึ่ง ก็จะกระทบกับอีกสองข้ออย่างเลี่ยงไม่ได้ครับ
เช่น ในตอนแรกเรากำหนด Scope ของ โปรเจกต์ ว่าต้องมี Task [ A, B, C, D ] ใช้เวลา 4 เดือน ใช้เงิน 4 แสนบาท แล้วอยู่ดีๆ user อยากเพิ่ม feature ให้ task A. PM ทำการประเมินแล้วว่า Task A ต้องใช้เวลาเป็นเพิ่มอีก 1 อาทิตย์ ถ้าเราไม่ไปดึงเวลาออกจาก task B, C หรือ D เราก็ต้องยอมรับว่า โปรเจกต์นี้ต้องใช้เวลาทั้งหมด 4 เดือน กับอีก 1 อาทิตย์ ซึ่ง 1 อาทิตย์ที่เพิ่มมาก็จะมีค่าใช้จ่ายเพิ่มขึ้น เป็นต้นครับ
PM คาดหวังอะไรกับ DEV
จากข้อที่ผ่านมา PM เขาจำเป็นต้องรู้ scope ของงานว่าต้องทำอะไรบ้าง ซึ่งในส่วนของการสร้างซอฟต์แวร์ ไม่ว่าจะเป็นการเขียนโปรแกรม การต่อ database การดีพลอย prototype ขึ้น server บลาๆ เนี่ย คนที่รู้ดีที่สุดก็คือ Dev ครับ
ซึ่ง PM มักจะคาดหวังให้ Dev ใช้ประเมินให้ว่า Dev มี task อะไรที่ต้องทำบ้าง ใช้เวลาทำแต่ละ task ตามที่ควรจะเป็นเท่าไหร่ หรือถ้าในระหว่างทำ ไม่สามารถส่งงานตามที่ commit ไปได้ ต้องรีบบอก ติดตรงไหนไหม ต้องการใครช่วยไหม ถ้าหาคนมาเพิ่มให้จะสามารถทำงานเร็วขึ้นไหม เป็นต้น
อีกอย่างเวลาทำงานเสร็จแล้ว Dev ก็ปัดตูดหนีไม่ได้นะครับ ต้อง Support การทดสอบโปรแกรม ต้องทำ Document ให้ดี เขียน API spec ให้ชัดเจน เพราะจะได้ Transfer Knowledge ได้ง่ายๆ เป็นต้นครับ
แล้ว DEV ความหวังอะไรกับ PM
คาดหวังว่า “~ ได้โปรดอย่าทำร้ายกันเลย ~”
Dev เองก็คาดหวังว่า PM จะได้ Requirement ที่มัน Solid มี Task ที่ชัดเจน ไม่คลุมเครือซึ่งอาจจะเกิดการ misunderstanding ได้ ทำให้เวลาเอาไปทำการเขียนโค๊ด ก็ทำผิด ทำไม่ครบ มารู้ทีหลังก็เจอว่าต้องแก้ ถ้าไม่อดหลับอดนอนท่แก้ให้ทัน ก็ต้องยอมให้มันกระทบ Timeline นั่นเองครับ
Dev คาดหวังว่า PM จะเป็นเกราะป้องกัน ไม่ให้ไปกระทบกระทั่งกับ stakeholder คนอื่นๆ เพราะว่า Dev ส่วนใหญ่ก็เข้าใจแต่ภาษา Dev นี่แหละครับ จะไปพูดให้ฝั่ง business หรือฝั่ง user เข้าใจได้ก็คงจะยาก แต่ PM คือคนที่อยู่ตรงกลางคือคนที่จะช่วยทำให้แต่ละฝ่ายเข้าใจกันได้
สรุป
บทความนี้ผมก็พยายามที่จะเรียบเรียงความเข้าใจหน้าที่ความรับผิดชอบของ PM พยายามอธิบายว่า PM ต้องการอะไรจาก Dev และ Dev ต้องการอะไรจาก PM
ผมหวังว่าคนที่มาอ่าน โดยเฉพาะ Dev บางคนนะครับ ที่อาจจะงงๆ อยู่ ว่า ทำไม PM ต้องมาให้เราประเมินอะไรก็ไม่รู้ ทำไมต้องทำเองสาร ทำไมบางทีทีมอื่นทำงานพลาดทำโปรเจกต์ช้า แล้วเราต้องมาอดตาหลับ ขับตานอนเพื่อทำงานให้ทัน มันมีที่มาที่ไปครับ
และถ้าเราช่วยกันดูโปรเจกต์ ช่วยกันประเมิน efford ที่ต้องใช้อย่างตั้งใจแต่แรก เราก็อาจจะลดความเสี่ยงที่ทั้งโปรเจกต์ต้อง delay ลงไปได้ครับ
