Как написать ТЗ на разработку

😐Я не люблю текстовые форматы ТЗ. Обычно они пишутся плохо. Я всегда за визуал.
😐Я люблю, когда исполнители не требуют досконального ТЗ и задают вопросы, чтобы уточнить детали и сделать задачу лучше.
😐Мне приходится часто писать ТЗ и формулировать его, но иногда приходится и "собирать" ТЗ от людей, которые шарят в доменной области. Да-да, прям как проджект. Так сложилось, такое бывает.

К чему я пришла?

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

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

В третьих, если ТЗ непонятное, у разработчиков начинается аллергия, выражающаяся в прокрастинации.

😮Чтобы написать ТЗ на задачу в области, который не шаришь, по моему опыту, есть один фреймворк.

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

Сначала спрашиваете стейкхолдера: что происходит на входе? Какие параметры? Какие действия пользователя должны произойти? В каком виде?

Потом, что на выходе: какой образ результата? Что должно отобразиться? Что должно произойти? Какой результат должен появится?

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

Вы как бы раскручиваете каждый из этих вопросов. Также декомпозируете на те уровни абстракции, которые вам нужны.

Было полезно? Ставь 🔥

🥰 Как сделать команду разработки счастливой?

Привет! Это Лев, продакт и автор канала @levlevitsky_channel. Сегодня хочу поговорить о том, почему команда разработки может терять мотивацию и как я с этим справлялся.

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

🔖 Почему такое происходит? Из моего опыта — потому что у команды возникает ощущение, что задачи делаются в стол.

Представьте: вот к разработке пришли с задачкой. Побрейнштормили вместе, пошатали требования (с). Запилили задачку. А что дальше-то? Зачем все это, зачееем?

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

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

🔥 Как же подсвечивать эффект от действий команды?

— ходить на дейлики разработки: делиться там новостями, которые происходят в продукте, мелкими задачками, показывать связь разработки и продукта

— выступать на демо разработки с результатами: а вот помните, мы запилили два месяца назад такую фичу, она нам принесла столько-то денег, а еще мы узнали из касдевов, что клиентам она нравится потому-то

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

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

✅ Команда разработки, которая видит эффект от своих действий — счастливая команда. Счастливая команда —> слаженная и эффективная работа —> классные результаты в продукте и бизнесе —> счастливый продакт и еще более счастливая команда. И так далее.

⭐ О чем еще можно почитать у меня на канале:
— Как описывать продуктовые кейсы? Фреймворк STAR
— Мощный шаблон резюме для продакта + мой подход к созданию резюме
— Что нужно уметь продакту в мире нейросетей?
— Важнейший принцип ведения задач: всегда уточняйте и фиксируйте сроки
— Где продакту искать вакансии?
— И подборка из ТОП-50 постов: вы точно найдете там для себя что-то интересное

Рад был познакомиться! Ставьте реакции, оставляйте комментарии, подписывайтесь на мой канал! И спасибо Фаре за предоставленную площадку 🙂

Ваш продуктовый Лев
@levlevitsky_channel

Scrum на пальцах

Недавно обнаружила, что меня читают люди которые не знают что такое Скрам, но при этом сами не в курсе, что по нему работают

Давайте я вам помогу.

😐В скраме есть 3 роли: Product Owner, Scrum-мастер и разработчики. Product Owner отвечает за видение продукта, бэклог и приоритеты. Scrum-мастер обеспечивает соблюдение принципов Scrum и поддерживает команду. Разработчики занимаются созданием и тестированием продукта.

Многие думают, что продакт менеджер и оунер - это про разное. Статьи даже разные пишут, чтобы объяснить разницу между Product Owner и Product Manager. По факту, это просто название роли по скраму.

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

Это в теории, на практике же есть MVP (ограниченное "сочное" количество фич, которые позволят проверять нашу основную гипотезу "купят-некупят") и все остальное ("много-много всего того, что мы хотим и это ОБЗАТЕЛЬНО НАДО!!!")

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

