Комментарии 72
Хм... Видимо, пора все же менять работу.

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

На самом деле административное устройство - вот чего не хватает 99% проектов, в том числе многим из тех, что мне удалось консультировать. Все очень креативны, а организованность традиционно страдает.
Немножко не улавливаю, к чему вы клоните. Не хватает управленцев? Или не хватает просто устаканивания процессов управления?
Все пункты весьма правильны. Почитайте Peopleware, этой книге лет 20, что ли, уже, но актуальность она не потеряет никогда.

Административные функции по налаживанию процессов - полная ерунда на всех этапах. Они, конечно, важны, но провалы вовсе не из-за этих функций происходят.

Кроме того, член (количество лет в отрасли) у меня больше.
Почитайте Адизеса о четырех функциях лидерства. Не одну из функций нельзя ставить во главу угла. В данном случае все перевешивает предпринимательская функция, что есть однозначный дисбаланс. Я ничего не имею против этой функции просто потому, что я сам яркий представитель именно этого (креативного жанра) и долго искал тех членов команды, которые могут меня дополнить (сбалансировать).

Рад за количество лет :) но аргумент как мне кажется последний :)
Удел одиноких гениев отрицать администратвную функцию.

Почитайте Deadline как более позднее сочинение на эту же тему. Не смотря на поверхностность (Адизес на порядок лучше) изложения, административные функции там прописаны достаточно подробно.
Адизес пишет про вообще управление, судя из аннотаций к книгам и их отрывкам. В данном случае разговор идёт не о компании в целом, а конкретно о разработчиках. Согласны, что работать с топ-менеджментом, продавцами пирожков и программистами надо по-разному? Думаю, да.
Обсуждаемая публикация как раз про разработчиков. Никакого дисбаланса здесь нет - это и есть описание работы одной из функций.
Для других функций должны быть другие рекомендации. Иначе получится каша.

Количество лет было шуткой, а не аргументом.

Deadline читал. Прописанных административных функций не заметил. Не подскажете пару мест? Можно без цитирования, своими словами.
Возможно, мы говорим разными словами об одном и том же.
У меня опыт таков, что программистам давалась возможность "играться" и "учиться", но только с тем, что 8 часов должен отработать при любом раскладе, поэтому некоторые программисты приходили в восемь утра, а уходили после семи вечера. Такова реальность: как только ты останавливаешься в развитии, ты отстаёшь за другими и постепенно отбиваешься от коллектива.
Ну, тут хоть -20 сделай, а опыт у меня действительно такой. И я сам пока для себя не определился, какая она, оптимальная схема. Давать волю работникам работать много или не давать... пинком с работы же не выгонишь. Всё-таки, у почасовой оплаты есть свои особенности.
Выгонишь. Можно просто отключать электроэнергию в помещении.
Много работать вредно.
я бы с радостью взял на работу разработчика, для которого эти 9 вещей действительно имеют большое значение. :)
Ничего вам "минусовать" не стану, хоть и разит от ваших слов цинизмом и жадностью...
цинизм - в определенной мере да, но без этого (в разумных пределах разумеется) не выжить в более-менее крупном проекте. А вот с жадностью... категорически не согласен. Если Вы не поняли мою фразу, то расшифрую - разработчик, для которого действительно важны эти 9 вещей является очень ценным сотрудником, поэтому его "оторвут с руками".

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

