พูดตามตรงเลยว่าวันนี้หลังออกจากห้องประเมินนี่โคตรเครียดเลย.. จิงๆ..
ตอนนี้มันมีอะไรหลายอย่างเต็มหัวไปหมดเลย.. อะไรผุดขึ้นมาเราก็ดึงมาเขียนละกัน อ่านรู้เรื่องหรือไม่ก็อีกเรื่อง ขอระบายในนี้ละกัน จริงๆแล้วมันก็ควรจะพูดให้จบในห้องหน่ะแหละ แต่ตอนนั้นมันนึกอะไรไม่ออก อึ้ง+มึน ไม่รู้จะพูดอะไร มันค่อนข้างขัดกับที่เราคิดไว้มาตลอดเวลา ความคาดหวังของเรากับของพี่เค้ามันต่างกันหว่ะ.. ออกมาพอตั้งสติได้ ก็ค่อยเรียบเรียงความคิดเก่าๆในช่วงเวลาที่ทำอยู่ตอนนั้น.. ก็พอได้มองเห็นอะไรบางอย่าง
พี่เค้าบอกเราประเด็นเดียวเลยคือข้อเสียที่เด่นชัดของเรา ทำงานช้ามากๆ (ย้ำ) ตามมุมมองของพี่เค้ามันควรจะเสร็จได้เร็วกว่านี้ ไม่ควรใช้ manday เยอะขนาดนี้ และเราเป็นคนที่ test ละเอียดมากเกินไป!?! พยายามจะหา case นู้น case นี่มา test เพื่อหา defect ต่างๆ ซึ่งไม่จำเป็นต้องทำถึงขนาดนั้นก็ได้ มันเสียเวลาเกินไป (งั้นเหรอ!?! อ่อ.. พอรู้แล้วล่ะ ว่าต่อไปเราต้องทำอย่างไร) โปรโมทขึ้นไปมีปัญหา ก็โปรโมทแก้ก็ได้ พี่ก็ไม่ได้ว่าอะไร… (อืม.. ครับ)
เรายังใหม่ เราต้องศึกษาระบบ การเพิ่มระบบใหม่เข้าไปเราต้องแก้เยอะมาก บางทีต้องแก้ถึง core และเราก็ควรจะต้อง test เยอะมาก มิใช่เหรอ?
การเพิ่มระบบใหม่ทำให้ระบบ complex มากขึ้น เราต้องพยายามทดสอบนู้นนี่ เพื่อหาทาง optimize มัน มิใช่หรือ?
งั้นสู้เราทำงานให้เสร็จ ให้พอใช้ได้ ทำงานถูกต้อง ก็เพียงพอแล้วใช่ไหม.. พอ live ไป ระบบช้า ลูกค้าบ่น แล้วค่อยเปิด task มาให้เรา แก้ให้ดีขึ้น ได้ manday มาทำอย่างสบายใจแฮ แถมยิ่งได้ความดีความชอบอีกต่างหาก.. โอ้วว้าว.. ธีรเดช โอเวอร์เอ๊กซ์เปกมาก.. (ประชด)
บั๊กหลายๆตัวที่แก้ไป บั๊กหลายๆตัวที่ลูกค้าติดใจมานาน.. ก็ถูกพบในช่วงเวลาที่เราถูกมองว่า "มันเสียเวลาเกินไป" นั่นแหละ เอวํ
เราไม่รู้นะ.. สำหรับเรา เวลาที่เสียไป กับสิ่งที่ได้กลับมา กับสิ่งที่วันนี้เปิดใช้งานวันแรกได้อย่างไม่มีปัญหา กับความเร็วที่เพิ่มขึ้น กับเซิร์ฟเวอร์ที่ทำงานลดลง.. มันคุ้มนะ!! แต่ก็นั่นแหละต่างคนต่างมุม.. เราอาจจะเน้น Quality มากเกินไป โดยลืมนึกถึง Throughput ที่ออกมาจาก black box ขี้เลื่อยนั่น
เวลาพี่หันไปถามธี.. ธีก็บอกว่ายังไม่เสร็จตลอด ติดนู้นติดนี่ พี่ก็เลยต้องให้คนอื่นทำ (คือส่วนใหญ่ที่พี่หันมาถาม คืออยู่ดีๆก็มาถามว่า เป็นไงทำถึงไหน เสร็จแล้วยัง เราก็คงต้องตอบไปตามคำถามว่า เหลือนู้นนิดนี่หน่อย ติดตรงนี้อยู่ แล้วก็หันไป จบบทสนทนา โดยเราก็ไม่รู้หรอกนะว่า นั่นคือถามเพื่อจะเอางานใหม่ให้ทำ ซึ่งจริงๆบางครั้งมันก็มีเวลาว่างแหล่ะ ไอ่งานที่ติดนิดๆหน่อย มันก็ไม่ได้ทั้งวัน ให้เอามาทำก็ได้ ซึ่งถ้ามองอีกมุมเราก็ผิดที่ไม่ยอมถามหรือเสนอตัว ส่วนครั้งไหนที่พี่เค้าตะโกน task ออกมา อยากหาคนทำก็มักจะเป็นช่วงที่เรางานเข้าตลอดเลย เหอๆ แต่ข้อนี้เราก็ ok เกินครึ่งก็น่าจะเป็นความผิดเราเองที่ไม่ยอมบอกพี่เค้าว่ายังพอมีเวลาว่าง.. (ไม่เหมือนปีที่แล้วที่ไฟยังแรงๆ))
ใบประเมินให้มาเขียนตอนเช้า แล้วให้ส่งตอนเย็น บังเอิญว่าวันนั้นเราท้องร่วงอย่างหนัก ถ่อไปออฟฟิศอย่างทุลักทุเล ก็คงเขียนไม่ละเอียดด้วยละมั้ง ไม่มีกะจิตกะใจจะเขียน.. อันนี้ก็คงต้องโทษตัวเอง.. ที่เขียนแต่งานที่ใหญ่ๆไปจริงๆ งานก็เลยดูน้อย.. ไม่รู้ว่าตอนเขียนไป คิดอะไรอยู่นะ..
แล้วที่แก้ไป เราโอเคใช่มั้ย (เอ่อ.. ครับ.. มันได้เลขตรงตามที่พี่ตั้งไว้ในใจแล้วล่ะครับ.. ..ผมก็ไม่รู้จะแก้ไงแล้วครับ..)
เราก็เข้าใจนะว่าพี่เค้าก็คงลำบากใจแหละ.. เป็นเราเราก็โคตรจะลำบากใจ หรือเครียดกว่านี้ก็ได้.. แต่ก็นะ.. ต่างคนก็ต่างมีหน้าที่ของตนเอง ก็พึงปฏิบัติไปตามหน้าที่ของตนเองให้ดีที่สุด รับฟังความคิดเห็นคนอื่น.. คำชมก็โปรยใส่ตัวให้ชื่นใจ คำติก็รับใส่หัวเอาไปปรับปรุงให้ดีขึ้น.. เราทำงานเป็นทีมเป็นสัตว์สังคม ต้องรับฟังและยอมรับมติของสังคม ^^
ไม่ว่าจะเป็นอย่างไรผมก็ยอมรับผลการตัดสินใจของทุกท่านอยู่แล้วครับ ทุกท่านทำดีที่สุดแล้วครับ 🙂
คุณทำดีที่สุดแล้ว แต่ยังดีไม่พอสำหรับพวกเรา เชิญค่ะ!! (แป่ว!) TT
ps. เรารู้สึกว่าเราได้รับรู้ช้าไป น่าจะได้รู้ความคาดหวังของพี่เค้าตั้งแต่ประเมินกลางปี (แต่ปีนี้ดันไม่มี!!) ไม่น่าจะต้องลากยาวมาถึงปลายปี.. กว่าจะรู้ก็สายไปแล้ว (สำหรับปีนี้)…
พี่เพิ่งเห็นโลกแห่งการทำงานจริงจริงจังจังจากคำพูดของน้องนี่แหละค่ะ
ขอบคุณที่ทำให้พี่เห็นโลกอีกมุมนะค่ะ (ไม่ใช่เห็นแต่งานวิจัย)
พี่เชื่อว่าน้องธีทำดีที่สุดแล้วค่ะ (อย่างที่เขียนไว้) แต่คำว่าดีไม่พอนั่นไม่จริงนะค่ะ
คำว่าดีมันแก็แปลความได้มากมาย ถ้าทุกคนทำตามอย่างที่คนอื่นวาดฝันทุกอย่างไว้ ว่าเราต้องทำได้อย่างนั้นอย่างนั้น
โลกนี้ก็ไม่มีคำว่า "อุดมคติ" ซิค่ะ
เห็นแกเขียนตั้งแต่เมื่อเช้าแล้ว เพิ่งมีเวลาเมนท์
โปรแกรมที่บั๊กน้อยลูกค้าเค้าก็มักไม่ค่อยชมเท่าไหร่หรอก แต่ถ้าบั๊กเยอะก็มั่นใจได้ว่าโดนด่าแน่ๆ เวลาเขียนโปรแกรมมันต้องมี trade-off ระหว่างคุณภาพของงานกับความเร็วในการทำอยู่แล้วหละ ดังนั้นบั็กยังไงมันก็ต้องมี แต่ขึ้นอยู่กับว่าเวลาที่จะเทสมันมีเท่าไหร่ ถ้ามีงานที่ต้องทำเยอะแต่คนเท่าเดิม เวลาการทำงานมันก็ต้องลดเพื่อให้มันมี features ที่ต้องการครบด้วยเช่นกัน เราคิดว่าในมุมมองของคนจัดการresource เค้าอยากให้มี features มากที่สุดในขณะที่มีบั๊กในระดับที่ยอมรับได้ (5%, 10% ก็ว่ากันไป) ดังนั้นเวลาที่เค้าคิดว่าจะต้องเสร็จ มันคือสมบูรณ์ xx% ตามมาตรฐานของเค้า แต่ไม่ใช่ถูกต้อง 100%
เราว่านะ แกควรจะไปคุยตกลงเลยว่าสิ่งที่ทำมันควรจะเสร็จในเวลาเท่าไหร่ ในความคิดของพี่เค้ามีเปอร์เซ็นต์ที่ยอมรับการเกิดบั๊กอยู่เท่าไหร่ เอาตัวเลขเป็นตัววัด ทุกคนเห็นเหมือนกัน ทุกคนเข้าใจตรงกัน ถ้าไม่เข้าใจ ก็ต่อรองกันได้ แบบนี้มันน่าจะแฟร์กว่านะเพราะความสามารถของแต่ละคนก็ไม่เท่ากัน จะใช้ความรู้สึกเป็นตัวตัดสินมันไม่ได้ เรื่อง test ก็พยายามทำให้มากที่สุดเท่าที่เวลาจะมี ถ้าแก้ไม่ทันก็โน้ตไว้ว่าเป็น known issue แล้วค่อยมาแก้เมื่อมีเวลา (หรือลูกค้าreportปัญหามา) ทุกคนชอบ developer ที่ทำงานละเอียดอยู่แล้วหละ
ส่วนเรื่องถามเพื่อให้งานเพิ่ม แกลองถามต่อดูว่ามีงานอะไร เร่งแค่ไหน ถ้าเค้ามี timeline ก็น่าจะรู้ได้ แล้วตัวแกเองก็น่าจะประเมินได้อ่ะว่าสามารถรับงานเข้ามาทำได้หรือเปล่า
ทั้งนี้ทั้งนั้นเราใช้ประสบการณ์ที่เราทำกับบริษัทเรานะ ถ้ามีอะไรเอาไปใช้ได้ก็ใช้ด้วยหละกันนะ ชีวิตจะได้แฮ้ปปี้ขึ้น ^^
แกเป็นคนมีความสามารถอยู่แล้ว บริษัทถ้าขาดแกไปคงต้องเสียใจแน่นอน 😀
ช่วงนี้เศรษฐกิจตกต่ำ
ยังไงก็ต้องอดทนว่ะ
อย่าเปรี้ยวมาก
เดี๋ยวโดนปลด
-*-