Автоматизировать или не автоматизировать, вот в чем вопрос?)🤔

Обычно ответ идет от оценки. Есть стоимость команды разработки, которая разработает автоматику, есть издержки на внедрение и поддержку автоматики. Берем период амортизации в 10 лет и сверяем стоимость разработки и стоимость ручного поддержания процесса. Если первое больше второго, то автоматику делать незачем… Так говорит теория.

Вот другие доводы, что автоматику все таки делать:

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

Автоматика может стать бизнесом
Если вы внедрили автоматику, то будте уверены, что это можно продать. Разработать и внедрить автоматику всегда задача не простая.

Автоматика как стратегия выживания
Все чаще это вижу. Дело уже даже не в издержках. Компания долгосрочно просто не сможет конкурировать. Сотрудникам и менеджменту нужно видеть данные, создавать другие процессы, которые недоступные без автоматики и обработки данных.

Цифра - это всегда стратегия, не тактика.

5АМ | #компания

Начну отвечать на вопросы из этого поста:

Как выделять оперативные проекты из этих таблиц?

После проведения сеанса связи с клиентом/ пользователем/ реальностью / виртуальностью😁 мы формируем запрос (работу). Чё надо ваще? на языке клиента, вне контекста конкретного продукта, но в рамках контекста его жизни. Заносим все запросы, которые можем нарыть и проставляем им приоритет и влияние (impact). Фильтруем.

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

Фичи отслеживаются по готовности в разрезе конкретного направления: аналитика, дизайн, бэк, фронт и т.п. То есть происходит аналитика фичей запроса, дизайн фичей запроса и так далее.

Итак, как стругать эпики-проекты для дорожной карты? Помним что они формируются по критерию "результат". Деление по принципу: большой запрос (больше месяца на релиз) или не большой (меньше).

Большой запрос
Проекты бьются по направлениям запроса. Например, проект "аналитика запроса REQ-345". Вывести фичи. 10 фичей, написать доку и задание на 10 фичей. Крупный результат. Делать 2-3 недели. На базе доки можно делать ux и tech исследование. Круто) Выглядит реально как проект, за который можно по голове погладить.

Маленький запрос
Просто сам запрос является проектом.

Как их выстроить в Roadmap-у то)

Дальше всё просто. Закидываем в табличку проектов-эпиков список, делим по приоритету и block. Закидываем на timeline в Notion. Периодически помешиваем обновляем.

PS. Все, о чем рассказываю, по завершении цикла покажу на видосе)

5АМ | #компания

Фразы «все переделать» или «нужен редизайн» начали вызывать у меня мурахи по коже и нервный тик.

Тут прям попадание во фразу: не трожь - вонять не будет. Если что-то работает, т.е. приносит деньги, то лучше пусть себе работает. Для продукта - это фраза очень зрелая. Когда проект перестает быть проектом и становится продуктом, то подход к разработке меняется. Гибкости уже нет и нужно аккуратно делать шаг, чтобы не наступить на какашку.

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

Мы сейчас чистим Локео по всем фронтам: документацию, UI kit, макеты, бэк и фронт. Глобальный рефакторинг всего. Локео стал продуктом и теперь, чтобы двигаться дальшее нужно навести порядок. Делать версии уже существующих фичей или добавлять новые на базе старых не получится, потому что проблемы будут наследоваться / импортироваться. Позже уже не будет такой гибкости к изменениям, просто потому что уже есть юзеры, они уже начнут привыкать и формировать опыт.

В этот период всё чаще возникают эти фразы, поэтому ко всему подходим с холодной головой, нужно установить границы и не делать лишнего. Главное почистить то, что блокирует дальнейшее движениие.

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

Как это все версионировать?

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

