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