СоХабр закрыт.

С 13.05.2019 изменения постов больше не отслеживаются, и новые посты не сохраняются.

| сохранено

H Как программисту лишиться работы. 5 способов от руководителя IT-студии в черновиках

Блог компании Нетология, Карьера в IT-индустрии, Программирование

  1. Способ №1. Сделать не так, как просил менеджер
  2. Способ 2. Не тестировать свой код
  3. Способ 3. Заниматься посторонними делами в рабочее время
  4. Способ 4. Использовать любимую библиотеку/фреймворк, не посоветовавшись с менеджером
  5. Способ 5. Просить повышение за несколько недель до сдачи большого проекта
  6. От редакции
Сооснователь Alef Development Стас Гольденшлюгер рассказал, почему программисты теряют работу и дал советы, как этого избежать.



Если вы новичок в программировании, вам эта статья может показаться шутливой. Матерый тимлид во время прочтения вряд ли даже улыбнется — тут все серьезно.

Способ №1. Сделать не так, как просил менеджер


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

Пример. Менеджер просит сделать комнату с дверью. Но по ТЗ в двери нет ручки, вместо нее педаль. Программист видел в жизни тысячи дверей и решает, что менеджер сошел с ума. Он пытается спорить, а потом делает «правильно». Его увольняют.

Программиста уволили, потому что:

а) это дверь для склада, куда люди заходят с коробками в руках — ножная педаль была главной идеей;
б) клиент — фирма, производящая ножные педали для дверей;
в) дверную ручку продали клиенту за огромные деньги — она должна была войти во вторую версию проекта, не в первую.

Мораль. Читай ТЗ, делай по ТЗ. Если не понимаешь — обсуждай. Если не согласен — спорь. Нельзя молча делать не то, что требуется.

Способ 2. Не тестировать свой код


Почему так неправильно. Уважайте труд тестировщиков. Это показатель элементарной вежливости, как почистить зубы перед походом к стоматологу.

Пример. Программисту нужно в окошке регистрации заменить слово «Ок» на «Зарегистрироваться». Он находит это слово в коде, заменяет его и, не глядя, отправляет на проверку. По проекту пару часов бегают автоматические тесты. Его смотрят тестировщики. Оказывается, новое слово не влезло в кнопку и испортило верстку. Задачу отправляют на доработку. На проверку в сумме ушел целый день.

В программировании есть понятие, пришедшее из радиоэлектроники — «smoke test». Ты запускаешь свой прибор и смотришь, а не пошел ли из него дым. Это самая простецкая проверка. Понятно, что тестирование — дело тестировщиков. Но если программист регулярно допускает «баги невнимательности», то коллектив его уважать не будет.

Мораль. Когда твои 5 минут, могут сэкономить другому человеку целый день — не ленись. Программирование — профессия педантов, которые готовы проверить и перепроверить.

Способ 3. Заниматься посторонними делами в рабочее время


Почему так неправильно. Ты получаешь деньги в обмен на то, что продаешь свое время. Если ты присваиваешь время себе — это воровство.

Пример. Программист работает одновременно на двух удаленных работах и вроде неплохо справляется. Его начальники не подозревают друг о друге. Вдруг на обеих работах — аврал. Тестировщики шлют новые задачи каждые 15 минут и требуют мгновенной реакции. Он медленно отвечает, путается в коде — в итоге подставляет обе команды.

Мораль. Если ты договорился работать на полную ставку — работай на полную ставку. Если есть свободное время — попроси у начальства больше задач и больше денег.

Способ 4. Использовать любимую библиотеку/фреймворк, не посоветовавшись с менеджером


Почему так неправильно. Программист — профессия, подразумевающая умение подчиняться правилам команды. Если ты любишь react, а твой коллега любит программировать на «сочетании чистого JS и личной самоотверженности», то вы все равно должны делать проект на той платформе, которую выбрал менеджер.

Пример. Программист получает задачу: приделать функцию к сайту. И он понимает, что ее можно быстро решить на ReactJS — и не отказывает себе в этом маленьком удовольствии. Через неделю происходит code review, и программиста увольняют, потому что:

а) он забыл заглянуть в соседнюю папку, а там 10 гигабайт кода на Angular;
б) в компании кроме него нет программистов на React  — если он заболеет, то некому будет поддерживать;
в) Angular был требованием клиента.

