即使在非常大的公司中，他们也经常像蘑菇一样对待开发人员：他们被置于黑暗中并被粪肥喂养。 编写代码，家庭，不要硬着头皮。 这种方法对许多人来说可能很方便（在管理不够充分的情况下，有时对于开发人员本身也很方便），但是从业务的角度来看并不是最佳的。 我的立场：开发人员应该能够学习公司和市场上发生的所有事情，而又没有压力。 想要-他挖了个洞，弄清楚了，不想-不想。
很少有开发人员不想了解他为什么做以及正在做什么。 很少有人不希望看到实施功能对周围世界的影响。 快点说吧，老实说：我们都在这里是因为钱，还是因为有做有意义的事情的能力。 到处都有钱。 但是有趣的项目并不常见。
我想分享在Tutu.ru团队中如何组织此类信息的过程。 也许对某些人来说，这似乎是一个教育计划，但对某人而言，它将是有用的。 好吧，或者您告诉我如何做得更好。
一般职位
- 开发团队将尽可能告诉市场情况，与竞争对手的关系，情况以及如何发生。
- 对于公司的高层管理人员来说，重要的是要知道项目中到底做了什么，以及这如何导致战略目标。 通常，我们谈论的是项目组的级别，但是如果需要，您可能无法报告特定的工作。
- 其他团队有兴趣查看同事的工作。 我们使用不同类型的运输工具（铁路，飞机，公共汽车）来解决类似的问题，并且您经常可以重用代码，监视创意或查看如何使用不同的工具。 并问。
这有什么影响？
看来，如果开发人员从上面落下了任务，那么他拥有完整知识的能力就是选择稍微更正确的体系结构解决方案。 人们相信，随着体系结构的正确性的提高，这降低了技术债务的增长率。 是的，的确如此，但是实际上，组织和支持午餐以外的信息流程与处理技术债务一样困难。
但是，第二个重要的事情出现了。 即，那些想与企业一起参加头脑风暴会议的人。 就是说，如果企业早先计划，设置任务和优先级并告诉自己做什么和怎么做，那么现在发展会对其产生影响。
在这里，我们有很多次非常有趣的现象。 工程师的思想与普通人的思想不同。 在某些结构上，在某些地方出乎意料的好决策，在某些地方出现认知失真。 外观乌云密布。 否定了“它发生了”的实践，因为对于某些实践来说，它们是给定的，对于工程师而言，它们是黑暗的遗产。 而且不在乎他多大了。
最初，讨论放缓了。 开发人员显然在财务分析上遇到了很大的困难，因此有必要经常加载它们，以证明解决方案的可能性或可能性（更多）。
然后几次，我设法找到了一个企业甚至都不认为可以用一个动作就能完成某事的地方。 因此，例如，使用公交车的数学模型，我们能够将车站和路线绑定起来，并恢复两个方向的时间表。
这是故事 。
下一个重要的事情是，单个系统有望在未来1-2年内投放市场。 一年前，这似乎很棒，每个承运人，包括带有生锈的80年代公交车的小型SP，都有自己的标准。 现在，所有这些都集中在一个信息系统中。 我们已经构建了其部分功能，但是现在可以删除此层并立即获取干净的数据。 当然，随着市场的变化，我们需要整个团队进行讨论。 至少，这消除了“为什么我们不完成酷功能的酷代码”级别的问题，并且最大程度地，它比其他任何人都可以更有效地为更改做准备。 营销部门会向技术团队咨询，询问他们如何制造新系统以及它将受到哪些限制。 我们描述了如何在联邦一级实施该体系结构，并意识到我们的系统将成为管理品牌，营销活动和其他工具以促进用户并与用户沟通的附加组件。 它不会重复竞争，而是集成在一起的。
或者这是一个示例，说明如果我们需要将许多小伙伴连接到系统上，该怎么办。 企业通过视线了解了每个人，并了解了他们的想法。 开发人员不认识任何人，也不了解市场限制，因此他计算了模型并提出了冷的合理解决方案。 为了证明不可能的理由，该公司意识到实际上市场限制是虚幻的。 在这里，我们还有另一个突破，但是现在还没有发展。 与合作伙伴合作的团队将重点转移到其他合作伙伴上，这为我们提供了更多的系统数据。
下面的例子。 开发人员在会议上发表讲话，谈论技术解决方案。 他谈到了自己的机票预定系统-承运人的个人帐户。 观众向他提出了一个完全定制的问题，即“如果我坐在下一站会发生什么”。 在98％的情况下，开发人员会在集成和数据交换方面做出回应。 在这里，他谈到了业务运作方式，承运人与车站之间的什么样的关系。 并争论了每一个细节。
好吧，该如何告知？
当公司有五个产品负责人时，我们每周收集并交换一次有关该产品有用的信息以及可能有所不同的信息。 然后我们变成了八岁。 然后-13人。 而且已经有13个人很难集会。 他们建议以字母形式交换分析结果。 他们开始谈论他们在产品中做了什么，并就如何将其应用到其他产品中提出了建议。 是一个半月一次，然后-一个月一次。
这样就形成了带有每月报告的传统规则。 根据团队的工作结果，一个月内就寄出了一封丰厚的信件（最后一次上车是27页A4页）。 您只能阅读最上面的内容，但是可以连续或分段进行所有操作。 它有助于获得反馈和新想法。
会议表演重复了该报告：不必参加会议，但是经常有来自相邻团队的人来参加会议。 会议上重要的事情很简短，您可以即时提问。 然后阅读该信，并根据需要了解详细信息。 在其中一次会议上，一名铁路员工告诉用户如何离开斯维尔德洛夫斯克（乌克兰）而不是叶卡捷琳堡（俄罗斯，斯维尔德洛夫斯克州前斯维尔德洛夫斯克）。 公共汽车上也有这种碰撞。 他们一起考虑了概率分析（可能应该去的地方）和有关非典型路线的警告系统。 更改了城市首字母提示的顺序，因此，不太可能的指示要比最重要的指示晚。
我收集了关于食物的摘要。 也就是说，他首先从最终用户（团队开发人员，项目所有者，与合作伙伴进行沟通的商人）的价值中发出了他认为正确的东西，然后他开始收集反馈。 在某个地方，有人开始问以前没有的问题。 他们在某个地方要求提供更多详细信息。 然后，我向所有人发送了关于什么有用和什么没有的民意调查。
结果，出现以下结构：- 产品中的主要任务：做什么，为什么，为什么，如何。 请务必注意，每项任务都会以某种方式影响市场。 功能集聚集在策略点中，例如“最快下订单”或“拥有最准确的时间表”，
- 然后我们取出分析研究的结果。 因此，例如，通过我们的研究，我们了解到，乘搭巴士通常只是旅程的第一步，然后一个人乘火车旅行。 或从火车换乘公共汽车（如果前往内陆地区）。 这一点非常重要，因为它首先会影响营销，其次才是影响所有界面。 因为任务已经不是购买公交车票，而是将其与火车停靠以便到达某个方便的地方。 下一位分析师-比较了火车，火车，公共汽车的路线网络以进行重复或扩展。 因此，在Moscow-Dmitrov火车及之后的时间表页面上，整个Dmitrovsky区的公共汽车都在小部件中。 现在-实施中。
- 可能有市场新闻。 一切都是平庸的：只是为了让每个人都知道期望什么以及做得怎样了。
- 调查-是否需要吸引某人的问题。 我们收集了谁开车以及他们遇到什么问题的信息。 他们询问团队，实施电子票证会更方便。 根据公共汽车的种类-谁开车去哪里，怎么了，一切都生锈了。 有时我们会要求您在某些方向的站点停下来拍照。
根据第一个摘要的结果，他们开始研究同一段火车票比公交车票便宜还是贵。 他们得出了许多不太明显的结果。 也许我稍后再写。
我们的许多研究对同事都是有用的。 我们采取一些措施。 以下是由CJM用户制作的另一种产品（游览）的示例。 我们习惯于认为购票的方法是线性漏斗型。 实际上，人们在页面之间徘徊，打开许多选项卡，自信地在浏览器中以不同的形式按下“后退”，并且通常可以同时从不同的设备浏览器（当您需要购买时，它们可以从手机转移到台式机）。 跟踪所有这些奇怪的轨迹，就可以决定在人员被封闭的地方采取一些额外的步骤。 俄罗斯人的一个典型问题：选择公共汽车时，许多人无法击败座位选择界面。 让我提醒您，我们正在谈论的是居住在村庄中的人们，他们不知道搜索查询和站点地址之间的区别。 这些只是不知道如何在超市的磅秤上使用卷轴的人（如果有的话）。 通常，一个假设诞生了：您需要自动选择一个位置，然后您需要同意或更改它。 而且-看哪！ -遥远的俄罗斯村庄的居民，劳务移民和许多用户类别在界面中不再被混淆。
一个呼叫中心来到其中一个会议，说他们在第一行被愚蠢的问题弄糊涂了，而现在已经有一个月了-同样的问题。 通过签署字段提示，买票后在信件中添加更多详细信息等方式，消除了一大堆问题。 最奇怪的是：在公交卡上，通往该路线的链接位于一个蓝色发光的骰子上，但人们没有戳那里，而是打了电话。 也就是说，有人不仅仅理解这是一个链接。
另一个有趣的发现-在这样的会议上，我们从空中听了同事的话，并弄清楚了航空公司的机票定价是如何工作的。 然后他们为我们的承运人提供了装载巴士的服务。 当航班的覆盖率不超过40％时，我们会在短时间内对价格进行打折，以使在同一方向上获得的火车减少。 票价为1,300卢布，变成400卢布：承运人要花400卢比买一辆整辆巴士是无利可图的，但要花10人乘400卢比乘车，总比不乘其他人要好。
报告是如何形成的？
任务及其进度。 范例：
CC的新决策规则
- 您决定了什么？ 在某些情况下，联络中心专家必须独立做出有利于客户的决定，而不必等待与合作伙伴（公交车站，承运人）进行分析的情况，这可能需要数周的时间或需要支持人员进行分析。 因此，他们评估了损失的价格阈值所在的位置，低于此阈值，CC的专家可以立即做出决策。
- 结果如何，下一步该怎么做？ 价格已确定，我们将继续在其他情况下工作。 在这种情况下，将收集所有数据，我们将控制此指标（机票损失）。 KC的专家开始独立解决客户的某些情况。
- 这在其他产品中如何有用？ 如果您立即帮助客户，那么投入到深层次的诉讼程序中，有时会更有效且对品牌有更好的影响。 评估一下，也许在这里您还有一些工作要做。
空问题包括所有CTIS（铁路，航空，火车）
- 您决定了什么？ 在空无一人的问题上，当我们无法为客户提供巴士时，他们开始展示所有CTIS，并返回火车。 重要的是要了解这如何影响行为，替代方案是否有趣以及是否值得进一步开发。
- 结果如何，下一步该怎么做？ 在36％的情况下，向客户提供了替代方案。 假设客户仍在寻找真正的公交车（他们真正去的地方），因此实际上有很多客户不满意。 对于公共汽车和PTT来说，这都是潜在的，我们正在扩大产品范围。 他们一直在关注这一点，但是我们不打算在空白的问题上积极发展，但是我们将进一步考虑如何将它们正确地整合到当前问题中。
- 这在其他产品中如何有用？ 对于我们的大国而言，公交车可能是某个地方旅行必不可少的一部分。 因此，如果您习惯于客户从A到B的类别进行思考，则运输方式（多式联运）的组合在战略上很有意义。
研究和假设，例如：
是什么让人们回来？
- 您决定了什么？ 描述返回给我们的用户，以及他们的行为与未返回的用户有何不同。
- 结果，下一步该怎么做？ 我们收集了一组描述用户的行为特征，这可能会影响其可返回性。 重要的是，这不是一种预测模型，而是一种描述性模型。 此外，我们将进行实验，对特征进行强加并观察收益。 最终，我们希望创建一个预测模型，以了解如何使用户参与到产品中来，涉及到什么以增加退货的可能性。 显而易见，但事实是：已经在其他区域购买过的人很可能会回来乘公共汽车重新购买。
- 这在其他产品中如何有用？ 如果您有兴趣沿这个方向进行挖掘，请进行类似的分析并比较交叉点。
然后-问题的答案：“正在发生什么？”，议程示例：
- 为什么要少买？ 是的，一切都很好，只是一个我们不知道的季节。
- 直接流量。 为什么会有如此急剧的增长？ 您答对了吗？ 而你不麻痹？ 并且还回答了几个问题（破坏者：是的，我们被解析了）。
- 平台。 我们正在吸引用户。 人们真正参与站点内容管理的最初结果。 人们正在积极帮助。
- 跨平台购买。 在没有打印机的情况下将人们停在PC上的电子票证。 接下来是什么？ 首次在PC上购物的人中有83％继续在PC上购物。
- 队列分析。 图表不适合胆小者。
- 空中销售如何。 我们不仅对行李票了解很多，而且...（在同一时期在飞机上进行订购的用户在公共汽车上订购了431份订单，其中42％是用于补充飞机的公共汽车（即公共汽车是到达出发地还是到达到达点），12％-相反的方向。）
非人类实验（这对所有团队都很有趣），例如：什么会影响航班需求？
- 运营商评级。 根据我们用户的反馈（例如9.4对8.4），评分的差值提高了23％。 对于承运人而言，这对于增加乘客的服务水平可能是一个非常重要的论据。
- 购买促销航班（标有Tutu.ru优惠徽章并标有打折价格）的概率增加了XX％。
- 将首批促销报价增加XX％，ceteris paribus，即发行后转化的可能性。 这意味着您需要扩大库存的方向范围。
- 如果在每次签发航班的A / B测试中，可用座位数减少了一个，那么从签发中转换的可能性将平均增加X％。
- 如果您在发行中扔掉（隐藏）超过10个航班的航班，则购买的可能性将增加0.6％。
我必须马上说，我们不打算根据方法3和4替换结果中的数据，但我们将研究选择的真正因素。 A / B测试大约占网站受众的1％，而且时间严格限制。 从实验意义上讲，所有实验都是合乎道德的，它们可以使一个人解决问题并且不会向他隐藏重要数据，并且从中获得的收益有时应大于可能带来的不便。
市场反馈，例如：- 我们进行了输入时间表数据的验证。 现在，敌人将不会越过（即，承运人将无法无意间输入不切实际的路线的数据）。
- 他们为承运商提供了编辑时间表和航班的机会。 伙计们很高兴，我们的工作更少了:)
接下来-为喜欢细节的人提供简单语言的Jira卸载（实际上）。 任何补充和注释。 仅此而已。
总结
- 企业开始了解产品的潜力，这使得非常清楚地证实技术解决方案的预算成为可能。
- 开发人员开始提出新的想法，并查看功能的实现方式如何结束以及如何改变世界。
- 附近的团队向开发人员传达了一些问题的重要性，并迅速解决了这些问题。
- 其他团队从我们那里获得经验，并分享他们的经验和我们重复使用的代码。
- 用户感到满意（不人道实验所涉及的流量的1％除外）。
因此，我要告诉所有人产品内部正在发生的事情。 另外，出现了商业机密问题：报告很容易转发或四处翻阅，但我们信任我们的人民。 同样，数据在不同的市场参与者之间流动，如果您确实需要完全隐藏某些内容，则该报告将链接到内部资源，而内部资源已经具有附加的身份验证层。