Comments 3
хороший выбор перевода, спасибо
лишь чтобы добавить третьесортную функциональность в какой угодно, даже самый завалящий продукт.
Возникает очень интересный вопрос: а почему для того, чтобы добавить третьесортную функциональность, требуется придумывать что-то настолько необычное, что нужно ломать существующий процесс разработки? Может быть, это как раз пример кодерства - ситуации, когда программист пишет код не для того, чтобы решить конкретную задачу, а чтобы писать код, который ему нравится?
Во многом, как пользователь продуктов Гугла, я очень рад, что возможности у программистов ограничены. Это делает продукты достаточно предсказуемыми и достаточно надежными. Недавно я был свидетелем того, как в достаточно известном проекте (не гугловом) разработчики реализовали настолько шикарную идею, что через нее сперли кучу важных данных моего знакомого.
С рисками в IT есть интересный момент: программисты очень любят принимать риск на рубль, а нести ответственность на копейку. И в большинстве случаев на вопрос, что же вы будете делать, если риск реализуется худшим образом, программист отвечает "Ну, максимум я уволюсь". Риски может принимать тот, кто за них отвечает, а не тот, кто хочет внедрить технологию с идеей, что она может принести какую-то пользу, будем быстрее кодить, резко релизить и безумно деплоить.
Я не говорю, что в Гугле все отлично. Но очень сильно подозреваю, что многие вещи, описанные в статье - это следствие тех вещей, которые автор не оценивает с высоты своей должности.
Это обычная, практически неизбежная история любой крупной иерархической структуры — корпорации, государства и так далее. Она попросту объективно обусловлена:
Управление с ростом структуры становится сложнее. Отцы-основатели, у которых было видение, уже физически не могут контролировать работу всей структуры.
Значительная часть управления — в руках наёмных менеджеров (в том числе, в конечном итоге, и верхушка структуры, потому что отцы-основатели не могут работать вечно), у каждого из которых какие-то собственные интересы, не всегда коррелирующие с благополучием структуры в целом. Набирать в структуру такого размера исключительно идейно преданных невозможно, их физически столько нет.
Цена ошибки сильно возрастает. Ошибка, которая небольшой компании обходится в сумму от нуля до единиц тысяч долларов, корпорации может стоить десятки, а то и сотни миллионов — потому что будет растиражирована на масштаб корпорации раньше, чем исправлена.
Это неизбежно, обойти это невозможно. Есть различные стратегии митигации, в разной степени успешные — KPI, управление рисками, привязка бонусов менеджмента к успеху компании, сменяемость менеджмента и т.п. Ни одна из них не даёт гарантированного успеха, более того, каждая в зависимости от сопутствующих обстоятельств может привести как к успеху, так и к полному краху.
В целом Google пока держится очень хорошо, при его-то масштабах. То, что внутри это уже не маленькая уютная быстрая инновационная компания — следствие того, что это действительно уже не маленькая уютная быстрая инновационная компания. Ну как «вода не сухая, потому что она мокрая».
Лабиринт внутри лабораторной мышки