Мораль. Архитектурные решения, выбор платформ, технологий, фреймворков, библиотек — задача технического менеджера. Если у тебя есть идея — предложи ее. Если решил устроить молчаливое самоуправство — начинай мониторить биржу труда. Не после первого раза, конечно, но если проделать такой фокус два раза, то почти наверняка.

Способ 5. Просить повышение за несколько недель до сдачи большого проекта


Почему так неправильно. Это шантаж.

Пример. Программист в рамках большого проекта сделал библиотеку «для распознавания голоса» — она почти готова, но еще сыровата. Сдача через 3 недели. Другому программисту потребуется месяц, только чтобы разобраться в коде. Программист решает, что сейчас подходящий момент попросить повышение.

У менеджера в этой ситуации поджимается все, что может поджаться. Он повышает программисту зарплату. После сдачи проекта программиста увольняют или больше не дают большие и важные задачи. Он потерял доверие начальства.

Если бы программист попросил повышение уже после сдачи проекта, отношение к нему было бы другим. «Мы повышаем, потому что он молодец и сдал проект» — мотивация получше, чем «мы повышаем, потому что он выкрутил нам руки».

Мораль. «Предложения, от которых нельзя отказаться» больше подходят итальянским мафиози, чем программистам.

От редакции


Курсы «Нетологии» по теме:

–37
~3900
  blognetology

комментарии (51)

+16
AllexIn ,  
Программист работает одновременно на двух удаленных работах и вроде неплохо справляется. Его начальники не подозревают друг о друге. Вдруг на обеих работах — аврал. Тестировщики шлют новые задачи каждые 15 минут и требуют мгновенной реакции. Он медленно отвечает, путается в коде — в итоге подставляет обе команды.

Почти всегда работаю одновременно на двух работах.
Как правило это одна основная, которой я выделяю рабочии дни и дополнительная на вечера и выходные.
Причина проста как три копейки — завтра что-то случилось в компании, и я сижу без работы и без денег.
Плюс не понятно что такое «рабочее время» в случае удаленки. Я за 10 лет практики не сталкивался с тем, чтобы кто-то назначал удаленщикам фиксированное рабочее время. Есть договоренность, что примерно 40 часов в неделю должно быть потрачено на работу и всё.
Соответственно ситуация «одновременно аврал, одновременно кидают задачи» просто невозможна.

P.S.
Ну и отдельный момент. Программисты не продают своё время. Программисты продают решение задач.
Я бы жестче сказал про продажу времени, но не буду.
0
+1 –1
Matisumi ,  
> Причина проста как три копейки — завтра что-то случилось в компании, и я сижу без работы и без денег.

У вас в городе всего одна компания, где нужны программисты? Просто последние лет 10 я наблюдаю как бы обратную ситуацию — вакансий больше, чем специалистов, готовых их закрыть.
+3
AllexIn ,  
Я работаю удаленно и только над интересными проектами.
Трэш вакансии предлагают регулярно, но 80% — офис, еще 15% — мусор.
0
berez ,  
У вас в городе всего одна компания, где нужны программисты?

