Многозадачность и управление приоритетами

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

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

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

Вот только утверждение, что Цезарь делал несколько дел одновременно - все-таки миф, на самом деле речь шла о быстром переключении задач.

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

Поэтому рациональное желание сделать быстрее/лучше при увеличении допустимого пула задач вполне вероятно приведет к увеличению сроков.

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

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

Часто вышестоящие менеджеры могут забывать о законе Брукса, стремясь увеличить производительность команд с помощью расширения количественного состава:

«Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше».

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

Да и вообще, написание кода - это лишь верхушка айсберга в продуктовой разработке.

😃 iOS Dev