ИТ-Перец

Врач - лучший учитель по CustDev

2022-06-24T10:32:47.544Z

Хотите прокачать навык по сбору проблем и подтверждению гипотез с пользой для здоровья? Сходите на приём к врачу и запишите разговор с ним. Ведь врач на приёме занимается именно проблемным интервью:
— Что беспокоит?
— Когда началось?
— Колет или тянет?
— Какие лекарства принимали?
— ...

Каждый вопрос - это вопрос о вас, о вашей жизни и, одновременно, проверка гипотезы:
— Больнее, когда нажимаю или когда отпускаю?
— Когда надавливаете
— Значит, вероятность аппендицита низкая.

Ровно этим занимается менеджер продукта. И основная ошибка - задавать вопросы, подтверждающие гипотезу, которую менеджеру хочется подтвердить:
— Вы бы купили за миллион эту потрясающую машинку для завязывания шнурков?
— Конечно, какой разговор! Как только у вас появится машинка - первым делом ко мне! (возможно, у меня уже появится к этому времени лишний миллион на открытие музея самых идиотских изобретений человечества)

Готовитесь к интервью - задайте себе мысленно вопрос: "А не похож ли я на врача, которому нравится лечить аппендицит и он всем средствами пытается обнаружить его у пациента?". И составляйте вопросы так, чтобы не быть таким врачом:
— Какую обувь предпочитаете?
— Спортивную, в основном - кеды, кроссы
— Вы завязываете шнурки на них сидя или стоя?
— Я вообще не завязываю, так как купил эластичные и просто надеваю
— А бегом вы занимаетесь?
— Конечно! Два-три раза в неделю бегаю.
— И на спортивных кроссах тоже используете эластичные шнурки?
— Нет, там, конечно, обычные, чтобы лучше держали ногу.
— Доверили бы машинке завязать шнурки на спортивных кроссах, чтобы не наклоняться к ним?
— Нет, мне важно чувствовать силу затяжки. И, кстати, я не наклоняюсь, я всегда завязываю сидя, поставив ногу на пятку, чтобы правильно расположить кроссовок на ноге.
— Круто, не знал! А зимой тоже бегаете?
— Зимой мне нравятся коньки. Кстати, там как раз такой гемор со шнуровкой и разшнуровкой - каждый виточек затяни, потом растяни...

Ну, а если пока не получается кастдевить - не трать деньги на курсы, просто сходи к врачу :)

Всё, что надо знать о таймменеджменте

2022-06-03T05:52:42.227Z

Весь таймменеджмент умещается в одну фразу: "Понять, что можно просрать, а что нельзя, и сосредоточиться на втором". Любой другой выбор - лишь иллюзия, такая же, как и у ребёнка, которого спрашивают: "Какую кашу ты будешь: манную или овсяную?". Всегда есть внешние обстоятельства, которые диктуют нам контекст, в котором мы делаем тот самый, единственный выбор. Работаешь в найме - контекст задаёт руководитель. Ты глава собственной фирмы - контекст зависит от договоров с клиентами и дат выплат ЗП сотрудникам. Отличие взрослого от ребёнка в том, что взрослый может сам выбирать свой контекст - например, работать по найму или открыть собственный бизнес. Но это выбор не имеет к таймменеджменту никакого отношения.

Собственно, прочитав мой пост, вы теперь можете не читать больше ни одной книги про таймменеджмент, ибо, отжав воду, вы получите ровно ту заветную фразу :)

Мифы и легенды утреннего стендапа

2021-11-16T19:59:44.637Z

Утренний стендап - это инструмент, в первую очередь, менеджера. Именно здесь менеджер продукта понимает, работает ли его команда по процессу, или внутри царит "творческий беспорядок". Процесс необходим для повторяемости результата. Для продукта это даже более важно, чем для проекта. Ежедневный стендап - это инструмент внутри операционного цикла, из котрого сам менеджер должен быть исключён. Задача менеджера помогать команде поддерживать и развивать процессы.

К стендапу нужно готовиться. Как участникам команды разработки, так и менеджеру. Первым - привести в порядок карточки в трекере, оценить риски и сложности текущих задач, подумать, с кем нужно провзаимодействовать, чтобы задача успешно решилась. Менеджер должен понять, какие задачи лежат на критическом пути спринта и задать вопросы по ним.

