Pull to refresh

Comments 40

Как тут не вспомнить 3 добродетели программиста по мнению Ларри Уолла: «Laziness, Impatience and Hubris».
Hubris — высокомерие (кому лень гуглить)
Помоему, в оригинальном переводе (не помню чьём), «Hubris» — это «Гордыня».
Что, конечно, радикально все меняет
Автор, спасибо за статью. Она позволила пересмотреть мое текущее видение.
В идеальном мире так и есть.
В реальном мире — увы, все совсем не так. Например, случай с одного из прошлых проектов — рукотдела (РО), разработчик (Р) и техдиректор (ТД) совещаются — обсуждают новую фичу, которую можно поставить клиентам.
РО утверждает что фичу можно сделать за 2 недели, разработчик говорит что это выглядит малореальным, ТД говорит — принимайте решение, либо делаем, либо нет. РО берет под свою ответственность фичу, и они уходят.
Ценой просиженных вечеров и 4 проведенных на работе выходных — фича готова, РО — герой, который приходи с «я же говорил это реально», разработчик выкладывает резюме на НН и через 3 недели уходит в другой интегратор, усердствовать там.
Стоило ли тут проявлять усердие или надо было сразу жестко отказаться для разрабочика?

Вот кстати да, думал, добавлять или нет ещё одно качество в список, видимо надо было все-таки добавить.


Внимательность тоже важно развивать.


В статье уже написан ответ на ваш вопрос.

Хм, здесь речь не про то, что надо думать прежде чем делать.
А про то, что в современном мире важную роль играют политические игры с руководством — кто кого лучше менеджерит, кто как представляет результаты своей работы, кто ценный для компании кадр (потому что работает кое-как, но с редким стеком), а кого хоть завтра гони на мороз за одну лишь мысль о прибавке, т.к. с такими знаниями как у него людей хоть отбавляй.
Могу в целом сказать одно — надо быть на своем месте. Если вы суперкрутой ИТ-спец, не идите работать в больницу — вас там не оценят. В больнице главные врачи, и будь вы круче всех в своем городе — вы так и останетесь ненужным и незамеченным. Ищите то место, где ваши навыки востребованы.
Примеров на моем веку была масса — плохие разрабы не сумев создать нормальный код, переходили в евангелисты и очень неплохо поднимались на этой должности, очень плохой ПМ (не умел работать с высокопоставленными лицами заказчиков) перешел в саппорт и стал ИТ директором в крупной компании, плохой внедренец в одном месте стал отличным и выскооплачиваемым тестером в другом месте, миддл на Delphi ушел на джуниора на Java и через 2 года стал получать в 2,5 раза больше своих бывших коллег, работая в соседнем офисе, плохой учитель инглиша (без опыта в ИТ вообще) за 2 года стал начальником отдела аналитики в западной компании благодаря тому, что офигенно разруливал вопросы из-за отличного знания языка…
Если вы хотите достичь успеха — просто подумайте что вы можете делать хотя бы нормально, и найдите того, кто готов ценить это (и платить за это деньги).

Ну с этим вашим сообщением я вовсе и не спорю) Однако. Во всех этих вариациях развития событий способности усердно делать своё дело, оптимизировать процессы и гибко мыслить будут только увеличивать КПД человека)

