Лендинг продукта. Как описать платформу из N сервисов по JTBD
«Технической информации присуще качество, когда ею легко пользоваться, её легко понять и легко найти.»
— Gretchen Hargis, Michelle Carey и др., Developing Quality Technical Information (IBM Press)
В статье «README — это продукт» мы сделали так, чтобы каждый файл в репозитории сервиса знал своего потребителя. У README — четыре потребителя, и каждый нанимает его на свою работу.
В статье «Композиция корректности» мы показали, что корректность системы из N сервисов выводится из корректности каждого сервиса и совместимости их контрактов. Один сервис никому не нужен — нужна система.
И вот тут вылезает дыра. Сервис описан хорошо. А продукт — платформа из десяти, двадцати, ста сервисов — не описан нигде. У системы нет входной двери. Менеджер не понимает, что это за зверь. Новый потребитель не понимает, из каких кусков он состоит. ИИ-агент, которого позвали делать фичу на три сервиса, не понимает, с чего начать и куда писать план.
В этой статье вводим лендинг продукта — витрину платформы. Разберём: кто его нанимает, что в него писать (и чего не писать), как это делают в индустрии, и как кросс-сервисная фича стартует именно здесь. Плюс скиллы для слабой модели и мат-часть.
Сквозной живой пример — concept-репозиторий codemonstersteam/pinout: экосистема инструментов для проверки совместимости сервисов по их OpenAPI/AsyncAPI-спецификациям. Платформа из четырёх модулей, у которой есть та самая входная дверь. Удобно, что pinout построен по той же методологии рациональной разработки, что мы разбираем в серии (его модули стоят на service-template и компонентных тестах) — так что лендинг тут не выдуман под статью, а живёт в проде.
GL HF DD!