Product owner (ч. 2)

Разработка бизнес приложений Лекция 4

В прошлой серии

• Заинтересованные лица (stakeholders)• Вижен• Персоны / Роли• Story Mapping (US)• Backlog

ДЕТАЛИЗАЦИЯ ТРЕБОВАНИЙUI design, test cases, оценка качества выполнения

Идеальная картина

• Если предметная область известна• Если реальные бизнес ценности понятны• Если команда самоорганизованная,

ответственная и высококвалифицированная• Если в команде есть аналитики, дизайнеры,

тестировщики• Если заказчик действительно принимает работу• То детализация требований – не нужна,

достаточно историй и общения

Начинаем с экранов интерфейса

• Особенно важно для веб приложений, но граница между веб и не веб стирается

• Глядя на сценарии использования прикидываем список экранов приложения– Хороший способ грубо оценить разработку

всего проекта• Более или менее сложные всплывающие

окна – тоже экран.

Навигация

• Список экранов необходимо упорядочить• В процессе можно выделить общие

элементы– Меню– Хэдер, футер

• Необходимо отметить основные (важнейшие пути навигации)– Но не все, что бы не переусложнять

Прототипы экранов

• Требования– Простые в разработке и изменении– Содержащие все функциональные элементы– Быть именно прототипами (четко понятными)

• Способы– Бумага / доска– Специальный софт

Два типа экранов и приложений

• Приложения (MS Office, google docs, facebook)– Основная цель – действие (или действия)– Скролл контента, управление на виду– Нужно определиться с основным (наиболее

частым) и оптимизировать, подчеркивать его.• Контент (lenta.ru, lib.ru, yandex.ru, …)– Скролл всей страницы– Больше места контенту, меньше управлению, хотя

оно тоже нужно, там где уместно

Некоторые принципы дизайна

• Пользователи – Не хотят думать / изучать продукт– Никогда не читают документацию– Спешат: не изучают экран, а просматривают

• Поэтому– Все пояснения – на экране, внутри приложения– 7+ / - 2 элементов, действий, блоков– Главное (частое) ВЫДЕЛЕНО, неважное убрано

– Все решения пользователя – д.б. осознанные!

И еще принципы дизайна

• Консистентность– По каждому вопросу нужно выработать принцип по

которому принято решение и придерживаться (ссылки / кнопки, печать в офисе)

– Каждый элемент должен отвечать на вопросы «Почему» и «Зачем» вплоть до бизнес требований

• Пользователь должен ощущать контроль– Отмена, undo– Информирование

• Максимальная защита от ошибок, – только один способ сделать что-то - правильный

О чем забывают

• Технические экраны– Регистрация, логин, управление паролем,

страницы ошибок• Обработка ошибок (вывод ошибок,

предупреждений, сообщений)• Административные экраны– Обновление контента (частота)

• Обратная связь, сбор статистики!

Типичные ошибки

• Универсальный интерфейс (Windows, Java, Apple, HTML)– Это утопия– Определитесь с платформой, форматом, размером– Если требуется несколько вариантов – нужно

запланировать на каждый – отдельный экран• Попытка запихать все что можно на один экран– Работы от этого становится не меньше – а больше

Test cases / Acceptance tests

• Для сценариев просмотра – чаще всего достаточно просто UI mockup

• Для сценариев редактирования этого может быть не достаточно для того, что бы конкретизировать. Поэтому пишут:– Как проверить (how to demo)– DoD (глобальный и частный)– Acceptance tests

ОЦЕНКА КАЧЕСТВА ПО

Главный критерий качества

• Удовлетворенность заказчика!–Клиент, в случае B2B–Потребитель в случае B2C–В общем смысле - рынок (деньги)

• И потом уже все остальное

ISO 9126 (ГОСТ Р ИСО / МЭК 9126-93, ГОСТ 28195)

Важнейшие вещи

• Соответствие функциональным требованиям• Безопасность• Тестируемость• Сложность (стоимость) поддержки и

изменения• Масштабируемость• Usability• Надежность (соответствие SLA)• Производительность и эффективность

Как измерить usability?

