Дизайн продукта

Design is not just what it looks like and feels like. Design is how it works. - Steve Jobs

Дизайн - создание продукта, услуги или системы. Термин «Продукт» подразумевает, что создаваемое программное обеспечение содержит бизнес-ценность. Продукт может быть направлен как на внутреннего, так и на внешнего потребителя. Продуктом может отдельный сервис, потребителем которого является другой «Продукт».

Состояние «Владелец продукта» не правильно относить к конкретному человеку. В этом случае неявно подразумевается, что есть выделенный человек, который отвечает за продукт и команда, которой продукт безразличен. В такой постановке работы есть несколько негативных моментов:

  1. Необходимость постоянного микроменеджемента для распределения работ

  2. Постоянный контроль за командой

  3. Искусственно ограничивается потенциал участников команды (разработчик — только кодирует) и т.д.

С психологической точки зрения каждому члену команды следует быть «владельцем» создаваемого продукта. Это более эффективно для поиска и принятия правильных решений.

Этапы дизайна продукта

Очень легко приступить к выполнению задачи, если вам дается решение (бизнесом, руководителем или кем угодно). Не принимайтесь за решение, если вы не понимаете проблему. Поймите проблему, болевую точку процесса. Провалидируйте решение — решает ли оно проблему, устраняет ли болевую точку? Если нет, ищите другое решение. Если да, подумайте, какие еще решения проблемы возможны. Можно ли решить проблему иначе, альтернативным методом? В чем разница этих решений? Какое решение проще и дешевле?

  1. Понимание проблемы. Проекты инициируются различными сторонами. Как правило проекты инициируют заинтересованные лица для решения определенных проблем. Понимание ожидаемых результатов проекта, доступных ресурсов, времени и иных ограничений.

  2. Исследование пользователей. Продукты создаются для внутренних и внешних пользователей. Исследование пользователей, как они решают проблемы сейчас. Сбор количественных и качественных показателей процесса. Интервью.

  3. Мозговой штурм — трансляция результатов исследования в решение проблем.

  4. Проектирование взаимодействия. Составление задач пользователей и вариантов использования. Проектирование сущностей и их поведения.

  5. Проверка решения. Получение обратной связи по прототипу.

Приоритеты

Бизнес-цели, цели клиентов и функциональность - в этом порядке определяют дизайн продукта. Цели создания продукта:

  1. Решение проблем бизнеса / достижение бизнес-целей. Метрики: NPV, IRR, количество занятых сотрудников и т. д. Для решения проблем требуется понимание, что и в какой мере влияет на метрики.

  2. Решение проблем пользователей / достижение целей клиента. Пользователем может являться сам клиент (самообслуживание) / сотрудник банка может выступать в роли агента клиента, выполняющего его поручения. Как пользователи выполняют задачи. Какие проблемы пользователей, какие существуют болевые точки процесса? Как устранение данных проблем повлияет в целом на процесс?

Архитектура продуктов

Все программные продукты создаются по принципу «Lego». Программный продукт — это комбинация нескольких «кубиков», связанных между собой через API. При проектировании продукта может появляться функционал, который может быть использован и отдельно в будущем. В этом случае создаются новые независимые модули для будущих продуктов. Для описания возможностей модуля формируется документация API в техническом слое базы знаний проекта.

Правила построения сервис-ориентированной архитектуры

  1. Данные и функционал продукта предоставляются через его интерфейсы

  2. Продукты связываются между собой только через интерфейсы, прямой доступ к данным запрещается

  3. Технология реализации интерфейсов может быть разной: HTTP, процедуры, представления SQL.

Минимально жизнеспособный продукт

Минимально жизнеспособный продукт (minimum viable product, MVP) — продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями. Основная задача — получение обратной связи для формирования гипотез дальнейшего развития продукта

Назначение минимально жизнеспособного продукта

  1. Начать получать выгоду (пока продукт в разработке, он создает только расходы. Чем раньше продукт запускается, тем раньше он начинает приносить выгоду

  2. Получить обратную связь для улучшения продукта. Есть большая разница между тем, как мы думаем будут пользоваться продуктом и тем как пользователя реально будут им пользоваться.

Жизненный цикл продукта

Прототипирование

На ранних этапах разработки продукта создается прототип, наиболее «быстро и дешево» отражающий внешнее поведение проектируемой системы. В прототипах допустимы упрощения, «гвозди», позволяющие программе работать в определенных, «специфичных» условиях. Данный подход удобен потому, что в при создании программного продукта наиболее эффективен итеративный подход, когда вы что-то делаете, учитесь, и принимаете решения на основе нового опыта. Поэтому нет смысла делать слишком качественный прототип, учитывающий множество условий. Многое из этого будет переосмыслено и выброшено. Лучше делать минимально жизнеспособную версию и получать обратную связь.

Рефакторинг и технический долг

Не важно что вы делаете, снимаете ли вы фильм, проектируете ракету или создаете программное обеспечение, чем раньше вы поймете, что вам нужно внести изменения, тем дешевле, проще и быстрее они будут.

Технический долг — дополнительная «работа», возникающая в следствие применения решений «на скорую руку», выгодных в краткосрочном периоде.

Рефакторинг - процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы.

Как правило, в ходе разработки, особенно это касается прототипов, применяются «быстрые решения». Такие решения нужно отмечать в коде специальными ключевыми словами «FIXME», «TODO» для того, чтобы иметь возможность вернуться к этим вопросам в будущем.

Возможен «местный» и «полный рефакторинг» приложений. Неоценима помощь IDE, статической типизации и юнит-тестов в «местном» рефакторинге. Вы можете закончить короткую итерацию рефакторинга, не переписывая всего приложения и провести тесты, прежде чем перейти к следующей итерации. «Местный» рефакторинг позволяет держать контекст изменений в голове. Для того, чтобы не ломать основную ветку приложения при итеративном рефакторинге можно создать новую ветку в репозитории. Не стоит слишком долго жить в «ветке», чем дольше идет рефакторинг, тем сложнее слияние.

Тестирование

Проблемы тестирования сводятся к тому, что одни и те же тесты нужно проделывать несколько раз. Например, однажды протестированное ломается при исправлении очередной ошибки или рефакторинге приложения.

Решением может быть автоматизация тестирования.

Тестировщик пишет критерии приемки в виде готовых расчетов, написанных независимо по тем же бизнес-правилам, которыми оперирует инженер при разработке программного кода.

При написании критериев приемки тестировщик продумывает, какие крайние случаи ему нужно описать для того, чтобы максимально полно покрыть бизнес-правила и записывает данные решения в виде таблицы.

В ряде случаев может иметь смысл автоматизация создания тестов. В этом случае, тестировщик, проверяя очередной кейс в интерфейсе приложения имеет возможность отметить кейс как «пройденный» с записью результата в базу данных приложения. По данным отметкам возможна автоматическая генерация тестов.

Если автоматизация тестов не оправдана, инженер пишет тесты вручную по таблицам проверки, созданным тестировщиком.