Техлид

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

02.03.2021 12:21:43 |

Автор: admin

Познакомьтесь с Бобом

Боб чрезвычайно амбициозный и активный разработчик.

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

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

Другими словами, ему придётся делать меньше того, что он любит в обмен на то, чем он заниматься не умеет управлять другими.

Ему не хватает навыка руководить другими, воспринимать их график работы и знания, разбивать задачи, чтобы с ними справлялись другие люди и выстраивать стратегии, ведущие к успеху. Он ожидает, что все остальные в его команде будут такими же хорошими программистами, как он, поэтому он не уделяет времени их развитию, в основном потому, что не может прочувствовать их потребности.

Проходят месяцы, и становится очевидным, что он неудовлетворительно проявляет себя на новой должности. Он достиг нового уровня некомпетентности. Его благодушие и отсутствие навыков руководства, способствовавшие предыдущей работе, теперь привели к провалу. Из-за его некомпетентности продуктивность команды упала, а сама компания дала трещину.

Ситуация Боба многим из нас болезненно знакома. Не знаю, как вы, а я знаком со множеством сениор-разработчиков и техлидов, абсолютно ужасно справляющихся с тем, что требуется от них по должности с руководством.

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

Это явление называется принципом Питера:

В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности. [] Сливки поднимаются кверху, пока не прокиснут.

Хотя Лоуренс Питер сформулировал эту идею в своём бестселлере как сатиру, она оказалась безусловно истинной: человека будут повышать до тех пор, пока он не достигнет своего уровня некомпетентности. Для разработчика эта ступенька может быть мидлом, сениором, техлидом, директором и так вплоть до CTO.

Среди разработчиков распространено мнение о том, что если ты хорошо справляешься и постоянно совершенствуешь свои навыки кодинга, то тебя повысят до более престижной должности. Она накладывает на тебя гораздо большую ответственность и позволяет проявить свои достоинства и умения. Это правда с большой вероятностью тебя повысят, именно так всё и происходит.

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

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

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

Как ни парадоксально, ваши собственные амбиции становятся ключом к вашей посредственности.

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

И именно поэтому нами управляет так много некомпетентных людей. Именно поэтому умы, когда-то блестящими, совершают ужасные ошибки. Поэтому некоторые проекты движутся не в том направлении под руководством конкретных людей. И нет, в этом нужно винить не коллектив это вожак стаи не смог создать среду и организованную структуру для успеха команды.

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

Творческая некомпетентность: способ быть профессионалом

Синдром самозванца часто считается чем-то плохим. Разумеется, менталитет, при котором вы считаете менее компетентным, чем требования к вашей должности, может нанести вам урон. Он может привести к недооценке себя. Когда в глубине души вы верите, что ничего не умеете, это часто проявляется в реальности.

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

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

Вы готовите стратегию. Вы учитесь большему, чем от вас требует текущая работа. Совершенствуете свои soft skills. Делаете то, что требуется, чтобы стать чем-то большим, чем просто программист. Вы предпринимаете действия, чтобы стать достаточно динамичным для перехода в будущем на руководящие должности в сфере разработки, не связанные конкретно с программированием.

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

Нужно быть готовым сразу же приступить к работе. Если вы считаете, что благодаря успеху на предыдущей должности вы обретёте успех на будущей, то разочарование будет тяжким.

Если вы думаете, что знаете всё, то ничего не знаете. Если вы думаете, что не знаете ничего, то кое-что знаете. Джейс О'Нил

Поэтому будьте творчески некомпетентным. Верьте в то, что не знаете ничего. Воспринимайте себя как некомпетентного.

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

На правах рекламы

Закажите сервер и сразу начинайте работать! Создание VDS любой конфигурации в течение минуты, в том числе серверов для хранения большого объёма данных до 4000 ГБ. Эпичненько :)

Подробнее..

Категории: Программирование , Управление проектами , Управление персоналом , Разработка по , Карьера в it-индустрии , Блог компании vdsina.ru — хостинг серверов , Техлид , Кодинг

Перевод Так выглядит эффективная работа техлида

12.11.2020 18:15:59 |

Автор: admin

фото с сайта pilot.com
В 2012 году Джессика МакКеллар с командой друзей из MIT (Мичиганский Технический Университет) запустила стартап скрытого чата Zulip. Менее двух лет спустя его выкупил Dropbox. И в этом не было ничего необычного. С ее командой такое уже случалось, когда они так же быстро продали Ksplice компании Oracle. Такая бешеная гонка дала МакКеллар больше опыта в разнообразных возможностях менеджера, чем обычный инженер получает за всю карьеру. Она была тимлидом, основателем, техлидом в огромной корпорации, а сейчас руководит десятками сотрудников в быстрорастущем международном стартапе. (Да, она еще и значимая фигура в мире Python). В статье Джессика рассказывает о своем опыте и подходе к управлению командами.

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

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

Что значит напрямую поддерживать команду?

Когда ты технический руководитель, ты в основном работаешь с людьми. И здесь всегда надо помнить о двух вещах: день и год. Представьте, что каждый сотрудник идет по обоим путям одновременно. И вы как лидер можете формировать их опыт на обоих уровнях, чтобы помочь им найти траекторию, которая отвечает их целям и соответствует вашим потребностям.