Наличие вакансий не означает немедленного трудоустройства на прекрасную должность.
Пока соискатель бегает по собеседованиям, ему надо как-то сводить концы с концами.
Или у вас в городе достаточно зайти в первую попавшуюся компанию, где нужны программисты, и ура — через пять минут вы уже приняты?
+2
vdem ,  
Не знаю как кому, но я практически не могу отключиться от задачи после того, как закончил рабочий день. Бывало, решение какой-нибудь проблемы приходило даже во сне. И за это время не платят, и непонятно как его посчитать :(
+2
AllexIn ,  
Не по времени.
Лично я категорически против считания работы программиста по времени.
Серьезно въехал в эту тему, когда делал свой тайм трекер и пришел к выводу, что считание по времени — это всегда обман.
ДАже есть желание статью об этом написать, но с другой стороны это всё так очевидно, что не уверен в её ценности.
+1
edogs ,  
Программисты не продают своё время. Программисты продают решение задач.
Очень даже продают. 20 лет уж как продаем. Наравне с решением задач разумеется.
0
bzzz00 ,  
я думаю это все же часть правды. что именно является объектом продажи нужно обсуждать _до_ начала работы. чтобы потом никто не плакал горько и не чувствовал себя обманутым.
0
M_AJ ,  
Программисты не продают своё время. Программисты продают решение задач.

Некоторые руководители почему-то считают, что если ты сделал условно говоря половину работы за 3 часа, то значит за 6 ты должен сделать ее всю, и взять следующую, а ты понимаешь ли сидишь и не работаешь. Ну а тот факт, что человек не станок по производству кода (или чего угодно), и устает воспринимают чуть ли не как личное оскорбление, мол как ты посмел устать, я тебе деньги плачу — уставай в свое личное время.
+17
little-brother ,  
Видимо на данный момент профессия программиста на рынке труда уже не востребована, потому их вот так просто можно и нужно увольнять. Если что, вон их сколько по улицам бегает.
0
yizraor ,   * (был изменён)

Не исключено, что есть начальники, которые питают подобную иллюзию.
Особенно, глядя на обилие учебных заведений, где готовят программистов (в т.ч. и заочно), а также всяческих курсов в Интернете на тему "как быстро стать программистом".
Ну, туда им и дорога...


Реально же — весьма поверхностная точка зрения.


Уже почти 10 лет стажа (между ними ещё лет 5 на столичных хлебах) работаю на 2-х достаточно больших предприятиях своего города. Оба предприятия принимают каждый год студентов-дипломников.


Мы с коллегами наблюдаем, как уровень студентов падает с каждым годом. Причём падает вместе с требованиями преподавателей к студентам, ибо коммерческая составляющая в образовании играет всё бОльшую роль (увы, знаю точно, т.к. есть связь со своими старыми преподавателями, есть и с кураторами, которые присылают нам студентов; есть преподающие там же коллеги).


Доходит до такого: студент за год ни разу не посетил своё учебное заведение, но ему всё равно проставляют 3-ки по всем предметам и переводят на следующий курс. А всё почему — "отчислять начальство запрещает, за обучение ж уплочено". Другой случай с той же оперы: не успела начаться преддипломная практика, студент решил жениться; не знаю, почему женитьба должна так сильно мешать получению специальности, но на заводе его видели только один раз, в начале практики, и в учебном заведении — тоже однажды. Непонятно где пробыв полгода, и даже не позаботившись о том, чтобы сделать хоть что-то (преподаватели были бы счастливы увидеть и купленный на стороне диплом, на любую тему, лишь бы был… но увы-с), студент в итоге себе специальность и диплом (корочку) получил.


Таких вот "дипломированных специалистов" сейчас пруд пруди.
А сколько из них реально могут работать по своей специальности?


О талантливых студентах-дипломниках давно уже и не мечтаем (хотя ещё помним). Сейчас-то за счастье хоть одного более-менее толкового увидеть за год. Подумываем о том, что нафиг не сдалось больше со студентами возиться, и потихоньку формулируем аргументы для начальства...

+3
SergeiMinaev ,   * (был изменён)
то вы все равно должны делать проект на той платформе, которую выбрал менеджер.


Не спорю, но как менеджер может выбирать платформу? У него есть необходимые знания? Мне кажется, такое должно происходить сообща. Разработчики должны рассказать менеджеру об особенностях той или иной платформы и помочь понять отличия.

Архитектурные решения, выбор платформ, технологий, фреймворков, библиотек — задача технического менеджера.


Надо было сразу уточнить, что речь о техническом менеджере. Но вообще, это все касается только крупных команд.
0
ebragim ,  
В первую очередь как раз мелких команд. Когда у тебя 3 кодера, и один из них решает стать незаменимым, начав использовать какой-то специфичный фреймворк или технологию, тем самым ставя под удар всю разработку — от него надо избавляться. Да, на альтернативе будет сложнее, дольше. Зато это будет понятно всем и надёжнее.
+9
SirEdvin ,   * (был изменён)
Способ №1. Сделать не так, как просил менеджер

Клик-бейт какой-то получился. По факту "втихую сделать не так, как написано в ТЗ, что бы переделка заняла большое количество времени".


Способ 2. Не тестировать свой код

Хах, если бы.


Способ 3. Заниматься посторонними делами в рабочее время

Ведь смотреть в код, который компилируется — это так интересно.


Способ 4. Использовать любимую библиотеку/фреймворк, не посоветовавшись с менеджером

Серьезно? То есть ладно с фреймворков (хотя синтегрировать два фреймворка обычно довольно сложно), но согласовывать либы с менеджеров — довольно странная идея.


Мне интересно, а где такие пункты как:


  • Регулярно срывать сроки
  • Писать отвратительный код, который или не работает, или работает так, что бы лучше не работал.
  • Воровать информацию о клиентах
  • Отдавать свою работу на аутсорс
  • Быть токсичным насколько, что начинаешь каждый день с оскорблений.
+1
j8kin ,  
но согласовывать либы с менеджеров — довольно странная идея

Например у нас в крупном банке именно так ибо сейчас эта библиотека MIT лицензию имеет, а завтра уже она платная, а выпиливание ее стоит и времени и денег. Поэтому каждое подобное использование — обсуждается в плане сколько профита от использования мы будем иметь и сколько гемора в случае изменения лицензии. И если при использовании ее для тестирования скорее будет положительный ответ, то в продакшен коде скорее откажут от греха подальше.
+3
SirEdvin ,  
Я прошу прощения, но разве лицензия имеет обратную силу? То есть что вам мешает использовать ту версию, что у вас осталась?
+1
MarazmDed ,  
Я прошу прощения, но разве лицензия имеет обратную силу? То есть что вам мешает использовать ту версию, что у вас осталась?

По видимому, необходимость сопровождать проект. В либах могут быть:
а) косяки
б) дыры
в) кривая архитектура
г) недостаточное покрытие функционала

