Некомпетентность команды, которая делает проект – очень распространенная ситуация. И, оказывается, в новом цифровом мире это не просто бизнес-модель подрядчика, для этого есть системные причины и это – неизбежно. Тезис – не тривиальный, и потому я решил посвятить ему отдельную статью.
Мне кажется, что некомпетентность команд, конечно, объективная вещь, но это не такое уж распространенное явление. Большинство задач, которые решают IT специалисты, весьма типовые и повторяются из компании в компанию. В итоге 95% всего что делается будет делаться командами с достаточно степенью компетенции. Остается небольшой процесс инновационных задач и пограничных случае. В случаи иновационных задач сама задача определяет то, что любая команда с ней сталкивающаяся окажется недосточно компетентной вначале. А пограничный случай – это ситуация излишнего оптимизма, когда команда лезет в область, которую не очень знает или недооценивает сложность, ну или бизнес специально выбирает тех, кто готов озвучивать фантастические по скорости планы, которые олждаются из-за некомпетентности команды.
Не, вы не понимаете ситуацию. Инновационных задач вовсе не 5% и даже не 10, их гораздо больше. Есть такая штука - TRL, Technology readiness level придуман NASA чтобы оценивать, насколько новые технологии гарантированно дают результат. Потом это начали использовать широко. И вот Боинг, который контрактует самолеты на стадии конструирования, выяснил, что чтобы контракты выполнялись, в новый самолет можно закладывать технологии с уровнем не ниже 8 из 10. Иначе провал по срокам и деньгам почти гарантирован как при большом НИОКР в новой области. Так вот, если мы по этой шкале посмотрим на технологии, на которых сейчас делают мобильную разработку, то их готовность - 4-5. И это - стабильная ситуация, потому что пока технологии становится более надежными, техника делает следующий шаг вперед, и процесс повторяется. Поэтому инновационных задач в IT-отрасли - не меньше половины. Ну, пусть треть.
Дальше, что происходит, когда в отрасли треть задач - инновационные? Их же все равно не новичкам дают, да и многие опытные люди хотят работать с новыми технологиями, а не с освоенными. И их - берут. А в результате те задачи, которые этой 1/3 опытных людей уже освоены, которые для них типовые - они не делают, они заняты новыми проектами. Кто эти задачи делает? Опять-таки некомпетентные - менее опытные, для кого эти задачи дают вызов, и новички. Об этом и было в статье.
Тут ещё проблема что часто именно в этих 5% вся суть проекта и заключается. Например, когда делался условный агрегатор авиабилетов вся сложность была именно в качественной агрегации (5% нового) - все интерфейсы, базовые алгоритмы и т.п. (95% старого) важны, но без этих 5% нового проект теряет смысл.
Поэтому в конце на это есть сноска, что если нет доступа к компетентной команде, то выбросить как раз те 5% задач, смириться с этим (ну или заменить задачи и тд)