На повседневном фронте вы хотите, чтобы люди были счастливы, продуктивны и вовлечены в работу. Сюда входят регулярные встречи один на один, когда вы находите время и место, чтобы поговорить обо всех имеющихся небольших проблемах и препятствиях на пути. Тут может потребоваться расписать проект на доске, разбив его на мелкие составляющие. Или разрулить запутанную межличностную ситуацию. Или отложить все свои дела и пройтись с тем, у кого трудный день.

Необходимо искать равновесие между структурированной еженедельной рутиной и временем на двустороннюю обратную связь в режиме здесь и сейчас. Одно это уже сделает вас весьма эффективным менеджером в проекции дня.

Большую сложность представляет вопрос, как помогать людям строить долгосрочный план по достижению удовлетворенности и продуктивности в вашей компании. Сюда относится много факторов. Если немного упростить, то 50% помочь людям понять, что они хотят делать, и 50% включить это в ежедневную рутину, планирование и проекты.

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

Хорошие лидеры экспертно вычленяют эту информацию и делают такой вариант осуществимым.

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

навыки, которые они хотят улучшить;
технический и нетехнический опыт, который хотят получить;
насколько они хотят расширить пределы своего влияния в компании.

Как только они смогут эти три пункта сформулировать, вам с намного большей долей вероятности удастся найти для них подходящие возможности. А они с намного большей долей вероятности эти возможности реализуют.

Раз в квартал я говорю: Отлично. Следующая неделя посвящается карьерному росту. И на личных встречах мы говорим именно об этом.

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

Все это может сработать только в случае, если каждый искренен с другими. На плечах менеджера лежит обязанность задать этот тон. Дайте людям понять, что они спокойно могут сказать, что в перспективе они хотят работать где-то еще или заниматься чем-то другим. Я стараюсь это представлять в таком свете: Все ли мы с компанией Dropbox делаем правильно, чтобы вы получили желаемый опыт для занятия тем, чем вы хотите, в будущем?

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

Дать людям представлять свое будущее в компании и то, как вы можете им помочь этого добиться помогают не только открытые разговоры, но и четкое понимание, какие есть перспективы карьерного роста. Такая структура особенно полезна в работе с инженерами, которые привыкли к жестко зафиксированным карьерным путям.

Dropbox уже прошел через это, и у нас сформированы два четко обозначенных и полностью параллельных пути: один для технических специалистов и второй для тех, кто заинтересован в карьере в управлении.

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

Для эффективности карьерных карт нужно, чтобы люди знали, какую опцию они хотят выбрать.
Когда вы проводите людей по пути принятия этого решения, оптимально спросить, какие изменения они хотят привнести в компанию. Четко отделите вопрос от традиционных представлений об успехе или от того, что, на их взгляд, им следует делать. Вместо этого выясните, какие проблемы они действительно хотят решить.

Одним из путей увеличения веса инженеров будет освоение все более и более сложных технических проблем, проблемы с высоким техническим риском, которые требуют новаторского решения. Такой человек, скорее всего, будет счастлив на месте технического специалиста высокого уровня. Чтобы направить их по этому пути, просто нужно столкнуть их в глубокую часть бассейна (с правильным наставничеством и защитными ограждениями) и дать им решать более сложные проблемы уже сегодня. Мы всегда можем скорректировать курс по мере движения, но для начала им просто нужно нырнуть и начать получать нужный опыт и расти в нем.

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

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

Будучи лидером, я прикладываю максимум усилий, чтобы уловить каждое из незначительных действий, которые совершают члены моей команды, выявить систему или общую тенденцию и сформулировать сферу проблем, которая больше интересует каждого. Такие наблюдения становятся основой для разговора с инженерами команды, в ходе которых мы вместе набрасываем будущее.

Производительность вашей команды = ваши возможности как руководителя

Почти каждый технический руководитель помнит поворотный момент, когда написание кода уже не было номером один в списке приоритетов. Я была инженером и техлидом прежде, чем перешла в менеджмент. И я помню самые первые случаи, когда мне приходилось делать выбор между тем, чтобы написать код самой, и тем, чтобы доверить задачу кому-то еще. Самостоятельное создание и написание кода, который порадует пользователей, приносит определенное удовольствие.

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

Когда вы отступаете от написания кода, взамен вы получаете время на то, чтобы собрать более широкую организационную среду и реализовать более стратегические организационные инвестиции.

В Dropbox у меня есть возможность отстраниться и поразмыслить с более отдаленной перспективы, как работает программирование: как мы планируем, как мы устроены с точки зрения компании, приводят ли нас к успеху наши инструменты. И если я обнаруживаю какую-то неэффективность, у меня есть время, пространство и максимально широкий контекст, чтобы исправить ситуацию.

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

Кого-то очень мотивирует абстрактно теоретизированная работа по созданию прототипа, которую они могут быстро повторить, даже если впоследствии придется половину выбросить. Кто-то очень любит создавать стабильный продукт, который они точно это знают будут использовать 300 миллионов человек. Существует целый ряд мотиваций. Вам просто нужно понять, в чем заключаются естественные склонности человека и использовать это, назначая его на проект, в котором его работа будет оптимальной.

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

Во время одной из наших встреч я просто сказала: Слушай, тебе явно нравится думать о таких вещах. Что если ты сможешь уделять мыслям о них гораздо больше времени? Я рассказала ему, что придется совершить вираж, и призналась, что, на мой взгляд, ему понравится переход от написания кода к другим задачам. Сейчас этот инженер руководит собственной командой технических специалистов. Было видно, что он уже мыслил, как менеджер. Вопрос был лишь в том, чтобы предоставить ему площадку для перехода в новую роль.

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

