เราเริ่มเผยแพร่คุณสมบัติเร็วขึ้นเป็นสองเท่าได้อย่างไร (กรณีศึกษา)

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

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

อ่านเพิ่มเติม เกี่ยวกับ SmashingMag:

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

ดังนั้น กระบวนการพัฒนาจึงต้องดำเนินไปอย่างราบรื่นและได้มาตรฐาน โดยลดความล่าช้าให้เหลือน้อยที่สุด ก่อนที่การเปลี่ยนแปลงใดๆ จะมาถึงผู้ใช้ขั้นปลาย จะต้องผ่านห้าขั้นตอนที่สำคัญ ได้แก่ ข้อเสนอแนะ การออกแบบ การพัฒนา การประกันคุณภาพ และการใช้งาน ในบทความนี้ ฉันจะแบ่งปันสิ่งที่เราได้เรียนรู้ (อย่างยากลำบาก) เกี่ยวกับแต่ละขั้นตอนจากกว่าแปดปีในธุรกิจ

การโทรปลุก

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

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

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

มาดูรายละเอียดของถนนที่ฟีเจอร์หนึ่งต้องเดินทางก่อนที่จะเสนอให้ผู้ใช้ปลายทาง

จากข้อเสนอแนะสู่คุณลักษณะ

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

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

ตามความคิดเห็น ทีมของเราอัปเดตแบบฟอร์มที่มีลักษณะดังนี้:

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

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

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

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

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

การออกแบบเพื่อผู้ใช้

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

เราเก็บสิ่งต่าง ๆ ในมุมมองโดยถามว่าผู้ใช้คาดหวังตัวเลือกนี้ไว้ที่ใด

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

ใช้แป้นพิมพ์ลัด คุณสามารถสร้างชุดทางลัดของคุณเองและคาดหวังให้ผู้ใช้เรียนรู้ (ซึ่งอาจจะไม่เป็นเช่นนั้น) หรือคุณสามารถเพิ่มสิ่งที่คนใช้อยู่แล้ว ผู้ใช้ของเราจำนวนมากใช้ Slack อยู่แล้ว ตัวอย่างเช่น เราจึงเพิ่มทางลัดที่พวกเขาคุ้นเคยอยู่แล้ว ( Command + K สำหรับการข้ามอย่างรวดเร็วทำงานใน Active Collab ด้วย)

เมื่อกระแสของผู้ใช้พร้อมแล้ว นักออกแบบ UX ของเราจะเลียนแบบการออกแบบใน Sketch เราไม่ค่อยใช้ HTML ในระยะแรก การแสดงภาพ Sketch ที่รอบคอบทำให้เรามีความยืดหยุ่นเพียงพอโดยที่เราไม่ต้องย้อนรอยเมื่อเราเริ่มเขียนโค้ด การออกแบบเริ่มต้นมักจะจบลงด้วยการจับคู่ประมาณ 80% ของผลิตภัณฑ์ขั้นสุดท้าย ส่วนที่เหลือจะถูกเพิ่มและปรับเปลี่ยนไปพร้อมกัน

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

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

ถึงเวลาที่จะเริ่มต้นสิ่งต่าง ๆ

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

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

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

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

หลังการประชุม ทีมงานจะมีข้อมูลที่จำเป็นทั้งหมด:

