Главный враг любых изменений/трансформаций - это… По управлению изменениями у меня было несколько постов, но если подумать, любой проект – это временное предприятие, направленное на создание уникального продукта, услуги или результата. (с) PMBoK Таким образом проект – всегда амбиция на смену status quo, а значит, делать проекты, не управляя изменениями, нельзя. Обратимся к статистике проектов «Много успешных проектов оказалось в IT-индустрии и консалтинге: 56 и 54% соответственно» «Удивительно высокую успешность показывают проекты в научных, образовательных и культурных организациях – 68%, а также в здравоохранении и госсекторе – более 50%.» «Однако в реальном секторе, в ритейле и строительстве ситуация иная. В производстве 29% респондентов ответили, что проекты были удачными, в строительстве и ритейле такой ответ дали 30 и 36% респондентов соответственно» «данные американского Института управления проектами (считается одним из основоположников проектного управления) и международной консалтинговой группы The Standish Group. Обычно из каждых 10 проектов успешными бывают только три, еще три сталкиваются с трудностями, два преодолевают значительные трудности, а еще два и вовсе проваливаются.» Источник Ведомости. Российские компании рапортуют об успешности половины своих проектов Видно, что, несмотря на объем накопленной экспертизы и развитой систмы сертификации, количество успешных проектов сильно не увеличивается. Значит, вопрос не в каком-то фреймворке или методологии, но в фундаментальной проблеме, которая препятствует успешному применению этих фреймворков и методологий. Прежде чем ответить на вопрос в заголовке, я хочу привести один случай. Не так давно выступали с коллегой на конференции Heisenbug. О чем мы рассказывали? О том, что любой бизнес считает деньги и понимает, что ручное тестирование – это бессмысленные потери, от которых нужно избавляться. В одной компании, кстати, так и сделали, и сначала стало очень плохо, а потом стало так хорошо, что никому не хочется возвращаться обратно. Способ борьбы с этими потерями – это автоматизация. Но бизнес на то и бизнес, чтобы думать про затраты, и за счет ее внедрения еще сильнее повышать стоимость разработки, которая только и делает, что растет, никто не хочет. Я, как руководитель дивизиона, думал ровно так же. Поэтому нужно с одной стороны автоматизировать, а с другой, чтобы это не требовало существенного роста компетенций (и зарплат) у тестировщиков. На конференцию мы принесли инструмент, который позволяет сделать тестовую документацию исполняемой (вот так прям на русском). Если будет интересно, как это работает, велкам смотреть доклад или изучать код на gitverse. И вот мы уже подходим к ответу на вопрос, что мешает изменениям. Для этого хочу привести окончание разговора в кулуарах, где один из слушателей мне честно сказал: Я не буду этим пользоваться – это слишком легко… Причина не в том, что дорого, сложно и долго – нет! Все как раз наоборот: 🆓 бесплатно (можно скачать бесплатно на гитверс с лицензией MIT, хотя мы умеем за деньги это внедрять), 🐣 легко (как писать на русском языке) и ⚡️ быстро (1.5 часа на установку и не больше 1 часа до запуска первого теста). Спустя месяц после этого разговора до меня дошло, что главный враг изменений – это ущемленное эго.