Вам нужно развивать локальных экспертов в рамках команд, проектов и платформ. Экспертов, которые могут глубоко мыслить и вести структурные обсуждения.

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

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

Самая прогрессивная из этих привычек особенно в том, что касается неудач, проведение поучительного, требующего принятия мер, анализа этих неудач. Предоставлять время и место, чтобы команда могла поразмышлять над тем, почему проект завершился таким образом, моя задача как лидера. И я вовсе не говорю, что надо рассказать команде, что пошло не так. К примеру, мы очень сильно нарушили сроки проекта. Нам нужно найти время и подумать, что в следующий раз следует делать по-другому и какие организационные или процессуальные изменения могли бы привести к иному результату. Я там нахожусь только для поддержания дискуссии и обобщения ее, чтобы информацию можно было передать другим командам.

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

Новые люди всегда приносят свежие идеи и задают конструктивные вопросы по поводу правильного способа ведения дел. Новые инженеры не принимают на веру, что определенные вещи никогда не работали. А это очень оздоравливает компанию. Опытные инженеры, в свою очередь, привносят полезные привычки и дисциплину в непростые проекты. У вас постоянно будет определенное количество крутых проектов. Распределяйте их равномерно между обеими категориями сотрудников.

Вам нужно непрерывно прокачивать всех членов команды. Мастерство подтянется.

Помимо руководства командами инженеров в Dropbox Джессика МакКеллар еще является директором Python Software Foundation. Она ведет твиттер @jessicamckellar. Фото: Бонни Рай Миллз

Помогайте людям работать быстрее с помощью правильных инструментов

Одна из причин, по которой я рада работать в Dropbox, размер продукта и вызовы, которые его сопровождают. Мы покрываем вопросы продукта и инфраструктуры, которыми обычно занимаются более крупные компании. Это означает, что у каждого инженера Dropbox огромная ответственность и влияние. У нас нет времени, которое бы можно было потерять. В то же самое время это значит, что автоматизация, инструменты и масштабируемые практики намного более важны. Для меня это многоуровневое утверждение: я одновременно руковожу и тимлидами, и своей командой инженеров. Планирование имеет решающее значение в обоих случаях.

В случае команды инженеров я вовлечена на уровне планирования спринтов. Есть процесс, созданный для вовлечения каждого не только в текущую работу, но и в то, как она влияет на будущее. Я откровенно разговариваю с сотрудниками о том, как они хотят расти в профессии. Мы это записываем и включаем непосредственно в процесс планирования.

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

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

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

Среда

Обеспечивать продуктивную проектную среду с позиции менеджера включает в себя все, начиная с добычи правильных инструментов и заканчивая балансировкой между работой над новыми функциями и инвестированием времени в улучшение текущих проектов. Сюда также входит сглаживание процесса онбординга для новых инженеров, что помогает им сориентироваться, определить, что для них означает успех, понять, как оценивается производительность.

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

Летучки

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

Вам нужно, чтобы ваша команда получала обратную связь несколькими способами. Для получения технических отзывов с высоким уровнем детализации особенно важно проводить ревью кода. Обсуждение планирования и анализ архитектуры, как правило, дают более верхнеуровневую обратную связь.

Вам нужна система, которая позволит одновременно замечать пропущенную запятую и поможет людям серьезнее задуматься о том, что такое хорошая архитектура.

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

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

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

Классический пример очень длинная цепочка писем по одному поводу, в которой нет решения проблемы. Соберите всех, кто включен в эту переписку, в одной комнате на 10 минут и решение будет найдено.

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

Мотивация

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

Люди всегда с энтузиазмом относятся к новому большому делу. Сложнее оказывается доделать последние 5% проекта, на который ты уже потратил вечность. И в такой ситуации нам надо, чтобы над задачей трудился тот, кто горячо заинтересован в работе и хорошо понимает, откуда взялся Dropbox. Наш бренд всегда запускает что-то классное, а для этого приходится основательно вкалывать над последними 5%.

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

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

Заботливый технический менеджер не оставляет незамеченной ни одну тяжелую работу, даже если она не очень броская.

В Dropbox большая часть естественной мотивации произрастает из того, что компания делает упор на поистине высококачественном и беспроблемном пользовательском опыте. По большому счету, основное конкурентное преимущество можно сформулировать так: у нас очень понятный, легкий продукт, который просто работает. Именно эта ценность делает мотивацию на последних 5% проще, потому что именно отсюда берется удовлетворение пользователя. Именно поэтому люди любят продукт.

В завершение этих размышлений о технических лидеров, стоит сказать, что им стоит внимательно следить за корпоративными ценностями и установками, которые обладают именно такой функциональной силой.

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

Подробнее..

Категории: Управление проектами , Управление персоналом , Карьера в it-индустрии , Блог компании southbridge , Управление разработкой , Тимлид , Техдир , Dropbox , Тимлиды и разработчики , Техдиректор , Техлид

Как продать технические задачи бизнесу

23.04.2021 12:19:27 |

Автор: admin

Поддерживать высокое техническое качество кода прямая обязанность техлида. Но чтобы этого добиться, зачастую приходится доказывать начальству и заказчикам необходимость вкладывать в улучшение кода силы и время. Как сделать это, не стаптывая в бесконечных согласованиях железные башмаки и не стирая язык до мозолей? Об этом в своем докладе на конференции TechLead Conf 2020 Online рассказал консультант Better Life Company Алексей Дерюшкин.

