Странный заголовок, не правда ли? Может лучше так: может ли стартап обойтись без детских болезней? Или так: как проще всего потратиться на маркетинговую компанию впустую. Если вы были частью стартапа — это может быть неинтересно. А может быть наоборот.

Выжженная земля, песок и дым вдалеке. Разбитые лампы и стимпанк во всей неприглядности. Да все верно. Примерно такую картину я вижу у любого успешного стартапа. Да простят меня иные отрасли, но поговорить решусь про ай ти.

Помимо обреченности и фаталистичности у меня есть некоторый опыт наблюдения за довольно успешными стартапами. По мере развития любого проекта в нем появляется все большее стремление к специализации. Это неизбежное и желаемое движение от стартапа к серьезному бизнесу. Выделение отделов и их неизбежная изоляция, появление поддержки, ее дробление и разделение по уровням невменяемости пользователей. Процесс бюрократизации неизбежен и, очевидно, обязателен. И именно он приводит к коллапсу. Очень давно, еще в прошлом веке, один талантливый мужчина все изложил в рассказе, а другой, ничуть не менее талантливый, изобразил в сценке "Кто сшил костюм". В двадцатом, социалистическом веке это было остро и смело. А в нынешнем веке это кажется пророческим. Каждый решает только свою проблему. Это его уровень ответственности. И это совершенно нормально. Цель и задача стартапа в развитом предприятии совершенно потеряны. Руководство будет слушать только продажников. Это совершенно оправдано - деньги идут только от них. Поддержка будет иметь четкий чеклист и он будет работать. Это тоже неизбежно и правильно. В поддержке не нужно творчества. Оно замедляет реакцию и увеличивает количество работы. Разработка на этапе хорошо функционирующего бизнеса не особенно нужна: все самое трудное уже решено, у брэнда есть известность и люди идут сюда за строчкой в резюме, а не в ожидании зарплат. К определенному моменту это создаст коллектив кипучей работы ради процесса. Люди будут вести блоги, выступать с лекциями и всячески популяризировать брэнд. Но рутина доведет их до банальных и неожиданных ошибок. Они устанут и уступят свое место новым, которые заменят незаменимых. В один момент уйдет в отпуск последний, понимающий архитектуру разработчик и в этот момент придет странный запрос про потерянную транзакцию.