Одна из замечательных особенностей участия в индустрии программного обеспечения сегодня заключается в том, что больше людей работает над более интересными проблемами, чем когда-либо прежде. Соответственно, существует больше программных сред, больше вариантов развертывания и больше вариантов инструментов, чем когда-либо прежде.
Таким образом, само собой разумеется, что создатели программных сред (инструменты тестирования, инструменты объектно-реляционного сопоставления, инструменты непрерывной интеграции, инструменты отслеживания дефектов и т. д.) сталкиваются с проблемой дифференциации друг от друга во все более тесном пространстве. В этой статье я буду использовать общее слово «фреймворк» для обозначения любых и всех этих ниш.
Я заметил эту проблему дифференциации, когда мы выбирали вспомогательное программное обеспечение для создания наших продуктов в IrisPR. Мы нашли простой пример при выборе шаблонизатора.
Дао шаблонизаторов
У меня было около четырех часов, чтобы сравнить и выбрать механизм шаблонов для использования в серверной части IrisPR. Для тех, кто не знаком с такими вещами: механизм шаблонов позволяет вам предоставлять некоторый «параметризованный» HTML и вводить в него настраиваемые данные, в результате чего получается полный HTML, пригодный для представления пользователю. Компании используют механизмы шаблонов для отправки исходящей электронной почты (вы знаете, «Уважаемый такой-то и такой-то, нажмите здесь, чтобы сбросить пароль…») и для продажи внешнего HTML-кода, среди множества других применений.
Шаблонизаторы — это товар. Все они делают одно и то же, но в разной степени. Для меня было полезно увидеть, как каждая структура представила свое ценностное предложение.
Одним из проверенных мной фреймворков был Thymeleaf. Вот снимок их домашней страницы на момент написания статьи.
Вы обратили внимание на содержание сообщения?
- Крутые люди используют его, так что это должно быть самым крутым.
- Бета 2 вышла, и видимо ее ждали долго.
- Он играет со Spring, предполагая, что читатель знает, что такое Spring.
- Он элегантен, по мнению его авторов.
Обратите внимание на специфическую терминологию диалекты и естественные шаблоны без априорного объяснения первого принципа. Затем, ниже, многословное объяснение его технической ценности, если кто-то дочитал до этого места. Много лишнего текста.
Thymeleaf, похоже, страдает от недуга, который очень распространен в технических структурах: они тратят слишком много энергии на сообщение «Что мы делаем» (WWD) вместо сообщения «Что в нем для меня» (WIIFM). «Я» в данном случае на самом деле я — потенциальный пользователь Thymeleaf. Это может быть отличный механизм шаблонов, но обмен сообщениями кажется несфокусированным и запутанным.
Сравните это с другим механизмом шаблонов под названием Handlebars. Первый текст на странице (на момент написания этой статьи) резюмирует их точку зрения:
Люди из Handlebars (даже производный проект Java), кажется, довольно четко понимают свое ценностное предложение: создавать шаблоны без разочарований. Хотя они делают предположения о своих пользователях (например, используют название проекта Mustache без окружающего контекста), сообщение очевидно. Они все о простоте принятия. Не случайно через час у меня был рабочий прототип.
Этот матч достался Handlebars, игнорируя более глубокие технические различия между ними и при всем уважении к вовлеченным командам разработчиков. Если бы у меня был более длительный временной горизонт для принятия решения, я мог бы принять другое решение, основанное на других критериях.
Здесь следует сделать интересное наблюдение.
А теперь проклятие
WTF это WIIFM? WIIFM исходит от наших друзей в мире продаж и маркетинга. Это все о общении таким образом, который резонирует с вашей целевой аудиторией. В простейшей форме WIIFM — это то, как вы рассказываете своим потенциальным пользователям, что вы можете для них сделать. Некоторые примеры:
- Пицца за тридцать минут или бесплатно.
- Механизм шаблонов HTML, который может быть интегрирован за 10 минут кем-то, у кого есть навыки работы с Java или JavaScript.
Обратите внимание, что сообщение не загрязняется тем, как сложно было достичь цели, насколько круто вы это считаете или трудностями интеграции. Эта информация может быть важной, но она важна только позже в процессе.
Просто, верно? Как и многие другие вещи в жизни, это сложнее, чем кажется.
Общение WIIFM может быть затруднено для технических сред. Это требует ясности в отношении предполагаемого использования (некоторые из которых могут быть неизвестны), хорошего понимания ценности фреймворка по сравнению с другими и ясного объяснения, которое находит отклик у потребителей фреймворка. Это требует контекстуального отделения важной информации от второстепенной. Это требует некоторого изучения конечного потребителя и того, что они считают расходной информацией.
Техническая природа программного обеспечения усугубляет это еще больше, потому что труднее смотреть на собственную работу с точки зрения человека, не вовлеченного в детали. Иногда это называют Проклятием знаний. Из википедии:
Проклятие знаний — это когнитивное искажение, из-за которого более информированным сторонам чрезвычайно трудно думать о проблемах с точки зрения менее информированных сторон.
Я могу идентифицировать себя с этой дилеммой, потому что я сам боролся с ней, и я видел, как многие другие команды также боролись с ней.
Вернемся к ВИИФМ. С точки зрения структуры, я думаю, что эффективная стратегия обмена сообщениями должна учитывать несколько важных моментов:
- Кто является предполагаемым потребителем фреймворка?
- Говоря языком потребителя фреймворка, какую конкретную болевую точку решает фреймворк?
- Чем этот фреймворк отличается от других фреймворков в той же нише?
- Как вашим потребителям следует адаптироваться к вашей платформе (например, необходимо ли пользователям платформы знакомиться с кодом?)
Резюме
Создание программного обеспечения — сложная задача. Обоюдоострый меч борьбы с этой сложностью связан с присущей ему сложностью чрезмерного усложнения вещей. Немного маркетингового мышления может помочь прояснить и дифференцировать вашу структуру.