Приведенные в статье примеры и истории помогут читателям выстроить баланс между продуктовыми и техническими задачами в диалоге с заказчиком и руководителями. А проверенные на практике советы правильно подготовиться к этому разговору.

При подготовке к докладу Алексей надел шапочку техлида и решил ответить на два вопроса. Чего ему самому не хватало в то время, когда он был техлидом? И что может сделать техлид для того, чтобы команда стала более успешной и начала добиваться лучших результатов?

Проблемы Алексея выглядели так:

Бизнесу совершенно неинтересно, что находится под капотом и как сделать код лучше;
Бизнес не разбирается в системе и не хочет это делать;
Сам техлид не умеет вести переговоры;

Представьте ситуацию: техлид приходит к бизнесу с классной идеей (глупо же ходить с плохими идеями!) он придумал ее и знает, что она поможет. Иногда уже знает, что не реализовать ее не получится. Начинает разговор, но беседа не складывается.

Почему?! Потому что техлид говорил о каких-то технических вещах, а коллегам из бизнес-подразделений не интересно, как это работает. У них другие цели и задачи: как повысить конверсию, как привлечь больше людей, как сделать классный продукт. И технические детали им не интересны.

Из-за этого непонимания техлид не может продать идею. К тому же не все умеют уговаривать людей и просто продавать что бы то ни было. Недопонимание накапливается, и в итоге : Блин, да что с ними спорить? Я ему рассказываю, как надо сделать, а он ничего не понимает. Не буду этим заниматься в следующий раз!

У вас были ситуации, когда не получилось договориться с бизнесом? Если ответ да, контент ниже будет вам полезен.

Чем продажа идеи отличается от программирования?

Спойлер: ничем!

Есть три ключевые вещи, которые обязательно нужно сделать для того, чтобы успешно продать какую-то идею:

Подготовиться заранее. Если вы не обучались продавать свои идеи, то выйти и свободно вести разговор в нужном русле может быть сложно.
Взять готовый алгоритм. Люди уже очень давно (гораздо дольше, чем программируют), продают друг другу и материальные вещи, и идеи, и концепции. Зачем выдумывать велосипед, когда можно взять то, что уже работает?
Использовать эмоции. С ними тоже нужно уметь работать. Но чтобы сделать это правильно, лучше пойти на какой-нибудь тренинг по эмоциональному интеллекту.

Пример неудачной продажи

Техлид приходит к владельцу продукта:

Привет! Я хочу добавить в этот спринт задачу по рефакторингу.
Привет! Нет, в этот спринт мы должны выпустить новую фичу, мы уже обещали.
У нас уже большой техдолг, мы все время торопимся и выпускаем фичи на костылях...
Ну, делайте сразу нормально, кто ж мешает?

Это результат неподготовленного диалога.

Давайте разберем ошибки типичного диалога техлида с бизнесом:

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

Итог закономерен: бизнес чувствует себя дураком, искренне не понимая, зачем нужно делать техдолг, когда можно сделать фичу.

Система продаж Джордана Белфорта

Есть замечательная цитата:

В фильме Волк с Уолл-стрит с Леонардо ДиКаприо прототипом главного персонажа является Джордан Белфорт один из самых известных продавцов и автор системы продаж.

На чем основывается его система? Джордан утверждает, что у вас купят идею (а на самом деле купят что угодно: телефон, автомобиль и т.д.), если есть 100% уверенность:

В идее (продукте, предложении);
В вас, как эксперте;
В людях, которых вы представляете.

Рассмотрим бытовой пример: вам продают автомобиль.

Идея 71%

Вы не совсем уверены, что автомобиль нужен вам как продукт. Но все же вам нужно ездить из пункта А в пункт В (на дачу, возить ребенка в школу).

Эксперт 83%

Вы почти уверены в продавце. То есть человек, который показывает вам автомобиль в салоне, вызывает у вас доверие.

Команда 78%

Вы также достаточно уверены в том, кого представляет продавец. Это может быть известная компания по продаже автомобилей или определенная марка. Например, вы уверены в том, что ес ли купите Mercedes, он не развалится в первый день, и не уверены в том же самом с АвтоВАЗом.

Если во всех трех пунктах ваша уверенность 100% или близко, то скорее всего, автомобиль вы купите.

В нашем случае, когда техлид идет с кем-то разговаривать, он представляет не компанию, а свою команду. Может быть, в голове своего собеседника он представляет программистов в целом, и с этим сложно будет бороться.

Вернемся к примеру с автомобилем, и рассмотрим вариант, когда вы не купили машину:

Идея 0%
Эксперт 100%
Команда 100%

Автомобиль вам не нужен, в принципе. В автосалон вы зашли, чтобы согреться или спрятаться от дождя.

Если вы уверены, что автомобиль вам нужен, но при этом вы не доверяете продавцу вам кажется, что он хочет вас надуть или впарить 100500 опций, то конкретно у этого человека вы не купите:

Идея 100%
Эксперт 0%
Команда 100%

В случае, когда вы не хотите связываться с АвтоВАЗом, и LADA Granta не ваша мечта, будет так:

Идея 100%
Эксперт 100%
Команда 0%

То есть если даже один параметр будет не 100%, а 30-40% и ниже, вы не убедите человека купить автомобиль. А на месте техлида не продадите идею сделать тесты, что-то автоматизировать или провести рефакторинг.

Важный момент по поводу 100 баллов из 100. Вы можете только предполагать, каковы цифры на самом деле. Странно было бы на переговорах говорить человеку: А ну, скажи мне: от 0 до 100, насколько ты во мне уверен?. Это просто метафора, а не цифры, которые можно использовать в разговоре.

