สวัสดีเพื่อน. บ่อยครั้ง โดยเฉพาะในงานเอาท์ซอร์ส ฉันเห็นภาพเดียวกัน ขาดขั้นตอนการทำงานที่ชัดเจนในทีมในโครงการต่างๆ
สิ่งที่สำคัญที่สุดคือโปรแกรมเมอร์ไม่เข้าใจวิธีการสื่อสารกับลูกค้าและระหว่างกัน จะสร้างกระบวนการพัฒนาผลิตภัณฑ์ที่มีคุณภาพอย่างต่อเนื่องได้อย่างไร วิธีวางแผนวันทำงานและการวิ่งของคุณ
และทั้งหมดนี้ส่งผลให้เกิดการพลาดกำหนดเวลา การล่วงเวลา การประลองอย่างต่อเนื่องว่าใครจะตำหนิ และความไม่พอใจของลูกค้ากับสถานที่และวิธีที่ทุกอย่างดำเนินไป บ่อยครั้งทั้งหมดนี้นำไปสู่การเปลี่ยนแปลงโปรแกรมเมอร์หรือแม้แต่ทั้งทีม การสูญเสียลูกค้า ชื่อเสียงเสื่อมโทรม และอื่นๆ
ครั้งหนึ่งฉันเพิ่งทำโปรเจ็กต์นี้ซึ่งมีเรื่องน่ายินดีมากมาย
ไม่มีใครอยากรับผิดชอบโครงการนี้ (ตลาดบริการขนาดใหญ่) มูลค่าการซื้อขายแย่มาก ลูกค้าถูกฉีกขาดและหงุดหงิด ครั้งหนึ่ง CEO เข้ามาหาฉันและบอกว่าคุณมีประสบการณ์ที่จำเป็น ดังนั้นนี่คือไพ่ในมือของคุณ ดำเนินโครงการเพื่อตัวคุณเอง หากคุณทำพลาด เราจะปิดโครงการและไล่ทุกคนออก มันจะได้ผล มันจะเจ๋ง แล้วค่อยนำไปพัฒนาตามที่เห็นสมควร เป็นผลให้ฉันกลายเป็นหัวหน้าทีมสำหรับโปรเจ็กต์นี้และทุกอย่างก็ตกอยู่บนบ่าของฉัน
สิ่งแรกที่ฉันทำคือพัฒนาขั้นตอนการทำงานตั้งแต่เริ่มต้นซึ่งสอดคล้องกับวิสัยทัศน์ของฉันในขณะนั้น และเขียนรายละเอียดงานให้กับทีม การนำไปปฏิบัติไม่ใช่เรื่องง่าย แต่ภายในหนึ่งเดือนหรือประมาณนั้น ทุกอย่างก็คลี่คลาย นักพัฒนาและลูกค้าก็คุ้นเคยกับมัน และทุกอย่างก็ดำเนินไปอย่างเงียบ ๆ และสะดวกสบาย เพื่อแสดงให้ทีมเห็นว่านี่ไม่ใช่แค่ "พายุในถ้วยน้ำชา" เท่านั้น แต่ยังเป็นวิธีออกจากสถานการณ์อย่างแท้จริง ฉันจึงรับภาระรับผิดชอบสูงสุด โดยขจัดกิจวัตรที่ไม่พึงประสงค์ออกจากทีม
หนึ่งปีครึ่งผ่านไปแล้ว และโครงการกำลังพัฒนาโดยไม่ต้องทำงานล่วงเวลา ปราศจาก "การแข่งขันหนู" และความเครียดทุกรูปแบบ คนในทีมเก่าบางคนไม่อยากทำงานแบบนั้นแล้วจากไป ในทางกลับกัน คนอื่นๆ กลับรู้สึกยินดีเป็นอย่างยิ่งที่มีกฎเกณฑ์ที่โปร่งใสปรากฏขึ้น แต่ท้ายที่สุดแล้ว ทุกคนในทีมมีแรงบันดาลใจมากและรู้ดีถึงโปรเจ็กต์ใหญ่นี้อย่างครบถ้วน ทั้งส่วนหน้าและส่วนหลัง รวมทั้งฐานโค้ดและตรรกะทางธุรกิจทั้งหมด มันมาถึงจุดที่เราไม่ได้เป็นเพียง "นักพาย" เท่านั้น แต่เราเองก็มีกระบวนการทางธุรกิจและฟีเจอร์ใหม่ ๆ มากมายที่ธุรกิจชอบ
ด้วยวิธีนี้ในส่วนของเรา ลูกค้าจึงตัดสินใจสั่งซื้อตลาดอื่นจากบริษัทของเรา ซึ่งถือเป็นข่าวดี
เนื่องจากสิ่งนี้ใช้ได้กับโปรเจ็กต์ของฉัน บางทีมันอาจจะช่วยใครบางคนได้เช่นกัน ดังนั้น กระบวนการที่ช่วยเราบันทึกโครงการ:
กระบวนการทำงานเป็นทีมในโครงการ “My Favorite Project”
ก) กระบวนการของทีมภายใน (ระหว่างนักพัฒนา)
- ปัญหาทั้งหมดถูกสร้างขึ้นในระบบจิรา
- แต่ละงานควรอธิบายให้มากที่สุดเท่าที่จะเป็นไปได้และดำเนินการอย่างใดอย่างหนึ่งอย่างเคร่งครัด
- คุณลักษณะใดๆ หากมีความซับซ้อนเพียงพอ ก็จะถูกแบ่งออกเป็นงานเล็กๆ จำนวนมาก
- ทีมงานทำงานเกี่ยวกับฟีเจอร์ต่างๆ เป็นงานเดียว ขั้นแรก เราทุกคนทำงานร่วมกันในฟีเจอร์เดียว ส่งไปทดสอบ จากนั้นจึงใช้ฟีเจอร์ถัดไป
- แต่ละงานจะถูกทำเครื่องหมายไว้สำหรับแบ็กเอนด์หรือส่วนหน้า
- มีประเภทของงานและข้อบกพร่อง คุณต้องระบุให้ถูกต้อง
- หลังจากเสร็จสิ้นงาน งานจะถูกโอนไปยังสถานะการตรวจสอบโค้ด (ในกรณีนี้ จะมีการสร้างคำขอดึงสำหรับเพื่อนร่วมงาน)
- บุคคลที่ทำงานเสร็จจะติดตามเวลาของเขาสำหรับงานนี้ทันที
- หลังจากตรวจสอบโค้ดแล้ว PR จะอนุมัติและหลังจากนั้นผู้ที่ดำเนินการงานนี้ก็จะรวมโค้ดดังกล่าวเข้ากับสาขาหลักอย่างอิสระ หลังจากนั้นเขาก็เปลี่ยนสถานะเป็นพร้อมสำหรับการปรับใช้กับเซิร์ฟเวอร์ dev
- งานทั้งหมดที่พร้อมสำหรับการปรับใช้บนเซิร์ฟเวอร์ dev จะถูกปรับใช้โดยหัวหน้าทีม (พื้นที่รับผิดชอบของเขา) บางครั้งโดยสมาชิกในทีม หากมีเรื่องเร่งด่วน หลังจากการปรับใช้ งานทั้งหมดตั้งแต่พร้อมสำหรับการปรับใช้ไปจนถึงการพัฒนาจะถูกโอนไปยังสถานะ - พร้อมสำหรับการทดสอบบน dev
- งานทั้งหมดได้รับการทดสอบโดยลูกค้า
- เมื่อลูกค้าได้ทดสอบงานบน dev แล้ว เขาจะโอนงานดังกล่าวไปยังสถานะที่พร้อมสำหรับการปรับใช้เป็นการใช้งานจริง
- สำหรับการปรับใช้สู่การใช้งานจริง เรามีสาขาแยกต่างหาก โดยเราจะรวมต้นแบบก่อนการปรับใช้เท่านั้น
- หากในระหว่างการทดสอบลูกค้าพบจุดบกพร่อง เขาจะส่งคืนงานสำหรับการแก้ไข โดยตั้งค่าสถานะเป็นส่งคืนสำหรับการแก้ไข ด้วยวิธีนี้เราจะแยกงานใหม่ออกจากงานที่ไม่ผ่านการทดสอบ
- ผลลัพธ์ก็คือ งานทั้งหมดตั้งแต่การสร้างไปจนถึงความสำเร็จ: สิ่งที่ต้องทำ → อยู่ระหว่างการพัฒนา → การตรวจสอบโค้ด → พร้อมปรับใช้กับ dev → QA บน dev → (กลับสู่ dev) → พร้อมปรับใช้กับ prod → QA บน prod → เสร็จสิ้น
- นักพัฒนาแต่ละคนจะทดสอบโค้ดของตนอย่างเป็นอิสระ รวมถึงในฐานะผู้ใช้ไซต์ด้วย ไม่อนุญาตให้รวมสาขาเข้ากับสาขาหลัก เว้นแต่จะทราบแน่ชัดว่าโค้ดใช้งานได้
- ทุกงานมีลำดับความสำคัญ ลำดับความสำคัญถูกกำหนดโดยลูกค้าหรือหัวหน้าทีม
- นักพัฒนาทำงานที่มีลำดับความสำคัญก่อน
- นักพัฒนาสามารถมอบหมายงานให้กันและกันได้หากพบข้อบกพร่องที่แตกต่างกันในระบบหรืองานหนึ่งประกอบด้วยงานของผู้เชี่ยวชาญหลายคน
- งานทั้งหมดที่ลูกค้าสร้างขึ้นจะตกเป็นของหัวหน้าทีม ซึ่งจะเป็นผู้ประเมินและขอให้ลูกค้าแก้ไขหรือมอบหมายงานให้กับสมาชิกในทีมคนใดคนหนึ่ง
- งานทั้งหมดที่พร้อมสำหรับการปรับใช้เพื่อ dev หรือ prod ยังตกเป็นของหัวหน้าทีม ซึ่งจะเป็นผู้กำหนดเวลาและวิธีดำเนินการปรับใช้อย่างอิสระ หลังจากการปรับใช้แต่ละครั้ง หัวหน้าทีม (หรือสมาชิกในทีม) จะต้องแจ้งให้ลูกค้าทราบเกี่ยวกับเรื่องนี้ และยังเปลี่ยนสถานะของงานให้พร้อมสำหรับการทดสอบ dev/cont
- ทุกวันในเวลาเดียวกัน (สำหรับเราคือเวลา 12.00 น.) เราจะมีการประชุมระหว่างสมาชิกในทีมทุกคน
- ทุกคนที่ที่ประชุมรายงาน รวมถึงหัวหน้าทีมถึงสิ่งที่พวกเขาทำเมื่อวานนี้และสิ่งที่พวกเขาวางแผนจะทำในวันนี้ อะไรไม่ได้ผลและเพราะเหตุใด วิธีนี้ทำให้ทั้งทีมทราบว่าใครกำลังทำอะไรและโครงการอยู่ในขั้นตอนใด สิ่งนี้ทำให้เรามีโอกาสที่จะคาดการณ์และปรับเปลี่ยนการประมาณการและกำหนดเวลาของเราหากจำเป็น
- ในการประชุม หัวหน้าทีมยังพูดถึงการเปลี่ยนแปลงทั้งหมดในโปรเจ็กต์และระดับของข้อบกพร่องปัจจุบันที่ลูกค้าไม่พบ ข้อบกพร่องทั้งหมดจะถูกจัดเรียงและมอบหมายให้สมาชิกในทีมแต่ละคนทำการแก้ไข
- ในการประชุม หัวหน้าทีมจะมอบหมายงานให้กับแต่ละคน โดยคำนึงถึงปริมาณงานปัจจุบันของนักพัฒนา ระดับการฝึกอบรมทางวิชาชีพของพวกเขา และยังคำนึงถึงความใกล้เคียงของงานเฉพาะกับสิ่งที่นักพัฒนากำลังทำอยู่ในปัจจุบันด้วย
- ในการประชุม หัวหน้าทีมจะพัฒนากลยุทธ์ทั่วไปสำหรับสถาปัตยกรรมและตรรกะทางธุรกิจ หลังจากนั้นทั้งทีมก็หารือเรื่องนี้และตัดสินใจปรับเปลี่ยนหรือนำกลยุทธ์นี้ไปใช้
- นักพัฒนาแต่ละคนเขียนโค้ดและสร้างอัลกอริธึมอย่างอิสระภายในกรอบงานของสถาปัตยกรรมและตรรกะทางธุรกิจเดียว ทุกคนสามารถแสดงวิสัยทัศน์ในการนำไปปฏิบัติได้ แต่ไม่มีใครบังคับให้ใครทำในลักษณะนี้และไม่ใช่อย่างอื่น ทุกการตัดสินใจมีความชอบธรรม หากมีวิธีแก้ปัญหาที่ดีกว่า แต่ตอนนี้ไม่มีเวลา งานจะถูกสร้างขึ้นอย่างมหาศาลสำหรับการปรับโครงสร้างบางส่วนของโค้ดในอนาคต
- เมื่อนักพัฒนารับงาน เขาจะโอนงานนั้นไปเป็นสถานะการพัฒนา การสื่อสารทั้งหมดเกี่ยวกับการชี้แจงงานกับลูกค้าตกเป็นหน้าที่ของนักพัฒนา สามารถถามคำถามทางเทคนิคกับหัวหน้าทีมหรือเพื่อนร่วมงานได้
- หากนักพัฒนาไม่เข้าใจสาระสำคัญของงาน และลูกค้าไม่สามารถอธิบายได้อย่างชัดเจน เขาก็จะดำเนินการงานต่อไป และหัวหน้าทีมก็นำเรื่องปัจจุบันไปหารือกับลูกค้า
- ทุกวัน นักพัฒนาควรเขียนในแชทของลูกค้าเกี่ยวกับงานที่เขาทำเมื่อวานนี้ และงานที่เขาจะทำงานในวันนี้
- กระบวนการทำงานเกิดขึ้นตาม Scrum ทุกอย่างแบ่งออกเป็นการวิ่ง การวิ่งแต่ละครั้งใช้เวลาสองสัปดาห์
- สปรินต์ถูกสร้าง เติม และปิดโดยหัวหน้าทีม
- หากโครงการมีกำหนดเวลาที่เข้มงวด เราจะพยายามประเมินงานทั้งหมดโดยประมาณ และเราก็รวมพวกมันเข้าด้วยกันเป็นการวิ่ง หากลูกค้าพยายามเพิ่มงานให้กับ Sprint เราจะจัดลำดับความสำคัญและย้ายงานอื่น ๆ ไปยัง Sprint ถัดไป
b) กระบวนการทำงานร่วมกับลูกค้า
- นักพัฒนาซอฟต์แวร์ทุกคนสามารถและควรสื่อสารกับลูกค้า
- ลูกค้าไม่ได้รับอนุญาตให้กำหนดกฎของเกมของตนเอง จำเป็นต้องแสดงให้ลูกค้าเห็นอย่างชัดเจนด้วยความสุภาพและเป็นมิตรว่าเราเป็นผู้เชี่ยวชาญในสาขาของเรา และมีเพียงเราเท่านั้นที่ต้องสร้างกระบวนการทำงานและให้ลูกค้ามีส่วนร่วมในกระบวนการเหล่านั้น
- ตามหลักการแล้ว จำเป็นก่อนที่จะเริ่มใช้งานฟังก์ชันใดๆ เพื่อสร้างผังงานของกระบวนการเชิงตรรกะทั้งหมดสำหรับคุณลักษณะ (เวิร์กโฟลว์) และส่งให้ลูกค้าเพื่อยืนยัน สิ่งนี้ใช้ได้กับฟังก์ชันที่ซับซ้อนและไม่ชัดเจนเท่านั้น เช่น ระบบการชำระเงิน ระบบการแจ้งเตือน ฯลฯ สิ่งนี้จะช่วยให้เราเข้าใจได้อย่างแม่นยำมากขึ้นว่าลูกค้าต้องการอะไร บันทึกเอกสารประกอบสำหรับคุณสมบัตินี้ และยังช่วยประกันตัวเราจากข้อเท็จจริงที่ว่าลูกค้าอาจพูดในอนาคตว่าเราไม่ได้ทำตามที่เขาขอ
- ไดอะแกรม/ผังงาน/ตรรกะทั้งหมด ฯลฯ เราบันทึกไว้ใน Confluence/Fat โดยเราจะขอให้ลูกค้ายืนยันความถูกต้องของการดำเนินการในอนาคตในความคิดเห็น
- เราพยายามที่จะไม่สร้างภาระให้กับลูกค้าด้วยรายละเอียดทางเทคนิค หากเราต้องการความเข้าใจว่าลูกค้าต้องการอย่างไร เราจะวาดอัลกอริธึมดั้งเดิมในรูปแบบของผังงานที่ลูกค้าสามารถเข้าใจและแก้ไข/แก้ไขทุกสิ่งได้ด้วยตัวเอง
- หากลูกค้าพบข้อบกพร่องในโครงการ เราขอให้คุณอธิบายรายละเอียดโดยละเอียดเป็นภาษา Fat ลูกค้าดำเนินการภายใต้สถานการณ์ใด เมื่อใด ลำดับการดำเนินการใดในระหว่างการทดสอบ กรุณาแนบภาพหน้าจอ
- เราพยายามทุกวัน วันเว้นวัน เพื่อปรับใช้กับเซิร์ฟเวอร์ dev จากนั้นลูกค้าจะเริ่มทดสอบฟังก์ชันการทำงานและโปรเจ็กต์ไม่ได้ใช้งาน ในขณะเดียวกันนี่เป็นเครื่องหมายสำหรับลูกค้าว่าโครงการนี้อยู่ในการพัฒนาเต็มรูปแบบและไม่มีใครเล่านิทานให้เขาฟัง
- มักเกิดขึ้นที่ลูกค้าไม่เข้าใจสิ่งที่เขาต้องการอย่างถ่องแท้ เพราะเขากำลังสร้างธุรกิจใหม่ให้กับตัวเองด้วยกระบวนการที่ยังไม่เกิดขึ้น ดังนั้น สถานการณ์ที่พบบ่อยมากคือเมื่อเราโยนโค้ดทั้งหมดลงถังขยะและออกแบบตรรกะของแอปพลิเคชันใหม่ จากนี้ไปคุณไม่ควรครอบคลุมการทดสอบทุกอย่างอย่างแน่นอน เป็นการสมเหตุสมผลที่จะครอบคลุมเฉพาะฟังก์ชันการทำงานที่สำคัญด้วยการทดสอบ และต่อด้วยการจองเท่านั้น
- มีสถานการณ์ที่ทีมงานตระหนักว่าเราไม่สามารถทำตามกำหนดเวลาได้ จากนั้นเราจะดำเนินการตรวจสอบงานอย่างรวดเร็วและแจ้งให้ลูกค้าทราบทันที เพื่อเป็นการหลุดพ้นจากสถานการณ์ เราขอแนะนำให้เปิดใช้ฟังก์ชันการทำงานที่สำคัญและสำคัญตรงเวลา และปล่อยให้ส่วนที่เหลือไว้สำหรับภายหลังการเปิดตัว
- หากลูกค้าเริ่มคิดงานต่างๆ ออกจากหัว เริ่มเพ้อฝันและอธิบายด้วยมือ จากนั้นเราขอให้เขาจัดเตรียมเค้าโครงหน้ากระดาษและการไหลด้วยตรรกะที่ควรอธิบายพฤติกรรมของเค้าโครงทั้งหมดและ องค์ประกอบของมัน
- ก่อนที่จะเริ่มทำงานใดๆ เราต้องตรวจสอบให้แน่ใจว่าคุณลักษณะนี้รวมอยู่ในเงื่อนไขของข้อตกลง/สัญญาของเรา หากนี่คือคุณสมบัติใหม่ที่อยู่นอกเหนือข้อตกลงเบื้องต้นของเรา เราต้องกำหนดราคาคุณสมบัตินี้ ((เวลาเสร็จสมบูรณ์โดยประมาณ + 30%) x 2) และแจ้งให้ลูกค้าทราบว่าจะต้องใช้เวลามากขนาดนี้ในการดำเนินการให้เสร็จสิ้น บวกด้วย กำหนดเวลาจะถูกเลื่อนไปตามเวลาโดยประมาณคูณด้วยสอง มาทำงานให้เร็วขึ้นกันเถอะ - เยี่ยมมาก ทุกคนจะได้รับประโยชน์จากมัน ถ้าไม่เช่นนั้นเราจะช่วยคุณได้
c) สิ่งที่เราไม่ยอมรับในทีม:
- ความไม่มีความมุ่งมั่น ขาดความสงบ หลงลืม
- “กำลังเลี้ยงอาหารเช้า” หากคุณไม่สามารถทำงานให้เสร็จสิ้นได้และไม่รู้ว่าต้องทำอย่างไร คุณจะต้องแจ้งให้หัวหน้าทีมทราบทันที และไม่รอจนถึงนาทีสุดท้าย
- คิ้วและโอ้อวดจากบุคคลที่ยังไม่ได้พิสูจน์ความสามารถและความเป็นมืออาชีพของเขา หากพิสูจน์ได้ก็เป็นไปได้ภายในขอบเขตแห่งความเหมาะสม :)
- การหลอกลวงในทุกรูปแบบ หากงานไม่เสร็จสมบูรณ์ คุณไม่ควรเปลี่ยนสถานะเป็นเสร็จสมบูรณ์และเขียนในแชทกับลูกค้าว่างานพร้อมแล้ว คอมพิวเตอร์พัง ระบบพัง สุนัขเคี้ยวแล็ปท็อป ทั้งหมดนี้เป็นสิ่งที่ยอมรับไม่ได้ หากมีเหตุสุดวิสัยเกิดขึ้นต้องแจ้งให้หัวหน้าทีมทราบทันที
- เมื่อผู้เชี่ยวชาญออฟไลน์อยู่ตลอดเวลา และเป็นเรื่องยากที่จะติดต่อเขาในช่วงเวลาทำงาน
- ห้ามมีพิษในทีม! หากมีใครไม่เห็นด้วยกับบางสิ่งบางอย่าง ทุกคนก็จะรวมตัวกันเพื่อชุมนุมและหารือและตัดสินใจในเรื่องนั้น
และคำถาม/วิทยานิพนธ์จำนวนหนึ่งที่บางครั้งฉันขอให้ลูกค้าช่วยไขความเข้าใจผิดทั้งหมด:
- เกณฑ์คุณภาพของคุณคืออะไร?
- คุณจะทราบได้อย่างไรว่าโครงการมีปัญหาหรือไม่?
- การละเมิดคำแนะนำและคำแนะนำทั้งหมดของเราเกี่ยวกับการเปลี่ยนแปลง/ปรับปรุงระบบ มีเพียงคุณเท่านั้นที่เป็นผู้รับผิดชอบความเสี่ยงทั้งหมด
- การเปลี่ยนแปลงที่สำคัญใดๆ ในโปรเจ็กต์ (เช่น โฟลว์พิเศษทุกประเภท) จะทำให้เกิดข้อบกพร่องที่เป็นไปได้ (ซึ่งแน่นอนว่าเราจะแก้ไข)
- เป็นไปไม่ได้ที่จะเข้าใจภายในไม่กี่นาทีว่าปัญหาประเภทใดที่เกิดขึ้นในโครงการและแก้ไขได้ทันที
- เราทำงานในขั้นตอนผลิตภัณฑ์เฉพาะ (งานใน Zhira - การพัฒนา - การทดสอบ - ปรับใช้) ซึ่งหมายความว่าเราไม่สามารถตอบสนองต่อคำขอและการร้องเรียนทั้งหมดในแชทได้
- โปรแกรมเมอร์คือโปรแกรมเมอร์ ไม่ใช่ผู้ทดสอบมืออาชีพ และไม่สามารถรับประกันคุณภาพที่เหมาะสมของการทดสอบโครงการได้
- ความรับผิดชอบต่อการทดสอบขั้นสุดท้ายและการยอมรับงานการผลิตขึ้นอยู่กับคุณแต่เพียงผู้เดียว
- หากเราดำเนินการงานไปแล้ว เราไม่สามารถเปลี่ยนไปใช้งานอื่นได้ทันทีจนกว่าเราจะทำงานปัจจุบันเสร็จ (ไม่เช่นนั้นจะทำให้เกิดข้อบกพร่องมากขึ้นและเพิ่มเวลาในการพัฒนา)
- ในทีมมีคนน้อยลง (เนื่องจากการลาพักร้อนหรือลาป่วย) แต่มีงานมากขึ้นและทางร่างกายเราจะไม่มีเวลาตอบสนองทุกสิ่งที่คุณต้องการ
- เราขอให้คุณทำการปรับใช้กับการใช้งานจริงโดยไม่มีการทดสอบงานบน dev - นี่เป็นเพียงความเสี่ยงของคุณ ไม่ใช่นักพัฒนา
- เมื่อคุณกำหนดงานที่ไม่ชัดเจน ไม่มีขั้นตอนที่ถูกต้อง โดยไม่มีเลย์เอาต์การออกแบบ สิ่งนี้ต้องใช้ความพยายามและเวลาดำเนินการจากเรามากขึ้น เนื่องจากเราต้องทำงานเพิ่มเติมแทนคุณ
- งานใดๆ เกี่ยวกับข้อบกพร่อง โดยไม่มีคำอธิบายโดยละเอียดเกี่ยวกับเหตุการณ์ที่เกิดขึ้นและภาพหน้าจอ จะไม่เปิดโอกาสให้เราเข้าใจถึงสิ่งที่ผิดพลาด และวิธีที่เราจะแก้ไขข้อบกพร่องนี้
- โครงการนี้ต้องการการปรับปรุงและปรับปรุงอย่างต่อเนื่องเพื่อปรับปรุงประสิทธิภาพและความปลอดภัย ดังนั้นทีมงานจึงใช้เวลาส่วนหนึ่งในการปรับปรุงเหล่านี้
- เนื่องจากเรามีล่วงเวลาเป็นรายชั่วโมง (มีการแก้ไขด่วน) จึงต้องชดเชยให้ในวันอื่น
ตามกฎแล้วลูกค้าเข้าใจทันทีว่าการพัฒนาซอฟต์แวร์ทุกอย่างไม่ง่ายนักและความปรารถนาเพียงอย่างเดียวก็ไม่เพียงพออย่างชัดเจน
โดยทั่วไปนั่นคือทั้งหมด ฉันทิ้งการเจรจามากมายและการดีบักเบื้องต้นของกระบวนการทั้งหมดไว้เบื้องหลัง แต่ผลที่ตามมาคือทุกอย่างได้ผล ฉันสามารถพูดได้ว่ากระบวนการนี้กลายเป็น "กระสุนเงิน" สำหรับเรา คนใหม่ที่เข้ามาในโปรเจ็กต์สามารถมีส่วนร่วมในงานได้ทันทีตั้งแต่วันแรกเนื่องจากมีการอธิบายกระบวนการทั้งหมดไว้และเอกสารประกอบและสถาปัตยกรรมในรูปแบบไดอะแกรมทำให้เข้าใจได้ทันทีว่าเราทุกคนกำลังทำอะไรที่นี่
ป.ล. ขอชี้แจงว่าฝั่งเราไม่มีผู้จัดการโครงการ มันอยู่ฝั่งลูกค้า ไม่ใช่คนเทคนิคเลย โครงการยุโรป การสื่อสารทั้งหมดเป็นภาษาอังกฤษเท่านั้น
ขอให้ทุกคนโชคดีในโครงการของคุณ อย่าเหนื่อยหน่ายและพยายามปรับปรุงกระบวนการของคุณ
ที่มาในเหมือง .
ที่มา: will.com