Як вистояти, коли колеги нехтують процесом?

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

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 хвилин. Отже, в основному вони погодилися на щось зовсім інше, ніж я запропонував.

Проблема може полягати в тому, що вони не хочуть платити за якість. Це може привести їх до того, щоб раціоналізувати вас критику як скуголення, але, на мій досвід, це не так. Технічна заборгованість може бути не такою видимою, і її легко віднести до обставин, але з часом реальність настає.

Сподіваємось, до цього вони зрозуміли це, або ви переключили Джобса.

Можливо, це ти

Здається, ви віддаєте перевагу дуже структурованому та організованому способу кодування, схоже, що ваші товариші по команді мають більш підхід "діло". Тепер ви згадуєте, що це призводить до багато "витраченого часу", тому, можливо, якась структура в порядку, і немає ніякого приводу для неохайної роботи. Однак проекти програмного забезпечення, як правило, є текучими, а застосування занадто великої структури також спричинить багато організаційних витрат.

Можливо, вам слід зустрітись посередині і спробувати більш спритний та інтерактивний, але структурований підхід.

Хто відповідає за цих людей? Хтось їх найняв, а хтось може їх звільнити / притягнути до відповідальності.

"Моя компанія вимагає ..." безглуздо без певного примусового виконання.

Ви не можете пред'являти вимоги до часу, що не дозволяє виробничому процесу.

Здається, що це відсутність контролю та нереалістичні очікування - причини низької якості.

Ви можете або: піти, стати провідним розробником, нічого не робити, або почати працювати з тими, хто відчуває себе так, як ви. Переконайтесь, що всі знають, що ви будете дотримуватися правильних процедур, поки хтось не знайде кращий спосіб і не змінить їх. Звучить як "Правила сидерного будинку".

Здається, ви не хочете, щоб ваші колеги дотримувалися зовсім іншого процесу, ви просто хочете, щоб вони приймали різні рішення в ньому. Звичайно, є правила (настанови?) Щодо того, що їм робити, і вони їх ігнорують. Але проблема, яку ви описуєте, полягає в тому, що вони повинні прийняти рішення (розпочати роботу над проектом або відхилити специфікацію), і вони вирішили продовжувати роботу. Це рішення не зміниться, якщо ви будете нагадувати їм правила; вони просто не хвилюються стільки правил, скільки ви . Вони хочуть відчути себе корисними, а кажучи, що ні, це не робить їх корисними .

Якщо ви хочете, щоб їх поведінка змінювалася, то постійне нагадування їм про правила, мабуть, не дуже ефективно; це швидше призведе до того, що вони вас ігнорують. Спробуйте знайти спосіб змінити процес, щоб вони почували себе кориснішими, продовжуючи стежити за процесом. Чи можете ви реалізувати якийсь огляд коду, перевіряючи код один одного та вивчаючи один одного, щоб запобігти хакам зробити його виробничим кодом? Чи можете ви змінити спосіб обробки специфікацій (docs / ext.interfaces / front-end) від чорно-білого готового / незакінченого рішення до більш спільного процесу, коли наприкінці специфікації розробник просить допомогти закінчити? (І, ви повинні визнати , що вимоги будуть змінюватися)

Переважно це не ти, це не вони, це процес. Якщо ви (і ваш прем'єр-міністр) зможете знайти спосіб організувати речі, коли людям не потрібно так сильно йти проти свого характеру, процес буде дотримуватися набагато швидше.

Йдеться про той момент, коли я завітав на сесію із закритими дверима зі своїм керівником команди. Сподіваємось, у вас є досить хороші робочі стосунки з ведучими, що ви можете зробити це дуже неформальним.

Мета зустрічі - з’ясувати, чому команда робить речі так, як їх робить. Якщо всі зібралися, кивнули, посміхнулися і погодилися на новий процес, то чому вони все ще не змінюються? Цілком ймовірно, що він проходить набагато глибше, ніж прості небайдужі чи некомпетентні. Цілком ймовірно, що на роботі є водії, яких не видно неозброєним оком.

Почніть засідання, припускаючи, що ваші колеги, якщо зможуть, слідкують за процесом, який призводить до меншої паніки, меншої технічної заборгованості та більшої якості продукції - адже хто цього не хоче? То яка небачена сила?

Здається, що перед передовою роботою з дизайну та прототипу інтерфейсу існує багато втілення / інтеграції. Чи не вистачає в компанії людей, які можуть виконувати цю передову роботу? Можливо, ти зможеш піти на волю. Чи є проблема з консенсусом із зацікавленими сторонами? Можливо, ваша команда може знайти новий спосіб спілкування з ними або може скористатися новим підходом до документування припущень.

Якщо ви почнете з одного на один, де ви запитаєте свого ведучого, чому тоді ви можете відкрити двері для дискусії, що дозволяє уникнути оборонності та зосереджується на проблемах та рішеннях.

Ще одна хитрість може полягати в тому, щоб запитати, чи можна піонірувати новий спосіб робити справи. Зворотній зв'язок з вашою командою призведе до того, щоб змусити проблему трохи і дозволити вам використовувати підхід, який ви пропагуєте - це, ймовірно, викличе проблеми, коли ви долаєте "систему", тому ви хочете, щоб управління було позаду вас. Але якщо ви виявитеся більш продуктивними та без стресу, ви зможете змінити спосіб речей, і ви, ймовірно, виграєте адвокатів.