Как добиться уверенности на 100\100\100?

Идти по алгоритму.

Джордан Белфорт в книге Метод волка с Уолл-стрит описал этот алгоритм детально. И его применения будет достаточно для того, чтобы ваши переговоры завтра или в следующий понедельник подросли в плане качества.

Алгоритм называется Прямолинейная система продаж. И он действительно о том, что мы честно рассказываем и показываем, что предлагаем. Договариваемся напрямую без подковерных игр и таких неприятных вещей, как обман.

Алгоритм продажи чего угодно, в том числе идей

Первые четыре секунды

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

Будьте доброжелательны и энергичны, но не слишком: не как персонаж из Маппет-шоу. Чуть-чуть энергичней, чем собеседник уже очень хороший уровень.

Кратко изложите, зачем пришли (позвонили, назначили встречу). Человек, скорее всего, чем-то занят, это элементарная вежливость.

Спросите, есть ли время на обсуждение? Это важно, особенно, если разговор спонтанный. Например, вы увидели в коридоре человека, с которым давно хотели поговорить. Он должен дать прямое согласие на то, чтобы пообщаться с вами.

Раппорт

Кроме того, важно в течение всего разговора поддерживать доверительные отношения с тем, с кем говорите: не вступать в конфронтацию, не валять дурака и т.д.

Отсутствие раппорта очень хорошо описывает картинка:

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

Сбор информации

Сбор информации важно делать заранее. Скорее всего, по ходу беседы вы не сможете этим заняться. Вам нужно заблаговременно подумать о человеке. Может быть, спросить у него напрямую или поинтересоваться у коллег, что его волнует, какие у него боли сейчас в его работе, каких он ждет выгод. То есть узнать, чего он хочет добиться, какие цели и задачи ставит (или ему ставят цели и задачи). Продажа идеи должна идти от потребностей или проблем покупателя.

Давайте посмотрим на три пункта:

Боли ярко окрашенные негативные эмоции;
Выгоды позитив;
Цели и задачи более нейтральные вещи.

Лучше идти сначала от боли, если она есть. А если нет, то от выгоды. Если нет ни того, ни другого, то просто апеллировать к задачам, которые человек перед собой ставит. Вам надо заранее разобраться, что у него болит, чего он хочет.

Основная презентация и предложение о покупке

Когда мы рассказываем о своей идее, обязательно нужно говорить на языке того человека, с кем мы общаемся. То есть на языке бизнес-целей!

Строим презентацию по схеме:

Как ваша идея поможет собеседнику?

Не почему это классная идея, не почему вы думаете, что она хороша, а почему она поможет собеседнику. Здесь вам поможет предыдущий этап сбора информации.

Визуализируем ужасное будущее;
Визуализируем хорошее будущее;
Если это нужно, даем МИНИМУМ технических деталей;

Когда вы продаете какую-то идею, надо уметь визуализировать плохое будущее, если человек с вами не согласился, и хорошее, если согласится. То есть вы продаете не через технические детали, которые можно (и нужно) обговорить, если без них никак. Важно построить картинку будущего. Как бы мы от этого не открещивались, все мы эмоциональные существа с логикой, а не логические существа с эмоциями. Люди покупают, в том числе идеи, через эмоции. Очень хороший способ вызвать эмоции нарисовать картинку в воображении (ужасную или приятную).

Называем цену.

Цена в кавычках, поскольку это может быть буквальная цена, или неделя работы. В любом случае (купить сервер и заплатить за это деньги или купить идею автоматизировать что-то и заплатить временем работы команды) алгоритмы продаж работают и во время договоренностей. Потому что любая договоренность, когда вы принесли какую-то идею, подразумевает действие и с обратной стороны. Человек в метафорическом смысле платит вам чем-то: своим вниманием, временем, тем, что ему придется выучить что-то новое. Не всегда речь идет о деньгах, но все-таки собеседник что-то дает вам взамен на вашу идею. Вы должны понимать цену этого.

Очень хорошая фраза, которая отдает мячик вашему собеседнику после презентации:

Мне кажется, это хорошая идея. Что скажешь?

Таким образом вы даете собеседнику возможность высказаться. И, слушая его, можете понять, насколько он уверен в идее, в вас и т.д.

Перенаправление на рост уверенности.

Если человек не убежден, мы перенаправляем разговор на уверенность. Например, вы сделали предложение: Давай что-то автоматизировать, а собеседник отказывается: Не хочу, нет времени (ресурса). Его возражение это ширма. На самом деле он не уверен либо в вас как в эксперте, либо в самой идее, которую вы принесли, либо в программистах вашей команды, в целом. Поэтому идет перенаправление на рост уверенности. Вам стоит еще раз пройтись по этим пунктам, разобраться, почему он не уверен. А после починить эту уверенность, а не ширму, которой он прикрывается, говоря о том, что нет времени, ресурсов и т.д.

Спросите, что смущает, и развейте страх

Если у вас не купили, значит, нет уверенности. Надо выяснить, где провал, почему 50% вместо 100%. И постараться это починить. Возможно, собеседник скажет напрямую:

Я не уверен, что это поможет.

Об идее, скорее всего, можно говорить прямо. Но вряд ли человек скажет:

Я тебе не доверяю, как специалисту.

Или:

Мне кажется, твоя команда не справится.

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

Снижение порога действия

