Несколько дней назад я наткнулся на пост в блоге Валентины Купач под названием «Баги и медленные релизы – нормально ли это?» Уже одного заголовка было достаточно, чтобы вызвать у меня раздражение. В смысле? Ответ на этот вопрос известен уже несколько десятилетий! Наверняка это кликбейт и больше ничего.
По мере того так я читал пост, мое раздражение переходило в истинное негодование. В посте (он небольшого объема и хорошо написан, стоит того, чтобы прочесть) Купач утверждает, что баги и долгие сроки – это, на самом деле, нормально. По ее опыту, большинство компаний могут себе позволить выдавать продукт с недочетами и в неспешном темпе. Влияние багов на бизнес не слишком велико, и скорость, с которой они исправляются, большого значения не имеет. Да и то, что разработчикам портит жизнь непрерывный поток срочных багфиксов – не беда.
Несложно догадаться, почему идеи Купач вызвали у меня, поддерживающего благородные принципы вроде разработки через тестирование и магистральной разработки, такое возмущение. Они ведь напрямую противоречат всем моим убеждения!
Но больше всего в ее посте меня разозлило вот что: она была права.
Купач говорит, что пришла к своим выводам, основываясь на личном опыте. Это подтолкнуло меня к размышлениям над собственным опытом, который сложился за пятнадцать лет работы в сфере разработки ПО.
Мне доводилось видеть (и писать) код ужасного качества – так чтобы всё прямо совсем плохо, и с тестами по большей части по нулям. Такое случалось почти на каждом месте работы. Я видел, как на дописывание тестов или исправление багов затрачивалась целая куча времени. Но знаете, чего я не видел ни разу за эти пятнадцать лет? Чтобы компания разорилась.
Затратное и бесполезное переписывание кода, после того как неизбежно объявлялось техническое банкротство – это да. Выгорание разработчиков, которых регулярно принуждают день и ночь работать над устранением багов – тоже было. Суетливые утешения, объяснения и, да, временами откровенное вранье клиентам от коллег из продуктовых команд, когда обновление функциональности запаздывает – и это видел. Но ничего из этого не привело к тому, чтобы компания ушла с рынка.
А всё почему? Думаю, ответ кроется в неприятной истине.
Даже если это техническая организация.
У программных продуктов есть разные пути к выживанию, и многие из них никак не завязаны на качество:
Плюс множество других факторов, никак не связанных с разработкой.
Когда я осознал правдивость аргументов Купач, то понял, что стал жертвой догматического мышления. Я был так убежден, что «высокое качество» (что бы это ни значило) – путь к успеху, что закрывал глаза на стоящие передо мной факты. Подобно овце из романа Оруэлла, я знай себе блеял: «Высокое качество – хорошо! Низкое качество – плохо!», не подвергая эти постулаты сомнению.
Это я не к тому, что теперь переключился на «Высокое качество – хорошо! Низкое качество – еще лучше!» Как отметили многие комментаторы под постом Купач, высокое качество пусть и не является обязательным условием успеха, но повышает шансы его достигнуть. Даже если мы считаем баги и сильные задержки приемлемыми, отсутствие багов и быстрые релизы составляют конкурентное преимущество.
Теперь у меня сложилось более тонкое понимание роли качества в технической компании. Хорошо, если вы поддерживаете его на высоком уровне, но свет на нем клином не сошелся. Иногда решение той или иной организации не вкладываться в качество бывает оправданным. Это не делает людей по умолчанию неправыми.
До сих пор я всегда исходил из того, что любая организация должна стремиться выдавать продукт на высоком уровне. А если пока не получается, то сам собой разумеется, что они идут к этой цели. Такой взгляд на вещи часто приводил к разочарованиям, когда я осознавал, что та или компания не разделяет моего убеждения.
Новый угол зрения в корне изменит моё восприятие технических компаний и, в первую очередь, поможет оценивать, какие из них хорошо вписываются в мои предпочтения касательно качества продукта (а это именно предпочтения, а не закон), а какие – хуже. Так что спасибо Валентине за пост, который заставляет задуматься. Он приятно меня выбесил.
По мере того так я читал пост, мое раздражение переходило в истинное негодование. В посте (он небольшого объема и хорошо написан, стоит того, чтобы прочесть) Купач утверждает, что баги и долгие сроки – это, на самом деле, нормально. По ее опыту, большинство компаний могут себе позволить выдавать продукт с недочетами и в неспешном темпе. Влияние багов на бизнес не слишком велико, и скорость, с которой они исправляются, большого значения не имеет. Да и то, что разработчикам портит жизнь непрерывный поток срочных багфиксов – не беда.
Несложно догадаться, почему идеи Купач вызвали у меня, поддерживающего благородные принципы вроде разработки через тестирование и магистральной разработки, такое возмущение. Они ведь напрямую противоречат всем моим убеждения!
Но больше всего в ее посте меня разозлило вот что: она была права.
Купач говорит, что пришла к своим выводам, основываясь на личном опыте. Это подтолкнуло меня к размышлениям над собственным опытом, который сложился за пятнадцать лет работы в сфере разработки ПО.
Мне доводилось видеть (и писать) код ужасного качества – так чтобы всё прямо совсем плохо, и с тестами по большей части по нулям. Такое случалось почти на каждом месте работы. Я видел, как на дописывание тестов или исправление багов затрачивалась целая куча времени. Но знаете, чего я не видел ни разу за эти пятнадцать лет? Чтобы компания разорилась.
Затратное и бесполезное переписывание кода, после того как неизбежно объявлялось техническое банкротство – это да. Выгорание разработчиков, которых регулярно принуждают день и ночь работать над устранением багов – тоже было. Суетливые утешения, объяснения и, да, временами откровенное вранье клиентам от коллег из продуктовых команд, когда обновление функциональности запаздывает – и это видел. Но ничего из этого не привело к тому, чтобы компания ушла с рынка.
А всё почему? Думаю, ответ кроется в неприятной истине.
Программное обеспечение не решает судьбу организации.
Даже если это техническая организация.
У программных продуктов есть разные пути к выживанию, и многие из них никак не завязаны на качество:
- Некоторые продукты создаются для внутренних потребителей, которые оказываются в положении клиентов-заложников. Они вынуждены проглатывать любую лажу, какую мы, разработчики, им предложим.
- Бывает, что внешние потребители так привязаны к определенному поставщику, что тоже недалеко ушли от положения заложников. Причиной тому могут быть условия контрактов, или глубокая интеграция продукта в клиентскую систему, или откровенная коррупция.
- Конкуренты могут быть ничем не лучше и страдать от тех же самых багов и проблем со скоростью.
- Сильные команды на продажах и обслуживании клиентов могут компенсировать недочеты в функциональности.
Плюс множество других факторов, никак не связанных с разработкой.
Когда я осознал правдивость аргументов Купач, то понял, что стал жертвой догматического мышления. Я был так убежден, что «высокое качество» (что бы это ни значило) – путь к успеху, что закрывал глаза на стоящие передо мной факты. Подобно овце из романа Оруэлла, я знай себе блеял: «Высокое качество – хорошо! Низкое качество – плохо!», не подвергая эти постулаты сомнению.
Это я не к тому, что теперь переключился на «Высокое качество – хорошо! Низкое качество – еще лучше!» Как отметили многие комментаторы под постом Купач, высокое качество пусть и не является обязательным условием успеха, но повышает шансы его достигнуть. Даже если мы считаем баги и сильные задержки приемлемыми, отсутствие багов и быстрые релизы составляют конкурентное преимущество.
Теперь у меня сложилось более тонкое понимание роли качества в технической компании. Хорошо, если вы поддерживаете его на высоком уровне, но свет на нем клином не сошелся. Иногда решение той или иной организации не вкладываться в качество бывает оправданным. Это не делает людей по умолчанию неправыми.
До сих пор я всегда исходил из того, что любая организация должна стремиться выдавать продукт на высоком уровне. А если пока не получается, то сам собой разумеется, что они идут к этой цели. Такой взгляд на вещи часто приводил к разочарованиям, когда я осознавал, что та или компания не разделяет моего убеждения.
Новый угол зрения в корне изменит моё восприятие технических компаний и, в первую очередь, поможет оценивать, какие из них хорошо вписываются в мои предпочтения касательно качества продукта (а это именно предпочтения, а не закон), а какие – хуже. Так что спасибо Валентине за пост, который заставляет задуматься. Он приятно меня выбесил.
