Profile cover photo
Profile photo
Gant Kulnirundorn
About
Gant's posts

Post has attachment
แตงโม Minecraft!

(เพื่อนที่อยู่ญี่ปุ่นบอกว่าเห็นจนชินแล้ว แต่เป็นของใหม่สำหรับผม = =')
Photo

Post has attachment
ฝนตกไม่ทั่วฟ้า :-o

ขอแท็กพี่หน่อย +noi meta 
Photo

คอมเม็นต์ที่ได้จาก code review รอบล่าสุดทำผมช็อคมาก

ขอเล่าว่า code review คือการส่งโค้ดที่เขียนไปให้คนอื่นดู ว่ายูโอเคด้วยรึเปล่า มีปัญหาอะไร หรือทำยังไงให้ดีขึ้นได้ ทำกันเป็นปกติในหลายบริษัท

เวลาขอ code review ในชีวิตประจำวันก็จะขอจากคนในทีม แต่รอบนี้พิเศษเพราะต้องส่งไปทีมอื่นที่เป็นทีมกลางดูให้ว่า เราทำตาม design langua.. เอ้ย style guide (code convention) รึเปล่า

ได้คอมเม็นต์กลับมาบานน =..='' แต่มีอันนึงที่เด่นออกมา
โค้ดใน unit test มันหน้าตาประมาณนี้ (แน่นอนว่าอันนี้โค้ดปลอม)

... = ImmutableList.of(new Person("James"), new Person("John"), new Person("Mark"));

ปัญหาคืออะไร?

คนที่รีวิวให้บอกว่า ให้ใช้ชื่อปลอมๆแทน (e.g. "P1", "P2", "P3") หรือไม่ก็ใส่ชื่อ ผู้หญิง เข้าไปด้วย เค้าว่าแผนก engineering นี่เป็นอะไรที่มีผู้ชายเต็มไปหมด (83% vs 17% ตามลิงค์แนบ)

แล้วเรื่องเล็กๆเช่นแค่ test case นี่ล่ะ บางทีทำให้ผู้หญิงใน engineering รู้สึกโดน exclude เข้าไปอีก...

:ผมนี่อึ้งไปเลยครับ:

ไม่ใช่ไม่เห็นด้วยนะ แต่คือ 1) ไม่เคยรู้ว่าเราทำให้คนอื่นรู้สึกแย่ได้ด้วยเรื่องแบบนี้ 2) ปกติเห็นภาพตัวเองว่าเป็นคนเท่าเทียม ผู้ชาย ผู้หญิง LGBT .. แต่ตัวเองก็อาจจะ bias โดยไม่รู้ตัวเหมือนกัน...

http://www.google.com/diversity/at-google.html#tab=womengoogle&tab=tech

Post has attachment
Was able to get myself out of the apartment yesterday :-)
Went to Yokohama.

Post has attachment
Gant Kulnirundorn commented on a post on Blogger.
Wow setting up your window manager. What a productive thing to do! ... And I thought I would get to read a post about Haskell ...

Post has attachment
Gant Kulnirundorn commented on a post on Blogger.
แก่ว่ะ 
ปล. รอยเตอร์ตอนนั้นพวกเราฝากชื่อผ่าน อ.ญาใจแล้วกว่าจะได้ผลมันช้าจนใกล้เดดไลน์มาก คนส่วนใหญ่เลยได้งานที่อื่นกันหมดแล้ว

Post has attachment
คนแปล: แปลไทยมาให้อ่านเล่น เพราะแก๊นอ่านแล้วชอบแนวนี้มาก :) บทความต้นฉบับเขียนโดย Ken Norton - https://www.kennethnorton.com/essays/how-to-work-with-software-engineers.html เผยแพร่ภายใต้ Creative Commons Attribution 3.0 Unported License - http://creativecommons.org/licenses/by/3.0/deed.en_US

ผมทำงานในสายเทคโนโลยีมา 20 ปี โดยที่ใน 13 ปีหลังมานี้ทำงานเป็น product manager ผู้คนเชื่อถือผมในเรื่องการทำงานกับ software engineer มาก จนผมได้รับการจัดอันดับเป็น หนึ่งในสาม product manager ที่เก่งที่สุด เลยทีเดียว (อีกสองท่านเป็น Steve Jobs และ Niccolò Machiavelli)

หลายปีมานี้ผมเก็บความลับเกี่ยวกับเทคนิคของผมไว้อย่างดี แต่วันนี้ผมจะมาเล่าให้ฟังหมดเปลือกว่า 10 ขั้นตอนการทำงานกับ software engineer ให้ได้ผล นั้นเป็นยังไง หรือจะพูดให้เข้าใจง่ายๆก็คือ จะทำยังไงให้ software engineer ยอมเชื่อฟัง!