Любой из пунктов может потребовать обновить либу, и в этот момент может вылезти лицензионный сюрприз.
0
SirEdvin ,  
ну, раз нужна либа, значит нужен ее функционал. И его так или иначе надо будет пилить, так почему не взять либу и не риснуть?
0
arandomic ,   * (был изменён)
Не, никто не говорит: «ни в коем случае не берите либы»
Вопрос стоит в том, что можно сделать так:
1. Взять крутую либу
2. Запилить всё так, что вокруг неё всё крутится
3. Продолжать развивать продукт, обнвлять версию либы
4. Выяснить, что лицензия у нее хоть и открытая и вообще опенсоурс, но внезапно не стандартный LGPL/MIT/Apache и она (лицензия) обновилась между минорными версиями либы.
4. Выяснить что компания, если выкатит продукт как есть, будет должна половину дохода автору либы.

А можно вот так:
1. Хей, менеджер, нам для работы нужна <супер-либа>
2. Менеджер берет в зубы <супер-либу>, отдаёт ее лицензию на проверку приходящему/штатному юристу
3. Юрист говорит «ОК»
4. Менеджер говорит «ОК»
5. Прогер пишет
6. Менеджер записывает либу в свой мегареестр и следит, чтобы лицензия не менялась между версиями.

В первом случае программист вроде как должен следить и за лицензией и за кодом.

Во втором случае программист следит за кодом, менеджер с юристом — за всякой туфтой типа лицензий и отчислений.

UPD:
Правда нельзя исключать, что между шагами 2 и 5 пройдет пара лет и проект станет никому не нужным.=)
0
WraithOW ,  
Ничто, но у вас по сути встает вопрос поддержки — кто и почём будет чинить баги, переводить на новые версии зависимостей и так далее.
0
AllexIn ,  
Ровно тоже самое касается внутреннего велосипеда.
+1
Juma ,  
Регулярно срывать сроки
Писать отвратительный код, который или не работает, или работает так, что бы лучше не работал.
Воровать информацию о клиентах
Отдавать свою работу на аутсорс
Быть токсичным насколько, что начинаешь каждый день с оскорблений.
Видимо за такое не увольняют.
+5
defaultvoice ,  
Способ 5. Просить повышение за несколько недель до сдачи большого проекта

Ну если менеджер понятия не имеет о bus factor и допускает ситуации, когда вся информация о проекте находится в руках одного человека, то он сам себе злобный Буратино.
+8
amarao ,  
Пока выглядит так, что «делать что сказали и не выделываться». Это разумное требование, которое сотрудник может принять, а может поискать работу, где ему дают больше свободы.

… А ещё эта статья подразумевает, что менеджер понимает больше программиста в том, что делает программист. Либо у вас такие крутые менеджеры, либо такие тупые программисты.