Бывает, что человек во всех трех шкалах уверен на 100%, но при этом ничего не делает. Почему так происходит? Есть такое понятие порог действия нужно, чтобы сама покупка была легкой. И под конец взаимодействия мы должны сфокусироваться на нем, чтобы человеку было легко войти в сделку, принять идею и начать что-то делать.

Итак, на предыдущем этапе во всех трех пунктах набралось по 100 баллов, мы молодцы, идея классная, она нравится нашему собеседнику. Однако ему нужно совершить очень много действий, чтобы реализовать озвученную идею. Например, вы предложили ему что-то автоматизировать, но для этого он, дорогой ваш владелец бизнеса, должен подать заявку, чтобы она прошла через бюрократическую систему. Ему проще сказать: Да ну его на фиг! и убежать, чем соглашаться на такую длинную историю.

Поэтому вы должны постараться обеспечить легкий вход, например:

Просто кивни, мы все сделаем сами.
Тебе ничего не надо будет делать.
Мы уже попробовали, и вот результат...

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

Усиление боли

Это визуализация страшного будущего, в котором ваш собеседник не согласился на вашу идею:

Если ничего не поменяется, то...
Знаешь ли ты, что будем, если мы этого не сделаем?
Через год станет

Если мы сейчас не автоматизируем тестирование, то как мы будем тестировать через год, когда напишем еще больше кода? А что будет через год, если мы не купим новый сервер? Прямо спросите у человека про негативные сценарии будущего, пусть сам вам расскажет.

Закрытие сделки

Это опять передача мяча собеседнику:

Что дальше?
Ну что, попробуем?
Ты согласен, что...?

Это прямые вопросы, которые вы задаете собеседнику: Ну, как? Берем работу в следующий спринт? Ставим в план на следующий месяц?. Но эти вопросы часто просто забывают задать. Мы вроде бы обсудили идею и просто ждем, когда человек сам скажет: Ладно, давай. Я буду делать то-то и то-то.

Нет, пожалуйста, возьмите инициативу на себя и задайте вопрос: Ну как, работаем дальше?.

Пример

В 2015 году в одной из команд Алексей работал как техлид и на этапе подготовки он узнал о том, что сроки выхода в продакшн жестко зафиксированы, а в SLA на починку ошибки в продакшн выделено всего три дня.

То есть у владельца продукта есть две проблемы: жестко зафиксированы сроки и выхода в прод, и на починку багов. Если что-то из этого нарушается, владельцу продукта будет очень плохо. Поэтому продажа идеи была реализована через боль.

Диалог был примерно такой:

Привет! Я хочу обсудить одну техническую задачу, которая может ускорить время разработки задач и починки ошибок. Есть 10 минут, чтобы обсудить сейчас?
Давай.

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

Дальше идет презентация:

Смотри, сейчас у нас нет автотестов, и каждую фичу перед выпуском мы тестируем руками, ЭТО ДОЛГО. Я с ребятами УЖЕ ПОСЧИТАЛ, что если мы закроем 15% функционала тестами, то разработка каждой новой фичи УСКОРИТСЯ НА 2 ДНЯ. Благодаря этому мы сможем сделать на 10 фич больше до дедлайна. Мы все сделаем сами, надо просто взять в этот и следующий спринты задачи по разработке тестов. За этот месяц мы сделаем меньше фич, НО зато потом каждую будем делать быстрее. А еще это поможет быстрее чинить баги.

Что мы здесь видим? Во-первых, в презентации были указаны конкретные цифры. 15% функционала, 2 дня и 10 фич.

Во-вторых, был минимум технических деталей, а конкретно одна: 15% функционала надо закрыть. Цифра на самом деле не важна это может быть и 10%. Владельцу продукта важнее, что разработка новой фичи ускорится, или что баги будут чиниться быстрее.

В третьих, разговор был не про фреймворк тестирования и не про то, как будут проводиться тесты. Говорили про боль владельца продукта, а продавалась выгода от автотестов и новых фич.

Дальше называем цену: Месяц будем делать меньше фич, но потом снова возвращаемся к выгоде (к хорошему будущему) с отсылкой на две боли клиента.

В оригинале презентация была долгой, встреча на час. И одна из фраз, которая там прозвучала:

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

Что скажешь?

Это пример, как можно по такому алгоритму проводить продажи идей.

Полезные фишки

Есть полезные фишки, которые помогут в любом диалоге:

НО наоборот;

В предыдущем примере как раз используется эта фишка: мы сделаем меньше фич, НО зато потом каждую будем делать быстрее. Обычно мы говорим: Я сделал что-то хорошее, НО будет вот это и вот это плохо. То есть сначала обговариваем позитивные моменты, а потом идут НО и неприятные вещи. Поменяйте их местами: если есть что-то неприятное, сначала расскажите о нем, а потом о хорошем: Сейчас сделаем на 20% меньше фич, НО потом мы будем эти фичи печь как пирожки.

Потому что;

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

Визуализация;

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

Двойная петля;

Если вы видите, что собеседник сомневается (сначала у него есть один аргумент против, потом появляется другой, третий), скажите ему прямо: Мне кажется, что ты не уверен в идее, которую я принес. Расскажи, почему?. Так он попадает в двойную петлю: либо говорит: Нет-нет, я уверен, и начинает сам себе продавать уверенность, либо говорит: Да, я не уверен, и тогда дает вам аргументы, с которыми вы сможете работать.

Прямолинейность.

То, что вы честно и открыто ведете диалог, всегда подкупает.

Подводя итог

Итак, чтобы договориться, нужно выполнить несколько важных условий.

