В последнее время мне везет — я работаю в компаниях, где по-настоящему уважают разработчиков. Но так было не всегда, приходилось сталкиваться с разным подходом к взаимодействию. Хотел бы я сказать, что “дикие нравы” уходят в прошлое, но рассказы коллег об их предыдущих местах работы да и мои наблюдения за рынком опровергают это утверждение.
Что ж, поговорим о том, как “правильно” взаимодействовать с разработчиком, например лично со мной…
(Если всей семьей купаться вы отправились к реке,
не мешайте папе с мамой загорать на берегу.
Не устраивайте крика, дайте взрослым отдохнуть.
Ни к кому не приставая, постарайтесь утонуть, — Григорий Остер)...
… помните, что лучше всего я работаю в режиме аврала, поспав 3 часа после вчерашней 40-часовой сессии кодинга. Именно в этот момент 2 монитора визуально превращаются в 4, а код начинает исполнять индейские танцы под равномерный звук бубна в голове. Только так вы получите от меня нестандартные, можно сказать, гениальные идеи. В таком экстренном состоянии код начинает походить на длинную лапшу. Он имел бы атрибут файла ‘write only’, если бы такой существовал. Читать такой код можно, только погрузившись в то же состояние аврала, в котором я его писал.
К сожалению, тимлиды пытаются заложить больше времени при оценке проектов, а это мешает формированию аврала. Поэтому оптимальный путь — потратить половину заявленного времени на согласование даты релиза и обсуждения проекта “в стол” (тайно, не оставляя следов). Помните, дешифровка ТЗ — любимое мое занятие, и оно приближает аврал.
Ближе к делу рекомендую поменять суть задачи или вообще передать ее другой команде — больше всего я люблю именно такие неожиданно прилетающие проекты, с которыми не справились предыдущие подрядчики, а теперь нужно успеть во что бы то ни стало. Так, последние 5 дней перед релизом будут самыми продуктивными!
Вот, кстати, вам один “лайфхак” с одной из прошлых работ. За пару дней до релиза вы можете взять за правило подключаться ко мне по Скайпу на 18 часов в сутки и слушать клацанье клавиш и задумчивое бормотание, чтобы быть уверенными, что я не уснул и пишу “код”, а вас не пристрелит очередной заказчик.
Если у вас не получается сжать сроки, то хотя бы сократите команду. Помните: аврал можно сделать в любом проекте, если быстро и без шума уволить половину разработчиков. Еще более перспективная идея — уволив половину, можно набрать других, неопытных, и чем больше, тем лучше. Я же в аврале могу еще и обучать ребят, попутно исправляя их код вторым полушарием.
Не забывайте о том, что меня нужно держать в тонусе на всех этапах работы, в том числе во время планирования. Если я оцениваю задачу в четыре часа работы, смело называйте заказчику два. Понятно же, что я заложил запас времени на безделье.
Назначив задачу, помните, что меня нужно отвлекать как минимум раз в 5 минут. Если я сижу в наушниках, значит, надо попросить их снять. Ведь если вы не будете проверять, чем я занимаюсь, я и работать не буду или почувствую себя брошенным и одиноким! Еще я могу заподозрить, что вы ничего не делаете, раз не беспокоитесь о судьбе проекта.
Проще всего подписать меня на все рассылки Jira, все публичные каналы Slack и другие доступные уведомления (без права на обжалования). Заранее предоставьте мне список всех необходимых каналов связи. И не забудьте взять телефон моих родственников, а то я крепко сплю.
Поскольку перед вами стоит задача регулярно “пинговать” весь коллектив, привыкните уже перед любым сообщением в Slack писать что-то типа @chanel или all, чтобы уведомление получил каждый вне зависимости от настроек клиента. И требуйте ответа не позже, чем через 5 минут (кто не отвечает, тому можно позвонить на телефон)! Иначе как коллектив будет жить без сообщения о том, что у кота секретарши сегодня день рождения?
С каналами, кстати, надо работать комплексно. Есть две оптимальные стратегии: либо не разделять по смыслу вообще ничего, обсуждая все и со всеми в одном окне, либо воспользоваться тем, что современные программы позволяют создавать тысячи каналов, и стараться каждый вопрос выносить отдельно. Главное — не удаляйте потом неиспользуемые каналы. А то вдруг их подписчики хотят чувствовать себя причастными, но осознанно наслаждаются дзеном тишины?
…заставьте оправдываться за каждый обнаруженный на тестировании баг.
Это же очевидно, если я находился где-то рядом с кодом, хоть и не лазил в него, значит, я и сломал! Не смотрите в git blame, там можно обнаружить автора строчки кода. И тогда вы лишите меня удовольствия репостнуть в Инстаграмм очередной шедевр с радостной мыслью: “Это не я”.
Но тут главное не перегнуть палку. Если у вас появится подозрение, что накосячил действительно я, постарайтесь наоборот промолчать. Иначе как у меня возникнет ощущение бренности всего сущего (в т.ч. бесполезности моей собственной работы)?
Да, и забудьте мантру “весь код проекта общий”, она обижает истинных авторов и нарушает право частной собственности.
Для повышения продуктивности также можно свести меня с каким-нибудь скандальным клиентом, чтобы тот высказал мне в лицо все, что думает о последнем релизе. Прослойка из менеджеров в данном случае испортит то самое ощущение бодрости, которое не получить без хорошей ругани с утра пораньше. Заранее попросите клиента перейти в своих обвинениях на личности. Главное — проследите, чтобы клиентский отзыв не оказался позитивным, а то я расслаблюсь и вообще перестану работать.
Если клиент отказывается выдавать разработчикам фидбек, передайте весь негатив самостоятельно. Желательно при этом даже немного приукрасить. Помните — мотивация образовалась от слова “мат”. В крайнем случае можно вызвать эмоционального тестировщика, который в своей работе видит только баги и с удовольствием рассказывает разработке, насколько плохое приложение мы пишем. А то (см. выше) я расслаблюсь.
Я пишу идеальный код ради идеального кода. Мне совершенно не интересно, как этот код потом используется и используется ли вообще. Не нужно отвлекать меня положительной или, уж тем более, отрицательной реакцией на функционал, который мы делаем. “Написал и забыл” — мой лозунг. Зачем мне слова благодарности от пользователей? Может, ещё и автограф им дать?
Раздайте всем сотрудникам ярлыки. Пусть у вас будет Петя, который “всегда работает медленно”, и Вася, который “всегда косячит”. А еще должен быть Максим, который делал этот “модуль ХХХ”, и только он может вносить туда изменения. Иначе как новые сотрудники будут ориентироваться в коллективе?
Почаще напоминайте, что Петя — медленный, ругайте Петю прилюдно, чтобы все четко понимали, за что. Помните: сотрудники не меняются и не развиваются — нет смысла проверять, а не исправился ли тот же Петя после года работы в компании. Если вдруг Петя сделает задачу быстро, похвалить его лучше тет-а-тет. А то вдруг коллеги забудут, что Петя все-таки медленный? Ну и вообще, ругайте во всеуслышание, а хвалите в личку.
Найдите в коллективе себе любимчика и побольше превозносите его достоинства, даже если он не выполняет и половины возложенных на него задач. Пусть именно ему достаются самые интересные задачи. Такая “правая рука” должна быть у каждого начальника. А то как вы без опоры продержитесь на руководящем посту?
Отличная встряска — задержка зарплаты. Если деньги не придут вовремя, я точно вспомню, что я работаю ради денег, соберу мысли в кучу и начну работать лучше. Эффект будет больше, если тщательно скрывать новости о компании. Пусть все вокруг думают, что что-то происходит, но никто не может понять, что именно. И поддерживайте тех, кто с помощью своего воображения делает ситуацию еще страшнее. Чем больше страшных слухов о будущем проекта ходит в командах, тем спокойнее работается разработчику, у которого за спиной ипотека на вечность и жена с маленькими детьми.
Если проект заканчивается, молчите об этом до последнего. Вдруг обойдется и заказчик вдруг решит повторить то же самое, переписав на модный фреймворк заново?
А в целом мотивация — это мой челлендж. Ваша же задача — либо принципиально меня не замечать, либо вывести из зоны комфорта, как советует интернетик. Как иначе я буду развиваться? Если видите, что я не люблю митапы и программистские тусовки, заставляйте меня на них ходить. И наоборот, как только у меня обнаружится склонность к подобному времяпрепровождению, загрузите работой так, чтобы на тусовки не осталось времени. Зона комфорта сама себя не покинет!
… формулируйте ТЗ как можно короче. Помните: краткость — сестра таланта, ведь я могу нагадать все детали на трех литрах кофейной гущи, оставшейся с прошлого бессонного релиза. Идеальная формулировка: “Все должно быть хорошо!”
Если от аналитика вводные пришли слишком понятные, смело сокращайте! Только текст, никаких скриншотов. Еще лучше — видео в Вайбере, в котором вы, сидя за рулем, 20 минут рассказываете о ситуации на дороге, а за последнюю минуту быстро сообщаете только о существовании задачи.
Если вдруг вам приходится прикладывать к задаче ссылки на какие-то макеты или документацию, постарайтесь, чтобы они относились к принципиально разным проектам, на худой конец — к разным версиям одного проекта. Иначе будет слишком просто. А какая же разработка без квеста на старте?
В ТЗ ни в коем случае не должно быть информации о точной версии браузера или операционной системы, никаких ссылок на документы, в которых возникла ошибка.
Нет ничего ценнее человеческого общения. Вы поднимете мне настроение, если за макетами отправите к дизайнеру, за деталями задачи — к аналитику, за спецификацией API — к клиенту. Хоть он и не в нашей команде, ему тоже скучно и хочется поговорить.
Кстати, к этому шагу лучше подготовиться заранее. Ни в коем случае не обсуждайте подробности задачи в общем канале, а то, чего доброго, я узнаю о ней слишком много и не пойду напрямую к коллегам с вопросами. Более того, увидев общение менеджера по задаче в общем канале, я могу подумать, что ПМ занят делом… а разве такое возможно? Всегда пользуйтесь только личными сообщениями — так фрагментация знаний о проекте выше!
По этой же причине не стоит самостоятельно обеспечивать мне поток задач под разработку. Задачу надо заслужить — найти ее у тех же дизайнеров, аналитиков или тестировщиков. Кстати, на меня еще можно свалить часть задач этих самых аналитиков и тестировщиков. Это ведь общепринято, чтобы именно разработчик писал и поддерживал UI-автотесты! Зато разработку можно с меня снять. Обожаю начать делать задачу, а потом отдать ее “недорожденной” по указанию начальства!
Любая задача для меня должна сопровождаться максимумом бюрократии. Как иначе я буду уверен, что она действительно важная?
Отчетность о выполненной работе должна быть максимально подробной. Если мне не придется отмечаться в паре систем трекинга времени (командном и общекорпоративном, например), я буду чувствовать, что мои усилия никто не ценит. Только дублирование информации обеспечит должный уровень ее сохранности! Желательно, чтобы и форма отчетности была разной.
Стоит условиться о том, что длительность выполненных задач за неделю никак не должна быть менее 40 часов. Обязательно учитывать все, даже 2-минутные перекуры. Если на это время сотрудник не поставил трекер на паузу — дисциплинарное взыскание!
Отчеты по времени проверяйте не реже раза в неделю, устраивая общий созвон для анализа каждой строчки. И подсчитайте наконец среднюю скорость кодеров — всем же известно, что длительность выполнения задачи прямо пропорциональна числу написанных строк кода!
Поставьте условие соответствия этой скорости в качестве KPI разработчика, чтобы еще и зарплата от этого зависела. А то простые разговоры о том, что задачу делали дольше, чем предполагалось, не позволяют ощутить всей важности процесса.
Кстати, о созвонах и митингах… их должно быть как можно больше! По любому вопросу созывайте всю команду! И всегда хоть немного, но опаздывайте. Честно, я не знаю другого способа подчеркнуть свою начальственную важность. Не вздумайте предупреждать добавляемого в созвон человека, о чём пойдёт речь. Пусть покажет, как он умеет прыгать с места в карьер. Пусть заготавливает ссылки на любую тему заранее и жонглирует ими мгновенно. Или пусть ищет их в тягостной тишине в личных сообщениях с дизайнером, остальные подождут. Остальные вообще могут кодить во время созвона.
В ходе собрания обсуждайте все вопросы, которые придут в голову. Если вынести на обсуждение даже частные нестыковки, которые обычно решаются тет-а-тет, день пройдет продуктивнее. Так, например, во время дейли можно задать все вопросы по текущей задаче каждого из сотрудников. Таким образом с 10 минут дейли можно растянуть до 2 часов.
А чтобы была возможность собрать собрание по тому же вопросу еще раз, никогда в итоге не формулируйте никаких решений (вдруг их придется исполнять?). Протоколы встреч? Зачем? Протоколы у следователя, а мы мирные “трэндуны”. Если вы все-таки проглядели и кто-то сформулировал эти действия до вас, постарайтесь их проигнорировать.
… помните, что лучший момент деплоя — это вечер пятницы. Выходные все равно у всех свободны, так что мы быстро поправим все ошибки на продакшене еще до начала следующего спринта.
И не забудьте оставить заказчику личные телефоны всей команды. Не правы те, кто вводит практику дежурств. В выходные после релиза вся команда с нетерпением будет ждать клиентского звонка. Лучшее время для общения — 23:59 в пятницу, когда я начинаю страдать, что работа закончилась, а впереди целые выходные. Отдых с семьей — штука бесплатная, буду рад его подвинуть.
Всем известно, что выпускать решение в продакшен надо в один день с релизом какого-нибудь важного API, задействованного в этом решении. Бэк должен встречаться с фронтом поближе к продакшену, интеграция — слово непонятное. И не слушайте тех, кто говорит, что разработка — штука командная. Дизайнерам, аналитикам и тестировщикам в проекте на начальных стадиях делать нечего. Подключайте их под конец, лучше — за день-два до релиза. И кстати, следующий спринт даже для них нельзя начинать готовить до того, как мы завершим этот.
Стройте процесс таким образом, чтобы мне как можно чаще нужно было переключать контекст. Пусть очередь на тестирование будет максимальной, чтобы мой пул-реквест протестили не раньше, чем через пару недель после того, как я его сдал. Исправления будут только качественнее, если к каждому багу я буду подходить, как в первый раз.
Ни в коем случае не создавайте отдельные стенды для разных веток разработки. Как иначе вы проверите взаимное влияние разных изменений на релиз? И обязательно используйте в разработке базы данных с продакшена. Только так вся команда будет чувствовать сплачивающий уровень адреналина. Ну и отдохнуть после “коммита-убийцы” от надоедливого и единственного стенда тестировщики будут только рады.
… ни в коем случае не допускайте его до рядовых задач. Гораздо эффективнее нанять ему 10 джунов в “подмастерья”, чтобы он за пару месяцев превратил их в мидлов. Он же спец, значит, у него все получится! Считайте, что заполучили целую команду примерно за те же деньги. Всячески мешайте ему брать задачи и писать код самому, пусть как коршун летает над архитектурой проекта и видит проект только при помощи ревью. Ревью кода тоже задержите на пару недель, не торопите ребят, некогда объяснять почему.
Главное — не повышайте зарплату обученным специалистам. Это верный шаг к обновлению коллектива. Почему бы не “выжать” уже обученных и не заставить сениора учить новую партию? Свежая кровь в коллективе — всегда полезно. И другие компании будут знать, что вы — настоящая кузница кадров. Они это ценят, поверьте.
Если джунов нет, так и быть, отдайте ему все собеседования и самые интересные задачи. Остальная команда будет рада, что им не придется делать это самим. Ведь все в восторге от рутины!
Модули, которые напишет этот сениор, должны оставаться только при нем — никто не должен иметь права их трогать. Зачем ревью и рефакторинг, если в ваших руках идеал? И новичкам этот код не показывайте. А то вдруг они что-то там поймут или обидят сениора при помощи ревью? Чик-чик — и в мастер.
… подумайте: чем новее технология, тем она сомнительнее. Не нужно торопиться переходить на новые версии и языки, если этого еще не сделала как минимум половина отрасли. Пусть шишки миграции себе набивают другие. Правду говорят — новые технологии проще старых. Но мы же профессионалы! Мы умеем работать на сложном! Вы набирали лучших не для того, чтобы тратить деньги и время на упрощения. Если разработчики работают давно, привяжите их тем, что старые и хорошо известные им технологии не востребованы на рынке. Бинго!
А если вы выберете современные технологии для нового проекта, как заказчик поймет, что мы — команда профи? А если у вас свой фреймворк и куча библиотек кода, универсальный конструктор конструкторов, то вы вообще можете никогда не обновляться.
Если разработчик пытается за вашей спиной все-таки узнать что-то про новые технологии, развивая pet-проекты, попробуйте посильнее загрузить его основной задачей. Я ведь развиваюсь в техническом направлении только для того, чтобы уйти от вас на большие деньги (и побыстрее).
Кстати, забудьте про рефакторинг проекта. Мы, разработчики, придумали эту формулировку, чтобы потешить свое самолюбие. И не ищите свежего взгляда на код у других членов команды или у соседних команд. Как я уже говорил, мы пишем идеальный код ради идеального кода. В ревью нет необходимости. Даже если разработчик работает один и не видит чужого кода, его собственный будет идеален. Если ревью все-таки требует заказчик, сделайте эту процедуру чисто формальной. Пусть у ревьювера будет возможность просто нажать зеленую галочку, не вчитываясь в суть. Не вздумайте создавать задачи на закрытие техдолгов и рефакторинг, это пустая трата ресурсов.
… не тратьте лишние деньги на мебель. Я могу посидеть и на стуле за 500 рублей. ДМС есть — спину потом подрихтуем.
И не надо ставить в офисе никаких турников и беговых дорожек. А то разработчики вместо продуктивного курения еще бегунами станут. Какой уж тут идеальный код, когда они целыми днями стаптывают кроссовки?
Продумывая график, постарайтесь сделать его максимально жестким. Разработчики любят поспать с утра? Нечего расслабляться! Пусть все приходят к 8:00. Обнаружились те, кому это нравится? Меняйте график. Пусть теперь все приезжают к 10:00 — через самые пробки. Главное, чтобы всем было одинаково плохо — это сплачивает коллектив! Мы уже говорили о том, что мне должно быть максимально дискомфортно. График в этом смысле оставляет широкое поле для маневров. Штраф за опоздание, гонки перед дверью в офис — что может быть увлекательнее? Предоставлять день для удалённой работы офисному работнику? Фух, страшный сон приснился, не запоминайте.
… постарайтесь связываться со мной как можно реже! Удаленная работа для того и создана, чтобы не разговаривать с другими Homo Sapiens.
К слову, я вышел на удаленку именно для того, чтобы не общаться с той частью команды, которая осталась в офисе. Пусть свои проектные решения они принимают в курилке и желательно без меня. Зачем мне в этом участвовать?
Не позволяйте мне самостоятельно определять рабочие часы. Если все офисные коллеги приходят в 12, то удаленщик должен в 12 уходить с рабочего места. А то какая же это удаленка, если не смещать график на ночь?
Главное — давать удаленщику поменьше свободы в выборе часов. Я вряд ли смогу оценить серьезность работодателя, если он не может настоять на своих условиях. И запомните, удаленщик — это тот, кто всегда у компьютера. Это удобно, не смотрите на рабочие часы, они их не соблюдают. Если не будете вечерами беспокоить удаленщиков, у них может что-нибудь завестись. Например, семья или дети.
Автор статьи: Евгений Вецель (@imater)
P.S. Мой рассказ имеет лишь призрачные совпадения с реальностью. Честно скажу, на своей шкуре я испытывал их достаточно давно и в гомеопатических дозах, тем более что я уже некоторое время не рядовой разработчик. Но я отлично помню свои ощущения и мысли.
А мораль тут простая: если мы задумаемся и попытаемся учесть эти “советы” (с правильным знаком, конечно) при планировании работы, всем станет жить немного комфортнее. А дальше, чтобы посмотреть на всё это с другой точки зрения, мы дадим вредные советы программистам от компании… в следующей статье.
P.P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.
Что ж, поговорим о том, как “правильно” взаимодействовать с разработчиком, например лично со мной…
(Если всей семьей купаться вы отправились к реке,
не мешайте папе с мамой загорать на берегу.
Не устраивайте крика, дайте взрослым отдохнуть.
Ни к кому не приставая, постарайтесь утонуть, — Григорий Остер)...
Когда вы планируете мой график...
… помните, что лучше всего я работаю в режиме аврала, поспав 3 часа после вчерашней 40-часовой сессии кодинга. Именно в этот момент 2 монитора визуально превращаются в 4, а код начинает исполнять индейские танцы под равномерный звук бубна в голове. Только так вы получите от меня нестандартные, можно сказать, гениальные идеи. В таком экстренном состоянии код начинает походить на длинную лапшу. Он имел бы атрибут файла ‘write only’, если бы такой существовал. Читать такой код можно, только погрузившись в то же состояние аврала, в котором я его писал.
К сожалению, тимлиды пытаются заложить больше времени при оценке проектов, а это мешает формированию аврала. Поэтому оптимальный путь — потратить половину заявленного времени на согласование даты релиза и обсуждения проекта “в стол” (тайно, не оставляя следов). Помните, дешифровка ТЗ — любимое мое занятие, и оно приближает аврал.
Ближе к делу рекомендую поменять суть задачи или вообще передать ее другой команде — больше всего я люблю именно такие неожиданно прилетающие проекты, с которыми не справились предыдущие подрядчики, а теперь нужно успеть во что бы то ни стало. Так, последние 5 дней перед релизом будут самыми продуктивными!
Вот, кстати, вам один “лайфхак” с одной из прошлых работ. За пару дней до релиза вы можете взять за правило подключаться ко мне по Скайпу на 18 часов в сутки и слушать клацанье клавиш и задумчивое бормотание, чтобы быть уверенными, что я не уснул и пишу “код”, а вас не пристрелит очередной заказчик.
Если у вас не получается сжать сроки, то хотя бы сократите команду. Помните: аврал можно сделать в любом проекте, если быстро и без шума уволить половину разработчиков. Еще более перспективная идея — уволив половину, можно набрать других, неопытных, и чем больше, тем лучше. Я же в аврале могу еще и обучать ребят, попутно исправляя их код вторым полушарием.
Не забывайте о том, что меня нужно держать в тонусе на всех этапах работы, в том числе во время планирования. Если я оцениваю задачу в четыре часа работы, смело называйте заказчику два. Понятно же, что я заложил запас времени на безделье.
Назначив задачу, помните, что меня нужно отвлекать как минимум раз в 5 минут. Если я сижу в наушниках, значит, надо попросить их снять. Ведь если вы не будете проверять, чем я занимаюсь, я и работать не буду или почувствую себя брошенным и одиноким! Еще я могу заподозрить, что вы ничего не делаете, раз не беспокоитесь о судьбе проекта.
Проще всего подписать меня на все рассылки Jira, все публичные каналы Slack и другие доступные уведомления (без права на обжалования). Заранее предоставьте мне список всех необходимых каналов связи. И не забудьте взять телефон моих родственников, а то я крепко сплю.
Поскольку перед вами стоит задача регулярно “пинговать” весь коллектив, привыкните уже перед любым сообщением в Slack писать что-то типа @chanel или all, чтобы уведомление получил каждый вне зависимости от настроек клиента. И требуйте ответа не позже, чем через 5 минут (кто не отвечает, тому можно позвонить на телефон)! Иначе как коллектив будет жить без сообщения о том, что у кота секретарши сегодня день рождения?
С каналами, кстати, надо работать комплексно. Есть две оптимальные стратегии: либо не разделять по смыслу вообще ничего, обсуждая все и со всеми в одном окне, либо воспользоваться тем, что современные программы позволяют создавать тысячи каналов, и стараться каждый вопрос выносить отдельно. Главное — не удаляйте потом неиспользуемые каналы. А то вдруг их подписчики хотят чувствовать себя причастными, но осознанно наслаждаются дзеном тишины?
Если вы не знаете, как меня мотивировать...
…заставьте оправдываться за каждый обнаруженный на тестировании баг.
Это же очевидно, если я находился где-то рядом с кодом, хоть и не лазил в него, значит, я и сломал! Не смотрите в git blame, там можно обнаружить автора строчки кода. И тогда вы лишите меня удовольствия репостнуть в Инстаграмм очередной шедевр с радостной мыслью: “Это не я”.
Но тут главное не перегнуть палку. Если у вас появится подозрение, что накосячил действительно я, постарайтесь наоборот промолчать. Иначе как у меня возникнет ощущение бренности всего сущего (в т.ч. бесполезности моей собственной работы)?
Да, и забудьте мантру “весь код проекта общий”, она обижает истинных авторов и нарушает право частной собственности.
Для повышения продуктивности также можно свести меня с каким-нибудь скандальным клиентом, чтобы тот высказал мне в лицо все, что думает о последнем релизе. Прослойка из менеджеров в данном случае испортит то самое ощущение бодрости, которое не получить без хорошей ругани с утра пораньше. Заранее попросите клиента перейти в своих обвинениях на личности. Главное — проследите, чтобы клиентский отзыв не оказался позитивным, а то я расслаблюсь и вообще перестану работать.
Если клиент отказывается выдавать разработчикам фидбек, передайте весь негатив самостоятельно. Желательно при этом даже немного приукрасить. Помните — мотивация образовалась от слова “мат”. В крайнем случае можно вызвать эмоционального тестировщика, который в своей работе видит только баги и с удовольствием рассказывает разработке, насколько плохое приложение мы пишем. А то (см. выше) я расслаблюсь.
Я пишу идеальный код ради идеального кода. Мне совершенно не интересно, как этот код потом используется и используется ли вообще. Не нужно отвлекать меня положительной или, уж тем более, отрицательной реакцией на функционал, который мы делаем. “Написал и забыл” — мой лозунг. Зачем мне слова благодарности от пользователей? Может, ещё и автограф им дать?
Раздайте всем сотрудникам ярлыки. Пусть у вас будет Петя, который “всегда работает медленно”, и Вася, который “всегда косячит”. А еще должен быть Максим, который делал этот “модуль ХХХ”, и только он может вносить туда изменения. Иначе как новые сотрудники будут ориентироваться в коллективе?
Почаще напоминайте, что Петя — медленный, ругайте Петю прилюдно, чтобы все четко понимали, за что. Помните: сотрудники не меняются и не развиваются — нет смысла проверять, а не исправился ли тот же Петя после года работы в компании. Если вдруг Петя сделает задачу быстро, похвалить его лучше тет-а-тет. А то вдруг коллеги забудут, что Петя все-таки медленный? Ну и вообще, ругайте во всеуслышание, а хвалите в личку.
Найдите в коллективе себе любимчика и побольше превозносите его достоинства, даже если он не выполняет и половины возложенных на него задач. Пусть именно ему достаются самые интересные задачи. Такая “правая рука” должна быть у каждого начальника. А то как вы без опоры продержитесь на руководящем посту?
Отличная встряска — задержка зарплаты. Если деньги не придут вовремя, я точно вспомню, что я работаю ради денег, соберу мысли в кучу и начну работать лучше. Эффект будет больше, если тщательно скрывать новости о компании. Пусть все вокруг думают, что что-то происходит, но никто не может понять, что именно. И поддерживайте тех, кто с помощью своего воображения делает ситуацию еще страшнее. Чем больше страшных слухов о будущем проекта ходит в командах, тем спокойнее работается разработчику, у которого за спиной ипотека на вечность и жена с маленькими детьми.
Если проект заканчивается, молчите об этом до последнего. Вдруг обойдется и заказчик вдруг решит повторить то же самое, переписав на модный фреймворк заново?
А в целом мотивация — это мой челлендж. Ваша же задача — либо принципиально меня не замечать, либо вывести из зоны комфорта, как советует интернетик. Как иначе я буду развиваться? Если видите, что я не люблю митапы и программистские тусовки, заставляйте меня на них ходить. И наоборот, как только у меня обнаружится склонность к подобному времяпрепровождению, загрузите работой так, чтобы на тусовки не осталось времени. Зона комфорта сама себя не покинет!
Если вы хотите мне дать задачу…
… формулируйте ТЗ как можно короче. Помните: краткость — сестра таланта, ведь я могу нагадать все детали на трех литрах кофейной гущи, оставшейся с прошлого бессонного релиза. Идеальная формулировка: “Все должно быть хорошо!”
Если от аналитика вводные пришли слишком понятные, смело сокращайте! Только текст, никаких скриншотов. Еще лучше — видео в Вайбере, в котором вы, сидя за рулем, 20 минут рассказываете о ситуации на дороге, а за последнюю минуту быстро сообщаете только о существовании задачи.
Если вдруг вам приходится прикладывать к задаче ссылки на какие-то макеты или документацию, постарайтесь, чтобы они относились к принципиально разным проектам, на худой конец — к разным версиям одного проекта. Иначе будет слишком просто. А какая же разработка без квеста на старте?
В ТЗ ни в коем случае не должно быть информации о точной версии браузера или операционной системы, никаких ссылок на документы, в которых возникла ошибка.
Нет ничего ценнее человеческого общения. Вы поднимете мне настроение, если за макетами отправите к дизайнеру, за деталями задачи — к аналитику, за спецификацией API — к клиенту. Хоть он и не в нашей команде, ему тоже скучно и хочется поговорить.
Кстати, к этому шагу лучше подготовиться заранее. Ни в коем случае не обсуждайте подробности задачи в общем канале, а то, чего доброго, я узнаю о ней слишком много и не пойду напрямую к коллегам с вопросами. Более того, увидев общение менеджера по задаче в общем канале, я могу подумать, что ПМ занят делом… а разве такое возможно? Всегда пользуйтесь только личными сообщениями — так фрагментация знаний о проекте выше!
По этой же причине не стоит самостоятельно обеспечивать мне поток задач под разработку. Задачу надо заслужить — найти ее у тех же дизайнеров, аналитиков или тестировщиков. Кстати, на меня еще можно свалить часть задач этих самых аналитиков и тестировщиков. Это ведь общепринято, чтобы именно разработчик писал и поддерживал UI-автотесты! Зато разработку можно с меня снять. Обожаю начать делать задачу, а потом отдать ее “недорожденной” по указанию начальства!
Любая задача для меня должна сопровождаться максимумом бюрократии. Как иначе я буду уверен, что она действительно важная?
Отчетность о выполненной работе должна быть максимально подробной. Если мне не придется отмечаться в паре систем трекинга времени (командном и общекорпоративном, например), я буду чувствовать, что мои усилия никто не ценит. Только дублирование информации обеспечит должный уровень ее сохранности! Желательно, чтобы и форма отчетности была разной.
Стоит условиться о том, что длительность выполненных задач за неделю никак не должна быть менее 40 часов. Обязательно учитывать все, даже 2-минутные перекуры. Если на это время сотрудник не поставил трекер на паузу — дисциплинарное взыскание!
Отчеты по времени проверяйте не реже раза в неделю, устраивая общий созвон для анализа каждой строчки. И подсчитайте наконец среднюю скорость кодеров — всем же известно, что длительность выполнения задачи прямо пропорциональна числу написанных строк кода!
Поставьте условие соответствия этой скорости в качестве KPI разработчика, чтобы еще и зарплата от этого зависела. А то простые разговоры о том, что задачу делали дольше, чем предполагалось, не позволяют ощутить всей важности процесса.
Кстати, о созвонах и митингах… их должно быть как можно больше! По любому вопросу созывайте всю команду! И всегда хоть немного, но опаздывайте. Честно, я не знаю другого способа подчеркнуть свою начальственную важность. Не вздумайте предупреждать добавляемого в созвон человека, о чём пойдёт речь. Пусть покажет, как он умеет прыгать с места в карьер. Пусть заготавливает ссылки на любую тему заранее и жонглирует ими мгновенно. Или пусть ищет их в тягостной тишине в личных сообщениях с дизайнером, остальные подождут. Остальные вообще могут кодить во время созвона.
В ходе собрания обсуждайте все вопросы, которые придут в голову. Если вынести на обсуждение даже частные нестыковки, которые обычно решаются тет-а-тет, день пройдет продуктивнее. Так, например, во время дейли можно задать все вопросы по текущей задаче каждого из сотрудников. Таким образом с 10 минут дейли можно растянуть до 2 часов.
А чтобы была возможность собрать собрание по тому же вопросу еще раз, никогда в итоге не формулируйте никаких решений (вдруг их придется исполнять?). Протоколы встреч? Зачем? Протоколы у следователя, а мы мирные “трэндуны”. Если вы все-таки проглядели и кто-то сформулировал эти действия до вас, постарайтесь их проигнорировать.
Если вы планируете релиз…
… помните, что лучший момент деплоя — это вечер пятницы. Выходные все равно у всех свободны, так что мы быстро поправим все ошибки на продакшене еще до начала следующего спринта.
И не забудьте оставить заказчику личные телефоны всей команды. Не правы те, кто вводит практику дежурств. В выходные после релиза вся команда с нетерпением будет ждать клиентского звонка. Лучшее время для общения — 23:59 в пятницу, когда я начинаю страдать, что работа закончилась, а впереди целые выходные. Отдых с семьей — штука бесплатная, буду рад его подвинуть.
Всем известно, что выпускать решение в продакшен надо в один день с релизом какого-нибудь важного API, задействованного в этом решении. Бэк должен встречаться с фронтом поближе к продакшену, интеграция — слово непонятное. И не слушайте тех, кто говорит, что разработка — штука командная. Дизайнерам, аналитикам и тестировщикам в проекте на начальных стадиях делать нечего. Подключайте их под конец, лучше — за день-два до релиза. И кстати, следующий спринт даже для них нельзя начинать готовить до того, как мы завершим этот.
Стройте процесс таким образом, чтобы мне как можно чаще нужно было переключать контекст. Пусть очередь на тестирование будет максимальной, чтобы мой пул-реквест протестили не раньше, чем через пару недель после того, как я его сдал. Исправления будут только качественнее, если к каждому багу я буду подходить, как в первый раз.
Ни в коем случае не создавайте отдельные стенды для разных веток разработки. Как иначе вы проверите взаимное влияние разных изменений на релиз? И обязательно используйте в разработке базы данных с продакшена. Только так вся команда будет чувствовать сплачивающий уровень адреналина. Ну и отдохнуть после “коммита-убийцы” от надоедливого и единственного стенда тестировщики будут только рады.
Если к вам случайно попадает спец уровня сениор...
… ни в коем случае не допускайте его до рядовых задач. Гораздо эффективнее нанять ему 10 джунов в “подмастерья”, чтобы он за пару месяцев превратил их в мидлов. Он же спец, значит, у него все получится! Считайте, что заполучили целую команду примерно за те же деньги. Всячески мешайте ему брать задачи и писать код самому, пусть как коршун летает над архитектурой проекта и видит проект только при помощи ревью. Ревью кода тоже задержите на пару недель, не торопите ребят, некогда объяснять почему.
Главное — не повышайте зарплату обученным специалистам. Это верный шаг к обновлению коллектива. Почему бы не “выжать” уже обученных и не заставить сениора учить новую партию? Свежая кровь в коллективе — всегда полезно. И другие компании будут знать, что вы — настоящая кузница кадров. Они это ценят, поверьте.
Если джунов нет, так и быть, отдайте ему все собеседования и самые интересные задачи. Остальная команда будет рада, что им не придется делать это самим. Ведь все в восторге от рутины!
Модули, которые напишет этот сениор, должны оставаться только при нем — никто не должен иметь права их трогать. Зачем ревью и рефакторинг, если в ваших руках идеал? И новичкам этот код не показывайте. А то вдруг они что-то там поймут или обидят сениора при помощи ревью? Чик-чик — и в мастер.
Если вы хотите обновить технологический стек...
… подумайте: чем новее технология, тем она сомнительнее. Не нужно торопиться переходить на новые версии и языки, если этого еще не сделала как минимум половина отрасли. Пусть шишки миграции себе набивают другие. Правду говорят — новые технологии проще старых. Но мы же профессионалы! Мы умеем работать на сложном! Вы набирали лучших не для того, чтобы тратить деньги и время на упрощения. Если разработчики работают давно, привяжите их тем, что старые и хорошо известные им технологии не востребованы на рынке. Бинго!
А если вы выберете современные технологии для нового проекта, как заказчик поймет, что мы — команда профи? А если у вас свой фреймворк и куча библиотек кода, универсальный конструктор конструкторов, то вы вообще можете никогда не обновляться.
Если разработчик пытается за вашей спиной все-таки узнать что-то про новые технологии, развивая pet-проекты, попробуйте посильнее загрузить его основной задачей. Я ведь развиваюсь в техническом направлении только для того, чтобы уйти от вас на большие деньги (и побыстрее).
Кстати, забудьте про рефакторинг проекта. Мы, разработчики, придумали эту формулировку, чтобы потешить свое самолюбие. И не ищите свежего взгляда на код у других членов команды или у соседних команд. Как я уже говорил, мы пишем идеальный код ради идеального кода. В ревью нет необходимости. Даже если разработчик работает один и не видит чужого кода, его собственный будет идеален. Если ревью все-таки требует заказчик, сделайте эту процедуру чисто формальной. Пусть у ревьювера будет возможность просто нажать зеленую галочку, не вчитываясь в суть. Не вздумайте создавать задачи на закрытие техдолгов и рефакторинг, это пустая трата ресурсов.
Если вы взяли меня в офис…
… не тратьте лишние деньги на мебель. Я могу посидеть и на стуле за 500 рублей. ДМС есть — спину потом подрихтуем.
И не надо ставить в офисе никаких турников и беговых дорожек. А то разработчики вместо продуктивного курения еще бегунами станут. Какой уж тут идеальный код, когда они целыми днями стаптывают кроссовки?
Продумывая график, постарайтесь сделать его максимально жестким. Разработчики любят поспать с утра? Нечего расслабляться! Пусть все приходят к 8:00. Обнаружились те, кому это нравится? Меняйте график. Пусть теперь все приезжают к 10:00 — через самые пробки. Главное, чтобы всем было одинаково плохо — это сплачивает коллектив! Мы уже говорили о том, что мне должно быть максимально дискомфортно. График в этом смысле оставляет широкое поле для маневров. Штраф за опоздание, гонки перед дверью в офис — что может быть увлекательнее? Предоставлять день для удалённой работы офисному работнику? Фух, страшный сон приснился, не запоминайте.
Если вы наняли меня на удаленную работу…
… постарайтесь связываться со мной как можно реже! Удаленная работа для того и создана, чтобы не разговаривать с другими Homo Sapiens.
К слову, я вышел на удаленку именно для того, чтобы не общаться с той частью команды, которая осталась в офисе. Пусть свои проектные решения они принимают в курилке и желательно без меня. Зачем мне в этом участвовать?
Не позволяйте мне самостоятельно определять рабочие часы. Если все офисные коллеги приходят в 12, то удаленщик должен в 12 уходить с рабочего места. А то какая же это удаленка, если не смещать график на ночь?
Главное — давать удаленщику поменьше свободы в выборе часов. Я вряд ли смогу оценить серьезность работодателя, если он не может настоять на своих условиях. И запомните, удаленщик — это тот, кто всегда у компьютера. Это удобно, не смотрите на рабочие часы, они их не соблюдают. Если не будете вечерами беспокоить удаленщиков, у них может что-нибудь завестись. Например, семья или дети.
Автор статьи: Евгений Вецель (@imater)
P.S. Мой рассказ имеет лишь призрачные совпадения с реальностью. Честно скажу, на своей шкуре я испытывал их достаточно давно и в гомеопатических дозах, тем более что я уже некоторое время не рядовой разработчик. Но я отлично помню свои ощущения и мысли.
А мораль тут простая: если мы задумаемся и попытаемся учесть эти “советы” (с правильным знаком, конечно) при планировании работы, всем станет жить немного комфортнее. А дальше, чтобы посмотреть на всё это с другой точки зрения, мы дадим вредные советы программистам от компании… в следующей статье.
P.P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.
xkondorx
Эх галера, «любимая» галера.
Maxilect Автор
К слову о галерах… habr.com/ru/company/maxilect/blog/464173