LINUX.ORG.RU

История изменений

Исправление shkolnick-kun, (текущая версия) :

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

Дихотомия не очевидна.

идя вразрез с сеюминутными прихотями какого-нибудь отдела маркетинга

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

упираясь и пытаясь продвигать

Это уже вопрос политики и он не входит в компетенции обычного разраба.

Так что выбор тут такой:

  1. Ты хочешь заниматься политикой, или нет?

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

ели да, то нужно делать следующий выбор:

  1. Ты хочешь быть руководителем, или нет?

если нет - иди в архитекторы, там у тебя будет возможность

пытаться продвигать

  1. Если все вокруг козлы, а разработчик Д’Артаньян

должен ли он

переквалифицироваться в менеджера?

Он может. Но (всегда есть это чертовое но, в каждом выборе присутствует оно (ц) Каста), ты должен понимать, что менеджеру найти работу гораздо сложнее, чем инженеру, говорю по собственному опыту.

Когда говнокод крутится, а бабло мутится, должно ли вообще кого-то волновать качество?

Смотря в какой фазе жизненного цикла проекта и продукта. Когда у меня были ресурсы, я делал так:

  • давал задачу быстрому говнокодеру наговнякать прототип (и плакал кровавыми слезами, глядя в код).

  • после того, как прототип пилотили и заказчик понимал, что ему на самом деле нужно, запускал процесс разработки нормального продукта.

  • поддержка прототипа прекращалась ровно в момент готовности продукта.

Исправление shkolnick-kun, :

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

Дихотомия не очевидна.

идя вразрез с сеюминутными прихотями какого-нибудь отдела маркетинга

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

упираясь и пытаясь продвигать

Это уже вопрос политики и он не входит в компетенции обычного разраба.

Так что выбор тут такой:

  1. Ты хочешь заниматься политикой, или нет?

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

ели да, то нужно делать следующий выбор:

  1. Ты хочешь быть руководителем, или нет?

если нет - иди в архитекторы, там у тебя будет возможность

пытаться продвигать

  1. Если все вокруг козлы, а разработчик Д’Артаньян

должен ли он

переквалифицироваться в менеджера?

Он может. Но (всегда есть это чертовое но, в каждом выборе присутствует оно), ты должен понимать, что менеджеру найти работу гораздо сложнее, чем инженеру, говорю по собственному опыту.

Когда говнокод крутится, а бабло мутится, должно ли вообще кого-то волновать качество?

Смотря в какой фазе жизненного цикла проекта и продукта. Когда у меня были ресурсы, я делал так:

  • давал задачу быстрому говнокодеру наговнякать прототип (и плакал кровавыми слезами, глядя в код).

  • после того, как прототип пилотили и заказчик понимал, что ему на самом деле нужно, запускал процесс разработки нормального продукта.

  • поддержка прототипа прекращалась ровно в момент готовности продукта.

Исправление shkolnick-kun, :

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

Дихотомия не очевидна.

идя вразрез с сеюминутными прихотями какого-нибудь отдела маркетинга

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

упираясь и пытаясь продвигать

Это уже вопрос политики и он не входит в компетенций обычного разраба.

Так что выбор тут такой:

  1. Ты хочешь заниматься политикой, или нет?

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

ели да, то нужно делать следующий выбор:

  1. Ты хочешь быть руководителем, или нет?

если нет - иди в архитекторы, там у тебя будет возможность

пытаться продвигать

  1. Если все вокруг козлы, а разработчик Д’Артаньян

должен ли он

переквалифицироваться в менеджера?

Он может. Но (всегда есть это чертовое но, в каждом выборе присутствует оно), ты должен понимать, что менеджеру найти работу гораздо сложнее, чем инженеру, говорю по собственному опыту.

Когда говнокод крутится, а бабло мутится, должно ли вообще кого-то волновать качество?

Смотря в какой фазе жизненного цикла проекта и продукта. Когда у меня были ресурсы, я делал так:

  • давал задачу быстрому говнокодеру наговнякать прототип (и плакал кровавыми слезами, глядя в код).

  • после того, как прототип пилотили и заказчик понимал, что ему на самом деле нужно, запускал процесс разработки нормального продукта.

  • поддержка прототипа прекращалась ровно в момент готовности продукта.

Исходная версия shkolnick-kun, :

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

Дихотомия не очевидна.

идя вразрез с сеюминутными прихотями какого-нибудь отдела маркетинга

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

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

Так что выбор тут такой:

  1. Ты хочешь заниматься политикой, или нет?

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

ели да, то нужно делать следующий выбор:

  1. Ты хочешь быть руководителем, или нет?

если нет - иди в архитекторы, там у тебя будет возможность

пытаться продвигать

  1. Если все вокруг козлы, а разработчик Д’Артаньян

должен ли он

переквалифицироваться в менеджера?

Он может. Но (всегда есть это чертовое но, в каждом выборе присутствует оно), ты должен понимать, что менеджеру найти работу гораздо сложнее, чем инженеру, говорю по собственному опыту.

Когда говнокод крутится, а бабло мутится, должно ли вообще кого-то волновать качество?

Смотря в какой фазе жизненного цикла проекта и продукта. Когда у меня были ресурсы, я делал так:

  • давал задачу быстрому говнокодеру наговнякать прототип (и плакал кровавыми слезами, глядя в код).

  • после того, как прототип пилотили и заказчик понимал, что ему на самом деле нужно, запускал процесс разработки нормального продукта.

  • поддержка прототипа прекращалась ровно в момент готовности продукта.