Трудовой Кодекс РФ с комментариями ТК РФ, бесплатные консультации юристов
Не все модные методы управления командой приносят хороший результат. Гибкая методология разрабоки Agile и система организации производства и снабжения Kanban могут давать сбои, а в попытке улучшить работу можно добиться противоположного. Основатель одной из крупнейших софтверных компаний мира Twilio миллиардер Джефф Лоусон рассказывает, почему разработчики срывают дедлайны и что с ними надо делать, чтобы такого не происходило
Основатель облачной платформы Twilio Джефф Лоусон стал миллиардером в том числе благодаря тому, что научился правильно руководить разработчиками. Будучи программистом, он точно знает, чем мотивировать гениев разработки, как устроен их мозг и какие вопросы им задавать, чтобы получать ответы, которые вам нужны.
В книге «Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО» он не только рассказывает историю своей компании, но и делится секретами эффективного взаимодействия между менеджерами и разработчиками. Всем, кому приходилось нанимать разработчиков в команду или иметь с ними дело (а в эпоху повсеместной цифровизации мало кому удалось этого избежать), пригодятся полезные лайфхаки по переводу с человеческого языка на язык программистов и инструменты для управления командой разработки на аутсорсе. Книга выходит в сентябре в издательстве «Альпина Паблишер». Forbes публикует отрывок.
Почему вы не знаете, когда продукт будет готов
«Первое, что вызывает досаду у руководителей и менеджеров, — это неспособность технических команд придерживаться жестких сроков. На мой взгляд, в разработке ПО есть четыре аспекта: функции, сроки, качество продукта и его определенность. Вообще говоря, вы можете выбрать любые три из них, но вам не удастся получить одновременно все четыре. Вы можете с уверенностью создать набор функций к определенному сроку, но качество продукта может сильно пострадать, поскольку разработчики будут упрощать многое, чтобы уложиться в срок. Вы можете создать продукт к определенному сроку и с предсказуемым качеством, но в реальности вам придется для этого урезать функции продукта. Вы можете с высокой уверенностью получить известный набор функций с хорошим качеством, но не будете знать, сколько времени это займет. Или можно замахнуться на все три аспекта — функции, качество и сроки, что звучит здорово, но, скорее всего, при низкой уверенности.
Если вы, как руководитель, потребуете выполнения всех четырех аспектов, то вам придется угадывать, какой из них — ложный. Или вы можете получить реалистичные отчеты от подчиненных, которые расскажут вам, основываясь на фактах, что произойдет, по их мнению. Если у вас жесткий срок — крупная конференция пользователей или маркетинговая кампания, которую необходимо осуществить любой ценой, — то они скажут, чем следует пожертвовать. Или назовут вероятность выдерживания сроков, что редко бывает точным или внушающим оптимизм. Поэтому, скорее всего, они будут настаивать на соблюдении функциональности, определенности и сроков. На первый взгляд, именно этого и ждут руководители. Жертвой, однако, чаще всего становится качество продукта. Поначалу это может быть неочевидно, но затем выйдет боком, если клиенты примут продукт. Выдерживание срока может помочь завоевать рынок, но клиенты столкнутся с ошибками, проблемами масштабирования, безопасности и т. д. На этом прогресс застопорится, поскольку команде придется исправлять базовые вещи. Это гораздо более неприятно, с учетом того, что у вас появляются недовольные клиенты или неудовлетворенный спрос.
Вот почему многие продукты, созданные по методологии аджайл, начинают свою жизнь с бедным функционалом. Чаще всего функционал продукта не так важен, как быстрое представление идеи клиентам. Таким образом, сроки берут верх над функционалом при соответствующем качестве, надо предполагать. Создание меньшего по объему продукта, но с уверенностью — это путь многих команд, разрабатывающих новый продукт. Если есть ключевой функционал, то к нему всегда можно добавить функции позднее.
Руководителю лучше заняться серьезным обсуждением того, какие параметры необходимо сохранить, а какими можно пожертвовать. В Twilio мы говорим, что качество и доверие — это самое главное. Мы считаем качество драгоценностью, которой никогда нельзя жертвовать. Да, мы совершаем ошибки, но стараемся донести до клиентов мысль о том, что качество для нас не тот аспект, которым можно жертвовать. Как и многие компании, мы проводим большую ежегодную конференцию пользователей (под названием SIGNAL), которая служит нам платформой для анонсирования продуктов, привлечения внимания прессы и информирования клиентов. Поэтому сроком обычно является тот момент, когда маркетинговая команда бронирует помещение для конференции и начинает продавать билеты. Это гарантирует функционал и уверенность.
Вообще говоря, неопределенность — скользкая вещь, поэтому функции продукта отдаются на усмотрение команд, с тем чтобы они уложились в срок. Мы измеряем определенность в месяцах до конференции SIGNAL, но, когда остается всего один месяц, она обретает вид однозначного «да» или «нет», и с этого момента функции продукта становятся единственной переменной, которую нужно реализовать в срок. Это хороший компромисс. Как руководители, мы часто зацикливаемся на функциях, однако клиенты редко покупают продукт на основе какой-то функции. Их больше интересует общий функционал, а функции всегда можно добавить позднее. Таким образом, руководители компании и менеджеры по продукту должны заранее определить, какие функции имеют первостепенное значение для принятия продукта клиентами и его конкурентоспособности на рынке, а какие просто было бы неплохо иметь».
Почему на решение проблемы нельзя бросить больше разработчиков
«Обычно руководители рады получить больше ресурсов, поэтому, когда техническим директорам предлагают увеличить численность сотрудников или бюджет для ускорения проекта, их отказ вызывает удивление. Кому не хотелось бы увеличить бюджет и штат? Причина в том, что переброска дополнительных работников на решение проблемы (особенно если проект выполняется, но отстает от графика) вряд ли поможет. На самом деле подобное решение может еще больше задержать работу над проектом. Почему же получается такой парадоксальный результат, особенно в краткосрочной перспективе? Да потому, что подбор исполнителя любой роли требует времени и отвлекает от текущей работы. Время нужно и на то, чтобы новый разработчик вошел в курс дела. Даже если вы наймете его сегодня, он не будет продуктивно работать, пока не ознакомится с кодовой базой и стилем работы команды. Этот процесс обычно занимает несколько месяцев и ничем не отличается от того, что происходит в других отделах. Возьмите отдел продаж — если вы нанимаете нового торгового представителя, ему требуется время, чтобы изучить набор продуктов и начать заключать сделки. Поэтому если вы не дотягиваете до целевых показателей по доходам в текущем квартале, то наем дополнительных торговых представителей прямо сейчас вам не поможет. То же самое и с разработчиками — для повышения производительности нужны предварительные затраты. Но если привлечь разработчиков из другой команды, то эти затраты значительно сократятся. Почему бы не поступить именно так? У ПО есть и другие, уникальные проблемы».
В 1975 году пионер софтверной индустрии Фредерик Брукс-младший опубликовал сборник эссе о разработке программного обеспечения «Мифический человеко-месяц». Одна из основных идей, давшая название книге, — это «мифический человеко-месяц» (я буду называть его «мифическим разработчико-месяцем»). Ее суть в том, что с увеличением численности разработчиков проекта, который отстает от графика, шансы на срыв сроков только возрастают. С чем связан такой нелогичный результат? Прежде всего со временем на введение новых разработчиков в курс дела. Но еще важнее коммуникационные издержки. Всем новым разработчикам приходится задавать много вопросов о том, как работает разрабатываемый продукт, и эти вопросы отвлекают и сбивают тех, кто давно работает над проектом. В результате прогресс замедляется, и вы отстаете еще больше. Это и есть принцип мифического разработчико-месяца в действии.
Конечно, бывают моменты, когда расширение команды ускоряет прогресс, но середина работы над проектом к их числу не относится. Понятно, что многое изменилось с тех пор, как Брукс опубликовал «Мифический человеко-месяц», но эта концепция в значительной степени осталась верной. Я составил формулу для расчета зависимости объема написанного кода от числа разработчиков: 100 — (N × 0,35)(2 + N × 0,005), где N — число разработчиков. Она не слишком научна, но, если спросить разработчиков о том, близка ли такая зависимость к истине, думается, они с ней согласятся.
Результаты снижаются, когда число разработчиков увеличивается до 10. Это подчеркивает необходимость сохранения небольших команд, а также объясняет, почему нельзя добавить людей в существующую команду и ожидать большего результата. Если увеличить число разработчиков с 10 до 20 то вы более чем вдвое снизите производительность и получите замедление работы, а не ускорение. А если команда разрастается примерно до 25 человек, то результат становится отрицательным. Я не знаю точно, чем объяснить этот эффект, но мой опыт говорит, что результат именно такой.
Понятно, если вас расстраивает то, что нет возможности привлечь больше работников к устранению проблемы. На бюджет тоже нужно смотреть с позиции руководителя, и он не резиновый. Но в краткосрочной перспективе не выливайте свое раздражение на команду. Это только деморализует уже и без того измотанных людей. Это все равно что злиться на гравитацию. Если ваш парашют не раскрылся, вы можете проклинать гравитацию сколько угодно, но это не поможет.
«Денег нет, делайте что хотите»: как геймстудии уходят из России и сокращают персонал
Однако в более отдаленной перспективе хорошие лидеры могут более эффективно «разделять и побеждать». Разделение проблемной области, кода и работников на более мелкие блоки позволяет создать резерв и добавить больше сотрудников. Не забывайте, что подобные реорганизации требуют времени. Рассчитывайте на то, что увеличение численности разработчиков и бюджета приведет к ускорению прогресса не ранее чем через полгода.
Недавно у меня был разговор с руководителем, рассматривавшим проект, для выполнения которого требовалось три года. Это был важный проект, и руководитель очень сожалел, что они не могли «бросить $100 млн на решение проблемы» и справиться с ней за год — лидеры разработчиков заявили, что прямо сейчас они не в состоянии ускорить проект даже с большим бюджетом. Затем руководитель сказал: «Держу пари, если предложить [название крупной консалтинговой фирмы] $100 млн, они сделают это». Я ответил: «Конечно, их торговый представитель скажет, что они сделают это, когда увидит $100 млн, но им тоже не удастся одолеть задачу». Вот почему крупные консалтинговые проекты никогда не укладываются в сроки и бюджет. Примечательно, что руководитель не стал спорить со мной, надо думать потому, что его опыт подтверждал мое мнение. Иногда принятие трудных решений требует времени. Но я все же предложил этому руководителю обсудить с техническими лидерами, что они могут предпринять сегодня и в ближайшие месяцы для увеличения бюджета через полгода и завершения проекта за полтора года вместо трех лет. Это разумный вопрос, и эффективный технический лидер должен знать, как ответить на него.
Даже в нынешней аджайл-среде работа по-прежнему делится между командами. Чтобы ускорить работу, менеджерам нужно либо добавлять персонал в команду (а это ведет к проблемам, описанным Бруксом), либо перераспределять работу так, чтобы команды могли выполнять ее параллельно. В любом случае это влечет за собой огромный перерасход ресурсов сначала на поиск сбалансированного распределения работы, а потом на встраивание ее частей в кодовую базу. Это классическое «замедление ради ускорения». И наконец, нужно укомплектовать команду и добиться продуктивности. Как бы то ни было, лучше всего просто позволить команде продолжить работу в краткосрочной перспективе, а в это время подумать над реорганизацией структуры команд, которая обеспечит ускорение. Существуют естественные точки остановки, где очень удобно провести переоценку и перераспределение задач, но это надо делать не в разгар работы над проектом, особенно если намечается отставание от графика».
Ловушки методологии аджайл
«Все это хорошо, но методология аджайл не панацея от всех проблем, как ее иногда описывают неофиты. Как и любая система организации, аджайл-подход имеет свои плюсы и минусы. В недавнем разговоре с генеральным директором публичной компании я спросил, как продвигается их аджайл-трансформация, и он ответил: «Сборище лентяев рассказывает нам, как вести бизнес, — и ничего не меняется!» Я чуть не упал со стула. Где же методология аджайл дала сбой?
Вместо высвобождения творческого потенциала разработчиков методология аджайл иногда может подавлять его. В попытке привнести дисциплину и предсказуемость в разработку программного обеспечения первые аджайл-практики обращались к миру материального производства с вопросом: «Как добиться предсказуемости сборочной линии в разработке программного обеспечения?» В результате родился метод организации рабочего процесса канбан, который был буквально заимствован из производственной системы Toyota.
В канбан владелец продукта разбивает недельную работу на небольшие задачи, которые записываются на стикерах и прикрепляются к канбан- доске. Инженеры снимают задания с доски, выполняют работу, перемещают стикеры в колонку «Сделано», и процесс повторяется. Когда неделя заканчивается, они отчитываются о количестве выполненных задач. Разбивка сложных задач на более мелкие необходима, но есть риск, что метод канбан превратит разработчиков в сборщиков на конвейере. Как вы могли понять из прочитанного, я не поклонник такого образа мышления. На сборочной линии автозавода не найти творчества. Автомобили, которые вы производите, не предназначены для решения индивидуальных проблем. Совсем наоборот. Вы хотите, чтобы все автомобили, сходящие со сборочной линии, были одинаковыми. И вам не нужно, чтобы рабочие сборочного конвейера привносили творческие элементы — «Давайте сделаем на этом автомобиле треугольный руль!».
Это подходит для сборки автомобилей, но не для работы творческих людей. Канбан- доски напоминают мне о статье, прочитанной несколько лет назад, — она была интересной, но немного пугающей. В ней рассказывалось о китайской деревне Дафэнь, на которую приходится 60% мирового производства картин маслом, многие из них — это копии работ великих мастеров. Это фабрика изобразительного искусства со «сборочными линиями», выпуска ющими выполненные вручную копии картин Винсента Ван Гога, Леонардо да Винчи, Энди Уорхола и многих других. Художники работают в бригадах. Каждый мастер идет по проходу между мольбертами и наносит несколько мазков на каждый холст. Следующий добавляет еще один элемент… В Дафэне работают более 8000 художников, и они выпускают от трех до пяти миллионов картин в год. Превращение Моне в деньги — это довольно хитроумный трюк. Но я был потрясен, когда прочитал о Дафэне: меня оскорбляло то, что компании нанимают творческих людей, а затем полностью изгоняют творчество из их работы.
Тем не менее это именно то, что некоторые компании делают с разработчиками. Они нанимают таланты, а затем засовывают их в офисы открытого типа, где они строчат стереотипные программы, вытаскивая билетики с канбан-доски. Мне часто жалуются, что трудно найти отличных разработчиков, а я в ответ говорю, что это и немудрено, если с ними обращаются как с рабочими сборочного конвейера.
Ежедневные летучки — еще один основополагающий элемент методологии аджайл. Каждый день команда начинает с совещания, на котором каждый рассказывает остальным, что он делал вчера и что собирается делать сегодня. Проблема в том, что многие разработчики просто ненавидят совещания — не из-за своей асоциальности, а потому, что совещания отнимают ценное время, которое было бы лучше потратить на написание кода. И, как любые совещания, ежедневные летучки могут быть как хорошо организованными и эффективными, так и безграничной и неконкретной тратой времени. Мы, как руководители, привыкли к рабочим дням, заполненным встречами, и часто ожидаем, что у всех в компании одинаковый график.
Не врать, не прокрастинировать и не сдаваться: Пол Грэм о правилах усердного труда
Это то, что Пол Грэм, соучредитель Y Combinator, называет «распорядком менеджера», очень эффективным для сотрудников, чья основная работа — это взаимодействие с другими людьми. Деление дня на одночасовые блоки — это метод, который позволяет координировать работу множества людей. Просто добавьте встречу в мой календарь. Но сделать что-то с нуля обычно невозможно за один час — это требует сосредоточенности и того, что Грэм называет «распорядком создателя».
Возможно, вы слышали о потоке — это состояние, когда человек сосредотачивается на проблеме и решает ее максимально креативно. Авторы, художники, музыканты и даже повара говорят о потоке. Это состояние ума, когда все складывается. А еще поток требует постоянной концентрации. Даже одна встреча может разрушить состояние потока. Грэм говорит: «Каждый тип распорядка прекрасно работает сам по себе. Проблемы возникают, когда они сталкиваются. Поскольку большинство влиятельных людей работают по распорядку менеджера, они в состоянии — если захотят — заставить каждого работать аналогичным образом. Но те из них, кто поумнее, сдерживают себя, если знают, что некоторым подчиненным нужны для работы более длинные интервалы времени». Поэтому неудивительно, что ежедневные летучки могут нарушать поток.
Какое соотношение состояния потока и встреч лучше всего подходит вашей организации? Почему бы вам… не спросить своего разработчика? Многие разработчики хотят свободы, чтобы понимать клиентов, глубоко вникать в бизнес и использовать весь свой потенциал. Но чрезмерно жесткое следование методологии аджайл может убедить разработчиков в том, что их работа вовсе не понимание клиентов или бизнеса, поэтому они ограничиваются той ролью, которую от них ожидает система. Важно не дать менеджерам по продукту и разработчикам попасть в эту ловушку.
Если разработчики ограничивают себя, это может в краткосрочной перспективе упростить их жизнь: «Просто говорите мне, что делать». Но довольно скоро они почувствуют неудовлетворенность и начнут искать работу в более подходящем месте. Методология аджайл сама по себе довольно хороша для разработчиков. Но руководители низшего уровня должны позаботиться о том, чтобы разработчики оставались вовлеченными в бизнес и относились к разработке как к совместной работе, а не как к выполнению задач.
Как алкоголь, уединение и чтение помогают найти гениальное решение и войти в поток
Одна из любимых поговорок моего отца — «Все в меру». Большинство вещей в нашей жизни нормальны, пока ты не увлекаешься ими слишком сильно. Алкоголь. Телевизор. Секс. Именно так я подхожу к методологии аджайл при разработке ПО. Вместо того чтобы развертывать полномасштабную реализацию аджайл с коучами, консультантами и кучей жестких правил и процедур, некоторые компании просто берут несколько принципов аджайл, которые имеют смысл, и отбрасывают остальное.
В Twilio мы не придерживаемся строго какой-либо определенной формы аджайл и позволяем командам выбирать свой стиль работы — какие-то из них принимают более формальные элементы аджайл, другие — менее формальные. Но мы строго реализуем ряд ключевых идей. Самое строгое правило состоит в том, что небольшие автономные команды — основа прогресса. Мы ограничиваем размер команд сотрудниками. Вместо системы планирования, навязывающей им работу, мы просим их намечать собственные ежеквартальные цели на основе пожеланий клиентов. Когда представления команд о том, что необходимо, отличаются от наиболее важных целей руководства, оно не спускает указания сверху, а начинает дискуссию для разрешения конфликта.
Оценка здорового подхода к работе у технической команды не менее важна, чем измерение результативности продавца на закрытых распродажах. Понимание ценности методологии аджайл, а также того, как команды внедряют ее, объясняет, почему вы слышите вроде бы нелогичные и нередко разочаровывающие ответы, когда пытаетесь добиться определенности от своих команд по разработке продуктов».
