Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон

быть неочевидно, но затем выйдет боком, если клиенты примут продукт. Выдерживание срока может помочь завоевать рынок, но клиенты столкнутся с ошибками, проблемами масштабирования, безопасности и т. д. На этом прогресс застопорится, поскольку команде придется исправлять базовые вещи. Это гораздо более неприятно, с учетом того, что у вас появляются недовольные клиенты или неудовлетворенный спрос.

Вот почему многие продукты, созданные по методологии аджайл, начинают свою жизнь с бедным функционалом. Чаще всего функционал продукта не так важен, как быстрое представление идеи клиентам. Таким образом, сроки берут верх над функционалом при соответствующем качестве, надо предполагать. Создание меньшего по объему продукта, но с уверенностью – это путь многих команд, разрабатывающих новый продукт. Если есть ключевой функционал, то к нему всегда можно добавить функции позднее.

Руководителю лучше заняться серьезным обсуждением того, какие параметры необходимо сохранить, а какими можно пожертвовать. В Twilio мы говорим, что качество и доверие – это самое главное. Мы считаем качество драгоценностью, которой никогда нельзя жертвовать. Да, мы совершаем ошибки, но стараемся донести до клиентов мысль о том, что качество для нас не тот аспект, которым можно жертвовать. Как и многие компании, мы проводим большую ежегодную конференцию пользователей (под названием SIGNAL), которая служит нам платформой для анонсирования продуктов, привлечения внимания прессы и информирования клиентов. Поэтому сроком обычно является тот момент, когда маркетинговая команда бронирует помещение для конференции и начинает продавать билеты. Это гарантирует функционал и уверенность. Вообще говоря, неопределенность – скользкая вещь, поэтому функции продукта отдаются на усмотрение команд, с тем чтобы они уложились в срок. Мы измеряем определенность в месяцах до конференции SIGNAL, но, когда остается всего один месяц, она обретает вид однозначного «да» или «нет», и с этого момента функции продукта становятся единственной переменной, которую нужно реализовать в срок. Это хороший компромисс. Как руководители, мы часто зацикливаемся на функциях, однако клиенты редко покупают продукт на основе какой-то функции. Их больше интересует общий функционал, а функции всегда можно добавить позднее. Таким образом, руководители компании и менеджеры по продукту должны заранее определить, какие функции имеют первостепенное значение для принятия продукта клиентами и его конкурентоспособности на рынке, а какие просто было бы неплохо иметь.

Почему на решение проблемы нельзя бросить больше разработчиков?

Обычно руководители рады получить больше ресурсов, поэтому, когда техническим директорам предлагают увеличить численность сотрудников или бюджет для ускорения проекта, их отказ вызывает удивление. Кому не хотелось бы увеличить бюджет и штат? Причина в том, что переброска дополнительных работников на решение проблемы (особенно если проект выполняется, но отстает от графика) вряд ли поможет. На самом деле подобное решение может еще больше задержать работу над проектом. Почему же получается такой парадоксальный результат, особенно в краткосрочной перспективе? Да потому, что подбор исполнителя любой роли требует времени и отвлекает от текущей работы. Время нужно и на то, чтобы новый разработчик вошел в курс дела. Даже если вы наймете его сегодня, он не будет продуктивно работать, пока не ознакомится с кодовой базой и стилем работы команды. Этот процесс обычно занимает несколько месяцев и ничем не отличается от того, что происходит в других отделах. Возьмите отдел продаж – если вы нанимаете нового торгового представителя, ему требуется время, чтобы изучить набор продуктов и начать заключать сделки. Поэтому если вы не дотягиваете до целевых показателей по доходам в текущем квартале, то наем дополнительных торговых представителей прямо сейчас вам не поможет. То же самое и с разработчиками – для повышения производительности нужны предварительные затраты. Но если привлечь разработчиков из другой команды, то эти затраты значительно сократятся. Почему бы не поступить именно так? У ПО есть и другие, уникальные проблемы.

В 1975 г. пионер софтверной индустрии Фредерик Брукс-младший опубликовал сборник эссе о разработке программного обеспечения «Мифический человеко-месяц»[9]. Одна из основных идей, давшая название книге, – это «мифический человеко-месяц» (я буду называть его «мифическим разработчико-месяцем»). Ее суть в том, что с увеличением численности разработчиков проекта, который отстает от графика, шансы на срыв сроков только возрастают. С чем связан такой нелогичный результат? Прежде всего со временем на введение новых разработчиков в курс дела. Но еще важнее коммуникационные издержки. Всем новым разработчикам приходится задавать много вопросов о том, как работает разрабатываемый продукт, и эти вопросы отвлекают и сбивают тех, кто давно работает над проектом. В результате прогресс замедляется, и вы отстаете еще больше. Это и есть принцип мифического разработчико-месяца в действии.

Конечно, бывают моменты, когда расширение команды ускоряет прогресс, но середина работы над проектом к их числу не относится. Понятно, что многое изменилось с тех пор, как Брукс опубликовал «Мифический человеко-месяц», но эта концепция в значительной степени осталась верной.

На рисунке показано то, что я наблюдал лично. Я составил формулу[10] для расчета. Она не слишком научна, но, если спросить разработчиков о том, близка ли такая зависимость к истине, думается, они с ней согласятся.

Результаты снижаются, когда число разработчиков увеличивается до 10. Это подчеркивает необходимость сохранения небольших команд, а также объясняет, почему нельзя добавить людей в существующую команду и ожидать большего результата. Если увеличить число разработчиков с 10 до 20, то вы более чем вдвое снизите производительность и получите замедление работы, а не ускорение. А если команда разрастается примерно до 25 человек, то результат становится отрицательным. Я не знаю точно, чем объяснить этот эффект, но мой опыт говорит, что результат именно такой.

Понятно, если вас расстраивает то, что нет возможности привлечь больше работников к устранению проблемы. На бюджет тоже нужно смотреть с позиции руководителя, и он не резиновый. Но в краткосрочной перспективе не выливайте свое раздражение на команду. Это только деморализует уже и без того измотанных людей. Это все равно что злиться на гравитацию. Если ваш парашют не раскрылся, вы можете проклинать гравитацию сколько угодно, но это не поможет.

Однако в более отдаленной перспективе хорошие лидеры могут более эффективно «разделять и побеждать». Разделение проблемной области, кода и работников на более мелкие блоки позволяет создать резерв и добавить больше сотрудников. Вспомните процесс клеточного деления, описанный в главе 8. Не забывайте, что подобные реорганизации требуют времени. Рассчитывайте на