软件顾问有多种形式，但如果你不能自己写代码，找到一个符合你需求的开发人员可能是一个充满压力的过程，涉及到很多尝试和错误。
为了缩小好的咨询公司的范围，我们通过TechCrunch专家项目对世界各地的专家进行了关于最佳软件开发顾问的调查。我们了解到的最值得推荐的公司之一是WolfPack Digital。我们采访了Wolfpack Digital的首席执行官Georgina 'Gina' Lupu Florian，谈论了她的公司，他们如何运作，以及经营咨询公司的细微差别。
(本采访已被编辑，以保证清晰度和长度。)
TechCrunch：作为一个雇佣的开发者，当帮助客户在将他们的应用程序推向市场之前验证想法时，你是如何参与的？
Gina Lupu Florian：我们的客户经常选择我们作为他们项目的唯一产品和技术合作伙伴，这意味着我们会高度参与帮助他们进行创意验证。我们在这里帮助他们进行产品发现和战略、市场分析、UX/UI设计、烟雾测试、可用性测试，以及其他一切必要的工作。在任何迭代的编程阶段完成后，我们支持向测试者推出应用程序，并以精益的方式从结果中反复学习，以便在产品正式推出时，最佳的第一个版本能够到达目标受众。
我们参与创意验证的程度可能会有所不同，这取决于项目的目标和需求、创始人和/或利益相关者，以及我们开始合作时项目所处的阶段。鉴于我们以产品为导向的方法，在过去的几年里，"开发人员雇佣 "的模式对我们来说并不常见，尽管我们也有符合这种模式的持续合作。我们愿意接受任何对我们的客户和他们的移动应用或网络平台最有效的设置。
TechCrunch：你能描述一下新客户的接收过程吗？你们如何评估他们的要求，在分享时间表和预算之前，你们需要哪些信息？
接收过程可能会有很大的不同，这取决于每个项目和合作的特殊性。我们通常会评估客户提供的信息，并提出一个建议，之后随着我们对产品的进一步了解，我们会与客户一起完善建议。
为了得到一个强有力的项目时间表和预算估计，我们认为用户故事、线框图和/或需求文件是一个完美的起点。我们可以直接从客户那里收集（如果他们在参加孵化器后已经准备好了），或者我们可以帮助把它们放在一起，并加入一个发现阶段，这通常需要几个小时到几天。从我们有足够的信息来准备提案的那一刻起，通常需要不到一周的时间来交付。
TechCrunch：一般项目的大概报价是多少，工作开始后你们与客户的沟通频率如何？
一般来说，关于报价的问题可能是最困难但也是最常见的问题。这是因为网站和/或移动项目的报价可以从几千美元到数百万美元不等。这一切都取决于项目的范围，而且越清晰，估计就越准确。然而，当我们开始一个项目时，我们要确保保持项目的敏捷性和适应性，以便将最好的产品推向市场。这就是在保持适应性的同时关注预算的平衡。
根据我们最近接手的项目，平均项目规模在10万至20万美元之间。由于我们是一家敏捷公司，我们与客户的沟通非常频繁，通常是每周一次。沟通频率在很大程度上取决于客户希望在开发过程中亲力亲为的程度--我们有的项目几乎每天都与他们同步，而在其他项目中，我们的客户则希望减少互动，以便他们能够专注于自己业务的不同部分。
你的客户中有多大比例是有想法但没有编程经验的非技术人员？这对推出一个应用程序有多大的限制？
我想说的是，我们的客户中大概有50%处于这种情况，要么是创业公司的创始人，要么是公司的代表（例如，规模化公司的产品所有者，或者企业创新部门的人员）。我们在这里为每一步提供帮助，所以我们根本不认为这是一种限制。
然而，在熟悉软件开发过程方面，以前有与机构/开发商合作的经验确实可能是有用的。但绝对是任何人，无论他们的背景如何，都可以迅速上手，我们在这里为他们提供支持。
作为一个顾问，帮助客户避免范围蠕变是你的职责之一吗？如果是的话，你如何帮助管理他们的期望？
当然是！
我认为这是我们工作的一部分。我认为这是我们责任的一部分，而最重要的因素是明确什么是优先事项。当然，我们鼓励构思，但最终，我们需要一起关注什么能给产品带来最大价值。除了明确优先事项外，关注项目的预算并在所有决策中考虑它是至关重要的，因为它可以使人大开眼界。
估算任何新功能/变化所需的工作，以便做出明智的决定，也是这个过程的一部分。我们的项目经理/产品负责人也会在整个过程中提供相关问题的支持，我们的团队也会提出建议，以便在考虑到所有相关因素的情况下，务实地达到客户的目标，取得最佳效果。
在签订合同后，你们交付一个可运行的应用程序的平均时间表是什么？在分享线框图之前，你们需要完成什么？
如果我们要从头开始做一个网站或移动应用，分别从一组需求开始，发现它、设计它、编程它、验证它等等，通常需要三个月到一年多的时间才能达到第一个版本。最常见的是六到九个月左右。这与产品的复杂性有很大关系，不仅从技术角度，而且从功能和产品体验角度，使其对用户有吸引力。
你希望你的应用程序拥有它所需要的一切，以便它是有用的，并通过把它变成比他们目前使用的任何东西更好的选择来解决一个问题，从而被用户采用。以银行应用程序为例，提供一个应用程序可能需要更长的时间，因为有许多集成需要创建，而且金融技术市场竞争相当激烈，所以你需要在应用程序的功能方面有一个强大的支柱。同时，投资会带来更大的收益。
你也监督QA过程吗？Wolfpack Digital能否帮助客户把握好应用商店的审批流程？
是的。我们有一个内部的QA团队，他们在寻找隐藏的问题方面有特殊的诀窍，他们与我们的开发人员和项目中的其他人密切合作。我们已经完成了数百次App Store的提交，我们已经优雅地处理了各种各样的情况。
我们发现，90%的情况下，审批工作是无缝进行的，但也可能遇到一些障碍（例如与条款和条件有关），在这种情况下，我们准备代表客户进行沟通，找到解决方案，并将问题和所需步骤翻译成无障碍语言。
你们是否提供一些营销服务？
这一直是我们计划的一部分，因为我们积极地收到关于此类服务的请求，但我们目前只营销我们自己的品牌，不向客户提供营销执行服务。不过，基于我们在这方面的内部知识，我们会帮助客户对他们的数字产品进行市场和受众分析--不仅是在开始时，而且随着应用的扩大，我们会根据现有的数据提出新的功能建议。
因此，我们为客户提供营销策略，作为我们产品策略和咨询服务的一部分。作为一家公司，我们曾在专注于应用概念和产品策略的全球竞赛中获奖，因此我们对这个主题特别有热情，其中包括一些强有力的营销元素。
你们同时从事混合和原生应用程序的工作吗？你能告诉我们两者的优点和缺点吗？你什么时候鼓励客户使用混合型应用程序？
是的，我们为移动应用程序提供原生和混合技术，而选择取决于每个项目的类型和特点。在一些重要的情况下，我们相信原生iOS和Android的力量。首先，当可扩展性和稳定性从一开始就非常重要时，例如金融技术应用。他们很可能在复杂性和用户群方面都有所增长，所以拥有一个人们可以依赖的稳定的应用程序是至关重要的。
随着时间的推移，本地应用程序的扩展性更好，因为它们使用苹果和谷歌创建的本地框架，所以你在做什么方面没有任何限制。此外，随着每个新的iOS或Android的更新，本地技术首先得到更新，所以你可以预先解决任何操作系统的意外。
另一种情况是，当应用程序需要使用手机的硬件功能时。蓝牙、相机、GPS、陀螺仪等。在原生端，你可以直接访问这些SDK，但在混合端，你需要编写自己的插件（原生代码），或依赖开源社区的现有插件。这可能会成为问题，特别是在某些边缘情况下（自动重新连接，改变相机的参数等）。
当你在寻找一个想法的快速验证时，或者当你处理一个简单的移动应用时，混合技术是一个很好的选择，它在很大程度上依赖于后端。如果应用程序的90%只是你输入的数据（例如，表格或问卷，用于医疗保健应用程序收集反馈），或显示来自服务器端的数据（数字、图表或建议），那么Flutter可能是最好的选择，因为这里没有任何与功能相关的惊喜。此外，Flutter允许你为iOS和Android创建相同的UI，如果这是目标之一的话，尽管大多数情况下，每个人都使用本地元素更好。
如果你选择原生系统，上市的时间通常会更短，因为你可以在两条轨道上迅速地并行发展，而总体预算，至少在初期，可能会比原生系统更高。然而，从长远来看，混合模式可能会带来某些挑战，使项目的预算达到类似的水平，甚至超过原生模式，这取决于你在开发过程中发现的挑战，或者你需要实现的新功能。
混合系统的可维护性绝对是一个强大的优势，因为你有一个单一的代码库需要维护。然而，你需要有熟悉所选混合技术和本地技术的开发人员，以防需要任何插件，这可能会使人员配置困难。总的来说，在原生和混合之间没有正确或错误的答案，最佳选择在很大程度上取决于你的应用程序的特殊性。
你曾经拒绝过一个客户吗？是否有一些你不愿意做的应用程序，例如游戏或约会？
我们曾经拒绝过客户，虽然我们的投资组合相当多样化，但对我们来说，重要的是我们所做的项目要符合我们的价值观和道德观。例如，我们曾为约会应用程序工作，但我们会拒绝涉及武器、非法毒品等的网站或应用程序的请求。
游戏是我们没有进入的领域，因为开发游戏所需的技术和设计能力与我们自己的有很大不同（包括使用的编程语言--例如，我们使用Ruby on Rails、Vue.js、Swift、Kotlin和Flutter，而Unity在游戏中使用得相当普遍）。然而，我们开发的许多应用程序都有很强的游戏化特征。
项目完成后，谁拥有源代码？源代码是如何管理的？
通常情况下，客户拥有源代码，所有的知识产权都属于他们，从第一天开始。这一点在我们的服务协议中也有规定。当涉及到管理源代码时，我们涵盖了不同的情况，但我们通常在每个项目中都有一个私人的版本控制（Git）库。从事该项目的团队可以访问这个仓库，定期推送代码，同时遵循Git-flow准则。
一旦项目完成，甚至在中间步骤，我们会将源代码转移到客户拥有的仓库。如果需要，我们会协助他们创建一个版本控制账户，然后是一个或多个仓库（取决于该项目需要多少技术--iOS、Android、后端等），最后是让我们将源代码转移给他们。
当然，他们也能看到提交历史和沿途的每一步。如果需要任何更新，我们可以继续在我们自己的存储库中工作，并再次转移代码更新，或者直接将代码更新推送到他们的存储库。我们也有合作，与客户的内部开发团队合作，因此整个团队在任何时候都活跃在同一个软件库上。
