Хочу оптимизировать процессы в разработке. Мы выросли, команда большая, но очень медленно выпускаются новые фичи. Хотим, чтобы вы, Алексей, поработали с командами и наладили быстрый выпуск фич. Возможно?
Да, конечно. Именно этим я и занимаюсь всегда.
Сколько времени займёт?
И вот тут, ты задаёшь вопросы, выясняешь детали (со слов руководства) и, кажется, ну ok, вроде бы типовая ситуация - конечно же, нужен аудит сначала, но, наверное, месяца 3-4…
А потом ты проводишь аудит и выясняешь, что в компании история как на моей любимой картинке из Клауса Леопольда (пожалуйста, посмотрите её, прежде чем читать дальше).
То есть проблема в скорости - не в разработке. И хорошо, если так же очевидно, как на картинке, что мы долго ждём управляющего комитета, квартальных планирований, согласований, интеграций итп.
И ты понимаешь… надо будет начинать вовсе не с разработки.
Идёшь определять стратегию (60% компаний с которыми я работал имели проблему именно там), сокращать портфолио проектов (80% компаний с такой проблемой), или идёшь работать с продажниками и определением, а что вообще такое “обещание заказчику” и “продажа” - коммитмент или не коммитмент?
Какие тут 3-4 месяца.
И изначальный вопрос заказчика оптимизировать процесс разработки перевоплощается в совсем другое.
А, бывает, уже и аудит проведёшь - и начнёшь работать, и уже в процессе работы выясняешь, что вообще в половине компании система оплаты труда почасовая. И там об ускорении работы никому говорить невыгодно.
Конечно, список вопросов на аудит всё пополняется и пополняется, но даже за 17 лет работы всё равно бывают новые ситуации.
В общем, ответ на вопрос в заголовке:
Попробовать оценить проект изменений, конечно, можно из опыта по аналогии с другими проектами. Но если перед тобой компания сложнее стартапа на 10-20 человек, то это, к сожалению, ничего не гарантирует.
Даже отдельные этапы проекта оценить сложно, потому что 90% зависит от ожиданий “как скоро соберётся комитет утвердить стратегию”, “как быстро продавцы смогут утвердить новые алгоритмы продаж”, “как много подводных камней вскроется на уровне работы в командах”
Но из хорошего:
Ни разу не было такого, чтобы из-за расширения масштаба изменений останавливали проект. Всё-таки если меняться надо, и изменения в разработке не дадут желаемого эффекта, то надо менять в другом месте - это все понимают.
Взгляд на организацию заказчика, как на систему поставки ценности клиентам заказчика, позволяет отлично сфокусировать внимание на действительно важных моментах.
Главное - наглядно показать, что изменения именно в этом месте тормозят процесс. Тут в помощь данные из информационных систем компании и статистика.