Данные и управленческое решение

Я перестал принимать решение без данных.

«Ну что решаем?» - Вопрос может вызвать фрустрацию и оттягивание.

Решение - это выбор. Мозг компьютер, ему нужно сравнить: «ноль или один», чтобы выбрать. А что сравнить? Какие у этих «что» параметры?

Если нужно решить здесь и сейчас
Выгрузить из своего опыта примерные параметры и выдумать данные. То есть прикинуть. Хотя бы так, но решение есть.

Если есть немного времени
Прикинуть параметры объекта выбора или узнать их. Понять кто может знать данные. Собрать их. Сравнить и выдать решение.

Если есть время
Помимо вышеперечисленного - нужно посчитать. Excel-ка наше все) Тогда решение будет точным.

Поэтому важный вопрос для принятия решения - это «сколько у меня есть времени».

Так или иначе, мы все равно принимаем решение на каких-то данных. Качество решения зависит от того осознаем ли мы данные или нет)

5АМ | #управление

Атака и оборона

Я как то писал, что у меня военный бэкграунд, так вот у меня иногда всплывают военные метафоры по отношению к разработке и управлению командой😁

Я заметил, что разработка идет крупными волнами. Намечаем план новых фич и фич под изменение и команда начинает фигачить) То есть - "атакует")) Мы набираем массу доки, кода, макетов, где-то конечно же говнякаем, а где-то приходят новые идеи как от команды, так и от пользователей. В общем проект обрастает новым.

После такого напряжения неизбежно наступает откат, команда переходит в "оборону". Рефачит доку, дизайн, код, проводится более спокойное и глубокое тестирование там, где не дотестили) Более спокойный период, чтобы восстановиться-прилизаться и снова вперед)

Вот мы сейчас в обороне, потому что был долгий период фичивания, команде нужно выдохнуть и поработать в спокойном темпе.

Я конечно понимаю, что разработка идет постоянно. Это больше аналогия с внутренним состоянием команды что ли)

5АМ | #управление

Тут такие крутые вопросы подъехали на пост про деление запросов на оперативные проекты, а я пропустил их, жуть) Возвращаюсь, смотрите что получилось)

Почитал профиль Даши. Она product owner у крутого онлайн банка Revolut, а раньше была продактом в Ozon)

Хочу сделать PS) У нас стартап, мы пилим свои процессы и делаем так, чтобы они были оптимизированы под наши ресурсы; чтобы найти баланс и не скатиться в бардак, но и не умереть в бюрократии. В корпорациях не часто встретишь excel, чаще либо самописные системы либо оплаченные "по зубы" Jira-ы) Поэтому не бейте "корпоративными" ногами😄

Получилось жирненько, поэтому разбил на два сообщения) 🔽

5АМ | #управление

"ну бьются, и что? как это применять в планировании? дальше об этом ни слова вроде бы"

Давай на примере) Вот есть запрос "хочу заказать пропуск через КПП, даже если я не знаю данных того, кто приедет. Я готов оплатить проезд". У человека есть работа. Чтобы наняться на неё нам нужно: провести аналитику и запаковать её в доку, разработать/доработать дизайн, разработать/поправить бэк, разработать/доработать фронт, протестировать. Каждое направление: аналитика, дизайн, бэкенд, фронтенд, QA выполняют свою работу, выдавая результат. Мы опускаем всю болталогию как связку между этими направлениями, берем pure result) Дока, Макет, Код, Отчет. 4 крупных результата, в результате которых будет релиз с доставкой решения этого запроса. В данном примере нам нужно 4 проекта-эпика на операционный уровень управления (например в Notion). Каждый из них может занимать от двух недель до месяца-полутора. Roadmap-a (тактическая) выстраивается из этих 4-х проектов-эпиков, каждый из которых ведет к результату и, как правило, блокирует следующий проект, так как, например, сделать дизайн без аналитики можно, но получится хреново)

