какие инструменты командной работы используются при разработке по
Инструменты, которые мы используем для командной разработки
Данная статья будет интересна разработчикам, которые решили попробовать себя в команде, как это в своё время сделал я со своими настоящими коллегами. Ничего нового я не расскажу, просто поделюсь своим скромным опытом и, надеюсь, подтолкну кого-нибудь сделать то же самое в комментариях.
Когда работаешь в одиночку, можно обойтись простым блокнотом. Notepad++ для написания кода и лист бумаги с карандашем для заметок. Я конечно утрирую, но, по сути, это так и есть. В командной разработке всё немного иначе.
Системы управления проектами
Здесь нужно постоянно общаться с другими участниками процесса, при этом необходимо, чтобы история переписки сохранялась и к ней был удобный доступ. Для этого используют сервисы и веб-приложения для управления проектами. В нашем случае это Redmine. До него пробовали TeamLab. Есть как SAAS версия, так и веб-приложение для установки на свой сервер, кстати opensource. Но последний как-то не прижился. Подобных инструментов нынче много, как платных, так и opensource. Они помогают распределять задачи между разработчиками и задавать для них приоритет, отслеживать затраченное время и многое другое.
Отдельно хотелось бы сказать об управлении ролями. Для каждой такой роли можно индивидуально настроить права доступа. Возьмем частный случай. По умолчанию в redmine есть роль reporter, т.е. человек, который только сообщает об обнаруженных проблемах, не принимая участия в их решении. Мы настроили ее таким образом, чтобы пользователь с этой ролью видел только проекты, в которых он участвует. Так у нас получилось вовлечь заказчиков непосредственно в процесс разработки. Если они находят баги или хотят сделать доработки, то заходят в редмайн и самостоятельно добавляют задачи с соответствующим трекером (ошибка, улучшение, разработка или поддержка). Конечно менеджер всё это контролирует и при необходимости корректирует, а так же предварительно проводит с каждым клиентом инструктаж. Так же можно написать для них инструкцию при помощи плагина Q&A.
Как говорится, встречают по одежке. По этому редмайн с первого взгляда не впечатляет и выглядит уныло по сравнению с его платными аналогами вроде JIRA, basecamp и т.п. Это обычное дело для opensorce. Но для redmine есть красивые темы оформления, при чем высокого качества, например A1.
Так же Redmine можно превратить в почти полноценную CRM при помощи бесплатного плагина от RedmineCRM, который добавляет контакты, сделки, заметки и отправку сообщений прямо из интерфейса, в связке с бесплатными Invoices (счета), Finance (финансы) и People (люди).
Системы контроля версий
Так же при командной разработке возникает проблема версионности. Если два разработчика одновременно открыли один и тот же файл и начали его редактировать, то при сохранении результатов неизбежно возникнут проблемы. Второй просто перезапишет изменения первого. Для избежания подобных ситуаций существуют системы контроля версий, например SVN или GIT. Это еще одна незаменимая вещь при командной разработке.
В SVN (не сомневаюсь, что и в GIT тоже) есть крайне полезные хуки — скрипты, срабатывающие по определенному событию. В их числе post commit. Этот хук при выполнении коммита загружает в указанное место на сервере все отредактированные файлы. Это очень удобно, например, при работе с версткой. Сверстал макет, сделал коммит — дал ссылку заказчику. Если он обнаружил баги — исправил, сделал коммит, ответил, что можно проверять. Никаких загрузок архивов на сервер, которые при большом количестве правок отнимают много времени.
Раз уж я заговорил об автоматизации рутинных действий, не правильно будет не упомянуть IDE — (Integrated Development Environment — интегрированная среда разработки). Как ни странно, но многие разработчики, особенно это касается программистов, пользуются примитивным софтом, например Notepad++. Ничего не имею против этой программы и сам ей часто пользуюсь, когда нужно что-то быстро отредактировать. Загружается он моментально, это несомненный плюс. Но когда речь заходит о ежедневном использовании, подобные миниатюрные приложения должы уступать место полноценным IDE со всеми их преимуществами. Лично я пользуюсь PHPStorm’ом. Перечислю только самые полезные, на мой вгляд, функции:
Само собой, что PHPStorm разрабатывался специально для PHP-программистов. Если вы работаете c другим языком, можете выбрать необходимый для ваc IDE от тех же разработчиков (JetBrains) на этой странице. На данный момент у них есть программы для следующих языков программирования:
Облачные хранилища данных
Помимо текстовых файлов, при работе в команде нужно обмениваться и бинарными (напр. изображения). Для этих целей системы контроля версий использовать смысла мало: при возникновении конфликта все равно объединить два файла не удастся, при большом количестве ревизий репозиторий будет иметь огромный размер. В случае с PSD файлами, которые зачастую весят по 20 мегабайт и более, эта проблема вообще становится критичной. По этому для таких целей лучше подойдет облачное хранилище данных. Мы используем Dropbox. У этого сервиса есть очень достойная альтернатива — Google Drive, которая имеет ряд преимуществ, например, хорошую систему распределения прав доступа к файлам. Это может быть очень удобным в том случае, если нужно кому-то дать доступ к материалам по проекту, но что бы при этом он их не мог редактировать. Но, к сожалению, когда мы выбирали такой инструмент для своей команды, последний был просто до безобразия сырым. Так что мы немного помучались, поплевались и перешли на Dropbox.
Так же мы используем дропбокс для демонстрации дизайна заказчикам. Это очень удобно — загрузил PNG-превьюшки макетов в отдельную папку, нажал «Share link» и получил ссылку с вот такой галереей. Изображения нужно загружать именно в PNG, потому что JPG макеты дропбокс дополнительно сжимает и они становятся совсем низкого качества. Главным преимуществом такого способа демонстрации дизайна заказчику является то, что он всегда видит самые свежие версии макетов по одной и той же ссылке. Например, дизайнер внес правки в макеты, обновил превьюшки и они обновились в галерее по ссылке, которую ранее дали заказчику. Осталось только сказать заказчику, чтобы обновил страницу в браузере.
Безусловно, этот список можно расширять и расширять. По этому буду рад, если в комментариях коллеги поделятся своими секретами по оптимизации командной разработки.
Какие инструменты для командной работы делают из обычных сотрудников Команду Мечты?
Вы когда-нибудь задумывались, какой процент успешно реализованных проектов был выполнен вами самостоятельно, а сколько из них требовало участия команды? Думается, ответ очевиден: для крутых проектов необходима крутая команда.
Любой мотивированный менеджер продукта должен не только заботиться о профессиональных навыках, изучать новые методологии и применять последние гроус хаки, но и стараться создать сильную и успешную команду.
Что делает команды сильней и крепче? Хорошо налаженное сотрудничество внутри – один из ключевых аспектов, помогающих командам справляться со сложными задачами и противостоять любым преградам. Сплоченная команда — мечта и цель любого менеджера продукта.
В чем сила сотрудничества? И какие секретные инструменты помогают менеджерам создавать сильные коллективы?
«Руководить – значит не мешать хорошим людям работать»
Сергей Капица
Какие инструменты лучше всего подходят для командного сотрудничества?
Естественно, любой профессиональный инструмент для менеджера и команды – это не панацея.
Руководители продуктов должны думать о качестве коммуникации начиная с собеседований, испытательных сроков сотрудника, знать как правильно проводить мозговые штурмы. Даже после успешного релиза во время тимбилдинга важно думать о том, как поднять уровень командного сотрудничества на новый уровень.
В этой статье описываем 9 типов инструментов, которые помогут создать сильный командный дух и упростить коллективные рабочие процессы. У всех этих инструментов разные цели, некоторые из них платные, некоторые бесплатные. Какие-то из них подходят для всех продуктов, а какие-то узкоспециализированные.
Этот список достаточно субъективен, поэтому после каждого приведенного примера предлагается несколько альтернатив, чтобы любой читатель мог выбрать лучшее для себя из перечисленного:
Инструменты для коммуникации
Пример: Slack
Slack — это чат-сервис в режиме реального времени, который получил быструю популярность после распространения в компаниях Силиконовой Долины.
Сервис работает на основе каналов и включает голосовые и видеозвонки, хотя эти компоненты Slack не так популярны, как текстовые чаты. Здесь можно добавлять картинки, emoji, GIF, обмениваться документами и организовывать групповые чаты.
Как работает Slack?
Вы можете использовать Каналы как чаты или общедоступные стримы. Это можно сделать всего с помощью нескольких кликов. Написать напрямую определенному контакту, крепить документы и файлы для него также можно.
Параметр «Private Groups» позволяет организовывать беседы с конкретными членами команды. Вы можете приглашать разработчиков, специалистов по продажам, HRов и так далее.
Весь контент в Slack доступен для поиска из одного поискового окна. Вы также можете использовать помощь бота Slackbot, который может дать вам больше информации, напоминать о срочных делах и быть полезным по другим вопросам.
Альтернативы: HipChat, Microsoft Teams
Инструменты для управления проектами и продуктами
Пример: Hygger.io
Hygger — это полноценная платформа для управления продуктами для растущих компаний. Сервис может использоваться для совместной работы в небольших и крупных командах. Hygger предлагает ряд качественных и полезных функций:
Альтернативы: Trello, Aha, Asana.
Инструменты для организации удаленной связи и видеоконференций
Пример: Hangouts
Сервис широко используется компаниями для внутренней удаленной связи в качестве обмена мгновенными сообщениями или видеоконференций с совместным использованием экрана. Это помогает организовать собрания и презентации без специального отдельного инструмента планирования. Вы можете отправлять приглашения любому члену команды и координировать действия прямо на боковой панели.
Индивидуальные чаты позволяют членам команды сотрудничать в групповом проекте, общаться с коллегами, клиентами или другими членами команды, вносить изменения в Google доки и т. д.
Альтернативы: Skype, Amazon Chime, Join.me
Сервисы для работы с документами
Пример: OneNote
OneNote будет полезен, если нужно управлять движением документов и делиться ими с вашей командой. Это своего рода совместная записная книжка, которая позволяет легко распространять большое количество данных среди членов команды.
OneNote — это больше, чем просто работа с документами. Многие компании используют его как идеальный инструмент для управления проектами в командах. Это бесплатный инструмент. Используя разные разделы и страницы OneNote, вы можете предоставить членам вашей команды релевантную информацию в любое удобное для вас время. Здесь можно создавать несколько разделов и подстраницы для хранения важных данных.
OneNote позволяет обмениваться информацией с любого устройства.
Альтернативы: Evernote, Quip, G Suite
Инструменты для отслеживания времени
Пример: Hubstaff
Хотите успешно управлять рабочими процессами и производительностью удаленных членов команды? Hubstaff — один из самых удачных инструментов, который упрощает процессы менеджера продукта и добавляет прозрачности в совместную командную работу.
Используя этот сервис тайм трекинга, вы можете установить ограничения по времени или стоимости для своих проектов, а также лимиты для каждого члена команды. Вы можете отслеживать планирование посещаемости, уровни активности и другие организационные моменты. Инструмент позволяет делать скриншоты работы команды и предоставить вам эти данные удаленно.
Hubstaff представлен бесплатной и платной подпиской.
Альтернативы: FreshBooks, Click time, Scoro, TimeCamp, Toggl
Инструменты для баз данных
Пример: Confluence
Большинство крупных мировых корпораций знают о Confluence. Этот инструмент помогает организовывать команды и централизовать всю информацию, необходимую для синхронизации действий.
Confluence предлагает дружественный интерфейс, где вы можете создавать заметки о встречах, задавать планы проектов или требования к продуктам, использовать шаблоны, писать комментарии и получать обратную связь. Все в одном месте. Здесь вы также можете использовать надстройки, такие как командные календари для планирования событий или обсуждения вопросов и голосования.
Альтернативы: Guru, Bloomfire, Nuclino, Crowdbase
Инструменты для обмена информацией (совместное использование файлов)
Пример: Dropbox
Популярным онлайн-хранилищем пользуются более 500 миллионов пользователей по всему миру. Dropbox позволяет не только хранить все ваши файлы вместе в одном месте, но и делиться ими с другими членами команды.
Вы можете отправлять ссылки по электронной почте или чатам, оставлять отзывы и обмениваться доступом к своим документам с любого устройства.
Dropbox бесплатен для индивидуального использования, но вы должны заплатить за бизнес-план, чтобы получить больше места или получить более широкий доступ.
Альтернативы: Hightail, MediaFire, Tresorit, ShareFile
Внутренние социальные сети
Пример: Yammer
Вы можете сказать, что это пример из «прошлого века». Но, на самом деле, Yammer является одной из первых социальных сетей, созданных специально для внутренних потребностей офисных команд. Сервис популярен сегодня не менее, чем раньше. Члены команды могут публиковать обновления и общаться в группах и каналах, используя этот инструмент.
Три основных преимущества использования Yammer для внутреннего или даже внешнего взаимодействия: простота использования, наличие мобильной версии и возможность сотрудничества с внешними пользователями.
Альтернативы: Jive-n, Facebook workplace
Сервисы для макетов и прототипов
Пример: Marvel
Marvel известна во всем мире как одна из самых простых программ для бизнес-макетов. Она помогает менеджерам и командам сотрудничать вместе на мобильных девайсах, планшетах и настольных прототипах приложений и веб-сайтов.
Если вы работаете с разными отделами или клиентами, этот инструмент позволяет организовать вашу работу более эффективным образом.
Вы можете добавить свои отзывы непосредственно к прототипам и аннотировать области, которые хотите выделить. Клиенты могут оставлять комментарии без необходимости подписываться на Marvel.
Альтернативы: Mockup.io, InVision, Flinto.
Сколько из описанных сервисов вы уже использовали в своей работе? Показались ли они вам действительно полезными или стоило обратить внимание на альтернативы? Делитесь своим опытом в комментариях!
Базовое руководство по созданию сбалансированных команд разработчиков
Общался недавно с миддлом из команды разработки, которая состояла из 6-ти сеньоров и одного миддла. По словам миддла, расти в этой команде было очень сложно по ряду причин:
Послушав этого миддла, я заинтересовался тем, как обстоят дела с балансированием команд разработки специалистами разного уровня, есть ли смысл создавать команды, состоящие из одних сеньоров, и как повышать свой уровень в таких командах на примере компаний из, например, Кремниевой Долины.
В результате я наткнулся на статью, перевод которой приведен под катом.
Прошу участников сообщества привести в комментариях свои мысли, как бы они действовали, будучи в описанной позиции миддла: как обучаться, как вести себя с другими членами команды и любые другие ваши мысли.
Базовое руководство по созданию сбалансированных команд разработчиков
Согласно опросу разработчиков StackOverflow за 2016 год, участие в программе наставничества сильней коррелирует с зарплатой, чем наличие кандидатской степени, а разработчики больше ценят изучение новых вещей по сравнению с другими мотиваторами, такими, как создание нового, вера в миссию компании и продвижение по службе.
Хорошие наставники могут помочь в решении большинства основных проблем, стоящих перед разработчиками, в том числе:
Взгляните хорошенько на свою команду. Есть у кого-нибудь более чем 6-ти-летний опыт создания масштабных промышленных приложений? Чувствуют ли члены вашей команды, что у них есть надежный гид и наставник, который постоянно подталкивает их к совершенствованию своего мастерства?
Если ответы будут «нет», то вы действительно многое упускаете из виду.
Есть много причин, по которым хороших наставников трудно найти и удержать, но все начинается с управления командой. Можно многое сделать для создания гораздо более эффективной и хорошо организованной команды, к которой разработчики будут рады присоединить на долгие годы.
В Кремниевой Долине многие инженеры либо переходят в управление, либо вообще уходят. Это плохо не только для старших разработчиков. Это плохо для работодателей.
Это плохо влияет на командную культуру и настрой. Это плохо сказывается на производительности команды. И это плохо для разработчиков младшего и среднего уровня, которые лишены больших возможностей наставничества.
Если вы занимаетесь разработкой очень долго, то, возможно, чувствовали давление, заставляющее вас перейти в управление. Если вы решили, что вы хотите выбрать именно этот маршрут, эта статья поможет составить представление о том, как построить оптимальную команду и соответствующую ей культуру.
Создание хорошо сбалансированной команды является важным элементом построения высокоскоростной команды разработчиков.
Все начинается с людей
Если вы хотите создать что-то великое, то начните с великих людей. Построить команду — это нечто гораздо большее, чем просто нанять людей с нужными навыками. Это также значит найти людей, которые будут вписываться в остальную команду и балансировать ее.
Для менеджера может быть заманчиво рассматривать других членов команды, как винтики машины. Было бы удобно, если можно было бы поставить их на любую позицию и ожидать, что они будут действовать в соответствии с вашими ожиданиями для этой позиции.
К счастью для всех, настоящие команды работают не так, поэтому ваша первая задача — научиться распознавать в себе соблазн оценивать членов команды по количеству тикетов, которые они закрывают.
Самая большая ошибка, которую я наблюдал у техлидов — определение ценности отдельных членов команды по количеству закрываемых ими тикетов.
Эта ошибка является первопричиной проблемы номер один, с которой сталкиваются разработчики: Нереалистичные ожидания. Когда вы фокусируетесь на подсчете количества закрытых тикетов, вы игнорируете более широкий контекст работы над проектом и нормальную динамику команды, что может привести к катастрофическим результатам: моральной подавленности, высокой текучке разработчиков и снижению продуктивности.
На самом деле существует два различных типа разработчиков, и для достижения оптимальной производительности вашей команде нужны они оба:
Культура стартапов в районе залива Сан-Франциско старается объединить всех в группу 2. Это недальновидно и расточительно. Сейчас разберемся почему.
Давайте разберемся с парой определений:
Тем не менее «старший» — это определенно не то, что происходит за одну ночь, а шкала навыков — это широкий градиент, не что-то бинарное. Ничто не может заменить уроки, полученные за годы работы. В книге Малкольма Гладуэлла «Outliers: The Story of Success» предполагается, что правило 10_000 часов может применяться ко многим навыкам: Чтобы достичь мастерства в своем ремесле, требуется 10_000 часов практики. Это означает, что разработчику требуется около 6 лет практики, чтобы овладеть этим ремеслом. Это звучит для меня абсолютно верно.
Однако просто опыта недостаточно для обеспечения прогресса. В статье «Peak: Secrets from the New Science of Expertise» Андерс Эриксон и Роберт Пул объясняют, что практикующие специалисты должны часто заниматься осознанной практикой, при которой обучающийся постоянно работает на грани своих способностей — это та приятная точка, в которой ощущается и сложность и уверенность.
Плюс к этому, как наставник и учитель, я обнаружил много других аспектов, которые могут радикально улучшить эффективность обучения разработчиков. В частности:
Почему вашей команде нужны сильные наставники
Некоторые члены команды отличаются своими знаниями и способностями к созданию архитектуры и служат хорошим примером для остальных членов команды. Когда они вовлечены в эту деятельность, их вклад является фактором умножения эффективности, увеличивающим продуктивность всей команды.
Кроме того, эти участники могут видеть более универсальные решения общих проблем и разрабатывать инструменты, которые помогут остальной части команды быть более продуктивной. (Другие члены команды тоже смогут, но, возможно, не так часто).
Если в команде из шести человек один сотрудник является сильным наставником с коэффициентом умножения эффективности = 2, то это означает, что оставшиеся пять человек выполнят работу десяти. Возможно, вы слышали термин десятикратный разработчик. Наставничество — это самый реалистичный способ внести десятикратный вклад.
Возможно, вы думаете, что моя математика сейчас ошибочна, ведь разве другие участники не заслуживают похвалы за свой однократный вклад? Возможно, некоторые, но все не так просто. Реальное количество разработчиков, которым нужно помочь, чтобы достичь десятикратной производительности, лежит где-то между 5-10.
Давайте копнем немного глубже. Эту часть многим людям трудно понять или оценить в полной мере:
Младший или средний разработчики в состоянии закрывать тикеты. Может быть даже быстро. Однако младшему разработчику не хватает видения и опыта, чтобы понять, как тот технический выбор, который он делают сегодня, повлияет на продуктивность всей команды в будущем. Другими словами, безнадзорный младший разработчик может быть дробным фактором эффективности, что создает помехи для производительности всей команды.
Оставленные без присмотра младшие разработчики будут выпускать быстрые фиксы в общем направлении по каждой проблеме, с которой они сталкиваются, регулярно упуская первопричины, часто повторно вызывая проблемы и пожары, и оставляя после себя кучу технических долгов.
Младшие разработчики также часто борются со сложными проблемами, отвлекая для помощи других разработчиков от их работы.
Разработчики среднего уровня (как правило, с 2-5-ти-летним опытом работы. Это то, что во многих вакансиях в районе залива называется «старшими») придумают рабочие решения сложных технических вопросов, но эти решения, как правило, будут сложными сами по себе и трудными для понимания другими членами команды, что также создает нагрузку на продуктивность команды.
Опытные старшие разработчики часто придумывают обманчиво простые решения сложных проблем и учат других разработчиков делать то же самое.
Так что, не надо нанимать младших разработчиков, верно? Не верно. Младший разработчик может быть очень умным и быть очень хорошим учеником. Просто отсутствие опыта и понимания создает отрицательное сопротивление.
В среде наставничества с частым парным программированием и код-ревью, даже начинающие разработчики быстро становятся отличными участниками.
Но прием на работу младших разработчиков без привлечения к их ориентированию старших наставников — это все равно что закладывать бомбы замедленного действия по всей кодовой базе.
Настоящая опасность
Когда команда разработчиков сталкивается с проблемами производительности и большими техническими долгами, возникает соблазн обвинить в этом отдельных разработчиков.
«Этот разработчик закрывает 1/5 от тех тикетов, которые закрывает другой, так что ясно, что в этом проблема, верно?» Не верно.
Первопричиной технического долга является ориентация менеджмента на краткосрочную микропродуктивность в ущерб долгосрочной макропродуктивности. Когда вы позволяете побочному продукту накапливаться достаточно долго, в конце концов он засорит механизм.
Менеджеры часто ошибаются, думая, что скорость обработки тикетов может быть использована для оценки эффективности отдельных участников. Это просто неправда.
Люди не работают в вакууме. Они работают друг с другом. Ваши самые знающие сотрудники быстро станут теми наставниками, к которым все обращаются с вопросами, и это хорошо.
Этот наставник/старший разработчик отвечает за поддержание механизма чистым и хорошо смазанным, предотвращая засоры, которые пустят под откос всю команду.
Но старшие наставники не закрывают много своих собственных тикетов. Вместо этого они будут сосредоточены на код-ревью, разблокировке остальной части команды, когда она столкнется с новыми проблемами, и работе над оптимизацией долгосрочной продуктивности всей команды.
Дело в том, что инженерные лидеры должны понимать, что ваши самые продуктивные члены команды часто закрывают наименьшее количество тикетов.
Множители усилий в команде будут терять время (и ваше, и остальной команды), если они будут действовать как индивидуальные разработчики, пытаясь быстро закрыть свои собственные тикеты.
Вам не нужно, чтобы ваши наставники быстро закрывали тикеты. Вы не хотите, чтобы ваши наставники быстро закрывали тикеты. Последнее, что вы хотите сделать в качестве инженерного руководителя, это оказать на них давление для этого.
Вам нужно, чтобы они помогли остальным разработчикам научиться разрабатывать приложения таким образом, чтобы команда в целом поддерживала более плавную скорость.
Стартапы в Заливе правильно придают большУю ценность скорости и гибкости, но там совершенно не понимают, как построить культуру, где скорость и гибкость процветают естественным образом.
Они слишком сосредоточены на закрытии конкретных тикетов сегодня, вместо осознания того, что именно культура обучения и наставничества обеспечит долгосрочное здоровье и стабильность совокупной скорости и продуктивности команды в будущем.
Если вы хотите определить ценность старшего разработчика или наставника, вместо того чтобы смотреть на индивидуальную скорость обработки тикетов, спросите других разработчиков в команде, насколько полезен этот наставник.
Еще один отличный способ убедиться в том, что ваши наставники работают продуктивно — это посмотреть на их деятельность по код-ревью. Они должны проводить много код-ревью, полных отличных советов о том, как код может быть улучшен конкретными способами на архитектурном уровне.
Неопытный рецензент больше сосредоточен на несущественных стилистических вопросах (точки с запятой, заглавные буквы, пробелы и т. д.). Великий наставник будет обучать концепциям разработки программного обеспечения, не подверженных влиянию времени, шаблонам проектирования и тому, как писать код, который легче читать и поддерживать другим разработчикам.
Почему каждая компания хочет иметь старших разработчиков
Каждая компания хочет иметь «старших» разработчиков, потому что правильно считается, что старшие разработчики будут лучше понимать, как написать приложение, которое само по себе будет устойчивым к меняющимся требованиям заказчиков и менеджеров продуктов.
Старшие разработчики сами по себе менее склонны создавать горы технических долгов, поскольку они закрывают тикеты и большинству из них требуется меньше усилий, чтобы быстро освоиться с новой кодовой базой.
Почему мало у каких стартапов есть настоящие старшие разработчики
Стандарты того, что подразумевается под «старшим разработчиком», с годами изменились. Когда я только начинал работать профессиональным программистом, очень часто приходилось видеть вакансии на старшие позиции, требующие минимум 5, 7 или 10 лет опыта.
Сегодня в Сан-Франциско вы увидите аналогичные позиции, требующие минимальный опыт работы 2-3 года. Отчасти причина этих изменений заключается в том, что на рынке труда ощущается нехватка разработчиков, которые не только обладают требуемым опытом в годах, но и знаниями и умениями, необходимыми для выполнения этой работы.
Но вакансии все еще не закрыты. Поэтому мы нанимаем людей с чуть меньшим опытом, называем их «старшими разработчиками» и надеемся, что все получится. Не получится.
Как я уже упоминал, опыт — это еще не все, но когда речь заходит о роли старшего наставника, опыт все равно имеет большое значение. Есть вещи, которым нельзя научиться, кроме как прожив жизнь.
Между старшим разработчиком на бумаге и реально старшим разработчиком действительно большая разница. Разработчик с 3-х-летним опытом не имеет реального жизненного опыта создания нескольких промышленных масштабных приложений. Он просто не работал на достаточном количестве ролей достаточно долгое время, чтобы увидеть, как это происходит более одного или двух раз.
Это означает, что он не знает всех или даже наиболее распространенных проблем, с которыми сталкиваются команды разработчиков.
Вы можете наполнить океан теми вещами, о которых 3-х-летний разработчик даже не подозревает, что он их не знает.
Но мы все равно их нанимаем. Потому что они отлично справляются с разработкой всяких штук и исправлением ошибок, а этого почти всегда достаточно на какое-то время.
Почему большинство компаний изо всех сил пытаются удержать старших разработчиков
Как я только что объяснил, многие «старшие» таланты, нанятые в районе залива Сан-Франциско, на самом деле не являются старшими. Это менее опытные разработчики, готовые работать за гораздо меньшую зарплату, чем настоящие старшие разработчики, которые в Сан-Франциско рассчитывают заработать более 150 тысяч долларов США в год.
Трехлетний разработчик будет счастлив, зарабатывая 130 тысяч долларов США в год. Медианная зарплата разработчика в Сан-Франциско составляет чуть более 110 тысяч долларов США в год.
(Замечание для неместных: это выглядит как будто много, но в Сан-Франциско вы не разгуляетесь после того, как заплатите аренду за жилье).
Многие технические основатели в районе залива сами молоды. Когда вы молоды и свободны от привязанностей, вы можете позволить себе делить квартиру с четырьмя соседями по комнате и приносить домой небольшую зарплату, пока вы бегаете в поисках финансирования и пытаетесь нанять других людей.
Молодому основателю может показаться безумным нанять «недосягаемого» разработчика за ту же цену, которую он заплатит за двух менее опытных «старших» разработчиков, а для CEO может показаться возмутительным платить старшему разработчику больше, чем он сам будет приносить домой. Молодые стартапы обычно рассматривают зарплату настоящего старшего разработчика как «дорогую».
По иронии судьбы, что действительно дорого, так это управлять командой без хороших наставников. Наставники повышают ROI (рентабельность инвестиций) всей вашей команды разработчиков.
Корпоративная культура компаний Сан-Франциско часто ориентирована на молодых работников, включая изнурительный режим и частые мероприятия во внерабочее время, такие как вечеринки, ужины, выпивания, вечерние викторины, турниры по пинг-понгу и барбекю. Сотрудники с семьями часто не чувствуют себя частью компании, когда они решают вернуться домой к семьям вместо того, чтобы посещать такие мероприятия.
Работа в молодом стартапе — не единственный вариант для старших разработчиков. Опытные компании, такие как Adobe, Google, IBM и Microsoft, ценят таланты старших разработчиков и готовы платить за это премии.
Google, как известно, заманивает разработчиков успешных приложений компенсациями в миллионы долларов.
Microsoft признает, что ей нужны как старшие, так и младшие разработчики и агрессивно набирает и тех и других.
Некоторые старшие разработчики разочаровываются в рынке труда района залива и уходят оттуда, предпочитая создавать собственные приложения или небольшие агентства по разработке программного обеспечения.
Другие просто недоумевают, почему стартапы в Долине их недооценивают и изо всех сил пытаются найти работу.
Почему каждой компании нужны младшие разработчики
Когда вы относитесь к каждому разработчику, как к старшему разработчику, которому вы можете доверять в условиях его полной самостоятельности, в итоге вы получаете команду, в которой сотрудники не могут учиться друг у друга и расти совместно в навыках и производительности.
Когда вы нанимаете младших разработчиков, вы воспринимаете как должное, что нужно создавать культуру обучения, чтобы была возможность развивать младших разработчиков и распределять опыт по всей команде.
Эта культура увеличивает объем парного программирования, ведет к более тщательному и продуктивному код-ревью (в отличие от тривиальной придирки к мелочам) и гораздо меньшему изолированию знаний.
Когда члены команды часто занимаются обучением друг друга, это убирает из головы их индивидуальную работу, что дает лучшее представление о том, как их работа вписывается в более широкий контекст приложения.
Одна из больших проблем, с которыми сталкиваются команды разработчиков, заключается в том, что индивидуальные разработчики, как правило, специализируются на небольшой области приложения (что приводит к повышению продуктивности, когда они работают в этой области). Но они делают это ценой снижения продуктивности, когда другие члены команды пытаются работать над этой частью приложения.
Помимо этих преимуществ, команды нуждаются в младших разработчиках, потому что никто не сообщил младшему разработчику, что существует что-то невозможное. Они возьмутся за невозможное и иногда смогут найти решение, и они не завязнут со словами «мы всегда так делали.»
Возможно, самая важная причина для найма младших разработчиков заключается в том, что трудно найти старших разработчиков, которые действительно знают, что они делают. Охота за хорошим старшим разработчиком может занять много месяцев и важно сбалансировать затраты на переезд сейчас по сравнению с переездом через шесть месяцев.
Заключение
Почему так трудно найти хороших старших разработчиков?
Потому что мы не поощряем достаточно младших разработчиков в системе. То, что мы делаем сейчас, неприемлемо в долгосрочной перспективе.
Если все нанимают только старших разработчиков, то откуда берутся новые старшие разработчики?
И если не ценить настоящих старших разработчиков, кто будет наставлять новобранцев? Как мы передадим глубокие знания следующему поколению?