🔥 Самые интересные материалы по управлению проектами за 2 недели Основы, гайды, кейсы (ч.2)
🐱 Как фанфик по Гарри Поттеру стал лучшей книгой по рациональному мышлению для программистов
Да, вот так вот - материал про легендарный фанфик про ГП (а какие фанфики читаете вы, мы знаем). Коротко - про полезные приемы типа: обновления гипотез по мере появления данных, борьбы с искажениями мышления, силы экспериментов. Отдельно подчёркивается важность различать совпадение и причинно-следственную связь при разборе инцидентов. В целом - учимся сами и учим команду сомневаться в первых объяснениях, проверять альтернативы и фиксировать, что именно привело к улучшению (или ухудшению).
🐱 Jira для управления тестовыми проектами: советы по организации работы и документированию
Пошаговый разбор того, как настроить систему задач под нужды QA: фильтры и язык запросов для быстрых выборок, массовые операции для изменений «пачкой», публикация выборок на панелях.Много примеров и советов.
🐈 Парадокс Джевонса и «эффект Черномырдина» ИТ проектов: как оптимизация приводит к катастрофе
О том, как улучшение отдельного узла системы может усилить нагрузку на весь поток и обернуться падением качества. Парадокс Джевонса - это когда повышение эффективности увеличивает потребление ресурса. В проектах это проявляется как «успели больше — на нас свалили ещё». (ну и что-то напоминающее «хотели как лучше, а получилось как всегда»).
🐱 Разработка и управление требованиями Систематизация работы с требованиями: от постановки цели и границ до формулировок, сценариев и критериев приёмки. Отдельный акцент - на свойства «качественного требования»: однозначность, проверяемость, осуществимость, связность с другими, на ведение единой структуры артефактов, прослеживаемость от задачи до результата и порядок изменения требований с оценкой влияния.
🐱 Почему ваше проектное управление никогда не будет работать Автор разбирает типичные иллюзии: попытку заменить ясные цели количеством совещаний, надежду «урегулировать» неопределённость регламентами и веру в «срок из воздуха». Корни сбоев — отсутствие понятного результата для пользователя, несогласованные приоритеты и слабая ответственность за решение. Что делать? Вести единый список работ, делать открытые критерии «готово», ограничить параллельность и регулярно проверять пользу.
Эссе напоминает: технический долг — это сознательное заимствование времени (“по-быренькому” залатаем), за которое мы потом платим ростом сложности и рисков. И опасность не в самом долге, а в том, что о нём забывают и не закладывают погашение. Что предлагает автор - вести явный реестр долгов, оценивать «процентов» (во что выливаются задержки и ошибки) и плановую долю времени на возврат.
🐱 Kaiten после 7 лет в Jira: рассказываю про свой опыт
Автор сравнивает многолетнюю работу в крупной системе учёта задач с переходом на более лёгкий инструмент. Главная идея - избыточная сложность настроек, полей и схем статусов со временем начинает жить собственной жизнью и мешать работе. Соответственно, переход дал упрощение и повысил скорость работы. Адептам джиры не читать)