… Что вполне вероятно с учётом первого пункта.
+3
+4 –1
DickCancer ,  
Программисты это как правило очень умные и талантливые люди, и при том очень скромные и иногда застенчивые. Я сам лично знаю много примеров как «крутые» продакт менеджеры унижали и обижали программистов. А уж среди «эффективных» менеджеров это в порядке вещей, не поиздевался над программистом считай день зря прошёл! Админов тоже стараются «опустить» но они как правило по зубастие и то что прокатывает с программистом, не прокатит с админом. А вообще если программист выполняет свою работу (по своиму, так как он лучше знает чем манагер) то доставать его придирками явно не стоит!
–6
VMichael ,  
А какой из пунктов вы считаете «придирками»?
Там вроде есть обоснование, можете написать ваше обоснование, почему именно это придирка?
+1
+2 –1
DickCancer ,  
Ну хотя бы четвёртый способ, почему программист должен советоваться с менеджером об используемом фреймворке? Программист может посоветоваться со своими коллегами программистами и дальше уже решить какой использовать. Для менеджера же это просто название, не более. Менеджер ведь не отличит один фреймворк от другого, или возможно я просто с такими менеджерами не знаком?
+6
Koneru ,  
У меня был менеджер. Два года опыта в FrontEnd. И он не мог себе позволить сам решить какие технологии будут использоваться на проекте. Всегда советовался в первую очередь с архитектором и командой которая будет реализовывать. И не потому что он плохой дев был, а потому что понимал, что писать будет не он и уважал мнение ребят.
+1
AllexIn ,  
«Придирки» — сложное слово, не однозначное.
В любом случае — задача управленца контролировать рабочий процесс. В идеале должен быть баланс между свободой и контролем. Тогда команда эффективно работает.
Но в баланс никто не умеет, поэтому либо команда сваливается в свободу и не делает нихрена, либо команда сваливается в контроль, и теряет мотивацию нормально работать — не делает нихрена.
Что характерно, в обоих случаях менеджмент обвиняет команду, и не считает что накосячил.
ТАк забавно на это смотреть, что снаружи, что изнутри.
+2
lair ,   * (был изменён)
Программисты это как правило очень умные и талантливые люди, и при том очень скромные и иногда застенчивые.

У вас есть ссылка на какое-нибудь исследование, подтверждающее хотя бы одно из сделанных вами утверждений (кроме "иногда застенчивые", я не встречал профессий, в которых это было бы не так)? А то по моим наблюдениям программисты — обычные такие люди, с тем же распределением ума, таланта и скромности, что и в других инженерных (и не только) профессиях.


А уж среди «эффективных» менеджеров это в порядке вещей, не поиздевался над программистом считай день зря прошёл!

Ни одного такого менеджера не видел.

–1
+1 –2
DickCancer ,  
Я написал исходя из своего опыта работы во многих командах, и мне не нужны какие либо исследования что бы выразить своё мнение!
0
AllexIn ,  
Ну вы сформулировали «правило», на основании «мнения».
Это не одобряется. Сам таким грешу и регулярно отлавливаю. :(
+3
MaZaNaX ,  
в) Angular был требованием клиента.

Слабо представляю себе ситуацию, когда человек работает на проекте, не зная требования со стороны заказчика. Хотя, если такое происходит, то увольнение, возможно, не самый худший вариант в таком случае
+6
koluka ,  
Причем не факт, что это должно быть увольнение программера… =)
+4
retran ,  
… или как за несколько минут уничтожить свой бренд в глазах разработчиков.
+1
dom1n1k ,  
Как подгорает-то в комментариях…
+3
Vadem ,  
Подгорает во многом от категоричности статьи: не согласовал библиотеку с менеджером — уволить, позанимался делами в рабочее время — уволить, и т.д.
Я конечно понимаю, что речь идёт о целой вёб-студии, работать в которой большая честь,
но вот так разбрасыватсья специалистами может себе позволить далеко не каждая компания.
Может можно сначала с сотрудником поговорить и попробовать решить проблему, а не сразу увольнять?
Конечно, если сотрудник систематически нарушает требования руководства, то тогда надо увольнять.
0
dom1n1k ,  
А по-моему, в половине комментариев категоричности намного больше, чем в статье.
0
yizraor ,   * (был изменён)

