Вредные советы работодателю. Как “правильно” взаимодействовать с разработчиком

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

    Что ж, поговорим о том, как “правильно” взаимодействовать с разработчиком, например лично со мной…

    image

    (Если всей семьей купаться вы отправились к реке,
    не мешайте папе с мамой загорать на берегу.
    Не устраивайте крика, дайте взрослым отдохнуть.
    Ни к кому не приставая, постарайтесь утонуть, — Григорий Остер)...


    Когда вы планируете мой график...


    … помните, что лучше всего я работаю в режиме аврала, поспав 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.
    Maxilect
    Умные решения для вашего бизнеса

    Comments 31

      0
      Эх галера, «любимая» галера.
      +4
      10 из 10. Мне кажется что это не шутка, а выдержка из какой-нибудь книги или тренинга «Как стать успешным руководителем». Прямо всё было на разных работах в той или иной степени.
        0
        Это выдержка из десятка лет опыта работы в разных компаниях и общения со множеством разработчиков из других компаний
          0
          Мишень для «Техасского меткого стрелка».
            0
            Интересно, это актуально только для российской индустрии или так по всему миру?)
          +4

          Продвинутый уровень:


          Помните: аврал можно сделать в любом проекте, если быстро и без шума уволить половину разработчиков.

          Ф. Брукс еще 40+ лет назад сказал, что с тем же (и даже большим) успехом можно и нанять. А то вдруг без половины разработчиков станет проще и быстрее согласовывать и писать. А если нанять ещё 2n программистов, то можно и себе денег больше попросить, и программистов постоянно укорять: "сколько же вас надо нанять, чтобы хоть что-то делалось".


          Проще всего подписать меня на все рассылки Jira, все публичные каналы Slack и другие доступные уведомления (без права на обжалования).

          А важную информацию, наоборот надо обсуждать только в ветвящейся переписке с постоянно меняемым списком адресатов.


          Заставьте оправдываться за каждый обнаруженный на тестировании баг

          Это работает только с джунами. Опытный знает, что он допускает баги. И даже уже гордится некоторыми. Продуктивнее запрещать элементы TDD и максимально усложнить процесс регистрации багов (KPI по количеству, согласование с QA на заведение багов, массовое внесение инцидентов, как багов — тут много приёмов)


          Отличная встряска — задержка зарплаты.

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


          формулируйте ТЗ как можно короче.

          С тем же успехом — как можно длиннее. Круто кинуть в разработчика 400-страничной спекой: "Оцени наши доработки в проекте". Наши доработки — это изменение XML схемы, которое следует из требований одного абзаца на странице 324.


          Если вы хотите обновить технологический стек, подумайте: чем новее технология, тем она сомнительнее

          С тем же успехом можно менять стек каждые полгода-год.

            0
            Ф. Брукс еще 40+ лет назад сказал, что с тем же (и даже большим) успехом можно и нанять

            У меня был печальный опыт. На спокойный (слегка подгорающий, как и всегда) проект на 5 разработчиков руководство добавило усиление — «hot house team», как они ее гордо называли. Это такая группа «экстренного» реагирования, состоящая из ~20 бравых работников скайпа и клавиатуры.
            Не знаю как они там нам должны были помочь, но работу парализовали знатно. Пару дней долбали, настраивая окружение (по очереди, естественно), пару дней бомбили вопросами, потом заставляли нас вмержить PRы в срочном порядке, с эскалацией к менеджерам и звонками на мобилу. Фиксили баги туда-сюда по четрые раза, ломая все вкруг.
            Через 10 дней ада они покинули поле боя… чтобы зажигать на новом проекте.
            0
            Норм такой эффективный менеджер. :-)
              0
              Всю статью не прочитал. Понятно, что это реальные претензии реального человека по реальным проблемам. Но меня всегда «радует» подход индивидуума (без разницы: программиста, тестировщика, манагера) к обособлению от общей проблемы.
              Вот человек пишет:
              Ближе к делу рекомендую поменять суть задачи или вообще передать ее другой команде — больше всего я люблю именно такие неожиданно прилетающие проекты, с которыми не справились предыдущие подрядчики, а теперь нужно успеть во что бы то ни стало. Так, последние 5 дней перед релизом будут самыми продуктивными!

              Понятно, да, неприятно. Но есть другие пути, когда предыдущая команда реально обделалась в последний момент? Другая команда была в состоянии на начальном этапе спрайта сказать: «Нет, я это сделать не могу, передайте другой команде»? Я не знаю, возможно у меня специфика провинциального городка, но я ни разу не видел программиста, который сказал бы: «Да, я это точно сделаю, и сделаю до такого-то числа». Вернее, по одной задаче такое может быть, по продолжительной работе — нет. Как правило, при вопросе о реальных сроках исполнения программист предпочитает не отвечать, а падать в обморок.
              А уж когда сроки из команды программистов вытянуты, согласованы с заказчиком, но командой просорваны, то единственный ответ ты получаешь от программистов «Ну не шмогла я, не шмогла».
              Как избежать? Мониторить работу команды. Но как? Ведь мониторинг — это сложно, это избыточно и вообще незачем:
              Отчетность о выполненной работе должна быть максимально подробной. Если мне не придется отмечаться в паре систем трекинга времени (командном и общекорпоративном, например), я буду чувствовать, что мои усилия никто не ценит. Только дублирование информации обеспечит должный уровень ее сохранности! Желательно, чтобы и форма отчетности была разной.

              И да, взяв принцип построения речи в статье могу добавить: «Никогда не давайте манагеру реальную оценку состояния дела. Почаще ему сообщайте, что количество кода не пропорционально количеству прошедшего времени, что измерить процент выполнения работы программистом никак нельзя, любые измерители неадекваты. И помните, что у вас всегда есть вариант при срыве сроков сказать: „ну не шмогла я, не шмогла“. Манагер добрый, он поймет.
              И вот тогда манагеру в срочном порядке приходится искать другую команду, которая конечно же, выскажет свое неудовольствие по прилетевшей задаче. И опять сзлобный косячный менеджер виноват!
              И да! Контора, в которой работает программист, должна в попу дуть программисту, следить, чтобы он не обиделся на неточное ТЗ, на сжатые сроки, на клиента. Все это чисто манагерские проблемы, не его. Только вот надо ещё чтобы зарплата была вовремя:
              Отличная встряска — задержка зарплаты. Если деньги не придут вовремя, я точно вспомню, что я работаю ради денег, соберу мысли в кучу и начну работать лучше.

              Она же никак не зависит от качества кода продукта, от соблюдения сроков, от кол-ва найденных заказчиком багов… Деньги — они же из воздуха. Хоп — и взялись!
              Понятно, что это вечная тема для холивара.
                +2
                Э-э-э вообще-то это работа манагера контролировать время/сроки.

                Если он взял команду, которую собрали «с бору по сосенке», в сроки рассчитывал по команде, которая 10 соответствующих проектов сделали вместе (без текучки кадров). Ну тогда не надо удивятся, что его компетентность ставят под сомнение.

                Треугольник (время, ресурсы, сроки) никто не отменял. И правильную оценку рисков то же.

                А так да. Манагеры никогда не ошибаются, т.к. ничего не делают. :-)
                0

                Классно) Не везде уловил сарказм, но основной посыл понял. Жду поста с вредными советами для разработчиков!

                  0
                  А что о них писать. Вредные советы для разработчиков уже давно написаны.
                  Типа
                  1) НИКОГДА! НИКОГДА ни при каких условиях не писать тесты, тем более unit-тесты
                  2) НИКОГДА! НИКОГДА не использовать стандартные библиотеки для работы. ВСЕГДА писать свою имплементацию. Как минимум ОБЯЗАТЕЛЬНО должны быть реализована своя коллекция и HashMap
                  3) НИКОГДА! НИКОГДА не использовать системы контроля версий.
                  4) НИКОГДА! НИКОГДА не рефактрить код.
                  5) Как можно чаще (ВЕЗДЕ) использовать case, elseif и т.д.
                  6) ВСЕГДА (ОБЯЗАТЕЛЬНО), весь код должен быть в одном файле/классе
                  7) ВСЕГДА (ОБЯЗАТЕЛЬНО) использовать кодогенерацию SQL-запросов в виде конкатенации строк
                  8) ОБЯЗАТЕЛЬНО для интеграции с внешними системами для полей использовать только один тип String/char[]. Для даты написать свой парсер.
                  9) Документация для слабаков.
                  10) В название классов, функций и полей использовать как можно больше сокращений и не документированных умолчаний
                  11) Комментировать таблицы и поля в БД не нужно. В названиях таблиц и полей использовать сокращения и названия типа tmp1, tmp2, table1, table2 и т.д.
                  12) Все п-сы, а ты Д`артаньян
                    +1
                    5) Как можно чаще (ВЕЗДЕ) использовать case, elseif и т.д.

                    Можно поподробнее?
                      0
                      Для Java
                      if(...) {
                      } else if(...) {
                      } else if(...) {
                      ....
                      } else {
                      
                      }
                      


                      Видел в одном проекте такую конструкцию ~ 1000 строк и ~100 условий.

                      Аналогично для switch/case не встречал правда.
                      Но теоретически ничто не мешает это сделать.
                      :-)
                        0

                        Но в этом «вредном совете» говорится, что использование как case, так и elseif — плохо. А что тогда?

                          0
                          Если у вас есть elseif и/или switch/case, то скорее всего здесь какая-то проблема.
                          Не обязательно, что она есть.
                          Но если при дополнении/изменении требований количество блоков в операторах увеличивается, то точно этот код надо рефакторить.

                            0

                            Можно где-то подробнее про это почитать? Почему, что не так со switch/case, чем вредно и каким образом рефакторить?

                              0
                              Например тут
                                0
                                А нет у вас под рукой коротенького примера/примеров? У меня, например, почти ежедневно получается очень большое количество вот таких ифов: if not empty/null then add to collection или if collection contains
                                Вот конкретно такие ифы — плохо? Если эти хорошо, то какие плохо? Если эти плохо, то как быть?
                                  0
                                  сами по себе «if» не плохо, а вот когда в функции есть длинный оператор if/elseif, то стоит задуматься, что что-то здесь не так.

                                  Например вот из «прекрасного»
                                      	if(ro instanceof PPPlanItem) {
                                      		PPPlanItem ppRO = (PPPlanItem) ro;
                                  
                                  	    		if(ppRO.getSource() == 2)
                                  	    			result = prefix + "oebs/showpoint/" + ppRO.getPlanNo();
                                  	    		else if (ppRO.getSource() == -1)
                                  	    			result = "";
                                  	    		else
                                  	    			result = prefix + "plans/show_point/" +  ((PPPlanItem) ro).getPlanNo();
                                      	} else
                                      		if(ro instanceof PPContractHeader) {
                                      			
                                      			PPContractHeader ppcRO = (PPContractHeader) ro;
                                      			if(ppcRO.getSource() == null || ppcRO.getSource() != -1){
                                  	    			if(ppcRO.getProcurementMethod().toUpperCase().indexOf("КОНКУРС") > -1)
                                  	    				result = prefix + "oebs/showagreement/" + ((PPContractHeader) ro).getNumber();
                                  	    			else
                                  	    				result = prefix + "agreements/show/" + ((PPContractHeader) ro).getNumber();
                                      			}
                                      		} else
                                      			if(ro instanceof PPAdvertisementHeader) {
                                      				PPAdvertisementHeader pRO = (PPAdvertisementHeader) ro;
                                      				if(pRO.getSource() == null || pRO.getSource() != -1){
                                  	        			if(pRO.getProcurementMethod().toUpperCase().indexOf("КОНКУРС") > -1
                                  	        					|| pRO.getProcurementMethod().indexOf("Из одного источника посредством электронных закупок") > -1)
                                  	        				result = prefix + "oebs/showbuy/" + pRO.getNumber();
                                  	        			else
                                  	    				if(pRO.getProcurementMethod().toUpperCase().indexOf("АУКЦИОН") > -1)
                                  		    				result = prefix + "oebs/showauc/" + pRO.getNumber();
                                  	    				else
                                  		    				result = prefix + "publictrade/showbuy/" + pRO.getNumber();
                                      				}
                                      		} else if(ro instanceof ExpenditurePayment){
                                      			result = ((ExpenditurePayment) ro).getPaymentId() + ", " + ((ExpenditurePayment) ro).getPaymentNumber();
                                      		}
                                  
                                  

                                    0
                                    Ну содержимое ифов можно конечно выделить в отдельные методы, а вот что/как дальше рефакторить? Первое, что приходит на ум это продублировать тип в текстовом поле ro, и использовать его как ключ в мапке с хандлерами, но эта мапка она прямо вот действительно нужна? Если это 1000 ключей то, наверное, да, а если как тут 4?
                                      0
                                      Тут пока четыре :-)
                                      Ключей побольше около 10-ка.
                                      Это часть функции формирующий URL-адрес.
                                      Вместо того, чтобы создать абстрактный метод, который перегружается при имплементации навалили вот это. :-)
                                    0
                                    Отличная как по мне статья на эту тему
                              • UFO just landed and posted this here
                            0
                            Полагаю, что речь идет о чём-то вроде "мой первый калькулятор на питоне"
                            • UFO just landed and posted this here
                        +2
                        Если вы не знаете, как меня мотивировать…
                        …заставьте оправдываться за каждый обнаруженный на тестировании баг.
                        Кхе. У меня жена работала в компании (чисто российской, большой такой, известной, на хабре их даже иногда каким-то чудным образом в «топ работодателей» упоминают), где одно время разработчиков пытались премий лишать за допущенные и пропущенные баги.
                        И кстати, регулярные авралы в стиле "пока остаются висеть критикалы, ваш рабочий день не заканчивается" перед релизами у них тоже были (а релизы то ли каждый месяц, то ли каждые две недели, и по-моему даже тоже по пятницам).
                        Естественно, она сбежала оттуда при первой же возможности, а руководители удивлялись «Как так, почему уходишь? Ты же у нас недавно только успешно аттестацию прошла
                          +1

                          Смеялся в голос, хотя подняты далеко не смешные темы. К сожалению, некоторое число работодателей совершенно не увидит сарказма в этой статье, и чем дальше от столицы, тем это число больше.
                          И, самое главное, ещё один плохой совет — "написали же вы прошлый проект, хотя ТЗ раз двадцать поменяли? Значит и без ТЗ сможете!".

                            +2

                            Ещё стоит занижать стоимость разработки перед клиентом, чтобы конкурировать с условными "Рога и копыта", тогда разработчикам нужно будет действительно в 2-3 раза быстрее согласованного делать задачи

                              0
                              Ну а как не снижать, коли Бангалор в спину дышит? В подавляющем большинстве проектов price is the king.

                            Only users with full accounts can post comments. Log in, please.