Достаточно одного раза жестко настоять на своем, и тогда вас либо уволят, либо будут считаться с вашим мнением.
А чтобы не бояться увольнения, нужно постоянно ходить по собеседованиям и держать руку на пульсе.
Подобный случай отлично описан в книге Роберта Мартина — Идеальный программист. Там достаточно много уделено внимания как раз таким случаям как жестко отказать или когда следует браться за реализацию фишки. В приведенном вами примере разработчику следовало четко сказать что за 2 недели — не сделать, а за 3-4 — да, реализуемо. И никаких «если постараться то за 2 успеем»
Ну разраб так и сказал. На что руководитель ответил — «Я точно знаю как сделать это за 2 недели, и я уверен в этом на 100%. Это мое решение, как руководителя, ты исполнитель, делай что говорят и не лезь в менеджмент».
Дело в том, что цели участников процесса должны пострадать. В моем примере выше — цели менеджера краткосрочные, показать как он круто меняет процессы и повышает производительность команды (в краткосрочном периоде).
У разработчика же цели долгосрочные — работать в компании, где нет диких овертаймов. Поэтому он, видя что началась такая кухня, задачи то сделает, только и компанию надумает сменить.
В этом и косяк — должна быть цель сделать крутой продукт. Разработчику надо было держаться до конца и говорить что если срок 2 недели то фишка не будет полностью готова и получится недоделанная и кривая. Или в процессе сказать руководителю отдела что как бы он ни хотел чуда не случится и нужно отодвигать сроки или обрезать функционал. В общем куча вариантов как обойти то что руководитель отдела захотел повыеживаться несмотря на предупреждения
Цель сделать крутой продукт всегда есть. Не всегда есть цели по срокам, бюджету, понимание того что надо сделать, система мотивации и т.д. и т.п.
В этом случае — разработчик почти ничего сделать не может. У него нет управленческих функций, на принятие решения — он не влияет (его голос совещательный и может быть проигнорирован).
Это проблема системы менеджмента, где исполнители и менеджмент находятся по разные стороны продукта вообще. Вспомните пример, когда на заводе инженер придумавший как сэкономить заводу кучу денег получал 100 рублей, его начальник — 1000 рублей, а директор завода — Ленинскую премию?
В скрам-команде — участники команды вместе решают сколько могут взять, такого минуса там нет — именно поэтому скрам-фреймворк и популярен — он почти гарантирует то, что люди сделают под чем подпишутся.
А в конкретной системе менеджмента «я начальник — ты дурак, ты начальник — я дурак» быть ответственным и исполнительным — часто не выгодно для исполнителя.
В таком случае надо перескочить через голову с намеком что прямой руководитель не хочет прислушиваться к голосу разума и фишка будет зафейлена за 2 недели без вариантов вообще. Если же никто так и не прислушается то или со спокойной совестью делать без переработок что возможно и потом говорить «я же говорил» либо сваливать из такого места. Быть слишком исполнительным в таком случае себе вреднее, потом все сроки так и будут ставиться с учетом того что чувак в экстренном случае пропустит свои выходные и будет перерабатывать потому что ему сказали что надо
Увы, с переработками обычно по другому — менеджер подходит и просит «Переработай сейчас, потом сочтемся» или наиболее распространено «Мне вообще все равно сколько вы сидите, хоть не ходите на работу вообще, лишь бы были сделаны все фичи». Вроде как и не причина уходить, т.к. не перерабатывать предлагают, и вроде не постоянно, но на самом деле это первый тревожный звоночек говнеца, попахивающего неоплачиваемыми переработками.
Я это очень близко к сердцу воспринимаю, т.к. знаю лично десятки менеджеров, заставляющих, уговаривающих и вынуждающих людей к диким переработкам (овер 20-30 часов в неделю вне основного рабочего дня) и не отдавших им ничего в замен.
На месте программиста я бы просил либо оплату сверхурочных, либо оплачиваемые отгулы. Именно для того, чтобы руководитель понимал, что такие вещи не даются бесплатно.
Согласен. Но, беда в том, что нечестные руководители обычно говорят — давай еще спринток, и там об отгулах поговорим и далее с этой темы соскакивает, или же дает отглул с очередным условием — «да, отгул конечно тебе положен, ты прав, но сначала заставь работать без проблем интеграцию и иди конечно»
Ну и по ТК работа в выходные дни оплачивается по двойному тарифу, отгулы же по одинарному.
Ну в данном случае разработчик уходит от руководителя-карьериста (РО) и правильно делает. С усердием это ни как не связано. Любые оценки должны быть обоснованы и к ним должно быть добавлено 25-30% на риски и баги. А если руководитель готов брать «под свою ответственность» чужую работу, то пусть идёт работать в госслужбу — там таких любят…

