Pull to refresh

Comments 21

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

Типа семья побоку, лишь бы шефу было хорошо? Ну-ну…
В таком случае, не стОит давать подобные обещания. Дальше написано же, что жертвы — дело добровольное.
Дело не в шефе, дело во внутренних принципах. «Всегда хорошо делать свою работу» превращается в преодоление трудностей и препятствий на пути к внутренней гармонии. Это как найти себя и быть собой.
UFO just landed and posted this here
чего так заминусовали сразу? дельный вопрос. по-моему, работает для жизни, а не живем для работы.
нужно работу так выстроить, чтобы не жертвовать любимыми делами или людьми
статья действительно исповедует «немецкий» способ менеджмента — нужно попытаться взять из него лучшее
Если бы вы внимательно прочитали ответы на тот коммент — вопросов бы не было.

Добавлю от себя: налицо явное передергивание. Человек сначала цитирует исходное утверждение «Я готов идти на личные жертвы, чтобы сдержать свое слово», а потом пишет «Типа семья побоку, лишь бы шефу было хорошо. Подскажите, с каких пор «держать свое слово» == «лишь бы шефу было хорошо»??? Разве вы не видите, что смысл исходного утверждения был совершенно иной, а не «Идти на личные жертвы, лишь бы шефу было хорошо»?
Браво. Это как раз то что вертелось в голове и хотелось сформулировать.

А вот антистатья habrahabr.ru/post/148358/. ;)
«антистатья» также хороша!
Если Вы единственный кто принял для себя этот Кодекс — Вы обречены. Окружающие будут пользоваться Вашей доброй волей и Вашим временем. Они будут пользоваться этим, а значит вы очень скоро откажетесь от него

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

Предпочли громко материться и смеяться вместо взаимного уважения.
Про честь и обещания: очень часто менеджеры не понимают, что программист — не всеведущее божество и требуют до начала работ достаточно точно указать срок. Ну, не требуют… Скорее, выпрашивают. И из каких-то там своих соображений дают запас процентов 30. Вроде как, мы пошли на встречу. Они, будто бы, не понимают, что бывают новые задачи, для реализации которых нужно предварительное изучение вопроса, обучение. Бывают сложные задачи, для которых требуется какое-то вдохновение, что ли… (не знаю, как у программистов это называется).

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

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

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

Этот кодекс — отличная вещь, но в жизни нужно соизмерять масштабы жертв и не портить себе жизнь, даже если вы поставили себя в угол непродуманным обещанием.
В вашем типичном для отечественного программиста случае менеджер — тот, кто не придерживается кодекса. Конечно жертвовать не надо, но не потому что никто не умрёт, а потому что у этого конкретного менеджера нет чести.
Требуют срок «хотя бы примерно!», а потом просят его соблюдать.
Действительно, встречаются такие.

Я один раз пострадал от менеджера-хитрюги с таким вот подходом и в следующий раз срок категорически отказался ему называть. Сказал, что слишком много неизвестных (а там их было действительно выше крыши + моя работа зависела от многих других людей) и я не могу назвать даже приблизительный срок. Я ему сказал:
— Я вот назову сейчас приблизительный срок, а вы потом за него опять спросите с меня как за реальный и окончательный — даже не разбираясь, виноват ли я, кто-нибудь другой или вообще виноватых нет, а всех участвующих еще и поощрить не мешало бы за ударную работу в условиях открывшихся позже проблем.
Как он ни старался выбить из меня конечный срок — ничего у него не получилось. Единственное, что я назвал — срок первого, ознакомительного этапа, после которого можно будет определиться с объемом 2-го этапа и хотя бы приблизительным списком остальных этапов. Считаю, что с такими менеджерами только так и следует поступать.
«Если сделать эту работу позже, то никто не умрет и не заболеет» — верно, но возможно кто-то недополучит прибыль (ради которой он и заказывал у вас работу), или не сможет вовремя выпустить продукт и (возможно), как результат, обанкротится и не сможет заплатить вам или вашей компании. Вполне вероятно компания выплатит из-за срыва сроков штраф, который не сможет компенсировать за счет вашей зарплаты :) Сроки для бизнеса иногда важнее чем качество, как это ни странно. Хотя вполне возможен сценарий что на самом деле срок не важен, и менеджер требует его по привычке. Но далеко не всегда.

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

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

Сам я программист, не менеджер, но фрилансер, так что всю эту кухню немного знаю. Просто что-бы не считали что я очередной теоретик, далекий от реальности.
Из фразы «примерный срок» почему то рождаются обещания. Что за фигня? Я не обещал, я назвал примерный срок! С каких пор слово примерно = слову «точно»?
ну если мы говорим о моральных обязательствах, если менеджер вдруг решил обмануть себя и других, превратив примерный срок, в точный — это уже его проблемы. с таким же успехом он мог сам придумать срок, никого не спрашивая. никаких моральных обязательств для разработчика тут нет.
Sign up to leave a comment.

Articles