6. Управление IT-проектами и продуктом. Требования, оценка, риски и команда | Технострим
6. Управление IT-проектами и продуктом. Требования, оценка, риски и команда | Технострим
https://www.youtube.com/watch?v=EbeBKWhnJ1Y
• Автор обсуждает свою нелюбовь к диаграммам Ганта, объясняя, что они выглядят отвратительно и занимают много времени на создание.
• Однако, диаграммы Ганта могут быть полезны для составления детального списка задач и отслеживания зависимостей.
• Автор подчеркивает важность требований для обеспечения того, что функциональность определяется пользователем или заказчиком, а не разработчиком.
• Требования помогают избежать споров и минимизировать изменения системы после начала разработки.
• Полнота требований и их соответствие ожиданиям заказчика важны для успешного выполнения проекта.
• Обсуждение важности формирования требований к разработке, включая определение критериев и метрик для оценки работы.
• Упоминание о том, что часто разработчики получают задачу "сделать что-то" без четких требований, что приводит к проблемам в дальнейшем.
• Примеры задач, которые могут быть поставлены перед разработчиками: создание новой рекламы на сайте, улучшение поиска и т.д.
• Указание на то, что формулировка задач должна быть максимально подробной и конкретной, чтобы избежать проблем в будущем.
19:53 Оценка задач и композиция
• Обсуждение важности оценки задач и композиции, включая учет времени на проектирование, общение с коллегами и написание тестов.
• Указание на то, что оценка задач должна включать все этапы разработки, чтобы избежать проблем в дальнейшем.
• Метод оценки задач - программа ревьюти книг, где оптимистическая оценка, наиболее вероятная оценка и пессимистическая оценка складываются и умножаются на 4, затем делятся на 6.
• Этот метод может быть удобен для крупных задач, но не для мелких.
• Можно проводить планирование спринта на 3 часа, собирать команду и обсуждать задачи, или подготовиться заранее, просмотрев бэклок и выбрав задачи для следующего спринта.
• Важно, чтобы в спринте были задачи, связанные с продуктовой разработкой и техдолгом.
30:10 Сомнения в адекватности разработки
• Если есть сомнения в адекватности оценки задач, можно использовать планнинг покер, где каждый оценивает задачу по времени.
• Если разница в оценке большая, стоит спросить у разработчика, почему так происходит.
• Задача должна быть сформулирована так, чтобы разработчик понимал, на что потратить время.
• В видео обсуждается важность декомпозиции задач в продуктовом проекте.
• Декомпозиция должна быть регулярной и учитывать технические и продуктовые аспекты задач.
36:03 Сложности в декомпозиции задач
• Сложности могут возникнуть при формулировании требований и учете возможных проблем.
• Важно учитывать метрики, продуктовые ценности и место задач в родд мапе.
• Сроки задач могут быть разными в зависимости от области работы и сложности задач.
• Важно задавать вопросы о причинах длительных сроков и разбивать большие задачи на более мелкие.
• Обсуждение важности понимания и планирования работы команды, включая выбор и размещение рекламы, редактирование материалов и взаимодействие с другими командами.
• Упоминается важность учета времени и ресурсов при планировании задач.
47:32 Фокус-фактор и планирование спринта
• Фокус-фактор - коэффициент, показывающий реальную производительность команды по отношению к теоретически возможной.
• В идеале фокус-фактор должен быть 0.8, но в реальности может быть ниже.
• Обсуждается корректировка объема спринта в зависимости от фокус-фактора.
50:55 Выгорание и планирование времени
• Упоминается выгорание задач и важность планирования времени для изменений в команде.
• Обсуждаются возможные причины выгорания задач и важность согласования с партнерами и продажными командами.
55:30 Проблемы с задачами в разработке
• Менеджер должен следить за тем, чтобы команда разработчиков не была перегружена задачами и не было вбросов.
• Важно уметь коммуницировать и договариваться о правильных вещах, чтобы избежать проблем с задачами.
• Если задачи не двигаются, возможно, менеджер плохо скоординировал команду или разработчики не хотят делать задачи.
• Важно показывать свой большой род мап и объяснять продуктовую важность для своего продукта.
• Риски могут быть связаны с болезнями, отпусками, изменениями в команде и другими факторами.
• Определение рисков, оценка, определение стратегий и регулярное отслеживание изменений помогают управлять рисками.
01:09:35 Работа с рисками в разработке
• В видео обсуждаются четыре стратегии работы с рисками: уклонение, снижение, передача и принятие.
• Уклонение - полное исключение риска из проекта, но это не всегда возможно.
• Снижение риска - уменьшение вероятности его влияния на проект.
• Передача риска - перекладывание ответственности на других, но это не всегда эффективно.
• Активное принятие риска - формирование резерва времени на устранение последствий или наличие плана Б на случай, если риск материализуется.
01:11:54 Примеры рисков и их решение
• В видео приводятся примеры рисков и их решения.
• Если разработчик заболел, можно использовать план Б или распределить задачи между другими членами команды.
• Если дизайнеры делают что-то не так, можно попросить их исправить ошибки или попросить их ставить задачи с повышенной важностью.
• Если коллеги предлагают срочные и опасные проекты, можно отказаться или объяснить причины отказа.
• Если у вас есть большой поток пользователей и вы не можете починить продакшн за день, вы можете потерять много денег и сил на восстановление.
• В таких случаях лучше отказаться от рискованных проектов.
01:20:10 Учет рисков в проекте
• Риски с вероятностью 80% и выше считаются случившимися, с вероятностью 20% - маловероятными.
• Включение в бюджет оценки риска и стоимости мер по работе с риском.
• Падение сервера, авария в компании, отключение света, уход сотрудника, конфликты в команде.
• Моделирование риска с помощью экспериментов и оценки вероятности.
• Использование симуляторов и научных работ для изучения метода.
01:30:30 Важность эмпатии и коммуникации
• Менеджер должен помнить об эмпатии и понимать, как люди будут чувствовать себя, работая с ним.
• Золотое правило нравственности: относись к другим так, как хочешь, чтобы относились к тебе.
01:36:01 Коммуникации и письма
• Письма должны быть структурированы, иметь тему и быть полезными для получателя.
• Создание чатов с мемесами и использование их для командной культуры.
01:39:21 Встречи и их эффективность
• Встречи должны быть полезными и иметь план.
• Встречи для решения проблем, а не просто для общения.
• Встречи должны иметь три пункта: выяснение проблемы, понимание и выводы.
01:43:56 Организация встреч с другими командами
• Рекомендуется проводить встречи с другими командами раз в квартал или раз в три месяца для обсуждения изменений и планов.
• Приходить на встречу подготовленными, с презентацией и списком вопросов, чтобы продуктивно провести время и получить необходимую информацию.
01:45:04 Важность списка вопросов
• Приходить на встречу с заранее подготовленным списком вопросов, чтобы улучшить свой продукт и получить необходимую информацию.
• Важно заранее определить цель встречи и сообщить об этом всем участникам.
• Рекомендуется записывать встречи на диктофон или с помощью специальных приложений, чтобы иметь возможность вернуться к обсуждению и проанализировать его.
• Если участники отказываются от записи, можно попросить кого-то из команды записывать или договориться о периодической смене ролей.
01:46:36 Важность встреч и совещаний
• Необходимо приводить к решению проблемы на встречах, а не просто обсуждать.
• Важно писать итоги встреч и доводить их до всех участников.
01:50:53 Работа с командой и серверами
• Менеджеры должны быть готовы к работе с командой и серверами, решать проблемы и улучшать процессы.
• Если у команды нет ресурсов или решений, менеджеры должны обратиться к другим отделам и решить проблему.
01:53:29 Работа с разработчиками
• Менеджеры должны быть готовы вникать в процессы разработки и понимать, что происходит.
• Отвечать на вопросы разработчиков и быть конструктивными в своих ответах.
01:57:20 Реагирование на проблемы
• В случае проблем с продакшеном, менеджеры должны быть спокойными и конструктивными, не истерить и не обвинять других.
• Решать проблемы и не искать виноватых, а сосредоточиться на решении проблемы и предотвращении ее повторения.