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

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

Ниже — качества, которые нужно развивать новичку, чтобы быстрее втянуться в команду и понять, что происходит.

Дисклеймер. Есть много точек зрения и материалов на эту тему. Это просто еще одно мнение — помощь на старте карьеры. 

Вникайте в мотивацию коллег 

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

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

Задача дизайнера — объяснить. Например, есть исследование, что кнопка в центре удобнее для пользователя и увеличивает переходы. Это аргумент, поймите и сделайте. Если не объясняет — спросите. И помните, что для коллег кнопка — не набор символов, а цветной квадрат с текстом.

Заказчики и так должны ставить нормальные ТЗ и всё объяснять.

???? В идеальном мире все ставят понятные ТЗ, но мы в нем не живем.

Учитесь работать в команде 

Представьте, что команда разработчиков — это «Биг Тейсти». Только смесь ингредиентов дает тот вкус и текстуру, которые вы чувствуете во рту. Сами по себе котлетка, огурцы, лист салата, булки и сыр — хороши, но они не работают по отдельности. Если убрать котлету или заменить булку — это уже не «Биг Тейсти».

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

Никто не развивается в одиночку. Роняет и поднимает не разработчик, а команда.

Мне не нужно развитие, я не люблю людей и разберусь самостоятельно.

???? Это путь к усталости и разочарованию. Рано или поздно наступит момент, когда знаний не хватит, понадобится совет, а идти будет некуда.

Интересуйтесь другими сферами

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

Например: 

Если фронтенд-разработчик разбирается в 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)


  1. uss
    01.11.2021 19:11
    +1

    материал из разряда пропаганды "теории малых дел"

    почему не заданы вопросы:

    почему компания хочет команду но никогда не закладывает ресурсов на построение этой самой команды?

    почему компания не ограждает исполнителей от заказчиков без внятного тз?

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

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

    все считают что построение культуры командной работы это побочный эффект работы...нет это тоже работа и на неё нужно тратить временные ресурсы


    1. anpetrova Автор
      02.11.2021 13:34

      Этот материал скорее про отношения человек-человек, а не бизнес-человек.

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


  1. anonymous
    00.00.0000 00:00


    1. vya
      01.11.2021 22:28
      -2

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


  1. anonymous
    00.00.0000 00:00


  1. bungu
    01.11.2021 22:01
    +7

    Советы от эффективных менеджеров как нам выполнять хорошо свою работу?


  1. 32bit_me
    01.11.2021 23:13

    Волки из пацанских пабликов. Докатились.


    1. vadimszzz
      02.11.2021 04:46

      Это постироничный флекс

      Мне понравился, угарнул с картинки


    1. tempick
      02.11.2021 07:34
      +1

      Это ж постирония) (правда, уже баянистая)
      image


  1. S-type
    02.11.2021 01:45
    +2

    Никому не сказать, закрыть задачу, потому что нет времени что-то исправлять. 

    С одной стороны, за такое надо просто увольнять. С другой - если система настроена правильно, то к задаче (заявке, тикету - в разных системах разное название), должен подвязаться твой PullRequest. Или, нет PullRequest-а - нельзя задачу закрыть. Как то так.

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

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


    P.S. Дальше читать уже сил не было, оценка -6 сама за себя говорит


    1. anpetrova Автор
      02.11.2021 12:16
      +1

      Что то ни разу не видел, что бы дизайнер, HR, бухгалтер или вообще кто поинтересовались - как устроена работа у программистов. 

      Согласна, вопрос работает в обе стороны. Это задача для статей на других ресурсах для дизайнеров, эйчаров и программистов)

      Спасибо за мнение!


  1. ivlad
    02.11.2021 04:03
    +1

    У меня не так много опыта, но думаю, что …  

    Лучше промолчать.

    Лучше выкатить … после …, потому что однажды одна компания сделала наоборот — и всё упало.

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


  1. shmidt_i
    02.11.2021 12:08

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


  1. saboteur_kiev
    02.11.2021 12:38
    +1

    Плохо

    Я знаю, что так будет лучше. Я читал в учебнике.

    Хорошо

    Лучше выкатить … после …, потому что однажды одна компания сделала наоборот — и всё упало. То, что вы предлагаете, проще и быстрее, но, мне кажется, мы рискуем.

    Тут обе вещи плохо. Если однажды компания сделала наоборот и все упало, то дело может быть не в идее, а в реализации. А в учебниках может быть описана world best practice, просто опять таки реализовывать ее надо с пониманием.

    Во-вторых почти все проблемы указанные в статье, особенно касающиеся замалчивания - относятся не к разработчикам, а к менеджерам младшего и среднего звена. А то и старшего. Я не помню, чтобы разработчики о чем-то умалчивали. Наоборот регулярно доносят наверх о существующих технических проблемах и накапливающемся техническом долге, из-за которого повышаются риски багов. Но менеджеру нужно отчитаться заказчику о выполненных бизнес-задачах, поэтому все техническое замалчивается и заметывается под коврик. Но это делают МЕНЕДЖЕРЫ, а не разработчики.

    капасити на технические задачи могут выделить только менеджеры

    капасити на курирование джунов могут выделить только менеджеры

    капасити на правильный code-review могут выделить только менеджеры

    проактивность без капасити невозможна, проактивность без поддержки со стороны менеджеров невозможна. Я работал в проекте, где за проактивность могли дать премию, если она проходила определенный этап ревью. За год от нашей команды было подано около 400 идей, из которых за 18 получили премию. А без этого, откуда взяться проактивности?

    Разработчик - имеет очень мало прав. В одной компании у нас в коридоре был турник, и мы почти всей командой разработчиков на нем регулярно занимались. Потом в компании случились перестановки, мы переехали в другой блок здания, где не было турника. Мы просили компанию организовать (стоимость такого турника ничтожна, мы его и сами бы купили и сами бы установили), но компания не позволяла. Нас было 12 человек разработчиков, проактивных. И только через пол года активных переговоров и переписок нам позволили организовать турник. Купили stand-alone, поставили прямо в кабинете.

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

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


    1. anpetrova Автор
      02.11.2021 13:23
      -1

      Спасибо за историю! Это негативный, но крутой реалистичный кейс. Компании и правда разные, руководство бывает разное.

      Сохранила ваш комментарий, чтобы пофиксить ошибки в будущих материалах.


  1. panzerfaust
    02.11.2021 13:35
    +2

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

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


    1. anpetrova Автор
      02.11.2021 13:40

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

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