Менеджер от боженьки

2022-09-14 18:00:03 ​Тестовые данные на проде

Однажды я искал дальних родственников на сайте кладбища.

Ради фана вбил в урл /admin. Открылась страница с логином. Недолго думая я ввел admin, admin и....открылась админка.

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

Разблокировав ачивку cool hacker, я написал разработчикам с левого имейла (они не ответили).

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

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

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

Недавно в одном сервисе я ввел промокод test на чекауте и получил год подписки бесплатно (+ coolhacker lvl2). Т.е. для компаний такие косяки могут иметь вполне измеримую стоимость. Открыть/Комментировать

2022-09-07 18:00:04 Пример джира тикета

Я оформляю задачи вот так. Поясню некоторые поля:

Goal + Affected metrics - зачем мы это делаем и на что повлияет.

Description - подробное описание, как работает фича, расписан флоу, как работает каждая кнопка.

Acceptance Criteria (AC) - главные сценарии, которые надо сделать, чтобы считать задачу выполненной.

Subtask - декомпозиция.

Time tracking - начальная оценка в часах, сколько времени потратили + есть ли вылет.

Assignee - кто сейчас занимается задачей.

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

Labels - использую для фильтрации на разные темы. Например, фича для клиента (Chingari), к какой части системы относится (FAR-effects), делаем доп. контрактом (CR).

Epic link - ссылка на эпик (разбивка системы большими мазками).

Fix version - в какой релиз войдет.

--------------------------------

А вы какие поля еще используете? Открыть/Комментировать

2022-09-02 13:00:03 ​#реклама

Что делать, если ты джун, умеешь немного, но готов работать и расти? Вопрос непростой, а ребята из самого душного (и смешного) подкаста про IT Форточку открой знают ответы.

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

Пилотный эпизод доступен на всех платформах. Ребята ждут вашей обратной связи - все контакты в описании к выпуску. Лайк, шэр и не забудьте открыть форточку! Открыть/Комментировать

2022-08-31 18:00:03 ​Как работать с рисками

О риск-менеджменте принято говорить шепотом, как о неприлично сложной науке, доступной только тем, кто читал PMBOK. На деле любой ПМ работает с рисками каждый день.

Объясню на примере.

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

Хороший ПМ увидит в этом потенциальную проблему и пойдет ее решать:

Вспомнит, что Валера говорил на последних ретрах. Какие из его задач были самыми грустными. Проведет 1-1 и выяснит, что Валера устал от проекта за 3 года, но пока еще не созрел уходить. Это идентификация риска.

Если забить на проблему, то с вероятностью 70% Валера уволится. На замену джависта компания потратит примерно $15K. Это анализ риска.

Затем ПМ прикинет варианты решения. Дать Валере других задач или, быть может, перевести на другой проект. А если Валера не вписался в коллектив, и код его так себе, то, может, и нафиг Валеру?

Предположим, другие задачи и проект Валеру не впечатлят, и он решит уйти. Как к этому заранее подготовиться? Потянет ли второй джавист Леша весь проект? Где быстро раздобыть замену? Как дела с документацией? Этот и предыдущий пункты называют смягчение (mitigation) риска.

Валера теперь под прицелом. ПМ будет наблюдать его настроение пристальнее обычного и встречаться с ним раз в неделю. Это мониторинг риска.

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

Честно говоря, я часто забиваю и не веду этот реестр. В продуктовых компаниях с плоской структурой, где ПМ репортает СТО, CPO или CEO, можно без него обойтись. Но если не чувствуете хорошей, доверительной культуры - лучше вести.

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

Вот и весь риск-менеджмент. Открыть/Комментировать

2022-08-25 17:00:03 ​Тест на технические скилы

Недавно на собеседовании спрашивали про устройство CI/CD пайплайнов в мобильной разработке . Я рассказал, что знал про тесты, инфру для билдов, метрики и гитфлоу, но чувствую, что можно было лучше.

Так глубоко спрашивают не везде, но на позиции вроде technical product manager или delivery manager довольно часто.

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

https://kavaleuski.me/tech-test

Пишите в комментах сколько набрали. Открыть/Комментировать

2022-08-25 11:50:01 Вчера на совете увлеклись таким вопросом:

В решении споров на чьей стороне должен быть ПМ: команды или клиента? Или может быть выступать таким медиатором, посередине?

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

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

А вы как думаете? Открыть/Комментировать

2022-08-19 17:00:03 ​Новости ПМ совета

3 месяца назад я запустил ПМ совет - сообщество проджектов по решению кейсов.

С тех пор мы разобрали 20 ситуаций из жизни ребят. Некоторые из них можно почитать здесь, остальные доступы по подписке.

Еще до запуска я думал, как реализовать подписку. Нужен был механизм оплаты, управление пользователями, 2 вида подписки, статистика, в общем целый проект. Хотелось найти готовое решение, желательно, не за миллион денег. Так я обнаружил бот @donate от официальной команды телеграма, он принимает большинство карт и комиссия минимальная.