แล้วทำไมคุณต้องฟังผม (ผู้ได้รับการจัดอันดับเป็นหนึ่งในสาม PM ที่เก่งที่สุด) ด้วยล่ะ? ลองมาคิดเป็นตัวเลขดู ผมประมาณคร่าวๆว่าตัวเองเคยทำงานกับ software engineer มาทั้งหมด 3,875,000 คน ในกลุ่มนี้มึถึง 95% ที่เชื่อฟังสิ่งที่ผมบอก นั่นหมายถึงมีคนตั้ง 1,000,000 คนที่เชื่อฟังผม (เป็นเลขประมาณคร่าวๆเท่านั้น - PM ยุ่งมากไม่มีเวลาคิดเลขหรอก) ตัวเลขนี้หมายถึงวิศวกรจำนวนมหาศาลและประสบการณ์มากมายที่คุณจะได้รับจากการอ่านเรื่องนี้

1. ยอมรับคำชม

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

2. โยนความผิด

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

3. อย่าใส่ใจรายละเอียด

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

4. ไม่ต้องรีบบอก

software engineer ทำหน้าที่เขียนโค้ดอย่างเดียว คนพวกนี้บ่นเสมอเมื่อมีอะไรไปกวนเวลาเขาตั้งใจทำงาน แล้วคุณจะไปถ่วงเวลาพวกเขาโดยการเรียกมาประชุมวางแผนโปรเจคก่อนถึงเวลาเขียนโค้ดทำไม? คุณเคยเห็นสถาปิกเรียกช่างก่ออิฐโบกปูนไปนั่งปรึกษางานออกแบบในออฟฟิศรึเปล่าล่ะ? จงวางแผนกลยุทธ์และระดมความคิดตกลงเรื่องต่างๆให้เรียบร้อยก่อน แล้วที่เหลือก็แค่เอาคนมาเขียนโค้ดแค่นั้นเอง ง่ายนิดเดียว ..

5. เพิ่มโปรเซส

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

6. อย่าบอกเหตุผล

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

7. สัญญาแทนทีม

หน้าที่ของการเป็น PM คือการให้คำสัญญาต่างๆกับคนนอกในฐานะตัวแทนทีม คุณต้องแสดงความเป็นผู้นำโดยการตั้งมาตรฐานสูงๆ และท้าทายให้คนในทีมพยายามก้าวข้ามมัน แสดงความเก๋าโดยการตั้งเดดไลน์ให้โปรเจคโดยไม่ต้องคุยกับลูกทีม การต้องทำให้ได้ตามความคำสัญญา​ (ของคนอื่น) เป็นการพัฒนาคนแบบหนึ่ง และจะดึงศักยภาพสูงสุดของคนออกมาได้  ตัวอย่าง: ประธานาธิบดี JFK เคยกำหนดวันมั่วๆที่มนุษย์จะเหยียบดวงจันทร์ และ NASA ก็ทำได้ก่อนกำหนดนั้นเสียด้วย!

 8. อย่าเกรงใจถ้าจะใช้งาน

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

9. กำกวมเข้าไว้

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

10. ลูกทีมโกหกเสมอ

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

ทั้งหมดที่กล่าวมาเป็นขั้นตอน 10 ขั้นในการทำงานกับ software engineer ของผม พิมพ์หน้านี้ออกมาแล้วเอาไปแปะไว้ที่โต๊ะคุณได้เลย (แต่ระวังอย่าให้คนอื่นมาเห็น) ถ้าคุณทำตาม รับรองว่าไม่ช้าคุณจะเป็น PM ที่เก่งแน่นอน (แต่อาจจะไม่ติด 3 อันดับแรกนะ) ง่ายนิดเดียวเอง

สรุป

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

1. ส่งต่อคำยกยอ
2. ยอมรับความผิด
3. เจาะลึกรายละเอียด
4. เอาทีมเข้ามามีส่วนร่วมให้เร็วที่สุด
5. ทำให้ขั้นตอนต่างๆไหลลื่น
6. บอกเหตุผลเสมอ
7. อย่าสัญญาอะไรถ้ายังไม่ถามทีม
8. เคารพเวลาของผู้อื่น
9. เฉพาะเจาะจง
10. เชื่อใจทีม
และสุดท้าย
11. ซื้อของกินไปฝากทีมบ้าง

(ปล. สามอันดับ PM ที่เก่งที่สุดรวมถึงตัวเลขทั้งหมด เข้าใจว่าคนเขียนบทความต้นฉบับเค้าตั้งมามั่วๆอ่ะนะ - -' (เผื่อใครไม่เก็ต))

 
Photo

Post has attachment

Post has shared content
interesting
(16) A premortem is the best way that I know to increase the probability of a project's success. It means you tell the team to assume that the project failed and then come up with the reasons why it failed. Then you eliminate as many of those reasons as possible.

Read Gary Klein's explanation of how to do this right:

http://hbr.org/2007/09/performing-a-project-premortem/ar/1
Photo

Post has attachment
Wait while more posts are being loaded