В чем собственно проблема:
- продукт не стоит на месте. Новые фичи появляются, старые обновляются или выпиливаются. Их описаниие и ТЗ меняются. Время идет, планета крутится, со временем никто уже не помнит «что там и как делали-то, Инакентий?». Как входить в версию и обновлять описание, не поломав ноги-руки и нервы продукта.
- документация - это дорогой продукт, который используется для онбординга сотрудников, подтверждения порядка бизнеса «разработка по» для инвестора, юридический щит в конце концов.
- источник данных для оценки. Расчет стоимости и сроков новых версий - это данные, без которых бизнес работать будет очень плохо. Как его получить)

Обо всем этом ниже 🔽

5АМ | #разработка

А в целом, что версионируется то?

- версионируется продукт в контексте запросов (job-s), которые могут быть пользовательскими, а могут быть техничскими (от команды)
- версионируется описание запросов/фич/функции
- версионируется описание заданий по направлениям

Для версионирования нужна табличка версий продукта, где бьются версии по общепризнаному методу 0.0.0 (Major, Minor, Micro). В этом посте писал про то, как разбить проекты-эпики. Эти проекты-эпики так же бьем в таблицу. Отрезаем версию в табличку версий и делаем ссылку на проект. Как писал раньше проект-эпик - это запрос или направление разработки запроса, поэтому у нас идет влияние на запрос, а через него на фичи.

Чуть отступ про крутую схему, чтобы максимално сохранялся helicopter view: описание запросов и фичей нет в таблице. В этом случае мы делаем «пару» таблица + док. В доке есть запрос и версии описаний запроса. Если в рамках версии продукта нужно версионируется запрос (добавить, обновить, удалить), то в доке добавляется версия описания, ставится закладка и дается ссылка на это место в таблицу. Версии запросов и фичей отображаются по версиям продуктов. Это позволяет понимать на какой версии появился запрос, на какой изменился, а на какой был удален.

Повторю набор «пар» (таблица+док) для управления продуктами.

Первый набор - версионируемая документация:
- пара для запросов (работ, job-ов)
- пара для возможностей (фичей)
- пара для функций (конкретная точка приложения)

Второй набор - управление версиями и оценкой.
- пара для версий продукта
- пара для проектов-эпиков, которые идут на «землю» в оперативный уровень (писал в этом посте про землю)

В таком виде мы:
1. Получаем новый запрос или его обновление (1). Фиксируем. Запускаем бизнес анализ.
2. Бьем на проекты. Отрезаем версии. Оцениваем сроки и цену. Запускаем продуктовый и сиситемный анализ (2).
3. Запускаем тех. и ux анализ (3). Обновляем оценку и сроки.

Главная удобность - можно плавно спускаться с очень высокого уровня на самый нижний. Можно пробежаться как по верхам продукта, так и спустится в глубокое его понимание. Почему? Потому что к запросам / фичам / функциям в доке помимо описаний цепляется уже документ анализа или ТЗ. Просто путешествуешь по ссылкам. А если нужно распечатать это все, просто берешь центральный док и вместе со всеми версиями распечатываешь)

Запишу видос, покажу)

Что думаете? Есть тут - кто решил проблему версионирования? Какие у вас решения? Может используете навороченное корпоративное ПО? Делитесь))

5АМ | #разработка

Ребята, всем новеньким душевный привет 👋 Давайте познакомимся!) Я вот тут писал про нас буквально недавно. Мы качаем студию разработки ПО и свой стартап Локео, а я делюсь о жизни студии и наработками про продуктовое, проектное управление, аналитику, команду, чутка бывает оффтопа прикольного)

Тут вот можно почитать интересненькое за последний месяц))
- Типы зрелости заказчиков
- Установки для сильного внутреннего стержня
- Как помогают сценаристика-конфликтология-типология в аналитике продукта

Вы кстати ворвались посреди крутого цикла про стратегическое и тактическое управление. Вот так цикл идет:
- Оперативное управление проектами
- Задачи проекта как сфера
- Стратегическое управление проектами
- Как выделять проекты на оперативный уровень
- Версионирование стратегической доки

