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

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

Корректировка - это мой личный щит) Ибо нельзя говорить "я не знаю" или "чтобы посчитать мне нужно провести аналитику в течение 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АМ | #Лóкео

Лендинги и презентации

Кто должен писать тексты для лендосов и презентаций? Кто должен думать за структуру? Кто должен фотки искать или образы?

Методик по типу AIDA полно, но соль как обычно проще 🎩

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

Кто делает и как:

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

Копирайтер - на основании того, что понаделал первый, формирует технично, красивенько тексты. Доворачивает смысл.

Иллюстратор/3D-ник/фотограф - показывает образ продукта, образ смысла через рисунок, фото, иллюстрацию, 3D рендер.

Дизайнер - собирает макет из смыслов, текстов и граф. контента. Дизайнит в конце концов)

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

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

Боль, конечно, но решается пониманием имеющихся ресурсов. Не нужно заворачивать лендос с 3D рендерами и огромной пачкой текста, если у вас нет копирайтера и 3D-ка. Аутсорс не лечит кстати)

Отдельно раскрою на неделе про связь разработки IT продукта с маркетингом, а также о подходе к формированию страниц через блоки или сторителлинг)

А вы как делаете лендосы?)

5AM | #маркетинг

Вчера ездил к нашему клиенту, УК Гельвеция, которой внедряем Локео. У ребят красивый поселок премиум класса)

Недавно к нашей команде присоединился Виктор) Он очень крутой инженер, сис.админ, я обязательно его представлю, потому что ну мощь человек просто)

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

Мы развернули нашу программу и показали как все работает. Ребята воодушивились, что все работает удобно и как это может решить их проблемки с оплатой, начислениями и проездами. А у меня появилась микро-мысль, которую можно только почувствовать. Мысль, что все получится, что мы делаем крутой продукт и попали в то, что было нужно и сделали так, как нужно) По своему, как видели, как умели, со своими ошибками... от земли, для земли) Это круто)

Так и хочется дальше делать) Все по-лу-чи-тся) И у вас тоже, надо верить и даже когда очень-очень кажется что ничего не выйдет - продолжать двигаться и все получится, передаю энергию)

Пост эмоция 🫶

5АМ | #Лóкео

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

"- Эх... Бизнес уродует систему - вздохнув, сказал я.
- Но система не должна уродовать бизнес... - получил я в ответ"

5АМ | #цитаты

Пробовали работать в VR очках?)) Вроде удобно, через часок глаза вытекают правда)

Круто заходит, если владеешь слепой печатью)

5АМ | #мемы