Если такая подготовка происходит, то стендап проходит действительно быстро - каждый по очереди называет номер и суть задачи, что было сделано за день, и что планируется сделать за сегодня. Кто и по какому вопросу нужен. Если на вопрос "что сделано вчера" или "чем планируешь заниматься сегодня" человек начинает долго думать и пространно рассуждать - менеджеру стоит задуматься о процессах внутри команды.

Как говорить меньше, а делать больше

2021-11-16T19:57:10.916Z

Обсуждать нужно и важно! Но часто аргументы двух точек зрения скатываются из области фактов в область гипотез, домыслов и частных точек зрения. Само по себе это неплохо, но съедается уйма времени на демагогию - это факты обсуждать быстро. Их интерпретациию дольше, но тоже недолго. А вот фантазии... Как только вы заметили, что диалог из фактов перешёл на гипотезы - остановитесь. И попробуйте обсудить, для какой из гипотез будет проще и быстрее собрать факты. Вот на ней и фокусируйтесь. На сборе фактов для её доказательства или опровержения. Сэкономите кучу времени!

Техническая красота решения

2021-03-26T11:32:59.970Z

Техническая красота решения имеет чёткие бизнесовые показатели - скорость, стоимость поддержки, удовлетворённость команды. Когда программист говорит: "А давайте всё это Г перепишем заново, а то оно ужасно написано", подумайте, какой показатель от этого изменения "выстрелит":
- Уменьшится время на борьбу с багами при выходе новых версий?
- увеличится time2market?
- Уменьшится число критичных (когда бизнес-пользователь не может выполнить свою работу даже обходным путём) инцидентов?
Если нет или не можете посчитать, значит, эта красота мнимая. С другой стороны, у разработки появляется чёткий водораздел - хочешь переписать, покажи прирост по этим показателям. Научись их считать. Ну, и сами не будьте сквалыгами - задачи, которые нужно сделать, чтобы начать собирать метрики, должны попадать в спринт, а не лежать вечно на задворках бэклога. Если хотим снизить баги при выходе новых версий - давайте время на юнит и автотетсты.

Отдельно хочу рассказать про удовлетворённость команды. Это важная составляющая для эффективной работы. Никому не нравится ковыряться в плохо структурированном коде, нарисованном фиг знает когда фиг знает кем. Если понимаете, что люди киснут, ищите новые задачи, которые можно попробовать решить новыми технологиями. Да, иногда это может быть "больно" в плане появления "зоопарка технологий", но тут приходится выбирать из двух зол - либо забить на эффективное и интенсивное развитие продукта, либо потерпеть переходный период к целевой технологии, но таки расти и развиваться функционально. Выбор в каждом случае свой.

Ретроспектива - это анализ сделанного, а не ответ на вопрос "почему не сделали"

2021-03-26T11:23:24.417Z

Очень часто происходит подмена понятий и на ретроспективе (или пост-анализе) начинают отвечать на вопрос "почему мы что-то не сделали". Вопрос важный, обсуждать и находить ответы на него нужно, но не нужно назвать это ретроспективой. Это проблема. Смешно слушать, когда диалог складывается примерно как: "Мы не смогли добежать до туалета, но мы всё равно молодцы, потому что можем отложить в баночку на анализы, авось, пригодится, коли не протухнет".

Ретроспектива нужна, когда есть зафиксированный результат. Достигнутая и подтвержденная ценность. И тогда важно понять, почему "нам было так сложно получить результат" или "почему нам пришлось потратить больше бюджета". Даже "почему мы не уложились в сроки" - хороший вопрос для разбора на ретре. Но в контексте полученного результата. Этот опыт даст возможность меньше ошибаться на следующем шаге, на следующей итерации.

Так же, на ретроспективе, важно не забывать и о позитивных рисках - "почему мы смогли сделать это быстрее, чем планировали" или "почему нам было это сделать проще, чем планировали". Без результата эти вопросы бесполезны, а значит и ценности у ретроспективы будет в несколько раз меньше.

Поэтому, если есть коммит - сжимаем зубы и получаем результат, проводим ретру, а потом уже даём более выполнимый коммит и работаем в спокойном режиме.

Всегда есть те, для кого проблема будет преимуществом

2021-03-26T11:16:50.882Z

