Спасибо за поддержку. Согласен, лиды бывают разные, и наверное предостерегу всех, что лично я имею некоторое представление о работе лида и текст в статье — это то, как я бы хотел работать со своими продактами.
Кстати думаю написать нечто подобное для лидов: как правильно управлять продактами в первые 3 месяца. Но пока не понимаю актуальна ли эта тема.
Лайкните этот коммент если чувствуете сложности при онбординге (как продакты так и лиды). Будет хоть какая-то аналитика)
Но обычно в корпоративной среде, обычным пользователям это мало интересно.
Наш опыт показывает противоположное: у нас много положительной обратной связи от обычных пользователей (doers). Но опять же, подчеркну, что эта статься не только про настройку интерфейса, а про возможности которые открываются, если вести разработку продукта таким образом.
Вы правы, в общем в этом направлении мы и пошли. Во второй части я расскажу о подходе и гипотезах, которые мы проверяли, а так же о том, что мерили как это отразилось на пользователях.
Можем копнуть глубже и вспомнить microsoft office, который еще в 98 версии позволял вынести нужные значки в быстрый доступ, а лишнее убрать
Я не претендую на уникальность разработки, скорее хочу подчеркнуть, что вижу ценность в том, чтобы софт был максимально полезен и не отвлекал людей от их основного рода деятельности. Люди любят свою работу, но случается, что процессы и софт вокруг приносят сплошное разочарование от процесса.
Отличное замечание! Примерно о подобном и пойдёт речь во второй части. Особенности мобильного телефона и рабочего стола в том, что пользователь сам настраивает себе окружение. Тут важно понимать, что система предлагает ему такую возможность.
Я понимаю ваши опасения, но как я писал выше, гибкость системы в руках её разработчиков. Если проектирование будет таким, что всё скачет перед глазами пользователя, то тут уж не вина концепции, а, как говорил мой преподавать, «кудрявые ручки».
Хочу отметить, что эта статья про размышления и без неё я не мог позволить себе говорить о практической части. Во второй части я расскажу что сделал, чтобы избежать подобных проблем с вайфаем.
Боюсь «мерзкая действительность» действительно существует.
Что же про ресурсы, то мы их на решение таких проблем не имеем. И да, сейчас мы придерживаемся схожего с вами мнения про удобство и не удобство одинаковых интерфейсов для разных пользователей.
Но это, кстати, решаемая проблема. Можно возложить настройку на пользователя. И это имеет сплошные плюсы. Все детали будут во второй статье.
Ваше замечание валидное. Подобное тоже приходило мне в голову, но такое поведение кажется уж очень сложным, то есть спроектировать систему таким образом логически не просто.
А вообще я думаю названия менять не стоит. За определённой функцией в системе спрятано определённое действие. Имя должно отображать суть этого действия. Если названия меняются, а функция остаётся прежней, то больше похоже на логическую ошибку.
В точку! В первое время мы столкнулись с зачатками этой проблемы, но об этом во второй части) Эта же про теорию и возможности.
Сразу скажу, что адекватный вариант решения тут один — зайти от лица пользователя (скажем access code какой-нибудь на один час). Но в любом случае при таком подходе требуется иметь очень грамотный штат тех. поддержки, которая будет в курсе работы принципов и механик настройки интерфейса
Согласен. Это вполне вписывается в эту концепцию. Так же добавлю, что как один из путей развития автоматической настройки интерфейсов можно подумать о accessibility. Скажем на входе в систему человек указывает свои возможности и интерфейс под них подстраивается. Но для меня эта история ещё только впереди)
Вы совершенно правы. Однако я сказал, что лишь определяю список на спринт, а не требую выполнения его полностью. В случае поддержки основного продукта мы понимаем, что важно всё, но это «всё» в один спринт поместить физически не можем. От того и появляется некоторая вариативность задач.
Цель статьи была рассказать про процессы в команде, а не мотивацию сотрудников. У нас в компании сотрудников ценят хорошо. Однако по опыту знаю, что после определённого количества нулей, человека больше начинают интересовать задачи, чем банковский счёт (хотя он тоже безусловно важен).
Если будут еще комментарии на тему мотивации, то обещаю написать статью на эту тему)
С лидом вариант рабочий, когда-то такое было, но в нашей команде не очень прижилось по трём причинам:
Первая банальна — лид сам любит покодить и заниматься только оценками + people менеджментом ему не в кайф (я немного утрирую, но думаю смысл передать удалось).
Оценка больших историй и их разбиение на маленькие вносит некоторое разнообразие в работу.
Линейные сотрудники приобретают опыт оценки и декомпозиции. А это полезно как с точки профессионального роста, так и для диверсификации рисков с лидом: отпуск, больничный, увольнение и т.п.
Добрый день. Появление любого новичка в команде откидывает её на стадию нормига или ниже. Однако в статье речь идёт в большей степени про организацию процессов, нежели про производительность каждого сотрудника. Для меня важно отметить, что это разные вещи и человек может быть хорошим командным игроком и это никак не пересекается с его профессиональным уровнем. Умение задавать вопросы, быть открытым, помогать другим — это то, до чего дотягивает его команда и позволяет сохранять предсказуемость работы на достойном уровне
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Спасибо за поддержку. Согласен, лиды бывают разные, и наверное предостерегу всех, что лично я имею некоторое представление о работе лида и текст в статье — это то, как я бы хотел работать со своими продактами.
Кстати думаю написать нечто подобное для лидов: как правильно управлять продактами в первые 3 месяца. Но пока не понимаю актуальна ли эта тема.
Лайкните этот коммент если чувствуете сложности при онбординге (как продакты так и лиды). Будет хоть какая-то аналитика)
Наш опыт показывает противоположное: у нас много положительной обратной связи от обычных пользователей (doers). Но опять же, подчеркну, что эта статься не только про настройку интерфейса, а про возможности которые открываются, если вести разработку продукта таким образом.
Можем копнуть глубже и вспомнить microsoft office, который еще в 98 версии позволял вынести нужные значки в быстрый доступ, а лишнее убрать
Я не претендую на уникальность разработки, скорее хочу подчеркнуть, что вижу ценность в том, чтобы софт был максимально полезен и не отвлекал людей от их основного рода деятельности. Люди любят свою работу, но случается, что процессы и софт вокруг приносят сплошное разочарование от процесса.
Хочу отметить, что эта статья про размышления и без неё я не мог позволить себе говорить о практической части. Во второй части я расскажу что сделал, чтобы избежать подобных проблем с вайфаем.
Что же про ресурсы, то мы их на решение таких проблем не имеем. И да, сейчас мы придерживаемся схожего с вами мнения про удобство и не удобство одинаковых интерфейсов для разных пользователей.
Но это, кстати, решаемая проблема. Можно возложить настройку на пользователя. И это имеет сплошные плюсы. Все детали будут во второй статье.
А вообще я думаю названия менять не стоит. За определённой функцией в системе спрятано определённое действие. Имя должно отображать суть этого действия. Если названия меняются, а функция остаётся прежней, то больше похоже на логическую ошибку.
Сразу скажу, что адекватный вариант решения тут один — зайти от лица пользователя (скажем access code какой-нибудь на один час). Но в любом случае при таком подходе требуется иметь очень грамотный штат тех. поддержки, которая будет в курсе работы принципов и механик настройки интерфейса
Если будут еще комментарии на тему мотивации, то обещаю написать статью на эту тему)