แอปรับคำขอโปรเจกต์และคำขอสตาฟฟิง: โฟลว์เรียบง่าย

ปัญหาที่แอปควรแก้

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

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

ตัวอย่างง่ายๆ แสดงปัญหา หัวหน้าฝ่ายขายขอคนสองคนสำหรับโครงการพอร์ทัลลูกค้า ข้อความหนึ่งระบุงาน frontend อีกข้อความบอกการเปลี่ยนแปลง API และแถวในสเปรดชีตระบุแค่ "ด่วน" เมื่อผู้จัดการทรัพยากรทบทวน ยังไม่แน่ใจว่าต้องการนักพัฒนา full-stack หนึ่งคน นักพัฒนาผู้เชี่ยวชาญสองคน หรือช่วยชั่วคราวแบบสัญญาจ้าง

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

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

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

ควรเก็บอะไรในฟอร์มคำขอ

ฟอร์มคำขอที่ดีควรตอบคำถามสามข้อทันที: งานอะไรต้องทำ เมื่อไหร่ต้องทำ และต้องการคนแบบไหน

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

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

ระบุความต้องการสตาฟฟิงให้ชัดเจน แทนที่จะให้กล่องข้อความใหญ่หนึ่งกล่อง ให้ถามว่าต้องการบทบาทใดบ้างและต้องการจำนวนคนเท่าไรต่อบทบาท คำขอ 1 นักพัฒนาฝั่งหลัง 1 QA 1 ดีไซเนอร์ ชัดเจน แต่คำขอ "ทีมเล็กๆ" ไม่ชัดเจน

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

สำหรับทีมส่วนใหญ่ ฟอร์มควรครอบคลุมเรื่องเหล่านี้:

• ทักษะหลักที่ต้องใช้สำหรับงาน
• เครื่องมือหรือแพลตฟอร์มที่ต้องรู้
• ระดับประสบการณ์ขั้นต่ำสำหรับแต่ละบทบาท
• ใบรับรองหรือความรู้เฉพาะด้านถ้าจำเป็น
• ข้อกำหนดที่ไม่สามารถต่อรองได้

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

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

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

การเคลื่อนย้ายคำขอผ่านกระบวนการรับ

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

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

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

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

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

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

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

ใน AppMaster โฟลว์แบบนี้มักแมปได้ดีเป็นกระบวนการธุรกิจแบบภาพที่มีการส่งต่อโดยกฎและการอัปเดตสถานะอัตโนมัติจากการส่งจนถึงการมอบหมาย

ตั้งค่ากระบวนการทีละขั้น

วิธีที่ง่ายที่สุดในการสร้างแอปคือตั้งเส้นทางก่อน แล้วค่อยมาสร้างแบบฟอร์ม สิทธิ์ และการแจ้งเตือนรอบๆ เส้นทางนั้น

เริ่มจากสถานะ เก็บให้สั้นและเข้าใจง่าย: Draft, Submitted, Under Review, Approved, Staffing in Progress, Assigned และ Closed หากคำขอต้องกลับมาแก้ไข ให้เพิ่มสถานะเดียวเช่น Changes Needed แทนการสร้างเส้นทางย่อยมากเกินไป

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

สิทธิ์ควรชัดเจน ผู้ขอต้องสร้างคำขอและดูสถานะของตนเองได้ ผู้ตรวจสอบต้องคอมเมนต์และส่งคืนรายการเพื่อให้แก้ไข ผู้อนุมัติต้องอนุมัติหรือปฏิเสธ หัวหน้าสตาฟฟิงต้องมอบหมายและยืนยันการจัดสรร ผู้ดูแลระบบต้องจัดการบทบาท กฎ และการแจ้งเตือน

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

เป้าหมายหลักคือเรียบง่าย: ทุกคำขอควรมีเจ้าของหนึ่งคน สถานะปัจจุบันหนึ่งค่า และก้าวถัดไปที่ชัดเจนเสมอ

เก็บทักษะและจับคู่คนที่เหมาะสม

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

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

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

ระเบียนการจับคู่ง่ายๆ ควรมีฟิลด์เหล่านี้:

• ทักษะที่ต้องมี
• ทักษะที่อยากได้
• ความพร้อมที่ต้องการ
• ตำแหน่งหรือโซนเวลาที่ต้องการ
• วันที่เริ่มและภาระงานที่คาดหวัง

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

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

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

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

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

ตัวอย่าง: จากคำขอถึงการมอบหมาย

ตัวอย่างจริงช่วยให้เห็นภาพโครงการได้ชัดขึ้น

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

คำขอยังระบุทักษะสำหรับแต่ละบทบาทด้วย บทบาท backend ต้องทำงาน API และฐานข้อมูล ดีไซเนอร์ต้องมีประสบการณ์กับแดชบอร์ดสำหรับลูกค้า ผู้ทดสอบต้องเขียนกรณีทดสอบและทำการทดสอบ regression ได้ดี นั่นทำให้คำขอมีประโยชน์กว่าแค่บันทึกจำนวนหัวงานมาก

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

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

ผู้สมัคร backend คนหนึ่งอาจว่างวันจันทร์หน้าแต่ทำงานพาร์ทไทม์ อีกคนอาจเริ่มช้ากว่าแต่มีประสบการณ์ฐานข้อมูลแข็งแกร่ง ดีไซเนอร์อาจเหมาะมากแต่ไม่ว่างสัปดาห์แรก ผู้จัดการอาจบันทึกช่องว่างชั่วคราวหรือปรับแผนตามนั้น

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

ข้อผิดพลาดที่พบบ่อยและควรหลีกเลี่ยง

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

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

ทักษะแบบข้อความอิสระเป็นปัญหาพบบ่อยอีกเรื่อง ผู้จัดการคนหนึ่งเขียน "React" อีกคนเขียน "frontend" อีกคนเขียน "JS UI work" ต่อมาการค้นหาและการจับคู่กลายเป็นความยุ่งเหยิง เรื่องเดียวกันเกิดขึ้นเมื่อการตัดสินใจมอบหมายอยู่แค่ในแชท ใครบางคนพูดว่า "ให้ Sam" แต่แอปไม่เคยบันทึกว่าใครตัดสินใจ เมื่อไหร่ และทำไม

ชื่อตำแหน่งสถานะก็สำคัญกว่าที่คิด หาก "In Review" หมายถึงการตรวจงบประมาณสำหรับทีมหนึ่งและหมายถึงการอนุมัติขั้นสุดท้ายสำหรับอีกทีม ความสับสนย่อมเกิดขึ้น

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

การแก้ไขมักเรียบง่าย เก็บฟิลด์ที่จำเป็นให้เข้มงวด ใช้รายการทักษะมาตรฐาน กำหนดเจ้าของในแต่ละจุดตัดสินใจ และบันทึกการอนุมัติและการมอบหมายทั้งหมดในแอป

โครงสร้างสำคัญที่สุด ฟิลด์ที่ชัดเจน สถานะที่กำหนดแน่น และการบันทึกการตัดสินใจทำให้กระบวนการน่าเชื่อถือและจัดการได้ง่ายขึ้น

เช็คลิสต์ก่อนเปิดใช้งาน

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

การตรวจสอบสุดท้ายที่ดีคือเรียบง่าย: คำขอสามารถย้ายจากการส่งไปสู่การมอบหมายโดยไม่ต้องมีข้อความข้างเคียง สเปรดชีตเพิ่มเติม หรือการตามงานด้วยมือหรือไม่

ยืนยันพื้นฐานเหล่านี้ก่อนใช้งานจริง:

• แต่ละคำขอมีเจ้าของที่ชัดเจนหนึ่งคน

• เวลามองเห็นได้และไม่คลุมเครือ

• ทักษะใช้รูปแบบมาตรฐาน

• เส้นทางการอนุมัติเข้าใจง่าย

• การตัดสินใจมอบหมายมีบันทึกชัดเจน

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

บรรทัดสถานะสั้นๆ มักทำงานได้ดีที่สุด: Submitted, Under Review, Approved, Matching in Progress, Assigned หรือ Closed หากคำขอถูกบล็อก เหตุผลควรมองเห็นได้ด้วย

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

ขั้นตอนต่อไปสำหรับการสร้างแอป

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

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

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

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

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

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

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

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

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