По пунктам 1,2,4 — если они программистом повторяются систематически, то вполне. Был свидетелем увольнения по подобным причинам.
Насчёт 3,5 — не знаю, не видел. Но если представить себя на месте менеджера, то чувствую следующее: "меня подгорает с таким человеком работать… не лучше ли с ним расстаться?"

+1
Akuma ,   * (был изменён)
Как написали выше, у вас либо очень умные менеджеры, либо очень тупые программисты.

Способ №1. Сделать не так, как просил менеджер

Пример с дверью слишком «в лоб», тут случай тупого программиста. Если, например, верстальщик начнет сам рисовать макеты, это как раз ваш случай.

Способ 2. Не тестировать свой код

Нет, на проверку в сумме ушло 10 минут вместо пяти. Остальное время — это ваша «бюрократия». Увеличение текста кнопки в пять раз должен был проверить тот, кто это придумал, а не программист.

Способ 3. Заниматься посторонними делами в рабочее время

Расскажите это тем людям, которым нужно больше думать, чем кодить. Понятно что не нужно играть в Дотку на работе, но почитать хабр пока что-то собирается/компилируется/деплоится — почему нет то?

Способ 4. Использовать любимую библиотеку/фреймворк, не посоветовавшись с менеджером

У вас очень крутые менеджеры. У меня около 70 зависимостей только в nodejs. Они правда будут проверять каждую?

Способ 5. Просить повышение за несколько недель до сдачи большого проекта

Нужно было назвать этот способ «Шантаж для повышения», т.к. в том чтобы просить повышение не вижу ничего плохого. Не хотите повышать — просто откажите человеку. Если он вам за это загубит проект — значит нет самоуважения у такого программиста и гнать его надо было еще на этапе собеседования.
0
Grigorenkovic ,  
Показываешь результат — можно нарушать все правила. Заваливаешь проект — любая мелочь ведет к увольнению.
+6
Scf ,  

Странная статья. С одной стороны, пишутся разумные и правильные вещи, а с другой, пишутся они так, что воспринимается очень негативно.


Способ №1. Сделать не так, как просил менеджер
Почему так неправильно. Часто менеджер знает о проекте больше, чем программисты.

И держит эти знания подальше от программистов, чтобы они не смогли занять его кресло


Способ 2. Не тестировать свой код

Увольнения за ошибки в коде рождают единственную верную стратегию — молчать об ошибках и не никогда не признаваться.


Способ 3. Заниматься посторонними делами в рабочее время

самообучением и исследованием заниматься будешь в личное время, перерывы в работе — воровство у компании.


Способ 4. Использовать любимую библиотеку/фреймворк, не посоветовавшись с менеджером

см. Способ №1. — диктат как средство упрочнения власти менеджера


Способ 5. Просить повышение за несколько недель до сдачи большого проекта

А кормить завтраками о повышении "а ты попаши сначала за троих пару лет, там мы тебя и повысим до Самого Главного Программиста с тем же окладом" не шантаж, да.

+3
Anshi85 ,  
Не вижу нечего зазорного чтобы попросить прибавки к зарплате во время проекта, если я показал и доказал свою полезность в проекте и в компании целом! Почему менеджер сразу рассматривает сколько займет времени вникнуть новому специалисту если меня уволить за такую «наглость»? А вдруг менеджер после завершения проекта похлопать меня по плечу и все? Обычно бонусы и премии за проект обсуждаются до начала работы на проекте, а не после, после тебе скажут что лишних денег нет, надо было до проекта просить. В общем менеджер как то однобоко мыслит, получается программист только должен, а прав у него нет.
+1
M_AJ ,  
Менеджер просит сделать комнату с дверью. Но по ТЗ в двери нет ручки, вместо нее педаль. Программист видел в жизни тысячи дверей и решает, что менеджер сошел с ума. Он пытается спорить, а потом делает «правильно». Его увольняют.

Раз уж вы решили разговаривать на языке аналогий… Менеджеры забыли, что двери нужно открывать с двух сторон. Когда программист спрашивает где вторая педаль, менеджер говорит ему: "делай по ТЗ, заказчик вторую педаль не заказывал!". Программист, чтобы его не уволили делает по ТЗ. За день до сдачи двери, случайно зашедший клиент спрашивает, как ему открыть дверь с другой стороны. Тут менеджер понимает, что в ТЗ вроде как сказано, что двери должны открываться в обе стороны, и вообще это требование пожарной безопасности. В общем, менеджер, нехотя признав свою ошибку, поручает программисту СРОЧНО сделать вторую педаль, говоря, что если он не сделает её к завтрашнему вечеру, то заказчик останется очень недоволен, а вся фирма (и он не исключение) останется без премий. В результате программист работает всю ночь и весь следующий день, кое как прилаживая вторую педаль, а менеджер, довольный тем, что решил проблему, уходит в шесть.

