Comments 20
Почему продукты со временем теряют способность к инновациям, даже имея все ресурсы? Ответ не в технологиях. Ответ — в ментальных ограничениях.
Давным давно, очень умные и инициативные люди решили освободить всех людей от гнёта и дать им творческую свободу. Ведь очевидно же, что человек, по природе своей, инициативен и жаждет творить. Надо просто найти что ему мешает.
70 лет эксперимента показали, что людям ничего не мешает работать в полную силу - они просто не хотят это делать
У меня нет метрик или подтвержденных данных, но мне кажется, что корневая причина чуть-чуть в другой плокости.
По большому счету, у любой компании может быть одна из двух интенций:
создавать (прорывной) продукт.
зарабатывать деньги.
Если в компании работает 200 разработчиков, то компания однозначно зарабатывает деньги, надо же чем-то зарплату платить хотя бы. На таком этапе что будет делать компания определяется тем, что в голове у собственника и топ-менеджмента.
Если там желание делать прорывной продукт, то мы видим что-то вроде OpenAI, где Сэм Альтман пишет работникам наивные письма в духе "мы тут пилим будущее, чего вы за зарплатами уходите-то" (возможно, я неправильно оцениваю мышление г-на Альтмана и это на самом деле циничная манипуляция).
Пример компании, где интенция поменялась в сторону зарабатывания денег -- Blizzard. Ребята имели линейку прорывных продуктов с невероятно лояльной фанбазой. Ровно до момента, когда высшее руководство решило, что пора бы уже зарабатывать больше денег. Фанбаза не очень оценила и сейчас компания по оптимистической оценке -- в стагнации. И давно не делает ничего прорывного.
Содержимое головы собственника-топов неизбежно будет фоном влиять на компанию через управленческую иерархию. А там и ментальные блоки на инновации у команды появятся.
Технический долг почти всегда следствие управленческого. Если продукт ориентирован на рост прибыли, а не идей, то страх ломать быстро становится нормой
Я бы не стал так категорически заявлять. Управленческий, технический, дизайн долги зависимы, но развиваются обособленно.
Однако стоит отметить, что представители, Лиды разработки не так прокачены в ведении переговоров и поэтому разработка находится в слабой позиции в менеджменте (в бизнесах, которые ориентированы на финансовую эффективность, open ai в данном случае не такой) и постоянно под давлением. Отсюда и дополнительные тех долги
Самое страшное в крупных продуктах не баги и не легаси, а момент когда команда искренне верит что "это невозможно" и даже не делает оценку
Почему команда из 200 разработчиков оценивает задачу в 6 месяцев, когда стартап из 10 человек делает её за месяц? Почему продукты со временем теряют способность к инновациям, даже имея все ресурсы? Ответ не в технологиях. Ответ — в ментальных ограничениях.
Конечно же нет, что за инфоциганство (вы считаете что 10 человек более уверены в себе чем 200?)... Все упирается в архитектуру программных решений (проблемы добавления, оценки, изменения функционала), но менеджеры уже не знают как свою работу оправдывать... Все рассказывают как че надо сделать, (мотиуацию надо подняяяяять!1!!)
Я не считаю малую команду более уверенной, но вот амплитуда рассматриваемых вариантов решений в малой команде было сильно выше. Так было в тех примерах, что видел своими глазами.
И дело не в мотивации, а в иерархии менеджмента и накопленном «опыте». В итоге на каждом уровне вариативность решений снижается.
И получается, как в старой присказке «замах на рубль, а удар на копейку»
Плюс много. Когда приложение делает одна команда, проблема "как добавить кнопку на экран X" решается максимум одним вопросом Васе, а минимум - так вообще минутным совещанием в своей же голове.
Когда на каждый экран работают по 2-3 команды, этот вопрос превращается в переформулирование бизнес-обоснования, встречу для описания ожидаемого поведения, размещение задачи в бэклоге соседней команды и периодическое её пинание ради движения по бэклогу. И это даже не то, что излишества сами по себе - это объективная цена координации, даже в идеальных процессах.
И самое интересное: я встречал ситуации, когда эти 2-3 команды попросту не нужны. Но стейкхолдер какой-то отдельной бизнес-функции считает неудобным хождение с запросами в единственную команду, и выбивает выделение под свои фичи отдельной, которая будет работать только на него. То есть работа никуда не девается, просто высокоуровневая проблема совмещения бизнес требований замещается низкоуровневой: совмещения технических решений. А оверхэды съедают всю выгоду от дополнительных рабочих рук. Но это всё где-то внизу...
Отличный текст, спасибо. Два дополнения: у птичек, которые строят не только код, но и физические объекты, точно такие же проблемы; и да, есть корневая причина в необходимости корректировки целеполагания. Если задача просто зарплату получать, то они все правильно делают на вводной картинке.
Странно называть потерями упущенную выручку. Потеря это когда у тебя было, а потом не стало. Когда выручки не было, то и потери этой выручки не могло быть.
Абсолютно доминирующую роль играют обьективные факторы. Если "стартап из 10 человек сдалал за месяц то что делает команда из 200 за пол года". То либо они сделали разные вещи, либо 200 человек некомпетентны. Стартап сделал МЖП которое взорвется если подключатся 100 пользователей одновременно, а двести человек делают то что миллионы выдержит.
доброго всем! что-то хабр прорвало на подобные или схожие публикации :)
предисловие: я в теме с 12 лет (сейчас мне 60 :)).
почему небольшая команда создает программу быстрее и эффективнее, чем крупная компания с 10^n ресурсами? для МЕНЯ ответ очевиден: команда объединяет единомышленников, которые ПИШУТ ПРОГРАММУ т е. заняты ТВОРЧЕСТВОМ, компания объединяет людей в погоне за ПРИБЫЛЬЮ, т.е. заняты РАЗРАБОТКОЙ.
согласитесь, сравнивать ТВОРЧЕСТВО и РАЗРАБОТКУ равносильно тому, как сравнивать создание болида формулы 1 с конвейером форда (сравнение - первое, что в голову пришло :)).
и то и другое имеет право на существование, только уж разработка никогда не создаст шедевра, она только может им воспользоваться.
моё мнение субъективно, но это моё мнение от которого я не намерен отказываться :)
ПыСы В процессе написания коммента возникла шальная мысль - если разработка ПО это конвейер, то замена человек -> робот очевидна :) уже предвижу массу гневных откликов :)))
почему небольшая команда создает программу быстрее и эффективнее, чем крупная компания с 10^n ресурсами?
Вы пропустили шаг на котором подтвердили что "небольшая команда создает программу быстрее и эффективнее, чем крупная компания с 10^n ресурсами".
Сперва нужно подтвердить наличие явления а потом уже задаваться вопросом о его природе.
Откуда взялись дополнительные 4 месяца? Из страха. Из ментальных ограничений. Команда добавила "буфер на всякий случай", потому что "с этим модулем всегда что-то идет не так".
0.Страх "чего"? Страх того, что не выполнишь задачу в срок и на ближайшем "перфоманс ревью" тебя этим будут бить больно по голове? :) Поэтому, когда в задаче много неизвестного, повышать сроки это логично.
В последние 6 месяцев команда отклонила амбициозные идеи со словами "это слишком сложно" до детального анализа...
1.Обычно на детальный анализ "сложного легаси" нужно много времени наиболее квалифицированного разработчика (а то и не одного, если задача масштабная), который и так перегружен. Если даже банально выделить их время на серьёзное исследование сложно, тогда при вносе в команду "амбициозной задачи" команда будет завышать сроки. А технический руководитель будет кивать прогнозу команды, т.к. если линейных разрабов "пожурят и лишат премии", то техруку снимут голову.
Ещё рапространённый вариант, команде просто не дают время на ресёч: "амбициозную идею" притаскивают под занавес периода планирования со словами "сегодня, край завтра скажите сроки реализации" (ну и закоммитьтесь под этот срок, естественно). Результат - см. п.0
Ментальные ограничения в управлении продуктом: как они незаметно убивают инновации