Скорее, хочешь поменять — пробуй разные подходы, делай выводы, пока не получится или не придёт понимание причин невозможности перемен. Надоест тратить силы впустую — уходи, ищи своё.
Стиль управления и мотивы решений можно научиться оперативно распознавать. Это приходит с опытом, если целенаправленно стараться этот опыт получить. Более того, многие детали о стиле руководства, отношении к сотрудникам, условиях и процессах в компании можно узнать ещё на этапе интервью, просто задав нужные вопросы. Собеседование это двусторонний процесс, а не кастинг, вы точно так же присматриваетесь, подходит ли компания вам, кап и предсиавители компании — подходите ли вы им.
Что касается схем в учебниках — признаться, тут я некомпетентнн, ибо ни единого на эту тему не прочёл, так что судить, работают ли какие-то методики, не могу. Однако, предполагаю, что истина где-то посередине — работают, в общих чертах. Ожидать, что кто-то выдаст вам универсальные, всегда работающие решения там, где замешана человеческая психология, по меньшей мере, наивно.
Указывать недостатки надо уметь. Можно ныть и поносить всё и вся, безрезультатно. А можно предлагать возможные решения и обсуждать их, совместно доводя до идеала. Важность социальных навыков программистами бывает сильно недооценена.
Если десятичасовые объяснения не возымели эффекта, нужно выяснять, почему. Как минимум, разузнать (и понять) аргументацию отказа. Убедиться, что вы преследуете совместимые цели. В конце концов, вы либо поймёте, как правильно преподнести своё предложение, либо найдёте альтернативный вариант, всех устраивающий. Либо, в худшем случае — узнаете, что ваши старания напрасны, смысла в трате сил на попытки применить свои профессиональные качества нет, здесь уже не исправить ничего, Господь, жги.
С работы, на которой вы не востребованы, уходить вполне нормально, иначе есть риск демотивации и профессиональной стагнации, а то и личностной деградации. Это вас тоже должно волновать, а не судьба компании, которой вы не нужны. Стокгольмский синдром, ей богу.
Это только в первый раз, и то только при неоптимальном подходе. Я б даже сказал — неправильном. Любой доклад надо выносить, в один присест мало кто способен сделать.
Основная часть вообще времени не занимает — проблемы находятся сами в рабочее время, возможные решения, равно как и повествовательная часть, формируются в уме фоновым процессом в любое время вообще, эксперименты, тесты, прототипы — зависит от желания: в личное (ну не прикручивать же очередной сторадж к реакту), в рабочее попутное или специально выделенное. Всё зависит от вовлечённости и желания реально достичь результата.
А слайды — скорее выжимка тезисов, изредка графики или скриншоты. Это несложно. Это же презентация технаря, а не маркетологов, тут смысл важен.
В таком случае, почему вы позволяете этому происходить, если деструктивная природа действий вам очевидна? Если работник, преследуя личные интересы, вредит производственному процессу и лично вашей работе — чем это отличается от воровства, например? Если вас реально волнует результат работы, почему вы позволяете кому-то обесценивать ваш труд и вредительствовать? Хата с краю?
Повторюсь, в конце концов, если невозможно исправить ситуацию — из неё всегда можно выйти. Было бы желание реально что-то делать, а не уныло констатировать факты.
Я повторю вопрос и вам — что вас держит на такой работе?
Если у вас есть аргументы, а у начальства нет — смысл такой работы? Быть инструментом автоматизации желаний? Чувствовать себя ничтожным? Просиживать штаны, выполняя тикет буква-в-букву?
Или просто не нравятся аргументы руководства? Или даже не пытались узнать?
Реально, я персонажей с такими настроениями повидал достаточно за пятнадцать лет в разработке. Всё плохо, руководство тупое, никто не слушает, накажут за инициативу… А чаще всего это означает завышенное самомнение, недостаток знаний и коммуникативных навыков, нерешительность и отсутствие инициативы. И, в конечном счёте — отрыв от реальности.
Можно быть гением программиррвария, но в жизни программирование должно приносить прибыль. Самая прекрасная архитектура бесполезна, если решает не те задачи, что требуются бизнесу. Для многих разработчиков профессия выросла из хобби, и удовольствие для них, по привычке, на первом месте. Но нанимают нас вовсе не для того, чтобы мы пускали радостные пузыри, полируя код, а чтобы мы эффективно решали задачи бизнеса в рамках имеющихся ограничений. И, на самом деле, это — реальный интересный вызов, а не игры в 30 строк на JavaScript.
И, замечу, эффективные социальные взаимодействия — тоже часть работы. Без понимания этих простых вроде вещей вы рискуете однажды обнаружить себя сорокалетним миддлом, изливающим душу на хабре.
Если можете самостоятельно выделить время в рамках рабочего, без ущерба для остальных задач — замечательно (это вообще важный навык).
Не можете или опасаетесь наказания за самодеятельность — обратитесь к руководителю и согласуйте с ним.
Боитесь просить руководителя или получили отказ, но сердце болит за проект — сделайте в личное время и заставьте выслушать.
Но сначала — сформулируйте, для себя в первую очередь, какой цели вы хотите достичь с точки зрения бизнеса. К примеру, «Сейчас мы тратим по два-три дня дорогого разработчика на добавление нового отчёта, так как надо писать SQL-запросы и готовить шаблоны на PHP. Эти задачи у нас регулярны. Если мы потратим две недели на новый модуль отчётов — в дальнейшем будем делать новые отчёты за считанные часы силами дешёвого верстальщика, потому что будет знакомый верстальщику XSLT и простенький генератор запросов. Это реальная экономия денег и времени, плюс мы сможем быстрее реагировать на пожелания пользователей, а разработчики займутся реальными задачами», вместо «Наши отчёты шляпа, легаси и говнокод, давайте сделаем нормально». Редкий вменяемый руководитель наотрез откажет, видя заинтересованность работника в результате. А если и откажет — можно не смириться сразу, а выяснить причины решения, возможно, вы видите не всю картину. В конце концов, если в руководстве реально невменько — что вы делаете на такой работе?
Вы не задумывались, что проблема может быть в способах, которыми вы высказываете своё мнение?
По опыту, «опять ты со своим брюзжанием, видишь одно только говно» — обычно ответ на условное «всё говно, архитектура говно, код плохой, всё будет только хуже» и в таком духе далее. И никакой другой реакции ожидать не приходится — посыл изначально деструктивен и вызвает желание ему сопротивляться.
Другое дело:
Колоеги, я провёл анализ результатов нашей работы по задаче А и хочу обсудить замеченные мною проблемы, а также предложить несколько решений для улучшения нашего продукта, кажущихся мне оптимальными.
На текущий момент у нас есть проблемы с архитектурой в %название_модуля%, заключающиеся в том, что %краткое_описание_проблем%. В дальнейшем, если мы продолжим развивать это решение, при разработке задачи Б, имеющейся в плане, нам придётся пойти на внедрение компромиссного решения %костыль%, что, впоследствии, в свою очередь, также увеличит трудозатраты на реализацию задачи В, в силу %список_причин%. Также возможно и %другое_решение% задачи Б, не имеющее этих недостатков, зато имеющее %другие_недостатки%. Кроме того, задача Г может оказаться и вовсе нерешаемой, так как %причины%.
Таким образом, мы можем оказаться в ситуации, когда дальнейшая разработка на основе текущего решения станет настолько трудозатратна, что выгоднее будет реализовать модуль заново. В пррцессе наверняка всплывут дополнительные проблемы, которые заранее предсказать невозможно, а так как продукт будет уже в зрелом состоянии, придётся тестировать гораздо больший объём взаимосвязанного функционала. Кроме того, на локализацию и устранение неизбежных ошибок также уйдёт труднопрогнозируемое количество времени, что повлечёт негатив от пользователей / риск срыва сроков по контракту / юридические последствия.
Исходя из вышесказнного, я предлагаю начать решать проблему сейчас, пока мы можем это сделать с меньшими трудозатратами. Хочу предложить %ряд_решений%, которые хороши тем, что %обоснование_решений%, а также дадут нам %дополнительные_возможности% и помогут избежать %ряда_проблем%. Для их реализации потребуется %время%, %человекочасы% и %иные_ресурсы%.
Возможно, я учёл не всё, а в некоторых оценках проблем ошибаюсь. Предложенные мною решения вряд ли идеальны, но, думаю, вполне подойдут в качестве стартовой точки для выработки дальнейшей стратегии. Хотелось бы услышать ваши мнения по поводу вышесказанного.
Конечно же, эта пламенная речь должна сопровождаться хотя бы парой слайдов, то есть, представлена в форме презентации. Важно внятно аргументировать свою позицию и пригласить к обсуждению. А главное — быть готовым тому, что ваша точка зрения может оказаться неверна.
Участие без предварительной регистрации или я нужную ссылку не вижу?
Очевидно, любые, вас интересующие. А уж там всё становится понятно по ответам или уклонению от них.
Скорее, хочешь поменять — пробуй разные подходы, делай выводы, пока не получится или не придёт понимание причин невозможности перемен. Надоест тратить силы впустую — уходи, ищи своё.
Стиль управления и мотивы решений можно научиться оперативно распознавать. Это приходит с опытом, если целенаправленно стараться этот опыт получить. Более того, многие детали о стиле руководства, отношении к сотрудникам, условиях и процессах в компании можно узнать ещё на этапе интервью, просто задав нужные вопросы. Собеседование это двусторонний процесс, а не кастинг, вы точно так же присматриваетесь, подходит ли компания вам, кап и предсиавители компании — подходите ли вы им.
Что касается схем в учебниках — признаться, тут я некомпетентнн, ибо ни единого на эту тему не прочёл, так что судить, работают ли какие-то методики, не могу. Однако, предполагаю, что истина где-то посередине — работают, в общих чертах. Ожидать, что кто-то выдаст вам универсальные, всегда работающие решения там, где замешана человеческая психология, по меньшей мере, наивно.
Указывать недостатки надо уметь. Можно ныть и поносить всё и вся, безрезультатно. А можно предлагать возможные решения и обсуждать их, совместно доводя до идеала. Важность социальных навыков программистами бывает сильно недооценена.
Если десятичасовые объяснения не возымели эффекта, нужно выяснять, почему. Как минимум, разузнать (и понять) аргументацию отказа. Убедиться, что вы преследуете совместимые цели. В конце концов, вы либо поймёте, как правильно преподнести своё предложение, либо найдёте альтернативный вариант, всех устраивающий. Либо, в худшем случае — узнаете, что ваши старания напрасны, смысла в трате сил на попытки применить свои профессиональные качества нет, здесь уже не исправить ничего, Господь, жги.
С работы, на которой вы не востребованы, уходить вполне нормально, иначе есть риск демотивации и профессиональной стагнации, а то и личностной деградации. Это вас тоже должно волновать, а не судьба компании, которой вы не нужны. Стокгольмский синдром, ей богу.
Это только в первый раз, и то только при неоптимальном подходе. Я б даже сказал — неправильном. Любой доклад надо выносить, в один присест мало кто способен сделать.
Основная часть вообще времени не занимает — проблемы находятся сами в рабочее время, возможные решения, равно как и повествовательная часть, формируются в уме фоновым процессом в любое время вообще, эксперименты, тесты, прототипы — зависит от желания: в личное (ну не прикручивать же очередной сторадж к реакту), в рабочее попутное или специально выделенное. Всё зависит от вовлечённости и желания реально достичь результата.
А слайды — скорее выжимка тезисов, изредка графики или скриншоты. Это несложно. Это же презентация технаря, а не маркетологов, тут смысл важен.
В таком случае, почему вы позволяете этому происходить, если деструктивная природа действий вам очевидна? Если работник, преследуя личные интересы, вредит производственному процессу и лично вашей работе — чем это отличается от воровства, например? Если вас реально волнует результат работы, почему вы позволяете кому-то обесценивать ваш труд и вредительствовать? Хата с краю?
Повторюсь, в конце концов, если невозможно исправить ситуацию — из неё всегда можно выйти. Было бы желание реально что-то делать, а не уныло констатировать факты.
Я повторю вопрос и вам — что вас держит на такой работе?
Если у вас есть аргументы, а у начальства нет — смысл такой работы? Быть инструментом автоматизации желаний? Чувствовать себя ничтожным? Просиживать штаны, выполняя тикет буква-в-букву?
Или просто не нравятся аргументы руководства? Или даже не пытались узнать?
Реально, я персонажей с такими настроениями повидал достаточно за пятнадцать лет в разработке. Всё плохо, руководство тупое, никто не слушает, накажут за инициативу… А чаще всего это означает завышенное самомнение, недостаток знаний и коммуникативных навыков, нерешительность и отсутствие инициативы. И, в конечном счёте — отрыв от реальности.
Можно быть гением программиррвария, но в жизни программирование должно приносить прибыль. Самая прекрасная архитектура бесполезна, если решает не те задачи, что требуются бизнесу. Для многих разработчиков профессия выросла из хобби, и удовольствие для них, по привычке, на первом месте. Но нанимают нас вовсе не для того, чтобы мы пускали радостные пузыри, полируя код, а чтобы мы эффективно решали задачи бизнеса в рамках имеющихся ограничений. И, на самом деле, это — реальный интересный вызов, а не игры в 30 строк на JavaScript.
И, замечу, эффективные социальные взаимодействия — тоже часть работы. Без понимания этих простых вроде вещей вы рискуете однажды обнаружить себя сорокалетним миддлом, изливающим душу на хабре.
Это ваш выбор.
Если можете самостоятельно выделить время в рамках рабочего, без ущерба для остальных задач — замечательно (это вообще важный навык).
Не можете или опасаетесь наказания за самодеятельность — обратитесь к руководителю и согласуйте с ним.
Боитесь просить руководителя или получили отказ, но сердце болит за проект — сделайте в личное время и заставьте выслушать.
Но сначала — сформулируйте, для себя в первую очередь, какой цели вы хотите достичь с точки зрения бизнеса. К примеру, «Сейчас мы тратим по два-три дня дорогого разработчика на добавление нового отчёта, так как надо писать SQL-запросы и готовить шаблоны на PHP. Эти задачи у нас регулярны. Если мы потратим две недели на новый модуль отчётов — в дальнейшем будем делать новые отчёты за считанные часы силами дешёвого верстальщика, потому что будет знакомый верстальщику XSLT и простенький генератор запросов. Это реальная экономия денег и времени, плюс мы сможем быстрее реагировать на пожелания пользователей, а разработчики займутся реальными задачами», вместо «Наши отчёты шляпа, легаси и говнокод, давайте сделаем нормально». Редкий вменяемый руководитель наотрез откажет, видя заинтересованность работника в результате. А если и откажет — можно не смириться сразу, а выяснить причины решения, возможно, вы видите не всю картину. В конце концов, если в руководстве реально невменько — что вы делаете на такой работе?
Вы не задумывались, что проблема может быть в способах, которыми вы высказываете своё мнение?
По опыту, «опять ты со своим брюзжанием, видишь одно только говно» — обычно ответ на условное «всё говно, архитектура говно, код плохой, всё будет только хуже» и в таком духе далее. И никакой другой реакции ожидать не приходится — посыл изначально деструктивен и вызвает желание ему сопротивляться.
Другое дело:
Конечно же, эта пламенная речь должна сопровождаться хотя бы парой слайдов, то есть, представлена в форме презентации. Важно внятно аргументировать свою позицию и пригласить к обсуждению. А главное — быть готовым тому, что ваша точка зрения может оказаться неверна.
Пробовали так?
даже почти моя модель есть, после редизайна, походу
уже 4 года живёт, уходят на секунду за месяц