Дьявол кроется в деталях. Книга, как часто бывает, описывает нечто сферическое в вакууме. В реальном мире роль пользователя (не являющегося одновременно и заказчиком) не предполагает под собой самостоятельной генерации конечных требований. Когда менеджмент заключает контракт на разработку, кассир Вася напрямую в ТЗ не зашлёт в требования "подвинуть кнопку" даже если эти требования ничему не противоречат. Сначала БА согласует это с реальным заказчиком.
При этом можно, например, разрабатывать систему отчётности для менеджмента и тогда заказчики будут ещё и пользователями.
Примеры из реальной жизни - это правильно, я это приветствую. Вот для пояснения таких нюансов они и нужны.
Для написания юзер стори представить написание программ стори... Сложно!
Плюс пользователи не обязательно входят в подмножество клиентов. Собственно говоря, канонично клиентов называть заказчиками - тогда всё будет понятнее. В примере с продажей лотерейных билетов заказчиком является менеджмент компании, а пользователями кассиры. Заказчик принимает решение о том, что модуль нужен, генерирует требования и принимает результат. А пользователь - одна из категорий стейкхолдеров (заинтересованных лиц), которые могут быть зайдествованы при написании ТЗ и приёмочном тестировании.
Если подытожить, заказчики и пользователи могут перекрываться или совпадать полностью. Но в приведённом примере это не так.
Можно как минимум ответить, что "пускать всех под нож" не планируется. Это уже снизит напряжённость.
А вообще, каждый работает на своём уровне абстракции. Топ-менеджмент работает на уровне стратегии и уж на своём уровне-то должен понимать, что он будет делать. Случился ВНЕЗАПНЫЙ кризис? Стратегия может быть изменена - именно от неё дальше будут приниматься решения. А может стратегия останется прежней, но для следования ей нужно принять какие-то важные решения.
И вот о стратегии точно можно рассказать. К сожалению, зачастую считается, что стратегия и цели - это не то, чем стоит делиться с рядовыми работниками. И я вполне понимаю, почему это звоночек. Возможно потому, что сам это дважды проходил, в IT и не в IT.
Интересный пример из жизни, спасибо, хотя подача немного тенденциозная. такие инструменты, как Kaiten, действительно экономят много времени Основной момент, который помог ускорить решение запросов, это сортировка задач, поиск и отброс неактуального. больше 50% были неактуальными И уже дальше начинается приоритезация, классы сервисов, WIPы и т.п. Это как сказать, что у меня дома стало чище благодаря роботу-пылесосу, когда одновременно с эти я перестал ходить по квартире в уличной обуви. Подчеркну, что это не умаляет того факта, что внедрённые практики принесли пользу и вообще являются шагами в правильном направлении. Вопрос в акцентах. Ну и вот эти 56% неактуальных запросов - это же очевидно пользовательская боль. Может, где-то пользователи натыкаются на "не баг, а фичу", где-то просто путаются в UI, но тем не менее. На запросы в поддержку нужно смотреть не только с т.з. траты ресурсов саппорта на их разрешение, но и на потерянное время для пользователей. В общем, было бы здорово "в следующей серии" почитать про решение этой проблемы.
Нужно фокусироваться на ценности, а не на инструменте. Поэтому на данном этапе речь идёт об общем видении. Когда стратегия будет принята, пойдёт проработка на более низких уровнях абстракции, в какой-то момент это сведётся к выбору конкретных инструментов.
Микроменеджмент тоже хочет жить. Вот и ищет новые формы. В данном случае турникет на входе превратился в целых две группы. А человек, который это придумал, считает себя боженькой управления персоналом)
На одних подбадриваниях и спасибах мотивация команды далеко не уедет. Как быть с рутиной? Застывшим или уже даже безбожно устаревшим стеком? Отсутствием перспективы роста на конкретном проекте? Позитивные моменты безусловно нужны, но разрешают только самые простые ситуации.
Очень сильно вымывает мотивацию невозможность влиять. А ведь на долгих проектах команда часто срастается с продуктом, порой переживая на него больше заказчика. Но ты наёмный рабочий, знай своё место там в уголке.
В общем, вещи в статье сказаны правильно. Но это только первая из многих глав.
Мне кажется, автор немного смешал всё в кучу. Будто тесто замешал. Ба-дум-тсс.
Программирование интерфейса простое, понятное и увлекательное? Ну, тогда ты пишешь код по чёткому ТЗ/гайду/спеке, то да. А вот всё, что осталось за кадром, уже включает в себя сложности, непонятки и рутину.
Объединять весь процесс «родов» интерфейса под термином «программирование» вполне в духе приведённого в статье комично-снисходительного отношения к дизайнерам. Но на самом деле получается, что именно эти ребята будут тягать рояль, на котором «просто и увлекательно» будет играть программист.
Во-первых, насколько я понял, вопрос был условно анонимный. Вписывать свои реквизиты не требовалось, но аналитики могли узнать кто как проголосовал. Не самый этичный вариант, на мой взгляд.
Во-вторых, важную роль в интерпретации ответов играл фактор участия в прошлом опросе. Например, проблему работы с VDI заявило вдвое меньше респондентов. Может, проблема так и осталась не решена и пользователи не посчитали нужным вновь тратить время на то, чтобы заявлять о ней? Иными словами, у скольки пользователей она осталась не решена, сколько вновь столкнувшихся и сколько людей, ныне проблему не испытывающих?
В-третьих, вопрос: использовалось ли информирование респондентов об эффекте от первого опроса? Например «Год назад вы просили добавить живых растений в столовую и теперь там открылся зимний сад!». Всё-таки акцент на позитивном эффекте обратной связи видится мне хорошим стимулом к участию.
Яркая, броская упаковка продаёт. Это факт. Лого «Без ГМО» продаёт лучше указанного состава продукта без этого самого ГМО. Печально, но факт. Веб-дизайн вполне подчиняется этим правилам.
Я бы скорее поставил вопрос об уместности избыточного оформления. Сайт арт-фестиваля ещё можно снабдить скроллингом, обилием встроенного медиа-контента. А вот интернет-магазин, даже модной одежды, должен быть более утилитарным и менее отвлекающим от товара.
А почему решение такой частной задачи должно влиять на адресацию миллиардов других объектов?
Давайте подойдём ситуации с другой стороны. Курьеру нужно доставить посылку, он получает от диспетчера адрес. Что дальше? Если адрес хоть сколько-нибудь юзер френдли и в городе есть указатели на основе его системы, можно ехать по ним. Можно ввести адрес в навигатор адрес и он составит маршрут. В любом случае, самопонятных человеку адресов нет, цифровой адрес фундаментально ничего не решает, просто предлагает другую форму.
Пример с картой на конверте умилительный, но если дом стоит в чистом поле, вы именуете его как населённый пункт и присваиваете номер 1. Всё, проблема решена.
Начал писать длинный коммент о глубинных проблемах нынешней и предлагаемой адресации, а потом поймал себя на мысли. С чем связано большинство проблем нынещшней адресации? Недостаточно глубокая стандартизация, ошибки в заполнении форм. Решит ли, к примеру, цифровой адрес эту проблему? Нет. Более того, без спецсредств расшифровать его человеку станет ещё сложнее.
Нужно сокращать перечень наименований существующих объектов. Выкинуть всякие проезды, тупики и поселки при станции. Ввести пару универсальных наименований. И научить наконец людей правильно заполнять адресные формы. Для всех остальных — милости прошу использовать абонентские ящики.
Это нас приводит к фундаментальному вопросу: а что, собственно, хочет видеть пользователь? Если в приоритете состояние счёта — линия по точкам подойдёт. Если нужны приходы-расходы, то нужен Ваш второй график. А свечи…
Сколько пользователей знали о них, до появления Вашего решения? Сколько новых работников системы изначально знакомы с ними? Мне кажется, в данном случае это, к сожалению, свечи ради свечей. Да, они работают. Нет, это не оптимально.
Просто задайте себе вопрос: так ли хороши свечи, если под ними нужно рисовать дополнительный график, а для получения какой-либо информации кроме «плюс-минус» нужно наводить курсов? И чем в таком случае свечи отличаются от обычного графика по интервалам (дням), где прямые соединяли бы значение на начало и конец?
Насколько я понял, именно «табличного» вида в мобильной версии нет. Строки таблицы трансформированы в карточки. Соответственно, лента карточек и есть таблица.
Без фильтра (читай в режиме по умолчанию) логично было бы выводить все карточки, отсортированные по дате создания от новых к старым.
1. Не совсем понятно как сбросить настройки сортировки
2. Почему «Заявитель» сделан выпадающим списком, а «Статус» полем ввода? Первое лучше делать выпадающим списком с возможностью ручного ввода и автоподбора. Второе просто выпадающим. Нет?
3. Что происходит с шапкой страницы (заголовок, фильтры, сортировка) при прокрутке?
4. При длительной прокрутке, появляется ли икнока возврата к началу?
5. Я бы предложил другой формат карточки. Договора, накладные и многие другие документы имеют формат «Номер такой-то от даты такой-то». Поэтому сверху-слева я бы отобразил номер, под ним дату. Затем автора и только потом заголовок. Таким образом «техническая» информация будет сгруппирована в одной области. Это было бы больше похоже на привычные форматы: новость на сайте или письмо электронной почты.
6. При выдаче результатов сортировки можно рассмотреть вариант выделения ключевого параметра в карточке: маркером слева, изменением фона и т.п. Тогда всегда понятно, какие фильтры активны на данный момент.
Делать единообразные, загромождённые карточки карточки на основе шаблонов системы — правильное решение. Приятно видеть такой подход.
Как лёгкая обзорная статья - ок. Но как на SRE смотрит бизнес и разработка из неё не понятно 0_о
Дьявол кроется в деталях. Книга, как часто бывает, описывает нечто сферическое в вакууме. В реальном мире роль пользователя (не являющегося одновременно и заказчиком) не предполагает под собой самостоятельной генерации конечных требований. Когда менеджмент заключает контракт на разработку, кассир Вася напрямую в ТЗ не зашлёт в требования "подвинуть кнопку" даже если эти требования ничему не противоречат. Сначала БА согласует это с реальным заказчиком.
При этом можно, например, разрабатывать систему отчётности для менеджмента и тогда заказчики будут ещё и пользователями.
Примеры из реальной жизни - это правильно, я это приветствую. Вот для пояснения таких нюансов они и нужны.
Для написания юзер стори представить написание программ стори... Сложно!
Плюс пользователи не обязательно входят в подмножество клиентов. Собственно говоря, канонично клиентов называть заказчиками - тогда всё будет понятнее. В примере с продажей лотерейных билетов заказчиком является менеджмент компании, а пользователями кассиры. Заказчик принимает решение о том, что модуль нужен, генерирует требования и принимает результат. А пользователь - одна из категорий стейкхолдеров (заинтересованных лиц), которые могут быть зайдествованы при написании ТЗ и приёмочном тестировании.
Если подытожить, заказчики и пользователи могут перекрываться или совпадать полностью. Но в приведённом примере это не так.
Можно как минимум ответить, что "пускать всех под нож" не планируется. Это уже снизит напряжённость.
А вообще, каждый работает на своём уровне абстракции. Топ-менеджмент работает на уровне стратегии и уж на своём уровне-то должен понимать, что он будет делать. Случился ВНЕЗАПНЫЙ кризис? Стратегия может быть изменена - именно от неё дальше будут приниматься решения. А может стратегия останется прежней, но для следования ей нужно принять какие-то важные решения.
И вот о стратегии точно можно рассказать. К сожалению, зачастую считается, что стратегия и цели - это не то, чем стоит делиться с рядовыми работниками. И я вполне понимаю, почему это звоночек. Возможно потому, что сам это дважды проходил, в IT и не в IT.
Интересный пример из жизни, спасибо, хотя подача немного тенденциозная.
такие инструменты, как Kaiten, действительно экономят много времениОсновной момент, который помог ускорить решение запросов, это сортировка задач, поиск и отброс неактуального.
больше 50% были неактуальнымиИ уже дальше начинается приоритезация, классы сервисов, WIPы и т.п. Это как сказать, что у меня дома стало чище благодаря роботу-пылесосу, когда одновременно с эти я перестал ходить по квартире в уличной обуви.
Подчеркну, что это не умаляет того факта, что внедрённые практики принесли пользу и вообще являются шагами в правильном направлении. Вопрос в акцентах.
Ну и вот эти 56% неактуальных запросов - это же очевидно пользовательская боль. Может, где-то пользователи натыкаются на "не баг, а фичу", где-то просто путаются в UI, но тем не менее. На запросы в поддержку нужно смотреть не только с т.з. траты ресурсов саппорта на их разрешение, но и на потерянное время для пользователей. В общем, было бы здорово "в следующей серии" почитать про решение этой проблемы.
Нужно фокусироваться на ценности, а не на инструменте. Поэтому на данном этапе речь идёт об общем видении. Когда стратегия будет принята, пойдёт проработка на более низких уровнях абстракции, в какой-то момент это сведётся к выбору конкретных инструментов.
Мне это таким образом видится.
Было бы интересно услышать пример минимального по объёму/сложности работ проекту, где будут присутствовать все эти роли в выделенном виде.
Опыт индустрии говорит об обратном. Поэтому одна из базовых книг по теме называется "Не заставляйте меня думать".
Микроменеджмент тоже хочет жить. Вот и ищет новые формы. В данном случае турникет на входе превратился в целых две группы. А человек, который это придумал, считает себя боженькой управления персоналом)
Очень сильно вымывает мотивацию невозможность влиять. А ведь на долгих проектах команда часто срастается с продуктом, порой переживая на него больше заказчика. Но ты наёмный рабочий, знай своё место там в уголке.
В общем, вещи в статье сказаны правильно. Но это только первая из многих глав.
Программирование интерфейса простое, понятное и увлекательное? Ну, тогда ты пишешь код по чёткому ТЗ/гайду/спеке, то да. А вот всё, что осталось за кадром, уже включает в себя сложности, непонятки и рутину.
Объединять весь процесс «родов» интерфейса под термином «программирование» вполне в духе приведённого в статье комично-снисходительного отношения к дизайнерам. Но на самом деле получается, что именно эти ребята будут тягать рояль, на котором «просто и увлекательно» будет играть программист.
Во-вторых, важную роль в интерпретации ответов играл фактор участия в прошлом опросе. Например, проблему работы с VDI заявило вдвое меньше респондентов. Может, проблема так и осталась не решена и пользователи не посчитали нужным вновь тратить время на то, чтобы заявлять о ней? Иными словами, у скольки пользователей она осталась не решена, сколько вновь столкнувшихся и сколько людей, ныне проблему не испытывающих?
В-третьих, вопрос: использовалось ли информирование респондентов об эффекте от первого опроса? Например «Год назад вы просили добавить живых растений в столовую и теперь там открылся зимний сад!». Всё-таки акцент на позитивном эффекте обратной связи видится мне хорошим стимулом к участию.
Я бы скорее поставил вопрос об уместности избыточного оформления. Сайт арт-фестиваля ещё можно снабдить скроллингом, обилием встроенного медиа-контента. А вот интернет-магазин, даже модной одежды, должен быть более утилитарным и менее отвлекающим от товара.
Давайте подойдём ситуации с другой стороны. Курьеру нужно доставить посылку, он получает от диспетчера адрес. Что дальше? Если адрес хоть сколько-нибудь юзер френдли и в городе есть указатели на основе его системы, можно ехать по ним. Можно ввести адрес в навигатор адрес и он составит маршрут. В любом случае, самопонятных человеку адресов нет, цифровой адрес фундаментально ничего не решает, просто предлагает другую форму.
Пример с картой на конверте умилительный, но если дом стоит в чистом поле, вы именуете его как населённый пункт и присваиваете номер 1. Всё, проблема решена.
Нужно сокращать перечень наименований существующих объектов. Выкинуть всякие проезды, тупики и поселки при станции. Ввести пару универсальных наименований. И научить наконец людей правильно заполнять адресные формы. Для всех остальных — милости прошу использовать абонентские ящики.
Сколько пользователей знали о них, до появления Вашего решения? Сколько новых работников системы изначально знакомы с ними? Мне кажется, в данном случае это, к сожалению, свечи ради свечей. Да, они работают. Нет, это не оптимально.
Без фильтра (читай в режиме по умолчанию) логично было бы выводить все карточки, отсортированные по дате создания от новых к старым.
2. Почему «Заявитель» сделан выпадающим списком, а «Статус» полем ввода? Первое лучше делать выпадающим списком с возможностью ручного ввода и автоподбора. Второе просто выпадающим. Нет?
3. Что происходит с шапкой страницы (заголовок, фильтры, сортировка) при прокрутке?
4. При длительной прокрутке, появляется ли икнока возврата к началу?
5. Я бы предложил другой формат карточки. Договора, накладные и многие другие документы имеют формат «Номер такой-то от даты такой-то». Поэтому сверху-слева я бы отобразил номер, под ним дату. Затем автора и только потом заголовок. Таким образом «техническая» информация будет сгруппирована в одной области. Это было бы больше похоже на привычные форматы: новость на сайте или письмо электронной почты.
6. При выдаче результатов сортировки можно рассмотреть вариант выделения ключевого параметра в карточке: маркером слева, изменением фона и т.п. Тогда всегда понятно, какие фильтры активны на данный момент.
Делать единообразные, загромождённые карточки карточки на основе шаблонов системы — правильное решение. Приятно видеть такой подход.