Разработчики то, разработчики сё... Как про хомячков написано.
Просмотрел оригинальный пост. Лаконично переведено. Rob Walling, в принципе, нормально написал :)
Я сужу по себе: читать длинные тексты мне сложно, если они меня чем-то сильно не затягивают и не завораживают. Вот, и опускаю некоторые примеры и прочие отступления в переводе.
По сути всё точно написано. Нехватает лишь упоминания о деньгах. Рано или поздно "разработчик", соизмеряя свою лояльность проекту и работодателю со своими доходами, набредёт на нелицеприятные выводы. Во всяком случае, так было на моей прошлой работе.
P.S. Нет выполнения перечисленных пунктов? Меняй работу.
Для этих целей есть опцион. Зарубежом - это обычная практика.
У нас же разработчики сами часто отказываются от опциона. Отечественный менталитет не принимает эту схему.
Как хорошо, что у меня сейчас именно такая работа!!! Но и про деньги так же сказано - я реально практически потреля 20% при переходе (точнее ничего не потерял, но на старой должны были поднять - неуспели). Всем желаю счастья заиметь такую работу!
Роба Уаллинг читает мысли...
статью отправил на печать. с пометкой ":Директору"
Директор ведь может понять это так: "Дайте мне интересную работу и не повышайте мне за это зарплату!" ;))
Есть шикарная книжка которая описывает эти проблемы в похожем стиле - "Deadline. Роман об управлении проектами", Тома ДеМарко. Рекомендую.
Абсолютно точно. Обязательно к прочтению руководителям проектов.
Я вот нашему исполнительному ссылочку кинул. Но похоже ответа не будет -_-
Это всё конечно правильно. Но правильный разработчик должен зарабатывать достойно. Нельзя эксплуатировать его нематериальные принципы вроде желания сделать мир лучше.

Надеюсь, следующим шагом будет написание подобных принципов для руководителя.
Эти принципы частично и для руководителя. Четверть даже напрямую.

Кратко можно описать и тех и других очень просто:
работнику надо любить свою работу;
руководителю надо любить свою команду.

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

Реальные сроки. Классная позиция. Будто вопрос о сроках появился с появлением программистов. А огромные фрески во Флоренции великие художники тоже разрабатывали по "реальным срокам"? Или Микеланджело был менее их достоин, чем программист? ;)))

Бюрократия. Тоже вопрос куда как спорный. Руководители создают бюрократию не от хорошей жизни. И если бы все разрабатывалось само и без проблем, то никакой бюрократии бы не было, или она была бы незаметна. Если принять в предположение, что все разработчики, которые работают в компании ИДЕАЛЬНЫЕ разработчики, то бюрократия отпадет сама собой. Но в реальности мы сталкиваемся с ленью, отсутствием интереса, попинываением работы и проч. Причина этих процессов бывает и в руководстве и просто в человеческой природе.

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

А вот последний пункт я вообще не понял. О чем это?
Последний пункт называется: малое количество ограничений. Вот я и пытался понять в чем там ограничения? Там про плохой код, про баги написано. Так их же сами эти разработчики создают.
Ну да. Я так подозреваю, что из-за ограничений и создают. Потому что вместо усилий на написание кода усилия идут на совещания и согласования.
Вот давайте не будем всех разработчиков записывать в святых мученников. Мол это не мы такие "бездарные", а это совещаниями нас мучают. В любой отрасли среди любых людей есть профессионалы от бога и серые посредственности. Эти серые посредственности как писали плохие программы, так и будут писать. Совещания и согласования тут ни при чем.
Вот давайте не будем всех разработчиков записывать в святых мученников.

Давайте их по этому поводу запишем в извергов? ;)
Любое правило должно применяться адекватно.

Вы спросили, о чём этот пункт, я выдвинул предположение. Куда и как Вы его будете применять, дело Ваше.
Я не разработчик, я наблюдатель, и в нашем проекте хороший руководитель, он не требует чего-то нереального и условие создал......можно смело сказать что все в какой-то степени пункты выполнил, но разработчики люди - а к каждому человеку нужен личный подход. Если их 5, то как правило 2 чем то недовольны и хотят совершенно противоположное))))) тяжело угодить всем одновременно.
Согласен. Хочу добавить: в каждом коллективе всегда найдутся такие, кому всё плохо и которые всё критикуют вплоть до начальства :)
хуже того, есть паренёк который еще на 4 курсе учиться получает больше тысячи баксов, сидит в ШИКАРНОМ офисе, работа интересная, шеф человечен, и все равно что то не так. Хочет сваливать в никуда - ему просто не хочется чего-то, а чего именно он сам не может сформулировать. Шеф в шоке, не знает как ему условия поменять, просто парень уже работает больше полугода и проект надо сдавать, а искать нового работника это долго. Вот так вот бывает)))) Так что все эти правила и настолько индивидуальны, что под каждого разработчика свои должны быть))) Как инструкция к применению))))
знакомая история.
наверное это потому, что паренек не знает о правиле номер 0: заниматься только той работой, которую в кайф делать даже за бесплатно.
так в том и дело, что он не знает что в кайф ему же, а что нет..........он просто не опредилен....вот как к такому достучаться?
Мужика осудили и приговорили к смерти через электрический стул. Настал день казни, привели его в комнату со стулом и вдруг поняли, что мужик просто не вместится на этот стул - уж слишком толстым он был. Было решено перенести казнь на неделю вперед, а мужика посадить на диету. Через неделю выяснилось что мужик только набрал 10 кг. Все в недоумении. Перенесли еще на неделю, посадили на хлеб-воду. Прошла неделя, мужик набрал еще 5 кг. Все в шоке, спрашивают:
- мужик, ну открой секрет, как тебе это удается?
- все просто, ребята, недостаток мотивации
)))

