ProductLand
24 октября 2022
Затраты, которыми нельзя пренебрегать
Крис Гейл, вице-президент по разработке компании Yammer, недавно впечатлил посетителей саммита First Round CTO выступлением на тему "Почему традиционный метод организации разработки мертв". Теперь он вернулся с новым материалом, на этот раз - в текстовом формате. Читайте перевод его статьи о том, как новые функции могут создавать дополнительные “затраты на сложность” в вашей компании.
Материал отобран, переведен и отредактирован командой ProductLand. Читать в источнике.
Я много говорю о затратах. Считаю, что хорошая разработка - это поиск и реализация наиболее экономически целесообразного решения проблемы, независимо от того, измеряются ли затраты в долларах, часах, нервах или упущенных возможностях. Некоторые затраты оплачиваются сразу, а некоторые откладываются во времени как долг. Как правило, все внутри компании интуитивно понимают это. Но некоторые затраты менее очевидны, чем другие, поэтому важно подчеркнуть их для вашей команды.
Из не учитываемых при разработке затрат как особенно опасную я бы выделил так называемую “стоимость сложности”. Это долг, который вы накапливаете, усложняя функции или технологии для решения пользовательских проблем. Переработать код в приложении, которое делает двадцать вещей, сложнее, чем сделать то же самое в приложении, которое делает одну вещь. Поэтому будущие изменения в коде займут больше времени. Иногда затраты на сложность необходимы. Но только те компании, которые полностью осознают эту концепцию, могут рассчитывать на предотвращение чрезмерных расходов в этом направлении.
"Неужели вы не можете просто..."
Я много лет общаюсь с продактами. И за все это время меня больше всего расстраивали две вещи, что я слышал от них: "Как же это сложно..." и "Неужели вы не можете просто...". Мне потребовалось немало времени, чтобы понять, почему я так остро реагировал на эти фразы. Сейчас ответ кажется очевидным. Чаще всего работа по внедрению функции на начальном этапе содержит в себе лишь малую часть работы по поддержке этой функции в течение всего срока службы продукта. И да, мы можем "просто" закодировать что угодно. Но то, что займет две недели прямо сейчас, добавляет незначительную стоимость разработки к каждому проекту, за который мы возьмемся в рамках этого продукта в дальнейшем. На самом деле, первоначальное время, затраченное на реализацию функции - один из наименее значимых моментов, что стоит учитывать при взвешивании затрат и преимуществ этой функции.
Часто именно второстепенные или намеренно скрытые функции обходятся дороже всего в долгосрочной перспективе. В Yammer уже давно есть функция, которая позволяет начать сообщение с "to:" и имени пользователя (чтобы отправить личное сообщение), или с имени группы (чтобы отправить сообщение в группу). На реализацию, тестирование и развертывание этой функции в 2008-м году у меня ушел, наверное, один час. За прошедшие 5 лет я потратил 40 часов своего времени на объяснение этой функции и ее обоснование.
В работе продакта - немало подводных камней. Если вы хотите быстрее и безболезненнее вырасти до уровня Senior, лучше знать о них заранее. Совместно с ProductStar мы подготовили большой курс для тех, кто хочет вырасти в профессии и закрепить новые знания на практике. Промокод со скидкой на курс - по ссылке.
Как только вы начинаете работать с кодом, стоимость сложности становится более очевидной
Когда вы впервые открываете новую часть кода, вам нужно сориентироваться. Чем меньше функционала обеспечивает код, тем быстрее этот процесс. Даже хорошо отлаженный, хорошо написанный, чистый код может потребовать времени, чтобы освоиться в нем, если он отвечает за множество функций. Любое упущение ведет к дополнительной работе. Возможно, вы провалите модульный тест. Возможно, вы не сделаете этого, и тогда код попадет к пользователям, которые позже сообщат об ошибках. Это отнимет время вашей техподдержки до того, как код вернется обратно к вам и его стоимость возрастет еще больше в процессе переработки.
Джим Паттерсон, бывший Head of Product в Yammer, определил миссию своей команды как ускорение работы разработчиков. Он делал особый акцент на том, что продакты и разработчики должны быть едины в вопросах оценки стоимости сложности. Именно такие отношения вам нужны между командой продукта и командой разработчиков. Разработчики должны открыто говорить про затраты на сложность, которые скрывают в себе предлагаемые спецификации, и предлагать альтернативные варианты решений, которые могут сэкономить время в будущем.
Ваши менеджеры, которые общаются с клиентом, и отдел контроля качества будут работать эффективнее, если вам удастся снизить затраты на сложность. Скажем, если в вашем продукте есть два простых переключателя, что взаимодействуют между собой, то предусмотрено 4 состояния, которые должны быть протестированы и понятны клиенту. Если у изделия три переключателя, у вас есть 8 состояний. Если четыре, то состояний уже 16. Третий переключатель, добавляющий 4 состояния, вероятно, так же легко интегрировать в продукт, как и четвертый тумблер, который дает еще 8 состояний. То же верно и для шестого переключателя, который добавит 32 (!) состояния. Вопрос в духе: "Насколько сложно было бы добавить этот переключатель?" демонстрирует отсутствие понимания общих затрат. Вопрос: "Насколько сложнее нам будет в дальнейшем с этим тумблером?" приближает нас к правильному обсуждению.
Обратитесь к данным
Если говорить о продукте, то лучшим инструментом для исключения затрат на сложность являются данные. Исследования показывают, что большинство идей, связанных с продуктом, не дают ценности, а многие идеи даже убивают ценность. Если вы методично проверяете влияние каждого вносимого изменения, вы можете отбросить те, которые приносят вред продукту. А еще, что не менее важно для стоимости сложности, сможете отбросить и те, что можно назвать нейтральными. Изменение, которое не влияет на KPI, все равно вредит продукту, ведь оно добавляет долг за сложность, который придется выплачивать во всех последующих проектах. Прозвучит странно, но иногда лучшее решение для продукта - сократить его функционал.
Кроме того, данные помогут вам со временем снизить уровень сложности. Идеально, если вы знаете как часто используют каждую из функций вашего продукта. Ваша команда должна четко понимать, где искать эти данные и как их интерпретировать. В компании Yammer, где данные собираются почти по каждой функции и доступны всем, я неоднократно наблюдал следующую картину. Разработчик работает над частью кода и обнаруживает, что для рефакторинга или другого изменения функции потребуется больше времени, чем ожидалось изначально. Вместо того, чтобы вслепую браться за эту работу, он обращается к данным, чтобы выяснить, часто ли используется данная функция. Затем эти данные можно передать продактам, которые помогут решить: а не стоит ли просто отказаться от данной функции?
Обучите всю свою команду разработчиков понимать стоимость сложности и использовать данные для ее снижения.
Примите простоту в разработке, процессах, продукте
Лучшие инженерные решения обычно не выставляются напоказ и не выглядят насыщенными. При одинаковом результате более простой код будет ценнее для вашей команды. Это часто не удовлетворяет эго людей, но лучшим разработчикам нечего доказывать.
Я помню, как в начале своей карьеры наслаждался работой над документацией своего проекта. Это была возможность похвастаться тем, насколько умным был код, как много он мог сделать и как легко его было расширить для любого, кто нашел время прочитать всю эту замечательную документацию. У меня прямо-таки дух захватывало, когда я рисовал сложную систему, которую я разработал, на доске с помощью квадратиков, стрелок и линий. Я был уверен, что эта документация и иллюстрации - доказательство того, что я классный разработчик. Когда я действительно стал хорошим специалистом, то понял, что чем проще я могу что-то создать и чем меньше это требует документации и иллюстраций, тем лучше для моих коллег - тем быстрее мы все сможем создать то, для чего нас наняли.
Примите простоту в своем продукте и в коде. Ценность - в том, что используется, а не в том, что создается.
Скажу больше: примите простоту даже в общении. Вытесняйте жаргон, непонятные аббревиатуры и сложные термины. Поощряйте простоту и эффективность общения. Ваши лучшие сотрудники могут объяснить ребенку все, чем занимается ваша компания. Ваши худшие сотрудники - это те, кто звучит умно и официально в ущерб тому, чтобы быть понятым всеми.
Прокачайте навыки middle и senior продакта на нашем совместном курсе с ProductStar. Забирайте промокод на скидку в 56% по ссылке.
