Испорченный телефон
Знаете, как осуществляется коммуникация? Мы обдумываем что-то, потом кодируем это в слова и фразы в соответствии с представлениями об сущностях и процессах. Передаем сообщения второй стороне через голос. В процессе разговора добавляется посторонний шум и различные технические потери (отвлекся, не услышал, перепутал). Вторая сторона – получатель декодирует информацию в обратную сторону. Но, внимание, словарь терминов может несколько отличаться, т к у каждого свой опыт, свои знания и свои модели.
На каждом из этапов возможны ошибки и это обычная история. Чем длиннее цепочка переноса информации, чем больше в неё включено лиц, тем больше ошибок происходит и тем сильнее накопленные ошибки усиливаются.
Во всех организациях есть та или иная степень иерархии. Часто бывает бизнес-процесс строится так, что информационные сообщения проходит кучу инстанции, чтобы попасть к адресату. Каждому менеджеру в иерархичной организации хочется быть важной прокладкой, обеспечивающей «надежное» взаимодействие, чтобы оградить кого-то от чего-то. От избытка информационного потока, лишней конфиденциальной информации, дополнительных оценочных данных… А если в процесс задействованы несколько организаций, все становится в разы хуже. Когда информация, пройдя несколько таких «точек демаркации», меняется кардинальным образом и утрачивает смысл.
За последние несколько лет постоянно экспериментирую с бизнес-процессами в разных местах. И пока не нашел универсального шаблона, который мог бы без изменений ложиться на любую, уже устоявшуюся структуру. Везде приходится работать и с процессами, и с ролями одновременно.
Все больше организационных структур тяготеют в сторону уплощения иерархии. Несмотря на децентрализацию, качество, а следовательно, и эффективность обмена информацией при этом растет. При правильных процессах уменьшаются и задержки получения информации заинтересованным адресатом.
@aheadofthepack
Знаете, как осуществляется коммуникация? Мы обдумываем что-то, потом кодируем это в слова и фразы в соответствии с представлениями об сущностях и процессах. Передаем сообщения второй стороне через голос. В процессе разговора добавляется посторонний шум и различные технические потери (отвлекся, не услышал, перепутал). Вторая сторона – получатель декодирует информацию в обратную сторону. Но, внимание, словарь терминов может несколько отличаться, т к у каждого свой опыт, свои знания и свои модели.
На каждом из этапов возможны ошибки и это обычная история. Чем длиннее цепочка переноса информации, чем больше в неё включено лиц, тем больше ошибок происходит и тем сильнее накопленные ошибки усиливаются.
Во всех организациях есть та или иная степень иерархии. Часто бывает бизнес-процесс строится так, что информационные сообщения проходит кучу инстанции, чтобы попасть к адресату. Каждому менеджеру в иерархичной организации хочется быть важной прокладкой, обеспечивающей «надежное» взаимодействие, чтобы оградить кого-то от чего-то. От избытка информационного потока, лишней конфиденциальной информации, дополнительных оценочных данных… А если в процесс задействованы несколько организаций, все становится в разы хуже. Когда информация, пройдя несколько таких «точек демаркации», меняется кардинальным образом и утрачивает смысл.
За последние несколько лет постоянно экспериментирую с бизнес-процессами в разных местах. И пока не нашел универсального шаблона, который мог бы без изменений ложиться на любую, уже устоявшуюся структуру. Везде приходится работать и с процессами, и с ролями одновременно.
Все больше организационных структур тяготеют в сторону уплощения иерархии. Несмотря на децентрализацию, качество, а следовательно, и эффективность обмена информацией при этом растет. При правильных процессах уменьшаются и задержки получения информации заинтересованным адресатом.
@aheadofthepack
Запуск процессов изменений
В проектных и продуктовых компаниях периодически нужно вводит новые процессы и управлять изменениями. То, что работало вчера, завтра может стать не подходящим. Есть два способа разработки и внедрения процессов:
🔸 Первый - «по классике», по сценарию сверху вниз, когда высшее руководство видит итоговую цель внедрения. Руководство само, либо с помощью бизнес-аналитика раскладывает все по полочкам и спускает по нисходящей на подчинённые структуры.
🔸 Второй, снизу вверх, когда менеджеры и тимлиды чувствуют проблемы и зная пути решения пытаются протолкнуть изменения начиная от своих рабочих групп наверх.
Высшее руководство обладает весьма ограниченным временным ресурсом, чтобы быть погруженным в процесс внедрения и доносить суть и основные цели до всех. При сценарии внедрения изменений сверху вниз информация и цели, проходя менеджерские уровни искажается и заглушается, может не учитывать важные факторы и контекст. Часто у рядовых сотрудников отсутствует полное понимаете почему процесс строится именно таким способом и почему от них хотят выполнения странных показателей. А это крайне важно. При таком подходе мотивация и вовлеченность промежуточных менеджеров и стоящих в конце цепочек исполнителей как правило минимальна, т к их слышат меньше всего. В результате получается либо что-то косое-кривое работающее со скрипом, либо вообще нововведения игнорируются или соблюдаются формально. Получается вроде единая, но кривая система. Да и продуктивность увеличивается незначительно, весь положительный эффект съедается издержками при внедрении.
Во втором сценарии в каждом уютном уголке компании идут независимые процессы улучшений. Устанавливаются свои процессы, внедряются свои инструменты и методы работы. Такой зоопарк тяжёл для систематизации и понимания занятого руководства. Оно как правило туда и не погружается, и не заимствует лучшие практики к себе, на уровень выше, не интегрирует положительные эффекты. Процесс проталкивания наверх средним менеджерским звеном слишком энергозатратный и встречает кучу сопротивлений: «Вы не первый с предложениями. Это уже не актуально для нас. Это не даст эффекта сейчас…» Но необходимые процессы внедряются независимо от формального согласования. В результате получается разрозненная компания с невнятным управлением, с сильной зависимостью от конкретных менеджеров подразделений, с непростой миграцией сотрудников внутри структур, и с зашаренными знаниями.
И тот и другой изолированный вариант ущербны. Совмещенный подход с учётом обоих направлений движения является разумным вариантом, который учитывает интересы всех сторон.
В течение многих лет я являлся сторонником KPI систем. Далеко не везде удавалось внедрить их изнутри организации и адаптировать все процессы. Тем более тяжело довести внедрение до стабильной стадии решив все противоречия и сопротивления. В последнее время интересуюсь и экспериментирую с OKR. Эта система более адаптивна к частым изменениям и более интересна для продуктовой разработки. Она хорошо дружит с обоими описанными сценариями. Заметил, что и внедрение этой системы проходит проще.
@aheadofthepack
В проектных и продуктовых компаниях периодически нужно вводит новые процессы и управлять изменениями. То, что работало вчера, завтра может стать не подходящим. Есть два способа разработки и внедрения процессов:
🔸 Первый - «по классике», по сценарию сверху вниз, когда высшее руководство видит итоговую цель внедрения. Руководство само, либо с помощью бизнес-аналитика раскладывает все по полочкам и спускает по нисходящей на подчинённые структуры.
🔸 Второй, снизу вверх, когда менеджеры и тимлиды чувствуют проблемы и зная пути решения пытаются протолкнуть изменения начиная от своих рабочих групп наверх.
Высшее руководство обладает весьма ограниченным временным ресурсом, чтобы быть погруженным в процесс внедрения и доносить суть и основные цели до всех. При сценарии внедрения изменений сверху вниз информация и цели, проходя менеджерские уровни искажается и заглушается, может не учитывать важные факторы и контекст. Часто у рядовых сотрудников отсутствует полное понимаете почему процесс строится именно таким способом и почему от них хотят выполнения странных показателей. А это крайне важно. При таком подходе мотивация и вовлеченность промежуточных менеджеров и стоящих в конце цепочек исполнителей как правило минимальна, т к их слышат меньше всего. В результате получается либо что-то косое-кривое работающее со скрипом, либо вообще нововведения игнорируются или соблюдаются формально. Получается вроде единая, но кривая система. Да и продуктивность увеличивается незначительно, весь положительный эффект съедается издержками при внедрении.
Во втором сценарии в каждом уютном уголке компании идут независимые процессы улучшений. Устанавливаются свои процессы, внедряются свои инструменты и методы работы. Такой зоопарк тяжёл для систематизации и понимания занятого руководства. Оно как правило туда и не погружается, и не заимствует лучшие практики к себе, на уровень выше, не интегрирует положительные эффекты. Процесс проталкивания наверх средним менеджерским звеном слишком энергозатратный и встречает кучу сопротивлений: «Вы не первый с предложениями. Это уже не актуально для нас. Это не даст эффекта сейчас…» Но необходимые процессы внедряются независимо от формального согласования. В результате получается разрозненная компания с невнятным управлением, с сильной зависимостью от конкретных менеджеров подразделений, с непростой миграцией сотрудников внутри структур, и с зашаренными знаниями.
И тот и другой изолированный вариант ущербны. Совмещенный подход с учётом обоих направлений движения является разумным вариантом, который учитывает интересы всех сторон.
В течение многих лет я являлся сторонником KPI систем. Далеко не везде удавалось внедрить их изнутри организации и адаптировать все процессы. Тем более тяжело довести внедрение до стабильной стадии решив все противоречия и сопротивления. В последнее время интересуюсь и экспериментирую с OKR. Эта система более адаптивна к частым изменениям и более интересна для продуктовой разработки. Она хорошо дружит с обоими описанными сценариями. Заметил, что и внедрение этой системы проходит проще.
@aheadofthepack
Не подходит, но брать надо!
Без чего не сделаешь продукт? Правильно - без команды.
В стартапах и малом бизнесе связанном с IT риски высоки. Не стоит к ним добавлять ещё и кадровые. Неэффективность могут позволить себе корпорации с большими финансовыми потоками, но не мелкие компании. Поэтому вопросу найма каждого специалиста стоит уделять повышенное внимание. Особенно на первых порах, когда часто идёт совмещение ролей и дополнение пробелов по командным компетенциям.
Ух, сколько раз приходилось слышать: «Надо взять хоть кого, заткнуть дыру, а там посмотрим. Да, этот человек не особо подходит, но надо дать ему шанс. Время не ждет».
Одни из самых дорогих ошибок случаются, когда нанимают не тех людей, не на те позиции, либо не могу нормально обучить, адаптировать и мотивировать. Увольнения получаются болезненными для обеих сторон. Поэтому даже есть простое правило: «Лучше не нанять нужного человека, чем нанять не того». Это правило спасало не раз и меня. Но гораздо лучше прорабатывать правильную систему. Не устану писать о пользе готовых моделей. Системность и стратегия при найме необходима. Она должна коррелировать и с общей стратегией развития компании.
В последнем марафоне @Analyst_maraphon несколько спикеров хорошо рассказали про матрицу компетенций и онбординг в системной аналитике. Общие правила легко экстраполируются на остальные направления: QA, программирование, дизайн, конструирование, техническая поддержка.
К найму можно подойти с тех же маркетинговых воронок. Можно лить бесконечный поток нерелевантных кандидатов, первых постучавшихся в двери. Адаптировать как получится: бросил в воду - дал доступ к репозиторию с кодом, как-нибудь новичок сам выплывет. Авось кто-нибудь да подойдет и удержится. Но это пустая трата денег и сил.
Что делать для большей эффективности?
🔸Сфокусироваться на свою целевую аудиторию по кадрам
🔸Определить оптимальные каналы найма
🔸Понимать, в какой момент, кто необходим больше всего для усиления команд
🔸«Просеивать» кандидатов через несколько разноплановых фильтров
🔸Стараться оптимизировать воронки на каждом из этапов найма, чтобы отыскать нужные самородки
🔸Повышать эффективность онбординга минимизируя затратный период адаптации
Вроде элементарно, но делают единицы
@aheadofthepack
Без чего не сделаешь продукт? Правильно - без команды.
В стартапах и малом бизнесе связанном с IT риски высоки. Не стоит к ним добавлять ещё и кадровые. Неэффективность могут позволить себе корпорации с большими финансовыми потоками, но не мелкие компании. Поэтому вопросу найма каждого специалиста стоит уделять повышенное внимание. Особенно на первых порах, когда часто идёт совмещение ролей и дополнение пробелов по командным компетенциям.
Ух, сколько раз приходилось слышать: «Надо взять хоть кого, заткнуть дыру, а там посмотрим. Да, этот человек не особо подходит, но надо дать ему шанс. Время не ждет».
Одни из самых дорогих ошибок случаются, когда нанимают не тех людей, не на те позиции, либо не могу нормально обучить, адаптировать и мотивировать. Увольнения получаются болезненными для обеих сторон. Поэтому даже есть простое правило: «Лучше не нанять нужного человека, чем нанять не того». Это правило спасало не раз и меня. Но гораздо лучше прорабатывать правильную систему. Не устану писать о пользе готовых моделей. Системность и стратегия при найме необходима. Она должна коррелировать и с общей стратегией развития компании.
В последнем марафоне @Analyst_maraphon несколько спикеров хорошо рассказали про матрицу компетенций и онбординг в системной аналитике. Общие правила легко экстраполируются на остальные направления: QA, программирование, дизайн, конструирование, техническая поддержка.
К найму можно подойти с тех же маркетинговых воронок. Можно лить бесконечный поток нерелевантных кандидатов, первых постучавшихся в двери. Адаптировать как получится: бросил в воду - дал доступ к репозиторию с кодом, как-нибудь новичок сам выплывет. Авось кто-нибудь да подойдет и удержится. Но это пустая трата денег и сил.
Что делать для большей эффективности?
🔸Сфокусироваться на свою целевую аудиторию по кадрам
🔸Определить оптимальные каналы найма
🔸Понимать, в какой момент, кто необходим больше всего для усиления команд
🔸«Просеивать» кандидатов через несколько разноплановых фильтров
🔸Стараться оптимизировать воронки на каждом из этапов найма, чтобы отыскать нужные самородки
🔸Повышать эффективность онбординга минимизируя затратный период адаптации
Вроде элементарно, но делают единицы
@aheadofthepack
Telegram
На шаг впереди
Польза должностной инструкции
В фирме появляется задача по разработке должностных инструкций. На одного из руководителей падает эта «почетная обязанность». Как вынести пользу из этой формальной задачи?
Для начала стоит озадачится вопросом какая преследуется…
В фирме появляется задача по разработке должностных инструкций. На одного из руководителей падает эта «почетная обязанность». Как вынести пользу из этой формальной задачи?
Для начала стоит озадачится вопросом какая преследуется…
Семь раз поверь один проверь
Так случилось, что не раз приходилось включаться в продуктовую разработку не в самом начале, а уже после первого рабочего прототипа. Когда уже заложена архитектурная канва и появился некоторый результат. Как правило работа начинается с изучения последних предпринятых шагов, с того, что уже есть.
Но время от времени приходится обращался к предпосылкам, чтобы понять первоначальные проблемы, для решения которых создавался продукт. Не всегда удаётся обнаружить кейсы применения и закрываемые ими боли. Чтобы воссоздать недостающее звено начинается археология с прошлыми анкетированиями и результатами интервью, чтобы заново переварить первичную информацию.
И почему-то уж не первый раз сталкиваюсь с ситуацией, когда этап исследования проблемы приходится проходить заново, либо дополнять. Ситуации всегда разные. Бывает все предыдущие собранные материалы канули в лету. Иногда интервью было без скрипта с результатом в виде разрозненных клочков описаний. В иных случаях скрипт был, но им не удалось воспользоваться, а отрывочная стенограмма респондента не отвечает на вопросы, представляя скорее поток сознания. И наиболее частая ситуация, когда выводы исследования упущены или никак не подкреплены статистикой.
В итоге прошлое проблемное интервью само превращается в проблему, которую придется решить, собрав все боли при его препарировании. Совсем нехорошо, когда разработка при этом ушла слишком далеко. Разворот может быть и не таким дешевым.
@aheadofthepack
Так случилось, что не раз приходилось включаться в продуктовую разработку не в самом начале, а уже после первого рабочего прототипа. Когда уже заложена архитектурная канва и появился некоторый результат. Как правило работа начинается с изучения последних предпринятых шагов, с того, что уже есть.
Но время от времени приходится обращался к предпосылкам, чтобы понять первоначальные проблемы, для решения которых создавался продукт. Не всегда удаётся обнаружить кейсы применения и закрываемые ими боли. Чтобы воссоздать недостающее звено начинается археология с прошлыми анкетированиями и результатами интервью, чтобы заново переварить первичную информацию.
И почему-то уж не первый раз сталкиваюсь с ситуацией, когда этап исследования проблемы приходится проходить заново, либо дополнять. Ситуации всегда разные. Бывает все предыдущие собранные материалы канули в лету. Иногда интервью было без скрипта с результатом в виде разрозненных клочков описаний. В иных случаях скрипт был, но им не удалось воспользоваться, а отрывочная стенограмма респондента не отвечает на вопросы, представляя скорее поток сознания. И наиболее частая ситуация, когда выводы исследования упущены или никак не подкреплены статистикой.
В итоге прошлое проблемное интервью само превращается в проблему, которую придется решить, собрав все боли при его препарировании. Совсем нехорошо, когда разработка при этом ушла слишком далеко. Разворот может быть и не таким дешевым.
@aheadofthepack
Маленькие UX респонденты не обманывают
Все родители знают, чтобы ребенок уснул нужно рассказывать сказки негромко и размеренно. Но иногда нет сил или времени на то, чтобы долго читать перед сном.
Уже пол года как у меня дома прописалась умная колонка одного из производителей. Пользуется ей в основном дочка дошкольного возраста, слушая сказки перед сном.
Но наша "умная" колонка вместо тихого, успокаивающего чтения иногда в ночи врубает звук на всю квартиру будя всех вокруг. Дочка возмущается, пытается снизить громкость голосовым управлением. Колонка не реагирует, она "в перегрузке". Ребенок кричит, думая что его не слышат. Но колонка не слушается и не снижает громкость. Дочка плачет.
Ребенок думает, что колонка должна работать как человек. Если громче крикнешь, то воздействие будет сильнее. Сколько не объяснял, что крик с данным алгоритмом не работает. В этом случае надо настраивать звук по другому, но она все равно забывает и расстраивается.
Нелегко переключаться между общением с людьми и неодушевленными объектами нашей жизни.
Голос один из самых естественных способов коммуникации и управления. Когда-то устройства которые нас окружают станут по настоящему человечными и начну улавливать тональность, соотносить желания людей с общим контекстом, и подстраиваться под индивидуальные особенности каждого человека.
Техническое дополнение
Цифровая фильтрация разностного сигнала штука сложная, не спорю. И выделить слабый сигнал - голос не просто. Все усложняется для малогабаритных железяк с дешевой электроникой и особенностями компоновки микрофонов и динамиков.
@aheadofthepack
Все родители знают, чтобы ребенок уснул нужно рассказывать сказки негромко и размеренно. Но иногда нет сил или времени на то, чтобы долго читать перед сном.
Уже пол года как у меня дома прописалась умная колонка одного из производителей. Пользуется ей в основном дочка дошкольного возраста, слушая сказки перед сном.
Но наша "умная" колонка вместо тихого, успокаивающего чтения иногда в ночи врубает звук на всю квартиру будя всех вокруг. Дочка возмущается, пытается снизить громкость голосовым управлением. Колонка не реагирует, она "в перегрузке". Ребенок кричит, думая что его не слышат. Но колонка не слушается и не снижает громкость. Дочка плачет.
Ребенок думает, что колонка должна работать как человек. Если громче крикнешь, то воздействие будет сильнее. Сколько не объяснял, что крик с данным алгоритмом не работает. В этом случае надо настраивать звук по другому, но она все равно забывает и расстраивается.
Нелегко переключаться между общением с людьми и неодушевленными объектами нашей жизни.
Голос один из самых естественных способов коммуникации и управления. Когда-то устройства которые нас окружают станут по настоящему человечными и начну улавливать тональность, соотносить желания людей с общим контекстом, и подстраиваться под индивидуальные особенности каждого человека.
Техническое дополнение
Цифровая фильтрация разностного сигнала штука сложная, не спорю. И выделить слабый сигнал - голос не просто. Все усложняется для малогабаритных железяк с дешевой электроникой и особенностями компоновки микрофонов и динамиков.
@aheadofthepack
«Вредный» технический долг
Продуктовая разработка и технический долг ходят рука об руку. Я еще не встречал ни одного продукта, где бы техдолг отсутствовал полностью. Хотя может быть такие и есть на кладбище продуктов? :)
По традиции начать стоит с плохого. Пара слов о «вредном», т е плохом техдолге. Вредный техдолг появляется чаще всего «случайно». Менеджеры иногда не особо понимают, откуда он взялся, почему так быстро вырос и как с ним теперь бороться. Поэтому его крайне сложно контролировать. Продуктовый Roadmap начинает разваливаться, а в проектном управление начинает пухнуть бюджет требуя больше ресурсов и начинают срываться дедлайны.
Самое простое - это отслеживать причины, из-за которых плохой техдолг может нарастать лавинообразно. Их как минимум несколько 👉 Далее
Предыдущие посты по теме
Полезный и вредный технический долг ч.1
Полезный и вредный технический долг ч.2
@aheadofthepack
Продуктовая разработка и технический долг ходят рука об руку. Я еще не встречал ни одного продукта, где бы техдолг отсутствовал полностью. Хотя может быть такие и есть на кладбище продуктов? :)
По традиции начать стоит с плохого. Пара слов о «вредном», т е плохом техдолге. Вредный техдолг появляется чаще всего «случайно». Менеджеры иногда не особо понимают, откуда он взялся, почему так быстро вырос и как с ним теперь бороться. Поэтому его крайне сложно контролировать. Продуктовый Roadmap начинает разваливаться, а в проектном управление начинает пухнуть бюджет требуя больше ресурсов и начинают срываться дедлайны.
Самое простое - это отслеживать причины, из-за которых плохой техдолг может нарастать лавинообразно. Их как минимум несколько 👉 Далее
Предыдущие посты по теме
Полезный и вредный технический долг ч.1
Полезный и вредный технический долг ч.2
@aheadofthepack
Teletype
«Вредный» технический долг
Я еще не встречал ни одного продукта, где бы технический долг отсутствовал полностью. Хотя может быть такие и есть на кладбище продуктов? :)
Про кофе. Нет, не про кофе.
В каждом айтишном офисе где-то в уголке стоит кофемашина. Такое место внутреннего притяжения и неформальной коммуникации команды. А ещё, это способ повысить тонус любимым напитком и работоспособность.
Однако даже на себе замечал, что поднятие тонуса - явление временное. Если нормально не выспался, конечно можно раскачать активность мозга на часик другой для проведения брейншторма, но работать по десять часов на кофеине не выйдет. Периоды активности будут сменяться периодами отката и вялости, которые могут быть даже более глубокими чем первые. В условном графике производительности получим что-то напоминающее гребенку. Вверх на кружке кофе, потом вниз, вверх на новой порции стимулирующего зелья, и снова вниз. В итоге средний уровень будет даже ниже, чем работа без стимуляторов. Уже вечером в полуубитом состоянии нужно еще доползти домой или до кровати :) если у вас удалёнка, чтобы повторить на следующий день новый цикл.
Так же и в бизнесе, если бежите марафон - развиваете бизнес или отдельный продукт. Постоянный хороший средний уровень эффективности будет лучше мощных рывков и глубоких расслаблений командной работы. Да, рывки в работе тоже случаются. Но их возникновение должно быть связано лишь с чрезвычайными внешними обстоятельствами, а не с желанием раскачать результативность в долгом марафоне.
Впрочем, то что я пишу не ново. Такие незамысловатые принципы используют и гибкие методологии в разработке: Scrum, Kanban и другие. Не стоит рвать и перерабатывать для получения локального выигрыша. Лучше найти правильный процесс, устранять препятствия и потери для медленного увеличения скорости и эффективности.
@aheadofthepack
В каждом айтишном офисе где-то в уголке стоит кофемашина. Такое место внутреннего притяжения и неформальной коммуникации команды. А ещё, это способ повысить тонус любимым напитком и работоспособность.
Однако даже на себе замечал, что поднятие тонуса - явление временное. Если нормально не выспался, конечно можно раскачать активность мозга на часик другой для проведения брейншторма, но работать по десять часов на кофеине не выйдет. Периоды активности будут сменяться периодами отката и вялости, которые могут быть даже более глубокими чем первые. В условном графике производительности получим что-то напоминающее гребенку. Вверх на кружке кофе, потом вниз, вверх на новой порции стимулирующего зелья, и снова вниз. В итоге средний уровень будет даже ниже, чем работа без стимуляторов. Уже вечером в полуубитом состоянии нужно еще доползти домой или до кровати :) если у вас удалёнка, чтобы повторить на следующий день новый цикл.
Так же и в бизнесе, если бежите марафон - развиваете бизнес или отдельный продукт. Постоянный хороший средний уровень эффективности будет лучше мощных рывков и глубоких расслаблений командной работы. Да, рывки в работе тоже случаются. Но их возникновение должно быть связано лишь с чрезвычайными внешними обстоятельствами, а не с желанием раскачать результативность в долгом марафоне.
Впрочем, то что я пишу не ново. Такие незамысловатые принципы используют и гибкие методологии в разработке: Scrum, Kanban и другие. Не стоит рвать и перерабатывать для получения локального выигрыша. Лучше найти правильный процесс, устранять препятствия и потери для медленного увеличения скорости и эффективности.
@aheadofthepack
Реализуемо или нет?
Когда прилетает новая идея реализовать новый продукт, прежде чем с рвением хвататься за работу, стоит рационально взвесить все аспекты, которые могу поставить эту реализацию по сомнения. Для такой быстрой оценки подойдет анализ рисков из проектного управления, часть стратегического SWOT-анализа, либо простенький чеклист. Например, можно прикинуть:
🔹 Сколько есть времени на реализацию MVP, и сколько на полнофункциональный продукт? Конкуренты есть всегда, даже если не прямые. И они вряд ли дремлют, если на рынке есть реальные возможности.
🔹 Как будет организовано финансирование и на сколько его хватит? На старте продукта некоторая резиновость бюджета и запас никогда не помешает. Если что-то может пойти не так, так и получится. А ещë будет то, что не удалось учесть.
🔹 Есть ли команда с требуемыми компетенциями и соответствующего уровня? Или хотя бы отлаженный процесс работы с аутсорсом. Если команда раньше такого не делала, время потраченное на обучение и хождение по граблям может быть критичным.
🔹 Есть ли понимание стеков технологий, на которых разрабатываются подобные продукты? Наличие внутренней экспертизы одна из сильнейших сторон, а вот её отсутствие - это явная угроза не всегда компенсируемая внешним консалтингом.
🔹 Как и когда будет масштабироваться продукт? Это особенно важно для продуктов содержащих аппатные решения в сочетании с предыдущим пунктом. Масштабирование может подразумевать количество подключений в единицу времени, количество устройств (или клиентов) в системе, и т п. А также предполагаемые вехи, осуществления кратного перехода.
🔹 Будет ли продукт с чем-то интегрироваться и как? Система состоящая из совокупности решений выходит на порядок сложнее, чем каждый элемент по отдельности.
🔹 Есть ли решение для непрерывного тестирования релизов продукта и какая инфраструктура для этого понадобится? Да, про QA стоит думать уже на старте. Немало продуктов провалилось из-за отсутствия контроля за качеством.
🔹 Затронет ли продукт области действия каких-либо регуляторов или важных стандартов соответствия? Получить запрет на этапе внедрения будет самым тяжелым ударом.
Не обязательно скурпулезно прорабатывать все, но держать на виду этот перечень все же стоит для периодического обсуждения с командой разработки.
@aheadofthepack
Когда прилетает новая идея реализовать новый продукт, прежде чем с рвением хвататься за работу, стоит рационально взвесить все аспекты, которые могу поставить эту реализацию по сомнения. Для такой быстрой оценки подойдет анализ рисков из проектного управления, часть стратегического SWOT-анализа, либо простенький чеклист. Например, можно прикинуть:
🔹 Сколько есть времени на реализацию MVP, и сколько на полнофункциональный продукт? Конкуренты есть всегда, даже если не прямые. И они вряд ли дремлют, если на рынке есть реальные возможности.
🔹 Как будет организовано финансирование и на сколько его хватит? На старте продукта некоторая резиновость бюджета и запас никогда не помешает. Если что-то может пойти не так, так и получится. А ещë будет то, что не удалось учесть.
🔹 Есть ли команда с требуемыми компетенциями и соответствующего уровня? Или хотя бы отлаженный процесс работы с аутсорсом. Если команда раньше такого не делала, время потраченное на обучение и хождение по граблям может быть критичным.
🔹 Есть ли понимание стеков технологий, на которых разрабатываются подобные продукты? Наличие внутренней экспертизы одна из сильнейших сторон, а вот её отсутствие - это явная угроза не всегда компенсируемая внешним консалтингом.
🔹 Как и когда будет масштабироваться продукт? Это особенно важно для продуктов содержащих аппатные решения в сочетании с предыдущим пунктом. Масштабирование может подразумевать количество подключений в единицу времени, количество устройств (или клиентов) в системе, и т п. А также предполагаемые вехи, осуществления кратного перехода.
🔹 Будет ли продукт с чем-то интегрироваться и как? Система состоящая из совокупности решений выходит на порядок сложнее, чем каждый элемент по отдельности.
🔹 Есть ли решение для непрерывного тестирования релизов продукта и какая инфраструктура для этого понадобится? Да, про QA стоит думать уже на старте. Немало продуктов провалилось из-за отсутствия контроля за качеством.
🔹 Затронет ли продукт области действия каких-либо регуляторов или важных стандартов соответствия? Получить запрет на этапе внедрения будет самым тяжелым ударом.
Не обязательно скурпулезно прорабатывать все, но держать на виду этот перечень все же стоит для периодического обсуждения с командой разработки.
@aheadofthepack
Telegram
На шаг впереди
SWOT-анализ кратко описан даже в Википедии. Поэтому есть смысл раскрыть лишь некоторые нюансы.
Очень часто SWOT используется как инструмент фиксации текущего состояния для построения стратегии компании, а также в разработке новых продуктов и сервисов. Выглядит…
Очень часто SWOT используется как инструмент фиксации текущего состояния для построения стратегии компании, а также в разработке новых продуктов и сервисов. Выглядит…
📚Данные: визуализируй, расскажи, используй
Не часто пишу рекомендации по прочитанным книгам. Это стоит исправить. Недавно прочел купленную еще в прошлом году книгу «Данные: визуализируй, расскажи, используй», автор Коул Нассбаумер Нафлик.
Периодически сталкивался и сталкиваюсь с решением задачи визуализации данных через различные дашборды. Чаще всего задачи касались прикладной области - помощи в принятии операционных управленческих решений (для себя и для других менеджеров) внутри небольших компании. Такие задачки непритязательны к выбору средства отображения и презентабельности конечного результата. Главное, чтобы работало и не глючило.
Совсем иной результат хочется получить, когда работаешь над внешним продуктом, для конкурентного рынка. И тут больше сталкиваешься не с задачей выбора инструментов, которых сейчас масса, а более с общими проблемами по UХ.
Отдельно стоит отметить мой факап. Когда ехал в отпуск, взял книжную библиотечку только в электронном виде на черно-белой читалке. 😂 Пришлось потом еще повторно перечитывать эту книжку местами.
Итак, какие же полезные мысли можно прочитать в книге?
🔹 Потребность пользователя как всегда первична. Перед решением любой задачи по визуализации необходимо поработать над контекстом. Кто ваша целевая аудитория? Что должны узнать или сделать ваши слушатели? Как использовать данные, чтобы добиться цели?
🔹 Слишком много инструментов (типов диаграмм) дают возможность дизайнеру делать совершенно неудобоваримые мозгодробительные интерфейсы. Подбор правильного, а точнее эффективного инструмента зависит от типа данных, которых хотим визуализировать.
🔹 Чем проще, тем лучше. Избавляйтесь от информационного мусора на графиках. Для изучения того, как пользователь воспринимает информацию, подходят принципы гештальта. Они дают некий минимальный набор правил чтобы выделить, отсечь и выкинуть лишнее, оставив самую ценную информацию.
🔹 Не стоит забывать механику работы зрения и памяти любого человека, увидевшего прямоугольный экран. Где будет расположен фокус его внимания? Как с помощью правильной работы с атрибутами, привлекающими внимание, такими как размеры, форма, направление, пропорции, цвет и другие сфокусировать внимание пользователя?
🔹 Как с помощью сторитейлинга можно управлять вовлеченностью аудитории. Конечно, уроки сторитейлинга больше применимы для построения захватывающих презентаций, чем в разработке дашбордов.
Настоятельно рекомендую к прочтению всем, кто проектирует UI дашбордов, а также тем, кто работает над различными презентациями.
@aheadofthepack
Не часто пишу рекомендации по прочитанным книгам. Это стоит исправить. Недавно прочел купленную еще в прошлом году книгу «Данные: визуализируй, расскажи, используй», автор Коул Нассбаумер Нафлик.
Периодически сталкивался и сталкиваюсь с решением задачи визуализации данных через различные дашборды. Чаще всего задачи касались прикладной области - помощи в принятии операционных управленческих решений (для себя и для других менеджеров) внутри небольших компании. Такие задачки непритязательны к выбору средства отображения и презентабельности конечного результата. Главное, чтобы работало и не глючило.
Совсем иной результат хочется получить, когда работаешь над внешним продуктом, для конкурентного рынка. И тут больше сталкиваешься не с задачей выбора инструментов, которых сейчас масса, а более с общими проблемами по UХ.
Отдельно стоит отметить мой факап. Когда ехал в отпуск, взял книжную библиотечку только в электронном виде на черно-белой читалке. 😂 Пришлось потом еще повторно перечитывать эту книжку местами.
Итак, какие же полезные мысли можно прочитать в книге?
🔹 Потребность пользователя как всегда первична. Перед решением любой задачи по визуализации необходимо поработать над контекстом. Кто ваша целевая аудитория? Что должны узнать или сделать ваши слушатели? Как использовать данные, чтобы добиться цели?
🔹 Слишком много инструментов (типов диаграмм) дают возможность дизайнеру делать совершенно неудобоваримые мозгодробительные интерфейсы. Подбор правильного, а точнее эффективного инструмента зависит от типа данных, которых хотим визуализировать.
🔹 Чем проще, тем лучше. Избавляйтесь от информационного мусора на графиках. Для изучения того, как пользователь воспринимает информацию, подходят принципы гештальта. Они дают некий минимальный набор правил чтобы выделить, отсечь и выкинуть лишнее, оставив самую ценную информацию.
🔹 Не стоит забывать механику работы зрения и памяти любого человека, увидевшего прямоугольный экран. Где будет расположен фокус его внимания? Как с помощью правильной работы с атрибутами, привлекающими внимание, такими как размеры, форма, направление, пропорции, цвет и другие сфокусировать внимание пользователя?
🔹 Как с помощью сторитейлинга можно управлять вовлеченностью аудитории. Конечно, уроки сторитейлинга больше применимы для построения захватывающих презентаций, чем в разработке дашбордов.
Настоятельно рекомендую к прочтению всем, кто проектирует UI дашбордов, а также тем, кто работает над различными презентациями.
@aheadofthepack
T-shaped специалисты в продуктовых командах
Идеи значимости T-shaped специалистов с углублёнными знаниями в области одной специализации и широким кругозором в остальных продвигаются достаточно давно. Однако, если открыть сайт с вакансиями, я нахожу в основной описания обычных рафинированных узкопрофильных I-shaped спецов. Какой же вариант лучше? Считаю, что для продуктовой разработки особенно на первоначальных этапах жизненно необходимы именно Т-shaped. Вот несколько аргументов о преимуществах таких команд.
🔸Для запуска продукта важна эффективность процесса разработки. И это прежде всего компактная команда с минимальным количеством участников. Они делят и совмещают между собой множество ролей в том числе и технических (по специализациям). Раздувать команду просто нерентабельно, если можно обойтись Т-shaped спецами.
🔸С учётом фактора автобуса и риск-менеджмента важна заменимость участников. Люди болеют, уходят в отпуска, да и переход на другую работу тоже случается. Для непрерывности процессов нужны горячие замены людям, уже погруженным в продукт. Ну, выбыл Вася на месяц по любой из причин. Ничего страшного, релизы не остановились. Остальные смогли подхватить «выпавшее знамя».
🔸Другим значительным преимуществом T-shaped команд будет Time to market. Скорость выхода продукта и каждой его инкременты — это конкурентное преимущество. Узкое горлышко - переход процесса из одной функциональной группы в другую становится барьером дальнейших оптимизации по времени. К примеру, релиз готов, пора тестировать. Но тестировщики заняты в других проектах, а время уходит, пока произойдут нужные переключения. На моей памяти T-shaped команды помогали проводить регрессионное тестирование тестировщику за часы в конце итерации. Примерно в таких же условиях команды с четким функциональным разделением провозились один, второй, да и третий день после перекидывания мячика.
🔸В T-shaped командах развиты не только хард, но и междисциплинарные софт скилы. К примеру, такие как эмпатия. Это даёт преимущество командам в генерации новых идей при мозговых штурмах, и в прототипировании. Также эмпатия и активное слушание помогает в обычных agile-процессах - совместном планирование, ретроспективе. Любой участник будет включаться в обсуждение, в том числе и «не своих задач».
T-shaped - это не просто отдельно подобранные люди, это специальный подход к управлению компетенциями продуктовой команды. В нем сама атмосфера работы способствует развитию дополнительных навыков через перекрестное обучение.
Тему T-shaped специалистов мы договорились охватить каждый со своего видения с Никитой Хромушкиным. В его канале Product Developer, который я читаю и нахожу очень полезным, сегодня должен появиться пост. Пойду, посмотрю, 👉что написал Никита.
Идеи значимости T-shaped специалистов с углублёнными знаниями в области одной специализации и широким кругозором в остальных продвигаются достаточно давно. Однако, если открыть сайт с вакансиями, я нахожу в основной описания обычных рафинированных узкопрофильных I-shaped спецов. Какой же вариант лучше? Считаю, что для продуктовой разработки особенно на первоначальных этапах жизненно необходимы именно Т-shaped. Вот несколько аргументов о преимуществах таких команд.
🔸Для запуска продукта важна эффективность процесса разработки. И это прежде всего компактная команда с минимальным количеством участников. Они делят и совмещают между собой множество ролей в том числе и технических (по специализациям). Раздувать команду просто нерентабельно, если можно обойтись Т-shaped спецами.
🔸С учётом фактора автобуса и риск-менеджмента важна заменимость участников. Люди болеют, уходят в отпуска, да и переход на другую работу тоже случается. Для непрерывности процессов нужны горячие замены людям, уже погруженным в продукт. Ну, выбыл Вася на месяц по любой из причин. Ничего страшного, релизы не остановились. Остальные смогли подхватить «выпавшее знамя».
🔸Другим значительным преимуществом T-shaped команд будет Time to market. Скорость выхода продукта и каждой его инкременты — это конкурентное преимущество. Узкое горлышко - переход процесса из одной функциональной группы в другую становится барьером дальнейших оптимизации по времени. К примеру, релиз готов, пора тестировать. Но тестировщики заняты в других проектах, а время уходит, пока произойдут нужные переключения. На моей памяти T-shaped команды помогали проводить регрессионное тестирование тестировщику за часы в конце итерации. Примерно в таких же условиях команды с четким функциональным разделением провозились один, второй, да и третий день после перекидывания мячика.
🔸В T-shaped командах развиты не только хард, но и междисциплинарные софт скилы. К примеру, такие как эмпатия. Это даёт преимущество командам в генерации новых идей при мозговых штурмах, и в прототипировании. Также эмпатия и активное слушание помогает в обычных agile-процессах - совместном планирование, ретроспективе. Любой участник будет включаться в обсуждение, в том числе и «не своих задач».
T-shaped - это не просто отдельно подобранные люди, это специальный подход к управлению компетенциями продуктовой команды. В нем сама атмосфера работы способствует развитию дополнительных навыков через перекрестное обучение.
Тему T-shaped специалистов мы договорились охватить каждый со своего видения с Никитой Хромушкиным. В его канале Product Developer, который я читаю и нахожу очень полезным, сегодня должен появиться пост. Пойду, посмотрю, 👉что написал Никита.
Telegram
Product Developer
Lagom T-Shape
На днях говорил с коллегой, он поделился своим затруднением:
«Вот я изучаю какую-то технологию, но мне всё кажется что недостаточно глубоко, и не могу остановиться. А еще репетитор по джаве говорил мне, что Т-Shape — фигня, а фуллстек разрабы…
На днях говорил с коллегой, он поделился своим затруднением:
«Вот я изучаю какую-то технологию, но мне всё кажется что недостаточно глубоко, и не могу остановиться. А еще репетитор по джаве говорил мне, что Т-Shape — фигня, а фуллстек разрабы…
Маленькие детки – маленькие бедки. О небольших GUI
Много лет назад разрабатывали мобильные устройства с небольшими экранами. Небольшими не в размерах диагонали, а в разрешении. Оно было, как сейчас помню, 320х240 пикселей. На тот момент это было современное решение. Но оно конечно далеко от разрешения современных смартфонов, где можно разгуляться с UX-излишествами. На таком дисплее сильно-то не разбежишься, ни длинного текста в поля не впихнуть, ни стильной графики не нарисовать. Сплошная пиксельная графика как для шрифтов, так и для объектов, иконок и изображений.
Проблема лежит на поверхности. Наделаешь сокращений в текстах, намельчишь в интерфейсе - получишь непонимание и боль у пользователей. Кто-то с грустью залезет и зароется в толстый мануал. Кто-то начнет терроризировать техподдержку. А кто-то накляузничает ЛПРу, чтобы больше такого не закупали и посмотрели в сторону ближайших конкурентов. В B2B не просто.
Борьба с текстами в крохотном интерфейсе была долгой и кровопролитной, бывало, до каждой буквы. Особенно почертыхаться пришлось с немецкой локализацией. Слова и фразы в переводе совершенно не влезали ни в какие нужные места интерфейса. Так или иначе, проблему мы с командой все-таки забороли. Даже наши немецкие коллеги на удивление не стали нас линчевать по чем зря.
Технологии постоянно бегут вперед. Однако, похожие задачки у моих коллег по цеху (встроенные системы) я постоянно подмечаю и на сей день.
Поэтому для меня совершенно не удивительно, что наконец-то начинают появляться специальные люди – UX-писатели. Они как раз и занимаются правильной разработкой и адаптацией такого типа информации. Что раньше было в диковинку, разделение специалистов на такую узкую специализацию, сейчас становится в порядке вещей. Не страшно, если это всего лишь роль в небольшой команде.
@aheadofthepack
Много лет назад разрабатывали мобильные устройства с небольшими экранами. Небольшими не в размерах диагонали, а в разрешении. Оно было, как сейчас помню, 320х240 пикселей. На тот момент это было современное решение. Но оно конечно далеко от разрешения современных смартфонов, где можно разгуляться с UX-излишествами. На таком дисплее сильно-то не разбежишься, ни длинного текста в поля не впихнуть, ни стильной графики не нарисовать. Сплошная пиксельная графика как для шрифтов, так и для объектов, иконок и изображений.
Проблема лежит на поверхности. Наделаешь сокращений в текстах, намельчишь в интерфейсе - получишь непонимание и боль у пользователей. Кто-то с грустью залезет и зароется в толстый мануал. Кто-то начнет терроризировать техподдержку. А кто-то накляузничает ЛПРу, чтобы больше такого не закупали и посмотрели в сторону ближайших конкурентов. В B2B не просто.
Борьба с текстами в крохотном интерфейсе была долгой и кровопролитной, бывало, до каждой буквы. Особенно почертыхаться пришлось с немецкой локализацией. Слова и фразы в переводе совершенно не влезали ни в какие нужные места интерфейса. Так или иначе, проблему мы с командой все-таки забороли. Даже наши немецкие коллеги на удивление не стали нас линчевать по чем зря.
Технологии постоянно бегут вперед. Однако, похожие задачки у моих коллег по цеху (встроенные системы) я постоянно подмечаю и на сей день.
Поэтому для меня совершенно не удивительно, что наконец-то начинают появляться специальные люди – UX-писатели. Они как раз и занимаются правильной разработкой и адаптацией такого типа информации. Что раньше было в диковинку, разделение специалистов на такую узкую специализацию, сейчас становится в порядке вещей. Не страшно, если это всего лишь роль в небольшой команде.
@aheadofthepack
Гибридный формат посещения офиса. Минусы и плюсы
Привет всем! 👋
Давно хотел высказать свои мысли по поводу относительно нового формата работы IT-компаний - гибридного. Когда некоторые дни недели сотрудники могут поработать из дома. Да, это похоже очередной модный тренд, который спровоцировала и усилила пандемия ещё в прошлом году. Тренд все равно продолжается, даже несмотря на обратное резвое упихивание персонала в офисы некоторыми компаниями. Не всем удалось приспособиться к новым для себя форматам работы в боевых условиях.
И что мы IT-шники получили в итоге? Вопрос настолько обширный, что затрагивает практически все аспекты жизнедеятельности фирмы: инфраструктуру с безопасностью, управление, взаимодействие, HR. Но я напишу лишь про малую часть из этого – командное взаимодействие.
Организовать процесс технически - это только половина дела. Для менеджеров и различного рода руководителей, от кого зависит выстраивание непрерывных процессов и эффективности, все равно появляется дополнительная нагрузка. Ведь надо точно держать все взаимосвязи, к примеру, кто кому и что должен был передать физически. Сверхответственнных сотрудников на все компании не напасешься. Голова может начать пухнуть, а отлаженный бизнес-процесс (что на удаленке, что в офисе) рушиться от постоянной перестройки.
Команда подразумевает коллективную форму работы и взаимодействия. Для всех сотрудников появились сложности проведения гибридных митингов. Когда часть людей на удаленке, а часть в офисе, системы групповой конференцсвязи не спасают. Всегда получается дискриминация вниманием тех, кто на удаленке. А как делать общую работу в неравных условиях? Как и многие другие, мы в команде после долгих экспериментов пришли к правилу: если хоть кто-то на удаленке, значит все встречаемся онлайн. Что делать, посидим уткнувшись в мониторы. Зато все в равных условиях.
Особенно пострадали фирмы, в которых продвигалось "чувства локтя", командного духа, разные техники типа парного программирования. Переход к гибриду ломает всю корпоративную культуру. Перестройка корпоративной культуры настолько долгий и болезненный процесс, что не все решаются к нему приступать. Ведь кадры под корпкультуру уже подобраны и отфильтрованы. Этот пункт, наверное, самый болезненный для всех.
Честно, хотел написать о плюсах, но, по сути, их как-то не много. Гибридный формат даёт возможность снизить психическую и физическую разгрузку. Особенно на тех, кто мотается в душном метро 😷 ежедневно. Но в целом от гибрида выходит ни то, ни сё. Не нормального удаленного процесса, ни нормальной офисной коллаборации.
Мы с Евгением Антоновым, автором канала Тимлид Очевидность договорились написать пост на тему гибридного формата, каждый у себя. Пойду, посмотрю, 👉что написал Евгений И вам рекомендую. Надеюсь на его взгляд на эту проблему с другой стороны.
Привет всем! 👋
Давно хотел высказать свои мысли по поводу относительно нового формата работы IT-компаний - гибридного. Когда некоторые дни недели сотрудники могут поработать из дома. Да, это похоже очередной модный тренд, который спровоцировала и усилила пандемия ещё в прошлом году. Тренд все равно продолжается, даже несмотря на обратное резвое упихивание персонала в офисы некоторыми компаниями. Не всем удалось приспособиться к новым для себя форматам работы в боевых условиях.
И что мы IT-шники получили в итоге? Вопрос настолько обширный, что затрагивает практически все аспекты жизнедеятельности фирмы: инфраструктуру с безопасностью, управление, взаимодействие, HR. Но я напишу лишь про малую часть из этого – командное взаимодействие.
Организовать процесс технически - это только половина дела. Для менеджеров и различного рода руководителей, от кого зависит выстраивание непрерывных процессов и эффективности, все равно появляется дополнительная нагрузка. Ведь надо точно держать все взаимосвязи, к примеру, кто кому и что должен был передать физически. Сверхответственнных сотрудников на все компании не напасешься. Голова может начать пухнуть, а отлаженный бизнес-процесс (что на удаленке, что в офисе) рушиться от постоянной перестройки.
Команда подразумевает коллективную форму работы и взаимодействия. Для всех сотрудников появились сложности проведения гибридных митингов. Когда часть людей на удаленке, а часть в офисе, системы групповой конференцсвязи не спасают. Всегда получается дискриминация вниманием тех, кто на удаленке. А как делать общую работу в неравных условиях? Как и многие другие, мы в команде после долгих экспериментов пришли к правилу: если хоть кто-то на удаленке, значит все встречаемся онлайн. Что делать, посидим уткнувшись в мониторы. Зато все в равных условиях.
Особенно пострадали фирмы, в которых продвигалось "чувства локтя", командного духа, разные техники типа парного программирования. Переход к гибриду ломает всю корпоративную культуру. Перестройка корпоративной культуры настолько долгий и болезненный процесс, что не все решаются к нему приступать. Ведь кадры под корпкультуру уже подобраны и отфильтрованы. Этот пункт, наверное, самый болезненный для всех.
Честно, хотел написать о плюсах, но, по сути, их как-то не много. Гибридный формат даёт возможность снизить психическую и физическую разгрузку. Особенно на тех, кто мотается в душном метро 😷 ежедневно. Но в целом от гибрида выходит ни то, ни сё. Не нормального удаленного процесса, ни нормальной офисной коллаборации.
Мы с Евгением Антоновым, автором канала Тимлид Очевидность договорились написать пост на тему гибридного формата, каждый у себя. Пойду, посмотрю, 👉что написал Евгений И вам рекомендую. Надеюсь на его взгляд на эту проблему с другой стороны.
Telegram
Тимлид Очевидность | Евгений Антонов
Евгений Антонов об ИТ, менеджменте и здравом смысле. Софты, карьера и т.д
Консультации https://clck.ru/3PyECF
Сообщество руководителей https://clck.ru/3PyEaL
Реклама https://clck.ru/3GdC7m
РКН https://www.gosuslugi.ru/snet/6785113f6aa9672b96a30f09
Консультации https://clck.ru/3PyECF
Сообщество руководителей https://clck.ru/3PyEaL
Реклама https://clck.ru/3GdC7m
РКН https://www.gosuslugi.ru/snet/6785113f6aa9672b96a30f09
Активности и продуктивности
Все ли помнят модель COCOMO по которой оценивалась стоимость разработки ПО? Нет? А метрику SLOC - количество строк кода? 🙈 Между прочем на полном серьёзе когда-то давно некоторые компании измеряли так производительность труда программистов. Чем больше кода написал, чем больше по клавиатуре настучал за интервал времени, тем круче программист, пора давать премию. Ну, а если мало строчек, хоть и без ошибок, то пиши пропало... дело дрянь.
Думал, такие системы и метрики давно остались в палеолите. Сейчас компаний смотрят на реальные результаты, а не на цифры, мало коррелирующие с ценностью, которую приносит и создаёт сотрудник. Даже на примере программирования именно опытные спецы пишут "более компактный" и чистый код, принося нужный результат. Уж даже не беря во внимание разницу в сложности решаемых задач, а также выделение времени "на подумать".
Но, нет...Совсем недалеко, на расстоянии одного светового года, в одной галактике решили измерять продуктивность сотрудников через метрики их активности в рабочих чатах, мейлах, системах тасктрекинга, и прочих инструментах. Аналогия с производительностью, выраженной в SLOC напрашивается сама собой. Вот только забыли померить, что на самом деле было произведено, работающий продукт или куча пустой активности?
Возможно, это было неуклюжее прикрытие других более тривиальных намерений. В любом случае, если галактика одумается, а не будет ли это уже поздно? Увидим все вместе.🤓
@aheadofthepack
Все ли помнят модель COCOMO по которой оценивалась стоимость разработки ПО? Нет? А метрику SLOC - количество строк кода? 🙈 Между прочем на полном серьёзе когда-то давно некоторые компании измеряли так производительность труда программистов. Чем больше кода написал, чем больше по клавиатуре настучал за интервал времени, тем круче программист, пора давать премию. Ну, а если мало строчек, хоть и без ошибок, то пиши пропало... дело дрянь.
Думал, такие системы и метрики давно остались в палеолите. Сейчас компаний смотрят на реальные результаты, а не на цифры, мало коррелирующие с ценностью, которую приносит и создаёт сотрудник. Даже на примере программирования именно опытные спецы пишут "более компактный" и чистый код, принося нужный результат. Уж даже не беря во внимание разницу в сложности решаемых задач, а также выделение времени "на подумать".
Но, нет...Совсем недалеко, на расстоянии одного светового года, в одной галактике решили измерять продуктивность сотрудников через метрики их активности в рабочих чатах, мейлах, системах тасктрекинга, и прочих инструментах. Аналогия с производительностью, выраженной в SLOC напрашивается сама собой. Вот только забыли померить, что на самом деле было произведено, работающий продукт или куча пустой активности?
Возможно, это было неуклюжее прикрытие других более тривиальных намерений. В любом случае, если галактика одумается, а не будет ли это уже поздно? Увидим все вместе.🤓
@aheadofthepack
Птичьи интерфейсы
Куча проблем в интерфейсах появляются из-за специфики продукта. В каждой области свои термины, понятные только узкому кругу специалистов. Особенно страдают этим продукты из сферы B2B, где куча слов из птичьего языка. Но в B2C проблемы не меньше. Причем, за счёт объема пользователей, проблем может быть даже больше.
Большинство из нас хоть раз в жизни выбирали отделочные материалы для квартиры. Что мы делаем? Бежим на сайт магазина, искать по каталогу товары, к примеру, нужных тонов. Но если попытаться найти с помощью фильтров интерфейса нужный цвет, то обычного человека (не дизайнера интерьеров) ждет сюрприз. Вместо ожидаемых: бежевого, серого, коричневого, его ждет: ясень ривьера, сосна арктическая, дуб неаполь. И ещё сотня-другая интересных названий, очень полезных продвинутому биологу, но не при выборе ламината. Главное - эти названия цветов не решают проблему подбора материалов для самого пользователя. Есть ли у него время углубляться в специфику?
Поэтому если уж что-то разрабатывать, для начала стоит понять на каком языке общаются основные пользователи продукта, который мы готовим. Кто наша аудитория, как им будет удобнее? Ведь для редкого случая, вряд ли кто-то захочет погружаться в дремучие дебри терминов. И при этом является ли задачей интерфейса обучать пользователей? Ведь в конечном счете от этого часто зависят издержки. Будут ли пользоваться этим продуктом, или поищут более удобные альтернативы при прочих равных.
Ну а уж, если мы нашли тот «правильный» набор терминов, то пора добавить системность. Словарь терминов является ключевым связующим звеном как во внешнем, так и во внутреннем поле. Он позволяет в дальнейшем популяризировать этих знаний через более понятные статьи, кейсы, онбординг пользователей. Он же позволяет команде разработки общаться на одном языке. Только так и разработка и пользователи научатся разговаривать на едином понятном диалекте.
@aheadofthepack
Куча проблем в интерфейсах появляются из-за специфики продукта. В каждой области свои термины, понятные только узкому кругу специалистов. Особенно страдают этим продукты из сферы B2B, где куча слов из птичьего языка. Но в B2C проблемы не меньше. Причем, за счёт объема пользователей, проблем может быть даже больше.
Большинство из нас хоть раз в жизни выбирали отделочные материалы для квартиры. Что мы делаем? Бежим на сайт магазина, искать по каталогу товары, к примеру, нужных тонов. Но если попытаться найти с помощью фильтров интерфейса нужный цвет, то обычного человека (не дизайнера интерьеров) ждет сюрприз. Вместо ожидаемых: бежевого, серого, коричневого, его ждет: ясень ривьера, сосна арктическая, дуб неаполь. И ещё сотня-другая интересных названий, очень полезных продвинутому биологу, но не при выборе ламината. Главное - эти названия цветов не решают проблему подбора материалов для самого пользователя. Есть ли у него время углубляться в специфику?
Поэтому если уж что-то разрабатывать, для начала стоит понять на каком языке общаются основные пользователи продукта, который мы готовим. Кто наша аудитория, как им будет удобнее? Ведь для редкого случая, вряд ли кто-то захочет погружаться в дремучие дебри терминов. И при этом является ли задачей интерфейса обучать пользователей? Ведь в конечном счете от этого часто зависят издержки. Будут ли пользоваться этим продуктом, или поищут более удобные альтернативы при прочих равных.
Ну а уж, если мы нашли тот «правильный» набор терминов, то пора добавить системность. Словарь терминов является ключевым связующим звеном как во внешнем, так и во внутреннем поле. Он позволяет в дальнейшем популяризировать этих знаний через более понятные статьи, кейсы, онбординг пользователей. Он же позволяет команде разработки общаться на одном языке. Только так и разработка и пользователи научатся разговаривать на едином понятном диалекте.
@aheadofthepack
Продажа воздуха
Заранее, никогда не знаешь имеет ли разрабатываемый продукт/решение реальную ценность. Конечно, всем хочется продавать готовый продукт, который приносит реальную пользу, но иногда, «продажа воздуха» необходима. Поэтому возникает задача продавать то, чего нет.
Речь здесь не идет об обмане потенциальных клиентов. Так как контракт на «воздух» не заключается. Мы всего лишь проверяем возможность потенциальной продажи.
Для теста продажи крайне полезен визуальный образ продукта. Никакие красивые слова и описания богатой функциональности не помогут, если нет того, что можно посмотреть. А еще лучше понажимать и пощупать. Многие просто не будут тратить время перерабатывая сухую информацию, чтобы представить продукт, который им может и не нужен вовсе.
У меня, как думаю и у многих из вас был такой кейс при запусках новых продуктов. Первые презентации с «весëлыми картинками» были вовсе не скриншотами реальных экранов и реальными фотографиями штуковин. Большая часть изображений для презентации была просто нарисована в графическом редакторе. Причем, даже имея такие презентации удавалось получать первые договоренности на последующие продажи. Когда спустя некоторое время продукт выходил с интерфейсом лучше, чем нарисованные мокапы, как правило никто не жаловался. 😊
Даже в отсутствии готового продукта можно и нужно рисовать его прототипы и пытаться их продавать. Как это будет реализовано, посредством презентаций или решенческих интервью, вопрос второй. Но надо получить реакцию на продукт до того момента, когда он будет уже оформлен к продаже. Потому что в отсутствии обратной связи ресурсы тратятся как правило не эффективно, и не совсем на то, что может быть продано.
@aheadofthepack
Заранее, никогда не знаешь имеет ли разрабатываемый продукт/решение реальную ценность. Конечно, всем хочется продавать готовый продукт, который приносит реальную пользу, но иногда, «продажа воздуха» необходима. Поэтому возникает задача продавать то, чего нет.
Речь здесь не идет об обмане потенциальных клиентов. Так как контракт на «воздух» не заключается. Мы всего лишь проверяем возможность потенциальной продажи.
Для теста продажи крайне полезен визуальный образ продукта. Никакие красивые слова и описания богатой функциональности не помогут, если нет того, что можно посмотреть. А еще лучше понажимать и пощупать. Многие просто не будут тратить время перерабатывая сухую информацию, чтобы представить продукт, который им может и не нужен вовсе.
У меня, как думаю и у многих из вас был такой кейс при запусках новых продуктов. Первые презентации с «весëлыми картинками» были вовсе не скриншотами реальных экранов и реальными фотографиями штуковин. Большая часть изображений для презентации была просто нарисована в графическом редакторе. Причем, даже имея такие презентации удавалось получать первые договоренности на последующие продажи. Когда спустя некоторое время продукт выходил с интерфейсом лучше, чем нарисованные мокапы, как правило никто не жаловался. 😊
Даже в отсутствии готового продукта можно и нужно рисовать его прототипы и пытаться их продавать. Как это будет реализовано, посредством презентаций или решенческих интервью, вопрос второй. Но надо получить реакцию на продукт до того момента, когда он будет уже оформлен к продаже. Потому что в отсутствии обратной связи ресурсы тратятся как правило не эффективно, и не совсем на то, что может быть продано.
@aheadofthepack
Значение имеют достоинства, а не недостатки
Питер Друкер – гуру менеджмента второй половины прошлого века, писал конечно не о продуктах, а о построении сильных команд, применяя лучшие качества людей. У каждого человека есть неограниченное количество недостатков, которые можно годами исправлять и выравнивать. Но работая над недостатками можно получить лишь средний результат, а можно и чуть выше, чем посредственный. Поэтому, гораздо выгоднее сосредотачиваться на достоинствах, преобразуя их в свои ключевые преимущества.
По прямой аналогии, в любом продукте не стоит выискивать недостатки, чтобы пытаться их выровнять и таким образом «вытянуть» продукт. «Мы пилим фичу почти как у продукта Х, и пытаемся угнаться за юзабилити, почти как у продукта Y». Можно ли такое потом продать? Не думаю... Это борьба со всеми конкурентами сразу, нерешаемая в силу ограничений: денег, времени, технически. Недостатки будут всегда и везде.
Лучше поработать над сильными сторонами и позиционированием. То, что отличает и выделяет продукт на фоне прямых конкурентов. Найти, что продумано у них не так хорошо. Чем недовольны их пользователи? В чëм у продуктовой команды есть экспертиза. На пересечении этих зон и надо выбирать ключевые преимущества, на которые делается упор. Дело за малым - попытаться извлечь максимальную пользу из этих преимуществ. 😎
@aheadofthepack
Питер Друкер – гуру менеджмента второй половины прошлого века, писал конечно не о продуктах, а о построении сильных команд, применяя лучшие качества людей. У каждого человека есть неограниченное количество недостатков, которые можно годами исправлять и выравнивать. Но работая над недостатками можно получить лишь средний результат, а можно и чуть выше, чем посредственный. Поэтому, гораздо выгоднее сосредотачиваться на достоинствах, преобразуя их в свои ключевые преимущества.
По прямой аналогии, в любом продукте не стоит выискивать недостатки, чтобы пытаться их выровнять и таким образом «вытянуть» продукт. «Мы пилим фичу почти как у продукта Х, и пытаемся угнаться за юзабилити, почти как у продукта Y». Можно ли такое потом продать? Не думаю... Это борьба со всеми конкурентами сразу, нерешаемая в силу ограничений: денег, времени, технически. Недостатки будут всегда и везде.
Лучше поработать над сильными сторонами и позиционированием. То, что отличает и выделяет продукт на фоне прямых конкурентов. Найти, что продумано у них не так хорошо. Чем недовольны их пользователи? В чëм у продуктовой команды есть экспертиза. На пересечении этих зон и надо выбирать ключевые преимущества, на которые делается упор. Дело за малым - попытаться извлечь максимальную пользу из этих преимуществ. 😎
@aheadofthepack
Безошибочный стартапер
Наверное, многие сталкивались на собеседованиях с вопросом, где вас просят рассказать о своих ошибках и провалах. HR из крупных компаний давно предлагают классический ответ, придумать что-то незначительное, или которое может иметь как прямую, так и изнаночную сторону. Это происходит, потому что никто не любит открыто говорить о провалах, а тем более своих. Да и многие компании по-прежнему не любят нанимать «неудачников», которые потеряли деньги на инвестициях, завалили проект или наняли не того подрядчика или исполнителя. Истории успеха напротив завораживают и дают почву для мечтаний и экстраполяции предыдущего опыта на будущие проекты.
Череда успехов возможна на типовых проектах с низкой маржинальностью; проектах с незначительными рисками, где многое известно заранее и это можно даже подсчитать и контролировать. Однако серьезные успехи и взлеты новых продуктов слепляются из множества разнородных факторов, позитивных случайностей и большим количеством существенных негативных рисков, которые удалось избежать. Как правило есть взаимосвязь между уровнем рисков и потенциальной прибылью, которую можно получить в случае успеха. А где высокие риски, там и потери. Это и не возможность достичь первоначальных целей, и смена курсов с фиксацией убытков, и разочарования от неправильно подобранной команды. Как правило факторов много и даже опытные инвесторы или фонды не всегда могут просчитать наперед путь выбранного продуктового стартапа.
Поэтому в небольших компаниях и стартапах напротив, не интересуются удачными кейсами, которые найдутся у любого из кандидатов. Историю успеха в области больших рисков, как правило, не так-то и просто повторить уже с другим продутом, командой, или в другое время на других трендах. Успешные кейсы достаточно уникальны. Гораздо интереснее истории провалов, и какие выводы были из них сделаны, чтобы в дальнейшем не ходить по граблям. Это должен быть реальный больный провал, а не его вымученная синтетическая имитация из предыдущего совета. Также интересна толерантность и стойкость по отношению к неудачам и потерям.
Из этого можно сделать вывод о том, какие люди наиболее ценны для стартапов. И с обратной стороны, что можно рассказать о себе потенциальному кандидату, чтобы обратить на себя внимание.
@aheadofthepack
Наверное, многие сталкивались на собеседованиях с вопросом, где вас просят рассказать о своих ошибках и провалах. HR из крупных компаний давно предлагают классический ответ, придумать что-то незначительное, или которое может иметь как прямую, так и изнаночную сторону. Это происходит, потому что никто не любит открыто говорить о провалах, а тем более своих. Да и многие компании по-прежнему не любят нанимать «неудачников», которые потеряли деньги на инвестициях, завалили проект или наняли не того подрядчика или исполнителя. Истории успеха напротив завораживают и дают почву для мечтаний и экстраполяции предыдущего опыта на будущие проекты.
Череда успехов возможна на типовых проектах с низкой маржинальностью; проектах с незначительными рисками, где многое известно заранее и это можно даже подсчитать и контролировать. Однако серьезные успехи и взлеты новых продуктов слепляются из множества разнородных факторов, позитивных случайностей и большим количеством существенных негативных рисков, которые удалось избежать. Как правило есть взаимосвязь между уровнем рисков и потенциальной прибылью, которую можно получить в случае успеха. А где высокие риски, там и потери. Это и не возможность достичь первоначальных целей, и смена курсов с фиксацией убытков, и разочарования от неправильно подобранной команды. Как правило факторов много и даже опытные инвесторы или фонды не всегда могут просчитать наперед путь выбранного продуктового стартапа.
Поэтому в небольших компаниях и стартапах напротив, не интересуются удачными кейсами, которые найдутся у любого из кандидатов. Историю успеха в области больших рисков, как правило, не так-то и просто повторить уже с другим продутом, командой, или в другое время на других трендах. Успешные кейсы достаточно уникальны. Гораздо интереснее истории провалов, и какие выводы были из них сделаны, чтобы в дальнейшем не ходить по граблям. Это должен быть реальный больный провал, а не его вымученная синтетическая имитация из предыдущего совета. Также интересна толерантность и стойкость по отношению к неудачам и потерям.
Из этого можно сделать вывод о том, какие люди наиболее ценны для стартапов. И с обратной стороны, что можно рассказать о себе потенциальному кандидату, чтобы обратить на себя внимание.
@aheadofthepack
Наличие багов не тождественно плохой продукт
Сколько раз вы сталкивались с ситуацией, когда присутствие ошибок в продукте приравнивали к плохому или сырому продукту?
Бывает, пишет/звонит пользователь и эмоционально высказывается, что найденная им ошибка мешает жить, да и сам продукт не продукт. И оказывается выявленная ошибка старая и в беклоге давно лежит себе спокойно с минорным приоритетом. Плохой ли продукт, если статистика по обратной связи от других пользователей говорит об обратном?
Другая ситуация. Кто-нибудь внимательный к деталям из менеджмента, стейкхолдеров или заказчик, начинает считать баги в продуктовом беклоге и оценивать продукт как плохой. Ведь в хорошем, ошибок быть недолжно. Плохой ли продукт?
Как правило ошибки в беклоге отсутствуют в двух случаях. В первом, продукт ещё не вышел, не продается, или даже не прошёл первоначального тестирования. Во втором случае он уже давно мёртв и не поддерживается. Что нужно уже сделано, остальное закрыли за ненадобностью.
В живом продукте всегда есть баги. Жирные пугающие, связанные с большим рефакторингом, мелкие досадные - неточности в пользовательском интерфейсе. Баги с высоким приоритетом и с низким. И весь этот супчик варится в беклоге нормального развивающегося продукта. Даже у именитых продуктов есть огромным беклог с проблемами, которые иногда не исправляются годами и которые не мешают ему развиваться и привлекать все новых и новых пользователей.
Управление техдолгом и его результатом и частым спутником - перечнем багов, одна из важных частей управления развитием продукта.
А что насчëт плохого/хорошего? Хороший продукт может быть тот, который монетизируется и востребован, с растущей базой пользователей, который достигает целей по метрикам и статистике. Количеством зарегистрированных багов это не оценивается.
@aheadofthepack
Сколько раз вы сталкивались с ситуацией, когда присутствие ошибок в продукте приравнивали к плохому или сырому продукту?
Бывает, пишет/звонит пользователь и эмоционально высказывается, что найденная им ошибка мешает жить, да и сам продукт не продукт. И оказывается выявленная ошибка старая и в беклоге давно лежит себе спокойно с минорным приоритетом. Плохой ли продукт, если статистика по обратной связи от других пользователей говорит об обратном?
Другая ситуация. Кто-нибудь внимательный к деталям из менеджмента, стейкхолдеров или заказчик, начинает считать баги в продуктовом беклоге и оценивать продукт как плохой. Ведь в хорошем, ошибок быть недолжно. Плохой ли продукт?
Как правило ошибки в беклоге отсутствуют в двух случаях. В первом, продукт ещё не вышел, не продается, или даже не прошёл первоначального тестирования. Во втором случае он уже давно мёртв и не поддерживается. Что нужно уже сделано, остальное закрыли за ненадобностью.
В живом продукте всегда есть баги. Жирные пугающие, связанные с большим рефакторингом, мелкие досадные - неточности в пользовательском интерфейсе. Баги с высоким приоритетом и с низким. И весь этот супчик варится в беклоге нормального развивающегося продукта. Даже у именитых продуктов есть огромным беклог с проблемами, которые иногда не исправляются годами и которые не мешают ему развиваться и привлекать все новых и новых пользователей.
Управление техдолгом и его результатом и частым спутником - перечнем багов, одна из важных частей управления развитием продукта.
А что насчëт плохого/хорошего? Хороший продукт может быть тот, который монетизируется и востребован, с растущей базой пользователей, который достигает целей по метрикам и статистике. Количеством зарегистрированных багов это не оценивается.
@aheadofthepack
Скрытые потребности
Одна из проблем разработки, отсутствие видения картины в целом. Потери истинных потребностей конечных пользователей продукта или его ценности для бизнеса часто случаются, когда разработку отдают на аутсорсинг. При этом не важно, будет ли это разработка продукта целиком, или же это какая-то часть большого проекта, например только дизайн и иллюстрации.
При этом, в отсутствии открытости информации, между заказчиком и исполнителем встают странные барьеры: «Зачем знать, как конечный продукт будет использоваться? Есть сухое ТЗ. Этого достаточно». Происходит то ли боязнь, что бизнес-идея будет украдена, то ли нежелание уделять время на погружение в особенности своего бизнеса, процессов, работы остальных контрагентов. В итоге бизнес-требования остаются недосказанными, а то, что было сделано в соответствии с системными из технического задания не закрывает потребности пользователя, либо доставляет ему значительные неудобства.
Вместо ситуации win-win, получаем противоположную. Появляются лишние издержки денег и времени на многократную доделку и переделку продукта. Продукт получается кривее, дороже и выходит на рынок позже, чем мог бы. Что уж говорить об удовлетворенности пользователя.
Но такие ситуации могут быть не только с аутсорсингом, но и внутри одной компании, когда люди бизнеса - маркетинг и продажи варятся в своём котле. К примеру, не предоставляют информации о рынке и обратной связи от пользователей, если процесс настроена подобным образом.
В результате недопонимания людей бизнеса и людей разработки и незнания истинных целей может рождаться большое количество дорогого техдолга, о котором периодически пишу. Ведь именно с бизнес-процессами, ролевой моделью, пользовательскими сценариями прорабатывается глубокое понимание первоначальных потребностей и закладывается правильная архитектура, удобные интерфейсы и дизайн.
@aheadofthepack
Одна из проблем разработки, отсутствие видения картины в целом. Потери истинных потребностей конечных пользователей продукта или его ценности для бизнеса часто случаются, когда разработку отдают на аутсорсинг. При этом не важно, будет ли это разработка продукта целиком, или же это какая-то часть большого проекта, например только дизайн и иллюстрации.
При этом, в отсутствии открытости информации, между заказчиком и исполнителем встают странные барьеры: «Зачем знать, как конечный продукт будет использоваться? Есть сухое ТЗ. Этого достаточно». Происходит то ли боязнь, что бизнес-идея будет украдена, то ли нежелание уделять время на погружение в особенности своего бизнеса, процессов, работы остальных контрагентов. В итоге бизнес-требования остаются недосказанными, а то, что было сделано в соответствии с системными из технического задания не закрывает потребности пользователя, либо доставляет ему значительные неудобства.
Вместо ситуации win-win, получаем противоположную. Появляются лишние издержки денег и времени на многократную доделку и переделку продукта. Продукт получается кривее, дороже и выходит на рынок позже, чем мог бы. Что уж говорить об удовлетворенности пользователя.
Но такие ситуации могут быть не только с аутсорсингом, но и внутри одной компании, когда люди бизнеса - маркетинг и продажи варятся в своём котле. К примеру, не предоставляют информации о рынке и обратной связи от пользователей, если процесс настроена подобным образом.
В результате недопонимания людей бизнеса и людей разработки и незнания истинных целей может рождаться большое количество дорогого техдолга, о котором периодически пишу. Ведь именно с бизнес-процессами, ролевой моделью, пользовательскими сценариями прорабатывается глубокое понимание первоначальных потребностей и закладывается правильная архитектура, удобные интерфейсы и дизайн.
@aheadofthepack
T-shaped специалисты во фрилансе
Тут много пишу о инхаус разработке, росте командной экспертизы и прокачке T-shaped навыков внутри команды. Но разработка не всегда целесообразна и возможна только за счёт внутренних ресурсов. Иногда бывает лучше отдать часть работы на аутсорсинг, либо фрилансерам. И мне приходилось с этим сталкиваться и нанимать внешний ресурс для проектов.
Развитие T-shaped специалистов – это трендовое направление современных продуктовых команд. И тут не поспоришь. Но, если продуктовые команды еще как-то могут существовать и работать на старых I-shaped подходах, то во фрилансе дела обстоят несколько иначе. Именно тут проявляется необходимость развития дополнительных навыков.
Начал писать пост об этом, но в итоге вышла небольшая 👉 Cтатья на VC
Тут много пишу о инхаус разработке, росте командной экспертизы и прокачке T-shaped навыков внутри команды. Но разработка не всегда целесообразна и возможна только за счёт внутренних ресурсов. Иногда бывает лучше отдать часть работы на аутсорсинг, либо фрилансерам. И мне приходилось с этим сталкиваться и нанимать внешний ресурс для проектов.
Развитие T-shaped специалистов – это трендовое направление современных продуктовых команд. И тут не поспоришь. Но, если продуктовые команды еще как-то могут существовать и работать на старых I-shaped подходах, то во фрилансе дела обстоят несколько иначе. Именно тут проявляется необходимость развития дополнительных навыков.
Начал писать пост об этом, но в итоге вышла небольшая 👉 Cтатья на VC
vc.ru
T-shaped специалисты во фрилансе — Карьера на vc.ru
Какие навыки хорошо бы подкачать фрилансеру, чтобы войти выстроить долгосрочную стратегию работы? И причем тут T-shaped?
❤3👍2
Как менеджеру мотивировать себя, если не видно прямого результата его работы?
Ух, сколько раз сталкивался с ситуацией, когда, работая в роли менеджера на операционке невозможно поделить свою работу на задачи, списывать часы и получать внутреннее удовлетворение от законченной работы. Вроде работаешь работаешь, а работа «не твоя». Но если не закрывать задачи, как же самомотивироваться?
Да, конечно, можно брать за основу корпоративные KPI/OKR. И очень хорошо, если они не спускаются откуда-то далеко сверху, а часть из них выработана в совместных усилиях. Но достижение каких-то показателей тоже не решает проблему полностью.
Как мне видится, гораздо важнее помимо корпоративной «обязаловки» ставить еще и свои собственные цели. Ведь внутренняя мотивация куда сильнее любой внешней. Честно, гораздо приятнее работать с какими-то вызовами и челленджами самому себе. И тут есть некоторые вещи, которые могут очень даже мотивировать:
🔹Возможность изучить и освоить что-то новое даёт классную мотивацию. Это может быть новая технология, метод или подход. Расширение кругозора в процессе работы круто мотивирует. Особенно прёт, когда есть возможность применить к месту эти новые знания. Для некоторых это даже является веской причиной смены вроде бы хорошей работы.
Следующая ступень – это возможность делиться этими знаниями внутри компании или даже вне её. Как говорится, сам изучил, обучи других.
🔹Достижение каких-то измеримых метрик, где они не встроены в общую систему. Например, метрик процесса разработки. Не секрет, что кому-то свойственно настраивать процессы, оптимизировать их и следить за тем, как улучшаются их метрики. Не менее интересны и метрики продукта. Причем в них можно получить иногда чуть ли не экспоненциальный рост. Само это может мотивировать.
🔹 Сопричастность с результатом общего труда. Менеджер проекта или продукта на то и менеджер, что сам он сделать в одиночку не сможет. Не сможет прейти к цели за адекватный отрезок времени. Но может это сделать с командой и ресурсами, приложив свои качества для достижения результата.
Поэтому, вне зависимости от того, выстроена ли корпоративная мотивация менеджеров, самомотивация может быть сильным драйвером. Главное, у менеджеров как правило гораздо больше направлений деятельности и, следовательно, возможностей замотивировать себя, чем у линейных сотрудников.
Подумать и написать пост на тему самомотивации менеджеров мы договорились с Александром Субботиным, CTO и автором канала Saturday Night Hack
Поэтому, рекомендую почитать его мнение по этому вопросу: 👉эволюция мотивации менеджера
Ух, сколько раз сталкивался с ситуацией, когда, работая в роли менеджера на операционке невозможно поделить свою работу на задачи, списывать часы и получать внутреннее удовлетворение от законченной работы. Вроде работаешь работаешь, а работа «не твоя». Но если не закрывать задачи, как же самомотивироваться?
Да, конечно, можно брать за основу корпоративные KPI/OKR. И очень хорошо, если они не спускаются откуда-то далеко сверху, а часть из них выработана в совместных усилиях. Но достижение каких-то показателей тоже не решает проблему полностью.
Как мне видится, гораздо важнее помимо корпоративной «обязаловки» ставить еще и свои собственные цели. Ведь внутренняя мотивация куда сильнее любой внешней. Честно, гораздо приятнее работать с какими-то вызовами и челленджами самому себе. И тут есть некоторые вещи, которые могут очень даже мотивировать:
🔹Возможность изучить и освоить что-то новое даёт классную мотивацию. Это может быть новая технология, метод или подход. Расширение кругозора в процессе работы круто мотивирует. Особенно прёт, когда есть возможность применить к месту эти новые знания. Для некоторых это даже является веской причиной смены вроде бы хорошей работы.
Следующая ступень – это возможность делиться этими знаниями внутри компании или даже вне её. Как говорится, сам изучил, обучи других.
🔹Достижение каких-то измеримых метрик, где они не встроены в общую систему. Например, метрик процесса разработки. Не секрет, что кому-то свойственно настраивать процессы, оптимизировать их и следить за тем, как улучшаются их метрики. Не менее интересны и метрики продукта. Причем в них можно получить иногда чуть ли не экспоненциальный рост. Само это может мотивировать.
🔹 Сопричастность с результатом общего труда. Менеджер проекта или продукта на то и менеджер, что сам он сделать в одиночку не сможет. Не сможет прейти к цели за адекватный отрезок времени. Но может это сделать с командой и ресурсами, приложив свои качества для достижения результата.
Поэтому, вне зависимости от того, выстроена ли корпоративная мотивация менеджеров, самомотивация может быть сильным драйвером. Главное, у менеджеров как правило гораздо больше направлений деятельности и, следовательно, возможностей замотивировать себя, чем у линейных сотрудников.
Подумать и написать пост на тему самомотивации менеджеров мы договорились с Александром Субботиным, CTO и автором канала Saturday Night Hack
Поэтому, рекомендую почитать его мнение по этому вопросу: 👉эволюция мотивации менеджера
Telegram
Saturday Night Hack
Субъективно про продуктивность и IT
Автор: @alexsubbotin, Software Engineer в Raycast, ex. CTO Appbooster.
Автор: @alexsubbotin, Software Engineer в Raycast, ex. CTO Appbooster.
👍4❤3