Деплой по кнопке

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

Чем меньше шагов в процедуре деплоя, тем выше шанс ничего не сломать. В этом и есть суть автоматизации девопс.

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

Анонимный тест на проектную грешность. Максимум 400 баллов (угадайте, сколько у меня, правильно, 400 😆).

По мотивам теста на продуктовую испорченность.

Ребята, сорри, с опросом я налажал, можно выбрать только один вариант, но отредактировать его уже нельзя :(

Вот примерно так выглядит результат пункта 4 «релизил без тестирования»

Навигация

👯‍♂️Команда
Персональные митинги (one-on-one)
Выходное интервью
Как работают американские команды
Мотивация на длинном проекте
Размер команды
Почему увольняются
Похвала
Давать негативный фидбек
Баланс джунов, мидлов и сеньоров
Сколько времени уходит на 1 разработчика


💪Scrum
Сердце Скрама
Скрам сертификация
DoR, DoD
Scrum аудит
Интро к ретроспективе
Scrum guide 2020
Icebreaker для ретроспективы
Структура ретроспективы
Результаты ретры в беклог
Как выбрать длительность спринта


🎮 Кейсы
Небольшая доработка
Плохие новости
Выбор кандидата


😇Софт скилы
Не идиот
Проводник культуры
Выгорание
Орки
Удобные письма
Главный скилл менеджера
Импульсивные решения
Что бесит любого ПМа
Потеря времени
Косячат все
Дать облажаться
Смещение фокуса
Право отказаться


👨‍💻Практики, лайфхаки, менеджерские штучки
Как продать рефакторинг
Что писать в контракте
Чек-лист ведения проекта
Прогноз бюджета
Какие отчеты обязательно делать
Что надо сделать до отпуска
Meeting notes
Как готовиться к командировке
Паузы в диалоге
Подборка ПМ каналов
Как понять, что на проекте все ок
Спринт репорт
Как отвечать за то, в чем не разбираешься
Проектный треугольник 2.0
Закрыть неготовую задачу
Кик офф
Фидбек от клиента
Изменения = терпение
Выясни кто стейкхолдер

Принципы планирования

Бест, прости господи, практис:

1️⃣ Команда говорит "когда будет готово", а не клиент или менеджер.

2️⃣ Оценивать должны те люди, которые будут делать. Или переоценивать на старте, если оценили другие.

3️⃣ В описании стори должна быть цель, все остальное вариативно. Чем детальнее описание, тем точнее оценка.

4️⃣ В каждый спринт надо закладывать хотя бы 1 рефакторинг, чтобы не копить техдолг.

5️⃣ Надо брать запас и закладывать риски. Лучше пообещать меньше, а сделать больше, чем наоборот.

6️⃣ DoD поможет уточнить оценку, определив какие именно задачи надо сделать, чтобы закрыть сторю.

7️⃣ Лучше не грумить больше чем на ~3 спринта вперед. Из-за меняющихся приоритетов, это может оказаться бесполезным.

8️⃣ Декомпозируйте на подзадачи, занимающие ~6-12 часов.

Задача менеджера - следить за тем, чтобы все понимали, принимали и следовали подобным принципам.

Cracking the PM interview

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

📌 пошаговый процесс найма в Google, Amazon, Apple, Microsoft, какие требования, что входит в обязанности;

📌 резюме, с которыми кандидаты получили оферы из этих компаний (+ как их можно улучшить) ;

📌 как отвечать на скользкие вопросы типо "почему вы решили сменить работу?" или "почему мы должны взять именно вас?"

📌 интервью с топовыми продактами, как будто Дудя смотришь;

Меня зацепила вот эта мысль:

Join the company, that's experiencing hyper-growth. The business will be growing faster than the team can scale, so you'll have lots of room to grow in terms of responsibility. Venture capital community can be a great resource here; they value meeting talent (you!) while you value getting job leads.

+ простой и понятный английский, не стесняйтесь читать в оригинале!

​Как отвечать за то, в чем не разбираешься

Недавно коллега спросил, как ему отвечать за девопс, в котором он ничего не понимает. Я спросил, а как ты, бывший аналитик, отвечаешь за все остальное? За код, за тесты, за дизайн?

Хороший менеджер отдает принятие многих решений (и ответственность за них) команде. Так она учится и развивает самостоятельность.

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

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

Еще помогает технический бэкграунд, об этом в следующем посте.

Как качать технические навыки, ч1

Прокачивать любые навыки можно в бою. Допустим, приходит требование клиента - надо 5000 сессий одновременно. Вроде понятное требование, несложное, бытовое. Идем к девопсу, узнаем, что сервер тянет 3000 (еще полезно узнать что именно тянет и при каких условиях). Вот тебе капасити.

Как будем делать 5000? А какие есть варианты? Вертикальным скейлингом? Горизонтальным? А как будут распределяться пользователи между серверами? Лоуд балансером? И так далее.

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

Спринт репорт

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

- Дать быстрый статус боссу \ клиенту;
- Прикрыть тыл менеджера;

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

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

Дать облажаться

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

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

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

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

Сколько получают менеджеры

Зарплата проджектов в Минске в 2020:

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

$1500-3000 начисляют на карточку мидлам, управляющим командой в 5-15 человек. Эти ПМы сами настраивают джира флоу, уже пробуют делегировать и адаптировать процессы под проект\клиента. Им нужно подсказывать направление и иногда проверять как идут дела.

$3000-5000 получают сеньоры с командой 20+ человек. Это полностью автономные сотрудники, которые решают проблемы еще до того, как те появились.

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

UPD 2022: легко умножайте все цифры на 20%

​на день рождения тим лиду

​Проектный треугольник 2.0

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

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

Как вам?

​Фидбек на канал

Я веду этот канал, потому что кайфую от своей работы. А еще, чтобы научиться лучше писать. Мне нравится красота текста и емкость мысли.

Автор моей любимой книги "Пиши, сокращай", Максим Ильяхов, разбирает тексты на заказ. Я прислал ему несколько постов и вот что он посоветовал:
https://www.youtube.com/watch?v=PdzuwlYgLUQ

С комментами согласен, есть полезные штуки, которые точно возьму на вооружение. Конспект:

👍 - четкая структура, нет воды, есть примеры и контрпримеры;
👎 - ...но их мало, как и историй из практики, поэтому некоторые идеи сложно уловить в плотном темпе смысла. Мало картинок и графики;

А что бы вы посоветовали каналу? Пишите 👉: https://forms.gle/utScJQwaQMok91Xz6

Как следить за сроками

Релиз через 2 месяца, мы точно успеваем сделать все к 1 июля?

Есть несколько способов проверить:

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

- Джира отчет Release burndown chart. То же самое, только автоматизировано, если пользуетесь fix version и оцениваете в SP.

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

- Джира плагин Folio - айфон, в мире плагинов. Помимо дедлайнов, он отслеживает еще и бюджет, закрывая базовые нужды ПМов при работе с фикс прайс проектами. Стоит безбожные $5,000 в год, но есть триал на 6 (!) месяцев.

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

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