Раскрою тему прошлого поста глубже) Да-да, нужно прочитать😝

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

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

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

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

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

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

5АМ | #команда

Немного про планы контента на канале

Что-то вяленькие все) Не интересно что ли?) Лето, отдых, понимаю)

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

- про b2b и внедрение. Типы компаний и приложений по типу внедрения. Во что вкладываться сложнее всего

- про аналитику. Я писал про салат из аналитиков. Хочу разобрать каждого по отдельности.

- agile и стартап

- про строительство отделов: маркетинг, продажи, внедрение. Реальные цифры запуска продаж)

Также, готовлю несколько статеек на VC. Наш кейс по VR, по 3D для сайтов. Нужна будет ваша помощь)

А сейчас запилю опросец по тому, что было бы интересно 😘

Опрос сказал менеджмента хотите) Принес лонгрид 😜

Я как-то разбирал оперативное управление проектами. Оно устроено у нас в виде проектов-эпиков в ноушине, каждый из которых ведет к своим ощутимым результатам. Но как планировать цепочку таких микро-проектов внутри огромного проекта/продукта? Это как раз уже тактическое и стратегическое управление проектом. Для этого у нас есть набор гугловских таблиц + дока к ним.

Главные требования:
- удерживать helicopter-view. Эффект карты должен всегда сохраняться
- с карты можно всегда спуститься в детали: описание, прототип, макет

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

Какой набор таблиц есть🔽

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

Понятно, что есть scope, но важнее даже не он.

Таблица работ / запросов (как клиента так и команды)
Это таблица с пожеланиями, которые учитывают контекст. Тут по JTBD. Разговор исключительно на языке пользователя, причем в отрыве от конкретного продукта.
Например: "Мой клиент приехал осмотреть поселок раньше меня (менеджера по продажам). Мне нужно его как-то быстро пропустить через КПП, чтобы он без меня начал смотреть участки/дома."
В таблице пишем короткое описание, общее описание, статус. Даем ссылку на конкретное место в доке с детальным описанием кейса. В этой точке как раз и происходит бизнес анализ и уточнение требований бизнеса. Тут нет вашего продукта, только проблемы и пожелания, которые клиент не знает как удовлетворить.
Кстати, именно из этих вещей строится скрипт продаж вашего сервиса.

Таблица возможностей (feature list)
Эта таблица с функциями, которые приносят конкретную полезность для пользователя в рамках продукта. Фичлист больше направлен в сторону пользователя. Язык более понятен пользователю и действует в контексте вашего продукта.
Например: "Создать пропуск для лица с ограниченным сроком действия" или "Отправить ссылку с данными публичного пропуска клиенту".
Зачем нужна: отработать гипотезы, понять готовность фичи, провести декомпозицию, пояснить команде.
Как правило, работа/запрос - это группа фич. Именно тут и проводится продуктовая и системная аналитика, чтобы вывести процесс и данные.

Таблица функций
Эта таблица отражает видимые функции программы на фронте в разрезе разделов и экранов. Выражается в точных и конкретных действиях пользователя. Создается исключительно для внутреннего использования и удобства. Язык менее понятный для пользователя.
Например: "Найти пропуск клиента и открыть страницу пропуска" или "Расширить пропуск на другой КПП".
Зачем нужна: чтобы дать объяснение дизайну и фронтам о том, как должно работать приложение в конкретной точке, справка пишется по этим данным, тех поддержка может работать по этой табле, тестеры могут работать так же по ней.
Из функций формируются возможности. Именно тут проводится технический анализ и анализ UX.

А теперь самое интересное, но на завтра))
- Как это все версировать?
- Через какие таблицы определять приоритеты?
- Какие формулы используются для оценки финансов и времени и с какой таблицей связывается эта оценка?
- Как выделять оперативные проекты из этих таблиц?
- Как их выстроить в Roadmap-у)

Все постепенно рассмотрим) Понимаю, что не каждый осилит, но если осилил пиши коммент или кидай огонёк🔥

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

Вчерашние вопросы по управлению достаточно масштабные) Наверняка устали от лонгридов на этой неделе) Дам пока легкую и полезную мысль для проектирования систем)

Ни один продукт нереально разработать сразу, но продумать систему/продукт можно куда глубже. Если мы знаем требования заранее, но они очень объемны, то мы можем спроектировать систему целиком. Продумать взаимосвязи и данные.

Важным элементов для анализа является понимание, что каждый процесс является выходом из другого и входом для другого. Корпускулярно-волновой дуализм в действии, хех)) Если вы не знаете откуда пришли данные и куда они должны выйти, вы не знаете свою систему. 1-0-1-0...

Поэтому спроектировать нужно можно сразу систему целиком, разбить версии и оставить для бэка или фронта точки для входа в будущие процессы, как проводки́)) Мне кажется этот образ мега понятный) Потом можно быстро скрутить и перемотать изолентой и сигнал пойдет)

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

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

5АМ | #life

Всегда было интересно как разные студии делают такие дружные гифки с командой)) Ну вот походу это выглядит так😂

5АМ | #мемы

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

Обычно ответ идет от оценки. Есть стоимость команды разработки, которая разработает автоматику, есть издержки на внедрение и поддержку автоматики. Берем период амортизации в 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АМ | #управление