Как известно, в 2018 году компания Google провела крупнейший редизайн интерфейса своего почтового сервиса Gmail. Как обычно, довольны им оказались далеко не все — и на этот раз есть вполне объективные причины для недовольства сервисом. Почему загрузка Gmail стала занимать так много времени, а действия вроде удаления или архивирования цепочки писем могут выполняться 4-6 секунд?
Пару дней назад подобным вопросом задался пользователь Hacker News — и он получил ответ от анонимного сотрудника Google, хлестко проехавшегося по культуре разработки внутри компании и своим коллегам.
С его слов, все это происходит в силу того, что в Google не предусмотрено никаких наказаний за подобные «промахи».
В стенах компании активно поощряют запуски (launch) — публичные релизы чего-либо. И то, что продукты могут содержать лишь половину необходимых фич, не работать, работать только из-под Chrome и прочее — это никого не волнует, ведь их создателям за это ничего не грозит. Это — норма.
Смысл подобный действий заключается только в одном — в продвижении по службе, поскольку без крупных запусков дальше определенного уровня пройти не удастся. Вот мы и получаем в итоге сотни ненужных приложений-чатов, бесконечные редизайны и перезапуски — иначе отдельные личности не смогут получить повышение.
Когда руководство компании попробовало решить проблему, выпустив внутренний документ, который вместо «launches» (запусков) мотивирует достигать успешных «landings» (посадок, успешных запусков) — всё, что изменили в своей жизни сотрудники, так это выполнили s/launch/landing/g в своих performance review.
Возьмем, к примеру, мессенджер Allo. На его разработку ушло два года, после чего компания решила приостановить разработку и заморозить проект. Как выясняется, отвечавшие за мессенджер люди при этом не пострадали — наоборот, некоторые из них даже получили повышение.
Увы, но судя по всему, насущные проблемы пользователей компанию сегодня не слишком интересуют:
Знаете, сколько багов нужно пофиксить, чтобы получить повышение? Бесконечно много. Неважно, как много багов вы исправите — это никогда не принесет вам достаточного «вклада» для повышения, никогда. Но достаточно запустить всего один редизайн — будь даже он практически бесполезен — и повышение у вас в кармане.
Естественно, в стенах самой компании есть люди, которые предупреждают о возможности подобного и жалуются, заносят баги производительности в трекеры — вот только все это игнорируется; большинство работников со временем сдается и перестает писать про баги, ведь типичным ответом им будет «вы не наша целевая аудитория».
И мы все знаем об этих проблемах! Все мы! Некоторые увольняются, когда до них это доходит; другие просто начинают «оптимизацию» в сторону повышения — вместо того, чтобы оптимизировать в сторону того, что будет хорошо для пользователя или для компании.
В своих мыслях разработчик не одинок. Грэхем Уилер поделился историей из своей жизни в Google, подтверждающей его позицию.
Однажды в Google я получил негативный performance review. Я решил, что лучшим способом потратить мое время будет произвести рефакторинг кода, который мне достался, чтобы довести степень его покрытия тестами с 0% до 80%, попутно исправив немало багов. В итоге я получил на performance review дерьмовый отзыв, а автор оригинального говнокода — повышение.
Рассказы о проблемах управления разработкой в стенах Google появляются в Сети регулярно. Реакция пользователей тоже не заставляет себя ждать. Бизнес-клиенты, использующие Google Apps, переходят на FastMail, основной принцип которого — только электронная почта и ничего лишнего.
Примерно так мы с вами и получаем вещи вроде нового Gmail. Который, с одной стороны, заполучил редизайн в духе Material Design, оффлайн-режим и множество других мелких улучшений, которые переносят в него из Google Inbox, который со следующего года прикажет долго жить. С другой — для полной загрузки выполняет 358 запросов и выкачивает 6.3MB. Для сравнения, «древний» режим HTML View в Gmail — это всего лишь 14 запросов и 25.3KB, что позволяло ему загружаться за 2 секунды.
Разумеется, данная практика касается не только Google, но и многих других крупных компаний. Мы наблюдаем известный принцип «Вы получаете то, что вы измеряете» в действии.
Похожую историю рассказал разработчик Стив, работавший в Apple над MacOS X Snow Leopard. Стив по большей части занимался тем, что исправлял баги во всех основных фреймворках ОС — и по итогам выпуска ему было отказано в повышении из-за того, что его присутствие «не было критически важным ни на одном из проектов».
Ирония здесь заключается в том, что данная версия ОС по идее руководства компании должна была стать релизом, в котором все было направлено на улучшение стабильности и производительности системы (у автора этих строк до сих пор сохранились). Однако, в то время как одни ожидаемо работали над стабильностью, другие активно «пропихивали» в релиз новые фичи вроде сборщика мусора для Objective-C, чем задержали работу остальных и сделали XCode неюзабельным на несколько месяцев.
Зато работа над ошибками не прошла даром для простых пользователей, которым запомнились отличная работоспособность Snow Leopard и последовавшей за ней Lion — в отличие от Chrome, который только за время написания этого поста успел пару раз зависнуть и вызвать «крэш» вкладки с черновиком.
Автор: HotWaterMusic
