Hi!
ฉันชื่อ Alexander และเป็นผู้นำการพัฒนาด้านไอทีที่ UBRD!
ในปี 2017 เราซึ่งเป็นศูนย์กลางการพัฒนาบริการเทคโนโลยีสารสนเทศที่ UBRD ตระหนักดีว่าถึงเวลาแล้วสำหรับการเปลี่ยนแปลงระดับโลก หรือการเปลี่ยนแปลงที่คล่องตัว ในสภาวะของการพัฒนาธุรกิจอย่างเข้มข้นและการเติบโตอย่างรวดเร็วของการแข่งขันในตลาดการเงิน สองปีถือเป็นช่วงเวลาที่น่าประทับใจ ถึงเวลาสรุปโครงการแล้ว
สิ่งที่ยากที่สุดคือการเปลี่ยนความคิดและค่อยๆ เปลี่ยนวัฒนธรรมในองค์กรซึ่งเป็นเรื่องปกติที่จะคิดว่า “ใครจะเป็นหัวหน้าในทีมนี้” “เจ้านายรู้ดีกว่าว่าเราจะต้องทำอะไร” “ เราทำงานที่นี่มา 10 ปีแล้วและรู้จักลูกค้าของเราดีขึ้น” เรารู้ว่าพวกเขาต้องการอะไร"
การเปลี่ยนแปลงแบบ Agile สามารถเกิดขึ้นได้ก็ต่อเมื่อผู้คนเปลี่ยนแปลงเท่านั้น
ฉันจะเน้นย้ำถึงความกลัวหลักๆ ต่อไปนี้ที่ทำให้ผู้คนไม่สามารถเปลี่ยนแปลงได้:
- กลัวการสูญเสียอำนาจและ "อินทรธนู";
- กลัวว่าจะไม่จำเป็นสำหรับบริษัท
เมื่อเริ่มต้นเส้นทางแห่งการเปลี่ยนแปลง เราได้เลือก "กระต่ายที่มีประสบการณ์" ตัวแรก - พนักงานของแผนกค้าปลีก ขั้นตอนแรกคือการออกแบบโครงสร้างไอทีที่ไม่มีประสิทธิภาพใหม่ หลังจากที่ได้แนวคิดเป้าหมายสำหรับโครงสร้างแล้ว เราก็เริ่มก่อตั้งทีมพัฒนา
สถาปัตยกรรมในธนาคารของเราก็เหมือนกับสถาปัตยกรรมอื่นๆ ที่เป็น "ขยะ" หากพูดง่ายๆ แอปพลิเคชันและส่วนประกอบจำนวนมากเชื่อมต่อกันแบบเสาหินด้วยลิงก์ DB มีบัส ESB แต่ไม่บรรลุวัตถุประสงค์ที่ตั้งใจไว้ นอกจากนี้ยังมี ABS บ้าง
ก่อนที่จะก่อตั้งทีม Scrum คำถามเกิดขึ้น: “ทีมควรรวมตัวกันด้วยอะไร?” แนวคิดที่ว่ามีผลิตภัณฑ์อยู่ในกระป๋องนั้นแน่นอนว่าลอยอยู่ในอากาศ แต่อยู่ไกลเกินเอื้อม หลังจากครุ่นคิดอยู่นาน เราก็ตัดสินใจว่าควรรวบรวมทีมตามทิศทางหรือส่วนใดส่วนหนึ่ง ตัวอย่างเช่น “Team Credits” ซึ่งพัฒนาสินเชื่อ เมื่อตัดสินใจเรื่องนี้แล้ว เราก็เริ่มคิดองค์ประกอบเป้าหมายของบทบาทและชุดความสามารถที่จำเป็นสำหรับการพัฒนาที่มีประสิทธิภาพของพื้นที่นี้ เช่นเดียวกับบริษัทอื่นๆ หลายแห่ง เราคำนึงถึงบทบาททั้งหมด ยกเว้น Scrum Master - ในเวลานั้นแทบจะเป็นไปไม่ได้เลยที่จะอธิบายให้ CIO ฟังว่าบทบาทของบุคคลที่ยอดเยี่ยมคนนี้คืออะไร
ด้วยเหตุนี้ หลังจากอธิบายความจำเป็นในการเปิดตัวทีมพัฒนาแล้ว เราก็ได้เปิดตัวสามทีม:
- เงินกู้
- บัตร
- การดำเนินงานแบบพาสซีฟ
ด้วยชุดบทบาท:
- ผู้จัดการฝ่ายพัฒนา (หัวหน้าฝ่ายเทคนิค)
- ผู้พัฒนา
- อนาลิติค
- ผู้ทดสอบ
ขั้นตอนต่อไปคือการพิจารณาว่าทีมจะทำงานอย่างไร เราทำการฝึกอบรมแบบ Agile สำหรับสมาชิกในทีมทุกคน และให้ทุกคนอยู่ในห้องเดียวกัน ไม่มี PO ในทีม ทุกคนที่ได้ทำการเปลี่ยนแปลงแบบ Agile เข้าใจว่าการอธิบายบทบาทของ PO ให้กับธุรกิจเป็นเรื่องยากเพียงใด และยิ่งยากกว่านั้นในการนั่งเขาข้างทีมและให้อำนาจแก่เขา แต่เรา "ก้าว" เข้าสู่การเปลี่ยนแปลงเหล่านี้ด้วยสิ่งที่เรามี
เนื่องจากมีแอปพลิเคชันจำนวนมากที่เกี่ยวข้องกับกระบวนการให้กู้ยืมและธุรกิจค้าปลีกที่เหลือ เราจึงเริ่มคิดว่าใครเหมาะสมสำหรับบทบาทนี้ นักพัฒนาของ Technology Stack หนึ่ง แล้วคุณก็มองหา - และคุณต้องการนักพัฒนาของ Technology Stack อื่น! และตอนนี้คุณได้พบคนที่ต้องการแล้ว แต่ความปรารถนาของพนักงานก็เป็นสิ่งสำคัญเช่นกันและเป็นการยากที่จะบังคับให้คนทำงานในที่ที่เขาไม่ชอบ
หลังจากวิเคราะห์กระบวนการทางธุรกิจการให้กู้ยืมและพูดคุยกับเพื่อนร่วมงานเป็นเวลานาน ในที่สุดเราก็พบจุดกึ่งกลาง! นี่คือลักษณะที่ปรากฏของทีมพัฒนาทั้งสามทีม
ทำอะไรต่อไป
ผู้คนเริ่มแบ่งออกเป็นกลุ่มที่ต้องการเปลี่ยนแปลงและกลุ่มที่ไม่เปลี่ยนแปลง ทุกคนคุ้นเคยกับการทำงานภายใต้เงื่อนไข “พวกเขาสร้างปัญหาให้ฉัน ฉันทำแล้ว ปล่อยฉันไว้คนเดียว” แต่การทำงานเป็นทีมไม่ได้หมายความถึงสิ่งนี้ แต่เราก็แก้ไขปัญหานี้ด้วย โดยรวมแล้ว 8 ใน 150 คนลาออกระหว่างการเปลี่ยนแปลง!
จากนั้นความสนุกก็เริ่มขึ้น ทีมงานข้ามองค์ประกอบของเราเริ่มพัฒนาตนเอง ตัวอย่างเช่น มีงานที่คุณต้องมีทักษะในด้านนักพัฒนา CRM เขาอยู่ในทีม แต่เขาอยู่คนเดียว นอกจากนี้ยังมีนักพัฒนา Oracle จะทำอย่างไรถ้าคุณต้องการแก้ปัญหา 2 หรือ 3 งานใน CRM? สอนกัน! พวกเขาเริ่มถ่ายทอดความสามารถให้กันและกันและทีมก็ขยายขีดความสามารถโดยลดการพึ่งพาผู้เชี่ยวชาญที่แข็งแกร่งเพียงคนเดียว (อย่างไรก็ตามใน บริษัท ใดก็ตามที่มีซูเปอร์แมนที่รู้ทุกอย่างและไม่บอกใครเลย)
วันนี้เราได้รวบรวมทีมพัฒนา 13 ทีมสำหรับการพัฒนาธุรกิจและบริการทุกด้าน เราดำเนินการเปลี่ยนแปลงอย่างคล่องตัวและก้าวไปสู่ระดับใหม่ สิ่งนี้จะต้องมีการเปลี่ยนแปลงใหม่ เราจะออกแบบทีมและสถาปัตยกรรมใหม่ และพัฒนาความสามารถ
เป้าหมายสุดท้ายของเรา: ตอบสนองต่อการเปลี่ยนแปลงผลิตภัณฑ์อย่างรวดเร็ว นำคุณสมบัติใหม่ออกสู่ตลาดอย่างรวดเร็ว และปรับปรุงบริการของธนาคาร!
ที่มา: will.com