Pull to refresh

Comments 13

>> надо заниматься только тем, что и так бы делал

Та не дай бог смешивать хобби и работу — останешься без хобби.
Или не придется работать.
UFO just landed and posted this here
> Так и вижу дизайнера, настраивающего базу данных…

Это было про совместное владение кодом. Программным кодом — значит про программирование. Но, кстати, хорошо что про базу сказали — был отличный пример когда все кодировали, а базой только один человек занимался — типа, он разбирается, зачем нам лезть. И это выросло в большую проблему, решением которой было как раз всем разобраться в нюансах SQL сервера.
UFO just landed and posted this here
Мы библиотеки пишем — у нас задачи дизайна все-таки не такой процент занимают как при разработке сайтов. Именно в команде из 2-4 человек у нас обычно нет дизайнера.

Но я уверен, что и более дизайн-итенсивном процессе можно работать командой. Подходы могут быть разные — главное чтобы не было синдрома «not my job» и результат был виден сразу. Например, я считаю что дизайнер должен HTML/CSS производить а не картинки в фотошопе — то есть, быть ближе к сути работы.
Вот хорошее видео о работе дизайнера в команде с гибким подходом
leanca.mp/2010/11/37-signals-design-process-explained/
1) «Работа должна быть в удовольствие» — +1

2) «Главная ценность? Приносить пользу. Деньги важны как мерило этой пользы» — то есть, если хорошо работать и, учитывая п. 1, следует, что будешь получать достойную ЗП — это очевидно.

3) «Программирование — это все-таки искусство, а не ремесло.» — возможно и было актуально лет 10-15 назад. Сейчас это обычная работа, обычный инженер.

4) «Если кого-то слушаются, значит, он более убедителен» — есть люди, которые не любят кому то что то доказывать и не хотят чтобы их слушали, но сами по себе являются профессионалами.

5) «Надо поменьше принимать решения за других» — +1

6) «Мы практикуем совместное владение кодом. Соответственно, существует разумный размер команды» — это работает для таких фирм как DevExpress. Когда вы сами себе хозяева. Сами планируете итерации, фичи, можете позволить себе что то не делать в данной итерации, отводите планированию достаточно времени. Вы сами себе заказчик и вы ни от кого не зависите. И это совсем не работает когда у тебя есть злой заказчик, дедлайн, и контролы, которые не работают так как вы ожидали, а времени нет.

7) «Не страшно ошибаться, надо просто снизить цену ошибки» — тоже самое что и п. 8.

Самое главное:

9) «Все люди на одном уровне получают одинаковые деньги.» — 60 человек одного уровня получают одну и туже ЗП — не верю что они «одинаково работают». Первые стремятся вырасти, работают по 60 часов в неделю, другие давно «текут по течению» — и получают одну ЗП, это как минимум не справедливо к первым, как максимум — проблемы с мотивацией в будущем у них же. Интересно, сколько продержится такой человек? Внедрите Time Tracking system (типа www.paymo.biz/) и поймёте, что все люди работают по-разному. Я к тому, что не надо всех мерить одной линейкой и разбивать на 5 категорий, все индивидуальны и подход ко всем должен быть индивидуальный, и материально вознаграждать всех следует по разному.

Всем привет! ;)
Как внедрение тайм трекера измерит результативность сотрудника? Как измерять время на размышления? Единственным мерилом квалификации является справляется сотрудник с потоком задач или не справляется. Если одному необходимо 60 часов кодить, чтобы справляться с потоком задач, с которым другой справляется за 20, то что-то здесь не так и не надо платить первому больше второго.
И мне кажется, что вы неправильно поняли фразу «Все люди на одном уровне получают одинаковые деньги.» — это не все люди в компании на одном уровне, а некий срез работников с одинаковой квалификацией получают одни деньги.
> И это совсем не работает когда у тебя есть злой заказчик, дедлайн, и контролы, которые не работают так как вы ожидали, а времени нет.

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

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

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

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

Часто бывает что у «меня» наоборот, меньше информации :( Но таки, я обеими руками за это правило и всегда так делаю. Отказ от моей идеи я как правило принимаю только в случае осознания факта некорректности идеи. Ну или я слышу 2 раза фразу «просто сделай так и все».

На счет расширения полномочий… это и хорошо и плохо. С одной стороны ты лучше понимаешь систему в целом. С другой… я в текущий момент являюсь создателем и владыкой нашего CI процесса, автором инсталятора «все для всего», поддерживаю маленькую часть функционала в Symbian клиенте, готовлю спец билды, являюсь автором(суппортом) мелкого шлюза и владыкой раций… я отдуваюсь за все это :(
Для этого правило — ничего не делай один. Вплоть тупо до парного программирования. Ну а лучше чтобы команда в этом разбиралась
Не всем так везет с работой
Sign up to leave a comment.