Pull to refresh

Comments 52

Эта статья просто обязана стать «топиком добра»
коли пошла лошадиная тема:
И не вставилось. еще раз:
А вы настойчивый.
(хотя да, закончить эти попытки комментом «а, ничего не получается» было бы еще тем обломом и интригой)
Продолжайте эту тему. Ваши «мысли вслух» достаточно интересно читать.
Сам, проходил такой путь :), было желание создать рай в отдельно взятой компании — получилось, только если это большая компания и для нее IT это новомодная (инновационная) игрушка (направление), где цитата «ничего посчитать нельзя, соответственно все потраченные деньги — это расходы на перспективу и их считать не надо. Условно решили, что это не будет больше 1-2% от маржинальной прибыли компании»

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

Это уже другая история.
Да, мой взгляд и опыт актуален для большой компании.

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

Не поймите меня не правильно, я согласен с вами, что не всё легко и гладко и бизнес-эффективность тут выходит на первый план. Но, всё-таки, это больше пособие о «хорошем» со стороны как исполнителей, так и руководителей, ведь 2\3 своей жизни мы проводим на работе, и она должна быть не только источником материального дохода, но и источником радости. По крайней мере, надо к этому стремиться начиная с самого низкого уровня и кончая стратегией компании. Так жизнь должна стать лучше — в зависимости от нашего вклада, как бы это избито и наивно не звучало.
Я только — за, все должно быть положительным :)
Если на работу бежишь и не важно кто ты менеджер или разработчик, значит климат системы сделан правильно и ты показываешь производительность на 150%.

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

А так же есть интересная статья "Управление без управления"
Очень интересно и занимательно. Особенно потому что я простой разработчик, но к рабочему процессу тоже присматриваюсь.
> Никогда, ни при каких обстоятельствах не давайте повод разработчикам делать чужую работу даже по их инициативе

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

Грубо говоря, у вас в задачах реализовать классы multiplication, а у ваших коллег — division и root. Так вот делать все скопом математические функции, даже если ваш коллега замешкался с кубическим корнем не следует без должной мотивации с вашей стороны; как и вёрстку сайта за девочку-дизайнера, если вы не собираетесь с ней вместе прийти за ручку и доложить о том, что вы помогли этой девочке и с последующем видите себя вправе выражать своё экспертное мнение, по сути — беря ответственность на себя.

Как я писал ниже в комментариях, что если у вас есть цель и реакция на вашу активность — без проблем. Главное будьте готовы принять ответное действие, в случае, если результат вас не устроит, чтобы вы впоследствие не опустили рук из-за своей недооценённости или перегруженности.
Ах молодость… Пони, графики, мечты о справедливости :) Жажда денег и комфорта к сожалению превалирует над всеми этими целями и сплоченностями.
Что ж, естественно, почти что львиная доля мотивации — это финансы и комфорт, социальные пакеты и защищённость. Но всё-таки всем, наверное, хочется помимо дома иметь и любимую работу, коллектив. В конце концов, главное чтобы жажда комфорта и денег в итоге не оказалась ложной, а жизнь не была прожита лишь в погоне за ними.
Жизнь несколько прозаичнее. Жажда комфорта и денег не может оказаться ложной, поскольку это вынужденная мера, а не прихоть. Кушать всем хочется, а еще и семью кормить. Отсюда и меркантильный взгляд на жизнь. Это очень грустный, но и решающий фактор. Предложите сотруднику повышение, с улучшенными условиями труда, большей ЗП, перспективой роста и «сплоченность» эта резвеится как пыль на ветру. Будут конечно фразы «я очень рад что работал с вами» и «я никогда не забуду», но внутри он уже будет грезить новым местом. Если это не клинический случай, конечно.
Безусловно. Однако имея почти одинаковые условия, но имея на одной чаше весов, допустим, разницу в 10% зарплаты и интересный проект с коллективом с другой — шанс выбрать второе при худших материальных условиях для инженера выше. И именно эта разница — кредит доверя и рычаг руководителя, которыми вне материальных ценностей можно управлять и мотивировать сотрудника.
Вопрос в балансе и пороге.
У материальной стороны, как правило, есть некоторый порог насыщения, после достижения которого ее привлекательность начинает стремительно уползать из ТОП-а приоритетов.
При этом каждый стремится его достичь, правда?
Правда, но только для тех «каждых», кто его еще не достиг.
Иллюстрация заставляет задуматься об инженере-руководителе как о сферическом коне в вакууме. А так очень интересно почитать следующие части.
Вы хотели сказать, сферическом пони в вакууме? ;)
Спасибо. Интересное, кстати сравнение.
Наверное поломка шаблонов исполнителя будет переводом всей сферичности руководителя к тяговой лошади, на которую могут положиться его подчинённые.
«Это в Google сотрудник имеет право 20% своего времени заниматься своими проектами»