😐 Спринты и планирование: Спринт представляет собой фиксированный период времени (обычно 1-4 недели), в течение которого команда работает над определенными задачами. Перед каждым спринтом проводится планирование, на котором команда определяет цели и задачи для следующего периода.

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

😐 Отдельно стоит выделить митинги. В теории их 5:
- ежедневные дейлики, когда вы синхронизируетесь с командой,
- планирование спринта
- ретроспектива спринта
- актуализация бэклога
- обзор

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

😐Самое важное, по моему мнению, что дал нам Скрам - это понятие "Definition of Done" (Коротко, DOD)

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

Полезно? Ставь 🔥

Как прокачать английский для работы

Мой топ приемов, которые работают.

🤼‍♀️ Завести чат в телеграме под названием "Английский" и скидывать в него слова и фразы, которые вы находите важными и интересными с переводом. Правило одно: в сообщении должно быть только слово-перевод. Ни грамматики, ни заметок и напоминаний. Никаких переписок. Не засоряйте чат. Когда я туплю в телеграме, я в этот чат невольно захожу и повторяю слова.

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

🤼‍♀️ Обучение на английском. Этот метод работает на 100500 баллов. И работает он только на том, что ВАМ ИНТЕРЕСНО. Недавно я писала, что проходила тренинги для сертификации по скраму. Сделано это было на английском. Вы же не думаете, что таких тренингов нет на русском? Найти при желании можно, но не интересно. Самый лучший способ быстро прокачать язык-это учиться предметной области и тем темам, которые вам интересны в данный момент на английском.

Есть вероятность что вы не поймете какой-то процент сказанного. Это нормально! На работе в международной команде ребята с С1 могут не понять процентов 30 из всего, что они услышали (маленький секретик). Самое важное вы поймете или получите пизды и в следующий раз понимать будете)

🤼‍♀️ Любите психологию? Да полюбас вы drama queen, хоть и бородатый мужик за 40. Все мы там окажемся) К чему я.? Психологию любят все и оказывается, именно по психологии, приемлимые по сложности книжки в перемешку с универсальными словами и смыслами. И, оказывается, когда пишут про твою проблему прочитать ее ой как хочется. Именно в таких книжках хорошо развивается "лингвистическая интуиция". Это когда вы примерно предполагаете значение слова или фразы из общего контекста. Важный навык.

Пока вы выживаете на пункте 2 и страдаете на пункте 3, вы конечно попутно добавляете слова в п 1.

🤼‍♀️ Последний пункт, которым я также занимаюсь, это использование добавленных слов. Вам нужно моделировать ситуации, возвращаться к новым словам и повторять их в разных контекстах. Есть несколько вариантов: встречаться с иностранцами (даже в России есть встречи экспатов, которые туда эмигрировали), общаться с ChatGPT для прокачки, добавлять в словари и повторять в PuzzleEnglish, продумывать спичи в голове (что я делаю каждый день, невольно).

Есть свои способы? Поделись в комментариях:)
Было полезно? Ставь 🔥

API на пальцах

Необходимый минимум, который нужно понимать.

😤АПИ - это протокол передачи данных. По сути свод правил, по которым два сервиса "общаются" между собой.

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

😤Сейчас же АПИ стал более широко использоваться. Теперь АПИ создается под каждый сервис в бизнес логике приложения или сайта. Это называется "микросервисная архитектура". Это позволяет избежать дублирования кода и снизить связанность между компанентами кода для последующего масштабирования. Чтобы объяснить проще представьте, что у вас Озон. Представьте что будет, если весь этот огромный маркетплейс будет написан сплошлным текстом кода? Чтобы добавить функционал вы будете плакать и страдать. А если у вас код разделен на "бизнес-блоки", которые взаимодействуют между собой, вы четко знаете куда засунуть дополнительный функцонал, чтобы ничего не поломать

😤Чтобы понять верхнеуровнево АПИ нужно знать, что оно состоит из:

- Метода ( по сути команда или функция)
- Пары "Параметр - значение". Параметры - те значения которые нужны на входе для исполнения команды.

