Системный подход vs нафигачить

Большинство IT-компаний начинают с малого. Часто с хаотического процесса, держащегося на здравом смысле и воле основателей. Если компания перерастает период «младенческой смертности», начинается осознание не только что нужно делать, но и как нужно делать. В процессе эволюционного развития R&D начинают вводить сложные процессы. При таком подходе становится возможным создавать серийное, масштабное и долгоиграющее; обрести устойчивость и повторяемость результатов разработки продукта или услуги. Происходит постепенное обрастание детальным BA/SA, сложным процессом CI/CD, полным QA automation и т д. Разработка становится неповоротливой, наподобие перекаченного атлета.

Но компании не живут на одном продукте вечно. Старт очередного нового продукта начинается с прототипов. Создание прототипов с тем же выстроенным тяжелым процессом – это долго и дорого. При этом теряется основная идея прототипирования - скорость и невысокие издержки в ущерб качеству. Если речь касается одноразовых прототипов для проверки гипотез или расчетов, то применение тяжелого подхода не оправдано и подавно. Принцип ошибаться часто и дешево никто не отменял.

Однако, самим разработчикам, да и менеджерам сложно перестроится с одних процессов на другие в моменте. Даже не так важно в какую в сторону нужно поменяться: в сторону облегчения процесса или обратно. Просто мозг так устроен, что выработанные и закрепленные паттерны работы не так быстро поменять. Иногда это может даже вызывать реальный дискомфорт и ломку мозга.

Если все так плохо, то что же можно сделать?
Под прототипирование лучше выделять отдельных разработчиков, создавать выделенные команды или даже аутсорсить или аутстаффить разработку прототипов если это не затрагивает статические процессы. В зависимости от типа и размера продуктовой компании мне встречались любые из перечисленных вариантов. Все имеют право на жизнь. Но главная идея - отделить легкие процессы от тяжелых, и тех, кто по ним будет работать.

@aheadofthepack