ผู้จัดการโครงการที่ดีจำเป็นต้องมีพื้นฐานการเขียนโปรแกรมหรือไม่? [ปิด]

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

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

คำถามของฉันคือ: ผู้จัดการโครงการที่ดีต้องมีพื้นฐานการเขียนโปรแกรมหรือไม่?

หรืออาจเป็นคำถามควรผู้จัดการโครงการที่ดีต้องเป็นโปรแกรมเมอร์ที่ดีมาก่อนหรือไม่ มีความสัมพันธ์กันไหม?

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

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

ผู้จัดการที่มีพื้นฐานด้านเทคนิคที่แข็งแกร่งมักจะเข้าใจดีกว่าว่าทีมของพวกเขา "คิด" จะดีกว่าเสมอหากมีผู้จัดการที่เข้าใจคุณใช่ไหม

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

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

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

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

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

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

สำหรับการประมาณการนั้นเป็นความจริงของชีวิตในงานใด ๆ คุณไม่สามารถสร้างบ้านตรงเวลาได้หากช่างไฟฟ้าไม่สามารถบอกคุณได้ว่าจะต้องใช้เวลานานแค่ไหนในการเดินสายไฟ - เมื่อไหร่ที่คุณจะรู้ว่าคุณต้องจองห้องติดผนังของคุณหรือไม่? ฉันเห็นด้วยว่ามันยากมากในด้านไอทีที่จะให้การประเมินเนื่องจากจำนวนที่ไม่สามารถคาดเดาได้ ลูกค้ามักไม่รู้ว่าพวกเขาต้องการอะไรและมักจะลืมบอกสิ่งต่าง ๆ ให้คุณฟัง สิ่งที่ฉันเคยทำคือประมาณคร่าว ๆ ว่าฉันจะใช้เวลานานเท่าไหร่จากนั้นคูณด้วย 2! และผู้จัดการโปรแกรมที่ดีไม่ควรตรึงคุณเมื่อการประเมินของคุณพิสูจน์ผิดมันจะทำให้เขาปวดหัวอีกครั้งในการจัดระเบียบตารางพูดคุยกับลูกค้าอธิบายให้เจ้านายทราบว่ามันจะมีค่าใช้จ่ายมากขึ้น ฯลฯ ... แต่ นั่นเป็นส่วนหนึ่งของงานของพวกเขา - อีกครั้ง ส่วนใหญ่เป็นสิ่งที่จำเป็น

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

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

PM ต้องการทราบอย่างแท้จริงว่าโครงการจะทำอะไรซึ่งน่าจะต้องมีพื้นฐานทางเทคนิค แต่ไม่พัฒนา

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

ฉันไม่คิดว่าผู้จัดการโครงการของโครงการ IT ต้องการพื้นหลังด้านไอที แต่เขา / เธอต้องเข้าใจ IT อย่างแน่นอนและควรรู้ว่าโครงการ IT ทำงานอย่างไร

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

ฉันทำงานกับทั้งสองประเภทและแต่ละชุดมีคุณภาพและปัญหาที่เป็นเอกลักษณ์

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

หากไม่มีพื้นฐานด้านไอที:
- จะสะดวกสบายในการต่อรองเพื่อเปลี่ยนกำหนดเวลาที่สะดวกสบาย
- สำหรับโครงการที่ไม่มีข้อกำหนดใด ๆ (ในตอนนี้) บางครั้งจะพูดว่า "เราสามารถให้ประมาณคร่าวๆ 100 วันและพูดถึงบัฟเฟอร์ 30%

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

@NimChimpsky ฉันเห็นด้วย

มันเป็นเรื่องของอะไรไม่ใช่วิธี (การฟังที่ใช้งานเป็นเครื่องมือที่ดี)

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

มันจะช่วยได้โดยเฉพาะอย่างยิ่งถ้าพวกเขาไม่ใช่ผู้จัดการโครงการที่ดี สำหรับผู้จัดการโครงการที่ดีมันสำคัญมาก

เลขที่

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

ผู้จัดการโครงการที่ดีหรือไม่ดีสามารถมีพื้นหลังได้ทุกประเภท:

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

ผู้จัดการที่ดีอาจเป็นโปรแกรมเมอร์โดยเฉลี่ยที่ไม่เก่งหรือฉลาดเท่าเพื่อนร่วมงานของเขา แต่มีความเข้าใจอย่างลึกซึ้งเกี่ยวกับโครงสร้างของโครงการความต้องการและเข้าใจบทเรียนของ The Mythical Man Month ด้วยหัวใจเพราะเขาใช้ชีวิตในชีวิตที่ไม่ดี ถูกเคี้ยวเพราะไม่สามารถส่งมอบให้ทันเวลา

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

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

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

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

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

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

อย่างแน่นอน.

ฉันต้องระวังด้วยสิ่งนี้เพราะมันขึ้นอยู่กับเรื่องจริง แต่ฉันจะพยายามอธิบายความเจ็บปวดของฉัน

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

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

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

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

BTW ตั้งแต่ฉันทำงานกับเขางานของฉันจะไม่สนุกอีกต่อไป

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

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

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

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

ดูเหมือนจะมีความสับสน:

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

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

คุณสามารถเป็น PM ได้: A) เข้าใจวิธีจัดการโครงการ B) เข้าใจกระบวนการพัฒนา ทั้งสองอย่างนี้ต้องการความรู้ด้านการเขียนโค้ด แต่ก็สามารถช่วย

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

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

ฉันนึกถึงคำพูดเดิม: "คุณไม่ต้องบ้าที่จะทำงานที่นี่ แต่ช่วยได้"

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

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

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

กล่าวโดยย่อผู้จัดการจะนำค่าประมาณของคุณไปใช้ในกรณีหนึ่งในสามสถานการณ์:

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

หากเป็นสถานการณ์สุดท้ายนั้นจะมีปมอื่น ๆ อีกมากมายรอบ ๆ สถานที่ทำงานซึ่งบางทีคุณควรจะได้รับการปลดปล่อย

ฉันไม่มีความคิด แต่ผู้จัดการของฉันต้องการความรู้ด้านเทคนิค บางครั้งมันเป็นไปไม่ได้ที่จะอธิบายเขา