Как это применить: Выводим запрос. Формализуем требования. Закидываем 4 проекта с примерными сроками на роадмапу. Запускаем бизнес анализ, который выводит процесс и ключевые точки/стыки процесса. Из него выводим анализ данных. Из них фичи. Описываем фичи. Тут уже можно сесть с командой и накинуть оценку. Из всех описаний накидываем в задачу "ТЗ-ху", данные то все уже есть. Корректируем сроки наших 4-х проектов. Запускаем проектирование дизайна и так далее по порядку. Роадмапа появляется сразу. А так как запрос не появляется в вакууме, то можно сразу прикинь как отработка запроса дружит с остальными проектами-эпиками.

Плюсы:
- сразу появляется роадмапа и синхронизация
- с каждым шагом сроки и оценка финансов корректируются

"«просто сам запрос является проектом» — ?"

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

Возможно тут недопонимание в том, что я называю проектом, потому что это цикл статей. Вот ссылочка на пост, где я пишу про "Оперативные" проекты)

"откуда взялось деление проектов по таймлайну месяц или меньше? почему именно эти 2 варианта?"

На самом деле - чисто из опыта. Поставить решение крупного запроса всегда занимает по опыту от месяца до трех. Если запрос меньше, то как правило до двух-трех недель. Все еще зависит от бюрократизации процесса конечно. Я после уже написал пост про оценку в рамках цикла)

Записать на это все скринкаст в луме? - 🔥

5AM | #управление

"Отец" и "Сын" продукта

Раньше, когда люди делали реально крутые вещи: ракеты, интернет и марсоходы, роль продакта была у главного инженера) Его видение охватывало весь продукт, поэтому их называли отцами продукта😁 20-30 лет назад продакты начали рождаться из профессии инженера, маркетолога, дизайнера. Был бэкграунд, опыт, а сейчас продакты ныряют в профессии после института и курсов. Мои преподаватели из Академии ФСБ тоже сетовали, что во времена КГБ в академию поступали после опыта армии и пары заводов.

Именно это приводит к тому, что у product-ов все никак не очертится их роль и в зависимости от размера компании продакт выполняет свои задачи по-разному. А когда корпоративный мир всем остальным сказал, что нам еще и owner-ы нужны оказывается — путаница увеличилась)

Масштаб - вот отличие между ними

Допустим большая картина, к примеру, "Явление Христа народу" А. Иванова. (Оффтоп эмоции - вы её видели вообще эту махину, 5х7 м? вот он - продакт менеджер "отец"😂).

Продакт думает за масштаб: какой должна быть картина, почему именно такой, почему понравится зрителям, что на ней должно быть, в какой позе должны быть персонажи, кто заказчик, как деньги платит, кому продать её потом?) Он смотрит на все без кадрирования (кроп-а), даже за рамками картины. Оwner же общается с поставщиками красок, контролирует наброски каждого эскиза(фичи) картины (Иванов сделал более 600-т эскизов), строит роадмапы, пинает Иванова "когда"!?, говорит что "вот должен быть Христос, должен быть народ")) Ну вы поняли)

Продакт и овнер - это два альтер эго Иванова))

Продакт - общается с князем Александром (тот, что потом станет императором). Овнер - пинает Иванова делать картину (20 лет делал) и говорит как надо.
Продакт - мыслитель. Овнер - реализатор.
Продакт - комбинатор. Овнер - соединитель.
Продакт - в медитации. Овнер - в суете.
Продакт - Отец. Овнер - сын😄

5АМ | #управление

Психологический контакт

Одной из учебных тем в Академии ФСБ была "Психологический контакт". Для предпринимателя, руководителя очень важно уметь в это, например, с клиентами, новыми сотрудниками, коллегами. Ведь когда ты расположил человека, цели достигаются быстрее. И не только ваши, но и этого человека. Главная задача - снять психологический барьер.

Мой топ методик по установке психологического контакта:

✏️Сделать так, чтобы человек захотел говорить о себе
Не все мы хотим говорить о себе, но любим это делать. Снимая акцент со своего эго на собеседника, вы входите в позицию слушателя. Умение слышать человека - это важный навык. Причем то, что вы слушаете отражается во всём: поза, жестикуляция, мимика. Любой человек тащит за собой груз проблем и поделиться ими всегда облегчение, за это мы подсознательны благодарны и располагаемся к слушателю. Как сделать: задавать уточняющие вопросы с открытым ответом.

✏️Обращаться по имени
Тут все просто. Если вы чаще обращаетесь по имени, то человек быстрее увидит в вас друга и будет расположен. Это переход в ближний круг.