Ведь это давно отменили, разве нет?

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

Смотрите, получение опыта — это очень хорошо, безусловно. Особенно когда это возможность взяться за новую работу или область. Однако регулярно выполняя «за того парня» такое поведение просто снизит вашу мотивацию. Вначале мотивация «я сделал больше всех\я решил сложную проблему, которую не смог сделать N, я молодец», а затем отношение «а какого я делаю это за других, мне больше всех надо? Мне платят за это?». Можно таким образом попытаться замелькать перед начальником, и если у него есть возможности и если он не дурак, то это должен оценить. А если нет? Сколько вы так планируете проработать? Сколько мириться, что вашу инициативу и ваши старания не оценивают? А сможете ли вы конвертировать ваши усилия на текущей работе в знания, которые вы в последствии сможете использовать?

Так чтобы сказать, хорошо это или плохо — надо поставить цель. И установить определённый дедлайн, что мы к нему хотим получить от своих стараний. И по достижению не продолжать в том же духе, а действовать. Идти к начальнику\менять работу\организовать своё дело\саботировать работу\постить поняшек.
Спасибо за развернутый ответ. Все понял, цели поставлены, сроки установлены)
«Ведь это давно отменили, разве нет?»

Нет.
Дорогие мои инженеры, разработчики и девелоперы!
Не ходите в манагеры, там вам будет плохо!
Рискую быть «обминусованным» но с темой «уникальности людей IT» вы переборщили. Рассмотреть ситуацию с разных сторон всегда интересно, к сожалению так и не увидел разных взглядов на одни и те же проблемы. К сожалению когда то давно у меня ситуация сложилась наоборот, и теперь я смотрю на работу по ту сторону от начальства, забавно так видеть обратную сторону. )
простите за тавтологию, писал отвлекаясь
Что считать уникальностью: те же две руки, две ноги, голова одна. То, что «звёзды» IT не похожи на среднестатистических обитателей офисов — факт. Как фактом будет, например, непохожесть качественных работников научной сферы. Думаю, тут дело в количественном отношении. Люди, имеющие способности к IT не столь привязаны к обычным удовольствиям жизни и набору условий, как те же менеджеры по продажам, для них решающими факторами будет с большей долей вероятности девайс, над которым они работают, а не близость от дома. По крайней мере, до поры до времени.

>к сожалению так и не увидел разных взглядов на одни и те же проблемы
Вы про руководителя и рядового разработчика? Я не ставил такой цели, я лишь указал знакомые ошибки и методы управления и корректировку их основываясь на опыте рядового разработчика. Моя позиция здесь — что допущения и упущение во взглядах и тех и других — плохо, её надо избегать.
Мировоззрение разработчика очень точно описано, руководилам читать обязательно
Не структурированно и сумбурно. Но кажется очень и очень правильным.

Образцом раскрытия этой темы считаю «Peopleware». Этот пост — отличное дополнение.
Когда компания растет и пересекает некую границу, то происходит «отдаление» отдела IT, отдела разработки непосредственно и менеджеров, продажников, а основное — от руководства (продажникам и программистам могло и изначально друг на друга наплевать было, а вот руководство всегда должно понимать и видеть истину). И разработчики, которые, зачастую, находятся в конце производственного процесса или не являются по ощущениям важным звеном (именно по ощущениям) начинают ущемляться, а всем все больше и больше начинает казаться, что IT отдел ничем не занимается.

Это как хороший админ, который сидит на месте и ничего не делает, а плохой, работает в поте лица (знаю реально примеры, когда у крупных интернет провайдерах проводного интернета увольняли хороших админов, потому что они «ничего не делали», а те, которые постоянно в мыле бегали продолжали работать).
> Более того, это повод задуматься, если один из сотрудников изучает мануалы, читает тематические ресурсы, и подходя к коллегам с желанием поделиться “я тут такой фреймворк нашёл” слышит в ответ “что ерунда, нам это не интересно”.
Про меня.
Желаю всем интересных разработок и конструктивных идей. И чтобы начальство было прогрессивным и понимало вас.
Эээх. Ваши бы слова… да нашему руководству в голову…
Благо прямой начальник в отделе понимающий грамотный мужик… Сам работал как мы, все четко делает.
Пирамида Маслоу. Однако тезис, и не только мой, что она даёт не исчерпывающее объяснение, и для IT-сферы бывает спутанной, и удовлетворение потребности более высокого уровня могут превалировать над низменными. Пусть и в очень ограниченных масштабах.
Пирамида Маслоу во всю пиарится везде — хотя сам Маслоу таки признал её ошибочной. Странно правда?
Sign up to leave a comment.

Articles