Во-первых, готовиться к разговору заранее. Для технических специалистов, непривычных к ежедневным продажам своих идей, такая подготовка критично важна. Во-вторых, говорить нужно на языке бизнес-целей, а не сыпать техническими терминами.

Кроме того, вы должны добиваться 100% уверенности по трем пунктам: в продукте, который продаете, в вас, как эксперте, и в людях, кого представляете.

Думайте о том, как помочь клиенту, а не как продать идею. И, наконец, следуйте приведенному в статье алгоритму. Его будет достаточно для того, чтобы ваши переговоры завтра или в следующий понедельник подросли в плане качества.

TechLead Conf 2021 пройдет 30 июня 2021и 1 июля 2021 в московской Radisson Slavyanskaya. Расписание можно посмотреть здесь.

Билеты на конференцию вы можете приобрести уже сейчас. Спешите: 1 мая цена станет выше!

Подробнее..

Категории: Управление проектами , Конференции , Конференция , Управление разработкой , Бизнес-процессы , Коммуникация , Код , Бизнес-модели , Блог компании конференции олега бунина (онтико) , Улучшение кода , Techleadconf , Техлид

Книги, которые повлияли на меня как на разработчика и управленца

18.06.2021 12:04:53 |

Автор: admin

Общаться в профессиональной среде, ходить на конференции и митапы, просто посидеть вечерком в приятном баре с профессионалом высокого уровня и обсудить какие-то классные идеи: всё это может помочь в работе. Среди этих ресурсов одно из первых мест занимают книги.

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

За мою практику я прочитал немало книг, но некоторые оказали большее влияние на становление разработчиком, а затем управленцем. Я разбил книги по нескольким разделам.

Практика

Книги из практического блока можно просто читать, независимо от того, разработчик вы сейчас или руководитель. Они все классные. Я рекомендую их всем, и они довольно простые прочитали, и можно сразу использовать.

Specification by Example

Книга понравилась мне настолько, что побудила написать первую статью на Хабре. Гойко Аджич автор книги сам описывает ее как книгу о разработке ПО без единой строчки кода. Ее фокус находится на пересечении управления требованиями, проектного менеджмента, DevOps и тестирования (в том числе автоматизированного). Если DevOps часто описывают как infrastructure as code, то Specification by Example это своего рода requirements as code. Проработав некоторое время в корпоративном сегменте индустрии любой разработчик рано или поздно узнает о том, насколько неполными, неточными, противоречивыми и устаревшими бывают требования и насколько сложно, долго и дорого бывает переделывать программы, написанные по таким требованиям. Существуют тяжелые методы борьбы с этим недугом. Например ГОСТ 34 до сих пор используется в госсекторе, несмотря на то, что он безнадежно устарел.

Specification by Example гораздо более гибкая и менее формальная техника, позволяющая, впрочем, заказчику и исполнителю говорить на одном языке, понятном обоим. Кроме того, ГОСТы описывают форму проектной документации, но не дают конкретных советов по проектному управлению и никак не поощряют коммуникацию и совместную работу по улучшению требований и нахождению лучших (более быстрых, качественных и дешевых) способов решения проблем. Примеры переформулированных требований из книги гарантированно не оставят вас равнодушными. Техникой контрольных примеров мы пользуемся уже восемь лет, и она позволяет экономить какое-то невероятное количество времени и избегать недопониманий.

На основе техники, описанной в книге, даже разработан продукт SpecFlow. Нам он показался излишне громоздким. Но вам, возможно, подойдет. О связи требований и автоматизированного теста на примере SpecFlow можно почитать в этой статье.

Event Storming

Это даже не книга, а своего рода комикс. Если вы любите стикеры, доски и kanban, то event storming скорее всего тоже зайдет. Со временем мы пришли к тому, что большинство web-проектов сразу создаем на основе CQRS-архитектуры, даже если на старте хранилище данных всего одно. Это позволяет по мере развития проектов независимо оптимизировать стеки чтения и записи. И в момент, когда запросы к БД становятся уже совершенно безобразными, воткнуть очередь с денормализоваными хранилищами.

Подробно о всех преимуществах CQRS перед классической n-layer- и onion-архитектурой я рассказывал в докладе Быстрорастворимое проектирование.

Причем здесь Event Storming? Это техника специфицирования в терминах DDD, CQRS и Event Sourcing в форме увлекательной игры со стикерами, фломастерами и доской (доска может быть физической или виртуальной, но с физической гораздо веселее). С точки зрения наглядности, метод не успевает за Activity и BPMN-диаграммами. Но он гораздо более легковесный и прост в освоении и понимании.

Impact Mapping

И снова книга Гойко Аджича. Часть идей в ней пересекается со Specification by Example, но у книг разные целевые аудитории. Spec by Example лучше подойдет для разработчиков, архитекторов, тестировщиков, аналитиков и менеджеров среднего звена. Impact Mapping инструмент, в первую очередь, для бизнеса: владельцев продукта (или даже компании), маркетинга и топ-менеджмента. Spec by Example лишь поощряет общение с целью поиска оптимальных решений. Impact Mapping это формальный процесс для стратегического планирования. Его можно использовать не только в разработке ПО, но и для стратегического планирования, в целом. Например, в этом году мы использовали Impact Mapping для приоритизации и планирования задач в HR.

Теория + практика

