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