Многозадачность и управление приоритетамиНа моей практике не сосчитать случаев, когда появлялись задачи с высшим уровнем приоритета, которыми нужно заменить часть текущих, а при тестировании появлялись корнер-кейсы, о которых догадаться просто-напросто невозможно.
Например, управление одной учеткой в реальном времени с разных девайсов и совершение почти похожих действий могут привести порой к неожиданным результатам (предотвращение таких гонок - одна из задач в любых системах общения, будь то какой-нибудь мессенеджер, и, например, организация голосового/видео чата).
И может показаться, что есть опция захватить пачку задач сразу и выполнять их параллельно, буквально как Юлий Цезарь.
Вот только утверждение, что Цезарь делал несколько дел одновременно - все-таки миф, на самом деле речь шла
о быстром переключении задач.
И хотя такой навык особенно полезен в нашей сфере, но на самом деле
сумма времени, потраченного на эти несколько задач якобы параллельно, будет точно такой же и при последовательном подходе.
Поэтому рациональное желание сделать быстрее/лучше при увеличении допустимого пула задач вполне вероятно приведет к увеличению сроков.
При оценке задач с опытом приходит и то, что фича попадет в релизную сборку не только после того, как вы напишете код, но и когда её протестируют, требования по ТЗ будут уточнены, а все изменения по дизайну приняты и реализованы.
Все остальные вещи вроде наличия общей дизайн-системы, общего подхода к проверке фич и заранее заложенного времени на тестирование могут помочь, но совершенно не гарантируют, что заложенное в неделю время окажется в итоге неделей, а не месяцем.
Часто вышестоящие менеджеры могут забывать о законе Брукса, стремясь увеличить производительность команд с помощью расширения количественного состава:
«Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше».
На самом деле, все абсолютно логично - новых ребят, пусть и супер-толковых, всегда необходимо онбордить, естественно закладывать время на обучение от их коллег и постепенно погружать в документацию.
Да и вообще, написание кода -
это лишь верхушка айсберга в продуктовой разработке.
😃
iOS Dev 