На одной из ретроспектив я с удивлением услышал благодарность продукт-менеджеру от одного из участников команды: "Спасибо за то, что ты знаешь, как работает наш продукт и отвечаешь на наши вопросы даже по ночам!". В моей парадигме управления продуктом такая ситуация - это мегафейл! Знания о продукте должны быть общими, их должно быть можно получить без обращения к менеджеру или коллеге по команде. Без этого у нас дикие риски остаться без знаний, низкая скорость выхода новых фич и высокие риски изменениями поломать что-то "переделав логику из лучших побуждений". Но команда с удовольствием приняла высказывание, менеджеру продукта такая похвала тоже пришлась в удовольствие. А самое главное, что это всё происходило в компании, которая показывает уверенный рост и занимает далеко не последнее место на своём рынке.

Мораль сей басни очень проста. Ценностная модель любой системы управления должна строиться от стратегических целей и решаемых задач. Не бывает хороших или плохих методов управления. Бывает лишь подходящие под ситуацию и неподходящие.

Получать результат за единицу времени

2021-03-26T09:34:15.626Z

Одна из важнейших метрик продуктовых команд - полезность результата за единицу времени. Будь то спринт, релиз или квартальный цикл - у пользователей и стейкхолдеров должно быть стойкое ощущение полезности того результата работы, который вы им показываете. Для этого важно рассказывать не о функциях, а о самих пользователях. Что они смогут теперь делать или чего не делать. Не "у нас теперь есть трекер всех поступающих обращений", а "теперь ваши обращении не будут теряться, благодаря новому трекеру. Вы сможете в любой момент понять, в каком статусе и за кем закреплено обращение, а на само обращение обязательно будет получен ответ".

Как получать ценность в каждую единицу времени? Я использую три способа

Ценность пользователя транслируется всей команде.
Это происходит, в первую очередь, на уровне языка. Даже программисты разговаривают терминами, понятными пользователям. Например, названия модулей, блоков или частей продукта совпадают с названиями ролей пользователей. Пусть даже код лежит в одном репозитории и изменяется под задачи пользователя настройками зон видимости.
Постановка задачи должна включать ответ на вопрос "чтобы что?"
Это и расширяет трансляцию ценностей, и даёт любому участнику команды правильный ценностный контекст. "Я, пользователь, хочу отчёт, чтобы показать руководителю динамику своей работы". "Я, пользователь, хочу отчёт, чтобы выстроить приоритеты для собственной деятельности". Почувствуйте разницу в контекстах.
Не надо делать слишком хорошо. Сделай нормально, но сделай.

В кейсе про трекер, конечно, главной ценностью было, в итоге, соблюдение SLA и снижение потерь от инцидентов. Но за один прыжок в неё не попасть, это игра в долгую. Плюс, надо не забывать, что в таком продукте основную ценность приносит не ИТ-программа, а процессы, которые выстраиваются вокруг автоматизированного workflow. На первой итерации мы действительно просто развернули трекер. У нас не было настроенных процессов, в форме была куча ненужных или непонятных полей, не всегда было понятно, кому маршрутизировать заявку. Но мы работали на одну метрику - 100% заявок должны получить ответ. Мы её выполнили, пользователи нам поверили. Поверили, что мы можем не только показывать красивые картинки. А мы получили опыт, который потом трансформировали в формальные процессы, базу знаний, инструкции для линий поддержки. Главное - делать.

Это создаст проблемы

2021-03-13T23:39:01.557Z

Из невольно подслушанного на кухне: "Если мы это сделаем, то опять будут жаловаться вот на это, а значит, да ну его нафиг". Мы люди и мы склонны принимать комфортные для себя решения. Но, зачастую, этот комфорт ведёт к тому, что мы не принимаем решений, которые серьезно что-меняют. Мы остаёмся к привычном круге проблем и решений. Это очень понятно - в этом меньше риска и меньше трудозатрат.

Избежать "ловушки обыденности", просто, если сначала сопоставить масштабы влияния изменения и масштаб влияния проблем. Если тех, кому изменения принесут ценность, ощутимо больше тех, кому принесут проблемы, значит, можно рисовать диаграмму Исикавы и оценивать пути решения новых проблем.

Стоит помнить, что любое решение для кого-то будет хорошим, для кого-то плохим. "Оптимум" - это когда при прочих равных влияние недовольных на продукт минимально.

Точка приложения силы

2021-03-13T23:02:56.760Z

