Здравствуйте, kostik78, Вы писали:
K> Но как только ему предлагают взят и вести проект from ground который требует межкомандного общения — типичный ответ, что ему за это не платят. Что собственно понятно, очень легко критиковать но гораздо труднее сделать.
Дык эта.... А просто платить инженеру за ведение проекта — не пробовали?
Разумеется, любой работник, если его попытаются нагрузить дополнительными обязанностями без адекватного изменения в зарплате — будет отбрыкиваться руками и ногами.
Здравствуйте, kostik78,
K> В списке требований к фиче обратная совместимость была. Инженер просто забил на нее ибо это сильно мешало ему. Опять же со слов инженера. Код ревью в данном случае был пропушен в виду неизвестных мне причин и инженер работал один.
Оба-на! Вот тебе, бабушка, и Юрьев день.... Инженер "просто забил" на требование. Причем — важное с точки зрения бизнеса. А чем в это время занимался его непосредственный начальник? И как тогда эта версия/сборка смогла пройти тестирование и испытания? А если не прошла — она не могла попасть в продакшен... Или все-же попала?
Разруха — она не в клозетах, да-с.
1/17/2014 1:45 AM, SkyDance пишет:
> Представь себя на месте менеджера.
Что тут ставить, сам был не раз на оном месте. Но я обычно старался
объяснить предлагателю почему в текущий момент мы это реализовать
позволить себе не можем. И даже, если председателю давалось добро на
реализацию, я соломку стелил — организовывал работу так, чтобы на откат
к старому тратилось не более пары дней (очко-то не железное).
1/17/2014 1:47 AM, SkyDance пишет:
> Поверьте, менеджер это прекрасно осознает.
Менеджеры ну очень разные бывают и часто качественный опыт и знания у
них только в одном — умении работать языком (если начну приводить
примеры с названиями контор меня здесь забанят, есть фирмы о которых
можно говорить только, как о мертвых, да и мне лишние срачи поднимать
неохота).
А тот, который осознает, он всегда может обосновано объяснить почему
сейчас это реализовывать нельзя, организовать работу так, чтобы
реализация не сломала уже работающее и объяснить, когда можно будет
делать эту реализацию. А да, предлагающие в 99.9 случаях понимают
объяснения и не ведут ситуацию к описанной в первом посте.
1/17/2014 3:29 AM, kostik78 пишет:
> Плюс дополнительно > работа на директорской позиции дало мне понимание бизнес стороны > проектов или их кусочков. > > Я же пытался сказать что критиковать мы все горазды а вот показать на > деле какие мы не многие соглашаються.
Как-то эти 2 высказывания плохо согласуются.
1/17/2014 3:53 AM, kostik78 пишет:
> Разработчик почасав > репу и посмотрев в код сказал что не знает точно но лучше бы выключить > фичу, так как это ничему не повредить. Ок что сказано то сделано, > выключили.
> ни кто его не винил в данных убытка в последствии. Но если бы он сказал > про пропадание странички то решение возможно было другим.
Великолепный пример. Инженер — бог?
1/17/2014 8:27 AM, kostik78 пишет:
> А к чему я это — хочется чтобы всетаки разработчики задумались и > обратили внимание что ихнее руководство всетаки не штаны просиживает как > многие здесь пытаются представить.
В данном примере просиживает и не более.
Ни в коему случае не поступил бы так, как описано тобой. Только через
тестирование и очень нежные аккуратные пробы, чтобы если что не так
максимально быстро все вернуть в рабочее состояние. Толстый слой соломки
сначала, а потом уже и прыгать.
Здравствуйте, kostik78, Вы писали:
K>Всетаки разработчик сказал "что не знаю точно, но вреда принести не должно". Это как бы ответ человека который проектировал и разрабатывал интеграцию и должен знать все "итимности сей интеграции". Вы бы на месте директора что сделали при условиях что алтернатива только ручной регрешен 3 QA инженеров на 6-8 часов?
В прицнипе тут главное, что инженер не на 100% был уверен в своем ответе. В этом случае уже вышестоящему руководству надо было как-то задуматься, хотя бы на пару минут.
Даже если инженер мне скажет, что "мамой клянусь, все будет ништяк", я все равно протестирую перед тем как выкатывать что-либо. Иначе при любом косяке мешок люлей дадут мне и заказчики и начальство.
Здравствуйте, Vzhyk, Вы писали:
V>1/17/2014 8:27 AM, kostik78 пишет:
>> А к чему я это — хочется чтобы всетаки разработчики задумались и >> обратили внимание что ихнее руководство всетаки не штаны просиживает как >> многие здесь пытаются представить. V>В данном примере просиживает и не более.
V>Ни в коему случае не поступил бы так, как описано тобой. Только через V>тестирование и очень нежные аккуратные пробы, чтобы если что не так V>максимально быстро все вернуть в рабочее состояние. Толстый слой соломки V>сначала, а потом уже и прыгать.
Что и требовалось доказать. Что было бы не сказано или сделано, менеджер всегда "виноват" на rsdn. Честно говоря я другого не ожидал. Очень четко прослеживается данная линия в других ветках где заходит разговор про менеджеров.
Здравствуйте, Vzhyk, Вы писали:
V>1/17/2014 3:29 AM, kostik78 пишет:
>> Плюс дополнительно >> работа на директорской позиции дало мне понимание бизнес стороны >> проектов или их кусочков. >> >> Я же пытался сказать что критиковать мы все горазды а вот показать на >> деле какие мы не многие соглашаються. V>Как-то эти 2 высказывания плохо согласуются.
Ну как я уже говорил — Ваше право.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, kostik78, Вы писали:
K>> Но как только ему предлагают взят и вести проект from ground который требует межкомандного общения — типичный ответ, что ему за это не платят. Что собственно понятно, очень легко критиковать но гораздо труднее сделать.
V_S>Дык эта.... А просто платить инженеру за ведение проекта — не пробовали? V_S>Разумеется, любой работник, если его попытаются нагрузить дополнительными обязанностями без адекватного изменения в зарплате — будет отбрыкиваться руками и ногами.
Предлагал — нормальную премию по успешному завершению проекта. С последующим увеличением зарплаты при годовом performance review. Пару человек бралось но по середине проекта стали забивать на организиционные "мелочи" Приходилось вмешиватся что бы проект не загнулся.
Здравствуйте, kostik78, Вы писали:
K>Что и требовалось доказать. Что было бы не сказано или сделано, менеджер всегда "виноват" на rsdn. Честно говоря я другого не ожидал. Очень четко прослеживается данная линия в других ветках где заходит разговор про менеджеров.
Да. Я всегда так считал и считаю и когда менеджерил и когда не менеджерил. Он принимает решения и отвечает за них. А линейные разработчики должны просто делать качественно те задачи, что им поставили — и их ответсвенность только в этом.
1/17/2014 4:36 PM, kostik78 пишет:
> Предлагал — нормальную премию по успешному завершению проекта. С > последующим увеличением зарплаты при годовом performance review. Пару > человек бралось но по середине проекта стали забивать на организиционные > "мелочи" Приходилось вмешиватся что бы проект не загнулся.
Потому что предлагать надо не всем, а только тем, кто способен
организоваться (организовать) и довести дело до конца. На это ты и
руководитель, чтобы знать, кто и что может, а кто и что не может.
Это все выясняется в процессе работы постановкой задач разного уровня и
отслеживание того, как человек их выполняет.
Есть море высококлассных программистов, которые не просто не могут даже
месяц самостоятельно работать, а их работу надо отслеживать каждые
несколько дней. Я уже не говорю о самостоятельном выполнении проекта.
З.Ы. Ты извини, но тобой написанное больше характеризует тебя как
"эффективного менеджера", как совет проанализируй свои действия как
руководителя. Какие книжки почитай, по психологии той же, психологии
коллектива.
Здравствуйте, Vzhyk, Вы писали:
V>Здравствуйте, kostik78, Вы писали:
K>>Что и требовалось доказать. Что было бы не сказано или сделано, менеджер всегда "виноват" на rsdn. Честно говоря я другого не ожидал. Очень четко прослеживается данная линия в других ветках где заходит разговор про менеджеров. V>Да. Я всегда так считал и считаю и когда менеджерил и когда не менеджерил. Он принимает решения и отвечает за них. А линейные разработчики должны просто делать качественно те задачи, что им поставили — и их ответсвенность только в этом.
Дык в данном пример отвественность как раз осталась на директоре, и он ее не делигировал на разработчика
З.Ы. Чтобы отсеять возможный вопрос, в данном примере я участвовал как главный разработчик а не директор. И мой персональный фаулт в данной ситуции был — я не учел возможные последствия для UI и не сказал об этом своем начальнику. И считаю что это моя вина а не директора, который доверяет мне.
Здравствуйте, kostik78, Вы писали:
K>З.Ы. Чтобы отсеять возможный вопрос, в данном примере я участвовал как главный разработчик а не директор. И мой персональный фаулт в данной ситуции был — я не учел возможные последствия для UI и не сказал об этом своем начальнику. И считаю что это моя вина а не директора, который доверяет мне.
Есть потрясающий принцип: Доверяй, но проверяй. Без него, к сожалению, в IT ну совсем никак. Именно в таких случаях лучше собрать несколько мнений, не плохо так же спросить тестовый отдел, потому что они могут знать последствия выкидывания той или иной фичи лучше, нежели разработчик, который даже эту фичу и писал, но не знает по каким-то причинам где она еще может использоваться.
Здравствуйте, Vzhyk, Вы писали:
V>1/17/2014 4:36 PM, kostik78 пишет:
V>Потому что предлагать надо не всем, а только тем, кто способен V>организоваться (организовать) и довести дело до конца. На это ты и V>руководитель, чтобы знать, кто и что может, а кто и что не может. V>Это все выясняется в процессе работы постановкой задач разного уровня и V>отслеживание того, как человек их выполняет. V>Есть море высококлассных программистов, которые не просто не могут даже V>месяц самостоятельно работать, а их работу надо отслеживать каждые V>несколько дней. Я уже не говорю о самостоятельном выполнении проекта.
Вы сделали вывод без знания конкректных деталей- кому было предложено и были у него предпосылки на успех.
V>З.Ы. Ты извини, но тобой написанное больше характеризует тебя как V>"эффективного менеджера", как совет проанализируй свои действия как V>руководителя. Какие книжки почитай, по психологии той же, психологии V>коллектива.
Спасибо за совет, я конечно подумаю об этом. Но в текущий момент это мне не нужно. Сейчас у меня подчинненых = 0.
З.Ы. Раз Вы перешли на личность, моя оценка Вам — Вы делаете очень резкие выводы не даваясь в детали конкретной ситуцаии. Как бы тоже имеет смысл задуматься.
1/17/2014 5:48 PM, kostik78 пишет:
> З.Ы. Чтобы отсеять возможный вопрос, в данном примере я участвовал как > главный разработчик а не директор. И мой персональный фаулт в данной > ситуции был — я не учел возможные последствия для UI и не сказал об этом > своем начальнику.
Задним умом все крепки. Разработчик часто даже предположить не может
многие места, где что-то может отвалиться, особенно, если проект не из
3-х строчек кода.
Для этого и тестеры и руководство есть. Первые, что найти эти места,
вторые, чтобы принимать решения и ответственность.
Вина в той ошибке только на руководителе. Даже, если он тебе доверял
больше, чем своей жене, это никак не говорит о том, что ты не мог ошибиться.
1/17/2014 5:56 PM, kostik78 пишет:
> V>Потому что предлагать надо не всем, а только тем, кто способен > V>организоваться (организовать) и довести дело до конца. На это ты и > V>руководитель, чтобы знать, кто и что может, а кто и что не может. > V>Это все выясняется в процессе работы постановкой задач разного уровня и > V>отслеживание того, как человек их выполняет. > V>Есть море высококлассных программистов, которые не просто не могут даже > V>месяц самостоятельно работать, а их работу надо отслеживать каждые > V>несколько дней. Я уже не говорю о самостоятельном выполнении проекта. > Вы сделали вывод без знания конкректных деталей- кому было предложено и > были у него предпосылки на успех.
Нет, это не вывод — это всего-лишь описание моего жизненного опыта о
людях в нашей области (точнее вывод, но из моего опыта).
> З.Ы. Раз Вы перешли на личность, моя оценка Вам — Вы делаете очень > резкие выводы не даваясь в детали конкретной ситуцаии. Как бы тоже имеет > смысл задуматься.
Я знаю и делаю это сознательно, причем еще специально утрирую многие
моменты.
И от этого есть проверенный плюс — удается поднять градус обсуждения и
почитать интересные мнения. Злясь, многие начинают писать более
однозначно и четко, не прячась за фразами ни о чем.
K>О чень часто непосредственный исполнитель не знает всего скопа задачи и данный проект может быть частью чего то большого. Соответсвено решения могут приниматся странные на его взгляд.
А в чем проблемма в той или иной форме выдать ему эту недостающую информацию?
K>Иногда надо принять просто на слово. В конце концов если ты не доверяешь коллеге, своему менеджеру то что за причина оставатся в этой команде. Мой опыт что удачные тимы это где люди доверяют друг другу и верят на слово как бы банально это не звучало.
Доверие берётся само из воздуха? Доверие мутному человеку вчера пришедшему рассказывающему "Ты пойми, так надо, нам же виднее, но мы не можем сказать тебе почему"
