Книга: «Карьера разработчика. Стафф — круче, чем senior»
Привет, Хаброжители! Если вы сеньор-разработчик, то наверняка задавались вопросом: «Что дальше?» Переход в менеджмент кажется очевидным шагом, но что, если вы не хотите управлять людьми? Что, если вы хотите оставаться техническим специалистом, но при этом расти профессионально и влиять на стратегию компании? Ответ на этот вопрос — открыть для себя путь стафф-разработчика.
Новая книга Тани Рейли, опытного инженера и технического лидера, под названием «Карьера разработчика. Стафф — круче, чем senior» — это подробное руководство для тех, кто хочет понять, как стать стафф-разработчиком и в чём заключается его роль.
Кто такой стафф-разработчик?
Стафф-разработчик — это технический лидер, который не управляет людьми, но при этом оказывает огромное влияние на компанию. Он отвечает за крупные проекты, определяет техническую стратегию, устанавливает стандарты разработки и помогает коллегам расти профессионально.
В отличие от менеджеров, стафф-разработчики остаются «в коде», но их влияние выходит далеко за рамки написания программ. Они думают о долгосрочных целях, работают над сложными архитектурными решениями и помогают компании двигаться вперед, не теряя технической экспертизы.
Почему стоит обратить внимание на «Карьеру разработчика»?
Многие разработчики сталкиваются с дилеммой: продолжать писать код или переходить в менеджмент. Книга Тани Рейли показывает, что есть третий путь — стать стафф-разработчиком. Это возможность оставаться техническим специалистом, но при этом влиять на стратегию компании, работать над интересными проектами и помогать другим расти.
Если вы сеньор-разработчик и задумываетесь о своем профессиональном будущем, эта книга станет для вас ценным ресурсом. Она поможет понять, подходит ли вам путь стафф-разработчика, и даст практические советы, как по нему двигаться.
- Книга отвечает на ключевые вопросы:
- Как стать стафф-разработчиком, если вокруг нет примеров для подражания?
- Какие навыки нужны для успеха на этом уровне?
- Как влиять на компанию, не имея формальной власти?
- Как совмещать техническую экспертизу с лидерством?
Что внутри книги?
Книга состоит из девяти глав, каждая из которых посвящена ключевым аспектам карьеры стафф-разработчика:
- Как перейти от уровня senior к стафф+.
- Как развивать панорамное мышление.
- Как успешно реализовывать крупные проекты.
- Как влиять на команду и компанию без формальной власти.
- Как стать ментором и вдохновлять других.
Для кого эта книга?
Для сеньор-разработчика, который хочет расти дальше.
Для технического специалиста, который хочет лучше понимать свою роль.
Для менеджера, который хочет лучше взаимодействовать со стафф-разработчиками.
Книгу можно купить у нас на сайте. А ознакомиться с отрывком можно прямо в этой статье.
ПРОЕКТ ЗАТОРМОЗИЛСЯ ИЗ-ЗА ОДНОГО ЧЕЛОВЕКА
Ждать одну команду неприятно, но еще неприятнее, когда важный проект останавливается из-за одного человека. Работа уже у него на столе, а он просто ничего не делает.
Что происходит?
Однажды мой проект остановился из-за коллеги, который должен был решить одну задачу с помощью пары коротких скриптов на Python. Шли недели, а скрипты так и не появлялись, и с каждым днем мне все больше хотелось написать их самостоятельно. При этом у моего коллеги всегда находилось оправдание: то произошел сбой, то ему понадобился выходной, то у него сломался компьютер. Я несколько недель расстраивалась оттого, что он не делал нужную мне работу, но потом поняла, что это не из-за лени: ему просто страшно. Он пришел с операционной должности, а там работа постоянно прерывалась, и ему приходилось перепрыгивать от одной срочной задачи к другой, так что умение полностью сконцентрироваться требовалось довольно редко. Мой проект стал для него возможностью написать код, но он не верил в свои силы, и поэтому даже не пробовал начать.
Иногда коллеги не называют истинные причины, по которым они не делают какую-то работу. Может быть, человек перегружен, боится, что не справится с заданием, или просто у него не получается его выполнить. Он может находиться в стрессе из-за событий в личной жизни, которые мешают ему погрузиться в задачу, или начальник постоянно присылает ему сообщения с важной работой, и вашему коллеге неловко сказать вам, что ваш проект имеет более низкий приоритет. Или, может быть, он даже со второго раза не понял, о чем вы просите, и слишком стесняется спросить вас в третий раз. Со стороны все эти причины выглядят одинаково: человек просто не делает свою работу.
Помогаем коллеге сделать его работу
Есть несколько способов помочь человеку, которому сложно сделать свою работу. Давайте внесем ясность: вы для него не начальник и не психотерапевт, а значит, исправлять его прокрастинацию — не ваша задача. Но возможно, вы получите нужный вам результат и, если вы имеете дело с менее опытным сотрудником, сможете использовать эту возможность, чтобы сформировать у него некоторые навыки. Вот что вы можете сделать:
Понять и объяснить. Выясните побольше информации о своем коллеге. При встрече с ним не принимайте на веру его обещание выполнить работу на следующей неделе: постарайтесь поглубже вникнуть в ситуацию. Может быть, вы так и не узнаете, что происходит, но хотя бы поймете, можете ли вы чем-то ему помочь.
Очень четко объясните, почему важно выполнить эту задачу. Особенно если вам приходится ждать коллегу, у которого более высокое положение в компании и который (предположительно!) не просто откладывает задачу, а принимает осознанное решение о ее второстепенной важности. Объясните, каковы цели бизнеса и что именно произойдет, если он не сделает эту работу. Если у него высокая загрузка и он не успевает, попросите его сообщить вам об этом заранее, чтобы вы могли найти альтернативы. Попробуйте установить более ранний срок выполнения, после которого сможете оценить, успеет ли ваш коллега выполнить задачу вовремя, и если нет, то найдите другой подход.
Упростить работу. Сделайте задачу максимально простой для человека, который должен ее решить. Например, раскройте ее структуру, разбейте на части или выделите основные этапы: если проект слишком сложный, то даже разбить его на части может быть непросто. Не усложняйте свой запрос, заставляя человека искать что-то в документах, касающихся назначенных ему задач, или догадываться о том, что вы просите сделать: просто скажите, что вам нужно. Рассмотрите технику Брайана Фицпатрика (Brian Fitzpatrick) и Бена Коллинза-Сассмана (Ben Collins-Sussman) «три пункта и призыв к действию», с помощью которой можно попросить занятого исполнителя сделать что-то для вас: здесь она тоже работает!
О чем вы просите?
Мне нравится метод «три пункта и призыв к действию», который Брайан Фицпатрик и Бен Коллинз-Сассман описали в своей книге «Debugging Teams» (изд. O«Reilly). Они пишут: «Хорошее письмо в технике «три пункта и призыв к действию» содержит (в основном) три коротких пункта, описывающих задачу, и один — только один — призыв к действию. И все, ничего больше — вы должны написать письмо, с которым будет легко работать. Если ваши мысли будут растекаться или вы поместите в одно письмо четыре принципиально разных вопроса, то будьте уверены, что вам ответят только на один наименее важный. Или еще хуже: чтение потребует так много умственных усилий, что ваше письмо просто удалят».
Если ваш коллега в ужасе от запутанности проблемы, то это может стать возможностью для его обучения. Объясните ему, что ваша задача действительно сложная, но в ней можно разобраться. Окажите помощь, но постарайтесь не брать все на себя. Задавайте вопросы, отвечайте на них и помогайте ему найти свой путь.
Если ваш коллега хочет сделать работу, но не знает, с чего начать, посмотрите, можете ли вы начать вместе. Для человека, о котором я рассказала ранее, такой подход стал хорошим решением: совместное написание скриптов помогло ему преодолеть страх первых шагов и дало возможность продолжить самому. Парное программирование также может принимать форму совместных размышлений у доски, или вы можете сесть и вместе отредактировать документ. Последнее может помочь, если задержка в работе произошла из-за менеджера: встретьтесь лично, предложите время, когда вы можете вместе отредактировать документ, и оставайтесь рядом, чтобы ответить на все вопросы, которые у него появятся.
Получить поддержку организации. Прежде чем выносить проблему на более высокий уровень, вы должны попробовать все остальные возможные подходы, но в конечном счете может оказаться, что человек действительно не делает свою работу, и тогда решать эту проблему должен менеджер по персоналу. Сложный разговор с менеджером не очень приятен, но если кто-то ставит под угрозу успех всего проекта, вы должны выполнить свои обязанности и озвучить проблему. Как я уже говорила, обращаться к начальству — не значит жаловаться: это значит найти поддержку. Например, если ваш коллега не берется за вашу задачу, потому что работает над тем, что его менеджер считает более важным, то разговор с менеджером может быть единственным способом изменить приоритеты.
ПРОЕКТ ЗАТОРМОЗИЛСЯ ИЗ-ЗА НИЧЕЙНОЙ ЗАДАЧИ
А что, если задача никому не назначена? Если группа команд совместно работает над какой-то проблемой, то некоторые задания не попадают ни в одну дорожную карту, хотя все согласны, что их нужно сделать. Они либо слишком велики для одного разработчика, либо занимают много времени, либо требуют создания нового компонента, за который кто-то должен отвечать и постоянно его поддерживать: нужна команда, которая возьмет это на себя. Может быть, несколько команд считают, что они уже вовлечены в эту работу (они один раз появились на совещании и высказали свои мнения в каждом RFC), но реально писать код не собираются.
Что происходит?
Это пример проблемы тектонических плит (см. главу 2). Каждая команда имеет четкие границы ответственности. Согласованные границы — это прекрасно, они помогают каждому сосредоточиться на своей работе, но вдруг возникает некоторая критическая, основополагающая задача, которая никому не принадлежит. Мы сталкивались с похожей ситуацией в главе 3 на примере SockMatcher. Многие разработчики думали об архитектуре: рабочая группа Женевы, в которой обсуждались проблемы архитектуры, включала в себя много участников. Но трудности были слишком велики, чтобы устранить их, не создавая отдельный проект. Работа не сделается, пока не получит должного внимания.
Если задача никому не назначена, то нет смысла делить ее на части, оптимизировать или строить какие-то планы: вы не продвинетесь, пока кто-то не возьмет ее на себя. Разработчики склонны решать подобную организационную проблему, вкладывая больше усилий в смежную с ней техническую работу. (См. иллюстрацию карты сокровищ на рис. 6.4: непреодолимые горы — это нехватка персонала!)
Если не решена организационная проблема, то вам не помогут дизайны и умные решения. Суть проблемы в организационном разрыве. Если вы не можете его склеить, то попусту потратите время.
Разбираемся с ничейной работой
Если проект тормозится из-за невыполненной работы, за которую, по-видимому, никто не отвечает, вы все-таки можете кое-что сделать.
Понять и объяснить. Не всегда очевидно, что задача никому не принадлежит, особенно если много команд тесно с ней связаны. Поскольку вы больше всех заинтересованы в успехе, не удивляйтесь, если все подумают, что эта работа теперь ваша. Больше общайтесь, ищите зацепки и выясняйте, что происходит на самом деле. Дайте свою интерпретацию ситуации и сделайте явные выводы. Затем запишите их! (См. блок ниже.) Будьте краткими и сформулируйте четкие утверждения: как я сказала в главе 5 о дизайн-документах, лучше неправильно, чем непонятно. Вы не найдете, где кроется недопонимание, пока не проясните все неясные моменты.
СВОДКА
Дэнис Ю (Denise Yu), менеджер из GitHub, описывает «искусство составления сводки» (https://oreil.ly/5U1wf): умение собрать всю информацию в одном месте, чтобы «внести ясность и уменьшить путаницу». Эта универсальная техника полезна, если у задачи длинная предыстория и несколько сюжетных линий, а также если кто-то потерял нить повествования.
Собирая факты в сводку, вы можете расширить свои знания и убедиться в том, что вы верно понимаете ситуацию. Также, записывая, вы можете синтезировать информацию, которую еще никто не сформулировал. Например, Алекс говорит: «Новая библиотека позволит реализовать аутентификацию для данной точки вызова». А позже Милена говорит: «Мы сможем обновить эту библиотеку до последней версии не раньше третьего квартала». Вы можете записать оба факта, а также их интерпретацию: «Мы не сможем реализовать аутентификацию раньше третьего квартала».
Если вы в курсе всех обстоятельств, то этот вывод может показаться очевидным, но если раньше никто до него не додумался, то для кого-то он может оказаться открытием. Проговорив вывод вслух, вы позволяете людям отреагировать на новую информацию и скорректировать курс.
Упростить работу. Если у вас есть время на обучение и консультирование или вы можете присоединиться к команде, которая делает нужную вам работу, укажите это в своей сводке. Директора любят сплачивать людей вокруг вызвавшегося добровольца, и шанс поучиться у разработчика уровня стафф+ может побудить присоединиться остальных участников.
Получить поддержку организации. Самое ценное, что вы можете дать проекту, — это обеспечить его поддержкой организации и собственной команды. Прежде чем вы начнете искать спонсора для своей работы, отрепетируйте свой питч и убедитесь, что вы можете объяснить, почему на эту проблему стоит тратить время компании. Вы же хотите, чтобы спонсор не только поверил вам, но и, если потребуется, смог оправдать затраченные вами усилия перед своими коллегами и руководством.
Составить альтернативный план. Если вам обещали предоставить персонал, запаситесь терпением: чтобы укомплектовать проект сотрудниками, нужно переформировать команды, а менеджеры и директора (по понятным причинам) предпочитают сначала обдумать такие вопросы. Но если вы не можете получить согласие компании на то, чтобы кто-то взял на себя определенную работу, или вас постоянно отправляют на «следующий квартал», не разъясняя, откуда возьмут сотрудников, то скорее всего, ваш проект не имеет высокого приоритета для организации и его можно отложить.
ПРОЕКТ ТОРМОЗИТСЯ УЙМОЙ НАРОДУ
И наконец, я хочу поговорить о ситуации, при которой требуется помощь всех сотрудников организации: например, если вы переходите на новую платформу или удаляете старую, то все команды, использовавшие определенный сервис или компонент, должны будут поменять свой алгоритм работы. Велика вероятность, что далеко не все захотят это делать.
Я работала над огромным количеством миграций ПО и знаю, как они раздражают. У вас есть веские основания убрать старую систему и четкий план, как это сделать, вы всем все объяснили, но другие команды не обращают на ваши письма никакого внимания. Когда вы к ним приходите, они говорят, что заняты, но вы тоже заняты! Почему они не понимают, что это нужно сделать?
Что происходит?
У каждой команды и у каждого человека своя правда. Одни могут поддерживать переход на другую систему, но не иметь времени этим заниматься. Другие могут противиться изменениям: может быть, им больше нравилась старая система или им кажется, что новой не хватает каких-то необходимых функций. У третьих вообще может не быть своего мнения, но они уже так сильно устали от постоянных, демотивирующих потоков обновлений, замен и изменений в процессах, что не видят в них никакой пользы.
У людей, голосующих за перенос и против него, есть свои аргументы. Но никто из них не хочет оказаться в ситуации, когда перенесена половина данных: командам придется поддерживать обе системы, а новым клиентам — разбираться, какой системой пользоваться, особенно если переход застопорился и существует риск, что его отменят.
Разбираемся с незавершенной миграцией ПО
Незавершенная миграция программного обеспечения замедляет работу всех, кто в этом участвует. И здесь стафф-разработчик может сильно повлиять на ситуацию. Вот несколько способов, которые могут помочь всем добраться до финишной черты.
Понять и объяснить. Причины перехода на новую систему могут затеряться среди другой информации, и я часто слышу, как про него говорят: «Да просто инфраструктурная команда хотела поиграться с новой технологией», хотя в реальности перенос пришлось запустить из-за потребностей бизнеса или проблем с совместимостью, и инфраструктурной команде тоже не нравится заниматься переездом. В то же время я часто слышу другую фразу: «Команду продукта не беспокоит наш технический долг; они просто хотят создавать новые функции», после того как эта самая команда полквартала реагировала на другие миграции ПО и уже отчаялась начать работу над своими задачами. Поймите обе стороны и помогите каждому рассказать свою правду. Объясните, почему работа так важна и почему ее трудно выполнить. Станьте парламентером.
Упростить работу. Повторяю снова: чтобы убедить других людей решить какую-то задачу, сделайте ее максимально простой. Стремитесь к тому, чтобы команда, настаивающая на миграции ПО, самостоятельно выполнила как можно больше связанной с этим дополнительной работы. Если можно автоматизировать какие-то шаги, пусть они сделают это. Если можно более подробно объяснить, что должна сделать каждая команда, например, какие файлы им нужно отредактировать, потратьте время и предоставьте им эту информацию. Я надеюсь, и так понятно, что новая система должна действительно хорошо работать, не заставляя команды спотыкаться о препятствия на каждом шагу.
Сделайте все, чтобы новый способ работы стал сценарием по умолчанию. Обновите документацию, код или процессы, которые ссылаются на старый способ. Найдите людей, которые поддерживают старый сценарий, и попросите их о помощи. Если у вас есть поддержка организации, то вы можете ограничить список пользователей, которым разрешается работать по старому сценарию, или усложнить его применение. Однажды мне встретился такой подход: чтобы старый способ заработал, пользователю приходилось писать в конфигурации что-то вроде: «я_знаю_что_это_не_поддерживается».
Покажите всем, что работа продвигается. На одном проекте я должна была заставить сотни команд изменить конечную точку в их конфигурационных файлах. Люди охотнее стали делать эту работу после того, как я поделилась графиком, который показывал, сколько было сделано и сколько осталось сделать. Всем хотелось снизить цифры. Наверное, какие-то нейроны в нашем головном мозге любят графики, стремящиеся к нулю!
Некоторые команды могут быть действительно слишком заняты, чтобы заниматься переходом на другую систему, или у них найдется сценарий использования, который не поддерживает ваша автоматизация. Также могут обнаружиться компоненты, которыми никто не занимается и которые теперь никто не может обновить. Можете ли вы сотрудничать с такими командами или внести в систему изменения специально для них?
Получить поддержку организации. Переход на другую систему пройдет легче, если вы всем покажете, что он важен для организации. Конечно, он действительно должен быть важен. Если команды завалены работой над изменениями, то организация должна приоритизировать наиболее важные из них и довести до конца первую группу изменений прежде, чем начинать работать над второй. Если вы не можете убедить свое руководство, что переход нужно прописать в целях организации на квартал или в списке важных проектов, то, может быть, вы не должны сейчас тратить на него свое время.
Составить альтернативный план. В конце миграции ПО вам могут пригодиться нестандартные решения. Если у вас есть разрешение компании, а команды все еще не переходят на новый способ работы, то можете ли вы отключить старый или даже добавить в него некоторые трудности, например ввести искусственные задержки или выключать старый сервис с определенными интервалами? Только не делайте этого, если вы не заручились сильной поддержкой организации (и совсем не делайте этого, если вы можете сломать что-то у ваших клиентов; будьте благоразумны). Если оставшиеся команды совсем отказываются переезжать со старой системы, можете ли вы назначить их единственными ответственными за нее и ее техническую поддержку, чтобы система стала компонентом их собственного сервиса? Кто уходит последним, тот и гасит свет, товарищи.
Карьера разработчика не заканчивается на уровне senior. Путь стафф-разработчика — это возможность оставаться техническим специалистом, но при этом влиять на стратегию компании, работать над масштабными проектами и помогать другим расти. Если вам интересно попробовать себя в новой роли и вырасти в своих профессиональных навыках, переходите на сайт и обратите своё внимание на «Карьеру разработчика. Стафф — круче, чем senior»!
» Оглавление
» Отрывок
По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
Для Хаброжителей скидка 25% по купону — Карьера
