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