Get best of the week

电子合同开发。项目计算




每个月，我们都会收到数十个电子开发应用程序。每个潜在客户都希望知道解决问题的成本，无论他对问题的理解程度如何。合同开发商可以请大家吗？如何提前淘汰“无望”？如何评估那些有发展机会的项目？这是我们的新文章。

什么项目不应该考虑


刚开始时，邮件中的每个应用程序似乎都是命运的礼物。我们与我们的整个小型团队坐下来，得出实施这个项目有多酷的想法。似乎有必要为每个潜在客户提供最大的细节。必须选择主要的技术解决方案，将工作分解为各个阶段，分解为各个任务，绘制甘特图，计算产品成本，并在商业建议书（KP）中尽可能详细地描述所有这些。我们在每个CP上花费了多达几天的时间，客户一直在考虑。 随着时间的流逝，人们逐渐意识到，您不能浪费时间工程师和筛选出没有未来的项目


甚至在深入技术细节之前。首先，有必要了解未来客户意图的严肃性。，诸如“我昨天在互联网上看到一个50,000卢布的设备，以30,000卢布的价格给我买的设备”之类的要求比我们想要的更为常见。

为了评估项目成功的机会，我们需要问什么？


  1. 为什么组织需要给定的产品（产品创建目标）？我们需要找出最准确的业务任务表述，因此，我们将通过下一个“聪明的主意”（带有蓝牙和移动应用程序的自动浴垫）过滤出梦想家。
  2. 谁是项目（DM）的发起人？我们找出谁负责这项技术，谁来分配预算。通常这些人是不同的人，他们在销售方面需要不同的方法。
  3. ( )?
  4. . : , , , .?
  5. ( , )?
    . , , , .
  6. ( )? , , , . « » =)
  7. ( .., )?
  8. ?

    • — :
      1. (, )?
      2. ?
      3. (), ? -? ?
    • — : . , , . « », , .
    • ? ? ? — .
  9. ? — :
    • (, )?
    • (, )?
    • ?
    • , ?
    • ( )?
  10. () ( )? «», - . , 9 .
  11. ? , . , , .
  12. (, , , )? « , ». , -.
  13. ? : , .
  14. ? – .
  15. ? (, , , , ). . ?
  16. ? ?
  17. (, , )?
  18. ? .


-




因此，客户和项目满足所有要求，我们开始评估。评估不准确且不合适。如果我们还没有传统知识，那么我们将得到一个不合格的评估，其范围很广。写传统知识-收到不正确的评估。如果没有TK，则分数的容差为±400％或更高。这称为不确定性锥： 有关界面的图，但是不同项目上的本质是相同的。我们知道的越多，不确定性就越小。不要在传统知识上浪费时间和精力。




我们的项目评估会议的非正式名称为“ Vanga Club”。参与者提前熟悉了该项目的资料。在指定的时间，俱乐部收到：商人，项目经理，首席电路工程师，首席程序员。有时，还会邀请其他具有狭窄专业知识的专家以及承包商代表。全面审查该项目需要大量人员。商家对自己的运气感到满意，并通过简化要求来努力满足客户。项目经理必须将项目付诸实践，他将负责时间安排，成本和工作量。他的愿望是储备金，要考虑到风险。工程师希望比昨天做得更好。他们可以轻易拒绝一个简单但无趣的选择。没有项目经理，您会被低估，因为商人非常有说服力。没有商人，您可以指望太多，以至于客户甚至都没有回信。



会议从对问题的一般性讨论开始，以形成所有参与者的共识。然后，为该项目构建工作的层次结构（WBS）。
对于单个设备，分配了软件和硬件部分。对于系统，添加了不同的部分，例如测试软件，模拟器，服务器部分等。生成的零件被分成较小的零件，例如，硬件分支为PCB和设计的两个修订版。下一步是将各部分分解为单独的任务。如果实施过程一切顺利，则任务应该很小。分类“写入固件”任务不适合。我们考虑评分较低的常规特定任务，例如：“ MCU I2C驱动程序”，“筹集项目”，“ E3计划”。
您不应该提前评估任务的复杂性，因为只有当它们全部写在板上时，它们的复杂性和关系才会变得清晰。

所有任务均以小时为单位分配劳力。该方法是专家评估。时钟可以从以下两个幂中取幂：2、4、8、16、32、64、128 ...在实现不清楚时会出现评估为128小时或更长时间的任务。这意味着值得进行工作以弄清要求，验证技术的适用性，有时甚至是散布和吸烟 Google。
根据我的观察，有可能提高评估的准确性，首先，请经验不足的开发人员提出意见。因此，他们学会了自己更快地评估任务。如果已经有一位著名的工程师发言，那么其他所有人往往会简单地同意他的观点。当项目工作开始时，任务很可能不是由他解决，而是由那些什么也没说的人解决。我们仍然会听到他们的评估，但不是在正确的时间。
对所有任务进行评估后，我们将对结果进行汇总，并在软件中添加30％进行调试，在软件测试中添加30％。这些数字取自已完成项目的统计数据。
结果，以下图片出现在板上：



评估通常伴随着对细节的敏锐讨论，因为可以有很多解决问题的选择。因此，需要不少于一个小时。如果有足够的准备时间，即使对项目进行初步评估也要花费5-20个小时的领先开发人员。

我们每个人都想制造出使人们受益的成功产品，即电子产品。我们讨论评估结果（时间表，资源）如何与整个项目的目标一致。可能值得为客户提供其他方式。例如，削减MVP的功能，或采用更昂贵的硬件来支持更便宜的开发。粗略计算项目后续阶段的总体经济效益是很有用的：生产，生产，支持。这些数字显示了项目各个阶段的资源和时间的相对权重，并且可以显着改变他们（我们和客户）的看法。

从Wang俱乐部收到的评分将输入Redmine。 EasyWBS适用于以可视形式快速添加任务：




为了确定发展的时机，我们建立铁链任务（瀑布）。我们得到了这样的甘特图： 对于软件，我们将劳动强度划分为可同时参与项目的人数的生产率。如您所知，一个程序员在一个月内要做的事情，两个程序员在两个月内要做的事情。因此，在计算时，您不应考虑所有的人力资源。另外，并非在每个项目中程序员都可以从头开始工作。碰巧您需要等待自己购买或购买的熨斗。相同的延迟可能发生在铁的阶段和修订版本的交界处。 为了通知客户，无法采用收到的日期。除非带有前缀“乐观的预测”。最好给一点余量。他会派上用场的。






在计算模块中，增加了专家费率，并增加了协约商，生产，材料，设备等的成本。 我们直接从这里创建对客户的极好的商业报价。pdf。 阅读我们的同事如何使用单个请求的示例来不同地评估项目。十二KP的小分析。 因此，该项目被接受，评估。仍然需要签订合同-继续进行，重写任务，更改技术解决方案，扩展需求，更改项目以至于无法认可！









对于我们而言，毫无疑问是否要评估项目，因为我们正在为客户做项目，因此如果没有评估就无法获得合同。但是对于公司内部项目，情况就不同了。通常，内部项目不会得到评估。而且非常徒劳。这种方法的结果是时间和资源的低估。团队和管理层都无法评估项目的当前进度。因此，团队的误解和士气低落。

现在-让我们在评论中讨论您的项目评估方法！

More articles:


All Articles