Политика Открытых ушей
Политика открытых дверей - распространённая практика донесения обратной связи по восходящей линии в организации. Большинство компаний с демократичным подходом к управлению не забывают о ней.
Но кроме обратной связи должен быть и второй вектор – действие на эту обратную связь. Участливое выслушивание, не приводящее ни к каким результатам, делает концепцию открытых дверей бессмысленной. Поэтому добавим и второе немного ироничное измерение - Политику открытых ушей.
👉 Подробнее в статье на vc
Политика открытых дверей - распространённая практика донесения обратной связи по восходящей линии в организации. Большинство компаний с демократичным подходом к управлению не забывают о ней.
Но кроме обратной связи должен быть и второй вектор – действие на эту обратную связь. Участливое выслушивание, не приводящее ни к каким результатам, делает концепцию открытых дверей бессмысленной. Поэтому добавим и второе немного ироничное измерение - Политику открытых ушей.
👉 Подробнее в статье на vc
Системный подход vs нафигачить
Большинство IT-компаний начинают с малого. Часто с хаотического процесса, держащегося на здравом смысле и воле основателей. Если компания перерастает период «младенческой смертности», начинается осознание не только что нужно делать, но и как нужно делать. В процессе эволюционного развития R&D начинают вводить сложные процессы. При таком подходе становится возможным создавать серийное, масштабное и долгоиграющее; обрести устойчивость и повторяемость результатов разработки продукта или услуги. Происходит постепенное обрастание детальным BA/SA, сложным процессом CI/CD, полным QA automation и т д. Разработка становится неповоротливой, наподобие перекаченного атлета.
Но компании не живут на одном продукте вечно. Старт очередного нового продукта начинается с прототипов. Создание прототипов с тем же выстроенным тяжелым процессом – это долго и дорого. При этом теряется основная идея прототипирования - скорость и невысокие издержки в ущерб качеству. Если речь касается одноразовых прототипов для проверки гипотез или расчетов, то применение тяжелого подхода не оправдано и подавно. Принцип ошибаться часто и дешево никто не отменял.
Однако, самим разработчикам, да и менеджерам сложно перестроится с одних процессов на другие в моменте. Даже не так важно в какую в сторону нужно поменяться: в сторону облегчения процесса или обратно. Просто мозг так устроен, что выработанные и закрепленные паттерны работы не так быстро поменять. Иногда это может даже вызывать реальный дискомфорт и ломку мозга.
Если все так плохо, то что же можно сделать?
Под прототипирование лучше выделять отдельных разработчиков, создавать выделенные команды или даже аутсорсить или аутстаффить разработку прототипов если это не затрагивает статические процессы. В зависимости от типа и размера продуктовой компании мне встречались любые из перечисленных вариантов. Все имеют право на жизнь. Но главная идея - отделить легкие процессы от тяжелых, и тех, кто по ним будет работать.
@aheadofthepack
Большинство IT-компаний начинают с малого. Часто с хаотического процесса, держащегося на здравом смысле и воле основателей. Если компания перерастает период «младенческой смертности», начинается осознание не только что нужно делать, но и как нужно делать. В процессе эволюционного развития R&D начинают вводить сложные процессы. При таком подходе становится возможным создавать серийное, масштабное и долгоиграющее; обрести устойчивость и повторяемость результатов разработки продукта или услуги. Происходит постепенное обрастание детальным BA/SA, сложным процессом CI/CD, полным QA automation и т д. Разработка становится неповоротливой, наподобие перекаченного атлета.
Но компании не живут на одном продукте вечно. Старт очередного нового продукта начинается с прототипов. Создание прототипов с тем же выстроенным тяжелым процессом – это долго и дорого. При этом теряется основная идея прототипирования - скорость и невысокие издержки в ущерб качеству. Если речь касается одноразовых прототипов для проверки гипотез или расчетов, то применение тяжелого подхода не оправдано и подавно. Принцип ошибаться часто и дешево никто не отменял.
Однако, самим разработчикам, да и менеджерам сложно перестроится с одних процессов на другие в моменте. Даже не так важно в какую в сторону нужно поменяться: в сторону облегчения процесса или обратно. Просто мозг так устроен, что выработанные и закрепленные паттерны работы не так быстро поменять. Иногда это может даже вызывать реальный дискомфорт и ломку мозга.
Если все так плохо, то что же можно сделать?
Под прототипирование лучше выделять отдельных разработчиков, создавать выделенные команды или даже аутсорсить или аутстаффить разработку прототипов если это не затрагивает статические процессы. В зависимости от типа и размера продуктовой компании мне встречались любые из перечисленных вариантов. Все имеют право на жизнь. Но главная идея - отделить легкие процессы от тяжелых, и тех, кто по ним будет работать.
@aheadofthepack
Насильственное обучение
В кросс-функциональных командах обучению смежных навыков стоит уделять повышенное внимание. Глубоких знаний в одной узкой области недостаточно, чтобы стать полноценным T-shaped специалистом. В свою очередь это необходимо, чтобы команда работала без перегрузок в более комфортном и при этом эффективном режиме.
Как организовать обучение внутри команды правильно? Практика показывает, что "насильственное" обучение людей дает невысокую эффективность.
Приведу пару примеров.
Пока курсы английского языка оплачивает работодатель, все ходят, некоторые даже стараются, получают сертификаты. Как только подталкивание и финансирование прерываются, продолжать обучение решают лишь считанные единицы из обучавшихся. Остальные продолжать не решаются и начинают потихоньку скатываться на первоначальный уровень. Были ли нужны курсы?
Другой пример. Компания проводит внутренние корпоративные митапы по бизнес-процессам. Все бы хорошо, но далеко не все включаются в процесс слушания. Такое бывает, даже если тема непосредственно связана с рабочими обязанностями. Кто-то откровенно спит, а потом уже в работе начинает задавать странные вопросы. Как повысить вовлеченность?
Причина кроется в отсутствии мотивации. Невозможно заставить обучиться того, кто этого внутренне не хочет или не готов тратить на это энергию. При этом другие, наоборот готовы сами построить собственный план и процесс обучения, но испытывают нехватку финансов или перегруз по рабочим задачам. Логично перестать заниматься продавливанием обучения среди сотрудников, и направить усилия на выявление потребности обучения у них самих. Потребности обеих сторон в конце концов можно и балансировать.
💡Почаще проводите интервью с командами и индивидуально, вы узнаете много нового.
@aheadofthepack
В кросс-функциональных командах обучению смежных навыков стоит уделять повышенное внимание. Глубоких знаний в одной узкой области недостаточно, чтобы стать полноценным T-shaped специалистом. В свою очередь это необходимо, чтобы команда работала без перегрузок в более комфортном и при этом эффективном режиме.
Как организовать обучение внутри команды правильно? Практика показывает, что "насильственное" обучение людей дает невысокую эффективность.
Приведу пару примеров.
Пока курсы английского языка оплачивает работодатель, все ходят, некоторые даже стараются, получают сертификаты. Как только подталкивание и финансирование прерываются, продолжать обучение решают лишь считанные единицы из обучавшихся. Остальные продолжать не решаются и начинают потихоньку скатываться на первоначальный уровень. Были ли нужны курсы?
Другой пример. Компания проводит внутренние корпоративные митапы по бизнес-процессам. Все бы хорошо, но далеко не все включаются в процесс слушания. Такое бывает, даже если тема непосредственно связана с рабочими обязанностями. Кто-то откровенно спит, а потом уже в работе начинает задавать странные вопросы. Как повысить вовлеченность?
Причина кроется в отсутствии мотивации. Невозможно заставить обучиться того, кто этого внутренне не хочет или не готов тратить на это энергию. При этом другие, наоборот готовы сами построить собственный план и процесс обучения, но испытывают нехватку финансов или перегруз по рабочим задачам. Логично перестать заниматься продавливанием обучения среди сотрудников, и направить усилия на выявление потребности обучения у них самих. Потребности обеих сторон в конце концов можно и балансировать.
💡Почаще проводите интервью с командами и индивидуально, вы узнаете много нового.
@aheadofthepack
Делать как для себя
Редко, когда разработка железа, ПО, да и любая работа, идет не в команде. Разработчиков отшельников в расчет не берем. 😋 А где команда, там появляются цепочки процессов. Не важно описанные они или образовались и зафиксировались естественным путем. Но стоит помнить о том, что же будет дальше с результатами труда каждого участника? Подкреплю примерами из жизни.
Программист реализовал новый функционал, а версию ПО не инкрементировал (к счастью, если есть CI, и она настроена правильно, такое не получится). Следующий в цепочке - тестировщик рискует получить проблему одинаковых версий ПО продукта, но с разным поведением. Совсем беда, если такое уйдет в продакшн. Хвосты разбирать придется менеджменту и техподдержке.
Либо ситуация, наоборот. Тестировщик или кто-то другой нашел в работе ПО ошибку. Название бага в системе багтренинга записал, но остальные обязательные поля заполнить поленился. Следующий, кому попадет эта задача возможно потратит не один час, пытаясь понять и воспроизвести проблему.
В работе я часто сталкиваюсь еще и с железом. Кто знаком с этой областью, наверное, знают, как же сложно определить без маркировочных подписей на плате назначение контактов. Придется как минимум найти схему. Это предыдущий в цепочке инженер не стал размышлять, как будут использовать его работу.
Либо совсем элементарный пример. Принимает кто-то ценный груз, но коробку после вскрытия запаковывает кое-как. Следующий взявший ее со склада, не зная подвоха с непроклеенным дном, разумеется, уронит и повредит товар.
Эти примеры всего лишь из внутренних процессов. Когда что-то уходит за пределы команды вариации возрастают.
Думаю, всегда стоит подумать:
⚽️ Кто стоит следующий в цепочке действий?
🏀 Хватает ли ему знаний о том, что было сделано?
🏐 Как облегчить ему работу?
🏉 Как бы я хотел, чтобы мне передали задачу?
Классно замечать, как люди учатся на своих и чужих ошибка и постепенно начинают относиться к делам вдумчиво.
@aheadofthepack
Редко, когда разработка железа, ПО, да и любая работа, идет не в команде. Разработчиков отшельников в расчет не берем. 😋 А где команда, там появляются цепочки процессов. Не важно описанные они или образовались и зафиксировались естественным путем. Но стоит помнить о том, что же будет дальше с результатами труда каждого участника? Подкреплю примерами из жизни.
Программист реализовал новый функционал, а версию ПО не инкрементировал (к счастью, если есть CI, и она настроена правильно, такое не получится). Следующий в цепочке - тестировщик рискует получить проблему одинаковых версий ПО продукта, но с разным поведением. Совсем беда, если такое уйдет в продакшн. Хвосты разбирать придется менеджменту и техподдержке.
Либо ситуация, наоборот. Тестировщик или кто-то другой нашел в работе ПО ошибку. Название бага в системе багтренинга записал, но остальные обязательные поля заполнить поленился. Следующий, кому попадет эта задача возможно потратит не один час, пытаясь понять и воспроизвести проблему.
В работе я часто сталкиваюсь еще и с железом. Кто знаком с этой областью, наверное, знают, как же сложно определить без маркировочных подписей на плате назначение контактов. Придется как минимум найти схему. Это предыдущий в цепочке инженер не стал размышлять, как будут использовать его работу.
Либо совсем элементарный пример. Принимает кто-то ценный груз, но коробку после вскрытия запаковывает кое-как. Следующий взявший ее со склада, не зная подвоха с непроклеенным дном, разумеется, уронит и повредит товар.
Эти примеры всего лишь из внутренних процессов. Когда что-то уходит за пределы команды вариации возрастают.
Думаю, всегда стоит подумать:
⚽️ Кто стоит следующий в цепочке действий?
🏀 Хватает ли ему знаний о том, что было сделано?
🏐 Как облегчить ему работу?
🏉 Как бы я хотел, чтобы мне передали задачу?
Классно замечать, как люди учатся на своих и чужих ошибка и постепенно начинают относиться к делам вдумчиво.
@aheadofthepack
Полезный и вредный технический долг ч.1
В продуктовой разработке с завидной периодичностью слышу высказывания в стиле: «Давайте все отрефакторим. Давайте заново перепишем с нуля. Ну, давайте же наконец сменим технологический стек». Действительно разработчикам, особенно склонным к перфекционизму, хочется жить вообще без технического долга. Сам когда-то давно рассуждал подобным образом. Однако, менеджеру стоит ясно понимать, когда и зачем это нужно делать.
На самом деле есть три явные цели, для которых стоит учиться работать с техническим долгом. Они увязаны с бизнес-моделью роста стартапов и малых фирм.
🎯 Экономия ресурсов. Прежде всего - капитала. Молодой фирме крайне желательно как можно быстрее проверить продуктовые гипотезы. Как можно быстрее вывести минимально жизнеспособный продукт MVP на рынок и запустить новый цикл разработки. При этом минимизировать первоначальные затраты. Физических ресурсов, ни тем более денежных у фирмы может и не быть. Основатели стартапа, вынуждены экономить ресурсы. Почему? Все просто - вероятность успеха, особенно в новой области невысока. Поэтому взятие техдолга – это большая экономия стартапов на старте. Лучше за меньшие деньги отработать как можно больше гипотез.
🎯 Уменьшение времени появления и модификации продукта, либо инкременты проекта. Time to Market – не менее важный показатель для стартапов. Для средних и крупных организаций такое тоже может быть, но в менее выраженной форме. Обычно для корпораций более важно качество, т к присутствуют уже сформировавшаяся аудитория и соответствующие репутационные и прочие риски.
🎯 Устранение ненужных трат. Классический случай - старые продукты, жизненный цикл которых подходит к концу. В них уже вряд ли будет какое-либо развитие. Поэтому разумно начинать накапливать технический долг. Нет смысла вылизывать внутреннюю кухню до блеска, можно и оставить/приделать костыли напоследок.
Еще один пример – это проекты без продолжения. В проектах с фиксированным бюджетом и соответствующим перечнем работ бывает нет никакой возможности расширить ни первое, ни второе. Поэтому приходится загрублять качество, внести риск в виде соответствующего техдолга.
А если коротко, описанные случаи намеренного появления техдолга приводят к краткосрочной экономии двух вещей – времени и денег.
@aheadofthepack
В продуктовой разработке с завидной периодичностью слышу высказывания в стиле: «Давайте все отрефакторим. Давайте заново перепишем с нуля. Ну, давайте же наконец сменим технологический стек». Действительно разработчикам, особенно склонным к перфекционизму, хочется жить вообще без технического долга. Сам когда-то давно рассуждал подобным образом. Однако, менеджеру стоит ясно понимать, когда и зачем это нужно делать.
На самом деле есть три явные цели, для которых стоит учиться работать с техническим долгом. Они увязаны с бизнес-моделью роста стартапов и малых фирм.
🎯 Экономия ресурсов. Прежде всего - капитала. Молодой фирме крайне желательно как можно быстрее проверить продуктовые гипотезы. Как можно быстрее вывести минимально жизнеспособный продукт MVP на рынок и запустить новый цикл разработки. При этом минимизировать первоначальные затраты. Физических ресурсов, ни тем более денежных у фирмы может и не быть. Основатели стартапа, вынуждены экономить ресурсы. Почему? Все просто - вероятность успеха, особенно в новой области невысока. Поэтому взятие техдолга – это большая экономия стартапов на старте. Лучше за меньшие деньги отработать как можно больше гипотез.
🎯 Уменьшение времени появления и модификации продукта, либо инкременты проекта. Time to Market – не менее важный показатель для стартапов. Для средних и крупных организаций такое тоже может быть, но в менее выраженной форме. Обычно для корпораций более важно качество, т к присутствуют уже сформировавшаяся аудитория и соответствующие репутационные и прочие риски.
🎯 Устранение ненужных трат. Классический случай - старые продукты, жизненный цикл которых подходит к концу. В них уже вряд ли будет какое-либо развитие. Поэтому разумно начинать накапливать технический долг. Нет смысла вылизывать внутреннюю кухню до блеска, можно и оставить/приделать костыли напоследок.
Еще один пример – это проекты без продолжения. В проектах с фиксированным бюджетом и соответствующим перечнем работ бывает нет никакой возможности расширить ни первое, ни второе. Поэтому приходится загрублять качество, внести риск в виде соответствующего техдолга.
А если коротко, описанные случаи намеренного появления техдолга приводят к краткосрочной экономии двух вещей – времени и денег.
@aheadofthepack
Полезный и вредный технический долг ч.2
Продолжу писать заметки по актуальной теме.
Технический долг может быть достаточно дешев в краткосрочной перспективе. Распространенный пример полезного использования техдолга — создание различных прототипов. Большинство новых продуктов как раз с этого и начинается.
Чтобы реализовать MVP необходим минимум технической и тестовой документации и полезных процессов. Для Proof of concept (PoC) технического долга можно набрать еще больше. Важно лишь зафиксировать что конкретно хотим проверить (наши гипотезы) и какими методами, чтобы потом не создавалось искажений при интерпретации результатов. Думаю, многие согласятся с Agile подходами. Работающий прототип и быстрая проверка результата более важна чем наличие правильной полной документации и отлаженного процесса. Работающее MVP является ценностью для пользователей, PoC для команды разработки или инвестора. При этом использование долга происходит наиболее эффективным образом. Об этом я уже писал недавно в посте Системный подход vs нафигачить
Прототипировать можно нарастающими итерациями: от менее затратных средств к более затратным. К примеру, для прототипирования дизайна я до сих пор использую бумажные прототипы, которые рисуются за пять минут для обсуждения концепции. Если команда собирается оффлайн обсуждать эскизы на листе бумаги проще простого. Потом они переносятся в средство рисования мокапов. Либо, миновав его, сразу переходить к проектированию интерфейса на конечном фреймворке. Но прошу, не начинайте UI с кода. :)
В итоге можем получить экономию на каждом шаге прототипирования. Если мы пошли не в ту сторону потери будут минимальны, лишняя документация и код не плодятся. Если же мы нащупали верное направление требуется срочно закрывать долг и приводить следующий цикл разработки с уже более правильным и полным подходом. Закрытие долга особенно актуально, если первоначально разрабатывали наш прототип не как одноразовый, а как эволюционный.
@aheadofthepack
Продолжу писать заметки по актуальной теме.
Технический долг может быть достаточно дешев в краткосрочной перспективе. Распространенный пример полезного использования техдолга — создание различных прототипов. Большинство новых продуктов как раз с этого и начинается.
Чтобы реализовать MVP необходим минимум технической и тестовой документации и полезных процессов. Для Proof of concept (PoC) технического долга можно набрать еще больше. Важно лишь зафиксировать что конкретно хотим проверить (наши гипотезы) и какими методами, чтобы потом не создавалось искажений при интерпретации результатов. Думаю, многие согласятся с Agile подходами. Работающий прототип и быстрая проверка результата более важна чем наличие правильной полной документации и отлаженного процесса. Работающее MVP является ценностью для пользователей, PoC для команды разработки или инвестора. При этом использование долга происходит наиболее эффективным образом. Об этом я уже писал недавно в посте Системный подход vs нафигачить
Прототипировать можно нарастающими итерациями: от менее затратных средств к более затратным. К примеру, для прототипирования дизайна я до сих пор использую бумажные прототипы, которые рисуются за пять минут для обсуждения концепции. Если команда собирается оффлайн обсуждать эскизы на листе бумаги проще простого. Потом они переносятся в средство рисования мокапов. Либо, миновав его, сразу переходить к проектированию интерфейса на конечном фреймворке. Но прошу, не начинайте UI с кода. :)
В итоге можем получить экономию на каждом шаге прототипирования. Если мы пошли не в ту сторону потери будут минимальны, лишняя документация и код не плодятся. Если же мы нащупали верное направление требуется срочно закрывать долг и приводить следующий цикл разработки с уже более правильным и полным подходом. Закрытие долга особенно актуально, если первоначально разрабатывали наш прототип не как одноразовый, а как эволюционный.
@aheadofthepack
Telegram
На шаг впереди
Системный подход vs нафигачить
Большинство IT-компаний начинают с малого. Часто с хаотического процесса, держащегося на здравом смысле и воле основателей. Если компания перерастает период «младенческой смертности», начинается осознание не только что нужно…
Большинство IT-компаний начинают с малого. Часто с хаотического процесса, держащегося на здравом смысле и воле основателей. Если компания перерастает период «младенческой смертности», начинается осознание не только что нужно…
Бесконечный потолок
Бывает сложно расти в глубины какой-то специфический области. Либо сам материал становится сложнее, либо практических кейсов в работе не удается набрать, либо нет поблизости людей, с которыми можно обсудить вопрос на требуемом уровне. Да и сверхпрофессиональному узкоориентированному специалисту тяжело продвигаться на рынке труда, что ограничивает мотивацию.
Я заметил тенденцию, что специалисты, дорастая до каких-то высот в профессиональном развитии упираются в потолок. При этом они сильно замедляются, топчутся на месте, либо совсем останавливаются. Кто-то начинает считать, что достиг своего предела. Это наши собственные ограничивающие установки.
На самом деле потолок практически ничем не ограничен. Все ограничивается лишь желанием ставить себе новые цели. Причем для сохранения мотивации это стоит делать самостоятельно, а не под действием постоянного подпинывания начальника или корпоративного HR-менеджера.
Логика и деверсификационные принципы подсказывают, что лучше развивать не только специфические навыки, но и смежные скилы. Изменения происходят так быстро, что приоритеты и сам перечень технических компетенции (hard skills) меняются каждые несколько лет. Вряд-ли придется всю жизнь сидеть на одном месте и широкий кругозор будет хорошим подспорьем.
@aheadofthepack
Бывает сложно расти в глубины какой-то специфический области. Либо сам материал становится сложнее, либо практических кейсов в работе не удается набрать, либо нет поблизости людей, с которыми можно обсудить вопрос на требуемом уровне. Да и сверхпрофессиональному узкоориентированному специалисту тяжело продвигаться на рынке труда, что ограничивает мотивацию.
Я заметил тенденцию, что специалисты, дорастая до каких-то высот в профессиональном развитии упираются в потолок. При этом они сильно замедляются, топчутся на месте, либо совсем останавливаются. Кто-то начинает считать, что достиг своего предела. Это наши собственные ограничивающие установки.
На самом деле потолок практически ничем не ограничен. Все ограничивается лишь желанием ставить себе новые цели. Причем для сохранения мотивации это стоит делать самостоятельно, а не под действием постоянного подпинывания начальника или корпоративного HR-менеджера.
Логика и деверсификационные принципы подсказывают, что лучше развивать не только специфические навыки, но и смежные скилы. Изменения происходят так быстро, что приоритеты и сам перечень технических компетенции (hard skills) меняются каждые несколько лет. Вряд-ли придется всю жизнь сидеть на одном месте и широкий кругозор будет хорошим подспорьем.
@aheadofthepack
Тренд по фрилансу
PwC сделал интересное исследование по глобальным и региональным трендам рынка фрилансеров
Фрилансеры исторически считались дешевой и относительно низкоквалифицированной рабочей силой. Серьёзные IT-фирмы с системным подходом и внутренними процессами расширять штат за счёт фрилансеров не любили вследствие больших рисков относительно результатов, сроков и качества. При этом часто предпочитался инхаус даже несмотря на возможную неполную загрузку ресурсов и совмещение не самых совместимых ролей. Я и сам скептически относился к этому направлению, если рассматривать исключительно IT сектор.
В России фрилансеры – это прежде всего молодое поколение людей. Согласно исследованию, 68% из них находятся в диапазоне от 18 до 34 лет. Постепенно идет смена поколений. Получившие первый опыт работы и при этом привыкшие к фрилансу зуммеры с их приоритетами, начинают задавать зарождающийся сильный тренд. И его стоит учитывать в будущем. 💡 А еще лучше - воспользоваться этой тенденцией. Усилению тренда фриланса способствуют два фактора из предыдущего 2020 года: пандемия, развеявшая мифы об неэффективности удаленных сотрудников, а также увеличение доли безработных специалистов на рынке труда.
Россия пока догоняет мировые тренды с запозданием на несколько лет. И здесь можно ожидать сильного роста. Так по прогнозам до 2025 рынок фриланса в России вырастет в 2,5 раза в денежном выражении. Также можно ожидать и увеличения гонораров за счёт повышения среднего возраста фрилансеров и профессионализма. С обратной стороны к этому подталкивает конкуренции за качественный ресурс работодателей вследствие вымывания квалифицированных постоянных сотрудников. Это особенно остро прослеживается в малом и микробизнесе.
Фриланс по всей видимости пока останется узкоспециализированным решением для временных задач и проектов. При этом займет более конкурентноспособную позицию по сравнению с аутсорсингом и аутстаффингом, чем сейчас.
@aheadofthepack
PwC сделал интересное исследование по глобальным и региональным трендам рынка фрилансеров
Фрилансеры исторически считались дешевой и относительно низкоквалифицированной рабочей силой. Серьёзные IT-фирмы с системным подходом и внутренними процессами расширять штат за счёт фрилансеров не любили вследствие больших рисков относительно результатов, сроков и качества. При этом часто предпочитался инхаус даже несмотря на возможную неполную загрузку ресурсов и совмещение не самых совместимых ролей. Я и сам скептически относился к этому направлению, если рассматривать исключительно IT сектор.
В России фрилансеры – это прежде всего молодое поколение людей. Согласно исследованию, 68% из них находятся в диапазоне от 18 до 34 лет. Постепенно идет смена поколений. Получившие первый опыт работы и при этом привыкшие к фрилансу зуммеры с их приоритетами, начинают задавать зарождающийся сильный тренд. И его стоит учитывать в будущем. 💡 А еще лучше - воспользоваться этой тенденцией. Усилению тренда фриланса способствуют два фактора из предыдущего 2020 года: пандемия, развеявшая мифы об неэффективности удаленных сотрудников, а также увеличение доли безработных специалистов на рынке труда.
Россия пока догоняет мировые тренды с запозданием на несколько лет. И здесь можно ожидать сильного роста. Так по прогнозам до 2025 рынок фриланса в России вырастет в 2,5 раза в денежном выражении. Также можно ожидать и увеличения гонораров за счёт повышения среднего возраста фрилансеров и профессионализма. С обратной стороны к этому подталкивает конкуренции за качественный ресурс работодателей вследствие вымывания квалифицированных постоянных сотрудников. Это особенно остро прослеживается в малом и микробизнесе.
Фриланс по всей видимости пока останется узкоспециализированным решением для временных задач и проектов. При этом займет более конкурентноспособную позицию по сравнению с аутсорсингом и аутстаффингом, чем сейчас.
@aheadofthepack
Отличный подход к организации встреч для обсуждений чего-либо. Всегда нужно готовиться правильно и формировать заготовку на основании уже известной информации. Это позволит повысить продуктивность этих встреч и сэкономить дорогое время как консультанта, так и топ-менеджера.
Как проектировать что-то с топ-менеджментом
Решил написать какие основные правила и инструменты я использую при проектировании чего-то с топ-менеджментом. Они ниже.
1. Всегда приходи с прототипом - не приходите с белым листом, топ-менеджеры привыкли относится уже к какому-нибудь решению, а не "придумывать его". В его голове "придумывать его” - то, за что он вам платит.
2. Приходите со словами "Хотим посоветоваться", "Хотим услышать ваше мнение"
3. Для обсуждения используйте функциональную карту или концептуальную модель данных - на этих инструментах топ-менеджер готов высказываться и рисовать. На функциональной карте обычно легче проектируют топ-менеджеры ИТ, а на концептуальной модели данных - топ-менеджеры от бизнеса.
4. Используйте дорожную карту, когда вы обсуждаете что-то во времени
5. Принесите ваш «прототип» так, чтобы топ-менеджеру было легко на нем рисовать, например, в порядке опыта успешности: несколько распечатанных листов A4/A3 (это всегда на всякий случай носите); плакат; отображение с проектора на белую "доску" на которой можно рисовать или какая-то форма в которой в онлайн можно вместе рисовать (в PowerPoint есть эта функциональность) или yEd какой-нибудь для сложных концепций (там быстро можно накидать, а потом по кнопке упорядочить до красоты)...
P.S. Прототип может быть не полный, но все равно принесите его. Там где не понятно поставьте «…».
#практика #топ #архитектура #итстратегия #геронимус #лучшее
via @it_ace
💬 Комментировать
Решил написать какие основные правила и инструменты я использую при проектировании чего-то с топ-менеджментом. Они ниже.
1. Всегда приходи с прототипом - не приходите с белым листом, топ-менеджеры привыкли относится уже к какому-нибудь решению, а не "придумывать его". В его голове "придумывать его” - то, за что он вам платит.
2. Приходите со словами "Хотим посоветоваться", "Хотим услышать ваше мнение"
3. Для обсуждения используйте функциональную карту или концептуальную модель данных - на этих инструментах топ-менеджер готов высказываться и рисовать. На функциональной карте обычно легче проектируют топ-менеджеры ИТ, а на концептуальной модели данных - топ-менеджеры от бизнеса.
4. Используйте дорожную карту, когда вы обсуждаете что-то во времени
5. Принесите ваш «прототип» так, чтобы топ-менеджеру было легко на нем рисовать, например, в порядке опыта успешности: несколько распечатанных листов A4/A3 (это всегда на всякий случай носите); плакат; отображение с проектора на белую "доску" на которой можно рисовать или какая-то форма в которой в онлайн можно вместе рисовать (в PowerPoint есть эта функциональность) или yEd какой-нибудь для сложных концепций (там быстро можно накидать, а потом по кнопке упорядочить до красоты)...
P.S. Прототип может быть не полный, но все равно принесите его. Там где не понятно поставьте «…».
#практика #топ #архитектура #итстратегия #геронимус #лучшее
via @it_ace
💬 Комментировать
Инфраструктурная зависимость
Немного незапланированной рефлексии о будних.
Исторически сложилось (хорошее начало), что у нас часть сервисов, обеспечивающих разработку, находятся в "облаках", а часть на внутренней инфраструктуре. И несмотря на тенденцию миграции на различные SaaS, старое "инфраструктурное проклятие" периодически даёт о себе знать.
Проблемы случаются с завидной регулярностью. То сервер потребует администрирования и апгрейда, то электричество отключат на день другой. Пользуясь случаем, посылаю лучи добра на головы электриков, ремонтирующих это в рабочие время.
В результате, несмотря на мнимую децентрализацию и автономность рабочих мест, работа не работается. Нет, конечно, в период отсутствия доступности можно заняться полезными оффлайн обсуждениями. К примеру, незапланированной ретроспективой, или техническими митингами, утилизировав время. В крайнем случае переключиться на задачи, которые можно решить за счёт оставшейся облачной инфраструктуры. Но основные планы от этого не двигаются, и дедлайны срываются, что совсем не хорошо.
А сколько времени-денег уходит на поддержание этого внутреннего "богатства" в рабочем состоянии...
Один из разумных выходов для снижения таких непросчитываемых рисков - переход в облака на SaaS, или хотя бы на IaaS в какой-нибудь дата-центр.💡Не зря есть правило - аутсорсить все, что не является основной деятельностью фирмы. Как правило затраты окупаются с лихвой.
🤔💭Интересно, насколько SaaS решения сейчас вытеснили такие пережитки нулевых и начала десятых, как внутреннюю IT инфраструктуру?
@aheadofthepack
Немного незапланированной рефлексии о будних.
Исторически сложилось (хорошее начало), что у нас часть сервисов, обеспечивающих разработку, находятся в "облаках", а часть на внутренней инфраструктуре. И несмотря на тенденцию миграции на различные SaaS, старое "инфраструктурное проклятие" периодически даёт о себе знать.
Проблемы случаются с завидной регулярностью. То сервер потребует администрирования и апгрейда, то электричество отключат на день другой. Пользуясь случаем, посылаю лучи добра на головы электриков, ремонтирующих это в рабочие время.
В результате, несмотря на мнимую децентрализацию и автономность рабочих мест, работа не работается. Нет, конечно, в период отсутствия доступности можно заняться полезными оффлайн обсуждениями. К примеру, незапланированной ретроспективой, или техническими митингами, утилизировав время. В крайнем случае переключиться на задачи, которые можно решить за счёт оставшейся облачной инфраструктуры. Но основные планы от этого не двигаются, и дедлайны срываются, что совсем не хорошо.
А сколько времени-денег уходит на поддержание этого внутреннего "богатства" в рабочем состоянии...
Один из разумных выходов для снижения таких непросчитываемых рисков - переход в облака на SaaS, или хотя бы на IaaS в какой-нибудь дата-центр.💡Не зря есть правило - аутсорсить все, что не является основной деятельностью фирмы. Как правило затраты окупаются с лихвой.
🤔💭Интересно, насколько SaaS решения сейчас вытеснили такие пережитки нулевых и начала десятых, как внутреннюю IT инфраструктуру?
@aheadofthepack
Зачем тратить время на чужие исследовательские интервью?
Подход к исследованию потенциальных пользователей через анкетирование и разнотипные интервью развивается не один десяток лет. И несмотря на оцифровку большинства действий пользователей интервью в формате один на один исследователя с респондентом остаётся сильнейшим инструментом для построения гипотез и принятия решений по продукту.
Исследовательские интервью - лишь часть подхода Customer Development.
Время от времени я участвую в чужих интервью и анкетированиях. Разумеется, если тема мне оказывается близка и есть что рассказать и ответить.
С одной стороны, тратится собственное время и не всегда удобно вставлять чужую работу в планы. Однако, в прохождении чужих интервью есть куча плюсов, о которых не стоит забывать:
🍏 Как минимум можно посмотреть как другие делают эту интересную и сложную работу. Всегда найдется то, что можно подчерпнуть.
🍏 Можно получить некоторый опыт нахождения в чужой шкуре с обратной стороны интервью. Это возможно избавит вас самих от неочевидных ошибок и перегибов в работе.
🍏 Интервью иногда дают неожиданный нетворкинг с коллегами по цеху. Связи лишними не бывают.
🍏И даже если ничего из вышеперечисленного не произошло, просто делать что-то полезное уже неплохо. Потому что отзывчивых респондентов, которые готовы поделиться болями и инсайтами, для интервью найти не просто.
@aheadofthepack
Подход к исследованию потенциальных пользователей через анкетирование и разнотипные интервью развивается не один десяток лет. И несмотря на оцифровку большинства действий пользователей интервью в формате один на один исследователя с респондентом остаётся сильнейшим инструментом для построения гипотез и принятия решений по продукту.
Исследовательские интервью - лишь часть подхода Customer Development.
Время от времени я участвую в чужих интервью и анкетированиях. Разумеется, если тема мне оказывается близка и есть что рассказать и ответить.
С одной стороны, тратится собственное время и не всегда удобно вставлять чужую работу в планы. Однако, в прохождении чужих интервью есть куча плюсов, о которых не стоит забывать:
🍏 Как минимум можно посмотреть как другие делают эту интересную и сложную работу. Всегда найдется то, что можно подчерпнуть.
🍏 Можно получить некоторый опыт нахождения в чужой шкуре с обратной стороны интервью. Это возможно избавит вас самих от неочевидных ошибок и перегибов в работе.
🍏 Интервью иногда дают неожиданный нетворкинг с коллегами по цеху. Связи лишними не бывают.
🍏И даже если ничего из вышеперечисленного не произошло, просто делать что-то полезное уже неплохо. Потому что отзывчивых респондентов, которые готовы поделиться болями и инсайтами, для интервью найти не просто.
@aheadofthepack
Испорченный телефон
Знаете, как осуществляется коммуникация? Мы обдумываем что-то, потом кодируем это в слова и фразы в соответствии с представлениями об сущностях и процессах. Передаем сообщения второй стороне через голос. В процессе разговора добавляется посторонний шум и различные технические потери (отвлекся, не услышал, перепутал). Вторая сторона – получатель декодирует информацию в обратную сторону. Но, внимание, словарь терминов может несколько отличаться, т к у каждого свой опыт, свои знания и свои модели.
На каждом из этапов возможны ошибки и это обычная история. Чем длиннее цепочка переноса информации, чем больше в неё включено лиц, тем больше ошибок происходит и тем сильнее накопленные ошибки усиливаются.
Во всех организациях есть та или иная степень иерархии. Часто бывает бизнес-процесс строится так, что информационные сообщения проходит кучу инстанции, чтобы попасть к адресату. Каждому менеджеру в иерархичной организации хочется быть важной прокладкой, обеспечивающей «надежное» взаимодействие, чтобы оградить кого-то от чего-то. От избытка информационного потока, лишней конфиденциальной информации, дополнительных оценочных данных… А если в процесс задействованы несколько организаций, все становится в разы хуже. Когда информация, пройдя несколько таких «точек демаркации», меняется кардинальным образом и утрачивает смысл.
За последние несколько лет постоянно экспериментирую с бизнес-процессами в разных местах. И пока не нашел универсального шаблона, который мог бы без изменений ложиться на любую, уже устоявшуюся структуру. Везде приходится работать и с процессами, и с ролями одновременно.
Все больше организационных структур тяготеют в сторону уплощения иерархии. Несмотря на децентрализацию, качество, а следовательно, и эффективность обмена информацией при этом растет. При правильных процессах уменьшаются и задержки получения информации заинтересованным адресатом.
@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