您如何处理头顶式API /技术

我想大多数人都处于这种情况。

初始项目计划开始。要求概述。在对体系结构进行审查并通过API / Frameworks进行排序后，便选择了合适的技术。开发开始。

然后开始。一旦您需要做一些据说简单的支持工作，框架/ API就开始适得其反，而您却没有做任何工作就与该技术作斗争。研究时间飞速增长，论坛一片寂静，似乎什么也没做，即使您有工作要做，也不确定自己是否做对了。

在这些情况下如何管理？您是否喜欢黑客，是否会进一步研究，对管理人员说什么？

原型，原型，原型！！

如果您的团队不熟悉特定的框架，则可以在其中构建原型以评估痛点所在。

Java Web框架比较器专家Matt Raible建议尽可能使用一个框架一周。

原型制作包括调查框架和其他因素背后的社区支持

管理外部依赖关系是许多IT项目的祸根。许多年前，与我合作的经验丰富的程序员总是确保他们能够控制其依赖项-通常是坚持要购买源代码许可证。

就个人而言，这不是我的方法。我倾向于承诺不足，过分讲究思想。有时候，我不得不竭尽全力，但是我事先会做私人研究以确保99％的确定-通常，我会在自己的时间做一个私人项目，以确保技术能够交付。在有效的原型中，测试，验证然后承诺。

在某些情况下，我确实会被吸引住-必须回溯或有创造力。拥有丰富经验的创造性思维在这里会有所帮助，但与其他人交谈也会有所帮助。-并非总是程序员。有时解决方案来自真正陌生的地方。

至于与管理打交道，关键是诚实。经常和早说话。不要把它留到最后一刻，因为在大笔交付的前一天让经理/客户失望，只会使您看起来像业余爱好者。能够说在经理需要在删除一些功能和/或延迟发货之间进行选择的截止日期之前的两个月在当时可能并不流行，但这确实使组织的其余部分能够开展工作并进行计划。能够做到这一点的关键是拥有一个能够跟踪时间和任务估计的良好任务管理系统。有确凿的证据支持您的观点，使您更有可能被倾听。

“在这些情况下您如何处理？”。我所见/经历：

我同意托勒密的数字1分：说实话：

如果确实存在问题，请：去那个房间，说出问题，坐下来等待愤怒的回应，然后……制定新的计划/解决方案。（这家伙并不生你的气）。

有一些IT课程仅处理这种情况。您和演员在一起，他们把听到这个消息的生气的客户放置了。您会得到很多提示。听起来很愚蠢，但也许只有在这样做之后，您才会注意到它的价值。在这种情况下，我留下了要记住80分的表格...（和练习）。

这种情况可能更为典型，因此在今天预算紧张，以“最低报价”完成销售的情况下，您给出的计划在客户接受之前被削减了5倍...（包括该原型，因为“他正在招聘您是因为您是专家，否则将等待10个人“）等...

-另一件事可能是横向思考：如果无法以这种方式完成，请尝试提出完全不同的方案，为客户提供相同的价值。如果该技术根本无法使用/破裂/退出交易/等等...如果客户对此表示满意，那么最终可以提供相同的价值。但是带来它也很困难。（对于某些人而言，完全不对其他人而言）。您需要真正有经验的人。同样的情况是，技术还没有达到极限……需要几个月的时间……所以您需要说服客户重新计划并接受重新计划及其对组织的影响……

-另一个“经验教训”是，一旦您注意到高级管理人员朝着这个方向发展，就立即去调用它。他们经常处理有问题的项目，在这种情况下确实很有帮助。通常，他们只从有问题的项目迁移到有问题的项目。

-吸取的另一个教训是让您的架构内容通过验证渠道，尤其是在较大的项目上。签名可以掩盖您的屁股。（保存您所有的电子邮件，哈哈）