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

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

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

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

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

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

Если есть время
Помимо вышеперечисленного - нужно посчитать. 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АМ | #управление

Продакт политик

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

Чем хуже со сроками, тем чаще и яснее должна быть трансляция. Формула если проблемы: «Как вы знаете, мы делаем вот это, есть вот такие проблемы, чтобы их решить есть варианты решения n1, n2, n3, на их проработку выделено такое-то время, будет решено к такому-то времени, сдвиг на такое-то время». Формула если нет проблем: «Мы делаем вот это, будет готово к этому времени в такой конфигурации, будет готово в полной конфигурации к такому времени».

Сбор информации с руководителей или исполнителей должен быть в контексте получения информации для этих формулировок. Людям нужно получить ясность, устойчивость, чтобы принять спокойное положение ожидания или транслировать эту позицию, чтобы кто-нибудь еще принял спокойное положение.

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

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

Что такое "Нашваш" или как руководителю понять, что теряет члена команды

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

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

Так вот - это местоимения "Наш-Ваш".

Как только вы слышите что-то типа такого: "Да в ВАШЕМ проекте все через жопу" или "ВАША система управления фигня" то, если ничего не сделать - человек уйдет в ближайшее время либо будет отсиживаться, выполняя работу на минимальном уровне.

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

Пользуйтесь))
🟣 Руководителю, чтобы попробовать понять сотрудника, решить его вопрос или хотя бы договориться о мягком уходе
🟣 Сотруднику, чтобы не палиться и отсиживаться грамотно 😄😄, ну или попробовать договориться, может вас все таки поймут, если дело вам дорого. Вы же когда-то говорили "Мы" и "Наш", зачем рубить, так ведь?))

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

В чем истинная полезность project manager-а в небольшой IT компании

Представьте производство автомобиля. Есть сборочная лента. Штампуют прессом кузовную деталь, сваривают детали между собой, устанавливаются внешние детали, красят и т.д.

Где здесь ПМ? ПМ - это сборочная лента.

Продакт выдал видение продукта и пачку сценариев, вылизанных с точки зрения нужности рынку и заработка. Положил на ленту. ПМ включился и поволок коробочку к бизнес аналитику. Этот побегал собрал процесс, акторов, результаты. Положил в коробочку. Сис. аналитик подобрал, дал процесс, модель данных, требования. Положил в коробочку. Продакт дизайнер посмотрел на все эти сценарии, пособирал свои требования, видение, разложил карту. Положил в коробочку. Тех. лид посмотрел на это все безобразие, сделал модель БД, архитектуру бэка. Положил в коробочку. И так далее пока не дойдем до тестирования. Каждый делает свою работу и кладет в коробочку, пока из неё не получится то самое нечто, что в экстазе увидел продакт.

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

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

ПМ должен склеить швы и нести знамя продакта до деплоя и положить аккуратно в ручки маркетологу и продажнику.

И от этого идет все: все планы, таски, созвоны, куча документов и умных слов. Но суть: сохранить видение продукта, за который заплатит клиент, даже если видение трансформируется пока ПМ несет знамя.

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

Ненавижу переключаться

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

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

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

Короче "делать нельзя делегировать". Поставь запятую.

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

Самое сложное - это не нервничать и признать этот факт. Стараться не обращать на мелкие течи, отпускать (это проще сказать, чем сделать поверьте), последовательно затыкать то, откуда прям заливает. Иногда отвлекаться и кружкой вычерпывать.

Выживет тот, кто умеет делать выбор: что затыкать, что вычерпывать, а на что забить вуй.

Когда много откуда течет, а особенно если есть несколько мест откуда прям заливает, то это хреновый сигнал, что в краткосрочной перспективе может произойти какой-нибудь внезапный(нет) пздц. Это главный сигнал, что не хватает ресурсов. Нужно это признавать и снижать ожидания. Просто барахтаться уже дальше некуда. От чего-то приходится отказываться, чтобы выжить. Либо искать гениальные решения, но это как лотерея. Так что на это я обычно не надеюсь, но тужусь, чтобы вылезло.

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

Выговорился 😄

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

Как создать любое программное обеспечение

Или от денег до денег (MTM - Money to money)

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

1️⃣ПРОЕКТИРОВАНИЕ - первая вершина треугольника

- Процесс: Взять процесс пользователя, который дает ему деньги

- Боль: Спросить у него что не так или найти проблему

- Механика: Найти видение решения проблемы

- Запрос: Обозначить потребность в сценарии

- Гипотеза: Заложить способ как реализовать запрос

- Процесс: Дать шаги как проблема решится в новой механике

- Данные: Вывести данные, которые участвуют в механике

- Процедуры: Вывести кейсы из данных

- Требования: Вывести как система должна работать в кейсах

2️⃣РАЗРАБОТКА - вторая вершина треугольника

- БД: Как будут храниться данные

- Макеты: Раскадровка того чем будет пользоваться человек

- Логика системы: Как будет работать система

- Логика отображения: Чем будет пользоваться человек

- Тестирование: Сверить разработанное с требованиями

- Публикация: Развернуть решение и дать доступ пользователям

3️⃣ПРОДАЖА- третья вершина треугольника

- Упаковка: Обернуть механику в решение боли процесса

- Реклама: Орать на всю ивановскую о том, что оно решает

- Продажа: Донести, что механика действительно решает

- Поддержка: Делать так, чтобы процесс приносил ему деньги

Дальше читаем заново 😎

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