MIC Group

Для пользователя релиз — это О, новая фича появилась!. Для команды это многочасовой процесс, где цена ошибки очень высока. Это целая цепочка действий, где каждый шаг важен. У нас релиз — это стандартизированный процесс...

Это классика: бизнес хочет вчера и подешевле, а разработка — делать качественно и без багов. Знакомо? Это не чья-то вина, а нормальная динамика любого проекта. В итоге бизнес давит на скорость, а разработчики боятся костылять, чтобы не получить головную боль потом. В реальном мире всё строится на компромиссах...

Многие думают, что code review — это когда сеньор проверяет джуна, чтобы найти ошибки. На самом деле всё гораздо глубже. Главная цель — не поймать опечатку, а обеспечить качество и обмен знаниями. Бывает, что смотрят только на форматирование и ставят LGTM («Looks Good To Me»)...

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

Есть популярный миф: если проект провалился, значит, программисты написали плохой код. На деле всё гораздо интереснее. Давайте честно: код — это обычно не главная причина провала. Настоящие проблемы кроются совсем в другом. По статистике, до 70% всех проблем в IT-проектах связаны с недопониманием между заказчиком, командой и менеджерами. Итог — все переделывать, сроки летят, бюджет растёт. В IT всё так же. Если на старте не договорились на берегу, кто, что и когда делает, проект обречён на хаос. В среднем, в каждом втором проекте требования меняются по ходу работы...