В нормальной команде эта ситуация выглядит так: Разработчик предоставляет оценку на фичу и эта оценка обсуждается (аргументировано). Если фича не влазит по времени или бюджету, то либо она убирается, либо режется часть функционала. (Вот тут вступает в игру РО, чтобы оградить своего разработчика от овертаймов, но в то же время реализовать пожелания). Т.е. РО и разработчик должны играть на одной стороне поля…
Не могу не согласится, в нормальных компаниях так и есть. Но в множестве других практикуется принцип — «мне пофигу сколько вы тратите на работу, лишь бы она была сделана», где якобы люди (не на руководящих позициях, и это важно!) уходят от работы по часам к результату (считай, свой бизнес открывают с ответственностью).
Я тоже сторонник работы на результат, а не лишьбы 8 часов в день отсидеть, но тут вопрос в том, что принцип: «мне пофигу сколько вы тратите на работу, лишь бы она была сделана», не означает отсутствия планирования и оценок. Это отично работает когда и руководители и подчинённые адекватные, но, к сожалению, это часто трансформируется в забивание на работу со стороны подчинённых или установлением заведомо неисполнимых сроков со стороны руководителя.
Я думаю что любой адекватный человек — сторонник работы на результат. Но есть нюансы — результат не всегда очевиден в среднесрочной и долгосрочной перспективе, платят тебе все таки не за результат (зарплата — это продажа часов, а не прибыль с результата).
И тут в ход идет умение нормального менеджера договариваться и контролировать. Вкратце — сотрудник спокойно работает 8 часов (и задача менеджера — контролировать что он работает это время а не валяет дурака).
Если же у сотрудника возникает необходимость поработать больше 8 часов — это согласовывается (!), и переработки фиксируются. Если же человек остался на часок поковырять код в удовольствие, или же потому что сам так считает нужным (например для развития себя) — это тоже нормально.
Далее, периодически, переработки считаются и обмениваются на деньги/отгулы.
И это нормально. А ненормально — договариваться с людьми при выдаче оффера на 8 часов, а затем используя менеджерские приемы заставлять их работать больше (значительно больше) бесплатно, лишая сотрудников времени на развитие и дальнейшего карьерного и финансового роста.
Самуил Маркович, Вы сильный, Вы справитесь! — Яша, я — умный, я даже не возьмусь!
Ну нормальные же технические статьи писали. А тут вот это…

Одно другому не мешает, технические никуда деваться не собираются, и вчера кстати я запостил сразу две статьи, эту и "техническую") Я считаю что важно объяснить и эти моменты, в особенности новичкам. Как там ваш ларавел-коллектив кстати поживает?) Сто лет не видел вас, не общался.

Довольно разрозненно. «Старички-активисты» получили, что хотели, прокачались, и теперь каждый занят своим делом, в основном. Новички в большинстве своем слабоваты и/или не очень активны. SerafimArts сейчас пилит graphql-фреймворк на php — получается неплохо.
принцип KISS — Keep it simple stupid!
UFO just landed and posted this here
Сударь, вы стали жертвой ошибки выжившего. Во многих случаях усердие приводит к отрицательному результату. Вместо того, чтобы в определенный момент отбросить неудачное решение и попробовать новое, человек продолжает усердно трудиться над мертвым решением. Альтруизм в свою очередь приведет разве что к успеху твоего руководителя. Так что все очень спорно.

Опять про усердие… В статье всё расписано на эту тему, почитайте внимательно пожалуйста. Текста-то всего ничего.

Я бы добавил «умение видеть работу», целеустремленность, упорство.
Именно упорство нужно чтобы превозмогать трудности. Так же и трудности в постижении нового. Когда ты не бросаешь после десяти попыток, а делаешь еще пять.
Целеустремленность нужна, чтобы видеть конечную цель. Не отдельный участок работы, а конечный результат всей твоей деятельности. Чтобы отличать когда твоя работа двигает проект вперед, а когда ты съехал не в том направлении или топчешься на месте.
А усердие, оно само по себе ведь такое… Можно сильно «потеть», без промедления хвататься за любую задачу, но при этом в итоге совершать бесполезную работу.
«Хуже ленивого дурака только дурак усердный.»
Очень тоскливо поддерживать код, написаные по принципу «терпение и труд все перетрут». Конечно, проевив должное усердие, с помощью «грузиков и противовесиков» можно заставить работать любую систему. Но всем будет лучше, если так делать не будут. Уердие хоошо только если идет в паре с профессионализмом, иначе вреда будет гораздо больше, чем пользы.