+4
andreysmind ,  
А там во всех пунктах один и тот же менеджер или каждый раз разные?
Там получился такой собирательный образ суперменеджера, который и требования заказчика знает и в фреймворках разбирается и зарплатами заведует?

Менеджер просит сделать комнату с дверью. Но по ТЗ в двери нет ручки, вместо нее педаль. Программист видел в жизни тысячи дверей и решает, что менеджер сошел с ума. Он пытается спорить, а потом делает «правильно». Его увольняют.

Я так понимаю, что информация о том, что клиент — бизнес производящий педали так и не была донесена до программиста? О чем спорили тогда?

А читать статьи для повышения квалификации это посторонние дела или еще нет?
А сходить прогуляться потому, что решение задачи в голову не идет — это воровство или нет?

Какой-то рашен бизнес в худшем его варианте типа «Я начальник, ты дурак».
+1
PMVyatkin ,  
Что то мне не очень нравится утверждение про то, что программист продает свое время.
Если вы покупаете разработчиков — от звонка до звонка, это очень странно. Многие разрабы делают задачи на стороне, и если в ущерб основной работе — да, это нечестно. Но еще чаще человек ставит приоритет на основной работе, и время на компиляцию кода\просто отдых тратит не на фриланс (сроки которого можно сдвинуть) а на обучение.
ИМХО надо договориться на берегу, сидит разраб от звонка до звонка и в вечер релиза уходит домой потому что 7 вечера и электричка в Мусохранск уходит, или мирится с тем что разраб прикрывает такие вещи но в свободное время ковыряет фриланс\петпроекты\качается.
+3
maslyaev ,  
Способ №1. Сделать не так, как просил менеджер
Часто менеджер знает о проекте больше, чем программисты.
Часто, но реже, чем наоборот. Увы.
Кроме того, я ни разу не сталкивался с тем, чтобы ТЗ (то самое, в котором написано про педаль, а не ручку) писал менеджер. У менеджеров, извините, другие задачи. Если менеджер пишет ТЗ, то в проекте уже что-то пошло не так.

Способ 3. Заниматься посторонними делами в рабочее время
Ты получаешь деньги в обмен на то, что продаешь свое время.
Если прогер продаёт своё время, то это сигнал, что его работу нужно отдать на аутсорс.
Не знаю как кто, но я получаю деньги не за затраченное время, а за решённые задачи и устранённые проблемы. В мире не должно быть ни одной живой души, которой было бы не всё равно, тупил я в задачу все положенные 8 часов, или сначала 4 часа доводил себя до кондиции чтением статеек на Хабре, потом за 3 часа сделал, а потом час на том же Хабре умничал в комментах.
Когда работник умственного труда относится к работе как к продаже своего время — это, я считаю, катастрофа, притом сразу для всех. Гораздо правильнее и продуктивнее к работе относиться как к взаимовыгодному сотрудничеству. Работник выдаёт полезный организации продукт, а организация обеспечивает наличие необходимого и достаточного для самореализации работника как работника.

Господа администраторы, как бы вам так научиться перестать относиться к сотрудникам как к скоту? Я понимаю, что в ваших MBA вас этому не учили, но почему бы не попытаться дотянуть самообразованием?
0
xfaetas ,  
Заниматься посторонними делами в рабочее время

А если разраб формошлепит ваши ТЗ за половину выделенного времени — чем ему занять оставшееся?

+1
32bit_me ,  

Всех уволю, один останусь.

0
kinall ,  
Почему-то мне кажется, что автору статьи следовало заменить слово «менеджер» на слово «тим-лид». Почти всё осталось бы справедливым, но гнева в комментариях было бы значительно меньше.
0
koluka ,  
ну да, если в боевой задаче «замполит» поменять на «боевой командир» — количество возмущенных заметно поубавится, но минус ли это подчиненных или недоработки самой задачи…