✏️Узнать факты о человеке заранее
Полученную информацию можно использовать в общении, задать уточняющий вопрос (для первого пункта важно) или найти общие интересы заранее и поднять их. Все это сблизит вас и уберет барьеры. Как найти: соц. сети, резюме, да даже физиогномика)

✏️Подстраиваться
Мимикрировать - сложный, но интересный навык. Человек серьезный - не нужно вести себя расхлябано, соберись, выправь осанку, поменяй тон. Человек более расслабленный - расслабьтесь, измените манеру поведения. Тут важна методика прощупывания и предыдущий пункт. Можно конечно поговорить и о НЛП, но тут все просто: повторяйте манеры и действия человека.

✏️Будьте приятными, шутите и улыбайтесь
По социальным меркам нужно быть приятным. Нужно следить за собой, особенно мужчине) Если вы не приятны и не опрятны, то это не поможет снять блок. Шутки могут снять барьер, а улыбка расположит к себе. Это базовая вещь.

Вы скажите: "Фу! Это манипуляции". Да, если ты используешь это только ради своей выгоды. Все решает умысел. А вот расположить к себе, чтобы быстрее достигать общего результата или быстрее понять мотивацию человека, чтобы не тратить время и ресурсы - это очень важно.

Важно: все это не работает без одного компонента - искренности. Нет искренности - вам не поверят и псих. контакт не установить)

Звучит страшно, но если посмотреть на это не с конспирологической точки зрения, то перед вами будет просто адекватный человек, который пытается подружиться с вами, и достаточно интеллектуальный, если пытается удержать все это в голове, следя за собой и вами. Наоборот нужно быть благодарным. Так что не кидайтесь какашками, мои дорогие))

5АМ | #управление

Февраль, 2001-й год. Горнолыжный курорт Snowbird в США. Встретились как-то 17 мужиков из сферы разработки ПО, которых задолбало описывать работу кода и рисовать UML диаграмки, которые будут пылиться на полках в папках и не обновляться, при этом не написав ни строчки кода. И договорились, что весь мир будет дальше болтать по Zoom, пить латте на кокосовом и обсуждать "прибить или приклеить". Ну а если серьезно: написали они 12-ть принципов Agile)

Поговорим о том, почему Agile - это, блин, дорого 😭

5АМ | #управление

Вообще, тема стара как мир. Сократ, Зенон, Диоген, софисты развлекались в древности с инфой как могли) В основе всего лежит научный метод, который дает способы исследования и формулирования выводов на базе данных, которые мы добываем эмпирически. Еще стоики определили: хорош теоретизировать - подтверди практикой.

В конце концов вывели гипотетико-дедуктивную модель из 4-х шагов: исследуй для формирования опыта, выведи гипотезы, доведи до результата, проверь на фактах. Ни на что не похоже? Scrum кажется)

Крупные циклы разработки ПО делятся по направлениям: аналитика, прототипирование, дизайн, бэкэнд, фронт, тестирование. Каждый производит свой набор результатов, причем как факт: следующий участник направления будет делать свою работу хуже, если нет результата от предыдущего.

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

Вот тут-то и кроется главная цель у Agile и его фреймворков (еще по научному методу) - это проверить идею (гипотезу). Поэтому появился Scrum - "А давайте накидывать идеи и быстро-быстро все вместе делать и обсуждать все постоянно". А потом Альфа банк такой - Scrum Master 250 000 руб. ваша задача (цитата): "Организовать работу коллектива так, чтобы они вместе генерили идеи". А скрам мастер помогает продакт оунеру еще, который тоже за 250к. Scrum - это высшая точка усложнения методики, поэтому смотрю на него. Kanban хотя бы просто про воронку и стикеры на досочке)

