คุณจะจัดการกับ API / เทคโนโลยีที่เหนือหัวได้อย่างไร

11

ฉันเดาว่าคนส่วนใหญ่อยู่ในสถานการณ์เช่นนี้

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

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

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

technology research

— coder
แหล่งที่มา

+1: เป็นคำถามที่ดีมาก คุ้มค่ากับ +10 ฉันเคยมีประสบการณ์แบบเดียวกัน

— Jim G.

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

— Mike Dunlavey

9

ต้นแบบต้นแบบต้นแบบ !!

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

Matt Raible (ตัวเปรียบเทียบกรอบงานเว็บ Java) แนะนำให้ทำงานกับเฟรมเวิร์กเป็นเวลาหนึ่งสัปดาห์ถ้าเป็นไปได้

การสร้างต้นแบบรวมถึงการตรวจสอบการสนับสนุนของชุมชนที่อยู่เบื้องหลังกรอบและปัจจัยอื่น ๆ

— Martijn Verburg
แหล่งที่มา

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

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

— edelwater

en dan willen ze og nog de exacte เซิร์ฟเวอร์ specs van voren ....

— edelwater

6

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

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

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

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

— Michael Shaw
แหล่งที่มา

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

— เคนเฮนเดอร์สัน

2

คุณจะจัดการกับสถานการณ์เหล่านี้ได้อย่างไร ". สิ่งที่ฉันได้เห็น / มีประสบการณ์:

หมายเลข 1 จุดที่ฉันเห็นด้วยกับปโตเลมี: ซื่อสัตย์:

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

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

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

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

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

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

— edelwater
แหล่งที่มา