Если вы внимательно понаблюдаете за повседневной работой технических студентов Сун Сяокай, вы обнаружите, что они любят говорить о слове «способность». Будь то при планировании системной архитектуры, проектировании технических решений, обсуждении проблем разработки или даже обзоре PRD, слово «возможности» будет постоянно появляться в их устах. В чем причина того, что это слово так часто встречается в общении партнеров по развитию?
Во-первых, что такое «емкость»?
Прежде чем подробно представить, что такое "способность", давайте сначала продадим ее, и я хочу представить вам еще одно слово - эпоха VUCA (эпоха Ука).
VUCA — это новое слово, состоящее из первых букв четырех слов, а именно: волатильность (изменчивость), неопределенность (неопределенность), сложность (сложность) и неоднозначность (неоднозначность). VUCA впервые появился в военных терминах, но теперь это слово все чаще и чаще встречается в нашей повседневной жизни, потому что люди считают, что эти четыре слова слишком соответствуют нашему нынешнему обществу и времени. Разве наша жизнь, работа, общество и эта эпоха стремительного развития не полны изменчивости, неопределенности, сложности и двусмысленности.
Возвращаясь к повседневной работе студентов технических специальностей, все будут удивлены, обнаружив, что требования, продуктовые решения, визуальные проекты, планы операций и даже технологии фреймворка, к которым мы привыкли, сервисы, на которые мы полагаемся, и инструменты промежуточного программного обеспечения, которые мы используем, полны Признаки VUCA. Так что тут очень хочется сказать моим однокурсникам-технарям (особенно тем, кто в стартап-компаниях, бизнес которых развивается с большой скоростью), не увлекайтесь "убийством ПРД без смены версии" или "убийством конструктора" приносить в жертву небу, если снова поменяете "версию UI" посреди брани или ссоры. Потому что, когда вы оглянетесь назад и пересмотрите, вы обнаружите, что вывод всех браней и ссор должен быть «изменить или изменить». Причина на самом деле очень проста.ВУЦА характерен для нашей эпохи.Если мы не подстраиваемся под него,а пытаемся сопротивляться ему всеми силами,это очень неэкономичная вещь,и часто ваши усилия становятся напрасными.
После стольких размышлений о VUCA пришло время ввести слово «емкость». Потому что мы обнаружили, что независимо от того, как быстро меняется направление компании, или количество мертвых предприятий, или рождение инновационных проектов один за другим, всегда есть некоторые вещи, которые относительно неизменны и могут быть ускорены нами. это "емкость". Это введение все еще может быть относительно абстрактным.Далее мы приведем два примера, которые могут дать вам некоторое представление:
1. С развитием бизнеса в компании появляется все больше и больше систем или приложений, и в каждой системе всегда должен быть процесс входа в систему. Вначале процесс входа в систему может быть независимым: система A имеет процесс входа (используя адрес электронной почты и пароль для входа), система B имеет процесс входа (используя динамический вход через SMS), а система C имеет процесс входа (используя вход в систему). имя+пароль+проверочный код логин). На этот раз мы нашли «способность», и процесс входа в систему — это «способность», которую нам нужно накопить. Поскольку процесс входа в систему может быть пронумерован, и как только определенная форма входа будет утверждена, ее можно будет быстро вывести в другие системы для использования (многократное использование), как показано на следующем рисунке:
2. Предприятия всегда разнообразны и сложны.Есть сценарий в бизнесе X, который необходимо уведомить по электронной почте руководителю для утверждения, есть сценарий в бизнесе Y, который должен уведомить о продажах по SMS о том, что клиент разместил заказа, и в бизнесе Z есть сценарий, который необходимо подтолкнуть, чтобы предоставить клиентам скидку. Срок действия купона подходит к концу. На этот раз мы снова нашли «способность». Центр уведомлений о сообщениях — это «способность», которую нам нужно накопить. Тот же образ мышления, что и в первом примере, потому что метод уведомления является фиксированным, и после того, как определенный метод уведомления о сообщении установлен, его можно быстро вывести в другие бизнес-сценарии (многократное использование), а затем эти возможности уведомления о сообщениях также могут быть используется в комбинации, как показано на следующем рисунке:
看了上述两个例子的介绍，很多技术的同学会觉得，这些不是很正常吗，在我们的公司里不就是这样设计的吗。举这两个例子，并不是想给各位介绍多么高深的技术方案，而是想把“能力“这个词讲透。因为”能力“的设计更像是一种思维模型，即”将抽象和稳定的向下沉，将多变和不确定的往上浮”。这个思维模型，无论是在接口编写、架构思考、技术方案设计甚至日常的生活工作中，都会起到很大的帮助，并且也是适应VUCA时代的有利技巧。
Во-вторых, ключевые точки дизайна «Возможность»
2.1 Различие между «бизнесом» и «возможностями»
很多刚毕业的同学或是工作经验尚浅的开发同学，在接到一个需求或任务时，往往会犯一个通病，是什么呢？就是不能很好的区分“业务“和”能力“。他们往往”只面向业务编程“，请注意，在这里提到的是”只面向业务编程“，重点是这个”只“字。好多开发同学一边听着产品经理描述需求和功能，一边脑子在飞快运转。需求评审结束，脑海里已经充满了表结构的设计和字段的含义了，要不是还没确定开发分支，都认为自己已经进入开发阶段了。这里有一句玩笑话”没有什么问题，是加一个接口或者加一张表不能解决的，如果有，那就加两个。“讲到这里，是不是会引起很多开发同学的会心一笑，这个阶段估计所有的程序员都经历过。
为什么我将这个问题总结为——不能很好的区分“业务“和”能力“呢。就像刚才提到的，其实关键是因为没有形成那样的思维模型，即”将抽象和稳定的向下沉，将多变和不确定的往上浮”。”业务“拥有的最多标签，就是易变的、模糊的、不确定的，这是”业务“天生就具备的特质。很多时候，运营同学也是边跑边摸索，还一边修正运营的战略战术，这个情况在创业公司中，就更加明显了。这时候如果技术同学在开发过程中不加思考，开发起功能来兵来将挡水来土掩，不停地加表不停地加接口，可想而知，如果长此以往结果将会多么可怕。这也是宋小菜业务高速发展了三年，我们犯过的错误，也给我们带来了长足的思考。举一个我们犯类似错误的例子：
因为业务发展快速，越来越多的角色被纳入到我们的业务链路当中，比如有“交易客户“、”供应商“、”司机”、”囤货商“等等。因为不同的项目组承接了对应的需求开发，所以设计出来的结果可想而知，只能用”非常贴近我们的业务“来形容了。后面遇到了什么问题呢，比如随着业务变化，用户的身份是会多样化的，比如有的用户可能既是”供应商“又是”司机“，有的用户身份既是”供应商“又是”囤货商“等等。这时候问题就来了，“我怎么知道他到底有几个身份呢？”、“有的身份需要能登录系统A，有的身份需要登录系统B和C，有的身份不需要登录我们的系统，到底要怎么控制呢？”
На самом деле, после того, как в нашей системе появятся две или три идентичности, в соответствии с только что введенным образом мышления, мы должны забить тревогу в наших сердцах: тонет, бизнес поднимается». Основываясь на абстракции бизнеса, мы ускорили «возможности» пользовательского центра, включая систему учетных записей, пользовательскую систему и систему идентификации, и экспортировали относительно абстрактные возможности расширения «атрибутов» и «меток» для поддержки высокоскоростных изменения бизнеса.
2.2 Не начинайте говорить о «способностях»
当开发的同学们慢慢理解了“能力”的作用和价值的之后，往往又会带来一个新的问题，那就是一开始就谈“能力”。“能力”并不是空想出来的，他一定是经过了一些业务形态的观察和抽象，才能被沉淀出来的。比如一上来就谈“我们先做一个库存中心，反正我们是电商模式，一定用的到的”、“这个时候就需要一个商品中心了，因为XX公司说他们有，我们业务有很多相似的地方，有个商品中心一定不会错的”等等。像商品中心、库存中心这些核心“能力”，一定不是这样出现的。
切记切记，“能力”不是凭空冥想出来的，也不是靠经验设计出来的。一定是贴合着具体的业务场景，不停的思考和抽象，在合适的实际沉淀下来的。又到了讲述宋小菜惨痛教训的时候了：
宋小菜前两年的业务，物流业务一直处于城际配送，比如从杭州城内的某个地，配送到杭州城内的目标站点。这时候我们做了一个统一的调度物流平台，想将其作为“能力“，输出给宋小菜所有的物流调度业务。现在回过头来看，只能怪当初太年轻了，看的业务太少了。之后我们物流的复杂情况，远远超出了当时的想象，比如我们接入了骨干物流，出现了从上游基地发货的业务；比如城内大车无法通行，必须先由大车倒给多辆小车的业务；比如一辆半挂车，先送杭州再送嘉兴最后送上海的跨城业务。当初设计的物流调度中心，根本承接不了这样多变和复杂的业务场景，而且就现在来看，当时的数据模型抽象都是有问题的。
所以，如果能意识到“能力下沉，业务上浮”这个设计思路，并明白他的价值和威力，只是第一步，千万不要跌入凭空冥想“能力“的坑，这样设计出来的”能力“，往往都只是雾里看花，只是美好的愿景而已。
3. Как нарастить «потенциал»
3.1 Накапливать «способности» в процессе проекта
Если вы решили, что какая-то способность особенно важна и хотите ее накопить, что делать дальше? Настроить специальную команду разработчиков, чтобы она усердно работала и производила быстро? Это конечно возможно, но по опыту стартапов такая модель часто нежелательна. Форма проекта, которую мы предпочитаем видеть, такова: рождение «возможностей» от 0 до 1 должно быть тесно связано с конкретным бизнесом J, и вывод в этот бизнес J с наивысшим приоритетом функциональных требований. Другие бизнес Q и бизнес K знают, что когда мы начнем производить «мощность» от 0 до 1, они обязательно будут выдвигать различные требования к производителю «мощности». В это время производителю «способности» необходимо иметь в сердце шкалу, потому что сейчас идет процесс рождения «способности» от 0 до 1, всех функциональных характеристик не удовлетворишь, да и не сможешь. даже судить ли эти потребности являются обоснованными или нет.. Таким образом, у нас есть ориентир: «емкость» составляет от 0 до 1, где подают только один бизнес. Каковы преимущества этого: 1. «способность» должна быть тесно связана с определенным бизнесом, с тем, чтобы избежать «способности» дизайнер, глядя на цветы в тумане, в случае окончательного «способность» не может служить даже сцены; 2. Только служить один бизнес-сценарий, который также позволяет избежать «возможностей» дизайнер аппетит слишком жестоким, чувствуя, что все потребности являются разумными, и все потребности должны быть удовлетворены, но в конце концов они становятся узким местом; 3. Дайте дизайнеру «возможностей» достаточно времени подумать. Поскольку первый бизнес успешно служил, это будет более эффективно помогать «возможностям» дизайнеру абстрагироваться и думать о «способности»;
3.2 Оптимизация «мощности» при реконструкции инфраструктуры
Самым сложным должно быть рождение «способности» от 0 до 1. Возможно, вам придется заблокировать некоторые задачи по разработке бизнес-требований или поговорить с другими о преимуществах «способности», пока они ее не узнают. Но рождение «мощности» часто является лишь началом Великого похода Красной Армии, и «мощность» необходимо постоянно повторять и наращивать. Откуда берутся эти повторяющиеся точки или точки, которые необходимо построить? Доступ из постоянного потока сценариев приложений. Пришло время ввести наш второй критерий: только те, кто обслуживал более трех бизнес-сценариев, действительно признаны «возможностями». Этот критерий заставляет разработчиков «возможностей» постоянно думать о природе бизнеса и абстрагироваться от истинной ценности «возможностей». Такие итерации часто устраиваются в некоторых инфраструктурных проектах, чтобы разработчики «возможностей» имели четкие цели и задачи по оптимизации «возможностей», за которые они несут ответственность.
4. Вывод
При общении с некоторыми друзьями по отрасли или одноклассниками, пришедшими на собеседование, они часто говорят о том, что «вы руководите центром XX, так знаете ли вы, зачем вам центр XX?», ответ часто звучит так: «Преподаватели архитектуры чувствуют, что им это нужно» или «Разве это не нормально, у других компаний это тоже есть». Если вы зададите мне этот вопрос, эта статья — мой ответ.
О том, как построить эффективную свежую B2B-платформу, потому что она содержит много контента и очень сложна, невозможно объяснить это в рамках одной статьи. Эта статья просто для того, чтобы почерпнуть некоторые идеи. Последующая будет разделена на несколько статей. описывается текущая ситуация в отрасли, бизнес-статус, обзор продуктов, построение технической команды, создание серверной технологической платформы, разработка интерфейса и другие аспекты.Мы раскроем основные продукты и технологические платформы, которые накопились в B2B поле уже более трех лет и надеюсь, что больше людей в отрасли смогут углубиться в понимание, избежать некоторых обходных путей, я надеюсь помочь всем, эта серия статей распространяется следующим образом (будет обновляться):
1,«Как создать эффективную свежую платформу B2B (часть 1 обмена технологиями B2B)»
2,«Как Song Xiaocai вышла на свежий рынок B2B (часть 2 обмена технологиями B2B)»
3.«Как итерировать продуктовую систему платформы Fresh B2B (часть 3 обмена технологиями B2B)»
4.Как создать эффективную техническую команду для Fresh B2B (часть 4 обмена технологиями B2B)
5.«Как построить свежую технологическую систему B2B от 0 до 1 (часть 5 обмена технологиями B2B)»
8,«Дизайн Сун Сяокай и размышления о« возможностях »(часть 8 обмена технологиями B2B)»
9,«Проектирование и обдумывание разделения услуг (часть 9 совместного использования технологий B2B)»