Чтобы скрам работал:
- Нужно, чтобы PM и PO хорошо поработали над требованиями, чтобы хорошо поработать нужно провести исследование и написать аналитику с выводами, поэтому нужны аналитики. (750-900к руб. + полис ДМС)
- Нужен скрам мастер, который будет бегать и пинать всех, писать и обновлять цели, постоянно совещаться, травить шутеечки и решать кто все таки обидел Коляна? Ирина или Петя. Колян же выгорел, он потерял мотивацию) (200к + скинуться на кофе Коляну)
- Скрам команда должна состоять из фулл стака спецов, которые могут решить проблемы, связанные с идеей. Команда должна быть самодостаточна. PO только поставляет требования, а ребятки сами все решают. Это горизонтальная или даже матричная структура компании с самостоятельными юнитами, а значит в ней должны быть лиды по направлениям, у каждого должно быть по миду и еще подметала джун: т.е. backend, frontend, tester: 9 человек минимум, в отпуска то нужно ходить. (2-3 мульта по рынку)

Итого один юнит будет кушать 3-4 млн р. в месяц или 50 в год. 🎩

Я конечно гиперболизировал, но вопрос именно в своевременности внедрения тех или иных методик и адекватности затрат для текущего уровня развития компании. На маленькой команде можно комбинировать решения. Тема жирная, киньте 🔥 и я напишу как можно комбинировать для небольших команд)

5АМ | #управление

Как вы думаете отличается ли работа продакта, когда у продакта есть продукт, и когда продукта еще нет? И можно ли вообще назвать его продактом в таком случае?Присоединяйтесь к обсуждению. Вот мои мысли по этому поводу.

Думаю, что главное отличие - это наличие или отсутствие пользовательских данных.

Продукта нет. Что делает продакт:
— Делает большой упор на анализ рынка: конкурентов, спроса, объема, чтобы понять и ориентироваться в каком поле он будет работать.
— Находится в прямом контакте с пользователями. Проводит интервью для точного формулирования запросов и согласования гипотез, чтобы вывести модели монетизации и суть продукта как можно быстрее. Исследует продукты конкурентов и похожих систем.
— Плотно работает с аналитиком/ми (бизнес процесс для гипотез, анализ данных сущностей для интерфейса и БД, взаимодействие с тех. анализом и анализом ux). Если их нет, то проводит эту аналитику. Результатом является пачка требований с оценкой сроков и стоимостью, распределенная по вехам и переданная в проектное управление. Если нет ПМ-а, то и управляет проектом)
— Формирует команду разработки, требования к компетенции участников. Участвует в найме. Инжинирит продукт вместе с ними, постоянно консультирует по требованиям и образу продукта, не мешает креативить идеи для решений поставленных им гипотез.
— Ищет кратчайшие способы вывода продукта на рынок.
— Готовит продукт к управлению им. Покрывает код методами сбора данных для расчета метрик продукта. Также, готовит продукт для подключения его к договорным отношениям: включение/отключение функций, лицензионные соглашения, выставление счетов, процесс оплаты и актирования.

Продукт есть. Что делает продакт:
— Регулярно собирает данные продукта для формирования отчетов по метрикам. Делает расчеты, а из них делает выводы, что такая-то функция не отрабатывает правильно, такая-то работает хорошо, но могла бы лучше, тем самым запуская в работу котел разработки. Некоторые продукты настолько сложные и имеют настолько много данных, что потребность в написания SQL запросов и элементарных классов обработки на Python становятся необходимостью. Иначе данные для принятия решения об изменения будут некорректными.
— Все, что не получается вытащить из данных собирается в интервью с пользователями, чтобы узнать их проблемы, в особенности почему они перестали платить или не хотят платить больше. Часть обнаруженных проблем можно передать на интервью UX-еру. Кстати, именно тут возникает стык и появляется такая роль, как продуктовый дизайнер.
— Актуализировать данные рынка, делать переоценку спроса, изучать новые фичи конкурентов, быть в курсе трендов рынка своего продукта.
- Глубоко взаимодействовать с командой разработки, чтобы понять технические проблемы, которые могут положить продукт, что приведет к убыткам.
— Взаимодействовать с командой маркетинга и сейлзами. Решать их проблемы, изучать метрики рекламных носителей, продаж и пытаться на них повлиять через знания о продукте. Участвовать в построении или строить самому CJM-ки, чтобы понять узкие места отвала процесса не только в самом приложении, но и вне его. Писать стратегию развития продукта в конце концов, чтобы заработать больше деняк.

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

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

Что думаете?

5АМ | #управление

Написано кровью деньгами — не блокируй процесс

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

5АМ | #управление

