Как и обещал в предыдущей статье, разворачиваем ситуацию в противоположную сторону. Мне довелось побыть не только разработчиком, но и руководителем разных уровней. Я уже упоминал, что в последнее время мне везет на команды и коллег. Но за все время работы бывало всякое.
(Григорий Остер)
Поговорим о том, о каких разработчиках мечтает руководство. В этот раз я выступлю в роли абстрактного управленца…
Знали ли вы, что высшее искусство управленца — принимать решения при минимальной начальной информации. Не мешайте нам, руководителям, тренировать этот скилл. Придерживайтесь следующей тактики:
Если на этапе постановки задачи вас допустили до клиента, чтобы задать ему уточняющие вопросы, учитесь у DDoS-атак — выкладывайтесь на полную. Клиент ждет от вас не менее 50 сообщений с вопросами, желательно по мелочам — он оценит ваше выступление в эпистолярном жанре. Никаких скриншотов или видео прикладывать не нужно — пусть расшифровывают ваше послание, даже если оно содержит только “Здравствуйте!” и долгое “typing...”.
Помните: клиент и конечный пользователь — разные люди. Никогда не общайтесь с конечными пользователями и не пытайтесь себе их представить! Если тетя Маша на кассе должна видеть 25 строк текста на мониторе, спокойно размещайте их без оглядки на диагональ экрана. Пускай лупу возьмет, если ей не нравится.
Никогда не рассказывайте нам о том, какие конкретно задачи будут решены в рамках проекта. Говорите только о методах решения. И желательно во всех подробностях — как иначе CTO будет спокойно спать этой ночью?
В своем рассказе ни в коем случае не упоминайте деньги, время или другие понятные окружающим метрики. Ведь даже секретарша директора может перевести рассказы об используемых абстрактных структурах в пользовательские сценарии и точную сумму прибыли, которую мы получим. Так что при оценке задач используйте наиболее абстрактную систему величин. Помните, 1 удав — это 38 попугаев!
Заготовьте как можно больше сюрпризов. Пусть кроме времени для решения задачи потребуются еще и платные подписки или инструменты, о которых мы не будем знать до последнего момента. Подводные камни мы любим и с радостью потом будем искать выход из тупика перед релизом. Мы с клиентом обожаем повышать выделенный бюджет еженедельно, постоянно согласовывая его через все инстанции. Прогоняйте Ивана-Царевича через новую итерацию с начала сказки после каждого обновления информации о том, где хранится смерть Кощеева.
Стремитесь писать только идеальный код ради идеального кода. Необязательно это делать с первого раза. Если спешите, пишите быстрым способом, потом переделайте и потом снова. Помните: повторение — мать учения. Если код переписан трижды и хоть немного отличается от идеала, срочно начните рефакторинг в рамках небольшой задачи, которая к этому не относится. А еще лучше переведите свой код на другую библиотеку или фреймворк. Пусть код будет модным и молодежным. Главное все эти процессы ни в коем случае нельзя формулировать в виде отдельных задач. А то вдруг мы догадаемся, что на проекте что-то оказалось не идеальным? Подобные вещи лучше всего делать непосредственно перед релизом. В этот момент вся команда работает намного быстрее!
К слову о рефакторинге. Он пойдет эффективнее, если попутно изменить механизмы в коде — чтобы два раза туда не лазить. Помните, такие процессы должны затрагивать как можно больше компонентов одновременно. Зачем тратить время на ковыряние в отдельных модулях? Только так вы в итоге будете выглядеть героем, который всех спас! Другие разработчики с радостью обнаружат сюрпризы новых механизмов, когда те прострелят им ногу.
Идеальный код должен быть правильно оформлен. Старайтесь создавать файлы максимального объема, занимающие множество экранов и содержащие в себе сразу несколько компонент. Следуя этому стилю оформления, вы сможете героически преодолевать мерж-конфликты и долго договариваться с коллегами, чьи правки были важнее. Код должен напоминать максимально длинную лапшу, не надо тратить время на создание мелких незначительных файлов. Ради одной функции придумывать название файла — что может быть мучительнее?
Созданный вами идеальный код совершенно не обязательно покрывать тестами. Можно разве что поговорить о необходимости доведения покрытия до 100%, а в реальности достаточно и 10%. Чтобы от вас отстали, добавьте пару тестов, которые по факту ничего не проверяют, их тогда и актуализировать не придется.
Если вдруг оказалось, что быстро написанное решение не работает или работает не так, как ожидалось, смело обвиняйте во всем архитектора системы, API, администратора сервера и т.п. Понятно же, что ваш идеальный код не может не работать. Запомните главное: мы так же, как и вы, знаем, что идеальный программист может работать только в вакууме в идеальных условиях. И если вас отвлекают, вовремя не дают информацию, пишут непонятные ТЗ, то вы вообще не можете отвечать за то, что реализованный модуль не выполняет бизнес-задачу. Ну и правильно, бизнес — это наша обязанность. Желательно все имена виновных факторов придержать до дедлайна, они позже понадобятся, сейчас не отвлекайте руководителей.
Когда мы говорим о необходимости быстро выпустить MVP, смело игнорируйте наши попытки ускорить проект в ущерб качеству и быстродействию. Все же знают, что с хорошей идеей стартовать на рынке можно в любой момент. Время не играет никакой роли. Пусть конкуренты говнокодят, а когда вы напишете идеальный код, наше MVP взлетит и через 5 лет. И все эти годы инвесторы будут с радостью платить за то, что на их деньги создается шедевр.
Ваша задача — это ваша индивидуальность. Творческий беспорядок добавит вам веса в наших глазах. Умение построить беспорядок и поддерживать его в достаточно хаотическом состоянии настолько ценно, что мы даже передаем проекты из рук в руки, чтобы повысить градус беспорядка. Как только хаос достигнет максимума, мы вознаградим вас новым проектом!
Если вы поняли, что на проекте образовался полноценный бардак, но вас до сих пор не переместили, или начните закапывать свои технические долги лапками, или попроситесь на другой проект сами. Возможно, мы просто не отследили ситуацию.
Все, что происходит внутри команды, должно проходить через нас. Даже если вы решили выйти покурить с тестировщиком, обязательно договоритесь с ним через менеджера проекта, а лучше привлечь к этому и CTO. Мы чувствуем себя ненужными, если нам никто не жалуется на коллег, не обращается, чтобы решить споры внутри рабочей группы или ввести какие-то правила работы.
По проектным вопросам желательно нам писать только в личку. Это скроет все следы нашей активности от вышестоящего руководства, а заодно заставит потом пересказывать выработанные решения другим участникам процесса. Мы же это так любим!
Как только вы решили задачу или исправили баг, ни в коем случае не проверяйте свое решение. Кричите “Ура” и убегайте от рабочего места как можно быстрее и дальше! Так вы и задачу быстрее сдадите и найдете команде занятие на первую половину следующего спринта — будете исправлять косяки только что сданной задачи. Что важно, вы также не лишите работы своих коллег тестировщиков. Комплект багов, вызванных новым костылем в решении, — лучший подарок к вечеру пятницы! Проверяйте в своем коде только один успешный случай, вы же оптимист.
Правильная последовательность действий при решении задачи:
Никакого рефакторинга по свежим следам, никакого причесывания кода. Пусть переменные называются так, как захотела ваша левая нога в момент прозрения, а код остается плохо читаем. Не вам же в этом разбираться потом! Ну и приучите принимать ваш код на ревью сразу — вы же хороший, но обидчивый парень.
На этом этапе нельзя создавать никаких подтверждений того, что задача выполнена (а то придумают порой на проекте видео записывать, как запускается модуль…). Авось тестировщик и не заметит расхождений с ТЗ или же на доделки задача отправится другому, а вы пока сможете отдохнуть на новой задаче.
Если в задаче встречаются неоднозначные моменты, например неизвестно, должно ли поле ввода принимать только английские или заодно и русские буквы, смело отвечайте на вопросы самостоятельно, в соответствии со своими вкусами и жизненным опытом. Раз в ТЗ не написано, значит, это должно быть очевидно каждому!
И никогда не проверяйте никаких гипотез на маленькой части задачи, а то коллеги подумают, что вы испытываете сомнения!
Если вы торопитесь с задачей к релизу и понимаете, что какой-то функционал необходимо будет доделать потом, не надо тратить время на то, чтобы поставить задачу в системе управления проектом. Лучше сделайте пометку прямо в комментариях к коду и никому о ней не сообщайте. Так будет даже интереснее отлавливать технические долги. Будет ощущение, что их много и вы все еще очень нужны на проекте.
Держите в репозитории проекта не более половины файлов! Не зря в мире изобретено столько разных мест хранения. Остальные файлы важно разместить равномерно между личными репозиториями сотрудников и, к примеру, документацией (даже не обязательно к текущему проекту). Так “тайное знание” о проекте окажется разделено поровну в команде и все будут незаменимы. А то придет еще какой-нибудь новичок в проект да разберется быстренько в уже реализованном. Эдак вы на своих местах не удержитесь — всех моментально заменят на более дешевых джунов.
В каждом проекте должны быть тайные знания, которые передаются из уст в уста. Только так вы можете картинно вздохнуть и, сплюнув, сказать: “Ох уж эти джуны, уже неделю работают, а ничего не смыслят в проекте. Отойдите, сделаю сам!”
Если вы взялись выполнять какую-то задачу из Jira, совершенно не обязательно это отмечать. Мы же медиумы — и сами догадаемся, чем вы сейчас занимаетесь, а заодно нагадаем и актуальное состояние проекта. Кстати, мы так можем сделать и с потраченным временем — не надо ничего нигде записывать, мы сами выясним количество отработанных часов и рассчитаем вам зарплату.
Слышали про омниканальность? Общение без разделения на разные каналы — последний тренд. Будьте в тренде! По любым вопросам пишите ПМ в какой-нибудь мессенджер, лучше личный, а не рабочий — чтобы он знал, что вы не отстаете от последних веяний этого мира. А вот проектные группы в Slack и других мессенджерах лучше использовать для рассылки смешных картинок с котиками и личных переговоров.
На регулярные митинги являйтесь с опозданием 15-20 минут. А ещё лучше иметь микрофон советских времён и вайфай подальше от рабочего места. Пусть все слушают ваше кваканье, оно как абстрактные картины — каждый слышит то, что хочет услышать. Причем на дейли можно задать все вопросы, которые есть у вас по проекту. Если не хватает проектных проблем, добавьте больше оффтопика. На худой конец всегда можно спросить что-то абстрактное. Такой наглядный пример лучше всего отразит, почему вы не любите созвоны и почему вам лучше на них не являться.
Ну и не забывайте, у каждого человека есть скоростной bluetooth в голове. Поэтому если вы уже представили все в голове, то достаточно передать эту картинку. Словами можно объяснить лишь мелкие детали, которых на картинке было не видно. Пусть пытаются понять вас, это их работа.
Кстати, опаздывать стоит и в офис, если вы работаете на нашей территории. Только так можно создать впечатление вашей важности. И никогда не предупреждайте об опозданиях. Это покажет, что вы все-таки торопились, т.е. испортит ваш имидж невозмутимого гуру.
Если вы уходите с рабочего места, не нужно утруждать себя расстановкой статусов в Slack или других мессенджерах. Тот, кто напишет в ваше отсутствие (и инициирует уведомление) даст повод долго и вдумчиво ругаться, что вас отвлекают в личное время. Где еще вы найдете такой повод? А менеджеры и коллеги пускай учатся копить свои быстрые вопросы до начала вашего официального рабочего дня (как раз будет, что обсуждать на дейли).
Обмен опытом — штука излишняя. Поэтому если вы все-таки кидаете в канал Education в Slack какую-нибудь ссылку на статью или фреймворк, не надо к ней делать никакого описания. Пусть это будет квест для коллег. Хотят новых знаний — пусть напрягутся и поймут, что же вы им закинули. И не важно, что это может быть не их область. И ни в коем случае не делитесь своими проектными наблюдениями, интересными решениями, багами и поучительными выводами. Разработчик разработчику волк. Вы же должны соревноваться, а не растить общий командный опыт! И да, чуть не забыл! Если нашли длиннющую статью, то сами не читайте, просто выложите коллегам, может, им будет интересно.
Работу коллег-разработчиков можно и нужно критиковать. Придираться надо к каждой мелочи. Только не путайте критику и ревью. Критиковать надо развернуто и со вкусом (и желательно как можно абстрактнее, например: “Твой код ужасен”), а вот ревью проводить как можно быстрее — нажимать зеленую галочку, не заглядывая в код и не оставляя никаких комментариев. А то придется какие-то конструктивные причины недовольства формулировать.
Переложите на нас всю ответственность за вашу мотивацию и повышение квалификации. Мы уже отдыхаем за вас, даже шлем фотографии с разных курортов. Давайте мы еще и мотивацию будем вам придумывать сами. Это же понятно, что на проекте все задачи интересные и лишь из вредности мы находим для вас рутину. И авралы мы устраиваем специально, потому что вы работаете в таком режиме лучше. Впрочем, на курсы мы вас не записываем тоже из вредности. Все ваши потребности вы передаете нам по bluetooth, встроенному в ваш мозг, мы их получаем, но игнорируем. Не надо их превращать в слова, мы их и так чувствуем.
Когда мы просим вас показать проект заказчику, ни в коем случае не готовьтесь к демонстрации заранее. Всем же ясно: если проект запустился на вашем ноутбуке, значит, он на 100% рабочий и запустится где угодно. Всем нам повезет!
Если по итогам демонстрации заказчик будет недоволен, вы почувствуете назревающий конфликт, надо послать заказчика куда подальше. Он просто ничего не понимает. И незачем ставить в известность менеджера. Кстати, конфликт с клиентом — лучший повод попросить у нас больше денег. Мы с радостью согласимся!
Срок релиза — это фикция. Мы просто очень любим отмечать эти сроки в календаре. На самом же деле управленцам, особенно на удаленке, очень не хватает общения. А перенос сроков релиза — это лучший способ быстро созвать 3-5 совещаний, на которые люди не откажутся прийти.
Когда обстановка на проекте накаляется, самое время распускать слухи о том, что все скоро свернется. Посвятите в свои предположения как можно больше коллег, распространяйте больше негатива. Если слухи обоснованы, их распространение мотивирует нас по взмаху волшебной палочки исправить ситуацию. А если не обоснованы, мы радуемся, что вы все еще в тонусе.
Кстати, если слухи не помогают, начинайте хором паниковать. Это самое конструктивное решение. В этот момент можно начинать говорить гадости о компании не только внутри, но и снаружи (например, на собеседованиях). Это определенно поможет выровнять финансовое положение и заполучить себе в коллеги сильных разработчиков!
Ближе к концу проекта можно громко и эффектно его покинуть, сформулировав причину ухода как слишком низкую зарплату, несмотря на то, что вы уже столько лет на проекте и ради нас не трогаете новые технологии. Смело идите к конкурентам — там оценят. Наш любимый квест — поиск новых специалистов за неделю до релиза. Когда уйдете в другую компанию, не забывайте про нас.
Рассказывайте всем об одной стороне проблемы. Молчите о своих “подвигах”, расскажите про то, какие менеджеры несправедливые. Не пытайтесь нас понять, рассказывайте посторонним. NDA придумали трусы!
Обо всех подводных камнях сообщайте только в крайнем случае — если проект не получается выложить в продакшен. Это же лучший тимбилдинг, когда команда совместно “тушит пожар” в ночь перед важным релизом или уже на продакшене. Не лишайте себя и команду этого удовольствия!
Если вы все-таки пережили в команде деплой и что-то пошло не так, баги на продакшене можно смело ставить в конец очереди. Они должны иметь такой же приоритет, как и все остальные. Пусть встают в очередь!
Ну и знайте, что в ночь после назначения разработчика на должность СТО с ним происходят глубокие метаморфозы. Он забывает все потребности разработчиков, становится недальновидным, авторитарным, глупым и недоступным. Поэтому и мы — менеджеры, руководители и СТО — так плохо понимаем вас, разработчиков.
Автор статьи: Евгений Вецель (imater)
P.S. Как и в прошлый раз, мой рассказ имеет лишь призрачные совпадения с реальностью. А мораль такова: давайте учтем весь этот сарказм, выстраивая отношения в коллективе.
P.P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.
(Григорий Остер)
Поговорим о том, о каких разработчиках мечтает руководство. В этот раз я выступлю в роли абстрактного управленца…
На старте любого проекта...
Знали ли вы, что высшее искусство управленца — принимать решения при минимальной начальной информации. Не мешайте нам, руководителям, тренировать этот скилл. Придерживайтесь следующей тактики:
- Называйте туманные сроки, а лучше не говорите о них вовсе.
- Когда мы спрашиваем, не сломают ли предлагаемые улучшения существующие модули, молчите, в крайнем случае делайте таинственное выражение лица!
- Рассказывая о предстоящих проблемах проекта, никогда не предлагайте своих решений, помните, нам нужны люди-вопросы, а не люди-варианты-решений.
- Как можно чаще меняйте скорость своей работы — вы же не хотите, чтобы мы без вашего участия могли прогнозировать, когда будет готова задача? Устраивайте 48-часовые сессии кодинга без сна и еды, а потом резко снижайте скорость в 10 раз, чтобы сбить нас с толку.
- Никогда не отдыхайте — так вы сможете еще и постоянно уменьшать скорость работы, нарушая наши спланированные дедлайны.
Если на этапе постановки задачи вас допустили до клиента, чтобы задать ему уточняющие вопросы, учитесь у DDoS-атак — выкладывайтесь на полную. Клиент ждет от вас не менее 50 сообщений с вопросами, желательно по мелочам — он оценит ваше выступление в эпистолярном жанре. Никаких скриншотов или видео прикладывать не нужно — пусть расшифровывают ваше послание, даже если оно содержит только “Здравствуйте!” и долгое “typing...”.
Помните: клиент и конечный пользователь — разные люди. Никогда не общайтесь с конечными пользователями и не пытайтесь себе их представить! Если тетя Маша на кассе должна видеть 25 строк текста на мониторе, спокойно размещайте их без оглядки на диагональ экрана. Пускай лупу возьмет, если ей не нравится.
Никогда не рассказывайте нам о том, какие конкретно задачи будут решены в рамках проекта. Говорите только о методах решения. И желательно во всех подробностях — как иначе CTO будет спокойно спать этой ночью?
В своем рассказе ни в коем случае не упоминайте деньги, время или другие понятные окружающим метрики. Ведь даже секретарша директора может перевести рассказы об используемых абстрактных структурах в пользовательские сценарии и точную сумму прибыли, которую мы получим. Так что при оценке задач используйте наиболее абстрактную систему величин. Помните, 1 удав — это 38 попугаев!
Заготовьте как можно больше сюрпризов. Пусть кроме времени для решения задачи потребуются еще и платные подписки или инструменты, о которых мы не будем знать до последнего момента. Подводные камни мы любим и с радостью потом будем искать выход из тупика перед релизом. Мы с клиентом обожаем повышать выделенный бюджет еженедельно, постоянно согласовывая его через все инстанции. Прогоняйте Ивана-Царевича через новую итерацию с начала сказки после каждого обновления информации о том, где хранится смерть Кощеева.
Идеальный код…
Стремитесь писать только идеальный код ради идеального кода. Необязательно это делать с первого раза. Если спешите, пишите быстрым способом, потом переделайте и потом снова. Помните: повторение — мать учения. Если код переписан трижды и хоть немного отличается от идеала, срочно начните рефакторинг в рамках небольшой задачи, которая к этому не относится. А еще лучше переведите свой код на другую библиотеку или фреймворк. Пусть код будет модным и молодежным. Главное все эти процессы ни в коем случае нельзя формулировать в виде отдельных задач. А то вдруг мы догадаемся, что на проекте что-то оказалось не идеальным? Подобные вещи лучше всего делать непосредственно перед релизом. В этот момент вся команда работает намного быстрее!
К слову о рефакторинге. Он пойдет эффективнее, если попутно изменить механизмы в коде — чтобы два раза туда не лазить. Помните, такие процессы должны затрагивать как можно больше компонентов одновременно. Зачем тратить время на ковыряние в отдельных модулях? Только так вы в итоге будете выглядеть героем, который всех спас! Другие разработчики с радостью обнаружат сюрпризы новых механизмов, когда те прострелят им ногу.
Идеальный код должен быть правильно оформлен. Старайтесь создавать файлы максимального объема, занимающие множество экранов и содержащие в себе сразу несколько компонент. Следуя этому стилю оформления, вы сможете героически преодолевать мерж-конфликты и долго договариваться с коллегами, чьи правки были важнее. Код должен напоминать максимально длинную лапшу, не надо тратить время на создание мелких незначительных файлов. Ради одной функции придумывать название файла — что может быть мучительнее?
Созданный вами идеальный код совершенно не обязательно покрывать тестами. Можно разве что поговорить о необходимости доведения покрытия до 100%, а в реальности достаточно и 10%. Чтобы от вас отстали, добавьте пару тестов, которые по факту ничего не проверяют, их тогда и актуализировать не придется.
Если вдруг оказалось, что быстро написанное решение не работает или работает не так, как ожидалось, смело обвиняйте во всем архитектора системы, API, администратора сервера и т.п. Понятно же, что ваш идеальный код не может не работать. Запомните главное: мы так же, как и вы, знаем, что идеальный программист может работать только в вакууме в идеальных условиях. И если вас отвлекают, вовремя не дают информацию, пишут непонятные ТЗ, то вы вообще не можете отвечать за то, что реализованный модуль не выполняет бизнес-задачу. Ну и правильно, бизнес — это наша обязанность. Желательно все имена виновных факторов придержать до дедлайна, они позже понадобятся, сейчас не отвлекайте руководителей.
Когда мы говорим о необходимости быстро выпустить MVP, смело игнорируйте наши попытки ускорить проект в ущерб качеству и быстродействию. Все же знают, что с хорошей идеей стартовать на рынке можно в любой момент. Время не играет никакой роли. Пусть конкуренты говнокодят, а когда вы напишете идеальный код, наше MVP взлетит и через 5 лет. И все эти годы инвесторы будут с радостью платить за то, что на их деньги создается шедевр.
Порядок в проекте...
Ваша задача — это ваша индивидуальность. Творческий беспорядок добавит вам веса в наших глазах. Умение построить беспорядок и поддерживать его в достаточно хаотическом состоянии настолько ценно, что мы даже передаем проекты из рук в руки, чтобы повысить градус беспорядка. Как только хаос достигнет максимума, мы вознаградим вас новым проектом!
Если вы поняли, что на проекте образовался полноценный бардак, но вас до сих пор не переместили, или начните закапывать свои технические долги лапками, или попроситесь на другой проект сами. Возможно, мы просто не отследили ситуацию.
Все, что происходит внутри команды, должно проходить через нас. Даже если вы решили выйти покурить с тестировщиком, обязательно договоритесь с ним через менеджера проекта, а лучше привлечь к этому и CTO. Мы чувствуем себя ненужными, если нам никто не жалуется на коллег, не обращается, чтобы решить споры внутри рабочей группы или ввести какие-то правила работы.
По проектным вопросам желательно нам писать только в личку. Это скроет все следы нашей активности от вышестоящего руководства, а заодно заставит потом пересказывать выработанные решения другим участникам процесса. Мы же это так любим!
Решение задач...
Как только вы решили задачу или исправили баг, ни в коем случае не проверяйте свое решение. Кричите “Ура” и убегайте от рабочего места как можно быстрее и дальше! Так вы и задачу быстрее сдадите и найдете команде занятие на первую половину следующего спринта — будете исправлять косяки только что сданной задачи. Что важно, вы также не лишите работы своих коллег тестировщиков. Комплект багов, вызванных новым костылем в решении, — лучший подарок к вечеру пятницы! Проверяйте в своем коде только один успешный случай, вы же оптимист.
Правильная последовательность действий при решении задачи:
- прочитать ТЗ, игнорируя примечания,
- перекурить, чтобы забыть подробности,
- быстро и без раздумий реализовать только основные функции,
- так же быстро сдать задачу,
- получить правки с четкой дешифрацией непрочитанных примечаний ТЗ,
- так уж и быть, исправить задачу через 3-4 итерации.
Никакого рефакторинга по свежим следам, никакого причесывания кода. Пусть переменные называются так, как захотела ваша левая нога в момент прозрения, а код остается плохо читаем. Не вам же в этом разбираться потом! Ну и приучите принимать ваш код на ревью сразу — вы же хороший, но обидчивый парень.
На этом этапе нельзя создавать никаких подтверждений того, что задача выполнена (а то придумают порой на проекте видео записывать, как запускается модуль…). Авось тестировщик и не заметит расхождений с ТЗ или же на доделки задача отправится другому, а вы пока сможете отдохнуть на новой задаче.
Если в задаче встречаются неоднозначные моменты, например неизвестно, должно ли поле ввода принимать только английские или заодно и русские буквы, смело отвечайте на вопросы самостоятельно, в соответствии со своими вкусами и жизненным опытом. Раз в ТЗ не написано, значит, это должно быть очевидно каждому!
И никогда не проверяйте никаких гипотез на маленькой части задачи, а то коллеги подумают, что вы испытываете сомнения!
Если вы торопитесь с задачей к релизу и понимаете, что какой-то функционал необходимо будет доделать потом, не надо тратить время на то, чтобы поставить задачу в системе управления проектом. Лучше сделайте пометку прямо в комментариях к коду и никому о ней не сообщайте. Так будет даже интереснее отлавливать технические долги. Будет ощущение, что их много и вы все еще очень нужны на проекте.
Держите в репозитории проекта не более половины файлов! Не зря в мире изобретено столько разных мест хранения. Остальные файлы важно разместить равномерно между личными репозиториями сотрудников и, к примеру, документацией (даже не обязательно к текущему проекту). Так “тайное знание” о проекте окажется разделено поровну в команде и все будут незаменимы. А то придет еще какой-нибудь новичок в проект да разберется быстренько в уже реализованном. Эдак вы на своих местах не удержитесь — всех моментально заменят на более дешевых джунов.
В каждом проекте должны быть тайные знания, которые передаются из уст в уста. Только так вы можете картинно вздохнуть и, сплюнув, сказать: “Ох уж эти джуны, уже неделю работают, а ничего не смыслят в проекте. Отойдите, сделаю сам!”
Если вы взялись выполнять какую-то задачу из Jira, совершенно не обязательно это отмечать. Мы же медиумы — и сами догадаемся, чем вы сейчас занимаетесь, а заодно нагадаем и актуальное состояние проекта. Кстати, мы так можем сделать и с потраченным временем — не надо ничего нигде записывать, мы сами выясним количество отработанных часов и рассчитаем вам зарплату.
Общение на проекте...
Слышали про омниканальность? Общение без разделения на разные каналы — последний тренд. Будьте в тренде! По любым вопросам пишите ПМ в какой-нибудь мессенджер, лучше личный, а не рабочий — чтобы он знал, что вы не отстаете от последних веяний этого мира. А вот проектные группы в Slack и других мессенджерах лучше использовать для рассылки смешных картинок с котиками и личных переговоров.
На регулярные митинги являйтесь с опозданием 15-20 минут. А ещё лучше иметь микрофон советских времён и вайфай подальше от рабочего места. Пусть все слушают ваше кваканье, оно как абстрактные картины — каждый слышит то, что хочет услышать. Причем на дейли можно задать все вопросы, которые есть у вас по проекту. Если не хватает проектных проблем, добавьте больше оффтопика. На худой конец всегда можно спросить что-то абстрактное. Такой наглядный пример лучше всего отразит, почему вы не любите созвоны и почему вам лучше на них не являться.
Ну и не забывайте, у каждого человека есть скоростной bluetooth в голове. Поэтому если вы уже представили все в голове, то достаточно передать эту картинку. Словами можно объяснить лишь мелкие детали, которых на картинке было не видно. Пусть пытаются понять вас, это их работа.
Кстати, опаздывать стоит и в офис, если вы работаете на нашей территории. Только так можно создать впечатление вашей важности. И никогда не предупреждайте об опозданиях. Это покажет, что вы все-таки торопились, т.е. испортит ваш имидж невозмутимого гуру.
Если вы уходите с рабочего места, не нужно утруждать себя расстановкой статусов в Slack или других мессенджерах. Тот, кто напишет в ваше отсутствие (и инициирует уведомление) даст повод долго и вдумчиво ругаться, что вас отвлекают в личное время. Где еще вы найдете такой повод? А менеджеры и коллеги пускай учатся копить свои быстрые вопросы до начала вашего официального рабочего дня (как раз будет, что обсуждать на дейли).
Обмен опытом — штука излишняя. Поэтому если вы все-таки кидаете в канал Education в Slack какую-нибудь ссылку на статью или фреймворк, не надо к ней делать никакого описания. Пусть это будет квест для коллег. Хотят новых знаний — пусть напрягутся и поймут, что же вы им закинули. И не важно, что это может быть не их область. И ни в коем случае не делитесь своими проектными наблюдениями, интересными решениями, багами и поучительными выводами. Разработчик разработчику волк. Вы же должны соревноваться, а не растить общий командный опыт! И да, чуть не забыл! Если нашли длиннющую статью, то сами не читайте, просто выложите коллегам, может, им будет интересно.
Работу коллег-разработчиков можно и нужно критиковать. Придираться надо к каждой мелочи. Только не путайте критику и ревью. Критиковать надо развернуто и со вкусом (и желательно как можно абстрактнее, например: “Твой код ужасен”), а вот ревью проводить как можно быстрее — нажимать зеленую галочку, не заглядывая в код и не оставляя никаких комментариев. А то придется какие-то конструктивные причины недовольства формулировать.
Переложите на нас всю ответственность за вашу мотивацию и повышение квалификации. Мы уже отдыхаем за вас, даже шлем фотографии с разных курортов. Давайте мы еще и мотивацию будем вам придумывать сами. Это же понятно, что на проекте все задачи интересные и лишь из вредности мы находим для вас рутину. И авралы мы устраиваем специально, потому что вы работаете в таком режиме лучше. Впрочем, на курсы мы вас не записываем тоже из вредности. Все ваши потребности вы передаете нам по bluetooth, встроенному в ваш мозг, мы их получаем, но игнорируем. Не надо их превращать в слова, мы их и так чувствуем.
Ближе к концу проекта…
Когда мы просим вас показать проект заказчику, ни в коем случае не готовьтесь к демонстрации заранее. Всем же ясно: если проект запустился на вашем ноутбуке, значит, он на 100% рабочий и запустится где угодно. Всем нам повезет!
Если по итогам демонстрации заказчик будет недоволен, вы почувствуете назревающий конфликт, надо послать заказчика куда подальше. Он просто ничего не понимает. И незачем ставить в известность менеджера. Кстати, конфликт с клиентом — лучший повод попросить у нас больше денег. Мы с радостью согласимся!
Срок релиза — это фикция. Мы просто очень любим отмечать эти сроки в календаре. На самом же деле управленцам, особенно на удаленке, очень не хватает общения. А перенос сроков релиза — это лучший способ быстро созвать 3-5 совещаний, на которые люди не откажутся прийти.
Когда обстановка на проекте накаляется, самое время распускать слухи о том, что все скоро свернется. Посвятите в свои предположения как можно больше коллег, распространяйте больше негатива. Если слухи обоснованы, их распространение мотивирует нас по взмаху волшебной палочки исправить ситуацию. А если не обоснованы, мы радуемся, что вы все еще в тонусе.
Кстати, если слухи не помогают, начинайте хором паниковать. Это самое конструктивное решение. В этот момент можно начинать говорить гадости о компании не только внутри, но и снаружи (например, на собеседованиях). Это определенно поможет выровнять финансовое положение и заполучить себе в коллеги сильных разработчиков!
Ближе к концу проекта можно громко и эффектно его покинуть, сформулировав причину ухода как слишком низкую зарплату, несмотря на то, что вы уже столько лет на проекте и ради нас не трогаете новые технологии. Смело идите к конкурентам — там оценят. Наш любимый квест — поиск новых специалистов за неделю до релиза. Когда уйдете в другую компанию, не забывайте про нас.
Рассказывайте всем об одной стороне проблемы. Молчите о своих “подвигах”, расскажите про то, какие менеджеры несправедливые. Не пытайтесь нас понять, рассказывайте посторонним. NDA придумали трусы!
Обо всех подводных камнях сообщайте только в крайнем случае — если проект не получается выложить в продакшен. Это же лучший тимбилдинг, когда команда совместно “тушит пожар” в ночь перед важным релизом или уже на продакшене. Не лишайте себя и команду этого удовольствия!
Если вы все-таки пережили в команде деплой и что-то пошло не так, баги на продакшене можно смело ставить в конец очереди. Они должны иметь такой же приоритет, как и все остальные. Пусть встают в очередь!
Ну и знайте, что в ночь после назначения разработчика на должность СТО с ним происходят глубокие метаморфозы. Он забывает все потребности разработчиков, становится недальновидным, авторитарным, глупым и недоступным. Поэтому и мы — менеджеры, руководители и СТО — так плохо понимаем вас, разработчиков.
Автор статьи: Евгений Вецель (imater)
P.S. Как и в прошлый раз, мой рассказ имеет лишь призрачные совпадения с реальностью. А мораль такова: давайте учтем весь этот сарказм, выстраивая отношения в коллективе.
P.P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.