В любом холиваре, в любом затянувшемся споре есть то, что остаётся за кадром, но это именно то, что и приводит к отсутствию решения на протяжении долгого времени. Это точка приложения усилий. Чем разнообразнее те, кого мы пытаемся свести воедино, тем сильнее сопротивление. Представьте себе батут, размер которого зависит от этого разнообразия. Причём, не сколько от разнообразия результатов - всегда можно найти высокоуровневый результат, который будет по душе почти всем, - сколько про разнообразие самих людей, которые будут пользоваться вашим решением. От их привычек, взглядов, стереотипов. И чем больше площадь батута, тем больше силы нужно приложить к нему, чтобы выполнить какой-то пируэт, а не просто барахтаться у поверхности.

Сила - обычно, величина постоянная - это наши возможности. Их можно прокачивать, развивать, увеличивать. Но это долго, дорого и всегда имеет предел. Если у вас накопился большой пул задач, который требует увеличения силы для их реализации - больше людей в команде, больше денег, больше времени, больше знаний, то попробуйте поменять точку приложения усилий:

Сфокусируйтесь только на данных, которым будет пользоваться ваше решение. Получать от пользователей, хранить, показывать пользователю
Сделайте обобщённую модель данных - объекты, атрибуты, взаимосвязи
Сделайте неуниверсальное решение для одной только группы пользователей
Добавьте функций для другой группы так, чтобы модель данных не поменялась
Повторите столько раз, сколько было разных мнений.

Таким образом вы сможете управлять получением одинакового результата при разности процессов. И двигаться вперёд уже теми силами, которые есть у вас сейчас.

Пример из практики. У одной крупной компании есть портал, на который подразделения скидывают заявки на потребности в том или ином оборудовании, расходных материалах, офисных расходниках. Проблема была в том, что заявок было много, ответственное подразделение не справлялось со своевременной закупкой, самой дорогой операцией было сведение всех заявок воедино по номенклатуре. Без этого сложно было попасть в минимальные партии поставщиков, а заключать договор с новым поставщиком для компании было сложно и дорого. В компании несколько раз пытались подойти к стандартизации номенклатуры, чтобы заказыали "всегда одну и ту же позицию в категории и не выпендривались", но это неизменно приводило к ухудшению производственных показателей и появлению десятков позиций "Другое" с запросом в комментарии. Точка приложения силы "сделать единый процесс заказа с едиными принципами и справочниками" оказалась слишком "плотной" и кульбит не получался.

Для решения этого кейса я поменял точку приложения усилий. Я разделил тех пользователей, которые готовы ждать чего-то конкретно под себя, и пользователей, которым нужно пользоваться чем-то здесь и сейчас. Среди вторых провел голосование, вопрос звучал так: "Пока идёт закупка именно того товара, который вам нужен, каким аналогом вы готовы пользоваться во время ожидания?". И вытащил в качестве ответов те названия из комментариев для позиции "Другие". Таким образом, я получил перечень того, что не должно кончаться на складе. Выдача "стандартного аналога" должна была происходить без ожидания закупки, закупка этих позиций должна была стать превентивной. Там, где две позиции набрали очень близкое количество голосов при существенном отставании остальных, я рекомендовал обе к превентивной закупке.

Для второй группы пользователей я предложил принцип аукциона. Общаясь с представителями этой группы, я подметил, что желание начать пользоваться чем-то нетиповым, обычно возникало, когда кто-то из коллег начинал этим пользоваться. Поэтому я сделал возможность поиска по коллеге - заказать что-то "как у Васи из бухгалтерии". А для тех, кто создаёт заявку на нетиповое оборудование, я добавил поля "опыт использования" и "фотографии и из реальной жизни". Так же, переструктурировал главную страницу - туда выводились заявки относительно людей и "истории успеха" - "Вася хотел такую штуку, к нему присоединились Петя и Катя, теперь они пользуются крутыми вещами, именно теми, какими хотели".

Решение для первой группы было сделать просто - там ничего не пришлось дорабатывать, всё закрылось управленческими решениями и правкой справочников. Мы его сделали, пока шло проектирование решений для второй группы. Решение для второй группы пользователей потребовало программирования. По сути, мы дали каждому сотруднику выбор - или пользоваться стандартным, но уже "здесь и сейчас", или становиться драйвером чего-то нового, набирая голоса коллег. Прошёл год и практика показала, что большинство сотрудников стали выбирать пользоваться стандартным здесь и сейчас, нежели заказывать что-то уникальное. И производственные показатели не падали. Таким образом, поменяв точку приложения усилий, я получил работающее решение для всех групп пользователей.