• Как измерить удобство использования?– Clicks / действие– Конверсия цели– Время просмотра– Лояльность– … GA (и существенно сложнее с offline apps)

• Абсолютные измерения ничего не дают– A / B тестирование– Usability тестирование (полноценное или не очень)

Надежность

• SLA – Service level agreement– Полная недоступность– Частичная недоступность– Uptime– Время восстановления после сбоя (авт. или нет)– Потеря данных

• Важно– Определиться с требованиями и стоимостью– SPoF – single point of failure– Холодный и горячий резерв

Производительность

• Для большей части систем (кроме потоковой обработки) наиболее важно время отклика (0,1с – идеал)

• Эффективность не так важна в эпоху бесплатного железа

• Scalability (горизонтальное) намного важнее эффективности– Оно же убирает SPoF

Стоимость поддержкиРазработано фичей

Время

Хорошо

Плохо

Как следить за сложностью

• Скорость команды (в US) не должна падать• Кол-во багов должно уменьшаться (около

нуля)– При следовании принципу fail fast и хорошо

настроенной системе сбора ошибок.– Не должно резко расти при разработке нового

функционала• Время полной сборки, тестов и готовности к

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

ИНСТРУМЕНТЫ ЭФФЕКТИВНОГО МЕНЕДЖЕРА (PO)

GTD

Email

• Empty inbox (http://inboxzero.com) • Outlook / Gmail• Всегда включен• Научитесь писать письма– http://www.proeticet.ru/1_delovoe_pismo.html

Инструменты (case средства )

• Word (серьезно)• Excel (www.planetaexcel.ru) • Хранилище документов (wiki)• Утилита управления проектами• Средства для прототипирования UI• Трекер задач для программистов

Demo

• Email (ActiveInbox)– Outlook / GTD + мониторинг ошибок

• Basecamp• Sharepoint (wiki)• Office (GDocs + Wiki)– Excel timing (project)– Спецификация (примеры)

• Balsamiq (+Axure, Visio), MindManager• Bug tracker + Wiki• Бумага

Главные умения PO

• Переводчик со здравым смыслом– Общаться с людьми– Слушать людей– Быть объективным– Уметь убеждать– Лидировать (проявлять инициативу)

• Целеустремленный лентяй– Как можно больше не делать

Читаем

• Джоел Спольски (JoelOnSoftware.com)– http://www.joelonsoftware.com/items/2009/03/09.html– http://www.joelonsoftware.com/articles/fog0000000036.html (4 части)– Переводы: http://local.joelonsoftware.com/wiki/Russian

• 37 Signals– Rework: Бизнес без предрассудков– Getting real

• Making things happen (Искусство управления IT проектами), Скотт Беркун

• Преодоление пропасти. Маркетинг и продажа хайтек-товаров массовому потребителю (Джеффри Мур)

Читаем (2)

• Дизайн– Веб-Дизайн

: книга Стива Круга или "не заставляйте меня думать!“– Web-дизайн. Удобство использования Web-сайтов– MIT Лекции: Human capabilities, Design princeples– Ководство

• Про личную эффективность– Как привести дела в порядок. Искусство продуктивности без стресса

(GTD), Скотт Ален– Дейл Карнеги, Как завоевывать друзей и оказывать влияние на людей– Кови, 7 навыков высокоэффективных людей

Темы для докладов

• AOP• MSF, Kanban / Lean• SCRUM: Team / ScrumMaster – подробнее

про процесс (DS, Retro, SprintPlan, Demo…)• Portfolio management, BMG (Alex Ostervald),

Scrum of Scrum

Лабы• Открытые данные

– http://www.apps4russia.ru/, http://apps4russia.reformal.ru/, http://data.worldbank.org/

• Готовое:– http://minenergo.gov.ru/activity/statistic/,http

://www.fms.gov.ru/about/ofstat/, http://www.federalspace.ru/main.php?id=10

• Повышенный балл:– Или наличие БД– Или наличие веб интерфейса– Индивидуальное задание (для тех, у кого уже есть что показать)

• Стажировка (Тестер / Разработчик)– MS: C#, MS MVC, MS SQL Server