Почитайте статью более внимательно, вы уже третий, кто говорит о том, о чём в ней и рассказывается.

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

К примеру, люди дышат всю жизнь. При этом, обычно не прилагают к этому никаких усилий. Так как люди охуенно замотивированны на это! Не будешь дышать, сдохнешь. Обратите внимание на своё дыхание, какое оно у вас в этот момент. Спокойное, мерное, глубокое, поверхностное, прерывистое, затруднённое, быстрое, медленное? Думаю пол минуты назад вы и не задумывались об этом. Если задумывались, то у вас проблемы со здоровьем и надо что-то делать.

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

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

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

Отчего у вас низкая мотивация и нужны дополнительные усилия? Это отдельный вопрос.

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

Многие руководители хотят что-бы работники работали лучше и больше, но не желают вознаграждать людей за труд.

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

Ну как тут сказать. Психология психологией, я согласен что в целом вещь важная, но про мотивацию тоже есть забавный троллинг от какого-то мужика.


Мне вот тоже как-то не надо ни книги читать, ни курсы по мотивации проходить, чтобы быть замотивированным в том, чтобы быть усердным. Мне просто на каком-то этапе жизни надо было понять, что без усердия многое пропустишь и мало сделаешь. Вот и всё. Теперь я стараюсь быть усердным, а не валяться на диване целый день и плевать в потолок. Наверное, можно сказать, что это и есть моя мотивация. И в какой-то степени я сейчас этой статьей постарался замотивировать остальных.


Короче, не надо так к словам придираться, и не думаю что если я там слово "мотивация" нигде не упомянул, то я никого ни в чём сегодня не замотивировал)

Использование точной терминологии, повышает эффективность коммуникации. В свою очередь использование не однозначных терминов, ведёт к «размыванию» эффективности.

Исходя из словарей, слово усердие это положительный термин. Исходя из отношения комментаторов, скорее отрицательный.

А так как смысл коммуникации заключается в той реакции которую она вызывает, то Ваш безусловно положительный порыв вызвал скорее отторжение, чем принятие.

Так же, усердие это результат, мотивация причина. Если есть проблема, то решать надо причину, а не бороться с результатом.

Простой пример из возможно знакомой вам области. SQL сервер. База данных. Тормозит. Что делать?

Борьба с результатом, это повышение частоты процессора -ров, увеличение объёма ОЗУ, перенос системы на SSD. И не факт что проблема будет решена.

Борьба с причиной, это оптимизация SQL запросов к базе данным. Есть вероятность что проблема будет решена без изменения текущей конфигурации сервера.
Ну и так далее.

В общем пока отсутствие усердия «прямо больная тема нашего СНГ'шного мира» будет решаться через борьбу с результатом, всё будет как и было.

Хотя… Теперь с новым президентом и новым премьер министром, всё изменится! Ух заживём!!!

Я ваш посыл понял ещё в вашем первом сообщении, спасибо за разъяснения. Своё мнение о "мотивации" я тоже разъяснил, надеюсь что и вы меня поняли. Спасибо.

Я бы наверное так сказал: мотивация — это отдельная большая тема, и она как раз не является неким "личностным качеством" человека. Скажем, вы можете легко увидеть разницу между ленивым и усердным персонами, если посадите их работать над одним проектом. Можно будет увидеть, что в одних и тех же условиях один делает больше, а другой делает меньше. Вот и вся метрика, как-бы. Я писал об этом.


А мотивация — это дело полезное в целом, да. В том смысле, что хорошо если руководитель стремится замотивировать своих сотрудников премиями и справедливой оценкой их труда. Но это тема отдельная и в рамки этой статьи не входит) Надеюсь вы поняли меня.

Sign up to leave a comment.

Articles