Нервничал перед запуском подписки - кто ее вообще купит? Какую поставить цену? Но нашлось целых 20 человек, кому формат зашел и почти все ребята продлили ее на 2 месяц. Спасибо вам!!

Было несколько гостевых встреч, где мы разобрали мое резюме и линкедин с экспертами по найму. Мне кажется, это интересный формат и я хочу его еще покрутить. В сентябре будет одна такая встреча, где построим архитектурную схему (system design) какого-нибудь продукта.

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

Из проблем, которые хочется решить - это невысокая конверсия в подписку - 2%. Если есть идеи, как ее увеличить - пишите в комментах.

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

И приходите на ПМ совет, у нас классно :) Открыть/Комментировать

2022-08-16 18:00:03 ​Как успевать стендап за 15 минут

Продайте команде проблему. Объявите целью августа начать укладываться в 15 минут.

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

Следуйте формату что сделал - что буду делать - есть ли проблемы.

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

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

Самый важный пункт-2: любой затруднительный вопрос, требующий >30 сек разбирайте после стендапа. Т.е. сначала завершили статус, часть ребят ушла, а те, у кого были вопросы, остаются (можно прямо в том же митинге). Да, вы будете оставаться два раза из трех, зато большая часть команды экономит время.

Было: 8 человек слушают претензии Саши по требованиям в 347 таске.
Стало: ПМ, БА и Саша разбирают претензии по требованиям в 347 таске.

Расшарьте экран со списком задач, чтобы соотносить слова Саши с 347 таской. Так всем понятнее о чем идет речь.

--------------------------------------

Менеджер - тоже часть команды. Рассказывайте ребятам, с каким клиентом вчера был звонок, что отдел маркетинга думает про последний релиз и тому подобное. Открыть/Комментировать

2022-08-10 17:00:03 ​Топовое исследование об эффективности команд

Иногда на проект выделяют разработчика на 4 часа в день. Остальные 4 часа он занят другим проектом.
Понятно, что эффективность такой работы ниже, так как на переключение между проектами нужно время. Но сколько мы потеряем в производительности? 10%? 20%

Исследователи CA Technologies опросили 50,000 команд и выяснили, что правильный ответ - 50%. Т.е. люди, работающие фултайм, делают в 2 раза (!) больше работы на единицу времени, чем работающие парт-тайм.

Еще несколько фактов, которые цепляют:

Команды, оценивающие задачи в часах на перформят на 20% хуже, чем те, кто оценивают в стори поинтах. Перфоманс оценивали по нескольким параметрам, вроде качества, продуктивности и т.д.

Команды в 5-9 человек, использующие 2-х недельные спринты наиболее результативны по сравнению с другими сетапами.

Команды, которые проводят ретроспективу, перформят на 20% лучше, чем те, кто не проводят. Особенно видно улучшение по качеству: + 42%.

Разработчик, у которого в момент времени 1-2 задачи, делает на 70% меньше багов, чем разработчик с 3-5 задачами.

Если хотите продать команде идею не брать кучу тасок в работу, то такое исследование - мощный аргумент. Советую почитать его полностью (всего 16 страниц с картинками!), действительно много интересной инфы: https://docs.broadcom.com/doc/the-impact-of-agile-quantified. Открыть/Комментировать

2022-08-05 12:15:02 ​Сдал на продакт оунера

Вчера сдал на PSPO 1 от Scrum.org.

Здесь я писал, как сдавал на скрам мастера и в чем отличие от сертификации Scrum Alliance. Это очень похожий опыт, поэтому расскажу в чем отличия:

На подготовку ушло 4 дня. В прошлый раз я готовился несколько месяцев, и сейчас понимаю, что можно быстрее. Больше всего помогли вот эти ресурсы:
- тесты на Udemy
- тесты Михаила Лапшина
- вот эта книжка с тестами

Я проходил их, в среднем, на 90% (при проходном в 85) и не был уверен, что справляюсь с реальным тестом. Иногда попадались вопросы, которые вводили в ступор, например: "Какими метриками измерить успешность перехода от Waterfall к Scrum?". Чегооо?

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

Плюс, конечно, скрам гайд, нексус гайд, EBM и бесплатные тренировочные тесты на scrum.org.

Тест PO сложнее теста SM. Если хотите сдать оба, то начинайте с SM.

Вопросы на PO на 60% совпадают с вопросами на SM. Если бы я знал это раньше, то сдавал бы PO сразу же после SM, пока свежи знания.

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

Зачем тогда его сдавать? Я начал смотреть работу в Европе и вижу, что около 20% вакансий просят PMI или эджайловые сертификаты. Думаю, пригодится.

Удачи на тесте! Открыть/Комментировать