Теоретически-практические книжки чуть более сложные. Я бы рекомендовал начать с DDD это очень холиварная тема! Возможно, DDD это не то, что вам нужно на этапе создания стартапа, но попробуйте обратить внимание не на технические аспекты, а на высокоуровневые паттерны. На то, как DDD предлагает общаться с экспертами, выделять главное, и на то, что продукт порой важнее используемых технологий. Если вам это зайдет, то дальше начнется протоптанная другими тропа: DDD -> CQRS -> Event Sourcing. Чаще всего все эти три темы обсуждаются в одном комьюнити. Как только вы разберетесь, что собой представляет каждая из концепций, вы поймете почему.

Немного особняком стоит книга Скотта Влашина про DDD в мире функционального программирования. Во-первых, ФП в изложении Влашина это не сложно. Обратите на книгу внимание хотя бы поэтому. Во-вторых, даже если в ближайшие десятилетия вы не собираетесь никуда сворачивать с тропинки объектно-ориентированного программирования, изучение других способов решения знакомых проблем может быть точкой роста. Я большой фанат гипотезы лингвистической относительности (и фильма Прибытие удачно выигрывающего эту гипотезу). В каком-то смысле знание языков программирования может влиять на ваше мировоззрение также, как знание естественных языков.

Теория

Факты и заблуждения профессионального программирования

Если эти книги вам знакомы или показались неинтересными, а вы хотите прочесть что-то более фундаментальное, рекомендую книгу Роберта Гласса Факты и заблуждения профессионального программирования. Она в свое время помогла мне перестать проваливать сроки реализации проектов, потому что я понял, что некоторые числа, которые были в моей голове, в три раза отличались от реальности. Книга хороша тем, что Роберт Гласс всю свою жизнь фактически проработал в аэрокосмической отрасли и собирал реальную статистику о том, сколько времени занимает анализ, разработка, тестирование, как неточны оценки, как часто меняются требования и как на самом деле сложно адаптироваться к таким изменениям.

Мифический человеко-месяц

Книга Фредерика Брукса, несмотря на то, что ей уже 100500 лет, и вы можете встретить в тексте что-то про перфокарты, это фундаментальный труд. Закон Брукса никуда не делся и, кажется, не денется. Понимание этого закона (девять матерей не родят дитя за один месяц) поможет принимать критические и зачастую контринтуитивные управленческие решения. Юбилейное издание включает в себя статью Серебряной пули нет, с которой тоже не грех ознакомиться всем и каждому.

Сколько стоит программный продукт

Большинство знает другую книгу МакКонела Совершенный код. Для кого-то она даже стала своеобразной Библией программирования. Если вы уже программируете хорошо и хотите научиться лучше оценивать трудозатраты на разработку, прочтите Software Estimation: Demystifying the Black Art (Сколько стоит программный продукт; в оригинале название звучит точнее, не находите?:). Книжка сложная, со статистикой, но ничего лучшего об оценке я не видел. Гарантирую, качество оценки тех, кто использует методы и советы из книги, многократно превосходит качество оценки тех, кто делает это по наитию.

Лютая теория и даже философия

Но если этого вам мало, и вы хотите улучшить свое умение думать о процессе, в целом, понять разницу между управлением, организацией и даже не прочь почитать что-то философское, то Г. П. Щедровицкий Оргуправленческое мышление это то, что вам нужно. Книга очень сложно читается, это конспект лекций для руководителей стройки атомных электростанций в СССР. На момент строительства никакой методологии Как строить атомные АС просто не существовало. Стройки велись по всему СССР, что делало каждый проект уникальным. В этих условиях успех строительства напрямую зависел от качества организации и от управления стройкой. В терминологии Щедровицкого эти два слова значат совсем не одно и тоже. В ходе лекций автор пытается найти баланс между первым и вторым. Труд просто фундаментальный и где-то философский, предназначенный для организаторов и руководителей с большой буквы.

Цель. Процесс непрерывного улучшения

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

На этом мой список книг подходит к концу. Выбирайте полезные для себя и enjoy!

TechLead Conf 2021 конференция, полностью посвященная инженерным процессам и практикам откроет свои двери уже совсем скоро: 30 июня и 1 июля она пройдет в Radisson Slavyanskaya (Москва).Расписаниеуже готово.Билетыв продаже. А ещё у нас открытдоступк докладам TechLead Conf 2020.

До встречи в офлайне!

Подробнее..

Категории: Конференции , Управление персоналом , Управление разработкой , Материалы , Блог компании конференции олега бунина (онтико) , Techleadconf , Литература , Техлид , Ресурсы

	Русский
	English

Техлид

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

Познакомьтесь с Бобом

Творческая некомпетентность: способ быть профессионалом

На правах рекламы

Перевод Так выглядит эффективная работа техлида

Что значит напрямую поддерживать команду?

Производительность вашей команды = ваши возможности как руководителя

Помогайте людям работать быстрее с помощью правильных инструментов

Среда

Летучки

Мотивация

Как продать технические задачи бизнесу

Чем продажа идеи отличается от программирования?

Пример неудачной продажи

Система продаж Джордана Белфорта

Как добиться уверенности на 100\100\100?

Алгоритм продажи чего угодно, в том числе идей

Пример

Полезные фишки

Подводя итог

Книги, которые повлияли на меня как на разработчика и управленца

Практика

Specification by Example

Event Storming

Impact Mapping

Теория + практика

Теория

Факты и заблуждения профессионального программирования

Мифический человеко-месяц

Сколько стоит программный продукт

Лютая теория и даже философия

Цель. Процесс непрерывного улучшения

Категории

Последние комментарии