вобщем почитайте книги по поднятию мотивации работников, может какая-нить техника и поможет ;)
спасибо за совет))) наглядный пример))) тут явно без психолога не обойтись)))просто, у меня вопрос в другом, как на собеседовании определить легко будет с этим разработчиком или нет???
перед приемом на работу дать разработчику испытательный срок и присматриваться к нему. других вариантов у меня нет )
На то оно и собеседование, чтобы вытянуть из кандидата как можно больше информации.
Думаю, что Вы сразу будете жить в Сочи, как только получите ответ на свой вопрос.
Синдром молодого работника. К хорошему очень быстро привыкаешь. А у некоторых просто сносит крышу.
Заметка отличная, но, по идее, сводится к одному - талантливый разработчик, + грамотный организатор (руководитель) + великолепная идея = решение всех проблем. И проект получится успешный, и руководство всем довольно, и разработчик счастлив.
Мне кажется, эта статья может руководителям проектов и прочим организаторам понять программистов. Может, по-другому посмотреть на их странности.
Мда. Позволю внести свой кусочек скепсиса: а если звезды над проектом не так сошлись? Никакая идея не поможет. :)
НЛО прилетело и опубликовало эту надпись здесь
Точно. По своему, путсь и небогатому опыту, знаю, что постоянная подгонка и нереальные дедлайны убивают энтузиазм сильнее всего. Даже сильнее, чем неподходящая конфигурация железа. Правда, наравне с ними еще и дурацкая обстановка и отношения.

Насчет обучения — тоже верно. Лично я при выборе следующей работы руководствуюсь деньгами, не больше чем интересностью, в определенных пределах, конечно. К примеру, если есть не очень занимательная работа при этом не отнимающая много времени и приносящая ощутимо больший доход, чем очень желанная и интересная, но дешевая — выбор будет на стороне первой, а интерес будет удовлетворяться на open-source проектах и просто програмировании и дизайне для себя. Но это matter of wealth.

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

Кстати, добавил бы еще один пункт — «Дайте разработчику спокойно работать». Тезисы — время (именно то, что в Getting Real называется Alone Time), спокойствие (не валите на него сразу еще и другие проблемы, меньше текучки, в илеале — ноль), слушайте его идеи (участие в проектировании проекта, а не только в реализации, хоть это и не всем интересно, но выбор должен быть).
Я сам порой рад, когда люди своими постами напрявят в нужный адрес, где можно почитать интересное. Понимаю, что перевод — это уже "не то", поэтому всегда есть ссылка для тех, кто предпочитает оригиналы. Карму начинает постигать инфляция, поэтому не переживай даже особо — вопрос краткого периода времени ;)
Полностью согласен со статьей. Знакомый психолог говорит, что деньги вообще не мотивация, или очень слабая мотивация.
Для кого? Для какого возраста, какого социального статуса, наконец какой национальности?
Что деньги не мотвируют это эдакий миф, который придумали бизнесмены. Убеди в этом окружающих и зарабатывай деньги. :) Деньги просто нельзя рассматривать отдельно от всего остального.
а цепочка нету работы - нету денег - семья сдохнет с голоду уже совсем не мотивирует?
Ну, я думаю речь шла о "зарплата: больше-меньше", а не о "работа: есть-нет".
Ага. Психологи там что-то себе имели ввиду, все говорят, но никто толком не знает, что они там себе ввиду имели.
Программистам можно вообще не платить за интересную работу, их счастье, что у них хватает мозгов не говорить об этом начальству.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.