Post #488

Про концепции продуктов. Для кино есть логлайн, для [ИТ-]продуктов есть формула, в которой отражены примерно похожие вещи. Состав концепции: * описание аудитории — для кого мы делаем продукт или решение? Это могут быть люди в определенной ситуации, или сотрудники с какой-то ролью, елси продукт внутренний. * задача, которую решают эти люди — чего они хотят или что им нужно делать по работе. * препятствие — что мешает им выполнять эту задачу * что мы для них делаем (какую систему создаем) * как они будут решать свою проблему, когда система будет готова * за счет чего проблема будет решена? (какое ключевое свойство нашего решения) Можно ещё добавить анализ альтернатив: в чем отличие от других способов решения и в чем выигрыш. В виде формулы это выглядит так: Для <описание аудитории>, которые хотят <описание задачи>, но не могут, потому что <описание препятствия>, мы делаем <тип решения>, которое поможет им <описание решения проблемы>, за счет того, что <ключевое свойство решения>. Примеры: "Для системных аналитиков, которые знают много отдельных техник, но не могут их сложить в единый процесс, потому что в книгах описаны отдельные свойства, нотации и инструменты, но не описана логика их применения, мы делаем курс по разработке требований, который помогает выстроить четкую последовательность действий за счет того, что дает последовательный алгоритм выявления требований и проектирования решения". Ладно, это шутка. Или нет. Вот очередной курс будет в конце октября. Давайте посмотрим пример ИТ-систем: "Для клиентов с открытыми брокерскими счетами, которые осуществляют мало операций, потому что не понимают, что им покупать, мы создаем сервис готовых стратегий, к которому можно будет подключиться, и в нём уже будут подобранные акции и облигации, стоп-ордеры и тейк-профиты, так что клиентам после присоединения к стратегии и делать ничего самим не придётся". "Для сотрудников подразделения KYC, которым нужно проверять действительность паспортов согласно требованиям 115-ФЗ, но они не могут это сейчас делать, потому что сервис МВД по проверке паспортов перестал работать, мы делаем интеграционное решение, которое позволит отправлять запрос через СМЭВ-4 в автоматическом режиме по ключевым событиям, что позволит сотрудникам не проверять паспорта вручную, а только мониторить этот процесс и получать оповещения о недействительности паспорта." "Для студентов, которые хотят проходить курсы от ведущих российских вузов, а не в своем, где препод толкает чушь, но не могут, потому что живут в других городах или не смогли в эти вузы поступить, мы делаем онлайн-платформу с открытыми курсами, где можно будет пройти курс и даже зачесть его в своем вузе." Зачем составлять концепцию? Как минимум, чтобы все согласились и были на одной волне. Концепция задает основных потребителей и ключевую функцию. Из неё следуют все остальные решения и приоритеты. Вот например, в последнем варианте реальная концепция была совсем другой: "Для администраций региональных вузов, которые хотят обеспечить высокое качество непрофильных курсов и выполнить показатели по числу сетевых программ, мы делаем платформу с онлайн-курсами, на которой вузы смогут заключать сетевые договоры, зачислять своих студентов на курсы и отслеживать их успеваемость" Чувствуете? Вообще всё другое: и целевая аудитория, и цель, и основные функции (вместо фокуса на удобстве обучения — фокус на удобстве заключения и администрирования договоров). Такую концепцию можно согласовывать с заказчиками, и дальше уже развивать и детализировать. Следующим шагом это всё превращается в развернутую таблицу, страницы на две, где кроме перечисленных выше параметров будет чуть более развернутое описание: как сейчас и как будет, измеримые показатели положительных изменений, сроки актуальности проекта и описание окружения (а то и первичный набросок архитектуры).