Цикл закончу завтра темой про оценку денюшек и времени из страт. управления)

5АМ | #дайджест

Точность и корректировка

"Ну че там долго делать то? Че там с деньгами?". Вопросы из разряда библейских)

Корректировка - это мой личный щит) Ибо нельзя говорить "я не знаю" или "чтобы посчитать мне нужно провести аналитику в течение 2-х месяцев...". Корректировка в % на оценку замечательная вещь.

В целом откуда пошла спешка в оценке. Это неизвестность. В начале отношений или запуска точная оценка не важна и невозможна. Важно, чтобы в голове появилась цифра, чтобы от нее оттолкнуться. У заинтересованных есть "мешочек/копилочка" с временем, когда наступит конец, и денег, когда тоже наступит он) Соответственно, чтобы не было страшно и больно спать по ночам, нужно сделать прикидку.

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

Озвучить требование голосом
Оценка только интуитивна. Умножается на x10. Время - 1 час. Звучит как "- Сколько? - Десять. -Чего десять? -Лямов... Лямов!? -Лямов."

Провести бизнес анализ
Есть требования. Они описаны. Оценка по прежнему интуитивна. Умножается на x5. Время - 40 ч.

Провести продуктовый анализ
Есть точные описания запросов. Крупные исследовали, проанализировали. Разбили фичи. Обычно этот уровень понимается под ТЗ) Собрались обсудить командой, каждый дал оценку. Оценка по прежнему интуитивна, но на командном уровне. Умножается на x3. Время - 80ч.

Провести системную, тех. аналитику (бэк, фронт) и ux/ui
Есть точные описания данных, схемы. Есть тех. анализ самых сложных блоков. Есть исследования, анализ ux, схемы, вайерфреймы. Команда прям поработала. С каждым из команды уже отдельно прошелся по каждой фиче и дал оценку. Интуитивно оценка дается только чудозверь-фичам, остальное уже более менее. Некоторые части умножаются на x1.5-2, некоторые даются с погрешностью или в 0. Время от 160ч*. На этот уровень можно рассчитывать в управлении проектом и студией.

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

Пояснил за точность и корректировку. Осталось раскрыть как, в каких таблицах набрасывается оценка и какими формулами)

5AM | #предпринимательство

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

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

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

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

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

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

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

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

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

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

Кто сходу может сказать: что самое сложное в разработке ПО?)

На втором месте у меня стоит аналитика. Но на первом: состояния и переплетения состояний. Это просто крышесносная мозгоштурмовая жвачка))

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

А вы что думаете? Что самое сложное в разработке?)

5АМ | #разработка

«Искусство - это действие с наименьшим потенциалом повторения успешного результата»

Попалось такое определение, в голове щелкнуло, вам принес, пусть тоже щелкает)) Таки выходит, что ИИ убивает искусство?) Или просто круг того, что можно назвать искусством становится уже)

5АМ | #цитаты

В чем сложность управления студией полного цикла разработки ПО?

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

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

- Провести глубокую аналитику продукта
- Разработать дизайн
- Разработать код (по направлениям: бэк, фронт сайт, фронт мобильного приложения)
- Протестировать и выпустить

С точки зрения бизнеса самое сложное кроется в синхронизации направлений по проектам, то есть - каждое направление должно работать внахлёст (или косичкой). Допустим есть три проекта. Аналитик должен работать по первому, дизайнер по второму, бэк по третьему. К моменту завершения работы аналитик должен приступить к четвертому, дизайнер к первому, бэк ко второму и т.д. Иначе заработать не получится, будет простой.

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

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

Я думаю, что одним из ключевых навыков лидов PM-ов или руководителя студии - уметь достигнуть синхронизации в самое короткое время)

5АМ | #компания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кстати, на следующей неделе расскажу про два подхода к формированию структуры рекламных страниц) Продакт - это ведь чуть-чуть маркетолог)

Будет интересно) Всех с выхами!)

5АМ | #Лóкео