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

คำถามที่คนอยากรู้ แต่ตอบยังไงให้ถูก ถ้างานที่อยากได้ มันเป็นงานที่สามารถประเมินได้ง่าย เช่นเอาน๊อตใส่รูแล้วขันสามรอบ งานแบบนี้ค่อนข้างประเมินง่าย เพราะเรารู้ flow รู้ speed รู้ความสามารถของคนที่ทำว่าทำได้กี่ตัวต่อนาที และยิ่งรู้จำนวนคน แบบนี้ก็ยังพอประเมินได้บ้าง แต่ว่า งานแบบเขียนโปรแกรม มันต่างออกไปอย่างมาก มันทำให้การประเมินทำได้ยากแบบที่ ถ้าจะให้ประเมินได้ถูก มันต้องมีสักคนที่เจ็บตัว ไม่ว่าจะเป็นกลุ่ม Developer ที่ถ้าประเมินวันมาน้อยเกินไป ก็ต้องทำงานกันหามรุ่งหามค่ำ และก็อย่างที่รู้ๆกันว่า OT มันมีแค่ทำงานล่วงเวลา แต่ค่าล่วงเวลามันไม่มี หรือถ้ามันไม่ทันจริงๆในที่สุด คนที่เจ็บก็ต้องเป็น Business เพราะส่วนมากจะไปสร้าง commitment เอาไว้ โดยเฉพาะอย่างยิ่ง ถ้ามีการตลาดเข้ามาเกี่ยวด้วยจะยิ่งเจ็บหนัก…

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

บอกตามตรงครับว่า ช่วง 2–3ปีหลังๆ (2021–2023) ที่ผ่านมานี้ ผมได้ไปเจอทีม Software Dev ที่ทำ Agile หรือ Scrum มาหลายรูปแบบ ซึ่งจะดูทิศทางไปแนวๆเดียวกัน และเป็นแนวที่ผมจะรู้สึกแปลกๆ ไม่ค่อยสบายใจเป็นการส่วนตัว ค่อนข้างมากอยู่พอสมควรเลย สิ่งที่ผมรู้สึกไม่ค่อยสบายใจที่สุดก็คือการ estimate งานใน sprint ที่เดิมผมเคยทำมา เราจะใช้หลักการการใช้ point หรือ ใช้เลขลำดับ fibonacci เป็นเกณฑ์ เพื่อสื่อสารว่างานนั้นๆมีความยากง่ายในระดับไหน แต่ช่วงที่ผ่านมา ผมเจอหลายที่ถูกกำหนดให้ estimate เป็น man day หรือ man hour แทน และที่สนุกกว่าคือ วิธีการ Daily จะใช้วิธี walk the wall และคนที่เป็น facilitator คือ Scrum…

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

ในชีวิตประจำวันกับการทำงานของคนทำ software มันจะต้องยุ่งเกี่ยวกับพวก credential ต่างๆ user/password ต่างๆอยู่แทบทุกเมื่อเชื่อวัน ไหนจะ user/password เพื่อ login เข้าเครื่องตัวเอง, user/pass สำหรับ login เข้าระบบบริษัท, user/pass เข้า app chat ที่เราเอามาใช้เพราะสะดวกกว่า, user/pass เข้าระบบบางอย่างเพื่อดู dashboard, user/pass ของ database เพื่อเข้าไปดู data เวลาต้องเทสระบบ และอีกมากมาย และเอาเข้าใจ เราจำไม่ไหวหรอกครับ เพราะชีวิตส่วนตัวเราก็มี user/password อีกนับไม่ถ้วน เพราะฉะนั้น โลกนี้จึงมีระบบที่ทำมาเพื่อช่วยจำ user/password แทนเรา เพียงแค่เราต้องจำ 1 master password เพื่อเข้าหามันคนเดียว ยกตัวอย่างเช่นพวก 1Password, Lastpass, Keeper และอื่นๆ…

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

ในกลุ่มที่ทำ Agile Team ในงาน Software Dev ปกติเราจะมีหนึ่งกิจกรรมที่มักจะนัดกันในช่วงเช้า ก่อนเริ่มต้นทำงาน เพื่อให้ได้ sync-up กันไวไว ว่าเมื่อวานแต่ละคนทำอะไรไปที่เป็นเรื่องสำคัญ และติดปัญหาอะไรหรือไม่ ต้องการความช่วยเหลือหรือเปล่า และวันนี้คิดจะทำอะไร ซึ่งโดยปกติในทีมที่มีคนราวๆ 10 คน อาจจะใช้เวลาประมาณแค่ 5 นาทีก็อาจจะจบ meeting นี้ได้เลย เราเรียกกิจกรรมแบบนี้ว่า Standup Meeting หรือบางทีก็เรื่อง Daily Scrum หรือชื่ออื่นๆที่ถนัดและเข้ากับกระบวนการที่ใช้

ในหลายๆอุตสาหกรรม จะมีวิธีการจัดการในการผลิตผลงานออกมาแตกต่างกัน แม้แต่ในอุตสาหกรรมซอฟท์แวร์เอง ซึ่งในหลายกรณีมันจะสะท้อนออกมาอยู่ในรูปแบบการจัดการองค์กรนั้นด้วย ผมยกตัวอย่างการจัดการทีมแบบแยกตาม function เช่นทีม Dev ที่มีการแยกเป็น ทีม Backend ทีม Frontend Web ทีม Frontend iOS ทีม Frontend Android ทีม DevOps ทีม Operations Support การแบ่งทีมตาม function จะช่วยให้แต่ละทีมมี skillset เฉพาะชัดเจน และทีมจะชำนาญงานนั้นๆมาก โดยส่วนตัวผมมักจะเห็นการแบ่งทีมแบบนี้ กับการใส่งานลงไปแบบที่มองทีมเป็น pool โดยไม่ว่าใครจะอยากได้งานแบบไหน ก็จะมีทีม PM/BA/Architect ไปคุยกันมาจนเสร็จ เหลือแค่เขียนโค้ด ก็จะแยกงานตาม function แล้วโยนใส่ pool ลงไป เดี๋ยวก็เสร็จ…