1. อะไร? นี่คือ ขอบเขตของฟีเจอร์ และรวมทุกอย่างที่จำเป็นต้องทำ เช่นเดียวกับตัวบล็อกและคอขวดที่อาจเกิดขึ้น เราพยายามคาดการณ์สถานการณ์และกรณีขอบให้มากที่สุด การทำนายทั้งหมดไม่ใช่เรื่องง่าย พวกเขามักจะขึ้นมาเมื่อเราไป
2. ทำไม? เจ้าของผลิตภัณฑ์ประเมิน มูลค่าธุรกิจ ของคุณลักษณะหนึ่งๆ และอธิบายว่าทำไมจึงคุ้มค่ากับความพยายาม ด้วยวิธีนี้ ทีมงานจะได้ภาพที่ชัดเจนเกี่ยวกับประโยชน์ต่อลูกค้าและผลิตภัณฑ์ แรงจูงใจหลักในที่นี้คือ ทุกคนควรเข้าใจว่าเหตุใดงานของพวกเขาจึงมีความสำคัญ และงานนี้มีส่วนสำคัญต่อบริษัทโดยรวมอย่างไร
3. ยังไง? โดยการสรุป ขั้นตอนที่จำเป็นในการทำให้คุณลักษณะสมบูรณ์ เรามั่นใจว่านักพัฒนาของเราจะไม่ทำเข็มทิศหาย นอกจากนี้เรายังตั้งความคาดหวังที่เป็นจริงด้วยการเพิ่มแท็กความซับซ้อน เราเลือกขนาดเสื้อยืด — S สามารถแก้ไขได้ภายในไม่กี่ชั่วโมง ในขณะที่ XXL ใช้เวลาหลายสัปดาห์หรือมากกว่านั้นจึงจะเสร็จสมบูรณ์
4. ใคร? หัวหน้าทีมมีหน้าที่รับผิดชอบ ในการดำเนินการคุณสมบัติหรืองานให้เสร็จตรงเวลาและอัปเดตความคืบหน้าของเจ้าของผลิตภัณฑ์ สมาชิกในทีมคนอื่นๆ ได้รับมอบหมายให้ทำงานย่อยของตัวเอง เพื่อให้ชัดเจนว่าใครรับผิดชอบอะไร การรักษาสิ่งนี้ให้โปร่งใสที่สุดเท่าที่จะเป็นไปได้ช่วยให้เราเห็นว่ามีคนกำลังดิ้นรนหรือทำให้เกิดความล่าช้า
5. เมื่อไร? เมื่อพิจารณาทุกอย่างแล้ว วันที่ครบกำหนดจะถูกประมาณการ ไว้ หากงานล่าช้า เราจะวิเคราะห์เหตุผลและใช้ประสบการณ์นั้นในครั้งต่อไป ด้วยวิธีนี้ เส้นตายที่พลาดไปจะกลายเป็นโอกาสในการเรียนรู้และไม่ใช่แหล่งของความเครียด

วันเปิดตัวอาจดูวุ่นวาย แต่ก็มีผลมากเช่นกัน ทุกคนเสนอไอเดียและความคิดเห็น งานเปลี่ยนจากกระดานชนวนที่ว่างเปล่าเป็นฮับสำหรับความคิดเห็น การแก้ไข และการอัปเดต ในตอนท้ายของวัน ทีมพัฒนามีภาพที่ชัดเจนของงานในอนาคตและจุดเริ่มต้นที่มั่นคง

เราผ่านรายการตรวจสอบนี้ก่อนเริ่มงาน:

• คุณสมบัติอธิบาย
• ขั้นตอนสำหรับการเสร็จสิ้นที่ระบุไว้
• มูลค่าธุรกิจที่กำหนดโดยเจ้าของผลิตภัณฑ์
• ความซับซ้อนที่ได้รับมอบหมายจากทีม
• ระบุคุณสมบัติและการอ้างอิงจุดบกพร่อง
• เกณฑ์ประสิทธิภาพที่ระบุ (ถ้าจำเป็น)
• กำหนดการสาธิต
• วันที่เริ่มต้นและสิ้นสุดที่กำหนดโดยหัวหน้าทีม

นี่คือช่วงเวลาที่งานย้ายไปที่คอลัมน์ "กำลังดำเนินการ"

ถึงเวลาเข้ารหัสแล้ว!

การทำงานเป็นทีมบนจอแสดงผล

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

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

แสดงและบอก

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

ประชุมประจำสัปดาห์

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

นำไปทดสอบ

เขียนโค้ดแล้ว การสาธิตประสบความสำเร็จ ทุกอย่างดูเหมือนจะจบลงด้วยดี... จนกว่าคุณจะปล่อยฟีเจอร์นี้และเห็นว่าแอปขัดข้อง นั่นคือเหตุผลที่ ทุกฟีเจอร์ที่เราทำจะต้องผ่านการประกันคุณภาพ (Q/A) เสมอ. ผู้ทดสอบของเราดำเนินการอย่างพิถีพิถันในทุกสถานการณ์ที่เป็นไปได้ ตรวจสอบตัวเลือกทั้งหมดและเรียกใช้การทดสอบในสภาพแวดล้อมที่แตกต่างกัน คุณลักษณะไม่ค่อยผ่านการถามตอบในครั้งแรก

