Хотите прокачать навык по сбору проблем и подтверждению гипотез с пользой для здоровья? Сходите на приём к врачу и запишите разговор с ним. Ведь врач на приёме занимается именно проблемным интервью: — Что беспокоит? — Когда началось? — Колет или тянет? — Какие лекарства принимали? — ...
Весь таймменеджмент умещается в одну фразу: "Понять, что можно просрать, а что нельзя, и сосредоточиться на втором". Любой другой выбор - лишь иллюзия, такая же, как и у ребёнка, которого спрашивают: "Какую кашу ты будешь: манную или овсяную?". Всегда есть внешние обстоятельства, которые диктуют нам контекст, в котором мы делаем тот самый, единственный выбор. Работаешь в найме - контекст задаёт руководитель. Ты глава собственной фирмы - контекст зависит от договоров с клиентами и дат выплат ЗП сотрудникам. Отличие взрослого от ребёнка в том, что взрослый может сам выбирать свой контекст - например, работать по найму или открыть собственный бизнес. Но это выбор не имеет к таймменеджменту никакого отношения.
Утренний стендап - это инструмент, в первую очередь, менеджера. Именно здесь менеджер продукта понимает, работает ли его команда по процессу, или внутри царит "творческий беспорядок". Процесс необходим для повторяемости результата. Для продукта это даже более важно, чем для проекта. Ежедневный стендап - это инструмент внутри операционного цикла, из котрого сам менеджер должен быть исключён. Задача менеджера помогать команде поддерживать и развивать процессы.
Обсуждать нужно и важно! Но часто аргументы двух точек зрения скатываются из области фактов в область гипотез, домыслов и частных точек зрения. Само по себе это неплохо, но съедается уйма времени на демагогию - это факты обсуждать быстро. Их интерпретациию дольше, но тоже недолго. А вот фантазии... Как только вы заметили, что диалог из фактов перешёл на гипотезы - остановитесь. И попробуйте обсудить, для какой из гипотез будет проще и быстрее собрать факты. Вот на ней и фокусируйтесь. На сборе фактов для её доказательства или опровержения. Сэкономите кучу времени!
Техническая красота решения имеет чёткие бизнесовые показатели - скорость, стоимость поддержки, удовлетворённость команды. Когда программист говорит: "А давайте всё это Г перепишем заново, а то оно ужасно написано", подумайте, какой показатель от этого изменения "выстрелит": - Уменьшится время на борьбу с багами при выходе новых версий? - увеличится time2market? - Уменьшится число критичных (когда бизнес-пользователь не может выполнить свою работу даже обходным путём) инцидентов? Если нет или не можете посчитать, значит, эта красота мнимая. С другой стороны, у разработки появляется чёткий водораздел - хочешь переписать, покажи прирост по этим показателям. Научись их считать. Ну, и сами не будьте сквалыгами - задачи, которые нужно...
Очень часто происходит подмена понятий и на ретроспективе (или пост-анализе) начинают отвечать на вопрос "почему мы что-то не сделали". Вопрос важный, обсуждать и находить ответы на него нужно, но не нужно назвать это ретроспективой. Это проблема. Смешно слушать, когда диалог складывается примерно как: "Мы не смогли добежать до туалета, но мы всё равно молодцы, потому что можем отложить в баночку на анализы, авось, пригодится, коли не протухнет".
На одной из ретроспектив я с удивлением услышал благодарность продукт-менеджеру от одного из участников команды: "Спасибо за то, что ты знаешь, как работает наш продукт и отвечаешь на наши вопросы даже по ночам!". В моей парадигме управления продуктом такая ситуация - это мегафейл! Знания о продукте должны быть общими, их должно быть можно получить без обращения к менеджеру или коллеге по команде. Без этого у нас дикие риски остаться без знаний, низкая скорость выхода новых фич и высокие риски изменениями поломать что-то "переделав логику из лучших побуждений". Но команда с удовольствием приняла высказывание, менеджеру продукта такая похвала тоже пришлась в удовольствие. А самое главное, что это всё происходило в компании, которая...
Одна из важнейших метрик продуктовых команд - полезность результата за единицу времени. Будь то спринт, релиз или квартальный цикл - у пользователей и стейкхолдеров должно быть стойкое ощущение полезности того результата работы, который вы им показываете. Для этого важно рассказывать не о функциях, а о самих пользователях. Что они смогут теперь делать или чего не делать. Не "у нас теперь есть трекер всех поступающих обращений", а "теперь ваши обращении не будут теряться, благодаря новому трекеру. Вы сможете в любой момент понять, в каком статусе и за кем закреплено обращение, а на само обращение обязательно будет получен ответ".
Из невольно подслушанного на кухне: "Если мы это сделаем, то опять будут жаловаться вот на это, а значит, да ну его нафиг". Мы люди и мы склонны принимать комфортные для себя решения. Но, зачастую, этот комфорт ведёт к тому, что мы не принимаем решений, которые серьезно что-меняют. Мы остаёмся к привычном круге проблем и решений. Это очень понятно - в этом меньше риска и меньше трудозатрат.
В любом холиваре, в любом затянувшемся споре есть то, что остаётся за кадром, но это именно то, что и приводит к отсутствию решения на протяжении долгого времени. Это точка приложения усилий. Чем разнообразнее те, кого мы пытаемся свести воедино, тем сильнее сопротивление. Представьте себе батут, размер которого зависит от этого разнообразия. Причём, не сколько от разнообразия результатов - всегда можно найти высокоуровневый результат, который будет по душе почти всем, - сколько про разнообразие самих людей, которые будут пользоваться вашим решением. От их привычек, взглядов, стереотипов. И чем больше площадь батута, тем больше силы нужно приложить к нему, чтобы выполнить какой-то пируэт, а не просто барахтаться у поверхности.