Как стоять на месте, когда коллеги пренебрегают процессом?

Проблема, с которой я сталкиваюсь:

1. Члены моей команды начинают работать над проектами без готовой функциональной / технической документации - даже если процесс нашей компании требует, чтобы они были перед началом работы.
2. Члены моей команды принимают дешевые, неструктурированные решения и будут внедрять действительно плохие хаки в программное обеспечение, не задумываясь, когда руководство проекта отмечает, что у них «ограниченное время».
3. Члены моей команды начинают работать над проектами, которые работают вместе с незавершенным проектом другой команды, которая не прошла испытания и не была завершена. (вызывая много дополнительной работы).
4. Улучшения и весь этап (ы) программного обеспечения не спланированы должным образом, и часто это приводит к тому, что внешний интерфейс / проектирование не завершается, когда внутренний сервер должен начать работу.

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

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

Члены моей команды жалуются много - но только навстречу друг другу. They keep on going - whatever the situation is, Результат?

1. Я чувствую себя неуверенно, возможно, это я?
2. Это так и должно быть?

Мой вопрос? How can I say no against work ignoring the process if everyone else seems to mindlessly accept?,

Это не выглядит как надоедливый разработчик, который все время ищет что-то сучко.

Все действительно согласились?

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

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

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

Чтобы продемонстрировать это, я сформулировал Вопрос по-другому: «Пожалуйста, расставьте приоритеты для всего, что я должен делать (реализация функций, устранение ошибок, следование улучшенному процессу, очистка стола, прибытие вовремя)».

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

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

Надеюсь, до этого момента они это поняли, или вы сменили Джобса.

Возможно это ты

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

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

Кто несет ответственность за этих людей? Кто-то нанял их, а кто-то может их уволить / привлечь к ответственности.

«Моя компания требует ...» бессмысленно без какого-либо принуждения.

Вы не можете требовать времени, которое не учитывает производственный процесс.

Похоже, это отсутствие контроля и нереалистичные ожидания являются причинами низкого качества.

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

Похоже, вы не хотите, чтобы ваши коллеги следовали совершенно другому процессу, вы просто хотите, чтобы они принимали в нем разные решения. Конечно, есть правила (руководящие принципы?) О том, что они должны делать, и они их игнорируют. Но проблема, которую вы описываете, заключается в том, что они должны принять решение (начать работу над проектом или отклонить спецификацию), и они решают продолжать. Это решение не изменится, если вы будете постоянно напоминать им о правилах; им просто наплевать на правила так же, как и вам . Они хотят чувствовать себя полезными, и отказ от них не делает их полезными .

Если вы хотите, чтобы их поведение изменилось, то постоянно напоминать им о правилах, вероятно, не очень эффективно; это скорее приведет к тому, что они вас проигнорируют. Попробуйте найти способ изменить процесс, чтобы они чувствовали себя более полезными, в то же время следуя процессу. Можете ли вы реализовать какой-то обзор кода, проверяя код друг друга и учась друг у друга, чтобы не допустить попадания хаков в рабочий код? Можете ли вы изменить способ обработки спецификаций (docs / ext.interfaces / front-end) с черно-белого готового / незавершенного решения на более совместный процесс, когда ближе к концу спецификации разработчику предлагается помочь закончить? (И, вы должны признать , что требования будут меняться)

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

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

Цель встречи - выяснить, почему команда делает то, что делает. Если все собрались вместе, кивнули, улыбнулись и согласились на новый процесс, то почему они все еще не меняются? Скорее всего, это намного глубже, чем простое безразличие или некомпетентность. Скорее всего, на работе есть водители, которые не видны невооруженным глазом.

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

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

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

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