ในการเพิ่มประสิทธิภาพการทำงาน เราเคยให้นักพัฒนาเริ่มใช้งานคุณลักษณะใหม่ ๆ ในระหว่างระยะนี้ แต่นั่นก็ส่งผลให้มีคุณลักษณะที่ล่าช้าและเสร็จสิ้นไปเพียงครึ่งเดียวจำนวนมาก ดังนั้น ตอนนี้ทีมพัฒนายังคงยุ่งอยู่กับงานบำรุงรักษาเล็กน้อยในขณะที่กำลังตรวจสอบคุณลักษณะ หาก Q/A พบปัญหา นักพัฒนาจะแก้ไขและส่งใหม่ทันที กระบวนการนี้จะทำซ้ำจนกว่าคุณลักษณะจะผ่าน Q/A และไปยังการตรวจทานโค้ด

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

นี่คือคำจำกัดความของคำว่า "เสร็จสิ้น" ของเรา:

• การทดสอบอัตโนมัติเขียน
• ถาม/ตอบเสร็จสิ้นและงานที่ได้รับทั้งหมดเสร็จสิ้น
• ตรวจทานโค้ดเสร็จแล้วและรวมโค้ดเป็นมาสเตอร์แล้ว
• อัปเดตบันทึกประจำรุ่น
• ระบุคุณสมบัติและการอ้างอิงจุดบกพร่อง

งานมาถึงขั้นตอนสุดท้ายแล้ว เรียกว่า “ปล่อย Q”

วันวางจำหน่าย

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

• เรามีวันจันทร์เพื่อตรวจสอบการเปิดตัวและเพิ่มรายละเอียดขั้นสุดท้ายก่อนที่จะปรับใช้
• หากมีวลีที่ไม่ได้แปล (แอปพลิเคชันเว็บของเราให้บริการในเจ็ดภาษา) เราก็มีเวลาเพียงพอในการแปลให้เสร็จ
• ทีมการตลาดมีเวลามากมายในการส่งจดหมายข่าวและประกาศผ่านโซเชียลมีเดีย
• เราพร้อมให้การสนับสนุนการอัปเกรดอย่างรวดเร็วและมีประสิทธิภาพตลอดทั้งสัปดาห์ที่เหลือ
• หากกำหนดเส้นตายผ่านไปด้วยเหตุใดก็ตาม เรายังมีวันพุธหรือพฤหัสบดีที่จะดำเนินการให้เสร็จ

วันกิจกรรมฟรี

วันหลังจากการเปิดตัวครั้งใหญ่เป็นวันที่ว่างสำหรับทีม นี่คือเวลาที่พวกเขาเรียนรู้ทักษะใหม่หรือทำอะไรก็ตามที่เกี่ยวข้องกับงานที่พวกเขาสนใจ แม้ว่าทุกคนจะอยากรู้ว่าเราจะเปิดตัวฟีเจอร์ใดในวันรุ่งขึ้น แต่ทีมยังไม่ได้พูดถึงเรื่องนั้น แต่พวกเขาจะผ่อนคลายและอาจดูการนำเสนอเกี่ยวกับประวัติของ Erlang หรืออ่านบทความนั้นเกี่ยวกับสาเหตุที่ PSR-7 และมิดเดิลแวร์มีความสำคัญต่อการพัฒนา PHP สมัยใหม่ หรือมีการอภิปรายย้อนหลังของตนเอง เป็นวันที่สมควรอย่างยิ่งที่จะชาร์จแบตเตอรีและฉลองให้กับงานที่ทำได้ดี

วันล่าแมลง

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

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

ผลลัพธ์คืออะไร?

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

ดังนั้น หากเรามีข้อเสนอให้คุณ นั่นคือ: การปลูกฝังวัฒนธรรมองค์กรที่ขจัดความกลัวต่อการเปลี่ยนแปลงจะทำให้ทีมของคุณดีขึ้นในสิ่งที่ทำ ไม่ว่าคุณจะเรียกว่า Scrum, Kanban หรือ Lean ไม่สำคัญ ตราบใดที่มันช่วยให้บริษัทของคุณเติบโต การทดลองและนวัตกรรมเป็นหัวใจสำคัญของแนวทางที่คล่องตัว อย่ากลัวที่จะทดสอบวิธีแก้ปัญหาต่างๆ วัดผล และปรับเปลี่ยนแนวทางปฏิบัติที่มีอยู่ตามผลลัพธ์ ผลลัพธ์ที่ดีจะตามมา