Пример:
Допустим у вас есть АПИ конвертирования валюты. Вам нужно сконвертировать валюту (это наша команда, она же метод), ей на вход нужно подать параметры: (1) С какой валюты нужно конвертировать, (2) НА какую валюту, (3) СКОЛЬКО со следующими величинами (3) - USD, (2)-EUR, (3)-1000

.../convert?from=USD&to=EUR&amount=1000

😤 Чтобы сервисы передавали друг другу большие объемы информации, используется текстовый формат JSON. То есть когда будете слышать это слово, просто знайте, что это некий документ, который передается с фрондента на бэкенд для корректного обмена

Полезно? Ставь 🔥

Правила работы с данными

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

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

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

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

😐  Чистота данных - это круто, но если есть возможность, то лучше провалидировать результаты через анализ данных "с двух сторон". Это касается открытых источников. Допустим, вы анализируете рынок мобильных приложений в Зимбабве. Есть открытые данные. Вы получаете по ним выводы. Так вот провалидируйте эти данные через опросы, например, и убедитесь что они совпадают. По возможности...

😐 Всегда нужно задавать себе вопрос "могу ли я доверять этим данным?" Это будет напрямую влиять на перекосы в выводах.

Например, жила была копания Data.ai. Продавала данные крупным компаниям. А потом оказалось, что она ими манипулировала и получила за это штраф в 21 году в 10 миллионов долларов. Можем ли мы доверять данным на ее портале до 21 года?

Понравилось? Ставь 🔥

Сustomer девелопьменьть😮

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

Потом я проводила много коридорок, кастдевов и просто разговоров с пользователями.

Когда ко мне обращаются за консультацией по запуску продукта, я сразу отправляю "спросить" у своего клиента и "поговорить" с ним.

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

😃Недавно я встретила пост Валерии Розовой и она, как с языка сняла. Я добавлю своего возмущения на кастдев.

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

1. Кастдевами спекулируют по разным причинам (продвигать свои интересы, просто, что то сказать, чтобы скрыть косяки и вообще много для чего)

2. Кастдевы реально сложно проводить. Заебисто и сложно. Каждый раз продумывая сценарии я ухожу в дебри, либо в детали и постоянно вынуждена возвращать себя к сути и гипотезам. Проводить их - это не просто вопросики позадавать. Это реально лидировать диалог и следить за тем, что "между строк"

У меня один коллега проводил опросы по телефону ориентированные на массовость и называл это качественными интервью. Но это не кастдев. Это опросы!

Другой коллега продумывает сценарии, а сами интервью делегирует своим миньонам помошникам. Это точно про качественные исследования?

😮Есть ли у вас реальные люди, курсы, книги, которые прям боженьки кастева? Сдавайте явки пароли в комментариях)

Инсайты про б2б

😤 Продавать компаниям - это практически всегда сверху в низ. Если заинтересовать ЛПР, то все пойдет быстро. Но воздействовать на ЛПР приходится практически всегда снизу вверх. Все равно нужно показать конечному пользователю в компании, что ему это поможет. Он идет к начальку и конючит у него твой продукт.

😤 Из-за пункта 1. цикл продаж может сильно удлиняться примерно в  тыщу раз 😂

😤 Из-за того же пункта 1 и 2 продукт может тупо  не продаваться, потому что у компании могут быть сложившиеся порядки, которые им больно менять

😤. Чтобы этот барьер преодолеть нужны сильные продажники и нужно снимать головную боль с ЛПР по вопросам внедрения очень четко проработанными возражениями

😤. Исследования на б2б рынке - это больше про качественные исследования на "попиздеть" о болях. Количественные нихера не работают

😤. Б2б продукт сильно зависит от состояния рынка на сегодня. Даже больше чем б2с. Например, компании в текущие времена скипнули статью расходов на обучение. Поэтому обучение в б2б сильно просело. Значительней чем б2с

ИТОГО: ваш продукт может не продаваться на б2б не потому что он гавно, а потому что никто не хочет ничего менять, пока продадите проедите последние штаны, да и рынок в жопе:) такие вот пирожки