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