Как и обещал в предыдущей статье , мы поворачиваем ситуацию в противоположную сторону.
У меня была возможность быть не только разработчиком, но и менеджером разного уровня.
Я уже говорил, что в последнее время мне везет с командами и коллегами.
Но за всю работу всякое случилось.
(Григорий Остер)
Поговорим о том, о каких мечтает руководство застройщиков.
На этот раз я буду выступать в роли абстрактного менеджера.
В начале любого проекта.
Знаете ли вы, что высшее искусство менеджера – принимать решения с минимальной исходной информацией.
Не мешайте нам, лидерам, тренировать этот навык.
Следуйте следующей тактике:
- Дайте расплывчатые сроки, а еще лучше, вообще о них не говорите.
- Когда мы спрашиваем, сломают ли предложенные улучшения существующие модули, промолчите или хотя бы сделайте загадочное выражение лица!
- Говоря о предстоящих проблемах проекта, никогда не предлагайте свои решения; помните, нам нужны люди с вопросами, а не люди с решениями.
- Как можно чаще меняйте скорость своей работы — вы же не хотите, чтобы мы без вашего участия могли предугадать, когда задание будет готово? Проведите 48-часовые сеансы кодирования без сна и еды, а затем внезапно уменьшите скорость в 10 раз, чтобы запутать нас.
- Никогда не отдыхайте – так вы также сможете постоянно снижать скорость работы, нарушая запланированные сроки.
Клиент ожидает от вас не менее 50 сообщений с вопросами, желательно по мелочам – он оценит ваше выступление в эпистолярном жанре.
Не нужно прикреплять какие-либо скриншоты или видео — пусть расшифровывают ваше сообщение, даже если оно содержит только «Привет!» и долгое «печатать.
».
Помните: клиент и конечный пользователь — разные люди.
Никогда не общайтесь с конечными пользователями и не пытайтесь их познакомить! Если тетя Маша на кассе должна видеть на мониторе 25 строк текста, спокойно размещайте их без учета диагонали экрана.
Пусть она возьмет увеличительное стекло, если оно ей не нравится.
Никогда не говорите нам, какие конкретные задачи будут решаться в рамках проекта.
Говорите только о методах решения.
И желательно во всех подробностях - как еще CTO будет спокойно спать этой ночью? В своей истории никогда не упоминайте деньги, время или другие показатели, понятные другим.
Ведь даже секретарь директора может перевести рассказы об используемых абстрактных структурах в пользовательские сценарии и точный размер прибыли, которую мы получим.
Поэтому при оценке задач используйте максимально абстрактную систему величин.
Помните, 1 удав – это 38 попугаев! Подготовьте как можно больше сюрпризов.
Предположим, что помимо времени решение проблемы потребует еще и платных подписок или инструментов, о которых мы не будем знать до последнего момента.
Мы любим подводные камни и с радостью будем искать выход из тупика перед релизом.
Мы с клиентом любим еженедельно увеличивать выделенный бюджет, постоянно согласовывая его через все инстанции.
Проведите Ивана-царевича через новую итерацию с начала сказки после каждого обновления информации о том, где хранится смерть Кощеева.
Идеальный код.
Стремитесь писать только идеальный код ради идеального кода.Не обязательно делать это в первый раз.
Если торопитесь, пишите быстро, потом переделывайте, а потом еще раз.
Помните: повторение – мать учения.
Если код переписывался трижды и хоть немного отличается от идеального, немедленно приступайте к рефакторингу в рамках небольшой задачи, не связанной с этим.
А еще лучше переведите свой код в другую библиотеку или фреймворк.
Пусть код будет модным и молодежным.
Главное, все эти процессы ни в коем случае нельзя формулировать в виде отдельных задач.
Что, если мы вдруг поймем, что что-то в проекте оказалось не идеальным? Лучше всего делать такие вещи прямо перед релизом.
В этот момент вся команда работает гораздо быстрее! Кстати о рефакторинге.
Он будет работать более эффективно, если по ходу дела менять механизмы в коде — чтобы не проходить его дважды.
Помните, такие процессы должны затрагивать как можно больше компонентов одновременно.
Зачем тратить время на возню с отдельными модулями? Только так вы в конечном итоге будете похожи на героя, который всех спас! Другие разработчики с радостью откроют для себя сюрпризы новой механики, выстрелив им в ногу.
Идеальный код должен быть правильно отформатирован.
Старайтесь создавать файлы максимального размера, занимающие много экранов и содержащие сразу несколько компонентов.
Следуя этому стилю дизайна, вы сможете героически преодолевать конфликты слияний и долго договариваться с коллегами, чьи правки были важнее.
Код должен напоминать самую длинную лапшу; не нужно тратить время на создание небольших, незначительных файлов.
Ради одной функции придумывать имя файла – что может быть мучительнее? Создаваемый вами идеальный код не обязательно должен быть покрыт тестами.
Можно только говорить о необходимости довести охват до 100%, но на самом деле достаточно и 10%.
Чтобы оставить вас в покое, добавьте пару тестов, которые на самом деле ничего не проверяют; тогда вам не придется их обновлять.
Если вдруг окажется, что быстро написанное решение не работает или работает не так, как ожидалось, смело вините в этом системного архитектора, API, администратора сервера и т. д. Понятно, что ваш идеальный код не может дать сбой.
Помните главное: мы, как и вы, знаем, что идеальный программист может работать только в вакууме и в идеальных условиях.
А если вас отвлекают, не дают вовремя информацию, пишут непонятные технические задания, то вы вообще не можете нести ответственность за то, что внедренный модуль не выполняет бизнес-задачу.
Ну да, бизнес – это наша ответственность.
Все имена виновных факторов желательно сохранить до срока, они понадобятся позже, не отвлекайте менеджеров сейчас.
Когда мы говорим о необходимости быстрого выпуска MVP, смело игнорируйте наши попытки ускорить проект в ущерб качеству и скорости.
Всем известно, что с хорошей идеей можно начать работу на рынке в любой момент. Время не имеет значения.
Пусть ваши конкуренты кодируют дерьмо, и когда вы напишете идеальный код, наш MVP взлетит через 5 лет. И все эти годы инвесторы с радостью будут платить за то, что их деньгами создается шедевр.
Заказать в проекте.
Ваша задача – ваша индивидуальность.
Творческий беспорядок добавит вам веса в наших глазах.
Умение создавать беспорядок и поддерживать его в достаточно хаотичном состоянии настолько ценно, что мы даже передаем проекты из рук в руки, чтобы увеличить степень беспорядка.
Как только хаос достигнет своего максимума, мы наградим вас новым проектом! Если вы понимаете, что проект превратился в полный бардак, но вас до сих пор не сдвинули, либо начинайте лапами закапывать свои технические долги, либо сами просите другой проект. Возможно, мы просто не отслеживали ситуацию.
Все, что происходит внутри команды, должно проходить через нас.
Даже если вы решите выйти покурить с тестировщиком, обязательно договаривайтесь с ним через менеджера проекта, а еще лучше привлеките к этому CTO. Мы чувствуем себя ненужными, если нам никто не жалуется на коллег, не обращается к нам для разрешения споров внутри рабочей группы или введения каких-то правил работы.
По вопросам проекта желательно писать нам только в личку.
Это скроет все следы нашей деятельности от вышестоящего руководства, а заодно заставит нас потом пересказывать принятые решения другим участникам процесса.
Нам это так нравится!
Решение проблем.
После того как вы решили проблему или исправили ошибку, ни при каких обстоятельствах не проверяйте свое решение.
Кричите «Ура» и убегайте со своего рабочего места как можно быстрее и дальше! Таким образом, вы быстрее выполните задачу и найдете, чем заняться команде в первой половине следующего спринта — исправление ошибок в только что отправленной вами задаче.
Важно то, что вы не оставите без работы и своих коллег-тестировщиков.
Набор багов, вызванных новым костылем в решении - лучший подарок на вечер пятницы! Отметьте в своем коде только один успешный случай, вы оптимист. Правильная последовательность действий при решении проблемы:
- читайте ТЗ, не обращая внимания на примечания,
- сделать перекур, чтобы забыть детали,
- быстро и без колебаний реализовать только основные функции,
- сдайте задание так же быстро,
- получать правки с понятной расшифровкой непрочитанных технических характеристик,
- так и быть, исправьте проблему за 3-4 итерации.
Пусть переменные будут названы так, как хотела ваша левая нога в момент прозрения, а код останется плохо читаемым.
Не вам решать это позже! Ну и привыкай сразу принимать свой код на рассмотрение — парень ты хороший, но обидчивый.
На этом этапе нельзя создавать никаких подтверждений того, что задача выполнена (иначе на проекте иногда придумают видео, чтобы записать, как модуль запускается.
).
Возможно, тестировщик не заметит расхождений с техническим заданием, или задачу отправят на доработку кому-то другому, а вы тем временем сможете отдохнуть от новой задачи.
Если в задаче есть неоднозначные моменты, например, неизвестно, должно ли поле ввода принимать только английские или русские буквы, смело отвечайте на вопросы сами, в соответствии со своими вкусами и жизненным опытом.
Поскольку в технических характеристиках этого не написано, то это должно быть очевидно всем! И никогда не проверяйте гипотезы на малой части проблемы, иначе ваши коллеги подумают, что вы сомневаетесь! Если вы торопитесь с задачей на релиз и понимаете, что какой-то функционал нужно будет доработать позже, не нужно тратить время на постановку задачи в системе управления проектами.
Лучше сделать пометку прямо в комментариях к коду и никому об этом не рассказывать.
Так будет еще интереснее ловить технические долги.
Будет ощущение, что их много и вы еще очень нужны проекту.
Храните в репозитории проекта не более половины файлов! Не зря в мире придумано столько разных мест хранения.
Оставшиеся файлы важно разместить равномерно между личными репозиториями сотрудников и, например, документацией (даже не обязательно по текущему проекту).
Таким образом, «секретные знания» о проекте будут равномерно распределены между командой, и каждый будет незаменим.
Иначе в проект придет какой-нибудь новичок и быстро разберется в том, что уже реализовано.
Если вы не останетесь на своем месте, всех моментально заменят более дешевые юниоры.
Каждый проект должен иметь секретные знания, которые передаются из уст в уста.
Только так можно драматично вздохнуть и, сплюнув, сказать: «Ох уж эти юниоры, они уже неделю работают, а в проекте ничего не понимают. Отойди, я сделаю это сам!» Если вы взяли задачу от Jira, отмечать ее вовсе не обязательно.
Мы медиумы, и сами будем догадываться, чем вы сейчас занимаетесь, а заодно и догадываться о текущем состоянии проекта.
Кстати, мы можем это сделать и с затраченным временем – ничего никуда записывать не нужно, мы узнаем количество отработанных часов и рассчитаем вашу зарплату.
Общение по проекту.
Слышали ли вы об омниканальности? Коммуникация без разделения на разные каналы – последний тренд. Будьте в тренде! По всем вопросам пишите в личку в какой-нибудь мессенджер, желательно личный, а не рабочий, чтобы он знал, что вы следите за последними тенденциями в этом мире.
А вот для отправки забавных картинок с котиками и личных переговоров лучше использовать группы проектов в Slack и других мессенджерах.
Опаздывайте на обычные встречи на 15–20 минут. А еще лучше иметь микрофон советских времен и Wi-Fi подальше от вашего рабочего места.
Пусть все слушают твое карканье, это как абстрактные картины — каждый слышит то, что хочет услышать.
Более того, в ежедневнике вы можете задать все интересующие вас вопросы по проекту.
Если проблем с дизайном недостаточно, добавьте еще оффтопа.
В худшем случае всегда можно спросить что-то абстрактное.
Такой наглядный пример лучше всего отразит, почему вы не любите звонки и почему вам лучше на них не ходить.
Ну и не забывайте, у каждого человека в голове есть высокоскоростной Bluetooth. Поэтому, если вы уже всё представили в голове, то достаточно передать эту картинку.
Словами можно объяснить лишь мелкие детали, которые не были видны на картинке.
Пусть они попытаются вас понять, это их работа.
Кстати, вам тоже придется опаздывать в офис, если вы работаете на нашей территории.
Это единственный способ создать впечатление вашей значимости.
И никогда не предупреждайте об опоздании.
Это покажет, что вы торопились, т. е.
испортит ваш имидж невозмутимого гуру.
Если вы покидаете рабочее место, вам не нужно заморачиваться с настройкой статусов в Slack или других мессенджерах.
Любой, кто напишет в ваше отсутствие (и инициирует уведомление), даст повод долго и вдумчиво ругаться, что вас отвлекают в личное время.
Где еще вы найдете такой повод? И пусть руководители и коллеги научатся сохранять свои быстрые вопросы перед началом вашего официального рабочего дня (на ежедневнике будет что обсудить).
Обмен опытом не нужен.
Поэтому, если вы все же кинете какую-то ссылку на статью или фреймворк в канал «Образование» в Slack, не нужно делать к ней никакого описания.
Пусть это будет квестом для коллег.
Если они хотят новых знаний, пусть напрягутся и поймут, что вы им кинули.
И не важно, что это может быть не их территория.
И ни при каких обстоятельствах не делитесь своими дизайнерскими наблюдениями, интересными решениями, ошибками и поучительными выводами.
Разработчик разработчику волк.
Вы должны соревноваться, а не развивать общий командный опыт! И да, чуть не забыл! Если вы нашли длинную статью, не читайте ее сами, а просто разместите коллегам, возможно, им будет интересно.
Работу коллег-разработчиков можно и нужно критиковать.
Приходится придираться к каждой мелочи.
Только не путайте критику и обзор.
Критиковать нужно обстоятельно и со вкусом (и желательно максимально абстрактно, например: «Ваш код ужасен»), но просматривать его как можно быстрее — нажать зеленую галочку, не заглядывая в код и не оставляя комментариев.
В противном случае вам придется сформулировать какие-то конструктивные причины недовольства.
Переложите всю ответственность за вашу мотивацию и профессиональное развитие на нас.
Мы уже отдыхаем для вас, даже присылаем вам фотографии с разных курортов.
Мотивацию для вас мы тоже придумаем сами.
Понятно, что все задачи на проекте интересные и только назло мы находим для вас рутину.
И мы специально устраиваем аварийное время, потому что в таком режиме работаешь лучше.
Однако мы не записываем вас на курсы тоже со злости.
Вы передаете нам все свои потребности через Bluetooth, встроенный в ваш мозг, мы их получаем, но игнорируем.
Нет нужды превращать их в слова, мы их уже чувствуем.
Ближе к концу проекта.
Когда мы просим вас показать проект клиенту, ни в коем случае не готовьтесь к демонстрации заранее.
Всем понятно: если проект запускается на вашем ноутбуке, значит, он на 100% рабочий и будет работать где угодно.
Нам всем повезет! Если в конце демонстрации клиент будет недоволен, вы почувствуете назревающий конфликт, нужно отправить клиента куда подальше.
Он просто ничего не понимает. И нет необходимости сообщать менеджеру.
Кстати, конфликт с клиентом – лучший повод попросить у нас больше денег.
Мы с радостью согласимся! Дата выхода — выдумка.
Нам просто нравится отмечать эти даты в календаре.
На самом деле менеджерам, особенно работающим удаленно, очень не хватает общения.
А перенос даты релиза — лучший способ быстро созвать 3-5 встреч, на которых люди не откажутся присутствовать.
Когда ситуация на проекте накаляется, самое время распускать слухи о том, что все скоро закончится.
Вовлекайте в свои предположения как можно больше коллег, распространяйте больше негатива.
Если слухи правдивы, их распространение побуждает нас взмахнуть волшебной палочкой и исправить ситуацию.
А если не оправдалось, то мы рады, что вы все еще в хорошей форме.
Кстати, если слухи не помогают, начинайте дружно паниковать.
Это самое конструктивное решение.
В этот момент вы можете начать говорить плохие вещи о компании не только внутри, но и снаружи (например, на собеседованиях).
Это обязательно поможет вам выровнять финансовое положение и получить в коллеги сильных разработчиков! Ближе к концу проекта вы можете громко и эффектно покинуть его, сформулировав причину ухода в слишком низкой зарплате, несмотря на то, что вы уже столько лет на проекте и ради нас не трогаете новые технологии.
Смело идите к конкурентам – они это оценят. Наш любимый квест — поиск новых специалистов за неделю до релиза.
Уходя в другую компанию, не забывайте о нас.
Расскажите всем об одной стороне вопроса.
Умолчите о своих «подвигах», расскажите о том, какие менеджеры несправедливы.
Не пытайтесь нас понять, расскажите незнакомцам.
NDA придумали трусы! Обо всех подводных камнях сообщать только в крайнем случае — если проект невозможно запустить в производство.
Это лучший тимбилдинг, когда команда совместно «тушит пожар» накануне важного релиза или уже в производстве.
Не лишайте себя и свою команду этого удовольствия! Если вы прошли развертывание в своей команде и что-то пошло не так, вы можете смело помещать ошибки в производство в конец очереди.
Они должны иметь тот же приоритет, что и все остальные.
Пусть встанут в очередь! Что ж, знайте, что в ночь после назначения разработчика на должность СТО с ним происходят глубокие метаморфозы.
Он забывает все нужды разработчиков, становится недальновидным, авторитарным, глупым и недоступным.
Поэтому мы — менеджеры, супервайзеры и СТО — так плохо понимаем вас, разработчиков.
Автор статьи: Евгений Ветцель ( подражать ) P.S. Нравиться последний раз , моя история имеет лишь призрачные совпадения с реальностью.
А мораль такова: давайте учтем весь этот сарказм при построении отношений в коллективе.
П.
П.
С.
Мы публикуем наши статьи на нескольких сайтах Рунета.
Подпишитесь на наши страницы в ВК, ФБ, Инстаграм или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях Максилекта.
Теги: #Управление разработкой #Управление проектами #Лайфхаки для гиков #Управление персоналом #управление людьми #управление проектами и командой #управление командой #вредные советы
-
Ария2С + Openwrt
19 Oct, 24 -
Где Популярна Openstreetmap?
19 Oct, 24 -
Пойдем Пешком, А Google Нам Поможет
19 Oct, 24
