我們已經有一個Excel電子表格現在（全球）在我的公司中浮動，以捕獲有關每個國家/地區技術使用情況的各種信息。問題在於它熄滅，發生變化，但它們從來不明顯，並經常發生衝突 - 然後我們必須將它們粉碎在一起。對我而言，工作簿不過是一個等待寫入的垃圾輸入/垃圾輸出應用程序。適當使用Grails，Rails等？
在一家有足夠的員工和知識致力於企業項目的公司中，出於某種原因，敏捷和語言/框架（如Rails，Grails等）被詬病。也就是說，我忍不住想到這幾乎完全適合這種需求，因爲只有幾次查找（即預先定義的類別）才能捕捉原始字段的極其簡單的實現。我認爲這將被視爲這些框架的非常恰當的使用。
有沒有人曾經在這些類型的快速和骯髒的應用程序之前在正常的大型，苛刻的企業環境中取得成功？將這種需求/適當性傳達給非技術管理的任何提示？
在僵化的組織中實現這一目標的唯一方法就是讓它工作並演示它 - 未經批准。管理層很難對完成的項目說不。
我爲一家真正的大公司工作&已經編寫了許多基於Rails的實用程序（以及對一些更大的Rails項目的貢獻）。也就是說，最大的問題不在於應用程序的質量，而是當你離開或受到巴士撞擊時誰會支持/維護它。
恕我直言，企業組織的主要擔心 - 特別是如果應用程序對其核心業務變得更加重要 - 則是如何支持它。如果它不適合它那整齊的小盒子的支持技術，那麼它不太可能發生。
公司過去多次被企業咬傷&引進新技術時比較謹慎。因此，如果您可以鼓勵更多人在您的團隊（或您公司的其他地方）學習Ruby/Rails，那麼您或許可以爲此做一個很好的例子。否則，可悲的是，你可能更適合在Sharepoint上實現某些功能:-(。
如果你已經有了Java基礎架構，那麼創建一個Grails應用程序幾乎不需要額外的IT支持和維護。支持和維護的成本和努力應該與Java應用程序（即在Tomcat上運行的Grails應用程序，使用相同的JVM，使用相同的診斷/性能分析工具等）相同（根據我的經驗，更大的IT由於其新的語言，新的部署環境，並且需要大量的支持和維護，所以組織對於Ruby尚未進入工具鏈的時間提供支持的難度更大。
我會開發一個最小可行的產品，然後與IT人員交朋友，他們可以幫助您將其部署到分段或生產環境中。然後讓一些用戶跳上船，並像測試版產品一樣對其進行測試。之後，將它開放給更多的觀衆。
正如其他人所說，寬恕超過許可，但要明智地考慮對IT組織的影響。