Возьму только один пример.

Есть самый важный процесс: оценка сроков и, соответственно, денег. Уже как три месяца я плавно произвожу переход компании на новую версию процесса проектирования, чтобы стратегически подготовить Локео к выводу на рынок и потоковой поставки фич в продукт.

Я привязал один процесс, оценку, к другому процессу - проектированию ПО в новой версии. Почему? Хорошо проработанные и упакованные по версиям требования позволяют дать очень точную оценку с корректировкой не более чем в 10-15%. Руководитель направления может произвести оценку, дать обратную связь и сделать декомпозицию, которую можно далее пустить в процесс оценки: расчет стоимости от цены часа и т.д.

Верю в этот процесс т.к. протестировал его на локальном уровне, но затраты времени на рефакторинг документации начали оттягивать время по выдаче расчетов траншей для инвестиций в Локео.

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

Расщепить - Распараллелить

🟣 Расщепить
Считаю, что это фундаментальнейший навык высококласных спецов. Чем выше скорость расщепления после того, как в голову поступила инфа, тем выше уровень спеца.

Еще мнение: причина почему мы усложняем кроется именно в неспособности увидеть точку расщепления. Думаю, что все что называют "гениально" - это вовремя сделанное расщепление.

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

Например, обновление high-level ux платформы не должен блокировать поставку макетов в разработку. Два разных результата. Можно было бы поставить их в ряд и сказать "пока мы не обновим ux - дальше не двигаемся". Разработка - денег стоит, нельзя её блочить.

Расщепление навык всех уровней. Нужно применять в аналитике требований, сущностей данных, процессов компании, юзабилити, да и в жизни тоже.

🟣 Распараллелить
Когда произведено расщепление, то разводим работу, обозначая два разных результата и думаем в будущем о мерже.

В любом случае, когда происходит сцепка, что-то одно является стратегией, а другое оперативным уровнем.

Попадались в сцепку процессов?

5АМ | #управление

Продуктовый экзорцизм

Оценка сроков определяет все: приоритеты разработки фич, оценка денег в договор, распределение позиций участников проекта и их загрузки и так далее. Поэтому нельзя говорить, что «я не знаю сколько», «сложно сказать».

5АМ | #управление

Продуктовый экзорцизм (далее...)
Снять сроки не простая задача для менеджера проектов и продакта, но её нужно выполнять как можно раньше. На точность сроков влияет то, когда начат их сбор. Чем раньше этап, тем больше приходится выдумывать, обращаясь к демонам и духам)

🟣 Экзорцист
Это продакт менеджер, который, закатывая глаза и скрещивая пальцы ладонями вверх, пытается ответить на вопрос стейкхолдера «че долго делать?». У него нет ни скоупа, ни классов пользователей, только минимальный вижн, объяснения несколько фич и пара бизнес целей. Он не говорил с пользователями, бегло посмотрел сайты конкурентов и пару роликов на ютуб.
Демоны обманчивы, точность сроков будет типа «ну может быть как от следующего вторника, так и до следующего сентября».

🟣 Ловцы душ
Это продакт, проджект и руководители направлений: аналитики, дизайна, фронта, бэка, тестов и т.д., собравшиеся за столом перед книгой заклинаний - скоупом. Продакт и аналитик собрали бизнес требования, разложили диаграмму фич, пользователей, конкурентов, заложили архитектуру юзкейсов. Далее продакт читает заклинания - наговаривает концепт и вижн блоков и разделов, описывая крупными мазками представителям всех направлений блоки работ. Затем, все сидящие за столом берутся за руки и запрашивают оценку сроков по направлениям у потустороннего мира. Проджект с овнером раскидывают приоритеты и получают примерную роадмапу и набор планов версий. Точность выше, но по прежнему может быть промах на месяца, корректировка от 20% до 50%, зависит от сработанности команды.

🟣 Медиум
Это руководитель направления разработки, получивший хорошо проработанные требования по каждой возможности (для фронта это еще и макеты и апи), декомпозирующий и оценивающий конкретные задачи по требованиям. Точность очень высокая, корректировка не более 5-10%, зависит от качества руководителя и сработанности команды.

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

Общаетесь с потусторонним миром при оценке сроков?😄

5АМ | #управление