- แชร์กรณีตัวอย่างของการประยุกต์ใช้แนวคิด DevOps, Staff Engineering และ Platform Engineering ได้อย่างมีประสิทธิภาพในสภาพแวดล้อมสตาร์ทอัพ
- ผู้บรรยาย Chad McElligott เป็น Senior Staff Engineer ของ Smartrr ซึ่งเป็นบริษัทที่ให้บริการระบบสมาชิกและระบบสะสมแต้มบนพื้นฐาน Shopify
- เสนอวิธีการทางวิศวกรรมที่ออกแบบให้เหมาะกับวัฒนธรรมและข้อกำหนดเฉพาะของสตาร์ทอัพ
[แนวคิดหลัก]
DevOps
- คำจำกัดความของ DevOps แตกต่างกันไปในแต่ละคน สำหรับบางคนมันคือชื่อตำแหน่งงาน ขณะที่สำหรับอีกบางคนมันคือวิธีการทำงาน
- แนวคิด "DevOps as No Ops" ทำให้วิศวกรซอฟต์แวร์ต้องจัดการงานด้าน Ops ที่เกี่ยวข้องทั้งหมดด้วยตนเอง
- DevOps คือ การส่งมอบคุณค่าให้ลูกค้าได้อย่างรวดเร็วผ่านกรอบความคิดแบบร่วมมือกัน การทำงานซ้ำๆ และทำด้วยมือ( toil )ให้เป็นอัตโนมัติ และการใช้เครื่องมือสมัยใหม่
- แก่นสำคัญไม่ใช่แค่องค์ประกอบทางเทคนิคอย่างการใช้คลาวด์ การทำโครงสร้างพื้นฐานให้เป็นโค้ด หรือการสร้าง CI/CD pipeline เท่านั้น แต่ยังรวมถึงการทลายกำแพงด้านการสื่อสารและความร่วมมือเพื่อให้ได้ผลลัพธ์ที่ดียิ่งขึ้น
Platform Engineering
- Platform Engineering คือ แนวทางทางเทคนิคเพื่อลดภาระการรับรู้ของนักพัฒนา
- เป้าหมายคือการเพิ่มทั้งความเร็วในการพัฒนาผลิตภัณฑ์และความเสถียรของระบบไปพร้อมกัน โดยจัดเตรียมองค์ประกอบพื้นฐานที่สนับสนุนกิจกรรมของนักพัฒนา
- มีกรณีของบริษัทขนาดใหญ่ที่จัดตั้งทีม Platform Engineering เพื่อเพิ่มประสิทธิภาพและปรับปรุงประสบการณ์ของนักพัฒนาเพิ่มมากขึ้น
- แนวคิดนี้เป็นที่แพร่หลายผ่านหนังสือ Team Topologies ของ Manuel Pais และ Matthew Skelton และสามารถพบตัวอย่างการเสริมศักยภาพด้านวิศวกรรมได้จากสื่อต่างๆ
Staff Engineering
- Staff Engineering ไม่ใช่กรอบความคิดหรือทักษะเฉพาะ แต่เป็น บทบาท ที่วิศวกรซอฟต์แวร์รับผิดชอบภายในองค์กร
- เป็นขั้นของสายอาชีพหลังจาก Senior Software Engineer และอาจอธิบายได้ว่าเป็น servant leadership ของวิศวกรรมซอฟต์แวร์
- วิศวกรระดับ Staff+ ไม่ได้ขยายความรับผิดชอบแค่ในงานของตนเอง แต่รวมถึงทั้งองค์กร โดยทำงานร่วมกับผู้จัดการหรือ VP เพื่อให้มุมมองและการลงมือทำที่เป็นรูปธรรม
- ในหนังสือ Staff Engineer ของ Will Larson ได้อธิบายบทบาท Staff ออกเป็น 4 archetype ได้แก่ Architect, Right Hand, Tech Lead และ Fixer
[วัฒนธรรมสตาร์ทอัพ]
- สตาร์ทอัพที่ขับเคลื่อนด้วยเงินลงทุนจาก VC มักมีค่าใช้จ่ายมากกว่ารายได้เพื่อเร่งการเติบโต
- บริษัทใช้เงินทุนที่ระดมมาเป็น "runway" เพื่อไล่การเติบโตอย่างรวดเร็ว และต้องทำให้เกิดทั้งการเติบโตและความสามารถในการทำกำไรก่อนที่ runway จะหมด
- สภาพแวดล้อมนี้สร้างลักษณะทางวัฒนธรรมสำคัญ 2 ประการ
- ไม่มีเวลาให้เสียเปล่า
- การเสียเวลาในสตาร์ทอัพเป็นเรื่องร้ายแรงอย่างยิ่ง
- ทีมพัฒนาต้องโฟกัสที่เป้าหมายเชิงกลยุทธ์ขององค์กร และลงมือทำภายใน runway ที่มี
- สมาชิกแต่ละคนต้องตรวจสอบอยู่เสมอว่าสิ่งที่ทำสอดคล้องกับเป้าหมายหรือไม่ และหากจำเป็นก็ต้องปรับใหม่
- แม้การทดลองจะล้มเหลว แต่ถ้ามีโครงสร้างสำหรับการเรียนรู้และได้บทเรียนที่ต้องการ ก็ไม่ถือว่าเป็นความสูญเปล่า
- ทุกคนสวมหลายบทบาท
- ในองค์กรขนาดเล็กมีงานที่ต้องทำมาก แต่มีคนทำไม่พอ
- ตัวอย่างเช่น นักพัฒนา frontend อาจต้องควบบทบาทนักออกแบบผลิตภัณฑ์ นักเขียนเทคนิค ผู้จัดการผลิตภัณฑ์ ฝ่ายประกันคุณภาพ และผู้ดูแลการเชื่อมต่อกับ third-party ไปพร้อมกัน
- เมื่อมีไอเดียใหม่เพื่อปรับปรุงประสบการณ์ลูกค้า คนที่เสนอไอเดียนั้นอาจต้องรับผิดชอบสร้าง prototype หรือทำให้เกิดขึ้นจริงด้วยตนเอง
- คุณลักษณะทางวัฒนธรรมเหล่านี้เป็นตัวกำหนดความสามารถที่จำเป็นสำหรับกลุ่มพัฒนาผลิตภัณฑ์ และโดยเฉพาะผู้นำด้านวิศวกรรมซอฟต์แวร์
- นอกจากนี้ยังให้เบาะแสว่า DevOps, Platform Engineering และ Staff Engineering ควรปรับตัวอย่างไรในสภาพแวดล้อมของสตาร์ทอัพ
[การนำหลักวิศวกรรม (Tenet) ของฉันไปใช้กับวัฒนธรรมสตาร์ทอัพ]
DevOps ในสตาร์ทอัพ
- ในสตาร์ทอัพ การเปลี่ยนแปลงกระบวนการทำได้ง่าย
- เพราะมีคนน้อย จึงไม่มีอุปสรรคใหญ่ในการนำรูปแบบการทำงานใหม่มาใช้
- การปรับกระบวนการโดยยึดตามเครื่องมือจะให้ผลลัพธ์ที่ดีที่สุด
- หากคงกระบวนการที่แข็งตัวไว้ จะต้องเสียเวลาไปกับการปรับแต่งเครื่องมือหรือพัฒนาซอฟต์แวร์เพิ่มเติม
- ควรหลีกเลี่ยงเครื่องมือที่ทำขึ้นเองให้มากที่สุด
- ควรใช้ serverless infrastructure, เครื่องมือ SaaS และไลบรารีโอเพนซอร์ส
- ควรไปตามกระแสหลักของเทคโนโลยี และไม่ควรปรับแต่งเทคโนโลยีหากมันไม่ได้สร้างความได้เปรียบทางการแข่งขันที่แตกต่าง
- อ้างอิง: Utility vs Strategic Dichotomy ของ Martin Fowler
- ควรเลือก "เทคโนโลยีที่น่าเบื่อ"
- ไม่ควรเดิมพันความเสี่ยงใหญ่กับโซลูชันที่ทีมไม่คุ้นเคยหรือมีชุมชนเล็ก
- เมื่อเกิดปัญหา ควรเลือกเทคโนโลยีที่สามารถหาวิธีแก้ได้ง่ายทางออนไลน์
- สามารถดูคำบรรยายที่อธิบายแนวคิดนี้อย่างละเอียดได้ที่ boringtechnology.club ของ Dan McKinley
Platform Engineering ในสตาร์ทอัพ
- เนื้อหาที่กล่าวถึงใน Engineering Unblocked podcast ของ Rebecca Murphey:
- "Developer experience ของบริษัทคือผลิตภัณฑ์ชิ้นหนึ่ง ไม่ว่าจะถูกออกแบบไว้หรือไม่ก็ตาม"
- แม้จะเป็นสตาร์ทอัพ ก็ยังต้องมีการมอนิเตอร์ การดีพลอย การติดตามข้อผิดพลาด การตรวจสอบล็อก และการสลับ feature flag
- คำถามสำคัญคือ "งานเหล่านี้สร้างความเจ็บปวดหรือไม่?"
- Platform Engineering เป็นบทบาทแบบ part-time ในสตาร์ทอัพ
- ในช่วงแรกอาจจำเป็นต้องมีสภาพแวดล้อมทดสอบแบบรวมศูนย์ แต่ภายหลังอาจถูกลดความสำคัญลง
- บทบาทด้าน platform engineering จะถูกทำเมื่อจำเป็นเท่านั้น
- ไม่มีเวลาพอสำหรับทำโครงการแพลตฟอร์มระยะยาว
- ดังนั้นควรสร้างสิ่งที่มีคุณค่าผ่าน งานชิ้นเล็กๆ
- ควรแชร์ภาพใหญ่และวิสัยทัศน์ให้ทีมรับรู้ พร้อมทำให้เข้าใจว่าส่วนย่อยเหล่านี้เชื่อมกันอย่างไร
- งานด้านแพลตฟอร์มในสตาร์ทอัพคือกระบวนการบุกเบิก productivity และแนวทางใหม่ๆ
- โดยมากไม่ใช่การย้ายจากซอฟต์แวร์เดิมไปยังเครื่องมือสมัยใหม่ แต่เป็นการ สร้างสิ่งที่ไม่เคยมีมาก่อนขึ้นมาใหม่
- สิ่งสำคัญไม่ใช่ว่าเราทำอะไรได้บ้าง แต่คือการตัดสินใจว่า เราควรทำอะไร
- ควรโฟกัสกับงานที่แก้ปัญหาขององค์กรในปัจจุบันหรือปัญหาที่จะเกิดขึ้นในอนาคตอันใกล้
- ควรระบุงานที่จำเป็นผ่านประสบการณ์หน้างาน การพูดคุยกับวิศวกร feedback จาก retrospective และการวิเคราะห์ตัวชี้วัด SDLC(วงจรชีวิตการพัฒนาซอฟต์แวร์)
- บางครั้งการเลื่อนงานด้านแพลตฟอร์มออกไป แล้วไปโฟกัสกับความจำเป็นด้านอื่น อาจเป็นทางเลือกที่ดีกว่า
- หัวใจสำคัญคือการเข้าหาอย่างยืดหยุ่น
Staff Engineering ในสตาร์ทอัพ
- บทบาท Staff Engineer เหมาะกับสภาพแวดล้อมของสตาร์ทอัพ
- ความเชี่ยวชาญเชิงเทคนิคเชิงลึก แนวโน้มที่จะสร้างอิทธิพลในวงกว้าง และทัศนคติที่พร้อมเข้าไปช่วยในจุดที่จำเป็นเพื่อแก้ปัญหาธุรกิจ ล้วนเข้ากับสตาร์ทอัพได้ดี
- ในองค์กรขนาดใหญ่มีคำพูดว่า "รู้ว่าหนี้ทางเทคนิคถูกฝังอยู่ที่ไหน"
- Staff Engineer จะหาคนที่มีความรู้นี้ มาจัดระเบียบ และสรุปเป็นการตัดสินใจเพื่อเดินหน้าต่อ
- ในสตาร์ทอัพ หนี้ทางเทคนิคและปัญหาต่างๆ มองเห็นได้ชัดเจน
- Staff Engineer สามารถสร้างผลกระทบอย่างมากได้ด้วยการจัดการความวุ่นวายนี้และสร้างโซลูชันที่ช่วยองค์กรในระยะยาว
- ในสตาร์ทอัพ Staff Engineer ไม่สามารถอยู่กับ archetype แบบเดียวได้
- เนื่องจากองค์กรมีขนาดเล็ก จึงต้องทำกิจกรรมหลากหลายรวมถึงการลงมือทำเอง
- ไม่เพียงต้องออกแบบสถาปัตยกรรม นำโปรเจกต์ และทำงานเชิงยุทธวิธีเท่านั้น แต่ยังต้องคิดไอเดียปรับปรุงและลงมือทำเองด้วย
- ความยืดหยุ่นและความรับผิดชอบเชิงรุกคือคุณลักษณะที่จำเป็นสำหรับวิศวกร Staff+ ในสตาร์ทอัพ
- หนึ่งในบทบาทสำคัญของวิศวกร Staff+ คือ การให้คำปรึกษาและ sponsorship
- โดยเฉพาะอย่างยิ่งเป็นการสนับสนุนและชี้ทิศทางที่สำคัญสำหรับบุคลากรรุ่นจูเนียร์ในสตาร์ทอัพ
- Staff Engineer ช่วยเร่งการเติบโตของทีมและเสริมความแข็งแกร่งให้กับองค์กรผ่านการสนับสนุนเหล่านี้
[การประยุกต์ใช้ Modern Staff Engineering ในสตาร์ทอัพ]
เรื่องที่ 1 จาก 2 - "Improving DevEx by Removing a Merge Freeze"
สถานการณ์ปัญหา
- กระบวนการ QA เดิม:
- ก่อนรีลีส 2-3 วันจะใช้ "merge freeze" และให้ทีม QA ทำการทดสอบ regression แบบแมนนวล
- บั๊กที่พบจะถูกแก้ทันทีและ merge เข้า main branch
- นักพัฒนาสร้างแพตช์ใหม่ได้ แต่ต้องพักคำขอ merge ไว้จนกว่าจะรีลีสเสร็จ
- ข้อเสีย:
- การทดสอบ regression แบบแมนนวลช้าและคาดการณ์ได้ยาก
- การเลื่อน merge ทำให้เกิด merge conflict บ่อยขึ้น
- ประสิทธิภาพการทำงานและการร่วมมือของนักพัฒนาลดลง
แนวทางแก้ไข
- รวมโค้ดอินฟราไว้ใน Monorepo
- รวมโปรเจกต์ Terraform ไว้ในรีโพเดียวกับ application code
- เชื่อมต่อกับเครื่องมือ linting และ dependency management แบบอัตโนมัติ เพื่อให้นักพัฒนาจัดการอินฟราได้ง่ายขึ้น
- จัดการทุก environment ด้วย Terraform
- ไม่ใช่แค่ environment ใหม่ แต่รวมถึง staging และ production เดิมด้วย
- ใช้การกำหนดอินฟราเดียวกันและเปลี่ยนตัวแปรตาม environment เพื่อรักษาความสม่ำเสมอระหว่าง environment
- ทำให้กระบวนการ CI/CD เรียบง่ายขึ้น
- เทมเพลต GitLab Auto DevOps เดิมมีการปรับแต่งมากจนซับซ้อน
- เอา Auto DevOps ออก และกำหนดไฟล์
.gitlab-ci.yml ใหม่ให้ชัดเจน
- ย้ายคำสั่งส่วนใหญ่ไปไว้ใน Makefile เพื่อให้รันด้วยมือได้ด้วย
- ปรับปรุงการจัดการ Secrets
- ย้ายแอปพลิเคชันซีเคร็ตไปที่ Google Cloud Secrets Manager เพื่อลดการผูกกับ GitLab
- แก้สคริปต์ deploy ให้สามารถอัปเดต Kubernetes ConfigMap แบบอัตโนมัติ
- งานที่ไม่รวมอยู่ในขอบเขต
- แอปพลิเคชันรันบน Kubernetes ในโครงสร้าง monolith
- คงรูปแบบนี้ไว้ เพราะการเปลี่ยนแปลงอาจทำให้เกิดความล่าช้าและความเสี่ยง
- ไม่ได้สร้าง automation pipeline สำหรับ Terraform
- เนื่องจากมีการเปลี่ยนแปลงอินฟราไม่บ่อย จึงยังคงใช้กระบวนการแบบแมนนวล
- แนวทางเข้าถึงซีเคร็ตแบบ Kubernetes native ก็ยังถูกเลื่อนไว้ก่อน
ผลลัพธ์และความสำเร็จ
- สามารถ deploy test environment ใหม่ได้ และทีม QA ก็ทำ regression test ได้อย่างอิสระ
- การ ยกเลิก merge freeze ทำให้นักพัฒนาสามารถ merge การเปลี่ยนแปลงเข้า main branch ได้อย่างอิสระ
- กระบวนการรีลีสง่ายขึ้น และความเร็วของทั้งทีมดีขึ้น
หลักการที่นำมาใช้
- หลักการ Staff Engineering
- ร่วมงานกับหลายทีมและเป็นผู้นำโปรเจกต์
- ทำหน้าที่ "Tech Lead" และพาโปรเจกต์ไปจนเสร็จสมบูรณ์
- ปรับปรุง CI/CD และอินฟราเพื่อเพิ่มความเข้าใจและการเข้าถึงสำหรับทีม
- หลักการ Platform Engineering
- ขยายโปรเจกต์ DevOps ให้เป็นโปรเจกต์แพลตฟอร์ม
- จัดการอินฟราทั้งหมดด้วยโค้ดเพื่อให้เกิดความสม่ำเสมอระหว่าง environment
- ปรับขอบเขตโปรเจกต์ผ่าน trade-off ที่สอดคล้องกับความเป็นจริง
- หลักการ DevOps
- จัดการอินฟราด้วยโค้ด เพื่อให้การดูแล cloud infrastructure มีความสม่ำเสมอ
- ปรับปรุงกระบวนการรีลีสและเพิ่มความเร็วในการพัฒนาด้วยเครื่องมือใหม่
- นำรูปแบบเอกสาร RFC (Request For Comment) มาใช้เพื่อเสริมความมีส่วนร่วมในกระบวนการตัดสินใจ
บทสรุป
- ทีม QA สามารถรัน automated test ได้ใน environment ที่เสถียรกว่าเดิม
- นักพัฒนาสามารถพัฒนาอย่างต่อเนื่องได้โดยไม่ต้องมี merge freeze และการร่วมมือก็ดีขึ้น
- ประสิทธิภาพการทำงานขององค์กรดีขึ้นผ่าน tooling และ process ที่ดีกว่าเดิม
- ในอนาคตอยากเดินหน้าต่อด้วยงานอย่างการสร้าง preview environment หรือการทำ regression test ให้เป็นอัตโนมัติ
เรื่องที่ 2 จาก 2 - "Iterating Towards a Productive Engineering Process"
สถานการณ์ปัญหา
- กระบวนการเดิม:
- สมาชิกทุกคนทำงานบน บอร์ดเดียว และแชร์ความคืบหน้ากันทุกวัน
- หลายคนมักไม่ค่อยโฟกัสและอยู่ในสภาพ "เช็กเอาต์" เมื่อยังไม่ใช่คิวของตัวเอง
- ความรับผิดชอบต่อการพัฒนาฟีเจอร์กระจายตัว จนบ่อยครั้ง product manager ต้องรับผิดชอบสุดท้าย
- ขาดความเข้าใจที่ชัดเจนต่อ technical architecture
- เป้าหมาย:
- ทดลองหลายรูปแบบเพื่อสร้างการทำงานร่วมกันและกระบวนการพัฒนาซอฟต์แวร์ที่ดีขึ้น
- การทดลอง 1: ทีมฟีเจอร์ระยะสั้น (Short-lived Feature Teams)
- วัตถุประสงค์: ให้วิศวกรมีความรับผิดชอบต่อวงจรชีวิตทั้งหมดของการพัฒนาฟีเจอร์
- วิธีการ:
- กำหนดผู้นำสำหรับแต่ละฟีเจอร์ และจัดทีมที่ประกอบด้วย backend, frontend, QA เป็นต้น
- ผลลัพธ์:
- ความรับผิดชอบของสมาชิกทีมดีขึ้น แต่ไม่ใช่ทุกคนที่เหมาะกับหรือต้องการบทบาทผู้นำ
- หลังจากนั้นจึงเปลี่ยนไปใช้ "โมเดลทีมประจำ" สร้าง "Squads" และให้แต่ละทีมวางแผนและ retrospective กันเอง
- การทดลอง 2: Epic Kickoff Documents
- วัตถุประสงค์: ทำให้ requirement ชัดเจน และสร้างความเห็นพ้องของทีมต่อขอบเขตโปรเจกต์กับแนวทางดำเนินงาน
- วิธีการ:
- ผลลัพธ์:
- การสื่อสารในทีมดีขึ้น และเริ่มร่วมมือกันได้ดีขึ้นตั้งแต่ต้นโปรเจกต์
- สมาชิกทีมประเมินว่าการประชุมนี้เป็น เวลาที่มีคุณค่า
- การทดลอง 3: การรีวิวโค้ดแบบกลุ่ม (Group Code Review)
- วัตถุประสงค์: ลดเวลา code review กระตุ้นการพูดคุยเรื่องโค้ด และแบ่งปันความรู้ทางเทคนิคระหว่างวิศวกร
- วิธีการ:
- จัดเซสชัน code review ครั้งละ 1 ชั่วโมงใน Slack Huddle สัปดาห์ละ 2 ครั้ง
- นักพัฒนาแชร์หน้าจอและอธิบาย PR ขณะที่ผู้เข้าร่วมให้ฟีดแบ็ก
- ผลลัพธ์:
- เวลาที่ใช้กับ code review ลดลงอย่างมาก และรักษาสถานะ Inbox 0 ได้
- การพูดคุยเกี่ยวกับโค้ดช่วยสร้างวัฒนธรรมที่นักพัฒนาเรียนรู้และให้ความเคารพกัน
- นอกจาก code review แล้ว ทีมยังได้รู้จักข้อดีของ pair programming ด้วย
หลักการที่นำมาใช้
- หลักการ Staff Engineering
- เป็นผู้นำการปรับปรุง process ในช่วงที่ไม่มี engineering manager
- นำวัฒนธรรมการปรับปรุงอย่างต่อเนื่องเข้ามาในทีม และเสริมการร่วมมือแบบอิสระผ่าน agile process
- สนับสนุนให้ทีมทำลาย process ที่หยุดนิ่ง และมองหาวิธีที่ดีกว่า
- หลักการ Platform Engineering
- มองว่าไม่ใช่แค่เครื่องมือ แต่ process ก็เป็นส่วนหนึ่งของแพลตฟอร์ม
- process ที่ไม่มีประสิทธิภาพบั่นทอน productivity ของทีม ดังนั้นการปรับปรุงจึงสำคัญ
- การเปลี่ยนแปลง process เพื่อ กำจัดความสูญเปล่า อาจส่งผลได้มากพอ ๆ กับการปรับปรุงเครื่องมือ
- หลักการ DevOps
- หลักการ CALMS: Collaboration, Automation, Lean, Measurement, Sharing
- ใช้ process แบบ Lean เพื่อ กำจัดความสูญเปล่า และส่งมอบคุณค่าได้รวดเร็ว
- ให้ความรู้ทีมเพื่อให้ปรับปรุงอย่างต่อเนื่องผ่าน agile process
บทสรุป
- การปรับปรุง process ของทีมแบบเชิงทดลองช่วยเพิ่มทั้ง productivity และการร่วมมืออย่างมาก
- การปรับปรุงแบบ ต้นทุนต่ำ ประสิทธิภาพสูง ช่วยยกระดับประสบการณ์การพัฒนาของทั้งทีม
- ขอแนะนำอย่างยิ่งให้ทบทวน process ของตัวเองอย่างมีวิจารณญาณ และมองหาพื้นที่ที่ยังปรับปรุงได้
[ปิดท้าย]
- การทำงานในสภาพแวดล้อมของสตาร์ทอัพเปิดโอกาสให้ได้ใช้ทั้ง ความเชี่ยวชาญและความหลงใหล อย่างเต็มที่ในการแก้ปัญหาที่หลากหลายและทำให้โซลูชันเกิดขึ้นจริง
- เนื่องจากมีข้อจำกัดด้านเวลา จึงเป็นโอกาสที่ดีในการฝึกฝน แนวทางเชิงปฏิบัตินิยม และสามารถสร้าง อิทธิพล ได้อย่างมากในช่วงเริ่มต้นของบริษัท
- สามารถนำแนวทางวิศวกรรมซอฟต์แวร์สมัยใหม่มาใช้เพื่อวางรากฐานสู่ความสำเร็จของบริษัท
-
Staff Engineering และสตาร์ทอัพ
- Staff Engineer ต้องอาศัยประสบการณ์ที่มีทั้ง ความกว้างและความลึก
- สตาร์ทอัพเปิดโอกาสให้วิศวกรระดับ Staff+ ขยายความรู้ทางเทคนิค และสำรวจขอบเขตใหม่ ๆ
- ตัวอย่าง: วิศวกรแบ็กเอนด์สามารถเรียนรู้เทคโนโลยีอย่าง React หรือ BigQuery ได้
-
Platform Engineering และสตาร์ทอัพ
- Platform Engineering ในสตาร์ทอัพจะแตกต่างกันไปตามขนาดขององค์กร
- สามารถระบุ pain point ของนักพัฒนาได้ผ่าน การสื่อสารแบบ 1:1 และปรับปรุงประสบการณ์นักพัฒนา (DevEx) ได้ด้วย โปรเจ็กต์ขนาดเล็ก
- ควรสร้าง วงจรฟีดแบ็กที่รวดเร็ว เพื่อปรับปรุงกระบวนการพัฒนา และช่วยให้นักพัฒนาสามารถแก้ปัญหาได้ด้วยตนเองในอนาคต
- การทำให้ครอบคลุมพื้นฐานของ วงจรชีวิตการพัฒนาซอฟต์แวร์ (SDLC) ด้วยเครื่องมือและเทคนิคมาตรฐานอุตสาหกรรมเป็นสิ่งสำคัญ
- ในสตาร์ทอัพ Platform Engineering ไม่ใช่งานเฉพาะทางประจำ แต่เป็นแนวทางเชิงเทคนิคที่นำมาใช้ตามความจำเป็น
- ควรจำไว้ว่า "ประสบการณ์นักพัฒนาภายในองค์กรคือผลิตภัณฑ์อย่างหนึ่ง" และควรใช้เวลาไปกับการออกแบบสิ่งนี้
-
DevOps และสตาร์ทอัพ
- DevOps มีบทบาทสำคัญมากในสตาร์ทอัพเช่นกัน
- หัวใจสำคัญคือการส่งมอบคุณค่าให้ลูกค้าได้เร็วขึ้น และสร้างสภาพแวดล้อมการทำงานที่ดีขึ้น ผ่าน วัฒนธรรม กระบวนการ และเครื่องมือ
- การเพิ่มประสิทธิภาพของบริษัทและสร้างรากฐานของ วัฒนธรรมการทำงานร่วมกัน ผ่าน DevOps เป็นงานที่ให้ความรู้สึกคุ้มค่าอย่างมาก
- ในสตาร์ทอัพ วิศวกรที่มีความหลงใหลใน DevOps สามารถสร้างคุณูปการครั้งใหญ่ได้ผ่านทักษะและประสบการณ์ของตนเอง
- สภาพแวดล้อมของสตาร์ทอัพเต็มไปด้วยความท้าทายใหม่ ๆ และโอกาสในการเรียนรู้ ซึ่งช่วยให้วิศวกรเติบโตยิ่งขึ้นและสร้างผลงานที่มีความหมายได้
3 ความคิดเห็น
บทสดุดีแด่ DevOps
Platform Engineer ที่ทำเงินได้มากกว่า DevOps Engineer
Staff Engineer คืออะไร?
ดูเหมือนว่าจะนิยามบทบาทงานวิศวกรรมที่จำเป็นสำหรับสตาร์ทอัพต่อจากนี้ได้ไว้ดีมากครับ คิดว่าเป็นการจัดระเบียบงานวิศวกรรมที่ก่อนหน้านี้ทำกันโดยไม่ได้แบ่งแยกชัดเจนได้อย่างดีเลย ทำให้ตัวเราเองก็น่าจะเข้าใจได้อย่างเป็นรูปธรรมมากขึ้นว่ารับผิดชอบงานวิศวกรรมด้านไหนเป็นหลัก และอยากพัฒนาตัวเองให้เก่งด้านใดต่อไป อีกทั้งสตาร์ทอัพเองก็น่าจะสร้างระบบงานวิศวกรรมที่เป็นระบบมากขึ้น และคัดเลือกวิศวกรที่จำเป็นได้ดีขึ้นด้วยครับ