Если вы новичок в программировании, вам эта статья может показаться шутливой. Матерый тимлид во время прочтения вряд ли даже улыбнется — тут все серьезно.
Способ №1. Сделать не так, как просил менеджер
Почему так неправильно. Часто менеджер знает о проекте больше, чем программисты. Кроме того, в машине должен быть один водитель: если левыми и правыми колесами управляют разные люди — машина не приедет в назначенную точку в нужное время.
Пример. Менеджер просит сделать комнату с дверью. Но по ТЗ в двери нет ручки, вместо нее педаль. Программист видел в жизни тысячи дверей и решает, что менеджер сошел с ума. Он пытается спорить, а потом делает «правильно». Его увольняют.
Программиста уволили, потому что:
а) это дверь для склада, куда люди заходят с коробками в руках — ножная педаль была главной идеей;
б) клиент — фирма, производящая ножные педали для дверей;
в) дверную ручку продали клиенту за огромные деньги — она должна была войти во вторую версию проекта, не в первую.
Мораль. Читай ТЗ, делай по ТЗ. Если не понимаешь — обсуждай. Если не согласен — спорь. Нельзя молча делать не то, что требуется.
Способ 2. Не тестировать свой код
Почему так неправильно. Уважайте труд тестировщиков. Это показатель элементарной вежливости, как почистить зубы перед походом к стоматологу.
Пример. Программисту нужно в окошке регистрации заменить слово «Ок» на «Зарегистрироваться». Он находит это слово в коде, заменяет его и, не глядя, отправляет на проверку. По проекту пару часов бегают автоматические тесты. Его смотрят тестировщики. Оказывается, новое слово не влезло в кнопку и испортило верстку. Задачу отправляют на доработку. На проверку в сумме ушел целый день.
В программировании есть понятие, пришедшее из радиоэлектроники — «smoke test». Ты запускаешь свой прибор и смотришь, а не пошел ли из него дым. Это самая простецкая проверка. Понятно, что тестирование — дело тестировщиков. Но если программист регулярно допускает «баги невнимательности», то коллектив его уважать не будет.
Мораль. Когда твои 5 минут, могут сэкономить другому человеку целый день — не ленись. Программирование — профессия педантов, которые готовы проверить и перепроверить.
Способ 3. Заниматься посторонними делами в рабочее время
Почему так неправильно. Ты получаешь деньги в обмен на то, что продаешь свое время. Если ты присваиваешь время себе — это воровство.
Пример. Программист работает одновременно на двух удаленных работах и вроде неплохо справляется. Его начальники не подозревают друг о друге. Вдруг на обеих работах — аврал. Тестировщики шлют новые задачи каждые 15 минут и требуют мгновенной реакции. Он медленно отвечает, путается в коде — в итоге подставляет обе команды.
Мораль. Если ты договорился работать на полную ставку — работай на полную ставку. Если есть свободное время — попроси у начальства больше задач и больше денег.
Способ 4. Использовать любимую библиотеку/фреймворк, не посоветовавшись с менеджером
Почему так неправильно. Программист — профессия, подразумевающая умение подчиняться правилам команды. Если ты любишь react, а твой коллега любит программировать на «сочетании чистого JS и личной самоотверженности», то вы все равно должны делать проект на той платформе, которую выбрал менеджер.
Пример. Программист получает задачу: приделать функцию к сайту. И он понимает, что ее можно быстро решить на ReactJS — и не отказывает себе в этом маленьком удовольствии. Через неделю происходит code review, и программиста увольняют, потому что:
а) он забыл заглянуть в соседнюю папку, а там 10 гигабайт кода на Angular;
б) в компании кроме него нет программистов на React — если он заболеет, то некому будет поддерживать;
в) Angular был требованием клиента.
Мораль. Архитектурные решения, выбор платформ, технологий, фреймворков, библиотек — задача технического менеджера. Если у тебя есть идея — предложи ее. Если решил устроить молчаливое самоуправство — начинай мониторить биржу труда. Не после первого раза, конечно, но если проделать такой фокус два раза, то почти наверняка.
Способ 5. Просить повышение за несколько недель до сдачи большого проекта
Почему так неправильно. Это шантаж.
Пример. Программист в рамках большого проекта сделал библиотеку «для распознавания голоса» — она почти готова, но еще сыровата. Сдача через 3 недели. Другому программисту потребуется месяц, только чтобы разобраться в коде. Программист решает, что сейчас подходящий момент попросить повышение.
У менеджера в этой ситуации поджимается все, что может поджаться. Он повышает программисту зарплату. После сдачи проекта программиста увольняют или больше не дают большие и важные задачи. Он потерял доверие начальства.
Если бы программист попросил повышение уже после сдачи проекта, отношение к нему было бы другим. «Мы повышаем, потому что он молодец и сдал проект» — мотивация получше, чем «мы повышаем, потому что он выкрутил нам руки».
Мораль. «Предложения, от которых нельзя отказаться» больше подходят итальянским мафиози, чем программистам.
От редакции
Курсы «Нетологии» по теме:
- онлайн-профессия «Веб-разработчик с нуля»
- онлайн-профессия «Python-разработчик»
- онлайн-профессия «Frontend-разработчик»
Комментарии (31)
little-brother
06.02.2019 17:46+14Видимо на данный момент профессия программиста на рынке труда уже не востребована, потому их вот так просто можно и нужно увольнять. Если что, вон их сколько по улицам бегает.
SergeiMinaev
06.02.2019 17:53+3то вы все равно должны делать проект на той платформе, которую выбрал менеджер.
Не спорю, но как менеджер может выбирать платформу? У него есть необходимые знания? Мне кажется, такое должно происходить сообща. Разработчики должны рассказать менеджеру об особенностях той или иной платформы и помочь понять отличия.
Архитектурные решения, выбор платформ, технологий, фреймворков, библиотек — задача технического менеджера.
Надо было сразу уточнить, что речь о техническом менеджере. Но вообще, это все касается только крупных команд.
SirEdvin
06.02.2019 17:54+7Способ №1. Сделать не так, как просил менеджер
Клик-бейт какой-то получился. По факту "втихую сделать не так, как написано в ТЗ, что бы переделка заняла большое количество времени".
Способ 2. Не тестировать свой код
Хах, если бы.
Способ 3. Заниматься посторонними делами в рабочее время
Ведь смотреть в код, который компилируется — это так интересно.
Способ 4. Использовать любимую библиотеку/фреймворк, не посоветовавшись с менеджером
Серьезно? То есть ладно с фреймворков (хотя синтегрировать два фреймворка обычно довольно сложно), но согласовывать либы с менеджеров — довольно странная идея.
Мне интересно, а где такие пункты как:
- Регулярно срывать сроки
- Писать отвратительный код, который или не работает, или работает так, что бы лучше не работал.
- Воровать информацию о клиентах
- Отдавать свою работу на аутсорс
- Быть токсичным насколько, что начинаешь каждый день с оскорблений.
j8kin
06.02.2019 18:20но согласовывать либы с менеджеров — довольно странная идея
Например у нас в крупном банке именно так ибо сейчас эта библиотека MIT лицензию имеет, а завтра уже она платная, а выпиливание ее стоит и времени и денег. Поэтому каждое подобное использование — обсуждается в плане сколько профита от использования мы будем иметь и сколько гемора в случае изменения лицензии. И если при использовании ее для тестирования скорее будет положительный ответ, то в продакшен коде скорее откажут от греха подальше.SirEdvin
06.02.2019 18:25+1Я прошу прощения, но разве лицензия имеет обратную силу? То есть что вам мешает использовать ту версию, что у вас осталась?
defaultvoice
06.02.2019 17:57+3Способ 5. Просить повышение за несколько недель до сдачи большого проекта
Ну если менеджер понятия не имеет о bus factor и допускает ситуации, когда вся информация о проекте находится в руках одного человека, то он сам себе злобный Буратино.
amarao
06.02.2019 17:58+5Пока выглядит так, что «делать что сказали и не выделываться». Это разумное требование, которое сотрудник может принять, а может поискать работу, где ему дают больше свободы.
… А ещё эта статья подразумевает, что менеджер понимает больше программиста в том, что делает программист. Либо у вас такие крутые менеджеры, либо такие тупые программисты.
… Что вполне вероятно с учётом первого пункта.
DickCancer
06.02.2019 17:59+3Программисты это как правило очень умные и талантливые люди, и при том очень скромные и иногда застенчивые. Я сам лично знаю много примеров как «крутые» продакт менеджеры унижали и обижали программистов. А уж среди «эффективных» менеджеров это в порядке вещей, не поиздевался над программистом считай день зря прошёл! Админов тоже стараются «опустить» но они как правило по зубастие и то что прокатывает с программистом, не прокатит с админом. А вообще если программист выполняет свою работу (по своиму, так как он лучше знает чем манагер) то доставать его придирками явно не стоит!
VMichael
06.02.2019 18:03-3А какой из пунктов вы считаете «придирками»?
Там вроде есть обоснование, можете написать ваше обоснование, почему именно это придирка?DickCancer
06.02.2019 18:12Ну хотя бы четвёртый способ, почему программист должен советоваться с менеджером об используемом фреймворке? Программист может посоветоваться со своими коллегами программистами и дальше уже решить какой использовать. Для менеджера же это просто название, не более. Менеджер ведь не отличит один фреймворк от другого, или возможно я просто с такими менеджерами не знаком?
Koneru
06.02.2019 18:54+1У меня был менеджер. Два года опыта в FrontEnd. И он не мог себе позволить сам решить какие технологии будут использоваться на проекте. Всегда советовался в первую очередь с архитектором и командой которая будет реализовывать. И не потому что он плохой дев был, а потому что понимал, что писать будет не он и уважал мнение ребят.
AllexIn
06.02.2019 18:03«Придирки» — сложное слово, не однозначное.
В любом случае — задача управленца контролировать рабочий процесс. В идеале должен быть баланс между свободой и контролем. Тогда команда эффективно работает.
Но в баланс никто не умеет, поэтому либо команда сваливается в свободу и не делает нихрена, либо команда сваливается в контроль, и теряет мотивацию нормально работать — не делает нихрена.
Что характерно, в обоих случаях менеджмент обвиняет команду, и не считает что накосячил.
ТАк забавно на это смотреть, что снаружи, что изнутри.
MaZaNaX
06.02.2019 18:02+2в) Angular был требованием клиента.
Слабо представляю себе ситуацию, когда человек работает на проекте, не зная требования со стороны заказчика. Хотя, если такое происходит, то увольнение, возможно, не самый худший вариант в таком случае
dom1n1k
06.02.2019 18:31+1Как подгорает-то в комментариях…
Vadem
06.02.2019 18:41+3Подгорает во многом от категоричности статьи: не согласовал библиотеку с менеджером — уволить, позанимался делами в рабочее время — уволить, и т.д.
Я конечно понимаю, что речь идёт о целой вёб-студии, работать в которой большая честь,
но вот так разбрасыватсья специалистами может себе позволить далеко не каждая компания.
Может можно сначала с сотрудником поговорить и попробовать решить проблему, а не сразу увольнять?
Конечно, если сотрудник систематически нарушает требования руководства, то тогда надо увольнять.dom1n1k
06.02.2019 18:49А по-моему, в половине комментариев категоричности намного больше, чем в статье.
Akuma
06.02.2019 18:33Как написали выше, у вас либо очень умные менеджеры, либо очень тупые программисты.
Способ №1. Сделать не так, как просил менеджер
Пример с дверью слишком «в лоб», тут случай тупого программиста. Если, например, верстальщик начнет сам рисовать макеты, это как раз ваш случай.
Способ 2. Не тестировать свой код
Нет, на проверку в сумме ушло 10 минут вместо пяти. Остальное время — это ваша «бюрократия». Увеличение текста кнопки в пять раз должен был проверить тот, кто это придумал, а не программист.
Способ 3. Заниматься посторонними делами в рабочее время
Расскажите это тем людям, которым нужно больше думать, чем кодить. Понятно что не нужно играть в Дотку на работе, но почитать хабр пока что-то собирается/компилируется/деплоится — почему нет то?
Способ 4. Использовать любимую библиотеку/фреймворк, не посоветовавшись с менеджером
У вас очень крутые менеджеры. У меня около 70 зависимостей только в nodejs. Они правда будут проверять каждую?
Способ 5. Просить повышение за несколько недель до сдачи большого проекта
Нужно было назвать этот способ «Шантаж для повышения», т.к. в том чтобы просить повышение не вижу ничего плохого. Не хотите повышать — просто откажите человеку. Если он вам за это загубит проект — значит нет самоуважения у такого программиста и гнать его надо было еще на этапе собеседования.
Grigorenkovic
06.02.2019 18:35Показываешь результат — можно нарушать все правила. Заваливаешь проект — любая мелочь ведет к увольнению.
Scf
06.02.2019 18:39+3Странная статья. С одной стороны, пишутся разумные и правильные вещи, а с другой, пишутся они так, что воспринимается очень негативно.
Способ №1. Сделать не так, как просил менеджер
Почему так неправильно. Часто менеджер знает о проекте больше, чем программисты.И держит эти знания подальше от программистов, чтобы они не смогли занять его кресло
Способ 2. Не тестировать свой код
Увольнения за ошибки в коде рождают единственную верную стратегию — молчать об ошибках и не никогда не признаваться.
Способ 3. Заниматься посторонними делами в рабочее время
самообучением и исследованием заниматься будешь в личное время, перерывы в работе — воровство у компании.
Способ 4. Использовать любимую библиотеку/фреймворк, не посоветовавшись с менеджером
см. Способ №1. — диктат как средство упрочнения власти менеджера
Способ 5. Просить повышение за несколько недель до сдачи большого проекта
А кормить завтраками о повышении "а ты попаши сначала за троих пару лет, там мы тебя и повысим до Самого Главного Программиста с тем же окладом" не шантаж, да.
Anshi85
06.02.2019 18:40+1Не вижу нечего зазорного чтобы попросить прибавки к зарплате во время проекта, если я показал и доказал свою полезность в проекте и в компании целом! Почему менеджер сразу рассматривает сколько займет времени вникнуть новому специалисту если меня уволить за такую «наглость»? А вдруг менеджер после завершения проекта похлопать меня по плечу и все? Обычно бонусы и премии за проект обсуждаются до начала работы на проекте, а не после, после тебе скажут что лишних денег нет, надо было до проекта просить. В общем менеджер как то однобоко мыслит, получается программист только должен, а прав у него нет.
andreysmind
06.02.2019 18:43+2А там во всех пунктах один и тот же менеджер или каждый раз разные?
Там получился такой собирательный образ суперменеджера, который и требования заказчика знает и в фреймворках разбирается и зарплатами заведует?
Менеджер просит сделать комнату с дверью. Но по ТЗ в двери нет ручки, вместо нее педаль. Программист видел в жизни тысячи дверей и решает, что менеджер сошел с ума. Он пытается спорить, а потом делает «правильно». Его увольняют.
Я так понимаю, что информация о том, что клиент — бизнес производящий педали так и не была донесена до программиста? О чем спорили тогда?
А читать статьи для повышения квалификации это посторонние дела или еще нет?
А сходить прогуляться потому, что решение задачи в голову не идет — это воровство или нет?
Какой-то рашен бизнес в худшем его варианте типа «Я начальник, ты дурак».
M_AJ
06.02.2019 18:43+1Менеджер просит сделать комнату с дверью. Но по ТЗ в двери нет ручки, вместо нее педаль. Программист видел в жизни тысячи дверей и решает, что менеджер сошел с ума. Он пытается спорить, а потом делает «правильно». Его увольняют.
Раз уж вы решили разговаривать на языке аналогий… Менеджеры забыли, что двери нужно открывать с двух сторон. Когда программист спрашивает где вторая педаль, менеджер говорит ему: "делай по ТЗ, заказчик вторую педаль не заказывал!". Программист, чтобы его не уволили делает по ТЗ. За день до сдачи двери, случайно зашедший клиент спрашивает, как ему открыть дверь с другой стороны. Тут менеджер понимает, что в ТЗ вроде как сказано, что двери должны открываться в обе стороны, и вообще это требование пожарной безопасности. В общем, менеджер, нехотя признав свою ошибку, поручает программисту СРОЧНО сделать вторую педаль, говоря, что если он не сделает её к завтрашнему вечеру, то заказчик останется очень недоволен, а вся фирма (и он не исключение) останется без премий. В результате программист работает всю ночь и весь следующий день, кое как прилаживая вторую педаль, а менеджер, довольный тем, что решил проблему, уходит в шесть.
PMVyatkin
06.02.2019 18:44Что то мне не очень нравится утверждение про то, что программист продает свое время.
Если вы покупаете разработчиков — от звонка до звонка, это очень странно. Многие разрабы делают задачи на стороне, и если в ущерб основной работе — да, это нечестно. Но еще чаще человек ставит приоритет на основной работе, и время на компиляцию кода\просто отдых тратит не на фриланс (сроки которого можно сдвинуть) а на обучение.
ИМХО надо договориться на берегу, сидит разраб от звонка до звонка и в вечер релиза уходит домой потому что 7 вечера и электричка в Мусохранск уходит, или мирится с тем что разраб прикрывает такие вещи но в свободное время ковыряет фриланс\петпроекты\качается.
maslyaev
06.02.2019 18:57+2Способ №1. Сделать не так, как просил менеджер
Часто, но реже, чем наоборот. Увы.
Часто менеджер знает о проекте больше, чем программисты.
Кроме того, я ни разу не сталкивался с тем, чтобы ТЗ (то самое, в котором написано про педаль, а не ручку) писал менеджер. У менеджеров, извините, другие задачи. Если менеджер пишет ТЗ, то в проекте уже что-то пошло не так.
Способ 3. Заниматься посторонними делами в рабочее время
Если прогер продаёт своё время, то это сигнал, что его работу нужно отдать на аутсорс.
Ты получаешь деньги в обмен на то, что продаешь свое время.
Не знаю как кто, но я получаю деньги не за затраченное время, а за решённые задачи и устранённые проблемы. В мире не должно быть ни одной живой души, которой было бы не всё равно, тупил я в задачу все положенные 8 часов, или сначала 4 часа доводил себя до кондиции чтением статеек на Хабре, потом за 3 часа сделал, а потом час на том же Хабре умничал в комментах.
Когда работник умственного труда относится к работе как к продаже своего время — это, я считаю, катастрофа, притом сразу для всех. Гораздо правильнее и продуктивнее к работе относиться как к взаимовыгодному сотрудничеству. Работник выдаёт полезный организации продукт, а организация обеспечивает наличие необходимого и достаточного для самореализации работника как работника.
Господа администраторы, как бы вам так научиться перестать относиться к сотрудникам как к скоту? Я понимаю, что в ваших MBA вас этому не учили, но почему бы не попытаться дотянуть самообразованием?
xfaetas
06.02.2019 19:02Заниматься посторонними делами в рабочее время
А если разраб формошлепит ваши ТЗ за половину выделенного времени — чем ему занять оставшееся?
AllexIn
Почти всегда работаю одновременно на двух работах.
Как правило это одна основная, которой я выделяю рабочии дни и дополнительная на вечера и выходные.
Причина проста как три копейки — завтра что-то случилось в компании, и я сижу без работы и без денег.
Плюс не понятно что такое «рабочее время» в случае удаленки. Я за 10 лет практики не сталкивался с тем, чтобы кто-то назначал удаленщикам фиксированное рабочее время. Есть договоренность, что примерно 40 часов в неделю должно быть потрачено на работу и всё.
Соответственно ситуация «одновременно аврал, одновременно кидают задачи» просто невозможна.
P.S.
Ну и отдельный момент. Программисты не продают своё время. Программисты продают решение задач.
Я бы жестче сказал про продажу времени, но не буду.
Matisumi
> Причина проста как три копейки — завтра что-то случилось в компании, и я сижу без работы и без денег.
У вас в городе всего одна компания, где нужны программисты? Просто последние лет 10 я наблюдаю как бы обратную ситуацию — вакансий больше, чем специалистов, готовых их закрыть.
AllexIn
Я работаю удаленно и только над интересными проектами.
Трэш вакансии предлагают регулярно, но 80% — офис, еще 15% — мусор.