Один разработчик-гений выучил все языки программирования, прочитал все книги по разработке и находил идеальные технические решения. Но нигде не задерживался надолго, потому что никто не хотел с ним работать. Этот гений умел общаться с компьютером, а с людьми — нет.
Можно как угодно хорошо разбираться в технической части профессии, но разработчик не просто пишет код. Он работает в команде и решает задачи бизнеса. Если он этого не умеет — вряд ли приживется.
Ниже — качества, которые нужно развивать новичку, чтобы быстрее втянуться в команду и понять, что происходит.
Дисклеймер. Есть много точек зрения и материалов на эту тему. Это просто еще одно мнение — помощь на старте карьеры.
Вникайте в мотивацию коллег
Маркетологи мыслят продажами и скоростью, дизайнеры — красотой и удобством, менеджеры продукта — ценностью и пользой. Разработчики подбирают лучшее техническое решение, которое не всегда в пользу скорости. Все решают свои задачи. Смотрят на одно и то же, а видят разное.
Поэтому в каждом отделе часто ворчат и не понимают, почему задача зависает надолго. Дизайнеры не знают, как устроен сайт, и ставят задачу «подвинуть кнопку в центр на всех страницах приложения». Разработчик не понимает причин и думает, что дизайнеру нечем заняться.
Задача дизайнера — объяснить. Например, есть исследование, что кнопка в центре удобнее для пользователя и увеличивает переходы. Это аргумент, поймите и сделайте. Если не объясняет — спросите. И помните, что для коллег кнопка — не набор символов, а цветной квадрат с текстом.
❓Заказчики и так должны ставить нормальные ТЗ и всё объяснять.
???? В идеальном мире все ставят понятные ТЗ, но мы в нем не живем.
Учитесь работать в команде
Представьте, что команда разработчиков — это «Биг Тейсти». Только смесь ингредиентов дает тот вкус и текстуру, которые вы чувствуете во рту. Сами по себе котлетка, огурцы, лист салата, булки и сыр — хороши, но они не работают по отдельности. Если убрать котлету или заменить булку — это уже не «Биг Тейсти».
Каждый разработчик — уникальный, сильный и умный специалист. Но крутые продукты делает вся команда. Каждый несет ответственность за свою работу и прогресс других. Команда растет, когда коллеги делятся опытом, вместе находят решения сложных проблем, подхватывают задачи друг друга, поднимают, когда всё упало.
Никто не развивается в одиночку. Роняет и поднимает не разработчик, а команда.
❓Мне не нужно развитие, я не люблю людей и разберусь самостоятельно.
???? Это путь к усталости и разочарованию. Рано или поздно наступит момент, когда знаний не хватит, понадобится совет, а идти будет некуда.
Интересуйтесь другими сферами
Быть спецом своего направления — круто. Но больше ценят тех, кто интересуется другими сферами и разбирается в них. Это помогает, когда надо договориться с коллегами и понять, что от вас хотят.
Например:
Если фронтенд-разработчик разбирается в UX-дизайне, то сам спроектирует простую страницу: это быстро. Или исправит ошибку в макете сразу на верстке, без участия дизайнера.
И наоборот. Если дизайнер понимает разработку, то не сделает страницу с разными отступами. Сразу нарисует так, чтобы разработчику не пришлось подгонять макет и исправлять значения.
Фронтендеру пригодятся основы бэкенда, а бэкендеру — основы фронтенда. Чтобы смотреть на продукт целиком и предугадывать ошибки. Это ускоряет коммуникацию отделов в разы.
Лера Павлова
CRM-маркетолог
Раз в полгода мы запускали однотипные акции на сайте и настраивали отдельные системные письма под каждый этап. Приветственное письмо всегда было одинаковое, отличались только дизайн и внутреннее название события в CRM. Помню, разработчик на одну акцию сам создал событие и выделил слот под письмо в воронке, хотя я еще не успела поставить задачу. Было приятно, что он подумал обо мне и запомнил, что мы всегда делаем такие письма.
❓Зачем мне лезть в чужую сферу? На это есть свои специалисты.
???? Верно. Никто не заставляет углубляться в виды дизайна или учить другие языки разработки. Но пригодится знать, как устроена работа коллег в соседних командах: это сэкономит время на переговорах.
Учитесь спорить
Споры в любой команде — норма. Каждый разработчик найдет несколько решений для одной задачи. Если вы видите, что команда идет не туда, и уверены в своей версии — убеждайте.
Помните: каждый в споре считает, что прав.
❌ Плохо |
✅ Хорошо |
Я знаю, что так будет лучше. Я читал в учебнике. |
Лучше выкатить … после …, потому что однажды одна компания сделала наоборот — и всё упало. То, что вы предлагаете, проще и быстрее, но, мне кажется, мы рискуем. |
Это плохая идея. |
Думаю, эта идея не сработает, потому что … |
(молчать) |
У меня не так много опыта, но думаю, что … |
Не бойтесь говорить свое мнение. В обсуждениях рождаются лучшие решения.
❓Старшие больше знают. Я не буду лезть туда, куда не просят: я интроверт.
???? За «неправильную» идею вас не побьют, в идеале — объяснят, почему вы неправы. В худшем случае — проигнорируют. Новички со свежим взглядом часто предлагают нестандартные идеи, а опытные коллеги докручивают до реального решения.
Признавайте ошибки
И берите за них ответственность. Признаетесь сразу — вас не уволят, а помогут. Разгребут последствия, разберутся, что пошло не так, и скажут, что так делать не надо. (Если вы в стабильной компании и в окружении адекватных людей.)
Ваша задача — запомнить и сделать выводы.
Дольше молчите — больше последствий. Небольшой косяк превратится в большую проблему, и вот тогда кого-то уволят. Не бывает людей, которые не ошибаются. Если вам говорят, что есть, — врут.
Допустим, была задача: передавать телефоны клиентов с сайта в базу данных. Настроили и перед запуском увидели, что они передаются неправильно: обрезается последний символ. Сегодня — день дедлайна, а завтра утром — старт продаж на сайте.
❌ Как не надо |
✅ Как надо |
Никому не сказать, закрыть задачу, потому что нет времени что-то исправлять. Итог: фиаско. Компания потратила много денег, собрала контакты клиентов, но не может ничего с ними сделать: не хватает последней цифры. Все потеряли деньги. |
Предупредить коллег о баге, сказать, что ошиблись. Объяснить критичность. Предложить решение. Оценить сроки. Если не успеваете — сдвинуть запуск. Итог: сайт запустится позже, но без ошибок. Есть контакты клиентов — есть продажи. |
❓Все компании говорят, что адекватные и хорошо относятся к ошибкам. На деле — штрафуют, наказывают, увольняют. Все врут.
???? Да, вас могут наказать. Если ошибка крупная или вышла за пределы компании — например, о ней написали в СМИ. Или если ошиблись не первый раз. В остальном — поговорите с коллегами и спросите, как на самом деле компания относится к проступкам. Узнаете, чего ждать.
Учитесь самостоятельности
Но не забывайте, что работаете в команде, да.
Если сидеть и ждать, когда в руки прилетит задача или тимлид придет и решит проблему, — не выйдет ничего хорошего. Со временем накопится обида, что о вас забыли и никто не помогает. А у команды появятся вопросы, можно ли доверять вам важные задачи, если не можете разобраться с простыми трудностями.
Проактивность часто указывают в вакансиях — это важно не только работодателю. Сидеть на одном месте и заниматься рутиной надоедает. Предлагайте идеи, решайте проблемы, задавайте вопросы, приходите к ответственным людям сами, учитесь — и увидите прогресс. Это сложно, но самостоятельность развивает.
Глеб Фокин
разработчик в Skypro
В Skypro мы называем это «самоходность». Когда человек не ждет, когда кто-то разблокирует его проблему и решит. А когда он напоминает о своих задачах, находит ответы сам, ходит к старшим коллегам и доводит до конца
❓Новичков разве не водят за ручку и не курируют на старте?
???? Да, в хороших компаниях новичков не бросают: всегда помогают и адаптируют в команде. Но дальше сотрудник сам учится и решает проблемы. Если он не хочет — ничего не получится.
Следите за новинками
Полезно знать, чем живет мир, и поглядывать в будущее. Тем более всё слишком быстро меняется прямо сейчас. Окружите себя профильными каналами или подкастами. Изучайте, что происходит не только в разработке и вашей сфере, а в технологиях в целом.
Несколько советов от опытных разработчиков:
Глеб Фокин
разработчик в Skypro
Я читаю твиттер интересных мне людей. Нахожу их по стандартному сценарию: послушал доклад с конференции, понравился — подписался на спикера.
Читаю еженедельные имейл-рассылки. Например, javascriptweekly.com — статьи, новости и интересные кейсы по JavaScript.
Или softwareleadweekly.com — про управление командами разработки и внутренние процессы. Полезно и руководителям, и новичкам, чтобы понять, как работают команды
Сергей Иванов
бэкенд-разработчик в Skypro
Слежу за Ycombinator. Они 15 лет инвестируют в небольшие стартапы.
На специальной странице собирают ссылки на свежие новости и технические материалы других изданий.Слушаю подкасты на radio-t.com — там про хай-тек, гаджеты, программирование и весь мир IT. Выходит каждую неделю.
Слежу за каналом @addmeto в телеграме. Его ведет Григорий Бакунов — директор по распространению технологий «Яндекса». Он мониторит новости из мира IT и технологий, самое свежее публикует в канал.
Дмитрий Денисов
разработчик в Skypro
Слушаю подкаст «АйТиБорода» — он не про программирование, а скорее про жизнь специалистов в IT.
Читаю издание «Типичный программист» — пишут о разработке и создают базу знаний для айтишников. Все материалы есть на сайте, а следить за новинками удобно в телеграме @tproger_official.
Что в итоге
Возможно, вы не узнали ничего нового и скажете, что эти истины понятные. Или вообще не важные. Новичкам бывает сложно влиться и понять, что происходит в команде и чего от них хотят. Потому что такое не пишут в текстах вакансий и вряд ли рассказывают на собеседовании.
Закрепим основное:
Развивайтесь не только в своей сфере.
Помните, что работаете в команде.
Но будьте самостоятельными.
Признавайте свои ошибки и берите ответственность.
Не бойтесь спорить.
Следите за новинками своего направления.
Комментарии (18)
anonymous
00.00.0000 00:00vya
01.11.2021 22:28-2Ну если у разработчиков есть в этом бизнесе доля сообразная вкладываемым в бизнес ресурсам, то делать на благо бизнеса - вполне рабочая схема. А если "взбивайте общие сливки, нам масло, вам сыворотка", то идея "чуть-чуть вредить", становится всё более привлекательной со временем.
S-type
02.11.2021 01:45+2Никому не сказать, закрыть задачу, потому что нет времени что-то исправлять.
С одной стороны, за такое надо просто увольнять. С другой - если система настроена правильно, то к задаче (заявке, тикету - в разных системах разное название), должен подвязаться твой PullRequest. Или, нет PullRequest-а - нельзя задачу закрыть. Как то так.
Верно. Никто не заставляет углубляться в виды дизайна или учить другие языки разработки. Но пригодится знать, как устроена работа коллег в соседних командах: это сэкономит время на переговорах.
Что то ни разу не видел, что бы дизайнер, HR, бухгалтер или вообще кто поинтересовались - как устроена работа у программистов. В основном всё общение происходит на совещаниях. Например, недавно дизайнер хотел изменить окно в браузере, которое отвечает за авторизацию в домене.
P.S. Дальше читать уже сил не было, оценка -6 сама за себя говоритanpetrova Автор
02.11.2021 12:16+1Что то ни разу не видел, что бы дизайнер, HR, бухгалтер или вообще кто поинтересовались - как устроена работа у программистов.
Согласна, вопрос работает в обе стороны. Это задача для статей на других ресурсах для дизайнеров, эйчаров и программистов)
Спасибо за мнение!
ivlad
02.11.2021 04:03+1У меня не так много опыта, но думаю, что …
Лучше промолчать.
Лучше выкатить … после …, потому что однажды одна компания сделала наоборот — и всё упало.
Ссылаться на абстрактный опыт абстрактной другой компании - куда хуже, чем на учебник. Потому, что от учебника можно ожидать обоснованного мнения с границами применимости и причинами, а опыт другой компании в такой постановке - это анекдот.
shmidt_i
02.11.2021 12:08Очень правильные мысли в статье, очень жаль коллег которые с такими комментариями приходят.
saboteur_kiev
02.11.2021 12:38+1❌ Плохо
Я знаю, что так будет лучше. Я читал в учебнике.
✅ Хорошо
Лучше выкатить … после …, потому что однажды одна компания сделала наоборот — и всё упало. То, что вы предлагаете, проще и быстрее, но, мне кажется, мы рискуем.
Тут обе вещи плохо. Если однажды компания сделала наоборот и все упало, то дело может быть не в идее, а в реализации. А в учебниках может быть описана world best practice, просто опять таки реализовывать ее надо с пониманием.
Во-вторых почти все проблемы указанные в статье, особенно касающиеся замалчивания - относятся не к разработчикам, а к менеджерам младшего и среднего звена. А то и старшего. Я не помню, чтобы разработчики о чем-то умалчивали. Наоборот регулярно доносят наверх о существующих технических проблемах и накапливающемся техническом долге, из-за которого повышаются риски багов. Но менеджеру нужно отчитаться заказчику о выполненных бизнес-задачах, поэтому все техническое замалчивается и заметывается под коврик. Но это делают МЕНЕДЖЕРЫ, а не разработчики.
капасити на технические задачи могут выделить только менеджеры
капасити на курирование джунов могут выделить только менеджеры
капасити на правильный code-review могут выделить только менеджеры
проактивность без капасити невозможна, проактивность без поддержки со стороны менеджеров невозможна. Я работал в проекте, где за проактивность могли дать премию, если она проходила определенный этап ревью. За год от нашей команды было подано около 400 идей, из которых за 18 получили премию. А без этого, откуда взяться проактивности?
Разработчик - имеет очень мало прав. В одной компании у нас в коридоре был турник, и мы почти всей командой разработчиков на нем регулярно занимались. Потом в компании случились перестановки, мы переехали в другой блок здания, где не было турника. Мы просили компанию организовать (стоимость такого турника ничтожна, мы его и сами бы купили и сами бы установили), но компания не позволяла. Нас было 12 человек разработчиков, проактивных. И только через пол года активных переговоров и переписок нам позволили организовать турник. Купили stand-alone, поставили прямо в кабинете.
И это еще про-активность, которая была очень мотивирована, еще и поддерживалась дайрект менеджером, но рубилась чуть выше, и совершенно не понятно почему рубилась - никому от этого не было бы плохо.
В общем все эти советы давать разработчикам бессмысленно. Просто читаешь как сказочку о том, как в какой-то волшебной компании есть волшебные менеджеры, и тогда все это заработает и без этих советов.
anpetrova Автор
02.11.2021 13:23-1Спасибо за историю! Это негативный, но крутой реалистичный кейс. Компании и правда разные, руководство бывает разное.
Сохранила ваш комментарий, чтобы пофиксить ошибки в будущих материалах.
panzerfaust
02.11.2021 13:35+2В статье можно заменить "разработчик" на любую другую роль в команде - и общий посыл ни на йоту не изменится. Потому что должна быть синергия и взаимопроникновение опыта. Что бывает редко.
Но я не вижу статей вроде "как стать отличным аналитиком и начать писать ТЗ, а не филькины грамоты". Вместо этого зачастили статьи, где учат жить разрабов, причем довольно топорно.
anpetrova Автор
02.11.2021 13:40Выходить за рамки настолько, чтобы полноценно заменять функции коллег — не круто, согласна. Тут уже задача бизнеса — оградить сотрудников от этого. Или задача сотрудника — отстоять свои границы или найти новое место.
Знания помогают только говорить на одном языке и понимать, что от тебя требуют. Но каждый должен заниматься своей работой.
uss
материал из разряда пропаганды "теории малых дел"
почему не заданы вопросы:
почему компания хочет команду но никогда не закладывает ресурсов на построение этой самой команды?
почему компания не ограждает исполнителей от заказчиков без внятного тз?
почему компании говорят о важности общения в команде но тут же забывают о солидарности внутри этой команды относительно харасмента, увольнения?
рыба гниёт с головы, чистят её с хвоста...проблема команд лежит на 99% в рамках требований тех, кто платит зарплату и эти требования как раз и мешают разработчикам создавать нормальные команды но вопрос в статье рассматривается сугубо с "хвоста"
все считают что построение культуры командной работы это побочный эффект работы...нет это тоже работа и на неё нужно тратить временные ресурсы
anpetrova Автор
Этот материал скорее про отношения человек-человек, а не бизнес-человек.
То, о чем вы пишете — тезисы для отдельной статьи. Про то, почему компания должна следить за климатом в команде, где ошибается бизнес, почему не выделяет ресурсы на выстраивание командных процессов и к каким проблемам это приводит. И это хорошая идея, спасибо вам за критику)